22

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

alt text

Community
  • 1
jldugger
  • 14,122
  • 19
  • 73
  • 129

8 Answers8

17

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

C. K. Young
  • 1,842
  • 16
  • 16
  • 3
    "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... – womble May 02 '09 at 02:29
  • 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.) – C. K. Young May 02 '09 at 02:33
  • Is it possible to configure sudo so that "sudo -s" can't be used? I've only used sudoers to configure individual commands. –  May 02 '09 at 09:06
  • @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). – C. K. Young May 02 '09 at 14:03
  • 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. – Hamish Downer May 02 '09 at 16:57
  • Chris, what do you do when there's a fsck error during bootup on one of the critical file systems? – Mihai Limbăşan May 02 '09 at 21:43
  • @mish: If I can't trust my admins, then they have no place having admin rights! :-) Still, some transparency is good, like you say. – C. K. Young May 04 '09 at 03:42
  • @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. – C. K. Young May 04 '09 at 03:43
  • @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. :) – Mihai Limbăşan May 04 '09 at 08:06
  • 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. – Christopher Cashell May 16 '09 at 00:23
  • @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. – C. K. Young May 18 '09 at 15:56
  • 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. – Brennan Sep 14 '10 at 21:25
16

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

Mihai Limbăşan
  • 3,071
  • 22
  • 19
  • 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. – jldugger May 02 '09 at 22:48
  • 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. – Mihai Limbăşan May 02 '09 at 23:51
  • 1
    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. – C. K. Young May 04 '09 at 04:12
  • 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) -- http://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 tries to present their position with references. – imz -- Ivan Zakharyaschev May 21 '11 at 05:10
  • 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. – tommyd Dec 09 '13 at 21:38
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.

pablasso
  • 225
  • 3
  • 8
  • 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 – Matt Simmons May 29 '09 at 18:32
  • 1
    @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 Apr 23 '15 at 18:16
3

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.

Gert M
  • 1,471
  • 1
  • 15
  • 14
  • 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). – Spoike May 02 '09 at 08:44
  • 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. – Christopher Cashell May 16 '09 at 00:26
  • That's the approach taken and advocated by the authors of the Owl secure distribuion (and Solar designer among them) -- http://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 tries to present their position with references. – imz -- Ivan Zakharyaschev May 21 '11 at 05:06
2

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?

Benoit
  • 3,499
  • 1
  • 18
  • 17
  • What if booting into single user mode is a grub option? – jldugger May 29 '09 at 18:25
  • 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)? – Benoit May 29 '09 at 20:17
  • `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. – Dan Apr 23 '15 at 18:18
2

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
Mike
  • 29
  • 2
1

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.

carlito
  • 2,489
  • 18
  • 12
1

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

Community
  • 1
imz -- Ivan Zakharyaschev
  • 137
  • 1
  • 1
  • 14