Ron Arts wrote:
Okay, the general feeling seems to be that you should disable remote root login, for the following reasons: 1. Why take the chance that someone cracks the root account. 2. You want to keep logs on who is logging in to your box. Though from the answers I may induce that it may be secure if: - you choose a strong root password
Even if you choose a strong root password, I don't recommend allowing direct root access in *most* scenarios. The two step process of logging in as a non-root user, and then escalating privileges allows for greater security. For example, you can choose a very strong user password AND a very strong root password. In my opinion, this is more secure than allowing remote root logins with a single strong root password. Note that i say it "allows" for greater security, not that it is, because one can always misconfigure or use weak passwords.
Another thing to note is that as part of the password based authentication mechanism, you have to know two pieces of information: 1) the login name, and 2) the shared secret. In the case of the root account, #1 is already known. (there were those that practiced renaming the root account for this reason) Although it is possible to guess user account login names, it's not as obvious.
This becomes most apparent if you watch your authlogs while under a brute force SSH attack. What account name do you think brute force attacks love to try?
- there are no other users on the box - constrain logins to certain ip addresses.
security by IP restrictions is not like what it use to be 10+ years ago. there are so many easy to use tools out now, even novices can perform ARP+IP spoofing.
I think if you allow users on the box, you run a much larger risk anyway not? Hacking root from a local account is much easier than hacking root remotely.
I'm not sure I agree with that statement. The comparison is out of context. One assumes you already have local account access trying to escalate to root. The other is attacking the root account remotely. You don't consider the amount of work it might take to attack the user account remotely. To be fair, i think the comparison should be made with the same point of origin (remote attack). From a penetration tester's perspective, you'd first have to figure out a way to get a shell or execute something remotely, even as non-root. And THEN, you have to find a way to escalate to root. That's ultimately more work.
I did not see defenders of the default redhat/fedora setup.
I've never heard of any reasoning for that choice. Fedora really isn't meant for enterprise consumption. RHEL is, but is mostly used by corporations that can afford to have system administrators that know better than to leave the default settings. So, regardless of their default stance on the issue, i don't know that it really matters from a practical standpoint.
Another choice of RHEL that isn't the best security practice is the ability to boot single user and obtain a shell without a password.
But your answers still convinced me that though there are valid reasons to use local user accounts together with sudo, they do not necessarily apply to the setups I use. Thanks, Ron
I think it all really boils down to the concept of "defense in depth". Having more "layers" allows for better security. one can argue that you can have many weaker layers that in total can be weaker than a single strong layer. However, such argument becomes an apples to oranges comparison. In each scheme, for a fair comparison, you have to make the assumption that identical layers provide equal amounts of security. E.g., if you're going to use very strong passwords for the root account, then do so for all schemes you're comparing.
i know i'm late to the thread, so apologies if much of the above is redundant. Just my 0.02.
-Bond Masuda
