Controlling Accounts and Passwords

If a server exists, it's a potential door into your computer. There are several different ways to lock this door. One is to use firewall tools like iptables (discussed in Chapter 25). Another, which works only with some servers, is to pay careful attention to user accounts and passwords on the computer. Servers that use these features can become vulnerable if the computer hosts unused accounts or if passwords fall into the wrong hands. This method of control requires a partnership between you as a system administrator and all of your users, so it's important that you communicate the risks of poor password choice, password use over unencrypted connections, and so on to your users.

Account Creation Procedures and Policies

The first step in protecting your system through account security is to develop and follow appropriate procedures and policies for the creation of accounts. To use the analogy of servers as doors, every account is a key that can open a door (often several doors). By minimizing the number of accounts on the computer, you reduce the risk that a key to enter your system will be abused. Of course, many servers need user accounts. Without user accounts, a file-sharing server is of limited utility, an FTP server can be used only for anonymous access, and so on. The trick is to determine when you really need to create a particular user account.

On some servers, the answer is simple: You don't create user accounts ”at least, not for anybody but a handful of administrators (perhaps just one). Earlier chapters in this book have described the circumstances in which a server requires user accounts. Many servers, such as font, DHCP, and time servers, don't need user accounts, and so such computers can easily do without user accounts. Other server systems, such as Web and FTP servers, may or may not need user accounts, depending upon precisely how they're to be used. Remote login servers are usually run on computers that host many user accounts, so these systems always require user accounts.

Assuming a computer needs ordinary user accounts, you should have a clearly defined policy regarding use of that computer that you can use to guide when to create an account. For instance, a computer in a university's physics department might exist for use by faculty, staff, and students associated with that department, so you should have a policy to create accounts only for those individuals. Formalizing these policies can help avoid an expansion that might be undesirable from a security point of view. You can change these policies if they become too constricting, but it's easy for a system to acquire unused or unnecessary accounts if your account-creation policies are too lax or informal. This formalization is particularly important if the computer has many users.

You may also want to develop scripts or a checklist to follow when creating user accounts. One particularly important detail in this process is how you set the password. The upcoming section, "Setting Good Passwords," addresses this issue. You should also create an appropriate default permissions system for your computer. For instance, you might want to create separate project groups and assign users to specific groups, and assign permissions on home directories to restrict who may access whose files. Appropriate policies vary greatly from one environment to another, so you'll have to develop your settings with your particular needs in mind. In an open environment, loose home directory permissions such as 0755 or even 0775 may be in order, with a matching umask value for file creation; but in an environment in which intra-system security is more important, you may need to set tight 0700 home directory permissions with restrictive umasks.

Monitoring Account Usage

Once you've created accounts for your users, you may want to monitor those accounts to see that they aren't abused. There are two key aspects to this monitoring: Checking for inactive accounts and checking for abuses of active accounts.

Handling Inactive Accounts

User accounts are seldom permanent. Students graduate and employees move on to other jobs, for instance. Whenever an account falls into disuse, it should be disabled or removed to minimize the risk of its being abused. If you receive a notice that the user has left your organization or should no longer have an account for some other reason, you can manually disable or delete the account. You might not always receive such a notification, though. One way to help automate the process is to create accounts that automatically expire, or that have passwords that expire. You can use the usermod command to set an expiration date on an account, thus:

  #   usermod -e 2003-07-04 george  

This command tells the system that the george account will become inactive on July 4, 2003. (You can use the -e parameter to useradd to create an account with an expiration date initially, as well.) This approach is most useful when you know that a given user will no longer need an account after a certain date, such as with student accounts and those for temporary employees.

A less drastic approach is to set up an expiring password. These require the user to change the password on a regular basis, such as once a month. You can do this with the chage command, thus:

  #   chage -M 30 -W 5 george  

This command tells the system that george must change his password every 30 days, and to warn george of an impending deadline 5 days before the fact. If george doesn't change his password, the account will be disabled and require administrative intervention to be used again.

These automated processes can help reduce problems, but they aren't appropriate for all situations. For instance, if the account exists for some nonlogin process, such as file sharing via a Samba server or mail delivery only, users may not see password expiration messages, at least not unless you create custom cron jobs to check for impending account expirations and notify users, say by sending them e-mail about the upcoming password expirations. There are some active steps you can take to monitor account usage. For instance, the last command returns information on the last few logins, and many distributions maintain a log file called /var/log/auth in which information on authentication is stored. If you want to be very diligent, you might even set up a cron job to monitor system log files, note when users log in, and notify you if an account goes unused for more than some given period of time. You can use these tools to monitor account usage, and if an account falls into disuse, investigate further to determine if it should be deleted.

You might need to take active administrative steps to alter account availability. For instance, once an account has automatically expired, you might want to delete it if you know it won't be used again. You might want to write a script that checks for expired accounts and reports back to you if it finds any. (These accounts can be identified because the third colon -delimited field in /etc/shadow contains a smaller value than the eighth field.)

Checking for Account Abuse

A nightmare for any system administrator is a local account that's being abused. Perhaps one of your users is untrustworthy, and is using the computer to attack other systems, or even the local system itself. Another possibility is that an outsider might have hijacked a user's account in order to abuse it.

One way to check for abuse is to look for suspicious activity in your system log files, such as /var/log/messages and /var/log/secure . (Precisely what log files exist, and what information they contain, varies from one distribution to another.) System log files mostly monitor the activity of servers, though, not of clients . Therefore, you might not see any evidence of a local user abusing , say, a Telnet client to attack another system. Such evidence might turn up in a firewall's log files, though, depending on your network's configuration. You might also see suspicious activity if your system comes under attack from outside.

Unfortunately, checking for such abuses by scanning log files is tedious at best. Automated tools like the Simple Watcher (SWATCH, http://oit.ucsb.edu/~eta/swatch/) can help by scanning log files for key strings that might indicate trouble, but such tools aren't foolproof.

One potentially important step you can take in tracking, if not preventing, abuse of your system is to run the auth server (also known as identd ). When a client on your system contacts an external server, that server might try contacting yours to find the identity of the user who makes the outgoing connection. If your user causes trouble on the remote system, that system's administrator can contact you and tell you who was causing problems, because the username will be recorded in the remote system's logs. This process only works, of course, if identd is installed and running on your system, and if it's not been compromised itself. (Most distributions ship with this server, which is very basic and so requires only minimal configuration. It's normally run from a super server.)

Ultimately, your ability to track and prevent abuse of your local systems is limited. You can be alert to suspicious local activity, such as processes that should not be running, but closely monitoring all the activity on even a single computer is far more work than a single system administrator can undertake.

Setting Good Passwords

In order to use passwords, computers must store them on disk. Typically, computers encrypt passwords, generally using a hash, or one-way encryption algorithm. In Linux, password files are usually stored in /etc/shadow (old Linux systems often used /etc/passwd ). This practice makes a password file useless even if a cracker obtains it ”or so it would be in a perfect world. Increasing CPU power and disk space have made it possible for crackers to encrypt entire dictionaries that span multiple languages and include many proper names and variant spellings, letter order reversals, and so on. If a cracker obtains an encrypted password file, the cracker can compare the file's entries to the encrypted results from the dictionary file. If a match results, the cracker has learned the password.

For this reason, the best passwords are random collections of letters , numbers , and any other characters the computer allows for a password. Such random strings are unlikely to appear in a cracker's password-cracking dictionary. Unfortunately, random passwords are hard to remember, so most people pick easy-to-remember ”and therefore easy-to-break ”passwords. A reasonable compromise is to build something that won't appear in a dictionary but that has personally memorable characteristics. This process is two-step: First, build a base, and then modify that base.

To build a base, take a pair of unrelated words and merge them together, such as bunpen; or use an acronym that has meaning only to you, such as yiwttd (for yesterday I went to the dentist ). This base is easy for you to remember and should not appear in a dictionary. It's best if the base is as long as possible. (I used six-character bases as examples because eight is the limit on some systems, and subsequent modifications will increase the length.) Nonetheless, a cracker might stumble upon your base by combining words from a dictionary. Therefore, further modifications are necessary.

Possible modifications include:

• Mix case ” If your system's passwords are case-sensitive, mix up the case randomly , as in BUnPeN or YiWTtd. Many systems use case-insensitive passwords, though, so this step may not help security in all situations. For instance, Windows uses case-insensitive passwords for its SMB/CIFS file sharing.

• Add digits or punctuation ” Add two or three randomly selected digits or punctuation, creating something like BU3nP&eN or Y+iWTtd2.

• Reverse a word ” If you used two words as your base, reverse the letter order of one of them. This might produce BU3nNe&P, for instance.

Further modifications are, of course, possible. The key is that, despite the random appearance of these end results, the person who produced them can regenerate the password with relative ease. Such passwords therefore need not be written down or stored unencrypted on a computer. These two practices both greatly degrade security, because the paper or computer file might fall into the wrong hands.

If you want to check that your users' passwords are good, you can use a password cracking program on them, such as Crack (http://www.users.dircon.co.uk/~crypto/). If the program delivers a password to you, you can help the user create a better password.

WARNING

If you run a password-cracking program, do it on a computer that's not connected to any network to eliminate the risk that a cracker will stumble across your efforts. Also, as with port scanning, password cracking is grounds for dismissal from many employers , so if you want to do this to improve local security, be sure to obtain permission first!

In addition to creating good passwords, users should take pains to keep passwords secure. This means that users should never write down passwords or give them to other people (even friends , family members , or co-workers ). You should explicitly tell your users that you will never need to know their passwords; there have been scams in the past where crackers have claimed to be system administrators and asked for passwords, and users have fallen for the ruse.

Even if users create good passwords and don't give them away, they can be discovered through various means. One is shoulder surfing, in which a cracker observes a user in a public area typing in the password. This is a real risk in public computer centers such as those common on university campuses, and to a lesser extent in the cubicle farms common in many companies. Another risk, which has been described elsewhere in this book, is password sniffing, in which a computer on a network is programmed to recover passwords sent between other computers on the network. This is a risk both on local networks and on the Internet at large. You can minimize the risk on local Ethernet networks by using switches rather than hubs; switches don't echo data to all connected devices, so the sniffer would have to be on the client or server computer itself to acquire a password. A still better approach is to use protocols that encrypt the password, rendering an intercepted password useless.