Tobin Titus Blog : Performance

IIS Security – Past and Present

TobinTitus — Tue, 28 Apr 2009 08:24:00 GMT

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_<machine_name>” 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.

Adding performance

TobinTitus — Thu, 30 Nov 2006 11:38:00 GMT

Some of you may have found the title to this blog post as amusing as I do. Throughout my career, I've been called into many a meeting asking that I "add" performance to a complete or nearly-complete product. No matter how many scowls I got, I could never resist joking about just adding the IPerformance interface. "And, while you are at it, just add the IScalable one too", I would quip. (OK, I know some of you are doing searches for these interfaces -- don't bother). Laugh as hard as I may, I'm embarrassed to say that I am trying to do this very thing now.

A few weeks ago, I started playing around with a small sample that shows off some of the fun features of IIS 7. As I started coding, I added more features to the sample. Scope creep is a no-no, but this was something I was doing on my own time so I didn't have a problem with it. However, the sample got so large that I had to actually stop and design a public API to support it. By the time I was done, my "sample" had a set of providers, a common API, localization support, utilities, and most notably, performance issues.

Last year on my personal blog, I talked about "engineering for usability". In that post, I declared that the simplest design is sometimes (and probably most often) the best approach. That said, performance should have been considered very early on, and the sample should have been kept simple. Performance, as many of you know, is not something you add as an afterthought. Starting my sample the way I did, I never considered code performance to be an issue.

Now I'm forced to decide: do I scale back my sample knowing full well that it doesn't have a security model or provide easy extensibility, or do I redesign the sample with the current feature set and design for performance up front? I'm leaning toward the latter despite reciting "keep it simple, stupid" in my head over and over again.

Improving code performance

TobinTitus — Tue, 06 Jun 2006 20:40:00 GMT

Recently, an old co-worker contacted me to ask me a question about code performance. Specifically, he was emitting IL from his code and had some questions about some of the opcode usage he witnessed when viewing the IL of some compiled assemblies. The question was based on a simple application he wrote in C#, compiled, and disassembled. He did this to see how the C# compiler produced IL and give him clues in how he should emit IL. The function in question was as follows:

public object GetProp(string name)
{   if (name == "X")
   {    return this.X;
   }
   return null;
}

Now, the code obviously isn't meant to do anything other than lend some insight into the IL. Compiling to 'debug' the following IL was produced.

.method public hidebysig instance object
        GetProp(string name) cil managed
{
// Code size       35 (0x23)
.maxstack 2
.locals init ([0] object CS$1$0000,
          [1] bool CS$4$0001)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldstr      "X"
IL_0007: call       bool [mscorlib]System.String::op_Equality(string, string)
IL_000c: ldc.i4.0
IL_000d: ceq
IL_000f: stloc.1
IL_0010: ldloc.1
IL_0011: brtrue.s   IL_001d
IL_0013: nop
IL_0014: ldarg.0
IL_0015: call       instance string class TestApp.TClass`1::get_X()
IL_001a: stloc.0
IL_001b: br.s       IL_0021
IL_001d: ldnull
IL_001e: stloc.0
IL_001f: br.s       IL_0021
IL_0021: ldloc.0
IL_0022: ret
} // end of method TClass`1::GetProp

The question was, why was the stloc.1 and ldloc.1 needed after the ceq instruction at IL_000d (there are actually other issues in this small snippet, but I'll focus on this particular one) . I, too, tried to resolve the issue and batted a few guesses around. I proffered two ideas, and then ultimately suggested that the JIT compiler would likely be modifying this code anyway (particularly once it was recompiled in 'release' with optimization).

Still curious as to why the compiler produced the stloc and ldloc opcodes, I asked around internally until Vance set me straight with this blog post.

Introduction: What does ‘foreach’ actually do?
http://blogs.msdn.com/vancem/archive/2006/02/20/535807.aspx

Essentially, he states what I initially felt -- that the JIT transformations on the IL are so dramatic, that you cannot judge an application's performance based on the IL. He also gives some great information on how to view your JITed code -- with release optimizations and everything. The other side to this is, that after further review, the inefficiencies of the IL were fixed in the optimized IL anyway once the code was set to 'release'.

Sometimes, it's really easy to get side-tracked by these discussions in your quest for software glory. I'm glad to know we have people like Vance around to set me straight when I do.