Lock IT Down: Use eEye's SecureIIS to help lock down IIS systems

Use SecureIIS to block data blocked before it can be processed and the attempted security breach is logged.

IIS Web servers are a favorite target of hackers for a couple of reasons. First, since companies often use IIS as their corporate Web server, IIS is a doorway that hackers can sometimes use to gain access to a company's private network. Second, IIS is loaded with security vulnerabilities. In fact, there have been more than a hundred security holes discovered in IIS to date.

Microsoft does a reasonably good job of making patches available when new IIS exploits are discovered. However, keeping up with IIS and Windows security patches can be a full-time job. Another problem with patch management is that Microsoft can't create a patch until it knows about a vulnerability. By the time a vulnerability goes public, Microsoft develops and tests a patch, and you download and install it, you may have already fallen victim to the exploit that the patch was designed to protect against.

Thus, it is also important to protect IIS systems against undiscovered or unpatched vulnerabilities. One way of doing so is to use a product called SecureIIS from eEye Digital Security.

SecureIIS is, for lack of a better characterization, an application-level firewall. SecureIIS is integrated into IIS and monitors all inbound data at each level of processing. If, at any time, SecureIIS detects data that is malicious in nature, the data is blocked before it can be processed and the attempted security breach is logged.

System requirements
SecureIIS is designed to run on a variety of platforms, including Windows NT 4.0 with Service Pack 6 and IIS 4.0. You can also run the software on Windows 2000 with Service Pack 1 or higher and IIS 5.0. Windows Server 2003 and IIS 6.0 are also supported, as long as your server is running in isolation mode.

Installing SecureIIS
There are actually two versions of SecureIIS: a personal version and the standard version. You can download the personal version for free. The standard version is designed for commercial use and starts at $995. In addition to being suitable for commercial use, the standard version is scalable and supports enterprise-level policy configuration, multiple languages, and technical support, among its other features. For the purposes of this article, I'll demonstrate the product using the personal version.

The personal version download consists of an 8.42-MB self-extracting executable. Running this file launches the Setup Wizard. Once you get through the preliminaries (accepting the end-user license agreement and closing running applications), click Next, and you will be asked for the installation path. Setup will then copy all of the necessary installation files.

When the copy process completes, Setup will ask for your e-mail address. This is the address SecureIIS uses to notify you of any attempts to violate your server's security and to inform you of any updates to the software. Finally, Setup will ask you whether you'd like to place a shortcut on the desktop. Click Finish to close Setup. You must now reboot your server before you can use SecureIIS.

After the server reboots, Windows will automatically launch the SecureIIS Registration Wizard. Even though the personal version is a free product, you can't access it until you have registered with eEye. The wizard consists of only a few screens, and registration takes less than five minutes.

After you register SecureIIS, the Quick Start Wizard will launch. It doesn't actually do anything to configure the software. Instead, it simply walks you through the steps for performing some of the most basic tasks, such as arming SecureIIS.

Using SecureIIS
SecureIIS uses several mechanisms to protect IIS. Each of the mechanisms that I am about to show you appears on its own tab within the SecureIIS Console.

The Buffers tab, shown in Figure A, allows you to protect IIS against a buffer overflow attack. Hackers often force a buffer to overflow as a means of tricking a server into disclosing the contents of its memory. As you can see in the figure, the Buffers tab allows you to do things like limit the length of the URL and specify the maximum size of a cookie. These are some really good precautions to take against buffer-related attacks. After all, if the longest legitimate URL on your Web site is 75 characters, why allow someone to enter a 200-character URL?

Figure A
The Buffers tab contains options that you can use to prevent a buffer overflow attack.

The Methods tab contains a list of the various HTTP methods and lets you control which ones you will allow. A generic Web site will typically use only the GET and POST methods. By disabling all other HTTP methods, you eliminate the risk of someone exploiting one of the otherwise-unused methods to gain an unauthorized level of access to your server.

The Shellcode tab lets you block any requests that use high-bit ASCII data. High-bit ASCII data are ASCII characters that do not appear on the keyboard. There are 256 ASCII characters, and, after you account for every uppercase letter, lowercase letter, number, and symbol on the keyboard, you've still accounted for fewer than half the available ASCII characters. These higher-range characters can sometimes be used to exploit a Web site.

Normally, you would want to block high-bit data. However, if your site is multilingual, you will want to leave the option enabled, since many foreign character sets rely on high-bit data.

The Keywords option works by scanning inbound requests for various keywords that would indicate malicious intent. For example, if someone uses CMD.EXE, ROOT.EXE, SYSTEM32, or XP_CMDSHELL within a request, you can be reasonably sure that they are up to no good. Blocking requests containing such keywords allows you to filter out these types of malicious requests.

The Protect tab serves as a general collection of exploitation filters that don't really fit into any other category. This tab primarily contains mechanisms to protect against directory traversal and encoding abuse.

Sometimes, a hacker will intentionally try to get an IIS Web server to generate an error in hopes that the error message will disclose information about the server. The Errors tab allows you to replace the standard IIS errors with custom error messages. This tab focuses mainly on 404 and 406 errors.

The Variables tab is used to supply data for the custom error messages generated by the Errors tab. For example, you can supply your domain name or e-mail address so that the information appears within the custom error message.

End sum
As you can see, SecureIIS takes a lot of steps toward safeguarding IIS. I've focused here on the personal version of SecureIIS, but the standard version is essentially the same, except that it provides a license to implement it in a corporate environment. Companies that rely on IIS to run their public Web sites should definitely consider using SecureIIS to lock down their servers.

Editor's Picks

Free Newsletters, In your Inbox