In "Protect Private Ports with IPSec," April 2002, InstantDoc ID 24273, and "Close the Doors to Your Web Server," February 2002, InstantDoc ID 23573, I discuss how to lock down the peripheral doorways into your Web server by disabling all unneeded services, then using IP Security (IPSec) to protect the remaining services and their corresponding TCP and UDP ports. Of course, IPSec isn't an option for a public Web server's port 80 (HTTP),which you must leave open to requests from Internet clients. Unfortunately, many common methods for breaking into an IIS server occur through HTTP, and most firewalls can't look inside an HTTP request to detect embedded attacks. The internal configuration of your Web server and your Web application must defend against such attacks. You need to lock down every internal component of your server, from file permissions to script mappings. You also must securely code your Web applications coded with Active Server Pages (ASP), Common Gateway Interface (CGI), Microsoft FrontPage, and Macromedia's ColdFusion—and patch your server against buffer-overflow attacks and other requests with malformed URLs.
Wouldn't it be great if you could scan each request as it comes into your server for telltale signs that identify the request as malicious? Microsoft offers a free tool that does exactly that: URLScan. Microsoft released URLScan 1.0 in September 2001, but because of parsing limitations and other defects, the tool broke many Web sites. Microsoft quickly refined the tool and released URLScan 2.0, which generated little activity in support forums—an indication that the tool was ready for general use. Since I drafted this article, Microsoft has released URLScan 2.5, which provides added features that include enhanced logging capabilities and the ability to limit the length of requests a client sends (and thus help avert buffer-overflow attacks). You can download and customize URLScan for your environment. After testing the tool, you can choose to install it in your production environment either automatically or manually. For more information about this new version, see the sidebar "URLScan 2.5 Adds Protection," page 8, and see the Microsoft article "INFO: Availability of URLScan Version 2.5 Security Tool" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q307608).
How URLScan Works
URLScan is an Internet Server API (ISAPI) filter that intercepts every request your Web server receives from the Internet and scans each request for anything unusual. As the URLScan documentation notes, "Most attacks share a common characteristic—they involve the use of a request that's unusual in some way. For instance, the request might be extremely long, request an unusual action, be encoded using an alternate character set, or include character sequences that are rarely seen in legitimate requests." URLScan's task is to detect such anomalies in HTTP requests. When URLScan detects anything unusual, the tool prevents the request from being processed. Because of this approach, URLScan can protect your server against future exploits—for example, a yet-to-be-discovered IIS buffer-overflow vulnerability. In most buffer-overflow attacks, attackers form a URL that contains many nonfunctioning characters and some binary code that the computer executes. By rejecting unusually long requests and requests with high-bit characters (i.e., characters greater than 127), both of which are useful indicators of buffer-overflow attempts, URLScan prevents the buffer overflow from reaching the faulty region of IIS code.
Preparing for URLScan
Before you begin to use URLScan, you need to download it cautiously, customize the tool, then test it on a nonproduction server that contains a copy of your Web site. Don't immediately install URLScan on your production Web server or you might block access to large portions of your Web site—especially if you use add-ons such as FrontPage Server Extensions. Because URLScan is an ISAPI filter, after it's installed, it's always active as part of the Inetinfo process.
Downloading URLScan. URLScan is bundled as part of the IIS Lockdown tool, which you can download at http://www.microsoft.com/downloads/release.asp?releaseid=33961. However, don't double-click iislockd.exe after you download it. Doing so prompts configuration of your server rather than downloading the files. Instead, extract URLScan's files to a folder. To do so, open a command prompt and type
iislockd.exe /q /c /t:<folder path>
where folder path is the location you designate for the files.
Customizing URLScan. URLScan lets you reject or permit requests based on HTTP verb, file extension, server header, suspicious character sequences, and non-ASCII characters. You control these restrictions through urlscan.ini, which I'll explore in depth in an upcoming article. For now, note that urlscan.ini must reside in the same folder as the URLScan DLL, typically in\%windir%\system32\inetsrv\urlscan. If URLScan doesn't find the .ini file, it rejects all requests. Also, be aware that whenever you edit urlscan.ini, you must restart IIS for your changes to take effect.
Urlscan.doc, which is in the folder to which you extracted the files from iislockd.exe, documents every option in urlscan.ini. You need to consider the effect that each option might have on your Web site. You want to edit urlscan.ini to be as strict as possible without breaking your Web site. For URLScan to continue to support specific functions, you must know exactly how to configure each function's related options. For example, if you use FrontPage extensions on your server, you must make sure that the POST and OPTIONS verbs are listed under the \[AllowVerbs\] section of urlscan.ini.
Testing URLScan. After you've selected the options you want URLScan to use, install the tool on a development or test server that contains a test copy of your Web site. Verify that every page and transaction still works. Note that URLScan offers a logging-only mode that comes in handy during testing.
When you enable logging-only mode, URLScan scans every request and logs any that are "illegal," but it doesn't reject any requests. Therefore, you can run URLScan in this mode and learn from the log which requests the tool will reject—without breaking anything. After you've enabled logging-only mode, send some requests that URLScan should reject to make sure the tool is actually guarding the server. For example, if you chose to disable the ampersand character (&) under \[DenyUrlSequences\] in urlscan.ini, open a browser, then enter and send a request such as //server/yada&yada. Verify that URLScan would reject the request. (Attackers have used ampersands in form input fields to fool IIS into running additional arbitrary commands after it runs the usual command.) After testing, you can consider deploying URLScan (with your customized urlscan.ini file) in production.
Deploying URLScan
You can install URLScan either automatically (using the IIS Lockdown Wizard, which is part of the IIS Lockdown tool download) or manually. Microsoft recommends that only experienced Web administrators use URLScan because you can configure the filters in ways that interfere with usual Web site operations. I agree that experience is important—and I recommend manual installation to prevent the IIS Lockdown Wizard from reconfiguring other settings on your IIS server without your knowledge. However, if you have limited IIS experience or limited time, you can let the IIS Lockdown Wizard step you through the process. In either case, be sure to perform a full system backup before you make changes to your system. For information about how to install URLScan by using the IIS Lockdown Wizard, see the Web-exclusive sidebar "Installing URLScan Automatically," http://www.windowswebsolutions.com, InstantDoc ID 25232.
Installing URLScan manually. To install URLScan manually, follow Steps 1 through 8 as outlined in urlscan.doc. The process is straightforward. The steps detail opening the Microsoft Management Console (MMC) Internet Information Services snap-in and adding urlscan.dll as a global ISAPI filter. You must install URLScan as a global (server-level) filter instead of as a site-level filter. If you install URLScan at the site level, you haven't locked down your server effectively because an intruder could access a different site on your server, then bypass and disable the filter.
After you install the URLScan ISAPI filter, you need to copy your customized urlscan.ini file to the same folder in which urlscan.dll resides, then restart IIS. Next, test your Web site and verify that URLScan doesn't reject legitimate requests and does reject improper requests. During your testing, you might find that some portion of your Web site breaks after you install URLScan. The reason usually lies in idiosyncrasies in your URL links, such as the use of folder names with periods or disallowed characters such as an ampersand.
Fortunately, URLScan does a great job of logging diagnostic information. URLScan creates a new log file each day in the same folder in which urlscan.dll resides. Each time IIS starts up, URLScan logs a detailed description of its current configuration, including what it will permit and reject. Then, each time URLScan rejects a request, the tool logs the date, the time, and the raw URL—and explains exactly why it rejected the URL, as Figure 1 shows. At the bottom of Figure 1, you can see two requests that URLScan rejected—one request that tried to call an executable file and another that contained an ampersand. The detailed log will help you adjust URLScan to your site's needs.
Next: URLScan Configuration Options
You now have an overview of what's involved in deploying URLScan to protect your Web server. URLScan can help protect against attackers knocking on your front door—port 80. URLScan's log file also provides an additional means to monitor for intrusion attempts. In an upcoming article, I'll examine the details of configuring the urlscan.ini file to choose which requests URLScan will reject or permit on your Web site.
