19.4 Managing Dormant Accounts

If a user is going to be gone for an extended period of time, you may wish to consider preventing direct logins to the user's account until her return. This assures that an intruder won't use the person's account in her absence. You may also wish to disable accounts that are seldom used, enabling them only as needed.

If you think that you do not need to be concerned with accounts belonging to people who are traveling or that are seldom used, think again: many security breaks have resulted from the penetration of such accounts. There are many reasons:

If the account's legitimate owner is traveling and not using his account, then no one is looking at the account to notice things like files that have suddenly appeared, suspicious email, or unaccounted logins and logouts.
Staff members who might normally be concerned that an account is being accessed from another country may dismiss their concerns if the account owner is, in fact, traveling abroad.

There are two simple ways to prevent logins to an account:

Change the account's password, or modify it so it can't be used.
Change the account's login shell.

Actually, you may want to consider doing both.

19.4.1 Disabling an Account by Changing the Account's Password

You can prevent logins to a user's account by changing his password to something he doesn't know. Remember: you must be the superuser to change another user's password.

For example, you can change mary's password simply by typing the following:

# passwd mary
New password: dis1296

Retype new password: dis1296

Because you are the superuser, you won't be prompted for the user's old password.

This approach causes the operating system to forget the user's old password and install the new one. Presumably, when the proper user of the account finds herself unable to log in, she will contact you and arrange to have the password changed to something else.

Alternatively, you can prevent logins to an account by inserting an asterisk in the password field of the user's account. For example, consider a sample /etc/passwd entry for mary:

mary:fdfdi3k1j1234:105:100:Mary Sue Lewis:/u/mary:/bin/csh

To prevent logins to Mary's account, change the password field to look like this:

mary:*fdfdi3k1j1234:105:100:Mary Sue Lewis:/u/mary:/bin/csh

Mary won't be able to use her account until you remove the asterisk. When you remove it, she will have her original password back.

If you use shadow passwords on your system, be sure that you are editing the password file that contains them, and not /etc/passwd. You can tell that you are using shadow passwords if the password field in /etc/passwd is blank or contains a symbol such as x or # for every password, instead of containing regular encrypted passwords.

Some Unix versions require that you use a special command to edit the password file. This command ensures that two people are not editing the file at the same time, and also rebuilds system databases if necessary. On Berkeley-derived systems, the command is called vipw .

Under some versions of Unix, you can accomplish the same thing as adding an asterisk by using the -l option to the passwd command:

# passwd -l mary

Changing an account's password does not completely disable the account:

The superuser can still access the account using the su command.
If remote access is allowed to the account using a trusted host mechanism (e.g., using rlogin or SSH's ~/.rhosts, ~/.shosts, or /etc/hosts.equiv mechanisms), the user will still be able to log in. (For more information, see Chapter 11.)
Any jobs that the user has scheduled using at or cron will continue to run.

Interactive access using the first two mechanisms can be disabled by changing the user's login shell to /bin/false. Automatic jobs need to be manually hunted down and terminated.

19.4.2 Changing the Account's Login Shell

Another way to prevent direct logins to an account is to change the account's login shell so that instead of letting the user type commands, the system simply prints an informative message and exits. This change effectively disables the account. For example, you might change the line in /etc/passwd for the mary account from this:

mary:fdfdi3k1j$:105:100:Mary Sue Lewis:/u/mary:/bin/csh

to this:

mary:fdfdi3k1j$:105:100:Mary Sue Lewis:/u/mary:/etc/disabled

You would then create a shell script called /etc/disabled:

#!/bin/sh
/bin/echo Your account has been disabled because you seem to have 
/bin/echo forgotten about it. If you want your account back, please 
/bin/echo call Jay at 301-555-1234.
/bin/sleep 10

When Mary tries to log in, this is what she will see:

bigblu login: mary
password: mary1234

Last login: Sun Jan 20 12:10:08 on ttyd3

                Whammix V17.1 ready to go!

Your account has been disabled because you seem to have
forgotten about it. If you want your account back, please
call Jay at 301-555-1234.

bigblu login:

Most versions of the ftpd FTP daemon will block access for users who have shells that are not listed in the file /etc/shells. Some versions, though, will not. You should check your FTP daemon for this behavior. If it does not block access, you may wish to change both the password and the shell to disable an account.

19.4.3 Finding Dormant Accounts

Accounts that haven't been used for an extended period of time are a potential security problem. They may belong to someone who has left or is on extended leave, and therefore the account is unwatched. If the account is broken into or the files are otherwise tampered with, the legitimate user might not notice for some time. If the user has left, he may end up at a competing firm and the old, dormant account may present a terrible temptation for mischief. Therefore, disabling dormant accounts is good policy.^[7]

^[7] Note that a dormant account that has been broken into and is being used by an attacker isn't dormant, and these techniques won't help you find it!

One way to disable accounts automatically when they become dormant (according to your definition of dormant) is to set a dormancy threshold on the account. Many versions of Unix allow this to be done with the -f option to the usermod command:

# usermod -f 10 spaf

In this example, user spaf will have his account locked if a login is not made at least once during any 10-day period. (Note that having an active session continue operation during this interval is not sufficient—the option requires a login.)

If your version of Unix does not have a usermod command, you will need to find another way to identify dormant accounts. The following simple shell script, called not-this-month, uses the last command to produce a list of the users who haven't logged in during the current month. Run it the last day of the month to produce a list of accounts that you may wish to disable.

#!/bin/sh
#
# not-this-month:
# Gives a list of users who have not logged in this month
#
PATH=/bin:/usr/bin;export PATH
umask 077
mkdir /tmp/NTM || exit 1
chmod 700 /tmp/NTM
THIS_MONTH=´date | awk '{print $2}'´
last | grep $THIS_MONTH | awk '{print $1}' | sort -u > /tmp/NTM/users1$$ 
cat /etc/passwd| awk -F: '{print $1}' | sort -u > /tmp/NTM/users2$$
comm -13 /tmp/NTM/users[12]$$
rm -r /tmp/NTM

The following explains the details of this shell script:

PATH=/bin:/usr/bin: Sets up a safe path. This also enables you to avoid specifying full pathnames to all of the commands that follow.
umask 077: Sets the umask value so that other users on your system will not be able to read the temporary files in /tmp.
mkdir /tmp/NTM || exit 1: Creates a temporary directory for the temp files. This prevents an attacker from hijacking the files used in the script. If the directory already exists, then the script exits with an error.
THIS_MONTH=´date | awk '{print $2}'´: Sets the shell variable THIS_MONTH to the name of the current month.
last: Generates a list of all of the logins on record.
| grep $THIS_MONTH: Filters the above list so that it includes only the logins that happened this month.
| awk '{print $1}': Selects out the login name from the above list.
| sort -u: Sorts the list of logins alphabetically, and removes multiple instances of account names.
cat /etc/passwd | awk -F: '{print $1}': Generates a list of the usernames of every user on the system.^[8]

^[8] Once again, you may need to replace the cat /etc/passwd command with your own system-specific command that prints out the contents of the password database.
comm -13: Prints items present in the second file, but not the first, i.e., the names of accounts that have not been used this month.

This shell script assumes that the database used by the last program has been kept for at least one month.

After you have determined which accounts have not been used recently, consider disabling them or contacting their owners. Of course, do not disable accounts such as root, bin, uucp, and news that are used for administrative purposes and system functions. Also remember that users who access their account only with the rsh (the remote shell command) or su commands won't show up with the last command. If these accesses are logged by syslog on your system, you can write another script to look for them (or their absence).

End Historical Accounts!

We have seen cases in which systems had account entries in the password file for users who had left the organization years before and had never logged in since. In at least one case, we saw logins for users that had not been active for more than three years, but the accounts had ever expanding mailboxes from system-wide mail and even some off-site mailing lists! The problem was that the policy for removing accounts was to leave them until someone told the system administrator to delete them—something often overlooked or forgotten.

The easiest way to eliminate these historically dormant accounts on your system is to create every user account with a fixed expiration time. Users of active accounts should be required to renew their accounts periodically. In this way, accounts that become dormant will automatically expire if not renewed, and they don't become a liability.

Under SVR4 or Linux, you can do this with the usermod command:

# usermod -e 12/31/05 spaf

Other systems may also have a method of doing this. If nothing else, you can add an entry to the crontab to mail you a reminder to disable an account when it expires. You must couple this with periodic scans to determine which accounts are inactive, and then remove them from the system (after archiving them to offline storage, of course).

By having users renew their accounts periodically, you can verify that they still need the resources and access you have allocated. You can also use the renewal process as a trigger for some user awareness training.

In most environments, the last program reports logins and logouts only on the computer running it. Therefore, this script will not report users who have used other computers that are on the network, but have not used the computer on which the script is being run.

Discovering dormant accounts in a networked environment that do not have a centralized authentication server can be a challenging problem. Instead of looking at login/logout log files, you may wish to examine other traces of user activity, such as the last time that email was sent or read, or the access times on the files in a user's home directory.