Implementing Windows 2000 Security

When implementing an IIS server, you must first ensure that the Windows 2000 server hosting the IIS service is secure. Measures you can take include the following:

Minimize services.
Define the user account for anonymous access.
Secure the file system.
Apply specific registry settings.

Minimizing Services

At a minimum, an IIS server requires that you configure the following services to start automatically:

IISAdmin
Allows administration of the Web server
World Wide Web Publishing Service
Enables the World Wide Web (WWW) Publishing service on the IIS server

You might have to enable additional Internet-based services if they are required on your IIS server. These services are enabled in the Add/Remove Programs applet in the Control Panel by adjusting the properties of IIS. These services include the following:

FTP Publishing Service
Enables the IIS server to function as an FTP server
Network News Transport Protocol (NNTP)
Enables the IIS server to host NNTP newsgroups
Simple Mail Transfer Protocol (SMTP)
Enables the IIS server to send and receive e-mail as an SMTP server

In addition to these services, you should configure baseline security services as recommended in the Windows 2000 Security Operations Guide.

For more information on recommended baseline services configuration, see Chapter 8, Securing Services.

Defining User Accounts

For anonymous access to the Web server, IIS provides a user account, IUSR_ComputerName, where ComputerName is the NetBIOS name of the member server. By default, all anonymous Web access is performed in the security context of the IUSR_ComputerName account. When created, the IUSR_ComputerName account is configured as a member of the local Guests group on the member server.

If you install IIS on a domain controller, the IUSR_WebServerName user account is assigned excess privileges. Any user account created in the Active Directory directory service is automatically assigned membership in the Domain Users global group. Membership in this group results in the IUSR_WebServerName user account having the same permissions as the Users domain local group. To rectify this security issue, add the IUSR_WebServerName user account to the membership of the Domain Guests global group, change the primary group for the user account to the Domain Guests global group, and delete the membership in the Domain Users global group. You must designate a new primary group before you can delete the Domain Users group s membership.

You should implement a custom account for anonymous access to the Web server. Rather than maintain default memberships, create a custom local group or domain local group. By creating a custom group, you can assign all anonymous permissions to that group, rather than assigning permissions to the Everyone group or to the Guests group.

If you implement a custom IIS anonymous account, disable the IUSR_ComputerName account to prevent attackers from using this account to attempt network connections.

You must assign specific account options and user rights to the anonymous Web access account. These custom settings include the following:

Account options
The custom user account must have the User Cannot Change Password and Password Never Expires options enabled.
User rights
You must assign the custom user account the Log On Locally user right.

In addition to these custom settings, you must configure IIS to manage the user account s password. This is accomplished by enabling the Allow IIS To Control Password check box in the properties of the IIS anonymous user account.

Securing the File System

To allow configuration of local file system security, all volumes that host Web content should be formatted by using the NTFS file system. In addition to using NTFS, you should consider hosting all Web content on a volume separate from the OS to prevent attackers from performing directory traversal attacks to gain access to OS files.

In a directory traversal attack, an attacker attempts to navigate to a location on the file system not published by the Web server. For example, the default path for the Web server root is %systemdrive%\Inetpub\WWWroot. An attacker might attempt to gain access to the command shell by using the URL http://../../windir/system32/cmd.exe.

In addition to storing all Web content on a separate drive, you should create a folder structure that separates available content by type to allow specific permissions for the assignment of file types. For example, you can create the folder structure shown in Figure 21-1 to separate content into the categories of executables, scripts, include files, images, and static Web pages.

figure 21-1 dividing web content into separate folders

Figure 21-1. Dividing Web content into separate folders

Once you create the required folder structure, you can apply discretionary access control lists (DACLs) specific to the Web content type, as shown in Table 21-1. The AnonWebAccess group is a custom local group created at the Web server that contains only the custom anonymous IIS user account.

Table 21-1. Securing Web Content by Content Type
Content Type	Recommended DACL Settings
Executables (.exe, .dll, .cmd, and .pl)	AnonWebAccess (Execute) Administrators (Full Control) System (Full Control)
Scripts (.asp)	AnonWebAccess (Execute) Administrators (Full Control) System (Full Control)
Server-side includes (.inc, .shtm, and .shtml)	AnonWebAccess (Execute) Administrators (Full Control) System (Full Control)
Images (.jpg, .gif)	AnonWebAccess (Read) Administrators (Full Control) System (Full Control)
Static content (.htm, .html)	AnonWebAccess (Read) Administrators (Full Control) System (Full Control)

Applying Specific Registry Settings

Web servers are frequently targets of denial-of-service attacks. You can help protect a Web server against a synchronization (SYN) attack by enabling the SynAttackProtect registry value:

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\SynAttackProtect

This REG_DWORD registry value protects against SYN attacks by adjusting the retransmission of SYN acknowledgment packets. These are the allowed values for the registry value:

0
Provides typical protection against SYN attacks
1
Adjusts the retransmission of SYN acknowledgments. This setting causes responses to time out faster if a SYN attack is detected
2
Adds delays to connection indications and times out Transmission Control Protocol (TCP) connection requests at a faster rate if a SYN attack is detected

A computer detects a SYN attack by inspecting three other registry values in the Tcpip/parameters registry key:

TCPMaxPortsExhausted
Determines how many connection requests the system refuses before initiating SYN attack protection. This should be set to a value of 2 or greater.
TCPMaxHalfOpen
Determines how many connections the server maintains in the half-open state before TCP/IP initiates SYN attack protection. A half-open state occurs when a client starts a TCP/IP three-way handshake but does not respond to the server s synchronization request. This should be set to a value of 2 or greater.
TCPMaxHalfOpenRetried
Determines how many connections the server maintains in the half-open state even after a connection request is retransmitted. This should be set to a value of 2 or greater.