Should we disable the root user?

Question

Should we remove the root password, disable remote login and basically require adminstrators to use sudo to perform administrative actions?

Solution 1

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.)

Solution 2

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."

Solution 3

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.

Solution 4

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.

Solution 5

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.

1. Make sure they really are who they say they are. Identity theft isn't the issue, identity verification is.
2. Check their authorisation, only give them what they need at that time. Graded authorisation allows them to elevate when they need it.
3. Audit it all, have a record so you know who, did what, when and where. Preferably why as well

View more solutions

Comments

[womble]

"No running of shells, either!" Uhm, do you know how many programs have a "drop to shell" command in them? Even before you start looking at shell job control...

[Chris Jester-Young]

I'm talking about "no shell" as a policy, not as a sudo option. (sudo does have a noexec option, but obviously that's not watertight unless you restrict the specific programs that a user is able to run.)

[Spoike]

If you want root shell from a console you could just do 'sudo -i' instead of opening it from sudo bash. Personally I really don't like the idea of logging in as root user directly since it is too risky for malicious goating (i.e. accidentally leaving the computer unlocked with the root shell open).

[Admin]

Is it possible to configure sudo so that "sudo -s" can't be used? I've only used sudoers to configure individual commands.

[Chris Jester-Young]

@Graham: You can. However, as you can see from the comments above, that doesn't stop anything, if your users can otherwise run anything. The only watertight solution is a whitelist approach, where you list specific program that users can run, and they must all be dynamically linked (so that the "noexec" option can do its thing).

[Hamish Downer]

As a policy where you trust the admins this is good. You can see what commands people run which can be really helpful when trying to work out what has changed.

[Mihai Limbăşan]

Chris, what do you do when there's a fsck error during bootup on one of the critical file systems?

[jldugger]

Is this a problem in systems like Ubuntu that never set a root password? I seem to be able to execute "sudo sulogin", but perhaps I don't comprehend a critical aspect.

[Mihai Limbăşan]

Unfortunately I'm not familiar with the way Ubuntu handles root. But if you're able to do "sudo sulogin" and get a root shell without being prompted for a root password, then no, it's not a problem, since conceivably the same mechanism will apply at boot. You could try looking grepping for sulogin through the initscripts to check when and how it's invoked.

[Chris Jester-Young]

@mish: If I can't trust my admins, then they have no place having admin rights! :-) Still, some transparency is good, like you say.

[Chris Jester-Young]

@Mihai: Some OSs where sudo-only is the norm (e.g., Ubuntu) do not request the root password for single-user mode. Really, if you have physical access to the machine (which is, short of serial console, what is required for using single-user mode), you can wreak a lot of havoc, whether you know the root password or not.

[Chris Jester-Young]

Ubuntu doesn't use sulogin. If you go into single-user mode you get a root shell straight away. However, read my comment (in my post) to see why this isn't a problem, in most cases.

[Mihai Limbăşan]

@Chris: Thanks, didn't know that. However, my concern wasn't whether or not physical machine access would allow one to wreak havoc (it obviously does :) - the idea was that disabling root login this way might further delay recovery in a catastrophic situation, i.e. cause additional costs. Noted, though, I'm much less concerned now. :)

[demonkoryu]

Actually, a better (more secure) option than an append only file is using syslog with remote logging. Get sudo to log via syslog and have that replicated to a separate secure log storage server.

[demonkoryu]

You lose logging/auditing with that, though. Make everyone use sudo, and prohibit people from doing sudo bash, or sudo -i, or sudo -s with corporate policy. That gives you an audit trail, and if you are pushing all your logs to a central loghost, it because easy to verify that people are following the policies.

[Chris Jester-Young]

@Christopher: Remote logging is not a bad idea in itself, but syslog is a bad idea: it's over unencrypted UDP. So unless the physical network between your server and the syslog server is secure, attackers can spoof log entries (local users can spoof local syslog entries, too). With enough of these, attacking the system becomes a simple of matter of "hiding in plain sight". Also, UDP has no guarantees of successful delivery.

[jldugger]

What if booting into single user mode is a grub option?

[Matt Simmons]

Changing SSH port is pointless anyway. A simple portscan gives it away easily. When I telnet to port 22 on my machine, I get SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2

[Benoit]

What is the aim of disabling the root account? What will you do if your brake your sudo binary or configuration (or whatever tool you use)?

[Brennan]

This "security solution" is ill-advised as it significantly impairs troubleshooting. In order to protect a log, it is better to use something like a WORM drive, or a remote syslog-ng. Another possibility is to use a remote syslog outputting to network on which exists a box with a sniffer listening, under control of the auditing group. That can be protected via secret key encryption on the network. Speaking as a matter of risk, it is more likely that you will require root access than it is that you will have a rogue administrator.

[imz -- Ivan Zakharyaschev]

That's the approach taken and advocated by the authors of the Owl secure distribuion (and Solar designer among them) -- unix.stackexchange.com/questions/8581/… tries to present their position with references.

[imz -- Ivan Zakharyaschev]

Besides, there are claims that having su or sudo in your system available to users means more security risks you can avoid if you have only dedicated root users. That's a position advocated by the authors of the Owl secure distribution (and Solar designer among them) -- unix.stackexchange.com/questions/8581/… tries to present their position with references.

[user7416]

I just had this very problem: I locked my root user and a fsck was forced because of a hard reset. Luckily I could boot my faulty Linux with the fastboot option, unlock the root account and restart to finally run fsck manually.

[Dan]

@MattSimmons Yes, but most dictionary attacks are automated and very elementary. They don't bother with port scanning; they attempt to connect to random IP addresses on port 22 and if they timeout they move on to the next IP in their list. It's not a security measure, it just helps get rid of the automated port 22 attacks. Obviously a targeted attack is a whole different ballgame.

[Dan]

Disabling root remote login might be relevant but only if you are able to log on locally. This is just blatantly false. You can log in remotely with any account; disabling root remote login does not limit you to local access.