Chapter 9: The Web Server Role
Published: December 31, 2003 | Updated: April 26, 2006
This chapter provides guidance that will help you harden the Web servers in your environment that run Microsoft® Windows Server™ 2003 with SP1. To provide comprehensive security for Web servers and applications within your organization's intranet, Microsoft recommends that you protect each Microsoft Internet Information Services (IIS) server as well as each Web site and application that run on these servers from client computers that can connect to them. You should also protect these Web sites and applications from the Web sites and applications that run on the other IIS servers within your organization’s intranet.
To help protect against malicious users and attackers, the default configuration for members of the Windows Server 2003 family does not install IIS. When it is installed, IIS is configured in a highly secure, "locked" mode. For example, in its default state IIS will only serve static content. Because they could be exploited by potential intruders, features such as Active Server Pages (ASP), ASP.NET, Server Side Includes (SSI), Web Distributed Authoring and Versioning (WebDAV) publishing, and Microsoft FrontPage® Server Extensions will not work until an administrator enables them. These features and services can be enabled through the Web Service Extensions node in Internet Information Services Manager (IIS Manager). IIS Manager has a graphical user interface (GUI) that is designed to facilitate administration of IIS. It includes resources for file management, directory management, and configuration of application pools, as well as security, performance, and reliability features.
You should consider implementation of the settings that are described in the following sections of this chapter to enhance the security of IIS Web servers that host HTML content within your organization’s intranet. To help secure your servers, you should also implement security monitoring, detection, and response procedures to watch for new threats.
Most of the settings in this chapter are configured and applied through Group Policy. An incremental GPO that complements the MSBP is linked to the appropriate OUs and provides additional security for the Web servers. To improve the usability of this chapter, only those policy settings that vary from the MSBP are discussed.
Where possible, these settings are gathered in an incremental Group Policy template that will be applied to the Web Servers OU. Some of the settings in this chapter cannot be applied through Group Policy. Detailed information about how to configure these settings manually is provided.
The following table shows the names of the Web server security templates for the three environments that are defined in this guide. These Web server security templates provide the policy settings for the incremental Web Server template. You can use this template to create a new GPO that is linked to the Web Servers OU in the appropriate environment. Chapter 2, "Windows Server 2003 Hardening Mechanisms," provides step-by-step instructions to help you create the OUs and Group Policies and then import the appropriate security template into each GPO.
Table 9.1 IIS Server Security Templates
For information about all default setting configurations, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at http://go.microsoft.com/fwlink/?LinkId=15159.
This guide illustrates how to secure IIS with minimal features installed and enabled. If you plan to use additional features in IIS you may need to need to adjust some of the security settings. If you install additional services such as SMTP, FTP, or NNTP, you will need to adjust the provided templates and policies.
The online article "IIS and Built-in Accounts (IIS 6.0)" at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3648346f-e4f5-474b-86c7-5a86e85fa1ff.mspx explains the accounts that different features of IIS use and the privileges that are required by each. To implement more secure settings on Web servers that host complex applications, you may find it useful to review the complete IIS 6.0 Documentation at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/848968f3-baa0-46f9-b1e6-ef81dd09b015.mspx.
Anonymous Access and the SSLF Settings
Four of the user rights that are explicitly defined in the SSLF scenario in the MSBP are designed to break anonymous access to IIS Web sites. However, if you need to allow anonymous access in an SSLF environment you will need to make some important changes to the OU structure and GPOs that are described in Chapters 2, 3, and 4 of this guide. You will need to create a new OU that is not part of the hierarchy below the Member Servers OU. This OU could be linked directly to the domain root, or it could be a child OU of some other OU hierarchy. However, you should not assign user rights in a GPO that will affect the IIS servers that will be placed in this new OU. You can move the IIS servers to the new OU, create a new GPO, apply the MSBP settings to it, and then reconfigure user rights assignments so that they can be controlled by local policy rather than the domain–based GPO. In other words, you should configure the following user rights settings to Not defined in this new GPO.
The IIS features that you need to enable will determine whether you will need to also reconfigure other user rights assignment settings to Not defined.
Audit Policy Settings
The Audit policy settings for IIS servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings ensure that all the relevant security audit information is logged on all IIS servers.
User Rights Assignments
The user rights assignment settings for IIS servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings ensure that all the relevant security audit information is logged on all IIS servers.
The security option settings for IIS servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings ensure that all the relevant security options are uniformly configured on all IIS servers.
Event Log Settings
The event log settings for IIS servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings ensure that the appropriate event log settings are uniformly configured on all IIS servers in an organization.
Additional Security Settings
When IIS is installed on a computer that runs Windows Server 2003 with SP1, its default setting only allows transmission of static Web content. When Web sites and applications contain dynamic content or require one or more additional IIS components, each additional IIS feature must be individually enabled. However, you should be careful to minimize the attack surface of each IIS server in your environment. If the Web sites in your organization are comprised of static content and do not require any other IIS components, then the default IIS configuration is sufficient to minimize the attack surface of the IIS servers.
The security settings that are applied through the MSBP provide a great deal of enhanced security for IIS servers. However, there are a few additional settings that you should consider. The settings in the following sections cannot be implemented through Group Policy and must therefore be performed manually on all IIS servers.
Installing Only Necessary IIS Components
IIS 6.0 includes other components and services in addition to the World Wide Web Publishing Service, such as the services that are required to provide FTP, NNTP, and SMTP support. IIS components and services are installed and enabled with the Windows Components Wizard Application Server that can be launched through Add or Remove Programs in Control Panel. After you install IIS, you will need to enable all IIS components and services that are required by your Web sites and applications.
To install Internet Information Services (IIS) 6.0
You should only enable essential IIS components and services that are required by Web sites and applications. If you enable unnecessary components and services, the attack surface of an IIS server increases. The following illustrations and tables show the location and suggested settings for IIS components.
The subcomponents in the Application Server dialog box are shown in the following figure:
Figure 9.1 Application Server dialog box with list of subcomponents
See full-sized image
The following table briefly describes the Application Server subcomponents and provides recommendations for when to enable them.
Table 9.2 Recommended Application Server Subcomponents Settings
The subcomponents in the Internet Information Services (IIS) dialog box are shown in the following figure:
Figure 9.2 IIS dialog box with list of subcomponents
See full-sized image
The following table briefly describes the IIS subcomponents and provides recommendations for when to enable them.
Table 9.3 Recommended IIS Subcomponents Settings
The subcomponents in the Message Queuing dialog box are shown in the following figure:
Figure 9.3 Message Queuing dialog box with list of subcomponents
See full-sized image
The following table briefly describes the Message Queuing subcomponents and provides recommendations for when to enable them.
Table 9.4 Recommended Message Queuing Subcomponents Settings
The subcomponents in the Background Intelligent Transfer Service (BITS) Server Extensions dialog box are shown in the following figure:
Figure 9.4 BITS Server Extensions with list of subcomponents
See full-sized image
The following table briefly describes the BITS Server Extensions subcomponents and provides recommendations for when to enable them.
Table 9.5 Recommended BITS Server Extensions Subcomponents Settings
The subcomponents in the World Wide Web Service dialog box are shown in the following figure:
Figure 9.5 World Wide Web Service dialog box with list of subcomponents
See full-sized image
The following table briefly describes the World Wide Web Service subcomponents and provides recommendations for when to enable them.
Table 9.6 Recommended World Wide Web Service Subcomponent Settings
Enabling Only Essential Web Service Extensions
Many Web sites and applications that run on IIS servers have extended functionality that goes beyond static pages, including the ability to generate dynamic content. Any dynamic content that is served or extended through features that are provided by an IIS server is accomplished through Web service extensions.
Enhanced security features in IIS 6.0 allow individual Web service extensions to be enabled or disabled. As stated earlier, IIS servers will transmit only static content after a new installation. Dynamic content capabilities can be enabled through the Web Service Extensions node in IIS Manager. These extensions include ASP.NET, SSI, WebDAV, and FrontPage Server extensions.
One way to ensure the highest possible compatibility with existing applications is to enable all Web service extensions, but this method also creates a security risk because it increases the attack surface of IIS. You should only enable those Web service extensions that are required by the Web sites and applications that run on IIS servers in your environment. This approach will minimize server functionality and reduce the attack surface of each IIS server.
To reduce the attack surface of IIS servers as much as possible, only necessary Web service extensions are enabled on IIS servers in the three environments that are defined in this guide.
The following table lists predefined Web service extensions, and provides details on when to enable each extension.
Table 9.7 Enabling Web Service Extensions
Placing Content on a Dedicated Disk Volume
IIS stores files for its default Web site in the <systemroot>\inetpub\wwwroot folder (where <systemroot> is the drive on which the Windows Server 2003 operating system is installed).
In the three environments that are defined in this guide, all files and folders that make up Web sites and applications are placed on dedicated disk volumes that are separate from the operating system. This approach helps prevent directory traversal attacks in which an attacker sends requests for a file that is located outside the directory structure of an IIS server.
For example, the Cmd.exe file exists in the <systemroot>\System32 folder. An attacker could make a request to the following location:
in an attempt to invoke the command prompt.
If the Web site content is on a separate disk volume, a directory traversal attack of this type would not work for two reasons. First, permissions on the Cmd.exe file have been reset as part of the base build of Windows Server 2003 with SP1 that restricts access to a much more limited group of users. Second, the Cmd.exe file would not exist on the same disk volume as the Web root, and there are currently no known methods to access commands on a different drive with this type of attack.
In addition to the security-related benefits, administration tasks such as backup and restore are easier when Web site and application files and folders are placed on a dedicated disk volume. Also, use of a separate, dedicated physical drive can help reduce disk contention on the system volume and improve overall disk access performance.
Setting NTFS Permissions
Computers that run Windows Server 2003 with SP1 examine NTFS file system permissions to determine the types of access a user or a process has on a specific file or folder. You should assign NTFS permissions to allow or deny access to specific users for Web sites on IIS servers in the three environments that are defined in this guide.
NTFS permissions affect only the accounts that have been allowed or denied access to the Web site and application content. You should use NTFS permissions in conjunction with Web permissions, not instead of Web permissions. Web site permissions affect all users who access the Web site or application. If Web permissions conflict with NTFS permissions for a directory or file, the more restrictive settings are applied.
You should explicitly deny access to anonymous accounts on Web sites and applications for which anonymous access is not desired. Anonymous access occurs when a user who has no authenticated credentials accesses network resources. Anonymous accounts include the built-in Guest account, the Guests group, and IIS Anonymous accounts. Also, eliminate any write-access permissions to all users except those who are IIS administrators.
The following table provides some recommendations about the NTFS permissions that should be applied to the different file types on an IIS server. The different file types can be grouped in separate folders to simplify the application of NTFS permissions.
Table 9.8 Recommended NTFS Permissions Settings
Setting IIS Web Site Permissions
IIS examines Web site permissions to determine the types of action that can occur within a Web site, such as script source access or directory browsing. You should assign Web site permissions to provide additional security for Web sites on IIS servers in the three environments that are defined in this guide.
Web site permissions can be used in conjunction with NTFS permissions, and can be configured for specific sites, directories, and files. Unlike NTFS permissions, Web site permissions affect everyone who tries to access a Web site that runs on an IIS server. Web site permissions can be applied with the MMC IIS Manager snap-in.
The following table lists the Web site permissions that are supported by IIS 6.0, and provides brief explanations of when to assign any given permission to a Web site.
Table 9.9 IIS 6.0 Web Site Permissions
Configuring IIS Logging
Microsoft recommends that IIS logging be enabled on IIS servers in the three environments that are defined in this guide.
Separate logs can be created for each Web site or application. IIS logs more information than the event logs and performance monitoring features that are provided by the Windows operating system. The IIS logs can include information such as who has visited a site, what the visitor viewed, and when the information was last viewed. IIS logs can be used to assess content popularity, identify information bottlenecks, or as resources to help investigate attacks.
The MMC IIS Manager snap-in can be used to configure the log file format, the log schedule, and the exact information to be logged. To limit the size of the logs, you should use a careful planning process to determine which fields to log.
When IIS logging is enabled, IIS uses the W3C Extended Log File Format to create daily activity logs in the directory that is specified for the Web site in IIS Manager. To improve server performance, you should store logs on a non-system striped or striped/mirrored disk volume.
Logs can also be written to a remote share over a network by using a full, Universal Naming Convention (UNC) path. Remote logging allows administrators to set up centralized log file storage and backup. However, server performance could be negatively affected when log files are written over the network.
IIS logging can be configured to use several other ASCII or Open Database Connectivity (ODBC) log file formats. ODBC logs can store activity information in a SQL database. However, note that when ODBC logging is enabled, IIS disables the kernel-mode cache, which can degrade overall server performance.
IIS servers that host hundreds of sites can enable centralized binary logging to improve logging performance. Centralized binary logging enables all Web sites on an IIS server to write activity information to a single log file. This method can greatly increase the manageability and scalability of the IIS logging process because it reduces the number of logs that need to be individually stored and analyzed. For more information about centralized binary logging, see the IIS Centralized Binary Logging (IIS6.0) page at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/13a4c0b5-686b-4766-8729-a3402da835f1.mspx.
When IIS logs are stored on IIS servers, only server administrators have permission to access them by default. If a log file directory or file owner is not in the Local Administrators group, the HTTP.sys file (the kernel-mode driver in IIS 6.0) publishes an error to the NT event log. This error indicates that the owner of the directory or file is not in the Local Administrators group, and that logging has been suspended for that site until the owner is added to the Local Administrators group, or the existing directory or log file is deleted.
Manually Adding Unique Security Groups to User Rights Assignments
Most user rights assignments that are applied through the MSBP have the proper security groups specified in the security templates that accompany this guide. However, there are a few accounts and security groups that cannot be included in the templates because their security identifiers (SIDs) are specific to individual Windows 2003 domains. User rights assignments that must be configured manually are specified in the following table.
Warning: The following table contains values for the built-in Administrator account. Do not confuse the Administrator account with the built-in Administrators security group. If you add the Administrators security group to any of the listed deny access user rights, you will need to log on locally to correct the mistake. Also, you may have renamed the built-in Administrator account in accordance with the recommendation in Chapter 4, "The Member Server Baseline Policy." When you add the Administrator account to any user rights, ensure that the renamed account is specified.
Table 9.10 Manually Added User Rights Assignments
Important: “All non-operating system service accounts” includes service accounts that are used for specific applications across an enterprise, but does NOT include LOCAL SYSTEM, LOCAL SERVICE or the NETWORK SERVICE accounts (the built-in accounts that the operating system uses).
Securing Well-Known Accounts
Windows Server 2003 has a number of built-in user accounts that cannot be deleted but can be renamed. Two of the most well-known built-in accounts in Windows Server 2003 are Guest and Administrator.
By default, the Guest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built-in Administrator account in an initial attempt to compromise a server. Therefore, you should rename the built-in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well-known account.
The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier (SID) of the built-in Administrator account to determine its true name and then break into the server. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account. However, your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a unique name.
To secure well known accounts on IIS servers
Note: You can rename the built-in administrator account through Group Policy. This setting was not implemented in any of the security templates that are provided with this guide because every organization should choose a unique name for this account. However, you can configure the Accounts: Rename administrator account setting to rename administrator accounts in the three environments that are defined in this guide. This policy setting is a part of the Security Options settings of a GPO.
Securing Service Accounts
Never configure a service to run under the security context of a domain account unless it is unavoidable. If the server is physically compromised, domain account passwords could be easily obtained by dumping LSA secrets. For more information about how to secure service accounts, see The Services and Service Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41311.
Creating the Policy Using SCW
To deploy the necessary security settings, you must use both the Security Configuration Wizard (SCW) and the security templates that are included with the downloadable version of this guide to create a server policy.
When you create your own policy, be sure to skip the "Registry Settings" and “Audit Policy” sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SCW.
You should use a new installation of the operating system to begin your configuration work, which helps ensure that there are no legacy settings or software from previous configurations. If possible, you should use on hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference computer.
To create the IIS server policy
Note: The MSBP disables several other IIS-related services, including FTP, SMTP, and NNTP. The Web Server policy must be modified if any of these services are to be enabled on IIS servers in any of the three environments that are defined in this guide.
Test the Policy Using SCW
After you create and save the policy, Microsoft strongly recommends that you deploy it to your test environment. Ideally, your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fix potential problems, such as the presence of unexpected services that are required by specific hardware devices.
Two options are available to test the policy. You can use the native SCW deployment facilities, or deploy the policies through a GPO.
When you start to author your policies, you should consider using the native SCW deployment facilities. You can use SCW to push a policy to a single server at a time, or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SCW. This capability can be very useful when you make multiple changes to your policies during the test process.
The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes, you should begin to verify the core functionality of the computer. For example, if the server is configured as a certification authority (CA), ensure that clients can request and obtain certificates, download a certificate revocation list, and so on.
When you are confident in your policy configurations, you can use Scwcmd as shown in the following procedure to convert the policies to GPOs.
For more details about how to test SCW policies, see the Deployment Guide for the Security Configuration Wizard at http://technet2.microsoft.com/WindowsServer/en/Library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx and the Security Configuration Wizard Documentation at http://go.microsoft.com/fwlink/?linkid=43450.
Convert and Deploy the Policy
After you thoroughly test the policy, complete the following steps to convert it into a GPO and deploy it:
Note that if the SCW security policy file contains Windows Firewall settings, Windows Firewall must be active on the local computer for this procedure to complete successfully. To verify that Windows Firewall is active, open Control Panel and then double-click Windows Firewall.
You should now perform a final test to ensure that the GPO applies the desired settings. To complete this procedure, confirm that the appropriate settings were made and that functionality is not affected.
This chapter explained the policy settings that can be used to harden IIS servers that run Windows Server 2003 with SP1 in the three environments that are defined in this guide. Most of the settings are applied through a Group Policy object (GPO) that was designed to complement the MSBP. GPOs can be linked to the appropriate organizational units (OUs) that contain the IIS servers to provide additional security.
Some of the settings that were discussed cannot be applied through Group Policy. For these settings, manual configuration details were provided.
The following links provide additional information about topics that relate to hardening IIS–based Web servers that run Windows Server 2003 with SP1.