Auditing user accounts is just as important as auditing other parts of your system. In fact, in large multi-user environments, it can be one of the most critical aspects of monitoring your system to prevent attack. For instance, if a user were to leave the company and the account was never removed, who would notice that the account was compromised if it did in fact become compromised? Certainly not the user in question; they are no longer with the company nor are they using the account. In a worst case scenario, the employee themself could be accessing their old account, obtaining informaiton they should no longer have access to. Perhaps providing that information to their new employer, or a competitor.
The most important thing to do is to keep an eye on accounts on your system and remove those that are no longer being used. Not only will this prevent former employees from accessing systems and data they no longer have a right to access, but it reduces the number of accounts an outside attacker can attempt to gain access through. Remaining vigilant in regards to system accounts that need to be there, and those that need to be removed, is a positive step in securing access to your network and computers.
There are a number of steps that can be taken to audit user accounts on your system; here he will take a look at them.
Finding Accounts Without a Password
An account without a password is an extremely bad account. A password is the basic form of protecting an account from abuse, and without one, an account can (and will) be compromised quickly. The only exception to the rule here is system accounts that cannot be logged into. The following command will detect accounts without passwords using /etc/shadow, or the shadow password file:
# awk -F: '$2 == "" { print $1 }' /etc/shadow
Because the shadow file is only readable by root, root must execute the command. Because the second field of each entry in the shadow file is a password, we can quickly detect those accounts without a password using awk (the -F: command tells awk to use the ” : ” character as the delimiter). In the second field of this file, if you look at it, you may also encounter two other special characters: The ” * ” character indicates that the account cannot be logged into, and the ” !! ” characters also indicate that the account has a null password; this is ok because these types of accounts cannot login. In both cases, you can use su to become one of these accounts (provided they have a valid shell in /etc/passwd).
On SVR4 UNIX systems, you can also determine what accounts have no password by using the logins command like this:
# logins -p
To accomplish something similar on OS X, you have to use the nidump utility to extract the information from NetInfo first. This can be accomplished using:
$ nidump passwd . | awk -F: '$2 == "" { print $1 }'
This command pulls the passwd information out of NetInfo and performs the same awk command since the format nidump uses is identical to that used by passwd and shadow. You can pull this information from other NetInfo domains as well; in the above example we are pulling the data from the local domain (indicated by the ” . ” (dot) character). Unfortunately, this data is not protected from casual snooping; any user can obtain the encrypted passwords of other users by using nidump as it does not require root privilege to view (unlike systems using shadow accounts).
Finding Accounts with UID 0 (aka SuperUser)
One means of obtaining (and keeping) elevated access by a cracker is to give themselves UID 0. This is the magic number for superuser powers on a system and does not need to necessarily be restricted to root. For instance, an attacker could obtain root access to a machine, change another account or add their own, and give it UID 0. This does not interfere with the real root account; you will simply have two accounts with equivalent superuser access. Detecting anomolies here can help you track down accounts with UID 0 and unless you made the change, any account other than root with UID 0 is suspect. Again, using awk you can determine if any accounts other than root have UID 0:
# awk -F: '$3 == 0 { print $1 }' /etc/passwd
Viewing Login History
Reviewing when accounts logged in is also an important step in observing any suspicious behaviour on your systems. This information is recorded to a binary database logfile called /var/log/wtmp. This file cannot be viewed using a normal text editor as it’s not a plaintext file; it also should not be rotated as other log files because it retains roughly the same size at all times. wtmp takes care of itself and as new data is written to the file, old data is removed.
To view a history of user logins, use the last command, optionally specifying a username to look at specifically (the default is to show information on all accounts):
# last joe
This will show when joe logged in; it will indicate what console or terminal they logged in at, the XFree86 display name if applicable, and the date/time of the login. By looking at this information, you can see if any anomolies appear; ie. accounts being logged in when an individual would normally be sleeping, or access outside of work hours, etc.
To view the last login, some systems provide the lastlog tool (most Linux systems do, OS X does not). lastlog displays pretty much the same information as last, but restricts the output to the absolute latest login. For instance:
# lastlog -u joe
This command will display the last login for the user joe. By default, lastlog displays the last login for all users on the system. Another useful command is lastb which displays the last bad login attempt for users. However, most systems do not enable this by default. The log file used here is /var/log/btmp which probably does not exist on the system. To create the file, execute as root:
# touch /var/log/btmp # chmod 640 /var/log/btmp
This will create the file and make it read/write only by the user root. Double-check the ownership and permissions of /var/log/wtmp and make sure that /var/log/btmp has the same. In most cases, the file should be owned by user and group root. Once this file is created, the system will start to record bad login attempts to the file, and they can be viewed with the lastb command. To view the list of bad login attempts, use:
# lastb joe
By default, lastb shows all of the bad login attempts; if you want to view the bad login attempts for a particular account, give lastb the username to check, as shown above.