All my servers have the root account disabled (sp_pwdp set to *). This is to require sudo for all root access.[1] The purpose of this is to have all superuser activities audited, so people can see what has been done to the system.
For a more hardcore option, you can make sudo write to a log file (as opposed to syslog), and make the file append-only (using chattr on Linux, or chflags on BSD). This way, nobody can edit the audit afterwards.
[1] I also have a policy of not running a root shell, or doing shell escapes from a root process. (It's okay to use sudo sh -c '...' for doing pipelines or redirections, though.)
I emphatically recommend against disabling the root user. Disable or restrict root logins (via securetty and via sshd_config and via PAM and via what have you) If your system permits it, limit root's privileges or split up the root role (akin to how RSBAC does it.) But please, please, do not disable the root account by removing the password, otherwise it will become impossible to log into the system via sulogin. sulogin is used by all initscripts I know in case of serious errors reported by fsck - and that means you will be locked out of the system if the root file system gets corrupted.
To clarify: By "disabling the root account by removing the password" I mean the various mechanisms that end up with a ! or a * in the password field of /etc/shadow, or similar. I do not mean "change the root login mechanism so you don't get prompted for a password."
I have the root account enabled on all my servers. All the administrators have their own user and have to log in through that. From there they switch to root. (root ssh is disabled)
Keep the administrator count low. Only the people that really need root access on that server have the password.
I'm not a fan of sudo. It's way too easy to just do 'sudo bash' for a root shell. I'm aware this can be disabled but why bother? Just limit the users that can perform administrator tasks and talk to eachother. We do have a policy to not let root terminals open unattended. So it's log in, su, do the work, log out.
Note: I work at a fairly small company (50-something employees) and we get around with only 2 part-time admins (1 windows/1 linux). This way of doing things might not be the best when you have orders of magnitude more users.
I'd personally still wouldn't use sudo. There are other ways to log root activity.
I just disable SSH access for root and require users (often is just developers) to use ssh keys. There's just too many dictionary attacks and changing the SSH port is not an option for us.
That way you don't have to trust in anyone's ability to write a good password. Once inside just the admins have permissions for sudo.
Disabling root password is imho a false "good idea". The day you will need it, you will really need it. (according to your configuration you might need it to log in single user mode for exemple)
Disabling root remote login might be relevant but only if you are able to log on locally.
And yes, sudo should installed on every one of your servers.
It is usefull and easy to configure. Why would you like to not use it?
I know this thread is really old but there are some major flaws in the linked articles logic and I'm feeling "rant'ie"
- sudo allows both whitelisting and blacklisting. Not just black as they specify in the linked article
- This skips over the idea of AAA (Authentication, Authorisation & Auditing)
- su & sudo allow for both graded authentication and accountability.
Scenario 1
An administrator accidentally introduces some rogue code to a system, logged in as root the code has complete access and the administrator may never know whats happened. At least with graded logins (e.g. su/sudo) the administrator would be prompted to authenticate if the rogue code tries to use elevated rights... If it doesn't elevate then its confined to the users rights which should result in minimal damage.
Scenario 2
A rogue administrator wants to get info/make a change. They connect to the console (physical console access, HP iLo/similar, or vGuest console access), login as root and do whatever they wish.
Unless there is a named account/access card used to gain console access there is probably not much of an audit trail.
Make sure they really are who they say they are. Identity theft isn't the issue, identity verification is.
Check their authorisation, only give them what they need at that time. Graded authorisation allows them to elevate when they need it.
Audit it all, have a record so you know who, did what, when and where. Preferably why as well
You should require everyone to use sudo for every root command as a policy. There is never a reason to run "sudo bash" or the like, it is only for convenience, due to ignorance, or to cover one's tracks.
If you disable logins to the root account directly, you cripple your ability to fix the system when there are severe problems.
If you can't convince your admins to log in as themselves and run sudo for every command run as root, and to not break out of it into a shell, you have serious problems for which there is no technical solution.
The authors of Owl secure distribuion (and Solar designer) have an opposite carefully justified point of view; see, e.g., the answer https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 for a presentation of their claims. The problem of auditing the superuser actions (which person did what) is also addressed in their point of view (basically, the solution is to have several root users with different names).
All my servers have the root account disabled (
sp_pwdpset to*). This is to requiresudofor all root access.[1] The purpose of this is to have all superuser activities audited, so people can see what has been done to the system.For a more hardcore option, you can make
sudowrite to a log file (as opposed tosyslog), and make the file append-only (usingchattron Linux, orchflagson BSD). This way, nobody can edit the audit afterwards.[1] I also have a policy of not running a root shell, or doing shell escapes from a root process. (It's okay to use
sudo sh -c '...'for doing pipelines or redirections, though.)I emphatically recommend against disabling the root user. Disable or restrict root logins (via securetty and via sshd_config and via PAM and via what have you) If your system permits it, limit root's privileges or split up the root role (akin to how RSBAC does it.) But please, please, do not disable the root account by removing the password, otherwise it will become impossible to log into the system via
sulogin.suloginis used by all initscripts I know in case of serious errors reported by fsck - and that means you will be locked out of the system if the root file system gets corrupted.To clarify: By "disabling the root account by removing the password" I mean the various mechanisms that end up with a ! or a * in the password field of /etc/shadow, or similar. I do not mean "change the root login mechanism so you don't get prompted for a password."
I have the root account enabled on all my servers. All the administrators have their own user and have to log in through that. From there they switch to root. (root ssh is disabled)
Keep the administrator count low. Only the people that really need root access on that server have the password.
I'm not a fan of sudo. It's way too easy to just do 'sudo bash' for a root shell. I'm aware this can be disabled but why bother? Just limit the users that can perform administrator tasks and talk to eachother. We do have a policy to not let root terminals open unattended. So it's log in, su, do the work, log out.
Note: I work at a fairly small company (50-something employees) and we get around with only 2 part-time admins (1 windows/1 linux). This way of doing things might not be the best when you have orders of magnitude more users. I'd personally still wouldn't use sudo. There are other ways to log root activity.
I just disable SSH access for root and require users (often is just developers) to use ssh keys. There's just too many dictionary attacks and changing the SSH port is not an option for us.
That way you don't have to trust in anyone's ability to write a good password. Once inside just the admins have permissions for sudo.
Disabling root password is imho a false "good idea". The day you will need it, you will really need it. (according to your configuration you might need it to log in single user mode for exemple)
Disabling root remote login might be relevant but only if you are able to log on locally.
And yes, sudo should installed on every one of your servers. It is usefull and easy to configure. Why would you like to not use it?
I know this thread is really old but there are some major flaws in the linked articles logic and I'm feeling "rant'ie" - sudo allows both whitelisting and blacklisting. Not just black as they specify in the linked article - This skips over the idea of AAA (Authentication, Authorisation & Auditing) - su & sudo allow for both graded authentication and accountability.
Scenario 1 An administrator accidentally introduces some rogue code to a system, logged in as root the code has complete access and the administrator may never know whats happened. At least with graded logins (e.g. su/sudo) the administrator would be prompted to authenticate if the rogue code tries to use elevated rights... If it doesn't elevate then its confined to the users rights which should result in minimal damage.
Scenario 2 A rogue administrator wants to get info/make a change. They connect to the console (physical console access, HP iLo/similar, or vGuest console access), login as root and do whatever they wish. Unless there is a named account/access card used to gain console access there is probably not much of an audit trail.
You should require everyone to use sudo for every root command as a policy. There is never a reason to run "sudo bash" or the like, it is only for convenience, due to ignorance, or to cover one's tracks.
If you disable logins to the root account directly, you cripple your ability to fix the system when there are severe problems.
If you can't convince your admins to log in as themselves and run sudo for every command run as root, and to not break out of it into a shell, you have serious problems for which there is no technical solution.
The authors of Owl secure distribuion (and Solar designer) have an opposite carefully justified point of view; see, e.g., the answer https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 for a presentation of their claims. The problem of auditing the superuser actions (which person did what) is also addressed in their point of view (basically, the solution is to have several root users with different names).