IIS 7.0/7.5 Security: Application Pool Identities

Windows 2008 SP2 introduced to IIS 7.0 the use of Application Pool identities to help secure web resources and enhance web application performance.  This became the standard with Windows 2008 R2 and IIS 7.5. In my article regarding IIS 7.0/7.5 Best Practices, several items include the use of Application Pool identities in configuring both IIS and NTFS resources.  The steps and practices below should be used when configuring IIS according to best practices.

 

Default Application Pools stopped

As explained in the IIS 7.0/7.5 Best Practices article, there are up to four Application Pools that are created by the installation of IIS and the .NET Framework v4.0. These Application Pools can be exploited by malicious code since they are commonly known and well-documented default objects. Use the IIS Manager to stop or delete the default Application Pools.

 

 

Each site should use its own associated Application Pool

As part of the planning for your web site structure, you should have already figured out what you will name your web site in IIS. If you create an Application Pool with the same name as your web site, when you create the web site it will automatically associate itself with that Application Pool. Otherwise, when you create a web site it will associate itself with the DefaultAppPool.

Either way, it is preferable to create an Application Pool with the same name as the web site and associate it for use so that configuring resources and troubleshooting issues later will be easier.

 

Each Site Has Its Own Application Pool

 

Configure Anonymous Authentication to use the AppPoolIdentity

By default, when you create an Application Pool it will configure itself to use the IUSR account for anonymous authentication. The IUSR account is created during the IIS installation process. In order to isolate web site content and resources, it is important to configure the Application Pool to use the AppPoolIdentity.

 

 

NTFS Permissions and the AppPoolIdentity

The planning phase of your IIS web site should include creating a new folder on a disk separate from the system disk. This will help prevent your web site’s disk resources from interfering with operating system disk resources. The web site folder will, by default, inherit permissions from the parent folder – or the disk’s permissions if the folder is in the disk’s root.

The first step is to remove the web site root folder’s permission inheritance and set the folder to allow only the local Administrators group and the local SYSTEM account full control. You can then configure each site folder to give the web site’s AppPoolIdentity read-only permissions.

 

 

 

 

 

 

 

 

Properly configured Application Pools in IIS 7.0 and IIS 7.5 can greatly enhance your web server’s security. Making these best practices a standard in your web server environment can help you provide your company with a good security framework. But security doesn’t stop here. As a Windows Systems Administrator (SysAdmin), your responsibility is to ensure security throughout your server environment and the steps here are provided to give you a starting point.

 

REFERENCES

CIS Microsoft IIS 7.0 Benchmark v1.1.0
Ensure Security Isolation for Web Sites
Application Pool Identities

IIS 7.0/7.5 Best Practices

At the time of writing this article, there are no “official” security best practices guidelines posted by Microsoft for IIS 7.0 or IIS 7.5.  Much of the documentation for any IIS security hardening has come from common sense and experience by IT personnel working with IIS technologies, and as such is considered unofficial. Security guidelines for IIS 7.0 and IIS 7.5 should reflect the minimal standards set out by Microsoft for IIS 6.0.

I’ve found that the settings below are the minimum best practice standards for IIS 7.0/7.5:

1. Default Web Site stopped
2. Default application pools stopped
3. Each site should use its own associated Application Pool
4. Each site should have Anonymous Authentication configured to use the AppPoolIdentity
5. Web root directory should be on a disk separate from the default IIS installation directory (ie. D:\wwwroot)
   • D:\wwwroot NTFS permissions = SYSTEM, Administrators (Full); folder set to not inherit permissions
   • D:\wwwroot\* (ie. D:\wwwroot\website1) NTFS permissions = AppPoolIdentity (Read); folder set to inherit permissions (default)
6. Log files @ D:\Logs
   • D:\Logs compressed
   • D:\Logs contents not indexed
7. 301 redirects for all redirected content
   • Configure domain.com canonical URL redirect to http://www.domain.com with the URL Rewrite module

IIS site bindings:

1. http://www.website.com, port 80, dedicated IP address AND cluster IP address (if in Microsoft NLB cluster)
2. website.com, port 80, dedicated IP address AND cluster IP address
3. http://www.website.com, port 80, dedicated IP address
4. Cert and instructions @ D:\certs

(NOTE: The D:\wwwroot folder is not the C:\inetpub\wwwroot folder that gets created with IIS installation.  This folder contains ONLY deployed web site folders and their content. The Default Web Site content remains in C:\inetpub\wwwroot.)

 

Why?

Ok, it’s one thing to say these are good practice, but knowing why is an entirely different thing.  Some of the above are obvious, others not so much.  Below is the list of reasons for why the settings above are considered best practice.

1. The Default Web Site and its location are created during the IIS installation process. It is best practice not to install new files or data in commonly known default program locations in case of network or system compromise. Hacking tools and utilities are almost always designed to scan default locations to begin their attacks.
   
   If you decide to install the admin tools for IIS, they will install in the Default Web Site. Other applications that integrate with IIS, like SharePoint, will also install their admin tools in the Default Web Site. In the event of network or system compromise, these admin tools can be used to harvest sensitive data.
   
   For these reasons it is best not to install web site files in the Default Web Site or the C:\inetpub\wwwroot folder.
    
2. There are two application pools that get created by a default IIS installation. When you install the .NET Framework v4.0 in IIS two more application pools will appear. These are created by default by the .NET Framework v4.0 installation. Stopping all default application pools will isolate your web sites from default installation sources that malicious code writers so often utilize to access sensitive data and/or code.
    
3. Web sites utilize application pools for traffic control, network and server resource access, and for securing web content. The server instantiates a new worker process for each application pool. Having multiple web sites run in the same application pool increases the probability that a malfunction in one web site will cause the other sites in the pool to malfunction. Also, since the web sites in the application pool all use the same identity, in the event that a network or system is compromised and a single web site is hacked, the application pool identity credentials may be used to access code in all web sites associated with the pool.
   
   For these reasons it is best to create separate application pools for each web site.
    
4. A default IIS installation creates the IUSR user account that is used, by default, for anonymous authentication of each web site’s content. Since an application pool creates a virtual user account that serves as the application pool identity, configuring the web site to use the pool identity for anonymous authentication further secures web site content by preventing use of a commonly known and well documented default user account.
    
5. See reasons in #1 for securing web content on a separate drive and folder location. The other rules for NTFS permission configuration will further prohibit cross-web site content access in the event of a network or system compromise that attacks a single web site.
    
6. IIS log files contain content that can be particularly attractive to a malicious attacker. Again, moving the log folder to a location other than the default installation location is best practice. Log files are only text files and can therefore be compressed to save disk space and should have a cleanup maintenance schedule so they do not fill up the disk they reside on. For performance and security reasons, log file content should also not be indexed.
    
7. Web sites are configured to listen on all unassigned interfaces by default. In the event of a network or system compromise, a hacker may merely use the local loopback address (localhost, or 127.0.0.1) to find web site content and access they desire. Binding the web site to a specific IP address makes this more difficult.
   
   A web site should have both http://www.website.ext and website.ext specified for the publicly accessible content interface. If both are not specified, IIS will not know how to route traffic properly for the header that is not configured. For example, http://www.website.ext is configured on the interface. The user types website.ext to get to the web site. IIS will not know how to route the traffic and will most often respond with a 404 error.
   
   In a Microsoft NLB cluster, the server’s dedicated IP address should also have at least one header entry for testing while removed from cluster during change deployments.
    
8. Configuring 301 redirects is a SEO method for IIS. Utilize the built-in HTTP-Redirect module in IIS 7.5 for directory and/or page URL redirection. Use URL Rewrite for canonical domain name redirection.
    

REFERENCES

IIS 6.0 Security Best Practices (IIS 6.0)
Hardening guide for IIS 7.5 on Windows 2008 R2 server core platform
Redirection SEO Best Practices
URL Rewrite
CIS Microsoft IIS 7.0 Benchmark v1.1.0