Account Management

I l @ ve RuBoard

Account management is a very large part of a system manager's job. It includes the assigning of accounts for new users, retiring accounts when the user is no longer authorized, and disabling accounts when the account is temporarily not going to be used. Unfortunately, account management is often considered administrative drudgery ” day-to-day work to be delegated.

Good account management can go a long way toward keeping a hacker from making your system his home. Appropriately retiring an account and disabling an account when the user will not be using it for a period of time, for example, during his vacation, and monitoring an account while it is not being used will often catch hackers who are using these accounts.

UNIX accounts are defined in the password file /etc/passwd and are the base element of accounting; that is, all processes are owned by an account and all of the resources that are consumed on a system are assigned to an account. Each account has a login name, an optional password, a numeric user ID and numeric group ID, a home directory, and a start-up shell. It is the numeric IDs that are used by the system; the character login name and group name are there for human convenience.

User Accounts

Accounts exist for all users of the system, as well as entities that are not users, per se. All accounts can own system resources. This ownership gives the account special privileges with the resources. There may be accounts that exist for subsystems, such as databases or networking services. These accounts generally do not have the ability to log in; that is, they have no valid password. However, they still have all the rest of the attributes of the account.

Every account should be for one specific function or user. Sharing an account creates group accountability and defeats the ability to assign resources and accountability to a specific individual. Most systems will have a one-user, one-login policy so all the resources can be traced to a specific individual.

Guest Accounts

A guest account is an account that has either no password or a well-known password. Generally these are set up so a "guest" can have limited access to a system. Guest accounts are created for someone who will be accessing the system for a short time. This way, the system manager does not have to create a new user, only to remove this new user a short time later. Some systems come with guest accounts built-in. The two most common are guest and demo.

Guest accounts provide anonymous access and no accountability. The perceived trouble to add and remove a user who will be on the system only a short time is much less than locating and correcting problems that can be created by an anonymous guest user. Guest accounts are extremely useful to hackers to get a foot in the door of the system and look around. Generally the guest accounts have very limited capabilities. However, even with limited capabilities there are numerous ways the hacker can use them to get more privileges.

Default Accounts

A default account is an account that is created by the hardware or software vendor by default. These accounts may be required for particular software to operate , or they may be for the convenience of support personnel, or they may be included because they have always been there. Many of these accounts have either no password or they have default passwords that have become well-known. This is a quick and common attack of a system, often used by hackers to judge the quality of administration of a system. Here is a list of some of the well-known default accounts.

• root is the default name for the superuser's account.

• daemon is the account that owns all the UNIX background processes.

• bin and sysbin are accounts that own the executable files on the system.

• adm and sysadmin are accounts for administrative activities. They generally own the system logs and accounting information.

• rje is the account for all IBM mainframe networking products.

• guest and demo are accounts that by default have no password and exist to allow anyone to access the system through a guest account or run the demonstration programs with the login demo.

• lp is the account for the print spooler.

• uucp , nuucp , and uufield are accounts for the UUCP serial networking protocol. The account names uucp and nuucp have both been used for anonymous accesses via UUCP. The uufield account is an account used by the hardware vendor for field support, so field support engineers can access customer systems and get and update files.

All default accounts, except for root, should be removed or disabled. To disable an account, you can change the encrypted password field in the password file to LOCKED. If you are using shadowed passwords, this will have to be done in the shadow password file. Most system management tools have the ability to lock an account and automatically manage both the password file and the shadow password file.

If your hardware or software vendor says that a default account is required, find out its purpose. Does it have to be on the system only when there are support people accessing it? Can the name be changed? Minimally, change the password!

Captive Accounts

A captive account is an account that is created to offer information to someone without logging on. It directly executes a noninteractive command or program. These accounts generally have no password to make them more usable. Some historic captive accounts are date, which shows the system's current time and date; who, which shows who is currently on the system; and backup, which performs a system backup. A system administrator may have created a captive account for simple processes or to restrict a user. Quite often if a user performs only one function on a system, it makes sense to restrict him to running only that one program. However, if that program is not well-designed, the user may be able to escape from the program and have access to the system in a more direct manner.

Captive accounts are dangerous because they allow anonymous access, even if it is limited. They also have a home environment that can be exploited with trusted systems. Remove all captive accounts.

Dormant Accounts

A dormant account is an account that has been created and either has never been used or has not been used for an extended period of time. This may be because the person has changed job responsibilities or is no longer employed, or the account may have been made for a project manager or sponsor who really did not need access to the computer. In any case, these are valuable accounts for hackers: Since no one is using them, no one may notice his misuse of them, since most computer misuse is noticed by regular users and not the system managers. Dormant accounts should be retired .

This points out the importance of having and enforcing a computer access authorization policy. This policy will require proper authorization for adding a new user and require that the security manager be notified on the termination of any computer-authorized users.

This also is a reason for a comprehensive computer security training for all computer-authorized personnel. They need to know how to tell if there is something suspicious going on with their account and they need to know whom to notify if they are concerned .

Disabled Accounts

A disabled account is a account that does not have a valid password. Accounts may be disabled because a user is on leave, or it may be disabled until the account and the associated files are removed. Generally system managers will disable an account by putting an asterisk, or the word "DISABLED" or "LOCKED" in the password field. Any entry in the password field that is not 13 characters long will effectively disable the login. If you are using shadow passwords, the system administration tools should allow you to disable accounts.

Disabled accounts are still valid accounts. They can still own files, and run processes. They can have access via the Berkeley Trusted Host mechanism.

Some systems have the ability to automatically disable an account if the account has a given number of successive failed login attempts. This is an attempt to thwart password guessing at the login prompt.

This is a useful tool to the hacker because he can easily lock users, and sometimes the system manager, out of the system by entering bad passwords at the login prompt. With a complete list of user names, he could deny service to all users on the system.

Any automated response system must be carefully thought out to see if it can be used by a hacker to attack a system, yours or another. In this case, automatically disabling accounts can rapidly be turned into a denial-of-service attack.

Retired Accounts

User IDs should never be reused. They are assigned to a specific user and are contained on backups and logs even after that user is no longer allowed on the system. When an account is not going to be used again, it should be retired and disabled, and files owned by the account reassigned. Retired accounts should not own anything.

I l @ ve RuBoard