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
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
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.
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
|Framework machine.config||Machine-level .NET Framework configuration||BUILTIN\IIS_IUSRS:(RX)
|Framework root web.config||Machine-level configuration for ASP.NET applications||BUILTIN\IIS_IUSRS:(RX)
|applicationHost.config||IIS machine-level configuration||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)
|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)|
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
Looking at the default permissions lets you see that:
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.
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.
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.
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
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:
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.
share out applicationHost.config, redirection.config, and
administration.config on the network. When using Shared Configuration,
prefer to export applicationHost.config to another location.
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
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.
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.
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.
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.
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.
configuration in location tags for specific Web sites, applications, or
URLs that do not reside inside the applications in the current
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.
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.
stored in .NET Framework machine.config and root web.config files is
not isolated. Only configuration stored in applicationHost.config is
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
- 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.
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.
restricted access to the share containing shared configuration.
Malicious access to this share can cause complete Web server compromise.