Controlling User and Privileges

Attempting to gain access to user accounts on the targeted host is a step common to many network-based attacks. To protect the system against this attack vector, it is important to control user access through the following measures:

• Managing unattended accounts

• Protecting administrative accounts

• Enforcing strong passwords

• Controlling group membership

Let's begin this discussion by looking at the threats posed by unattended accounts.

Managing Unattended Accounts

Some of the most vulnerable accounts on a host are those assigned to the system's services, as opposed to human users. Such accounts are often left unattended, without a legitimate user available to notice attempts to misuse the account. Examples of unattended accounts in Windows that should be disabled, unless they are actually used, are Guest and IIS_servername, where servername is the name of the machine. UNIX platforms often come with unattended accounts that many hosts end up not using as well, such as sys, lp, and bin.

You should delete or disable unattended accounts if you do not need them. Deleting, rather than disabling, such accounts is often a more attractive option because it eliminates the likelihood that the account will be accidentally enabled. However, removing an account may result in orphan files owned by a UID that may get reassigned to another user by accident, particularly on UNIX platforms. Additionally, it is more difficult to restore an account that you deleted, rather than simply disabled, should you later find the need for using this account.

Note

It's important to verify regularly that unused user accounts are disabled or deleted to ensure that they are not accidentally reactivated.

If possible, unattended accounts should be deactivated in a way that logs any attempts to access them over the network. In UNIX you can easily accomplish this by setting the shell of the disabled account to noshell, which disconnects any user attempting to log in to the disabled account and creates an appropriate entry in the system's log. (The noshell utility is part of the Titan hardening package and can be downloaded free from http://www.fish.com/titan.)

Unattended accounts are often created with more privileges than they require or are assigned easy-to-guess passwords. You may need to leave some of these accounts on the system so that the applications that use them continue to function. In this case, you may still be able to limit access rights assigned to them and to change their password. Unattended accounts that remain on the system should be configured with the least necessary amount of privileges, and they should have complex passwords.

Protecting Administrative Accounts

Administrative accounts, such as root in UNIX and Administrator in Windows, may be even more attractive to attackers than unattended accounts. After all, administrative users are known to possess the greatest access level to the targeted host. You can protect administrative accounts by making them available to as few individuals in your organization as possible and by being careful about the actions these persons take while using such accounts.

Traditionally, UNIX systems have a single administrative user named root, which has a user identifier (UID) of 0. The root account is special because UNIX grants special privileges to any account that has UID 0. The Administrator account on Windows systems has a security identifier (SID) that ends with the suffix 500. This SID belongs to the Administrators group by default; any account you add to this group will have administrative privileges.

If the machine is maintained by multiple administrators, we recommend assigning dedicated nonprivileged accounts to these users. You should ask the administrators to use privileged accounts only when their actions require such access. They can accomplish this without logging out of their primary account by using the su utility in UNIX or the runas tool in Windows. Limiting the users of administrative accounts in this way will minimize the chance that these accounts will be compromised (for instance, when the administrator browses a malicious website while using a vulnerable browser). Using administrative accounts in this manner also helps provide an audit trail for detecting and investigating the compromise of such accounts.

Tip

Consider renaming the original root or Administrator account, and placing a dummy account in its place that has no privileges and a very long and complex password. A naïve attacker will attempt targeting this account, wasting time on an attack that is bound to fail. Creating a dummy administrative account and enabling auditing on it allows you to detect when someone is attempting to target your privileged accounts.

Enforcing Strong Passwords

Even a password for a nonprivileged account can act as an entry point for launching further attacks against the host as well as for accessing information available through the user's account. User accounts with poor passwords are one of the most commonly exploited security weaknesses. After an attacker obtains access to a user account, he often seeks to elevate the user's permissions to administrative permissions. The attacker gains full access to the system by taking advantage of a vulnerability in the OS or in one of the installed applications.

The system's users need to be educated to understand that they are responsible for safeguarding their passwords. Knowing that even security-conscious people have a tendency to select passwords that are easily guessable, administrators should implement mechanisms that enforce the desired password guidelines. On the one hand, a person may have a difficult time remembering cryptic passwords required by an organization that has unreasonable password strength requirements. On the other hand, increasing the complexity of a user's password makes it much harder for an attacker to "crack" the password with a tool that guesses passwords based on a dictionary file. Some of the tools attackers can use for this purpose are listed here:

• L0pht Crack (http://www.atstake.com/products/lc)

• Crack (ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack)

• John the Ripper (http://www.openwall.com/john)

Just as the attackers can use these tools to locate accounts with weak passwords, so can you. In fact, you should routinely audit the strength of your users' passwords so that you have an opportunity to address the issue before attackers can take advantage of it. Before auditing system passwords, it is very important that you obtain documented authorization from your organization's management to perform this task. Jobs have been lost, and administrators have even gone to jail due to apparent misunderstandings over the purpose of their password-auditing activities.

Establishing an effective password policy and educating the users about proper ways to select and remember strong passwords goes a long way toward helping to prevent unauthorized system access. Another way to help ensure the integrity of the authentication process is to use tokens such as RSA's SecurID. SecurID is a small hardware device or a software module that generates a different access code approximately every minute and works in conjunction with RSA back-end software. When logging in, users are asked to supply a password that they remember as well as the temporary access code that the SecurID token has generated.

Another challenge in securing access to user accounts is the administrative complexity of assigning initial passwords to new user accounts. Many organizations use the same default password for all new users, and many individuals in the organization generally know this password. Using a random initial password is an effective way to protect new user accounts. Many attackers, especially insiders, attempt to compromise newly created accounts by trying typical first-time passwords such as "password," "test," or the username of the user. Other important password policies include a minimum password length of eight characters, password aging, password history, and account lockout after a certain number of consecutive failed login attempts.

Note

Enforcing the account lockout policy might open your organization to a denial of service (DoS) attack if attackers can attempt to log in to your system over the network as the user whom they want to lock out.

Password aging limits the amount of time a password is valid before the user must select another password. This option is critical for preventing an attacker who knows an account's password from being able to access the host months later because the user doesn't want to and doesn't have to change the password.

Maintaining password history is important because users often inadvertently circumvent security policies. Password history will remember the prior n number of passwords used for an account and prevent these passwords from being used again. Although password history is helpful, users can frequently bypass this restriction by incrementing the number that they add at the beginning or the end of the password. If possible, consider implementing mechanisms that require that a new password differ from the previous password by a certain number of characters.

Password Games Users Play

In some environments, password aging only sets the maximum age for a password, not a minimum age. A minimum age says that after a password has been set, a user cannot change it for a certain number of days. If you do not establish a minimum password age, but you require passwords to be changed regularly, some of your users will play a fun password game. For example, a user might change his password "raiders" to "newpass" and then immediately change it back from "newpass" to "raiders." If you have password history enabled, some users will rapidly change their password several times, then change it back to what it originally was. Change the rules of the game by implementing a minimum password age of at least a few days.

You can help prevent users from picking weak passwords by implementing password-filtering mechanisms that verify the strength of the password before allowing the user to set it. You can use the ntpassword tool to accomplish this on UNIX platforms (http://www.utexas.edu/cc/unix/software/npasswd). Windows 2000 and above come with such capabilities built in, whereas Windows NT requires you to install the passfilt.dll utility before you can enable this functionality (see Microsoft Knowledgebase article 225230).

A compromise of the password's confidentiality might grant a remote attacker local access to the system, whether the password belongs to a user or service account. Password-related issues can be mitigated through user awareness and through enforceable policies that encourage good password practices. By developing and implementing a password policy that balances security needs, business requirements, and human limitations, you can alleviate many of the risks associated with password misuse.

Controlling Group Membership

Another aspect of controlling user access involves examining groups that user accounts belong to and limiting access permissions assigned to those groups. One reason for assigning access permissions to groups instead of individual users is that group permissions automatically apply for each user in the group. By managing permissions for groups and assigning users to groups, administrators can keep much better control of security in their environments. You should grant groups the minimum access rights that the group's members need to fulfill required tasks.

A common configuration mistake when placing users into groups is having too many users assigned to highest-privilege groups. Although it's natural to think of placing users who need to perform certain administrative functions in the Domain Administrators group in Windows or in the root group in Linux, you should determine whether another administrative group has lesser permissions that are still adequate for performing the required tasks. For example, if you have to change the time on a host, what would be the preferred group membership? The recommended group for Windows would be Server Operators or Power Users. It's important to determine which group would provide the most restrictive level of permissions while still supporting the task.

UNIX groups such as sysadmin, sys, and root should also have a controlled membership. The permissions granted to these groups might allow their members to access sensitive files and executables. Instead of adding user accounts to these critical groups, consider using tools such as Sudo to allow specific users to execute privileged commands without having full root privileges (http://www.courtesan.com/sudo). Using Sudo is an effective security measure because it restricts administrative privileges and records the invocation of Sudo privileges into a log; this is terrific for determining accountability for restricted tasks.

Keeping an eye on how your administrative accounts and groups are used is an important aspect of protecting a host against attacks. You can quickly detect the misuse of user accounts, and investigate other security-related problems, if you maintain and monitor security logs as we discuss in the following section.