42

This page on server hardening claims:

Disabling the root account is necessary for security reasons.

Why is disabling the root account necessary for security reasons?

10
  • 8
    I believe your answer is in the section just above your quote "Create “shadow user” with sudo powers"
    – schroeder
    Feb 15, 2016 at 21:07
  • 6
    BTW, I can't say that I think that is a great article. Feb 16, 2016 at 1:29
  • 2
    If you're running an Ubuntu server, try tail -f /var/log/auth.log and see how many attackers try to log in as root. Feb 16, 2016 at 12:09
  • 1
    An undisabled root account is only protected by its password strength. If that password is compromised, your system is compromised. Feb 16, 2016 at 14:40
  • 2
    A page on server hardening that goes on at great length about how important it is to secure /tmp, yet manages to confuse /tmp and /var/tmp (they are not the same!) and somehow not mention libpam-tmpdir? While it definitely has some good suggestions, clearly that page should not be taken as gospel.
    – user
    Feb 16, 2016 at 17:45

6 Answers 6

80

If you're not using Root, you're using sudo! Sudo is a great way to become root only when you need to.

  1. Root is a giant target. What's root's username? Root! I'm so smart :)
  2. Logging. Sudo has a greater command of audit logging (so that when someone uses sudo to do something silly, you can tattle on them to the central logging server). This is helpful for forensic analysis in some cases.
  3. Granular permissions. Root is a Big Flippin' Hammer. Do not hand BFHs to your users. Sudo allows you to specify that a user can run update commands like aptitude without password, but everything is off limits! You can't do that with the BFH that is root. IT allows you the flexibility of sanctioning certain commands for users, but disallowing others. This allows you to build a security policy that does not require an administrator to physically log in to a machine every time a machine needs to be updated (or another menial task).
  4. Idiot-proofing. Why do you not hand users a BFH? Because they're dumb. Why do I use sudo instead of root? I'm dumb. Dumb means mistakes, and mistakes mean security holes and sysadmin-issues.
21
  • 19
    Then the user types: sudo bash
    – Tom Leek
    Feb 15, 2016 at 21:19
  • 43
    And if you have a proper audit policy, the user will see: Permission denied. This incident will be reported.
    – Ohnana
    Feb 15, 2016 at 21:20
  • 10
    Then the user types SHELL=/my/program apt-get install <I forget> and gets a shell because some package has mistaken $SHELL for sh. Feb 15, 2016 at 21:26
  • 8
    While you make a good argument for using sudo over the root account, I'm not sure that you actually make an argument for disabling the root password. Feb 16, 2016 at 1:19
  • 7
    @PyRulez Allowing only updates wouldn't help. However, the default sudo configuration on many distributions where it scrubs most environment variables including SHELL does solve this particular avenue of escalation. There are probably others involving packages with interactive configuration, though allowing only upgrades reduces the risk a lot there. Feb 16, 2016 at 10:25
38

The site you link to is very poor at explaining what they are getting you to do. The root account is not being disabled, but rather, the password for root is disabled. That's what passwd -l does.

The intent of those instructions is to make it so that people cannot log in as the root user, because the root account is easy to guess. I'm not sure that their approach of creating a pseudo-user with a "hard to guess name" will be that much more secure ...

1
  • 1
    root is indeed the main target of ssh bots. Should you forget to disable it in sshd_config, the OS would back you up.
    – edmz
    Feb 16, 2016 at 15:40
17

It is an old Tradition from the days of the Mainframe. The idea is that root can do what he wants with the machine, including replacing the kernel or destroying the UEFI variables, which can brick the machine. Whereas a non-root account cannot -- unless that account is given administrative rights through sudo, which is what you will have with Ubuntu, and it totally destroys the rationale above.

Really, disabling the root account is now used exclusively to appease elder gods, who:

  1. are grumpy;
  2. are obsolete;
  3. have been dead for decades, but are still worshipped by a powerful caste of high priests, collectively known as "conformance auditors".

In practice, your digital life is completely accessible from your normal user account, so making any protection relative to the root user does not make a lot of sense. Mucking with the root/non-root distinction is a thing of the past, when machines were big servers shared between hundreds of users who were possibly hostile to each other.

4
  • 19
    "your digital life is completely accessible from your normal user account" - OP is asking in the context of server hardening. This presumes a desktop system.
    – Kevin
    Feb 16, 2016 at 0:53
  • 4
    Also, sudo logs stuff, I believe. Feb 16, 2016 at 2:20
  • 7
    There is an accountability aspect when on multi-user machines. Root is a generic account, so anything done by root can't be tied to a user (unless the login was elevated from a specific user account). Feb 16, 2016 at 5:56
  • 2
    Is this answer tongue-in-cheek? Or do you also still use password authentication instead of keypairs?
    – aross
    Feb 16, 2016 at 14:07
6

Please be aware that (at least on Ubuntu and its derivatives), there is a tradeoff involved with disabling the root password.

Should there be a disaster on your system, you will want to boot the system into recovery (or single-user) mode from the console. If the root password is disabled (as it is by default), then no authentication whatsoever can be required when booting into single-user mode, because the root account has no credential to be used for this purpose, and no other account can be guaranteed to work under those circumstances. This is handled by special-case code in the sulogin program.

On balance, though, this is an easy trade to make: you are preventing a whole class of remote attacks while opening up the system to unauthenticated root login from the physical console. Remember that you cannot ever secure a system from an attacker with physical access to it anyway. This is why secure data centers with electronic access controls exist.

2

Root is generally disabled to provide an extra layer of security throughout the Linux operating system. The root user has the ability to change literally anything no matter the importance. This makes it a common target of hackers, viruses, etc. Disabling it (or rather disabling the password) ensures that the account cannot be logged into if the password is retrieved (not actually that hard to do).

3
  • 2
    Actually, it can be quite difficult to "retrieve" a complex root password on modern Linux systems, notwithstanding basic user mistake.
    – Stephane
    Feb 16, 2016 at 12:02
  • There's always the brute-force methods, or if they use a password with any sort of word in it, a rainbow table could be used. Either way, it's possible to do so, and if you're running a server that could be a popular target (say a server for Google, Facebook, or something) it would be best to ensure that it wont happen anyways Feb 18, 2016 at 2:13
  • It depends on the config, but good luck on brute-forcing a complex root password that has been stored with bcrypt. And since passwords are salted (in pretty much all possible configuration, including most default), rainbow tables are useless.
    – Stephane
    Feb 18, 2016 at 6:53
0

By default, the root account password is locked in Ubuntu.

Because If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so. The user account is the weak link in this chain, and so must be protected with the same care as root.

The root account password does not need to be shared with everybody who needs to perform some type of administrative tasks on the system .

To disable your root account use the following command:

sudo passwd -dl root

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .