Auditing Server Access
Take the following steps to set up server-access scanning, run scans, and interpret the results.
1 Set up auto-scanning (optional)
You can conduct access scans manually or automatically. If you want automatic scans, decide whether and how frequently you want to conduct them. Then go to [Site Administrator menu] > Site Administration in the Halo Portal and click the Scanner Settings tab.
Under Scanner Scheduling, in the line for "Server Access Management", select Enable Automatic Scanning, then choose a scan frequency from once per hour to once per week. Leave Execute scan on daemon start selected if you want to run an initial scan on each server as soon as it starts up.
The next scheduled scan will occur in as little as one hour or as much as 24 hours later, depending on the frequency you have specified. Note that all of your active servers, regardless of what server group they may be in, are scanned at each automatic scan.
2 Select servers and run a scan (optional)
For a manual scan, you can choose to scan all of your servers, or one server group, or a subset of the servers in a server group.
Click the Access icon ( ) on the Halo Dashboard and then select All Servers or a different server group. Use the checkboxes to select all servers in the group or individual servers. Then choose Launch Scan from the Actions menu to run the scan.
3 View access summaries for a group's servers
After at least one scan has occurred, return to the Dashboard, click the Server Access icon, and select a server group that was scanned.
For each server, note its operating-system indicator and its status: Active (the Halo agent has recently communicated with the Halo analytics engine), Deactivated (the server was shut down or the agent was stopped), or Missing (agent-engine communication has been interrupted). Then inspect the account information:
- Root Accts. The number of root-privileged accounts on the server (if the server has been scanned). If there is more than one, one is named "root" and the others have a UID or GID of zero. (Some distributions provide only one root-privileged account by default, others may provide several.) Make sure this number is not different from what you expect; extra root-level accounts could be a strong security concern.
- Total Accts. The total number of local accounts in the server. This number should not be larger than what you reasonably expect the number of accounts to be. Note also that, if the servers are all in the same server group and you instantiate them from a server template, this number should be the same for all of the servers.
- Last Root Login. The date and time of the last login, if any, by a root-privileged account (UID or GID = 0). You can see whether there has been any recent login activity on that server by one of its privileged accounts.
This value includes only remote logins; it does not account for console logins on the server itself, or for logins in which
sudocommands might have been used to perform root-level tasks. (Note that local logins are typically recorded in the server's log file
4 View access details for a server
To get more information about the accounts on a server, click the number of root accounts or total accounts for that server (in the Root/Total column in the list of servers on the Dashboard). The Server Access Scan Results page appears:
This page includes information about the most recent access scan, and displays a line of information about each server account.
Hint: Click a column head to sort the results by that column. For example, to see all accounts with root privileges at the top of the list, sort by "Root Privilege" or "GID".
For each account, note especially these values:
- Username. The account's login name. Check the list of accounts for any unexpected account names or accounts that should have been removed (for example, from ex-employees).
- Root Privilege. "Yes" if the account has root privileges. Make sure there are no accounts with root privileges that shouldn't have them.
- UID and GID. The user ID and group ID of the account. Note that an account with root privileges will have a UID or GID of zero. Make sure that only accounts that should have root privileges have a zero UID or GID.
Note: "Root privilege" by this definition does not include accounts with membership in the "wheel" group (giving them 'su' capabilities) or accounts with any level of 'sudo' capability.
- Shell. The path to the command shell that the account has used to access the server. If shell access to the server is not allowed, the shell is shown as something like
/bin/false. Thus you can easily tell whether a given account has remote access to this server.
- Last Login. The date and time of the last login to the server from this account, plus the IP address of the remote machine from which the user logged and the terminal that was used. This not only tells you whether this account has been active recently, but can also indicate whether the login occurred outside of normal business hours, and whether it came from an unexpected location.
Note: This value includes only remote logins; it does not account for console logins on the server itself, or for logins in which
sudocommands might have been used to perform root-level tasks. (Note that local logins are recorded in the server's log file
- Active. Whether the account is active or inactive (deactivated).
5 View details of one account
On the Server Access Details page, click the username of an account to get even more information about that account. The Account Details page appears:.
This page includes the same account information as the Server Account Details page, and adds more:
- Home. The account's home directory. (It may or may not have been created.)
- Groups. The groups that this account belongs to. If the "wheel" group is listed, this account can use the
sucommand to assume root level privileges.
- Sudo access. This section specifies the commands, if any, that this account is allowed to execute as the root-level user. In the above example, user "adm", as a member of the "adm" group, can gain full superuser privileges through 'sudo'.
- Password Details. When the password was last changed (a recent change may be of interest), how soon after the change it is possible to change it again, and the deadline for the next change. Also, whether this account is automatically disabled a certain number of days after its password expires.
- SSH Info. This indicates whether SSH keys are stored for this account, and what permissions are set on the account user’s SSH directory. In the above example, the value of
rwx------is appropriate, indicating that the account has full permissions on the directory, whereas the account's group and others have no permissions.
6 Compare all accounts on one server
To see detailed account information for all accounts on a server, click Expanded Account Details on the Server Access Details page, or click View all accounts on ServerName on the Account Details page. The All Accounts page appears:
Account details for all of the accounts on the server are displayed on this page. You can quickly scroll down and up to compare different accounts. For example, you can look for "wheel" membership, sudo access, or recent password changes without opening each account's details separately.
7 Compare one account across all servers
Besides looking at all accounts on one server, you can also analyze login activity by looking at one account across all of your servers. On the Account Details page for an account, click view 'AccountName' on all servers in 'GroupName' group. The following Account in Group page appears:
With this view, you can easily compare a user's recent activity across all servers being scanned. The account's information should mostly be identical across all servers in a given server group; any differences might be cause for investigation.
// <![CDATA[ var pdfTitle="Server Account Management"; var pdfURL="http://www.cloudpassage.com/document_images/sam/account-management.pdf"; specifyPDF(pdfTitle, pdfURL); // ]]>