IIS 7.0 : Securing Configuration - Restricting Access to Configuration

Previous versions of IIS have used a centralized configuration store known as the metabase. IIS 7.0 abandons the metabase in favor of a new configuration system based on a hierarchy of XML configuration files, in order to provide for simpler deployment and more flexible management of the Web server.

In this section, we will take a look at the files that comprise the IIS 7.0 configuration hierarchy and how they are accessed. We will also review security best practices for limiting access to these files to ensure that the configuration contained therein is secure against unauthorized information disclosure and tampering. In addition, we’ll look at isolating the configuration between application pools that are using the new configuration isolation support.

Because the configuration is stored in plain text XML files, some of which may be taken off the server during deployment or otherwise exposed, it is sometimes necessary to protect the information stored therein from being discovered. The configuration system provides built-in encryption support to protect secrets stored in configuration files against disclosure even if an attacker is able to access the file. Later in this section, we’ll take a look at best practices for storing secrets in configuration files and using encryption to protect them.

The configuration file hierarchy goes beyond centralized configuration and includes distributed web.config configuration files access that can be delegated to the site or application owner. This enables sites and applications to contain required configuration as part of their content for single-step deployment that does not require administrative rights on the server. It also enables site and application owners to manage their applications remotely without having administrative rights. In this section, we will review the best practices for securely configuring configuration delegation.

Restricting Access to Configuration

IIS 7.0 configuration is stored in a hierarchy of configuration files, including both server-level configuration files and distributed web.config files that may be delegated to site and application owners. Because these files store configurations by using plain text XML, anyone with the ability to access them can read and/or tamper with a server configuration without using any additional tools or APIs. Therefore, the NTFS access permissions placed on these files determine who can access server configuration and what they can do with it.

To properly secure configuration files, it is important to understand the files that comprise the hierarchy and how they are accessed. This can help define and maintain the proper access strategy in your environment.

Note

The files that constitute the IIS 7.0 configuration hierarchy, and their default access permissions, are listed in Table 2.

Table 2. Default Access Permissions for Configuration Files

File	Description	Default Permissions
Framework machine.config	Machine-level .NET Framework configuration	BUILTIN\IIS_IUSRS:(RX) BUILTIN\Users:(RX)
Framework root web.config	Machine-level configuration for ASP.NET applications	BUILTIN\IIS_IUSRS:(RX) BUILTIN\Users:(RX)
applicationHost.config	IIS machine-level configuration	NT SERVICE\WMSvc:(R) NT SERVICE\WMSvc:(R)
.config	Auto-generated version of applicationHost.config for each application pool	IIS APPPOOL\:(R)
Distributed web.config (wwwroot)	Delegated configuration files in the Web site directory structure	BUILTIN\IIS_IUSRS:(RX) BUILTIN\Users:(RX)
administration.config	Machine-level configuration file for IIS Manager	NT SERVICE\WMSvc:(R)
redirection.config	Machine-level configuration file for configuring remote location of applicationHost.config	NT SERVICE\WMSvc:(R)

Note

The default permissions for all entries in Table 14-18 also contain permissions granting full rights to NT AUTHORITY\SYSTEM and BUILTIN\Administrators. These were removed from this table for clarity.

Looking at the default permissions lets you see that:

• The server-level configuration files, including Framework machine.config, Framework root web.config, applicationHost.config, administration.config, and redirection.config are writable only by the System and members of the Administrators group.

• All members of the Users group and the IIS_IUSRS group Framework can read machine.config and root web.config files. Unlike IIS server-level configuration files, any user on the machine—as well as any application running inside the IIS worker processes—can read the configuration in these files. This is due to the fact that these files are used to configure the behavior of .NET Framework components in any .NET application that runs on the machine.

• The IIS server-level configuration files, applicationHost.config, redirection.config, and administration.config, are only readable by the system, members of the administrators group, and the Web Management Service (NT Service\WMSvc). Unlike .NET Framework configuration files, they cannot be read by non-administrative users or even IIS worker processes. IIS worker processes receive a subset of configuration in the applicationHost.config file from the automatically generated ApppoolName.config files for each application pool.

• The Windows Process Activation Service (WAS) automatically generates the ApppoolName.config files for each application pool, which are readable only by the IIS worker processes in the corresponding application pool.
  

• The distributed web.config files located in the site directory structure are by default readable by members of the Users group. These files typically must also grant access to the IIS_IUSRS group to allow access to the IIS worker process (IIS setup automatically grants this for the default Web site root located in %SystemDrive%\Inetpub\Wwwroot).

Setting Permissions on Configuration Files

The configuration files in the IIS hierarchy have restrictive permissions configured by default and should typically not be changed (with the exception of distributed web.config files that are part of your site directory structure). Changes to the permissions on these files may cause these files to become more vulnerable to unauthorized access. Keep the following in mind to maintain the security of these files:

• Never grant non-administrative identities (with the exception of NT SERVICE\WMSvc) access to applicationHost.config, redirection.config, and administration.config (either Read or Write). This includes Network Service, IIS_IUSRS, IUSR, or any custom identity used by IIS application pools. IIS worker processes are not meant to access any of these files directly. See the following section titled “Understanding Configuration Isolation” for information on how IIS worker processes get the configuration from applicationHost.config.

• Never share out applicationHost.config, redirection.config, and administration.config on the network. When using Shared Configuration, prefer to export applicationHost.config to another location.

• Keep in mind that all users can read .NET Framework machine.config and root web.config files by default. Do not store sensitive information in these files if it should be for administrator eyes only. Encrypt sensitive information that should be read by the IIS worker processes only and not by other users on the machine.

The only exception to this rule is the distributed web.config files that are part of your Web site’s directory structure. It is up to you to ACL these files correctly to prevent unauthorized access to their contents.

Understanding Configuration Isolation

As mentioned earlier, IIS worker processes do not have Read access to applicationHost.config. How, then, are they able to read any of the configuration set in this file?

The answer lies in the configuration isolation feature provided by IIS 7.0, which is always on by default. Instead of enabling IIS worker processes to read applicationHost.config directly when reading the configuration file hierarchy, IIS generates filtered copies of this file and uses these copies as a replacement of applicationHost.config when configuration is read inside the IIS worker process.

The reason for doing this is to prevent IIS worker processes from application pool A to be able to read configuration information in applicationHost.config that is intended for application pool B. Because applicationHost.config may contain sensitive information, such as the user name and password for custom application pool identities, as well as user name and password for virtual directories, allowing all application pools to access applicationHost.config would break application pool isolation.

WAS is responsible for generating the temporary application pool configuration files that each IIS worker process uses as a replacement of applicationHost.config. These files are placed by default in the %SystemDrive%\Inetpub\Temp\Apppools directory and are named AppPoolName.config. As mentioned earlier, these files are configured to allow access only to the IIS worker processes in the corresponding application pool, by using the IIS APPPOOL\AppPoolName Application Pool SID.

Note

This process occurs automatically each time applicationHost.config is changed and therefore does not require any manual action from the administrator outside of normal configuration procedures.

Each application pool configuration file contains the configuration in applicationHost.config, with the following information removed:

• All application pool definitions in the system.applicationHost/applicationPools configuration section. Only WAS is required to read this configuration section.

• Any Web site definitions in the system.applicationHost/sites configuration section for sites that do not have applications in the current application pool.

• Any configuration in location tags for specific Web sites, applications, or URLs that do not reside inside the applications in the current application pool.

Caution

All application definitions (and their virtual directory definitions, possibly containing user name and password credentials) for any site that has at least one application in the current application pool will be present in the application pool configuration file. To disable this behavior and include only the application definitions for applications in the application pool, set the IsolationWholeSiteInclude DWORD value to 0 in the HKLM\System\CurrentControlSet\Services\WAS\Parameters key and perform an IISRESET. This may break applications in sites with applications in multiple application pools when they attempt to map physical paths for URLs in other applications.

Keep in mind that global configuration settings set in the applicationHost.config (without using location tags to apply them to specific Web sites, applications, or URLs) are not filtered. Each application pool configuration file will contain all of these settings.

Configuration isolation is a key part of the application pool isolation strategy in IIS 7.0. It is enabled by default to provide configuration isolation for server-level configuration in applicationHost.config.

Caution

Configuration stored in .NET Framework machine.config and root web.config files is not isolated. Only configuration stored in applicationHost.config is isolated.

Setting Permissions for Shared Configuration

IIS 7.0 supports sharing server configuration in the applicationHost.config configuration file between multiple Web servers on a Web farm. Using a shared configuration requires exporting the configuration from the source Web server, placing it on a network share, and configuring the share so that all member Web servers have access to it.

To prevent unauthorized access to the shared configuration, follow these guidelines:

• Do not grant Write access to the identity that the Web server uses to access the shared applicationHost.config. This identity should have only Read access.
  
  
• Use a separate identity to publish applicationHost.config to the share. Do not use this identity for configuring access to the shared configuration on the Web servers.
  
  
• Use a strong password when exporting the encryption keys for use with shared configuration.
  
  
• Maintain restricted access to the share containing the shared configuration and encryption keys. If this share is compromised, an attacker will be able to read and write any IIS configuration for your Web servers, redirect traffic from your Web site to malicious sources, and in some cases gain control of all Web servers by loading arbitrary code into IIS worker processes. Consider protecting this share with firewall rules and IPsec policies to allow only the member Web servers to connect.
  
  

Warning

Maintain restricted access to the share containing shared configuration. Malicious access to this share can cause complete Web server compromise.