Tobin Titus Blog : configuration

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.

Installing CakePHP on IIS 7

TobinTitus — Fri, 03 Apr 2009 14:15:00 GMT

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

Install: IIS 7 on Windows 2008 Server or Windows Vista
- Install: PHP for IIS 7.0. Use the Web Platform Installer for easiest experience.
- Install: URL Rewriter module. Use the Web Platform Installer for easiest experience.
Install: A database supported by CakePHP. This post uses MySQL.
Download: CakePHP source code
- Unzip: CakePHP (entire contents) to the intended path

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:\inetpub\CakePHP\ . You should have the following paths now:

c:\inetpub\CakePHP\
- \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:\inetpub\CakePHP\app\webroot\ .

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:\inetpub\CakePHP\app\config\ to database.php

Open c:\inetpub\cakephp\app\config\database.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 not 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”.

Click on the “Default Web Site”
Open the “URL Rewrite” module
Click on “Import Rules…” in the Actions pane
Click the “…” button next to the “Configuration file” textbox.
Select the c:\inetpub\cakephp\.htaccess file and click “OK”
Click the “Import” button
Click the “Apply” button in the “Actions” pane
Repeat steps 4, 5, 6 and 7 for c:\inetpub\cakephp\app\.htaccess and c:\inetpub\cakephp\app\webroot\.htaccess files.

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

Click the “Back to Rules” button in the “Actions” pane
Edit the two rules with the action starting with “webroot/”
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.

IIS cannot start after upgrade to Vista SP1

TobinTitus — Mon, 22 Sep 2008 04:31:00 GMT

Some time ago, I tried to start up the IIS Management Console on my Vista machine and I received an exception. After trying a few quick fixes, I gave up. I had several VPC images that I worked from and I didn't particularly need this machine to work when I had so many others. However, I've been doing a great deal of development on this machine now, and having IIS working is obviously rather handy. So, I tracked down the exception and solved my problem. I thought I'd go ahead and chronical my adventures for anyone else who is having this issue and needs help.

So first of all, the error that was displayed when I started inetmgr was as follows:

---------------------------
Failed to connect
---------------------------
There was an error when trying to connect. Do you want to retype your credentials and try again? 
Details: 
Creating an instance of the COM component with CLSID {2B72133B-3F5B-4602-8952-803546CE3344} 
from the IClassFactory failed due to the following error: 8007000d.
---------------------------
Yes   No   
---------------------------

So I thought that this might be a configuration error. I tried to roll back to a known good configuration but appcmd failed with the following exception:

ERROR ( hresult:80070426, message:Command execution failed.
The service has not been started. )

I tried to start the service with a good old fashion iisreset command and the following exception occurred:

Attempting stop...
Internet services successfully stopped
Attempting start...
Restart attempt failed.
The IIS Admin Service or the World Wide Web Publishing Service, or a service dep
endent on them failed to start. The service, or dependent services, may had an
error during its startup or may be disabled.

Once again, I thought I'd go into the services console and try to start IIS manually. After trying to start it manually, it failed, stating that a dependent service failed. So I looked at Windows Process Activation Services (WAS) and noticed it was stopped. I tried to start it manually and found the following:

---------------------------
Services
---------------------------
Windows could not start the Windows Process Activation Service service on Local Computer.
Error 13:
The data is invalid.
---------------------------
OK
---------------------------

So I checked out the event log and found the following four entries:

First Event :

Log Name:      System
Source:        Service Control Manager
Date:          9/21/2008 11:52:00 PM
Event ID:      7001
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Description:
The World Wide Web Publishing Service service depends on the Windows Process Activation Service service which failed to start because of the following error:
The data is invalid.

Second Event:

Log Name:      System
Source:        Service Control Manager
Date:          9/21/2008 11:52:00 PM
Event ID:      7023
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Description:
The Windows Process Activation Service service terminated with the following error:
The data is invalid.

Third Event:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          9/21/2008 11:51:59 PM
Event ID:      5005
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Description:
Windows Process Activation Service (WAS) is stopping because it encountered an error. The data field contains the error number.

Fourt Event:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          9/21/2008 11:51:59 PM
Event ID:      5036
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Description:
The configuration manager for Windows Process Activation Service (WAS) did not initialize. The data field contains the error number.

I checked through my event logs and realized that this started happening after I had upgraded to SP1. I hadn't recognized this as the issue because, as I said, don't typically use IIS on this machine on a regular basis. I decided to go back to my initial assessment that this had to be configuration related. I started doing comparisons between configuration of a pure Vista installation vs a Vista machine with SP1. I found that the schema had changed during the install, but something had been left out. The schema file was updated to add the configurationHistory configuration section, but a corresponding section definition was not added to the applicationHost.config file.

Whether this was what was causing the problem or not, I knew this was going to cause a problem. I added the following configuration entry to the applicationHost.config file under the section group for "system.applicationHost".

<section name="configHistory" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />

After this I started the WAS service, the World Wide Publishing Service and the IIS Admin Service. I opened up the IIS Management Console and everything was working just fine.

I'm not sure what exactly happened during the SP1 upgrade that caused this file to not be updated, but I'm pleased to report that all things are up and running again.

Tobin Titus Blog : configuration

IIS Security – Past and Present

Ghosts of IIS Security Past

Improvements in IIS 6

Improvements in IIS 7.x

Customizable Installation

Limitable Attack Surface

IUSR account

IIS_IUSRS group

ASP.NET / IIS Unified Security Architecture

Request Filtering / URL Rewriting

Application Pool Identities

Kernel mode SSL

Configuration Improvements

Dynamic IP Restriction

Summary

See Also

Installing CakePHP on IIS 7

Prerequisites

Assumptions / Conventions

Installing the Blog Sample

Pointing IIS to the cake document root

Creating a Blog Database

Cake Database Configuration

Setting up Rewriting Rules

Creating your MVC Application

Summary

IIS cannot start after upgrade to Vista SP1