Securing 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.

Note You can learn more about the new IIS 7.0 configuration system in Chapter 4, "Understanding the Configuration System."

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 builtin 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.

Note For more information about enabling and securing remote delegated management, see Chapter 8.

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 You can learn about the configuration file hierarchy, the locations of each file, and their role in configuring the server in Chapter 4.

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

Table 14-18 Default Access Permissions for Configuration Files

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 application-Host.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. This is the basis of configuration isolation explained in the section titled "Understanding Configuration Isolation" later in this chapter.
• 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 (see the section titled "Setting Permissions for Shared Configuration" later in this chapter).
• 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. You should follow the standard guidance for setting permissions for your Web site content provided in the section titled "Setting NTFS Permissions to Grant Minimal Access" earlier in this chapter, including using application pool isolation to properly restrict access to the application pool to which the application belongs and setting required permissions to allow remote delegated administration through IIS Manager.

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. For strategies on achieving proper application pool isolation, see the section titled "Isolating Applications" earlier in this chapter.

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. The process of doing this is explained in Chapter 4.

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.

For more information on setting up shared configuration, see Chapter 4.

Securing Sensitive Configuration

The information in the configuration files in the IIS 7.0 configuration hierarchy is protected by the restricted permissions specified by the NTFS ACLs on each file. These permissions should prevent unauthorized users from being able to access these files. For more information on maintaining secure permissions on the configuration files, see the section titled "Restricting Access to Configuration" earlier in this chapter.

However, this alone may not provide a sufficient level of protection for especially sensitive information stored in configuration files, such as user names and passwords of custom application pool identities. It is essential to prevent this information from being discovered even if an attacker manages to compromise the local Web server and gain access to the configuration file containing the information. In addition, if someone copies the configuration file off the server for archival or transport reasons, an attacker should not be able to read the secrets stored in the configuration file. To ensure this, IIS 7.0 provides the ability to encrypt specific information stored in configuration.

Using Configuration Encryption to Store Configuration Secrets

IIS 7.0 configuration encryption works by encrypting the contents of configuration attributes for which encryption is enabled before storing their values in the configuration file. Therefore, even if someone obtains access to the file, they cannot read the contents of the attribute without decrypting it first.

Whether or not configuration encryption is used for each attribute is determined by the attribute's definition in the schema of the containing configuration section. You can find more information about how encryption is configured in the configuration section schema in the section titled "Protecting Sensitive Configuration Data" in Chapter 13, "Managing Configuration and User Interface Extensions." The schema also serves as a mechanism to select the encryption provider used to encrypt the data for this attribute (you can learn more about available encryption providers in the following section titled "Selecting Encryption Providers").

When any configuration tool or API writes the value of each encrypted attribute, the configuration system will automatically encrypt it using the configured encryption provider before persisting it to the configuration file on disk. If you inspect the resulting configuration file, you will see the encrypted value, as shown in the following code example for the password attribute in the application pool definition inside the system.applicationHost/applicationPools configuration section.

<applicationPools> 
    <add name="MyAppPool"> 
        <processModel identityType="SpecificUser" userName="TestUser" 
password="[enc:IISWASOnlyAesProvider:N8mr4dLU6PnMW5xlmCWg6914cKePgeU0fTbxew 
ZppiwyTLmBQh0mZnFywQO78pQY:enc]" /> 
    </add> 
</applicationPools>

The configuration system decrypts the attribute automatically when it is accessed, provided that the caller of the configuration system has the rights to use the encryption provider used to perform the encryption. Therefore, the decryption and encryption process is completely transparent to the administrator, while ensuring that the resulting configuration is not stored in plain text.

Selecting Encryption Providers

IIS provides several encryption providers that can be used to encrypt configuration, in addition to several encryption providers provided by the .NET Framework. One of these providers is used for each configuration attribute that is marked for encryption. The providers are listed in Table 14-19.

Table 14-19 Configuration Encryption Providers

.NET Framework creates both the RsaProtectedConfigurationProvider and the DataProtection-ConfigurationProvider providers. These providers are primarily used to encrypt .NET configuration for ASP.NET applications using the Aspnet_regiis.exe tool. For more information on using the .NET Framework configuration encryption, see https://msdn2.microsoft.com/en-us/library/53tyfkaw.aspx.

Note You cannot use IIS configuration encryption to encrypt .NET configuration sections. Likewise, you cannot use .NET configuration encryption to encrypt the contents of IIS configuration sections with Aspnet_regiis.exe. If you attempt to read .NET configuration sections encrypted with .NET configuration encryption by using IIS configuration APIs, you will receive an error, because IIS does not support section-level encryption used by the .NET Framework configuration system.

You can use the IIS encryption providers—IISWASOnlyRsaProvider, IISWASOnlyAesProvider, and AesProvider—to encrypt IIS configuration sections.

IISWASOnlyRsaProvider and IISWASOnlyAesProvider are both used to encrypt configuration sections that WAS reads, such as the system.applicationHost/applicationPools section, and do not allow IIS worker processes to decrypt the configuration. The IISWASOnlyAesProvider provides better performance because it uses AES encryption using an RSA encrypted session key, instead of using full RSA encryption, and is used by default. The session key itself is encrypted using the RSA key container used by IISWASOnlyAesProvider, so it has the same access requirements. Configuration attributes encrypted using these providers can only be decrypted by SYSTEM and members of the Administrators group.

The AesProvider provider is an AES provider that uses a session key encrypted using an RSA key container that has permissions for the IIS_IUSRS group, therefore allowing IIS worker processes to encrypt and decrypt configuration encrypted with this provider. This is the provider used by default by all IIS configuration sections that are read by IIS worker processes. It is also the provider you should consider using to protect your custom configuration sections. Configuration attributes encrypted using this provider can be decrypted by any IIS application.

Note The IIS configuration system does not support pluggable encryption providers unlike the .NET configuration system. However, you can configure new instances of the IIS configuration provider types to use different key containers for encryption purposes.

You can also create additional instances of the RSA and AES providers by creating new entries in the configProtectedData configuration section, and configure them to use new RSA key containers. You can create new RSA key containers by using the Aspnet_regiis.exe pc command, as described at https://msdn2.microsoft.com/en-us/library/2w117ede.aspx.

You can then manipulate the permissions on the RSA key to determine who can use it to encrypt and decrypt configuration by using the Aspnet_regiis.exe –pa and Aspnet_regiis –pr commands.

Keep in mind the following guidelines when using encryption:

• Configuration encrypted with IISWASOnlyAesProvider can only be decrypted by members of the Administrators group. This provider is only used to encrypt configuration read exclusively by WAS.
• Configuration encrypted using AesProvider can be decrypted by any IIS application. It can be used to protect configuration from being disclosed outside of the Web server, but it is not a way to protect configuration from applications running on the Web server. It also does not protect configuration used by one application pool from another application pool (although this protection may be afforded by proper NTFS permissions configured for application pool isolation).
• If you require to encrypt configuration for each application pool as an additional isolation measure, you should create separate RSA keys for each application pool identity and ACL them for that application pool using the Application Pool SIDs or custom application pool identities. Then you can create a provider for each application pool, using the corresponding RSA keys, and encrypt the configuration for each application pool using the corresponding provider.
• In order to share a configuration on a Web farm or deploy an application with a encrypted configuration to another server, you must share encryption keys and provider definitions between the original server on which encryption was performed and the target server. When exporting encryption key containers, be sure to use a strong password and protect these keys from being accessed by unauthorized users. You can learn more about exporting encryption keys here: https://msdn2.microsoft.com/en-us/library/2w117ede.aspx. In addition, you can export encryption keys by using IIS Manager when setting up shared configuration. For more information, see Chapter 4.

Caution Changing the permissions on the RSA key containers may lead to compromise of the encryption keys and therefore may expose your encrypted configuration. Do not change the default permissions on the built-in IIS RSA key containers.

Limitations of Storing Secrets in Configuration

When you store secrets in configuration, the secret is protected by both the NTFS permissions on the configuration file (see the section titled "Restricting Access to Configuration" earlier in this chapter) and configuration encryption, if configured. However, you should be aware of the following limitations that may impact the security of your secret:

• NTFS permissions provide the basic level of protection for secrets in configuration files. However, when configuration files are archived, copied off the machine, or sent over a network, this protection is lost. Always use encryption to provide protection for secrets in these cases.
• Any code in the IIS worker process can decrypt any encrypted configuration data that the IIS worker process has access to. By default, any IIS worker processes can decrypt any configuration data encrypted using the default IIS encryption provider (AesProvider).
• Encryption is only as secure as the key that is used to perform the encryption. Therefore, be sure that only the users authorized to perform decryption have access to the key container used to perform the encryption and make sure that this key container is not compromised if it is exported off the machine.

Limiting Access to Configuration from Managed Code in Partial Trust Environments

When accessing IIS configuration from native code, the permissions set on the configuration files are the basis for determining whether or not access to the configuration is granted. Native modules and other code running in the IIS worker process can therefore read any of the configuration in the configuration file hierarchy that is not hidden by application pool isolation or encrypted with encryption keys that the IIS worker process does not have access to.

However, when managed code modules access configuration using the Microsoft.Web. Administration API, their ability to read some configuration sections can be further constrained through Code Access Security (CAS) policy configured for the application. This is similar to how CAS is used to prevent managed code applications from performing other actions that the hosting process may otherwise be allowed to perform, such as accessing files or opening network connections.

You can leverage this mechanism to prevent ASP.NET applications running in partial trust from being able to access information from certain configuration sections. This is done by setting the requirePermission attribute on the section declaration to true. When this is done, only ASP.NET applications and managed modules running with Full Trust can read the contents of these configuration sections. For more information on setting the requirePermission attribute as part of the section declaration process, see the section titled "Declaring Configuration Sections" in Chapter 13.

Note The requirePermission attribute only prevents the application from using the configuration APIs to read the configuration section when in partial trust. The application can still access the file directly, if the CAS policy and file permissions allow it. Because of this, requirePermission is only effective at preventing medium or below trust applications from reading the contents of configuration sections specified outside of the application's directory structure, such as in applicationHost.config. The application can still open the distributed web.config files in its directory structure by using file IO APIs directly.

By default, no IIS configuration sections are declared with requirePermission set to true, so the contents of IIS configuration sections can be read by partial trust applications. So, this technique is more applicable to new configuration sections being declared.

For more information on using ASP.NET trust levels to constrain the execution of managed modules and ASP.NET applications, see the section titled "Reduce Trust of ASP.NET Applications" earlier in this chapter.

Controlling Configuration Delegation

One of the key management scenarios that the IIS 7.0 configuration system has in mind is configuration delegation. Configuration delegation refers to the ability of the Web site or application owner to specify the required IIS configuration for their application without being an administrator on the Web server computer. To allow this, the IIS 7.0 configuration file hierarchy supports specifying configuration in distributed web.config files, which can be located anywhere in the Web site's directory structure to override the configuration specified at the server level. This also allows Web sites and applications to become portable by including all of the configuration files necessary alongside their content, so they can be deployed by simply being copied to the Web server.

If configuration delegation was an all or nothing approach, it likely wouldn't work, because most Web server administrators would not want to allow the Web site or application to be able to override all of the configuration set at the server level, especially for configuration sections that affect security, reliability, and performance of the Web server. Therefore, the IIS 7.0 configuration system provides an extensive set of controls that server administrators can use to determine which configuration sections, and further yet, which specific configuration attributes, can be overridden at the Web site or application level. If you manage a Web server that allows others to publish application content, you will likely need to review the configuration allowed for delegation, and in some cases lock or unlock specific configuration for delegation.

Further, IIS 7.0 also provides the infrastructure for Web site and application administrators to manage their configuration remotely through IIS Manager, without having administrative privileges on the Web server computer. Again, as a server administrator, you have fine-grained control over who can manage the Web sites and applications on your computer remotely, and what management features they can use. You can learn more about configuring remote management permissions in Chapter 8.

Controlling Which Configuration Is Delegated

The configuration section is the basic unit of configuration delegation. By default, each configuration section is marked to initially allow or deny delegation when it is first declared, by specifying the overrideModeDefault attribute in the section declaration (this is typically determined by the developer based on whether the section is considered sensitive and should not be modifiable by non-Administrators by default). If the section is marked as not delegated, any attempt to specify the configuration for this section at any lower level in the configuration hierarchy will lead to a configuration error when this section is accessed.

Note You can learn more about declaring configuration sections and the overrideMode-Default attribute in the section titled "Declaring Configuration Sections" in Chapter 13.

By default, all IIS configuration sections are declared in applicationHost.config. Each section declaration specifies whether or not this section is available for delegation, based on the Microsoft IIS team's criteria for whether or not the configuration section is sensitive. This criteria includes considerations of whether the configuration section can be used to weaken the security, reduce reliability, or significantly impact the performance of the Web server overall, or allow the Web site or application to access information outside of its boundaries.

Note You can also manage the delegation of .NET configuration sections using the IIS administration stack. Both IIS and .NET configuration use the same mechanism for controlling delegation, including section-level locking and fine-grained configuration locking. For more information, see Chapter 4.

The default delegation of IIS configuration sections is shown in Table 14-20.

Table 14-20 Default Delegation of IIS Configuration Sections

The default delegation state for IIS configuration sections is just that—a default—and may not work for everyone. If you allow third parties to publish Web site or application configuration on the server, you will need to review the impacts of allowing each section to be delegated and strike a balance between application requirements for delegation and the need to protect the Web server from unintended or malicious configuration changes. Then, you can lock or unlock configuration sections to allow them for delegation or even use fine-grained configuration locking to allow section delegation but lock specific configuration attributes, elements, or collection entries.

Note For information about how to lock and unlock sections, and use fine-grained configuration locking, see the "Delegating Configuration" and "Granular Configuration Locking" sections in Chapter 4.

When determining which configuration should be delegated, keep the following guidelines in mind:

• Err on the side of leaving configuration sections locked at the server level and unlock specific sections as needed by the application. You can also unlock specific sections for specific Web sites or applications only and leave them locked for others. This is an effective method to avoid unexpected configuration changes at the application level even if you do not delegate configuration to other parties.
• When unlocking a specific section, you can still lock parts of it that contain sensitive configuration or configuration you do not want to be changed. Use fine-grained configuration locking to lock the attributes, elements, or collection elements that you don't want changed while allowing other parts of the configuration section to be delegated.

< Back      Next >

 

 

© Microsoft. All Rights Reserved.