In the Linux operating system, the root account has unlimited power. If not used carefully, unexpected, evil things can happen to your system.
I could tell you horror stories involving mistyped commands while logged in as root. Now, imagine this power in the hands of attacker—executing any command they desire with methodical precision.
Only Use the Root Account When Absolutely Necessary
Too often system administrators immediately jump to the root level to perform routine tasks — this is when mistakes occur. The administrator is in a hurry and one wrong space, sitting in the wrong directory, or typed an incorrect parameter - all can result in evil things the moment the [ENTER] key is pressed.
I used to tell junior administrators:
“Stop and remove your hands from the keyboard. Now, slow down and think about what you are doing. When in doubt, do not hit that [ENTER] key. Your lightening speed on the keyboard does not impress me and as far as completing your assigned tasks, I want quality not quantity.”
This advice extends to experienced administrators, too. They’ve done these tasks so often, sometimes they can have a lackadaisical or even cavalier attitude.
Since senior administrators have more commands in their repertoire, this situation is more toxic than a junior administrator who may only know a fraction of commands.
Protect the Root Account from Compromise
Whenever possible, software developers should avoid writing applications with root level access. Typically system administrators are not developers and developers are not system administrators.
System administrators are often responsible for hosting many applications on the same server.
It is critical that you work together through out the product’s life cycle and ensure the development environment is as close to the production as possible. If you don’t, there could be deployment problems.
When the management team is standing over you about to go into panic mode, crunch time can result in relaxing access controls in order to get an application to run. Bad move!
Tell management to relax and fetch you a cup of coffee while you sort it out… they love that.
Always run applications, such as Apache web server, as non-root accounts. This way if the application is compromised, root level access is not immediately given to the attacker. Consider using technologies such as sudo, SELinux, and AppArmor.
Also, establish common groups through traditional discretionary access controls and POSIX.1e access control lists (ACL).
Know Who is Using the Root Account
First and foremost, you should never log directly into the root account. Log into your designated user account and use the switch user command to become root. If personnel login in directly as root, you have no audit trail to help identify who became root and performed administrative tasks.
Grant system administrator accounts membership in the wheel group and use pam_wheel(8) to allow only group members to switch to the root account.
The only time you should login directly as root is when you are physically on the console and entering single-user mode to perform critical maintenance.
To prevent this, modify the securetty(5) configuration file to include only authorized devices root can directly login.
Set PermitRootLogin to ‘no’ in the Secure Shell daemon configuration file. If you are running an FTP site, be sure to edit your ftpusers(5) file.
Many people are confused by the term console as it pertains to the securetty(5) file. On many virtual machines, console is not the physical device you directly login. Additionally, in some hardware configurations the console isn't always the console.
To identify your desired device name to store in the securetty(5) file, login in as root before editing the file and use the who(1) command to identify your current login device. Now, add that device to the securetty(5) file.
Lastly, edit the syslog.conf(5) or syslog-ng.conf(5) to log all authpriv messages to /var/log/secure and if possible, configure auditd(8). Don’t forget to routinely examine /var/log/secure to see who has gained access to root.
Summary
There are many other techniques and things to consider when protecting your root account. These are just a taste to get you thinking about how important this account is to the system.
It is imperative that you control administrative privileges such as root. For more ideas and information, see Critical Control 8: Controlled Use of Administrative Privileges of the Consensus Audit Guidelines. Security Blanket automates many of these tasks but there is no substitute for a well-trained, disciplined team of system administrators.
Cross-posted from Security Blanket Technical Blog
