Chapter 6: Hardening Web Services
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:
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.
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:
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
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.
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:
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.
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:
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.
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 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:
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.
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.
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.
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.
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.
%windir%\system32\inetsrv\appcmd set config -section:anonymousAuthentication -enabled:false
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:
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 184.108.40.206, then 220.127.116.11, 18.104.22.168, 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
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:
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
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:
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
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.
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.
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:
You can also change the site's identity by changing the Application Pool identity to a low privileged local account.
The following resources on Microsoft.com can provide you with further security best practice information about how to design and maintain Web servers: