User Level System Hardening

There are two schools of System Hardening at the User level. The first school is to restrict access to an administrative user (not root) through sudo (this document details that school of thought). The second school is restricting all execution, as your administrative user. This is a finer grain, user level control and is indeed the best option. However, this is extensive to setup, configure and maintain. An example of this is that no user logged in is allowed access tot he administrative user (as option 1) rather you execute all commands through sudo: sudo su -u myadmin -c myCommand. All of your comamnds must be listed or they will not be available.

In order to control who can and cannot access your systems, at the user level, user access must be controlled. Let us review a few reasons we want to harden a platform at the user level. In this example, we have a user 'theAdmin' who is shared across a couple of departments. The role of this user is to manage a select list of software and applications. In order to allow these multiple departments access, each selected user will have to be provided 'theAdmin's password. Now we have developers, architects and operations all sharing the same username and password.

We know from experience and years of being in IT that within a month, almost everyone in both departments, plus some others, will have access to 'theAdmin'. What could possibly go wrong here? Changes are made and cannot be tracked. Since anyone can log into the box as 'theAdmin' we do not know who is actually on the system. Scenario two, someone fat fingers the password too many times and now all of our groups are locked out of the system - administration and deployment have stopped until the 'theAdmin' can be unlocked.

Finally, what if someone changes the password? Once again, we are locked out of the user and work has come to a grinding halt. Even worse, an hour is spent changing the password back, and a malicious user (knowing their actions cannot be traced) again resets the password. To prevent this - the admins reset the password to something new and the cycle starts all over again. Password is distributed, it leaks out, the password is changed or the user is locked out.

So how do we prevent this from happening while still allowing a select group of individuals access to 'theAdmin'? Luckily, this is an old question and one that has been solved many times over. The following steps are a simplified solution for System Hardening at the user level.

As a 'validated' admin (meaning you have root access) log into the box, assume root and make the following changes:

Step 1: Restrict 'theAdmin' from logging in anywhere except locally on the box (we are making a leap of faith that the box itself has been hardened and FTP as well as SCP have been disabled - I come from a PCI background and natively make these assumptions).
To disable the user, as root, edit '/etc/ssh/sshd_config' and check for the following entry 'DenyUsers'. If it does not exist, add it to the last line of the config file and include the user (theAdmin) with a space: DenyUsers theAdmin
Save and close. Now 'theAdmin' is blocked from logging in over SSH.

Step 2: We need to restrict who logs into the box. If your box supports AD, enable it by group. If not, manually add your users with the 'useradd' command.

Step 3: Allow access to 'theAdmin' through the sudo command. This can be tricky so you want to make sure you add the full rights and not just blindly allow sudo to any user.
enter SUDO editor mode by executing 'visudo'. Jump to the bottom of the file, and add the following two lines:
User_Alias THEADMINS = johnd,janed,jackb,tux
THEADMINS ALL = /bin/su - theAdmin
save the file. You should not see any errors; one good feature with visudo is it validates the syntax before it saves and change 'theAdmin' password to something obtuse and tell it to no-one.

You're all done, your system has been hardened from a user level.
So what exactly did we just do? we have restricted access to 'theAdmin' to 1) local login only 2)only a select few users and 3) the password is never needed since you obtain the user roles through sudo.
So how do you become 'theAdmin'? Log in as a 'registered' user and execute 'sudo su - theAdmin' - enter your login password and hit enter. You are now 'theAdmin'. Any user can change the password, it will have no effect, 'theAdmin' is not assumed through local credentials any longer.

Additionally, by going down this path, you now have the ability to log who assumes 'theAdmin'.

Recap

• Disable SSH; add 'DenyUsers ' to '/etc/ssh/sshd_config'
• change 's password
• Add login by user only (either through AD or add a new system account)
• Create the following entries with visudo
• User_Alias THEADMINS = ,,,
• THEADMINS ALL = /bin/su -
• recommended
• Defaults logfile=/var/log/sudo/sudo.log
• Defaults mailto=""
• As root
• mkdir /var/log/sudo