Should I still disable root if I disable password authentication and enable only key authentication?

Question

I'm new to the linux world and I've been reading a few tutorials on security. I've seen some questions on StackExchange tackling this subject, but from what I've seen, none of the answers clarified things for me.

I keep seeing them (the tutorials) recommending to disable root due to various reasons, the most important being the fact that servers with root users are mostly likely to fall, should a brute force attack occur (from my undersanting, a brute force attack means an automated process which repeatedly tries to authenticate with a username / password combo, until it succeeds)

Now, assuming that I disable username/password authentication and only SSH RSA key authentication is enabled (and also assuming that I'm pretty confident with the security of the device where the private key is located, and that I also have a passphrase for that key) what would be the risk of having root enabled?

Assuming that attackers will never get hold of my private key (and the passphrase), what are their option(s) of getting access of the server?

Answer 1

Yah. It's off by default on FreeBSD.

Part of the reason being is that knowing a username is half the battle for anyone attempting a brute force break-in. 'root' is a user which all unix'like OS contain. Presumably your own username is a bit harder to guess. You can always sudo up as you need it after you're in. Also, sudo logs will show which user is doing bad things when you ~do~ have a break-in.

Wade thru your sshd and/or security logs (depending on how you have your logging set-up). You will be appalled at the sheer number of random attempts to log in.

If this is a server, you probably also want to firewall the machine such that ssh can only connect from certain well known networks.

Also consider some of the nifty pam plug-ins which can add an IP address to your firewall after n failed logins within time span t.

If you really, really have to allow root, you can also specify in /root/.ssh/authorized_keys a list of ip addresses/hostnames from which that key is acceptable.

e.g. (uglified for public viewing):

from="*.foo.bar.isp.net,*NewEngland.bellatlantic.net,333.132.227.*,*.mydomain.net,*.customer.com,177.12.47.2??" ssh-dss AAAA ..[public key].. cas6A== ericx@workstation.com

Answer 2

The risk of hardening methods should always be weighed against what assets you are trying to protect and what the intrinsic value of those assets are.

The reason I say this is because consideration needs to be given to the fact that even with the root account disabled, elevated access can be obtained through other ways. It gets to be a gopher hole, and if you only go 'half-way down', you really haven't gained the security you think you have.

• some processes run as root. exploiting that process may elevate privilege. So, let's go through all running processes and make sure they run with less privilege. This isn't always easy, depending on the required software.

• even with the root account disabled, booting from another OS or boot media may render filesystems vulnerable. So, let's use encrypted FS on everything so in case that happens, we can ensure the integrity of our data.

• what about backups? If run while the machine is hot, will sensitive data be archived in the clear on some medium which is not encrypted?

• user accounts; bob needs sudo to install software. What happens if bob's login credentials are compromised? This may even be easier than compromising the root account but the end result is the same.

You mentioned you are a beginner so possibly we should consider this from the perspective of a home system. Servers are typically hardened differently than a home system and applying the same paradigm across both is just silly. Nonetheless, there are some basic principles which do apply to both.

• consider the value of the assets you are protecting and the cost of securing them
• remove un-needed software and services
• stay current with patches
• consider the usability being sacrificed. Does it warrant the added security?

If you've already disabled password based login over ssh and only allow key-based auth, that's easily the best bang for your buck. It's impossible to brute-force an ssh login when password auth is disabled and it took maybe 10 minutes of your time to implement.

If you want to take it a step further, you can additionally define restrictions on where root (or any other user/group for that matter) is/is not allowed to login. see man 5 access.conf

In the end, it's a security consideration and one which should be weighed with sacrificed usability in mind. There aren't too many security measures which do not result in reduced usability, although sometimes the are quite minuscule.