(Previously: Leveraging Halo to Audit System Accounts – Part 1)
In my last post we looked at the main Server Access screen on the Halo user interface. In this post we’ll look at what information is available if you drill down on an individual server.
To access the main Server access screen, log on to your Halo account and mouse over the “Servers” option in the main menu. When the drop down menu appears, select “Server Access”. Now, in the “Server” column click on any one of your listed servers. This will produce the Server Access scan report shown in Figure 1.
This report contains some extremely useful information. We get to see the logon name for each account, any associated comments, and the user ID (UID) and group ID (GID) assigned to each account. We also get to see the shell being used, as well as the date, time and source IP address associated with the last time this account was accessed.
The first thing we should check is for any unexpected accounts or accounts that should have been removed. Employee turnover is a fact of life, and it can be even more problematic with cloud servers if you are not restricting the source IP of remote access. Ensure all of the accounts on the server actually belong there. If you are unsure of an account, compare the results to your gold standard image.
Next, let’s start with the right hand column and work our way to the left. As mentioned above, the “Last Login” column identifies pertinent information regarding account access. Check the date/times to ensure they are in sync with regular business hours. Confirm the source IP address comes from an expected source. If you see the account was accessed from a Chinese telecom and you don’t have a field office in China, this should send up a warning signal.
Now, make note of the “Shell” column. This identifies the shell environment the account uses when connecting to the system. For example the “cbrenton” account is using the Bash shell. This is typical for most Linux systems, although occasionally you may see the Bourne shell (/bin/sh) being used. “nologin” is a special entry, that does not provide shell access to the system. If you attempt to logon to one of these accounts, you will receive the message “This account is currently not available”. This is a common trick for locking accounts so they cannot be accessed remotely. An alternative you may also see is setting the shell to /bin/false.
You may also run into binaries being directly executed by an account. For example examine the shells being displayed in Figure 2. In particular, note the “shutdown” account. If this account has been assigned a valid password, connecting to the system using this account will initiate the shutdown command. Be careful what binaries can be accessed in this fashion.
Also in Figure 2, examine the UID and GID columns (columns 3 and 4 respectively). In my last post I mentioned that any account that has a UID or GID of zero will have the same level of permissions as the root level user. Also in that post I showed a Fedora system that listed five root level accounts. Figure 2 above shows three of the five mentioned accounts that have root level permissions to the system, because they have the same GID as the root level user (a value of zero).
Want even more details on each account? Scroll to the top of the Server Access scan report and click the “Expanded Account Details” link. This will produce a report similar to Figure 3. Note that this report produces a wealth of information on each account.
For example, examine the information for the “cbrenton” account. If you look at the left hand column, there is a line item called “Groups”. This identifies group membership for this specific user. Note the “wheel” group is part of the list. The wheel group is a special group that controls which accounts can use the “su” command to assume root level privileges. So any member of this group has the potential to assume root’s permissions, provided they know root’s password for the system. Needless to say wheel group membership should be strictly monitored.
At the bottom of the left column, any sudo access for the account is identified. Sudo permits regular users to execute specific commands as the root level user, without assuming full root permissions or knowing the root users password. It is a better way to administrate a system than giving users full root access, as it keeps permissions to a minimum and creates a nice audit trail in /var/log/secure. Note the entry states that because cbrenton is a member of the wheel group, he has access to “ALL” root level commands and is not required to reenter his password when using sudo. This can be considered a point of insecurity, because if cbrenton walks away from his terminal and fails to lock it, anyone can sit down and run root level commands.
In the right hand column we get to see password policy information, including how frequently the password must be changed. We can also identify if this account will be automatically disabled if it every goes inactive. Note this setting must be configured at the time of account creation, or if you know what you are doing you can manually edit the /etc/shadow file.
At the bottom of the right hand column is a section titled “SSH Info”. This identifies if the account has used SSH, and what permissions are set on the user’s SSH directory. This directory should only be accessible by the account owner, so the cbrenton account appears to be properly configured in this aspect.
While auditing system account activity can be time consuming and cumbersome, Halo can help you streamline the process. Have any questions or additional tips to add? Feel free to leave a comment!