Installation | Tobin Titus

This topic has been covered many times both by Microsoft and non-Microsoft employees. However, I’ve recently been asked what the main features of IIS 7 are and have seen a great deal of misinformation about IIS security on twitter, blog posts and forums.

I think, therefore, the issue deserves yet another look. In this post, I’m going to go over security in the past for IIS and then move on to talk about security features in IIS 7. These are not in any particular order. This post is not meant to diminish the many thoughtful works already created by others – both complimentary and critical. This is just meant to bring the subject back up for discussion again in hopes that you can be properly equipped with the decision making information you may need.

Ghosts of IIS Security Past

The reason for so much misinformation about the current state of security in IIS is likely due to the earned reputation the product had in versions previous to IIS 6.0. A quick search on the web for IIS 5 security vulnerabilities may be like a walk down memory lane for some of the more veteran administrators and IT staff across the globe. The search results are littered with critical vulnerabilities related to buffer overflows, ISAPI extensions, exploits on rarely-used features, or features that were available by a default installation. We are haunted by names like “Code Red” and “Nimda”. I don’t know about you, but those very names send shivers down my spine. I was consulting as a developer and web administrator for a very large property management company when these hit. We were lucky enough to avoid these as we had patched our services. That said, many whom I did business with on a regular basis were not very happy. So, to be clear, I feel the misinformation that is spread today is built on an element of experience with previous versions. Secunia reports 16 advisories and 6 vulnerabilities with IIS 5. And so started the reputation , perhaps deservedly so, that IIS was not secure unless you really knew what you were doing with security.

Bill Gates was apparently visited by the ghosts of security past, present and future when he laid his head on his pillow January 14th, 2002. I say that because on January 15th, 2002 Mr. Gates sent out the now-famous trustworthy computing memo to every employee at Microsoft. This set off a major revamp of products from the ground up. Standards were set for test planning and testing. Writing Secure Code was mandatory reading for every Microsoft developer and tester. The results have been staggering.

Security drastically improved in Microsoft products over the years, and IIS was definitely no exception to this. IIS 6 saw 5 security advisories and 4 vulnerabilities reported since 2003. Not to get ahead of myself, but IIS 7 has exactly 1 advisor and 1 vulnerability from Secunia. Compare this against Apache 2.0.x which has had 39 advisories and 23 vulnerabilities (4 of which are still unpatched as of this writing) and Apache 2.2.x which has had 10 advisories and 16 vulnerabilities (2 of which are still unpatched as of this writing) in the same period. Now I have seen attempts ([1], [2]) to quantify or otherwise explain these numbers further. You can read those articles for yourself and determine how much weight you want to give them. However you skew it, the facts should speak for themselves – IIS has dramatically improved and taken a leadership roll in security in IIS 6 and 7. Our ghost of IIS past still haunts the product’s reputation today, despite obvious strides taken. Even if you feel you like Apache better I think it is only fair to give credit where it is due.

Improvements in IIS 6

The IIS team took the four tenants of Microsoft’s Trustworthy Computing initiative to heart: Secure by Design, Secure by Default, Secure in Deployment and Secure Communication. Since we are already on the next version, I won’t spend a great deal of time talking about the security improvements in the last version other than a brief overview so you know how they relate to changes in our current version, IIS 7.

IIS 6 took vast strides to improve security. During upgrade installations, IIS 6 was disabled by default if the previous server had not been secured by the IIS lockdown tool. The architecture was completely revamped to separate kernel-mode HTTP listening from user-mode application execution. Changes were made to application pools, authentication, access control, encryption and certificate handling, auditing, logging and patch management that made the product far superior to its predecessors. You can find a detailed list of these features on TechNet. SecurityFocus did a comparison of these features in March of 2004.Server Watch wrote an article in December of 2003. By most accounts, everything accomplished in IIS 6 was a huge step in the right direction.

Despite the massive steps already taken in IIS6, IIS 7 took these all a bit further. Let’s go ahead and investigate these now.

Improvements in IIS 7.x

Customizable Installation

Continuing with the tenant of being secure in deployment, IIS 7 has made installation a wonder to behold. In IIS 6, you could reduce your attack surface by disabling features native to web server. However, these features were still loaded into the process. This carried not only a security factor, but also a performance and memory footprint issue. IIS 7 has a completely modular architecture. That means that features which you do not want are not only NOT loaded into the process, you can leave the bits for those features off of your disk completely.

Limitable Attack Surface

This is a bit dubious and is essentially part of the customizable installation. By reducing the modules that are available on disk or loaded into a process, you significantly reduce the attack surface for your specialized web servers. If all you intend to do is serve static content with caching and no default documents, you can simply install the static file handler and caching module and leave the rest of the IIS modules off of your server. Additional controls and limitations will also reduce your attack surface and I’ll cover those below.

IUSR account

Anyone who has tried to migrate an IIS installation from one machine to another or attempted to recover your installation on a new machine, previous to IIS 7, has likely run into an issue with the local “IUSR_” account. IIS 7 now uses a built-in IUSR account that allows you to easily copy your security settings from one machine to the next. This is great news for those using distributed configuration in web farms, recovery, restoration, or replication.

IIS_IUSRS group

IIS 6 introduced the IIS_WPG group. Application pool security identities had to be assigned to this group in order to host the w3wp.exe process. Like the IUSR account, IIS 7 now creates a built-in security group (IIS_IUSRS) and assigns application pool identities to the group automatically. You can find more information about the built-in user and built-in group for IIS 7 on IIS.NET (Understanding the Built-In User and Group Accounts in IIS 7.0).

ASP.NET / IIS Unified Security Architecture

Previous versions of IIS did not provide a unified approach to security with ASP.NET. The IIS 7 unified request pipeline that supports both Windows and non-Windows principals and provides one place to do all authentication and authorization. Apart from simplification and performance improvements, this also reduces the attack surface and allows for greater flexibility in authentication / authorization scenarios with custom modules.

Request Filtering / URL Rewriting

IIS 7.0 includes a request filtering module that is based on the URLScan ISAPI Filter for IIS 6.0. The module helps you tighten security of your Web servers.

The IIS team has also released an add-on URL rewrite module for IIS 7.0, which provides functionality for rule-based URL manipulation. Even though the primary purpose of the URL rewrite module is to rewrite URL paths for requests, the rewrite module can also be used as a security enforcement tool that helps prevent access to Web site content.

Application Pool Identities

On top of Application Pool Isolation, IIS introduces a new security feature in Service Pack 2 of Windows Server 2008 and Windows Vista. It’s called Application Pool Identities. Application Pool Identities allows you to run Application Pools under an unique account without having to create and manage domain or local accounts. The name of the Application Pool account corresponds to the name of the Application Pool.

Kernel mode SSL

The implementation of SSL has changed from IIS 6.0 to IIS 7.0. On Windows Server 2003, all SSL configuration was stored in the IIS metabase and encryption/decryption happened in user mode (required a lot of kernel/user mode transitions). On Windows Vista and Windows Server® 2008, HTTP.sys handles SSL encryption/decryption in kernel mode, resulting in up to 20% better performance for secure connections.

Configuration Improvements

IIS 7.0 allows locking and unlocking configuration settings in various levels and scopes. Locking down configuration means that it cannot be overridden (or set at all) at lower levels in the hierarchy. Unlocking configuration can only be done at the level where it was locked. This is useful, for example, when creating different configuration for different sites or paths, and only some of sites and paths are allowed to override it. Locking can be done at the section level or for specific elements, attributes, collection elements and collection directives within sections.

Dynamic IP Restriction

IIS 7 provides a new module that allows dynamic, temporary IP address restriction. This module prevents brute force attacks and HTTP clients that make unusually high number of concurrent requests or a large number of requests over a short period of time.

Summary

A verbose list of security features in IIS 6 and IIS 7 might be nearly impossible. Apart from the obvious features, there were numerous improvements to code made over these two versions that make the product far more secure than IIS 5 and earlier. That said, this should give you a summary start on information. I’ve listed some reference documents that may help you understand these features better. In general, I would encourage you to ask questions of the product team and or other users on the IIS.NET forums if you hear something that sounds negative regarding IIS. If the feedback is true, the product team has the benefit of improving the next release. If the feedback is unfounded, the product team has the benefit of helping you find the information you need to make an informed decision.

Tag Archives: Installation

IIS Security – Past and Present

Ghosts of IIS Security Past

Improvements in IIS 6