Comments
One of the more time consuming activities a system administrator has to perform is auditing system account activity. While there are some excellent command line tools for auditing server access, they can be extremely cumbersome in an elastic IaaS environment where you may need to check hundreds of servers.
Luckily, Halo can make this task a whole lot easier.
Reviewing Server Access
To review server access information, logon to your Halo account and mouse over the “Servers” option in the main menu. When the drop down menu appears, select “Server Access”. This should produce a screen similar to Figure 1.
Note the above screen lists each of your servers, whether the server is currently online (active) or unreachable (missing), as well as summary information regarding accounts on each of the servers.
Before we dig into what the account information means, let’s first talk about the two servers with no information reported. The server “starling” has never had an account scan, so we are being prompted to perform our first check. If I wanted to rescan all of the systems at this time, I could simply click the radial box next to the “Actions” pull down menu, and then click the “Actions” pull down to select “Launch Scan”. If you’ve selected any inactive servers, you will be warned that these servers will not be included in the scan. Depending on how many servers you have in your list, the fresh results should be presented within a minute or two.
Note the last server on the list is also missing account information. This is because it is running an older version of the Halo daemon which does not support account scanning. If you see this entry, select “Servers” from the main menu, then “Install Daemons” from the drop down menu. Follow the directions provided to update your software.
OK, enough housekeeping, let’s move on to interpreting the scan results!
Understanding the Scan Results
The “Root Accts” column identifies the number of accounts on the system that have the same user ID (UID) or group ID (GID) as the root user. Typically, root will have a UID of zero and a GID of zero. If any accounts set their UID or GID to zero as well, they will have the same level of permissions as the root user. Needless to say you want to strictly monitor and control the number of accounts that operate with this highest level of access. The screen then goes on to identify how many accounts in total are on the system, as well as the last occurrence of root remotely logging into the system.
Note the “fedora-policy-test” server is listed as having five root accounts. If we assume one account is the actual root account, this means that four other accounts have a UID or GID set to zero. We will most likely find out that it is the GID that has been set to zero. This is a common trick to give alternate accounts a high level of permission.
TIP: Click the column titles to change your sort options. So to sort the servers based on the number of root accounts, click “Root Accts” once to sort lowest to highest, and again to sort highest to lowest
Red Hat based systems (like Fedora and CentOS) ship with five root level accounts, but Debian and Ubuntu based systems have only one. A slick trick is to group your servers based on OS and flag any servers that exceed these root account default settings. Excessive root level accounts may be an indication that someone has setup a high level account on the system, but they are attempting to hide their tracks.
The “Total Accts” column identifies how many accounts there are in total on each server. If you are cloning servers from a gold standard, the number of accounts should be the same on every system. Investigate any server that does not match this standard.
The final column, “Last Root Login”, identifies the last time root remotely connected to the server. It is important to note that this information is pulled from lastlog, so it only shows remote connections. Local root connections do not get reported. Some possible exceptions that will not show up in this output:
To audit local authentication, you will have to review the /var/log/secure file on the server. A slick trick is to send these entries to a remote Syslog server and parse out all use of root privileges for later review.
That’s it for this post. In my next installment I’ll talk about how to drill down on additional information on each of the servers.
– Chris
