Executive Summary:
| Microsoft Internet Information Services (IIS) 7.0 includes four new security features called componentization, feature delegation, URL authorization, and request filtering. To reduce Microsoft IIS 7.0's attack surface, Microsoft broke the Web server into a set of component modules. Feature delegation lets Web server administrators delegate the configuration of certain features to a Web site or application owner. The URL authorization feature lets you define access to a Web site by linking permissions to the Web site's URL. Request filtering can be configured only from the Microsoft IIS 7.0 configuration files. |
Windows Server 2008 (formerly code-named Longhorn) includes the latest version of Microsoft's Web server, IIS 7.0. At the time of this writing, Microsoft had released Server 2008 Beta 3 and was planning to launch Server 2008 on February 27, 2008. IIS 7.0 is also included in the Home Premium, Professional, and Ultimate editions of Windows Vista.
Overall, the changes in IIS 7.0 are less fundamental than the changes Microsoft made in IIS 6.0, which is the version that's bundled with Windows Server 2003. IIS 7.0 builds on IIS 6.0’s architecture, but it adds quite a few new security features. Several of these features better integrate into the Web server security functionality that was previously added by using the IIS 6.0 Resource Kit Tools or other tools. Microsoft also added security features to IIS 7.0 that have been available for quite some time in IIS’s main competitor, the Apache HTTP Server. This article will focus on four of IIS 7.0's new and important security features: componentization, feature delegation, URL authorization, and request filtering.
Componentization
IIS 7.0 includes two major security changes that greatly reduce the IIS attack surface. First, the Web server isn’t installed by default when you install a Windows 2003 server. Also, IIS 7.0 is locked down by default when installed. Previous IIS versions require you to run the IIS Lockdown Tool after installation to lock down the Web server.
To further reduce the attack surface in IIS 7.0, Microsoft introduces componentization. Microsoft broke down the IIS 7.0 Web server into a set of modules, each of which implements a piece of Web server functionality. Previous IIS versions have a monolithic architecture, although they let you enable and disable support for certain Web server extensions (e.g., Active Server Pages—ASP, ASP.NET). For example, an IIS 6.0 or IIS 5.0 Web server installation always provides all IIS authentication methods, even if your Web site requires only anonymous access.
However, when you do a fresh installation of IIS 7.0, Windows installs only a bare minimum of modules that enables the Web server to serve only static Web content to only anonymous users. If you want your IIS 7.0 Web server to provide additional services, you must explicitly add them. For example, Web server administrators might want to enable support for dynamic content (e.g., ASP, ASP.NET, Common Gateway Interface, Internet Server API extensions), add support for other authentication methods (e.g., basic authentication, digest authentication), or add one of the IIS management tools (e.g., the Microsoft Management Console—MMC—IIS snap-in, IIS management scripts).
Componentization has several interesting advantages. First, componentization lets organizations create fully customized Web servers that include only the services that they need. Componentization also reduces organizations’ total cost of ownership for maintaining their Web servers. Also, thanks to componentization, you don't have to install all IIS 7.0–related security patches because you have to patch only the services that are installed on your Web servers.
You can select the components that you want to make available on your IIS 7.0 Web server from the Role Services page of the Add Roles Wizard during the installation of the Web server. Once the Web server has been installed, you can add or remove components using Role Services in Server Manager, which is shown in Figure 1. Note that Server Manager also provides a command-line utility (ServerManagerCmd.exe) that lets you automate the installation of IIS components.
The components that are installed on your Web server are referred to in IIS 7.0’s main configuration file—ApplicationHost.config—which is located in the %systemdrive%/windows/system32/inetsrv/config folder. If you're familiar with XML and the structure and syntax of the IIS 7.0 ApplicationHost.config file, you can also edit this file directly to add or remove IIS components. However, given the critical role of the ApplicationHost.config file, I don't recommend editing this file directly. If you decide to edit ApplicationHost.config, make a copy of the original file first.
It’s important to note that IIS 7.0 no longer uses the metabase configuration database (except for maintaining IIS 6.0 metabase compatibility for legacy applications). Instead, all IIS 7.0 configuration data is now stored in XML-formatted configuration files. The most important configuration files are the ApplicationHost.config file, which is IIS 7.0’s main configuration file for storing Web server configuration settings, and the web.config file, which contains Web site and application-specific configuration settings.
Another IIS 7.0 security feature that can significantly reduce the Web server’s attack surface is its support for the Server 2008 Server Core. Server Core is a new Server 2008 installation option that provides a minimal Windows server installation. Server Core ensures that only the functionality that’s actually needed to run a Windows server is installed. Server Core doesn't include applications such as Microsoft Internet Explorer or any of the Windows installation wizards. Also, Server Core doesn't include the classic Windows Explorer UI; instead, Server Core must be managed from the command line. The version of Server Core that’s bundled with Server 2008 also doesn’t support managed code, so you won’t be able to run ASP.NET and .NET Framework-based Web applications on a Server Core IIS Web server.
Feature Delegation
Because server consolidation has become a popular practice, powerful administrative delegation features have become indispensable. Administrative delegation is important because in many Web server environments, there’s a clear separation of duty between the people who administer the Web server and take care of its day-to-day operation and maintenance, and the people who own the Web site’s data and maintain the applications that are hosted on the Web server.
In IIS 5.0, Microsoft introduced the Operators tab, which let IIS administrators delegate the administration of a Web site to one or more Web site operators. However, Web site operators are fairly limited in what they can do, so most IIS administrators end up adding their Web site operators’ accounts to the local Administrators group. In IIS 6.0, Microsoft acknowledged this practice by getting rid of the Operators feature and introducing metabase ACLing for locking down Web site administrators’ metabase permissions. Microsoft provides two tools for changing metabase permissions: the Metabase Explorer, which is part of the IIS 6.0 Resource Kit Tools, and the metaacl.vbs Visual Basic (VB) script, which is bundled in an executable called metaacl.exe. However, metabase ACLing is a limited solution for the broader delegation problem, and it certainly doesn’t resolve the problem of requiring local Administrators group membership for operating a Web site.
IIS 7.0 includes a new feature called feature delegation, which provides a rich and easy-to-set-up delegation experience. Feature delegation lets Web server administrators delegate the configuration of certain features, such as authentication, default documents, or directory browsing settings, to an individual Web site or application owner. Feature delegation doesn’t require the delegated administrator to be a Windows administrator, and end users can be delegated IIS administrative permissions. Contrary to other Windows delegation models, feature delegation doesn’t leverage the classic Windows permission and ACL model for setting and enforcing delegation settings; instead it uses a set of special permissions that are written to the XML-formatted IIS 7.0 configuration files.
To set up feature delegation from IIS 7.0 Manager, use the Feature Delegation option in a Web server’s or Web site’s management section. Figure 2 shows the default delegation state as it’s defined on the IIS 7.0 Web server level.
The Features view contains a list of configuration items that can be delegated to Web site and application owners. Each configuration item is assigned a Not Delegated, Read Only, or Read/Write permission. If a configuration item is assigned the Not Delegated permission, Web site administrators can't see or change the item. If a configuration item is assigned the Read Only permission, it will be visible to Web site administrators but will be locked so that Web site administrators can't change it. If a configuration item is assigned the Read/Write permission, Web site administrators can make changes to it.
As I mentioned, the delegation shown in Figure 2 is the default state that applies to all Web sites and applications hosted on the Web server. If you want to change this default state for a particular Web site to give the Web site’s administrator more or less control, you must use the Custom Web Site Delegation link in the Actions pane of IIS Manager. If you use this link, IIS Manager shows a configuration screen similar to the one in Figure 3. From the Sites drop-down box, you can select the Web site for which you want to define custom delegation settings.
URL Authorization
If you've worked with IIS before, I'm sure you've been annoyed by the complexity of setting up and troubleshooting access control for Web resources. You have to take into account not only the Web server–specific permissions (e.g., the Read/Write permissions configurable from the Home Directory tab in an IIS 6.0 or IIS 5.0 Web site’s properties dialog box) but also the NTFS-level permissions. Also, your access control problem typically isn’t a permission problem but rather an authentication problem.
IIS 7.0 supports an access control feature that's referred to as URL authorization. URL authorization lets you easily define access to a Web site by linking a set of permissions to the Web site’s URL without having to juggle other IIS or NTFS permissions. IIS 6.0 provides a similar feature, but this feature isn't well integrated with the Web server and requires a complex manual setup procedure.
URL authorization can be configured from the Authorization Rules configuration section, which can be found under the Features view of the Web server or Web site. In the Authorization Rules interface, you can configure simple Allow and Deny rules for specific Windows user accounts, groups, or ASP.NET roles to control access to a Web site’s URL. The Allow or Deny rules can also be fine-tuned based on the use of particular HTTP verbs.
To see how easy it is to set up access restrictions for a Web site using URL authorization, I recommend following this simple example: Create two Windows user accounts, Alice and Bob. Remove the default Allow rule for All Users on the IIS Default Web site, create an Allow rule for Alice, and create a Deny rule for Bob. Doing so should result in a configuration screen similar to the one shown in Figure 4. Then try to access the default Web site—first using Alice’s account and then using Bob’s account.
I also recommend taking a look at the resulting web.config file entries for the authorization rules that are set up in the Alice and Bob example. The configuration file content shown in Figure 5 illustrates how easy it is to define authorization rules directly in a Web site’s configuration file without going through the IIS Manager interface. Also note that these rules can easily be transferred to another Web server (which can be helpful when setting up a Web farm) by simply copying the application’s web.config file to the other Web server.
Request Filtering
Request filtering is the IIS 7.0 equivalent of IIS 6.0 and IIS 5.0's add-on URLScan tool. URLScan checks the URLs of all incoming Web server requests. In the past, many attacks against Web servers consisted of sending a URL to the server that contained a string that could be taken by the Web server as an instruction to execute a malicious command. If a URL contains suspicious character combinations, strings, or verbs, or if it exceeds a certain length, URLScan automatically blocks the associated Web request.
Although IIS 6.0 provides built-in URLScan-like functionality, many Web site administrators still add the URLScan tool to their IIS 6.0 Web servers because URLScan supports additional features such as the ability to remove server identity headers and support for a single unified text-based configuration file (urlscan.ini). IIS 7.0 includes the URLScan features out of the box, so it's no longer necessary to implement URLScan.
Request filtering supports the filtering of hidden namespaces, request filtering–specific error and status codes, and the definition of Web site and URL-specific request filtering settings. Hidden namespaces define critical Web server content that can’t be requested in a URL even if it’s present on the server. For example, IIS 7.0 defines the following important files and folders as hidden namespaces by default: the Web.config file and the \App_Data and \Bin folders. Request filtering–specific error and status codes let Web administrators quickly identify why IIS’s request filtering–logic rejects certain Web requests. In IIS 7.0, Web site administrators can define a different request filtering behavior for each individual URL and Web site. In IIS 6.0, the settings defined for URLScan are applied to all incoming Web server requests independent of the target URL or Web site. Table 1 compares URLScan and the request filtering functionality and shows the request filtering–specific error and status codes IIS 7.0 logs when it rejects a request based on a request filtering rule.
Unlike the other IIS 7.0 security features, request filtering can't be configured from the IIS Manager interface, only from the IIS 7.0 configuration files. Use the ApplicationHost.config file to set request filtering rules that you want applied to all the Web sites hosted on your IIS 7.0 Web server. To set Web site–specific request filtering rules, use the web.config file. The Microsoft article "How to Use Request Filtering" (http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Configuring-Security/Configuring-Request-Filtering/How-to-Use-Request-Filtering) describes in detail how to set up request filtering.
IIS 7.0 Security
Componentization, feature delegation, URL authorization, and request filtering are the main security features of Microsoft’s new Web server. If you install and play around with IIS 7.0, you’ll quickly discover many other security-related changes. Many Microsoft and third-party application servers leverage IIS, which is a great reason to become familiar with IIS 7.0 and its new security features now.
