0

linux security and root access question....

I'm setting up a server that has a validator node running on it for a blockchain. I was trying to harden the security of my server. I set up ufw for all ports but those necessary for the node to operate. I set up 2FA, SSH with ed25519, and then I was spending time trying to figure out, if for some crazy reason someone got in... how could I stop someone from using systemctl or poweroff with sudo privilages. The goal is maximize uptime and remain in sync with the other nodes at all times.

Anyways, I started blocking bash commands for the user account that allows SSH and blocked SSH to root. Then I blocked a few more commands and thought, what if someone could find their way around this? So, I just started blocking too many things lol. Even though I disabled sudo for the user and blocked a number of commands the user could still use systemctl and stop the service for the node. Eventually I found this guide on how to only allow a few commands for a user.

Update: I didn't properly remove the user from the sudo group. Afterwards they could still use systemctl but the system then allowed systemctl to pop up with an input for the root user password for authentication. Anyways, I just wanted something simple yet secure sooo....

I ended up removing all of the commands from the user and symlinked the su command and renamed it to a random command that only I know. All of the other commands done by the user respond with

-rbash: /usr/lib/command-not-found: restricted: cannot specify /' in command names

I took away bash history and bash autocomplete/tab completion. Now the only thing you can do is guess commands that will get you to the point where you still have to get past my root password.

Anyways, I'm saying all of this because I have always heard best security practices involve "disabling root". Sometimes I see it as just disable root SSH, which i already have done, but sometimes i read it like disable the root account. Some say disable the password and try to divvy it up with sudo privileges so it's more traceable to individual users, but I'm just one guy with a server.

In my case I need to preserve root access in some way but I basically hid everything within the root user. So, if anyone gets access to root it's over. But, it's behind 2FA, SSH, and an unknown command that just gets to where you can try a password to access root.

Am I thinking about this "disable root for security" all wrong and I should disable it completely or does it make sense what I've done so far?

1

I find this slightly ironic. Basically your expressed concern here is to guarantee maximum uptime for a system even after it is compromised. If you detect a breach, your concern should be to shut it down asap and cut off access for attackers. If uptime is important, then you need to think about a redundant architecture involving multiple servers.

So I don't think your efforts make sense and will increase your security posture at all.

Indeed, the goal is to minimize the attack surface. So you block all ports that should not be exposed. That's what the firewall is for. Use public key authentication for SSH. But the SSH server may still allow password access. So it doesn't hurt to add Fail2Ban or CSF+LFD on top of that, so that brute force attempts will be frustrated.

Even better if you can, restrict access to a few whitelisted IP addresses under your control. My servers are configured in such a way that only a few designated IP addresses can connect to them over SSH, which means I must be on VPN for that.

You can use the netstat command to list the processes listening for network connections, make sure there is nothing more than what is strictly needed and if you can restrict access to the open ports to whitelisted IP addresses/ranges, then by all means go for it. Thus it becomes significantly harder to break into your system.

0

Once someone is on your machine, you can expect that they will find a way to execute commands. They already have bash and network access - that means they can simply download any executable they need and run it.

Anything past blocking all traffic from unneeded ports and setting up SSH so you can only connect via public key authentication and 2FA is completely pointless.

5
  • Regarding that last sentence: minimizing user privileges is also helpful. For example, if your dummy git user gets compromised, it might expose some source code to the attacker but they can't access the mail server running on the same system. It's not quite true that nothing beyond those three things you mention is ever useful, and it all depends on the context. Maybe change it to something like: "Security by obscurity is never going to stop an attacker already on your system if you already implemented other measures such as blocking unneeded ports, public key ssh authentication, and 2FA."?
    – Luc
    Sep 30 '21 at 14:48
  • @Luc It's essentially security theater. Security measures are effective as long as you can implement them more easily than it takes for an attacker to circumvent them. And on a machine that essentially fulfills one role, I don't see why there would be any source code stored on the machine.
    – MechMK1
    Sep 30 '21 at 14:49
  • It's an example. OP never described what their system is doing and this is not a full penetration test. We give general advice here, so I used a general example of why that last sentence is incomplete in its current form.
    – Luc
    Sep 30 '21 at 14:51
  • @Luc OP did that in the first sentence of their question
    – MechMK1
    Sep 30 '21 at 14:58
  • oh I'm blind, I only skimmed the question (got here via the edit queue). I'd still not limit an answer to 1 specific use-case from 1 specific user for posterity (e.g. you could prefix "if this one piece of software is all the server will ever do, then ..."), but you're right that I overlooked their specific example
    – Luc
    Sep 30 '21 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.