Published: February 27, 2008

This chapter focuses on how to harden Web servers running Windows Server® 2008. The Web Server role by default installs Microsoft® Internet Information Services (IIS) 7.0 on a computer running Windows Server 2008.

Microsoft redesigned IIS 7.0 into 40 modular components that you can choose to install as needed. The fewer components that you install, the smaller the attack surface that is available to a potential attacker.

By default, IIS 7.0 Setup installs a Web server with minimum functionality that supports static Web pages, request filtering, static file compression, and the IIS Manager GUI interface. There are many IIS 7.0 scenarios that organizations can use to provide Web services. However, the following two considerations are key to planning your Web server design:

• The sensitivity of the data that the server will present: Knowing this provides you with an idea of the risk involved if the data is compromised, and how much effort your organization should spend to protect it.
• The required user experience: Knowing this governs the feature requirements of the Web site itself, and the components that you need to install to secure it.

This chapter focuses on a typical scenario of a Web server hosted on a corporate intranet that displays mission critical content and data. Access to the server, or applications on the server, are restricted to users on a job need basis. This type of Web server requires authentication and authorization mechanisms that are tied to Active Directory® users and groups. You can use these groups to generate certificates to identify users after you have granted them permission to access information on the server.

For this scenario, this chapter discusses how you can apply best practice processes to harden your Web server against malicious attacks from either anonymous or authorized users. If you choose to use the default modules that install with IIS 7.0, these configure the Web server to only provide static HTML pages and images. The Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator lists the files and services that install with each feature.

As in previous versions of IIS, when you perform a default installation of IIS 7.0 on a computer running Windows Server 2008, the Setup program installs and starts the Worldwide Web Publishing (W3SVC) service on the server computer.

In addition, the IIS 7.0 Setup program installs and starts the Windows Process Activation Service (WAS). WAS generalizes the IIS process model, making IIS 7.0 HTTP independent. Because of this, your IIS server can now host Windows Communication Foundation (WCF) services using non-HTTP protocols. It also includes configuration application programming interfaces (APIs) that allow you to configure WAS settings programmatically. The W3SVC service depends on the WAS service.

Finally, the default installation of IIS 7.0 also installs the Application Host Helper Service (AppHostSvc). This service provides a configuration history feature that lets you go back to an earlier version of the Web server configuration. The Application Host Helper Service saves the ApplicationHost.config file to separate configuration history subdirectories at intervals that you specify. Previous configuration settings for this service were stored by default in the \inetpub\history\CFGHISTORY_xxxxxxxxxx subdirectory, where each x represents a number that would increment for each configuration version. If you copy an earlier version of the IIS configuration file into the %windir%\system32\inetsrv\config directory, you will return IIS to the configuration state contained in the restored file.

Secure By Default

At a conceptual level, the security considerations for the Web server role using IIS 7.0 on a computer running Windows Server 2008 have not changed significantly from those for a computer running IIS 6.0 with Windows Server® 2003. It remains important to keep the server's attack surface as small as possible.

However, at the implementation level, a lot has changed between the releases of IIS 6.0 and IIS 7.0. A fundamental change is that instead of installing a variety of features with IIS 6.0 and then having to enable or disable them, IIS 7.0 uses a minimum installation by default approach—only installing components that work with static sites. The default installation for IIS 7.0 includes the following feature modules:

• Static content module
• Default document module
• Directory browsing module
• HTTP Errors module
• HTTP Logging module
• Request Monitor module
• Request Filtering module
• Static Content Compression module
• IIS Management Console module

The default installation of IIS 7.0 does not support ASP.NET or ASP functionality. You must explicitly select them during the role selection process to include these technologies on your IIS 7.0 Web server. The following figure illustrates the role services that make up the Windows Server 2008 Web Server (IIS) role.

Note   The items in bold in the figure are components that install by default when you select the high-level Web Server role.

Figure 6.1. Role services hierarchy for the Web Server role

Attack Surface

Microsoft designed IIS 7.0 with a modular architecture and a minimum of module and feature dependencies. You can choose from 40 modules to customize your installation for the needs of your particular Web server.

The default installation of IIS 7.0 only supports serving static content such as HTML and image files. This exposes the minimum attack surface while still providing Web server functionality.

Microsoft organized the IIS 7.0 installation into seven feature areas. These include the Common HTTP Features feature area, the Application Development feature area, the Health and Diagnostics feature area, the Security feature area, the Performance feature area, the Management Tools feature area, and the FTP Publishing Service feature area. How you want to manage your IIS 7.0 Web server and the feature requirements of the sites and applications that you plan to host on your IIS 7.0 Web server determines which modules and features to install. However, the more modules and features that you install, the larger the attack surface on the Web server.

The IIS 7.0 setup program installs a different set of files, services, and firewall rules based on the features and modules that you choose. To determine the attack surface of this role service, you need to identify the following:

• Installed files. These are files that are installed as part of the Web Server role.
• Installed services. These are services that are installed as part of the Web Server role.

  Note   You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.

• Firewall rules. These are the firewall rules that are installed (or enabled) for the Web Server role.

The details of the attack surface for the Web Server role are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this role service, on the Web tab of the workbook, view the sections that correspond to each of the items in the previous list.

Security Measures

This section describes security measures that you can incorporate into your Web server (IIS) configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Web Server role on the Select Role Services page of the Add Roles Wizard, accepted all of the defaults, and included the ASP.NET option. Further recommendations for the Common HTTP Features, Application Development, Health and Diagnostics, Security, Performance, Management Tools, and FTP Publishing services are not included. For more information about how to configure these services, see the IIS 7.0: Configure Web Server Security.

There are many ways to set up a Web server that uses IIS, but this guidance focuses on a common scenario that uses an ASP.NET application that connects to a database. For example, an internal ordering system or a Human Resource application could provide such a database.

A Web site of this type typically consists of the following:

• Static pages (HTML pages).
• Images that use .jpg and .gif file formats.
• Dynamic ASP.NET pages.

As part of planning the installation for the Web server, ensure that the application developers in your organization follow security best practices. For more information about best practices in this area, see Improving Web Application Security: Threats and Countermeasures.

It is important to understand that if your organization does not follow security best practices, you will be making it easy for your Web server to fall victim to malicious attacks. Even after using security best practices to set up a Web application, there are several steps that you need to take to secure the Web server.

Configuration Checklist

The following table summarizes the recommended security configuration tasks for hardening servers that perform the Web Server role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.

Table 6.1. Configuration Checklist

Consider Deploying a Server Core Installation of Windows Server 2008

Consider deploying Windows Server 2008 using the Server Core installation option to further reduce the attack surface of the operating system by reducing the number of installed files and running services. The advantage of the Server Core installation option is that a graphical user interface (GUI) is not installed, so the files and services required by the normal GUI are not installed.

There are two issues you need to be aware of when using a Windows Server 2008 Server Core installation for the Web Server (IIS) role. First, you cannot directly manage the installation using a GUI. Instead you must use the Microsoft Management Console (MMC) management tools remotely from a computer that has them installed or use command-line management tools to directly manage the server installation. Second, Server Core does not support ASP.NET and .NET Framework associated features. If your applications require .NET functionality, you cannot use the Windows Server 2008 Server Core installation.

Because the scenario used in this chapter requires ASP.NET, you cannot attempt these procedures using a Server Core installation. However, apply the general principles outlined to any Web Server (IIS) role using a Server Core installation.

You can use the following command-line management tools to install the Web Server role on computer running Windows Server 2008:

• To install the default Web Server (IIS) role and the services associated with it, complete the following command:
  Copy

  start /w pkgmgr /iu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel
  

• To install all available services and features for the Web Server (IIS) role, complete the following command:
  Copy

  start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;
  IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;
  IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;
  IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;
  IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;
  IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;
  IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic; 
  IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementScriptingTools;
  IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-FTPPublishingService;
  IIS-FTPServer;WAS-WindowsActivationService;WAS-ProcessModel
  

  Note   This example displays on multiple lines because of display limitations and to make it easier to read. However, you must type the information at the command prompt on one line when you run the command.

For more information about how to install the Web Server (IIS) role with a Windows Server 2008 Server Core installation, see Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.

In addition, you can use the appcmd command-line tool to manage the Web Server role. For instructions on how to use the appcmd command-line tool, see the Administrative Tools section of the IIS 7.0: Operations Guide in the Windows Server 2008 Technical Library.

You can also use WMI to locally or remotely manage the Web Server (IIS) role running on Windows Server 2008 Server Core installations.

For more information about WMI, see Windows Management Instrumentation and the WMI Section of the IIS 7.0 Operations Guide in the Windows Server 2008 Technical Library.

Install the Application Development Environment

The scenario tested in this chapter uses ASP.NET because it is the most popular application development infrastructure that IIS provides. ASP.NET uses .NET Framework 2.0, which is available in Windows Server 2008.

In the Select Role Services section of the installation process for the Web server, when you select ASP.NET, the following IIS 7.0 components are required:

• ASP.NET: Includes files and configuration settings to enable ASP.NET on IIS.
• ISAPI Filters: ASP.NET requires an ISAPI Filter with the name "ASPNET_FILTER.DLL".
• ISAPI Extensions: The core functionality of ASP.NET is in the ASPNET_ISAPI.DLL file. This DLL file is built on top of the ISAPI Extension interface. IIS does not install the ISAPI Extension interface by default.
• .NET Extensibility: .NET extensibility allows your server to support managed modules that run using the ASP.NET programming model. Your developers can use .NET Framework APIs to create new Web server features.
• WAS .NET Environment: This supports managed code activation in the IIS 7.0 process model.

  If your ASP.NET applications are designed to use the out-of-process ASP.NET Session state service, you must enable this feature. If you have enabled this feature and your ASP.NET applications do not use it, disable it.

After installing the development environment, the next step to securing your Web server is to install the authentication mechanism that you want to use to determine the identity of users who connect to the applications on the Web server.

Set the Authentication Mechanism

Microsoft recommends using Windows Authentication for Web applications as your user authentication mechanism because it is integrated with Windows and Active Directory Domain Services (AD DS). By turning Windows Authentication on and Anonymous Authentication off, only authenticated users can access Web applications. You can use the following procedures to install, enable, and disable these authentication mechanisms.

To install Windows Authentication

1. Click Start and then click Server Manager.
2. In the Server Manager pane, expand Roles, and then click Web Server (IIS).
3. In the Role Services box, click Add Role Services.
4. In the Add Role Services wizard, select Windows Authentication and then click Next.
5. On the Confirm Installation Selections page, click Install.
6. On the Installation Results page, click Close.

To enable Windows Authentication

1. In the Server Manager pane, click Internet Information Services (IIS) Manager.
2. In the Connections pane, click the server name, and then in the Home pane, double-click Authentication.

   

   Figure 6.2. Enabling Windows Authentication in IIS Manager

3. In the Authentication pane, click Windows Authentication, and then in the Actions pane, click Enable.

To disable Anonymous Authentication

1. In the IIS Manager Authentication pane, click Anonymous Authentication.
2. In the Actions pane, click Disable.

Important   This procedure turns Anonymous Authentication off for the entire IIS Web Server. If you have other Web applications that need anonymous access you might have to turn the setting back on for those Web applications.

It is also possible to disable Anonymous Authentication using the command line. This can be useful when using a script to configure the Web server.

To disable Anonymous Authentication via the command line, at the command prompt, use the following syntax:

%windir%\system32\inetsrv\appcmd set config -section:anonymousAuthentication -enabled:false

Remove Unused IIS Components

At this point in the Web Server role configuration process, review the IIS 7.0 components installed on the server to ensure that all of those that your installation requires are present. You must explicitly install all role services and features provided by IIS 7.0. The only way a service you do not need can install on your Web server is if you install it. Refer to the "Attack Surface" section earlier in this chapter to determine the role services that your Web server requires, add any that your applications require, and remove any that you do not require.

Some typical areas in which to check for components include:

• Default Common HTTP modules installed by the IIS 7.0 Setup program.
• Unused development environments.
• Management features.

Configure a Unique Binding

By default, the IIS Web site listens on all configured IP addresses of the Web server for connections. The site also serves all requests that use port 80, regardless of the host header specified. Malicious software, such as viruses or worms, can attempt to iterate through a range of IP addresses to find new Web servers to infect. You can reduce the risk or such attacks by configuring the default Web site to only listen to a specific host name, which is called a unique binding.

For example, if you configure a host name as, *:80:myWebServer, instead of listening to all host names (*:80:*), such a configuration can prevent automated attacks that only use an IP address to attempt to access a server. An automated attack would usually attempt to iterate through the IP address namespace. For example, it could first try 1.1.1.1, then 1.1.1.2, 1.1.1.3, and so on.

Without a host name configured as a unique binding, your Web site would eventually receive a network packet from the attack. However, if you configure the server to require a host name, the automated attack will fail because the request to the IP address will fail, and the worm cannot determine the host name of the server without including more complex code to resolve host names. You can use the following procedure to configure a unique binding.

To configure a unique binding

1. Open Internet Information Services (IIS) Manager.
2. Select the name of your Web server, and then under the Sites node, right-click the required Web site.
3. From the context menu select Edit Bindings.
4. In the Edit Site Binding dialog box, select http in type list, and then click Edit.
5. Select the required IP address for the server's Web site, and then configure the Host header to match your required host name as shown in the following figure.

Figure 6.3. The Edit Site Binding dialog box

Based on the information in the previous figure, only applications that request the full URL for "http://contoso" can access the site. If an automated Internet worm tries to access the site using an IP address, for example "http://10.10.10.20," the connection attempt will fail.

You also can configure this setting from a command line using the following syntax:

%windir%\system32\inetsrv\appcmd set site "Default Web Site" -bindings:http/10.10.10.20:80:contoso

Move Root Directories to a Separate Data Partition

Past security vulnerabilities allowed an attacker to traverse from the URL namespace into the file system directories of the operating system. For example, if http://contoso/cgi.exe mapped to C:\inetpub\wwwroot\cgi.exe, without safeguards, an attacker could use the URL to execute the Windows command processor cmd.exe instead of the CGI program cgi.exe to access the following location:

http://contoso/../../windows/system32/cmd.exe.

IIS 7.0 is designed to prevent this type of attack by default. However, it is a best practice to move your Web site content on to a separate data partition from the one that the operating system uses. Although not required, many organizations choose to store Web site content on a dedicated data partition. This can provide both performance and security benefits. The following steps explain how to move Web site content to a new partition.

To move Web site content to a new partition

1. Open Internet Information Services (IIS) Manager.
2. Click the name of your Web server, and then underneath Sites, right-click Default Web Site.
3. Select Manage Web Site, and then select Advanced Settings.
4. Change the Physical Path property to a directory on the new data partition.

This process does not move the Web site's content or change the permission for the Web folder, so you also must transfer those resources across to complete the move.

You can change the default physical path for the Web site by executing the following command line:

%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" -physicalPath:D:\Web

Note   This command assumes your new Web site content directory is D:\Web.

Configuring User Account Permissions

Next, you must assign permissions on the Web site content directory and check the user accounts that will be allowed access to the Web site. To do this, grant access to the following security entities:

• The account associated with the IIS worker process used for the Default Web Site.

  By default, this is the NetworkService account. You must edit the Default Application Pool configuration settings to change this default. If you have changed this setting to a custom account, you must grant access to the custom account, not the NetworkService account.

  Note   Do not change the account to the LocalSystem or LocalService account. Each of these accounts have more permissions that Microsoft recommends to grant to IIS worker processes.

• The users who access your Web site.

  In most cases, you can keep the default ComputerName\Users group permissions for the folder, which allows members of a domain to access the content folder. If there are any special permissions granted to the ComputerName\Users group, ensure to remove them.

• The Web site administrators.

To configure the permissions for the Web site, you use the standard Windows file system permissions mechanism via Windows Explorer. This allows you to determine the exact security permissions for each security entity. You can use the following procedure to achieve this.

To set permissions on the D:\Web folder

1. Open Windows Explorer, right-click the Web content folder (D:\Web in the example in this chapter), and then click Properties.
2. Click the Security tab, click the Advanced button, and then select Edit.
3. Clear the checkbox for Include inheritable permission from this object's parent.
4. In the Windows Security dialog box, select the Copy checkbox to copy the inherited permission to the folder.
5. Select the checkbox for Replace all existing inheritable permissions on all descendants with inheritable permissions from this object.
6. Select each permission entry, and then click Remove, except for the following:
   • SYSTEM
   • Administrators
   • <ComputerName>\Users, for example WebServer1\Users

1. Click Add, and then in Enter the object name to select box, type Network Service.
2. Click Check Names to resolve the NETWORK SERVICE name. This is the IIS default worker process identity.
3. Click OK, then confirm that the list of permissions displayed in the following figure is selected under Allow in the Permission Entry box, and then click OK.

   

   Figure 6.4. Setting ACLs for the Network Service Account

4. On the Advanced Security Settings dialog box, click Add, and then in the Enter the object name to select box, type <DomainName>\Users.

   For the Contoso domain this example uses, you would type Contoso\Users.

5. Click Check Names to resolve the Domain Users name.

   Note   These are the users who you are allowing access to the Web site. For a site that has special security requirements, you may wish to assign permissions to a dedicated user group that contains users who are specifically added to the group as required. If possible, maintain the MachineName\Users group with read and execute permissions.

6. Click OK and then ensure that permissions are selected in the Permission Entry for Web dialog box as displayed in the following figure.

   

   Figure 6.5. Setting ACLs for domain users

7. Click OK as needed to exit the Properties window.

Enable Secure Sockets Layer (SSL)

If the network communications between the Web server and the client computers passes over untrusted networks, Microsoft recommends enabling Secure Sockets Layer (SSL) to encrypt the traffic to help secure it from network sniffing and host spoofing.

SSL requires a certificate that proves the servers identity and that is trusted by the client browsers. If the Web server can only be accessed privately within the enterprise, this certificate can be obtained from the organization's existing public key infrastructure (PKI). However, if the Web server can be accessed from the Internet, Microsoft recommends to obtain a certificate from a public certificate authority. For testing purposes, you can also use a self-signed certificate to encrypt traffic.

IIS 7.0 supports several methods to install a SSL certificate including:

• Using the IIS Manager GUI.
• Using the Certificate Manager GUI.
• Web and Auto-enrollment.
• Using the appcmd command-line tool.
• Programmatically through Microsoft.Web.Administration using Windows Management Instrumentation (WMI) scripts.

For more information about how to install a SSL certificate, see the "How to Setup SSL on IIS7" article on the Microsoft Internet Information Services (IIS) Web site.

Installing the SSL certificate hardens your Web server configuration to a level that provides elevated security while ensuring that you can manage a functional feature set for the server.

Consider Additional Specialized Security Configuration Measures

For environments that require added security, there are a few additional measures that you can take to further harden the Web server. However, it is important to note that these steps do increase management overhead and can create Web application compatibly issues. It is very important to conduct thorough testing of your Web applications in a test environment before attempting to implement these recommendations on a production server.

To further secure your Web server installation, you might consider using the following features:

• Access control list (ACL) hardening. You can further limit access to your Web site by specifying particular users in the ACL for your content directory instead of allowing all domain users to access the site.
• If you want a more user friendly feature to limit access to your Web site, you can use the built-in IIS7 URL Authorization feature. For more information about this feature, see the "Understanding IIS7 URL Authorization" article on the Microsoft IIS Web site.
• The IPv4 Restriction Lists feature, which lets you restrict the IP addresses of the client browsers you allow to connect to the Web server.
• The Request Filtering feature, which lets you control many HTTP features, such as HTTP verbs, HTTP headers and URL size. For more information about this feature, see the "How to Use Request Filtering" article on the Microsoft IIS Web site.
• Client certificate mapping, which allows you to enforce strong authentication by requiring users to provide client certificates when requesting to access your site. For more information about this feature, see the "How to Setup SSL on IIS7" article on the Microsoft IIS Web site.

You can also change the site's identity by changing the Application Pool identity to a low privileged local account.

More Information

The following resources on Microsoft.com can provide you with further security best practice information about how to design and maintain Web servers:

• How to Setup SSL on IIS7.
• How to Use Request Filtering.
• Improving Web Application Security: Threats and Countermeasures.
• IIS 7.0: Configure Web Server Security.
• Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
• Windows Management Instrumentation.
• Windows Server 2008 Technical Library.
• Understanding IIS7 URL Authorization.