Microsoft's New URLScan for IIS

It's a somber day for America. I don't mind saying that it's rather hard to concentrate on writing this editorial this morning. Here at Penton Media, our heart-felt condolences go out to all the people who suffer from the terrorist attacks on America this week—may justice meet its targets swiftly and effectively.

That said, I'll do my best to focus on business as usual: We have an exciting announcement regarding a new security tool from Microsoft. If you look back at the history of Microsoft IIS, you'll find that users have discovered plenty of security problems over the years. Many of those problems relate to malformed URLs, which often lead to intrusion or Denial of Service (DoS) attacks. In an attempt to ward off unknown attack types and unwanted URL requests, Microsoft has released a much-needed filter for IIS called URLScan. The filter intercepts all URLs sent to IIS before those URLs reach the actual Web server process. This approach lets the filter preprocess the URL to determine whether the URL is a legitimate request to the Web server before letting the Web service process the request.

I received a sneak preview of URLScan a couple of days ago and immediately put it to work on a test Internet Information Services (IIS) 5.0 system. URLScan installs quickly and easily, and configuration is a relatively simple process. URLScan is flexible; it lets the user reject or accept URLs based on various criteria including request method, file extension, suspect URL encoding, non-ASCII characters or particular character sequences in the URL, and by the header in the request.

For example, I found it simple to configure URLScan so that it accepts only GET requests for .htm and .asp files, while ignoring all other requests, including those that use a POST method or contain Unicode-style encoding. I simply defined the file extensions for which I wanted to accept requests (.htm and .asp files) and defined the characters in a URL for which I wanted to deny requests, such as the percent character (%) typically used with Unicode encoding.

URLScan configuration is fairly straightforward, although you might find it somewhat puzzling if you aren't familiar with HTTP verbs (often referred to as methods). For example, when is the last time you heard of the "PROPFIND" verb? Don't worry about verbs too much, however; Microsoft has a decent Help file that ships with the filter, which explains configuration items in moderate detail.

One slick aspect of URLScan is that you can redefine the Server: header that the Web server presents so that the header is simply an empty value or spoofs some other Web server type. This feature helps ward off intruders who are specifically looking for IIS systems to attack. In addition, when URLScan rejects a request, it presents the user with a generic "404 - File Not Found" error message. URLScan also supports Web-related technology such as FrontPage and WebDAV.

URLScan logs any rejected requests to a text file called URLScan.log. I found it strange that Microsoft designed the filter to create a text file log as opposed to writing events to the Event Logs. Microsoft explained that the development team thought it would be better to isolate the related logs so users can see what the filter is actually rejecting. The premise is that writing events to the Event Logs would probably make a mess of the Event Logs, given the potential volume of rejected requests a server might receive.

As an example that demonstrates potential log volume (which somewhat validates Microsoft's choice to use a text-based log), I loaded the URLScan onto an IIS 5.0 test server. I put the system live on the Internet 2 days ago, and URLScan has already rejected more than 65 requests to the server—almost all of them designed to exploit known issues with .ida file extensions.

URLScan is a much-needed and long-overdue IIS filter. By configuring the filter properly, you can potentially mitigate untold numbers of future security risks before they are discovered. If you aren't already using a third-party URL filter, I highly recommend that you look at URLScan immediately and consider applying this filter to all your IIS Web servers. You can download a copy at the Microsoft Web site.

A word of caution: Although URLScan can ward off unknown attack types, it's no replacement for security patches, so be sure to keep your systems up to date with related hotfixes.