Step 5. Accounts | Improving Web Application Security: Threats and Countermeasures

You should remove accounts that are not used because an attacker might discover and use them. Require strong passwords. Weak passwords increase the likelihood of a successful brute force or dictionary attack. Use least privilege. An attacker can use accounts with too much privilege to gain access to unauthorized resources.

During this step, you:

Delete or disable unused accounts .
Disable the Guest account .
Rename the Administrator account .
Disable the IUSR Account .
Create a custom anonymous Web account .
Enforce strong password policies .
Restrict remote logons .
Disable Null sessions (anonymous logons) .

Delete or Disable Unused Accounts

Unused accounts and their privileges can be used by an attacker to gain access to a server. Audit local accounts on the server and disable those that are unused. If disabling the account does not cause any problems, delete the account. (Deleted accounts cannot be recovered.) Disable accounts on a test server before you disable them on a production server. Make sure that disabling an account does not adversely affect your application operation.

Note	The Administrator account and the Guest account cannot be deleted.

Disable the Guest Account

The Guest account is used when an anonymous connection is made to the computer. To restrict anonymous connections to the computer, keep this account disabled. The guest account is disabled by default on Windows 2000. To check whether or not it is enabled, display the Users folder in the Computer Management tool. The Guest account should be displayed with a cross icon. If it is not disabled, display its Properties dialog box and select Account is disabled .

Rename the Administrator Account

The default local Administrator account is a target for malicious use because of its elevated privileges on the computer. To improve security, rename the default Administrator account and assign it a strong password.

If you intend to perform local administration, configure the account to deny network logon rights and require the administrator to log on interactively. By doing so, you prevent users (well intentioned or otherwise ) from using the Administrator account to log on to the server from a remote location. If a policy of local administration is too inflexible , implement a secure remote administration solution. For more information, see "Remote Administration" later in this chapter.

Disable the IUSR Account

Disable the default anonymous Internet user account, IUSR_MACHINE. This is created during IIS installation. MACHINE is the NetBIOS name of your server at IIS installation time.

Create a Custom Anonymous Web Account

If your applications support anonymous access (for example, because they use a custom authentication mechanism such as Forms authentication), create a custom least privileged anonymous account. If you run IISLockdown, add your custom user to the Web Anonymous Users group that is created. IISLockdown denies access to system utilities and the ability to write to Web content directories for the Web Anonymous Users group .

If your Web server hosts multiple Web applications, you may want to use multiple anonymous accounts, one per application, so that you can secure and audit the operations of each application independently.

For more information about hosting multiple Web applications see Chapter 20, "Hosting Multiple Web Applications."

Enforce Strong Password Policies

To counter password guessing and brute force dictionary attacks on your application, apply strong password policies. To enforce a strong password policy:

Set password length and complexity . Require strong passwords to reduce the threat of password guessing attacks or dictionary attacks. Strong passwords are eight or more characters and must include both alphabetical and numeric characters .
Set password expiration . Passwords that expire regularly reduce the likelihood that an old password can be used for unauthorized access. Frequency of expiration is usually guided by a company's security policy.

Table 16.3 shows the default and recommended password policy settings.

Table 16.3: Password Policy Default and Recommended Settings
Password Policy	Default Setting	Recommended Minimum Setting
Enforce password history	1 password remembered .	24 passwords remembered.
Maximum password age	42 days	42 days
Minimum password age	0 days	2 days
Minimum password length	0 characters	8 characters
Passwords must meet complexity requirement.	Disabled	Enabled
Store password using reversible encryption for all users in the domain.	Disabled	Disabled

In addition, record failed logon attempts so that you can detect and trace malicious behavior. For more information, see "Step 10. Auditing and Logging."

Restrict Remote Logons

Remove the Access this computer from the network privilege from the Everyone group to restrict who can log on to the server remotely.

Disable Null Sessions (Anonymous Logons)

To prevent anonymous access, disable null sessions. These are unauthenticated or anonymous sessions established between two computers. Unless null sessions are disabled, an attacker can connect to your server anonymously (without being authenticated).

Once an attacker establishes a null session, he or she can perform a variety of attacks, including enumeration techniques used to collect system- related information from the target computer ” information that can greatly assist subsequent attacks. The type of information that can be returned over a null session includes domain and trust details, shares, user information (including groups and user rights), registry keys, and more.

Restrict Null sessions by setting RestrictAnonymous to 1 in the registry at the following subkey :

HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

For more information, see Microsoft Knowledge Base article 246261, "How To: Use the RestrictAnonymous Registry Value in Windows 2000."

Additional Considerations

The following is a list of additional steps you can consider to further improve security on your Web server:

Require approval for account delegation .

Do not mark domain accounts in Active Directory as trusted for delegation unless you first obtain special approval to do so.
Do not use shared accounts .

Do not create shared account for use by multiple individuals. Authorized individuals must have their own accounts. The activities of individuals can be audited separately and group membership and privileges appropriately assigned.
Restrict the Local Administrators Group Membership .

Try to limit administration accounts to two. This helps provide accountability. Also, passwords must not be shared, again to provide accountability.
Require the Administrator to log on interactively .

If you perform local administration only, you can require your Administrator account to log on interactively by removing the Access this computer from the network privilege.