Monthly Archives: April 2009

You are browsing the site archives by month.

IIS Security – Past and Present

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.

See Also

Posted in: technical / Tagged: , , , , , , , , ,

Philly Code Camp 2009.1

I flew to Philadelphia from my home in Pittsburgh to attend and speak at the first Philadelphia area code camp for 2009.

I spoke on Extending IIS 7. You can find my photos of the event on flickr.

I took the opportunity to visit family that I hadn’t seen in ages and to see Philadelphia — a big deal for me as I’m a history buff.

Posted in: events / Tagged: ,

I might be Speaking at CodeStock

OK, so I had intended to announce that I posted a session submission to CodeStock and that voting was open. However, I procrastinated and Shawn Wildermuth beat me to the punch. So in an act of utter creepiness, I am modeling my post after his and invoking his name for extra copy-cat points.

For those of you that don’t know what CodeStock is, think of it as a CodeCamp done better – in two days instead of one. In their own words:

CodeStock is about Community. For Developers, by Developers (with love for SysAdmins and DBAs too!). Last year and idea started at CodeStock to mix Open Spaces within a traditional conference. This year we’re going to crank things up to 11 and rip off the knob – and you’re being drafted to help.

This two-day conference, of sorts, will be kicked off June 26th and costs only $25 to register.

My sessions are in the running, right along side Shawn’s. As he so eloquently pointed out, CodeStock attendees get to pick what sessions they wish to see from all of those submitted by would-be speakers. If my session doesn’t get picked, perhaps I can just watch Shawn. I’m told he has given a presentation or two in his career 🙂

So if you haven’t already, please go register for CodeStock so you can vote on those sessions while you can! Session voting ends on May 15th.

(Thanks, Shawn!)

Posted in: events / Tagged: ,

Installing CakePHP on IIS 7

Recently I spoke with someone on Twitter who was having issues running CakePHP on IIS. With all the talk about ASP.NET MVC on IIS, folks forget that the MVC pattern works in other languages as well. CakePHP provides MVC  development on PHP. That said, I wanted to dive in and see what the issues were involved in getting this project up and running on IIS 7. I managed to get it installed pretty quickly, but it does take a little tweaking to get you up and running. I’ve chronicled my adventures with CakePHP below in case anyone else is having issues. That said, I must first say that I am not an expert working with CakePHP. This was my first experience with the project, so this information is provided “as-is” and should be taken with a grain of salt. With this demo, I’ll be walking through the “Cake Blog Tutorial” offered on cakephp.org, and modifying it as needed to work with IIS 7. That said, let’s get started.

Prerequisites

Yes, there ARE a lot of Prerequisites, but these are pretty typical for any MVC app on any platform.

Assumptions / Conventions

For the purposes of this post, I will use the convention/assumption that you have unzipped CakePHP to c:inetpubCakePHP . You should have the following paths now:

  • c:inetpubCakePHP
    • app
    • cake
    • vendors
    • .htaccess
    • index.php
    • version.txt

I will also use the assumption that this is being installed on the “Default Web Site”. This is unlikely what you are doing, so you’ll want to replace the “Default Web Site” instances in the steps below with your site or application path.

Lastly, I will assume that you are using and have already installed MySQL. You may use another database if you please, but this blog will reference MySQL.

Installing the Blog Sample

Pointing IIS to the cake document root

First, you’ll need to configure your website to point to the correct location. Using the assumptions above, the correct location would be c:inetpubCakePHPappwebroot .

Creating a Blog Database

Second, configure your database connection. To do this, you’ll need to create a blog database, and then point your configuration to that new catalog.

Start by creating a new MySQL Catalog using your favorite tool. I used MySQL Administrator. Simply right click in the catalogs and click “create new schema.”

Create a schema named “CakeBlog”. Once the schema is created, click on the “Tools” menu and select “MySQL Query Browser” and execute the following script:

/* First, create our posts table: */
CREATE TABLE posts (
     id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
     title VARCHAR(50),
     body TEXT,
     created DATETIME DEFAULT NOT NULL,
     modified DATETIME DEFAULT NOT NULL8.);

/* Then insert some posts for testing: */
INSERT INTO posts (title,body,created)
      VALUES ('The title',
                  'This is the post body.', NOW());
INSERT INTO posts (title,body,created)
      VALUES ('A title once again',
                  'And the post body follows.', NOW());
INSERT INTO posts (title,body,created)
      VALUES ('Title strikes back',
                  'This is really exciting! Not.', NOW());

* This SQL code copied verbatim from tutorial found here:

http://book.cakephp.org/view/326/The-Cake-Blog-Tutorial 

You’ve now created your database and a blog posts table with some default posts. Time to configure CakePHP to read from the database:

Cake Database Configuration

We’ll need to let CakePHP know where the database is. Copy database.php.default in c:inetpubCakePHPappconfig to database.php

Open c:inetpubcakephpappconfigdatabase.php and change the $default variable to point to your database:

var $default = array( 'driver'    => 'mysql',
                      'connect'   => 'mysql_connect',
                      'host'      => 'localhost',
                      'login'     => 'CakeBlog',
                      'password'  => 'c4ke-1z-k00l',
                      'database'  => 'CakeBlog',
                      'prefix'    => '' );

* This PHP code copied nearly verbatim from tutorial found here:
http://book.cakephp.org/view/326/The-Cake-Blog-Tutorial

You should now be able to open your browser to your application and see the default cake configuration page.

Setting up Rewriting Rules

CakePHP uses mod_rewrite, but also provides the ability to use Cake’s built-in ‘pretty URLs’. We’ll be importing the mod_rewrite rules from the .htaccess files from the default cakephp installation into the IIS URL Rewrite module. We’ll then have to modify those rules.

Start this process by opening the IIS Management Console. Open your application path. In this instance, we are using “Default Web Site”.

  1. Click on the “Default Web Site”
  2. Open the “URL Rewrite” module
  3. Click on “Import Rules…” in the Actions pane
  4. Click the “…” button next to the “Configuration file” textbox.
  5. Select the c:inetpubcakephp.htaccess file and click “OK”
  6. Click the “Import” button
  7. Click the “Apply” button in the “Actions” pane
  8. Repeat steps 4, 5, 6 and 7 for c:inetpubcakephpapp.htaccess and c:inetpubcakephpappwebroot.htaccess files.

The rules are imported, but now you’ll need to edit the rules.

  1. Click the “Back to Rules” button in the “Actions” pane
  2. Edit the two rules with the action starting with “webroot/”
  3. Remove the “webroot” portion of the “Rewrite URL”. Your paths should now look as follows:

Creating your MVC Application

The remainder of your application setup should follow the steps found in the original “Cake Blog Tutorial”. There is nothing different between IIS and Apache at this point, so copying the steps would be a bit redundant. Start with the step named “Create a Post Model”. Much like ASP.NET MVC, Cake provides an MVC pattern for developing PHP applications.

Once you have completed the steps, you should have a default site that looks something like the following:

Summary

Installing CakePHP on IIS is actually not much different from installing on Apache. The main difference lies in the implementation of mod_rewrite on Apache vs URL Rewriter in IIS. Obviously the installation of PHP differs from Apache. IIS makes the installation of PHP simple with Web Application Installer. If you are using CakePHP on IIS, I would be interested to hear if your experience was different than mine.

Posted in: technical / Tagged: , ,