News | Unix security | Self-Defense | Anti Hackers | Cryptography | Articles

Unix security

UNIX system security can be divided into three main areas of concern. Two of these areas, account security and network security, are primarily concerned with keeping unauthorized users from gaining access to the system. The third area, file system security, is concerned with preventing unauthorized access, either by legitimate users or crackers, to the data stored in the system. This section describes the UNIX security tools provided to make each of these areas as secure as possible.

One of the easiest ways for a cracker to get into a system is by breaking into someone's account. This is usually easy to do, since many systems have old accounts whose users have left the organization, accounts with easy-to-guess passwords, and so on.

The password is the most vital part of UNIX account security. If a cracker can discover a user's password, he can then log in to the system and operate with all the capabilities of that user. If the password obtained is that of the super-user, the problem is more serious: the cracker will have read and write access to every file on the system. For this reason, choosing secure passwords is extremely important.

The UNIX passwd program  places very few restrictions on what may be used as a password. Generally, it requires that passwords contain five or more lowercase letters, or four characters if a nonalphabetic or uppercase letter is included. However, if the user ``insists'' that a shorter password be used (by entering it three times), the program will allow it. No checks for obviously insecure passwords (see below) are performed. Thus, it is incumbent upon the system administrator to ensure that the passwords in use on the system are secure.

Experiments determine typical users' habits in the choice of passwords. In a collection of 3,289 passwords, 16% of them contained three characters or less, and an astonishing 86% were what could generally be described as insecure. Additional experiments in show that by trying three simple guesses on each account - the login name, the login name in reverse, and the two concatenated together - a cracker can expect to obtain access to between 8 and 30 percent of the accounts on a typical system. A second experiment showed that by trying the 20 most common female first names, followed by a single digit (a total of 200 passwords), at least one password was valid on each of several dozen machines surveyed. Further experimentation by the author has found that by trying variations on the login name, user's first and last names, and a list of nearly 1800 common first names, up to 50 percent of the passwords on any given system can be cracked in a matter of two or three days.

Selecting Passwords

The object when choosing a password is to make it as difficult as possible for a cracker to make educated guesses about what you've chosen. This leaves him no alternative but a brute-force search, trying every possible combination of letters, numbers, and punctuation. A search of this sort, even conducted on a machine that could try one million passwords per second (most machines can try less than one hundred per second), would require, on the average, over one hundred years to complete. With this as our goal, and by using the information in the preceding text, a set of guidelines for password selection can be constructed:

• Don't use your login name in any form (as-is, reversed, capitalized, doubled, etc.).
• Don't use your first or last name in any form.
• Don't use your spouse's or child's name.
• Don't use other information easily obtained about you. This includes license plate numbers, telephone numbers, social security numbers, the brand of your automobile, the name of the street you live on, etc.
• Don't use a password of all digits, or all the same letter. This significantly decreases the search time for a cracker.
• Don't use a word contained in (English or foreign language) dictionaries, spelling lists, or other lists of words.
• Don't use a password shorter than six characters.
• Do use a password with mixed-case alphabetics.
• Do use a password with nonalphabetic characters, e.g., digits or punctuation.
• Do use a password that is easy to remember, so you don't have to write it down.
• Do use a password that you can type quickly, without having to look at the keyboard. This makes it harder for someone to steal your password by watching over your shoulder.

Although this list may seem to restrict passwords to an extreme, there are several methods for choosing secure, easy-to-remember passwords that obey the above rules. Some of these include the following:

• Choose a line or two from a song or poem, and use the first letter of each word. For example, ``In Xanadu did Kubla Kahn a stately pleasure dome decree'' becomes ``IXdKKaspdd.''
• Alternate between one consonant and one or two vowels, up to eight characters. This provides nonsense words that are usually pronounceable, and thus easily remembered. Examples include ``routboo,'' ``quadpop,'' and so on.
• Choose two short words and concatenate them together with a punctation character between them. For example: ``dog;rain,'' ``book+mug,'' ``kid?goat.''

The importance of obeying these password selection rules cannot be overemphasized. The Internet worm, as part of its strategy for breaking into new machines, attempted to crack user passwords. First, the worm tried simple choices such as the login name, user's first and last names, and so on. Next, the worm tried each word present in an internal dictionary of 432 words (presumably Morris considered these words to be ``good'' words to try). If all else failed, the worm tried going through the system dictionary, /usr/dict/words, trying each word [Spaf88]. The password selection rules above successfully guard against all three of these strategies.

Password Policies

Although asking users to select secure passwords will help improve security, by itself it is not enough. It is also important to form a set of password policies that all users must obey, in order to keep the passwords secure. First and foremost, it is important to impress on users the need to keep their passwords in their minds only. Passwords should never be written down on desk blotters, calendars, and the like. Further, storing passwords in files on the computer must be prohibited. In either case, by writing the password down on a piece of paper or storing it in a file, the security of the user's account is totally dependent on the security of the paper or file, which is usually less than the security offered by the password encryption software.

A second important policy is that users must never give out their passwords to others. Many times, a user feels that it is easier to give someone else his password in order to copy a file, rather than to set up the permissions on the file so that it can be copied. Unfortunately, by giving out the password to another person, the user is placing his trust in this other person not to distribute the password further, write it down, and so on.

Finally, it is important to establish a policy that users must change their passwords from time to time, say twice a year. This is difficult to enforce on UNIX, since in most implementations, a password-expiration scheme is not available.

However, there are ways to implement this policy, either by using third-party software or by sending a memo to the users requesting that they change their passwords.

This set of policies should be printed and distributed to all current users of the system. It should also be given to all new users when they receive their accounts. The policy usually carries more weight if you can get it signed by the most ``impressive'' person in your organization (e.g., the president of the company).

Checking Password Security

The procedures and policies described in the previous sections, when properly implemented, will greatly reduce the chances of a cracker breaking into your system via a stolen account. However, as with all security measures, you as the system administrator must periodically check to be sure that the policies and procedures are being adhered to. One of the unfortunate truisms of password security is that, ``left to their own ways, some people will still use cute doggie names as passwords''.

The best way to check the security of the passwords on your system is to use a password-cracking program much like a real cracker would use. If you succeed in cracking any passwords, those passwords should be changed immediately. There are a few freely available password cracking programs distributed via various source archive sites. Alternatively, you can write your own cracking program, and tailor it to your own site. For a list of things to check for, see the list of guidelines above.

Expiration Dates

Many sites, particularly those with a large number of users, typically have several old accounts lying around whose owners have since left the organization. These accounts are a major security hole: not only can they be broken into if the password is insecure, but because nobody is using the account anymore, it is unlikely that a break-in will be noticed.

The simplest way to prevent unused accounts from accumulating is to place an expiration date on every account. These expiration dates should be near enough in the future that old accounts will be deleted in a timely manner, yet far enough apart that the users will not become annoyed. A good figure is usually one year from the date the account was installed. This tends to spread the expirations out over the year, rather than clustering them all at the beginning or end. The expiration date can easily be stored in the password file (in the full name field). A simple shell script can be used to periodically check that all accounts have expiration dates, and that none of the dates has passed. On the first day of each month, any user whose account has expired should be contacted to be sure he is still employed by the organization, and that he is actively using the account. Any user who cannot be contacted, or who has not used his account recently, should be deleted from the system. If a user is unavailable for some reason (e.g., on vacation) and cannot be contacted, his account should be disabled by replacing the encrypted password in the password file entry with an asterisk (*). This makes it impossible to log in to the account, yet leaves the account available to be re-enabled on the user's return.

Guest Accounts

Guest accounts present still another security hole. By their nature, these accounts are rarely used, and are always used by people who should only have access to the machine for the short period of time they are guests. The most secure way to handle guest accounts is to install them on an as-needed basis, and delete them as soon as the people using them leave.

Guest accounts should never be given simple passwords such as ``guest'' or ``visitor,'' and should never be allowed to remain in the password file when they are not being used.

Accounts Without Passwords

Some sites have installed accounts with names such as ``who,'' ``date,'' ``lpq,'' and so on that execute simple commands. These accounts are intended to allow users to execute these commands without having to log in to the machine. Typically these accounts have no password associated with them, and can thus be used by anyone. Many of the accounts are given a user id of zero, so that they execute with super-user permissions. The problem with these accounts is that they open potential security holes. By not having passwords on them, and by having super-user permissions, these accounts practically invite crackers to try to penetrate them. Usually, if the cracker can gain access to the system, penetrating these accounts is simple, because each account executes a different command. If the cracker can replace any one of these commands with one of his own, he can then use the unprotected account to execute his program with super-user permissions.

Simply put, accounts without passwords should not be allowed on any UNIX system.

Group Accounts and Groups

Group accounts have become popular at many sites, but are actually a break-in waiting to happen. A group account is a single account shared by several people, e.g., by all the collaborators on a project. As mentioned in the section on password security, users should not share passwords - the group account concept directly violates this policy. The proper way to allow users to share information, rather than giving them a group account to use, is to place these users into a group. This is done by editing the group file, /etc/group, and creating a new group with the users who wish to collaborate listed as members. A line in the group file looks like groupname:password:groupid:user1,user2,user3,... The groupname is the name assigned to the group, much like a login name. It may be the same as someone's login name, or different. The maximum length of a group name is eight characters. The password field is unused in BSD-derived versions of UNIX, and should contain an asterisk (*). The groupid is a number from 0 to 65535 inclusive. Generally, numbers below 10 are reserved for special purposes, but you may choose any unused number. The last field is a comma-separated (no spaces) list of the login names of the users in the group. If no login names are listed, then the group has no members. To create a group called ``hackers'' with Huey, Duey, and Louie as members, you would add a line such as this to the group file: hackers:*:100:huey,duey,louie

After the group has been created, the files and directories the members wish to share can then be changed so that they are owned by this group, and the group permission bits on the files and directories can be set to allow sharing. Each user retains his own account, with his own password, thus protecting the security of the system.

Yellow Pages

The Sun Yellow Pages system  allows many hosts to share password files, group files, and other files via the network, while the files are stored on only a single host. Unfortunately, Yellow Pages also contains a few potential security holes.

The principal way Yellow Pages works is to have a special line in the password or group file that begins with a ``+''. In the password file, this line looks like +::0:0::: and in the group file, it looks like +: These lines should only be present in the files stored on Yellow Pages client machines. They should not be present in the files on the Yellow Pages master machine(s). When a program reads the password or group file and encounters one of these lines, it goes through the network and requests the information it wants from the Yellow Pages server instead of trying to find it in the local file. In this way, the data does not have to be maintained on every host. Since the master machine already has all the information, there is no need for this special line to be present there.

Generally speaking, the Yellow Pages service itself is reasonably secure. There are a few openings that a sophisticated (and dedicated) cracker could exploit, but Sun is rapidly closing these. The biggest problem with Yellow Pages is the ``+'' line in the password file. If the ``+'' is deleted from the front of the line, then this line loses its special Yellow Pages meaning. It instead becomes a regular password file line for an account with a null login name, no password, and user id zero (super-user). Thus, if a careless system administrator accidentally deletes the ``+''. the whole system is wide open to any attack.*

Yellow Pages is too useful a service to suggest turning it off, although turning it off would make your system more secure. Instead, it is recommended that you read carefully the information in the Sun manuals in order to be fully aware of Yellow Pages' abilities and its limitations.

(from "Improving the Security of your Unix System", Final Report + April 1990, by David A. Curry)