Home > IIS > IIS 7.0/7.5 Best Practices

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
 

Advertisements
  1. February 6, 2013 at 10:30 pm

    Your personal article, “IIS 7.0/7.5 Best Practices
    AdminSpeak” was in fact well worth writing a comment here!
    Merely needed to mention you really did a tremendous job.
    Thanks a lot -Wilma

  2. February 8, 2013 at 5:11 am

    Hello,
    Thanks for the great articles on securing IIS.
    Currently I am working on an IIS server with a couple dozen sites which are all using the default application pool. The server is running ASP, ASPX, and PHP. If I were to follow the guides to create separate application pools for each site could you foresee any potential trouble I may encounter, or would you expect it to work properly?
    Thanks in advance.
    Chris

  3. Gareth
    August 10, 2013 at 1:14 pm

    Really good article – good work and much appreciated.

  4. January 21, 2014 at 12:24 pm

    I do believe all the ideas you’ve presented to your post.
    They’re really convincing and can definitely work.
    Still, the posts are too quick for beginners. May you
    please lengthen them a bit from subsequent time? Thanks for the
    post.

  5. June 3, 2014 at 7:25 am

    I just like the helpful info you supply on your articles.
    I will bookmark your blog and check once more right here frequently.
    I’m rather sure I will be told plenty of new stuff right right here!
    Good luck for the next!

  1. December 27, 2011 at 9:30 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: