Securing IIS

Now that we’ve examined patching and vulnerabilities, let’s take a look at how you can secure IIS. Previously, IIS was wide open by default, and this caused some security issues. IIS 6 is installed in lockdown mode by default. Even so, you can do a few things to make IIS more secure on your system.

Don’t Install Components You Don’t Need

Don’t need the FTP service? Don’t install it. Won’t use the BITS Server Extensions? Don’t put them on just because they sound cool. The more components you install, the more you expose your site to vulnerabilities, especially if you don’t do the work of configuring those components.

Don’t Turn On Directory Browsing

Directory browsing allows anyone to see a listing of the files in a directory if no default page is configured. Needless to say, letting everyone see the structure of your files and filenames is a security risk.

Lock Down cmd.exe

The command prompt is a common way for hackers to get control of a system. Typically, the system32 directory isn’t in the web site path, but a buffer overflow vulnerability has allowed hackers to run cmd.exe. Windows File Protection will make deleting or renaming cmd.exe difficult, but if you don’t need it, just take permissions away from everyone so that no one can access it—even explicitly deny the anonymous user account. As an administrator, you can always take ownership of it and reassign permissions if you need to. This will make it more difficult for an attacker to take over the system.

Set Execute Permissions for Your Web Site

Three execute permissions settings are available: None, Scripts, and Execute. Make sure that you choose the most restrictive permissions possible for your site to help keep it secure. If you aren’t using Common Gateway Interface (CGI) applications, and you are using Active Server Pages (ASP) or static content, choose the Scripts permission. If you aren’t even using ASP, choose None.

None

Allows only static web pages to execute, so no scripts will be executed. This will prevent any server-side applications from running. This is the default setting for all web sites in IIS 6.

Scripts

Allows scripts, such as ASP, to run through their associated Internet Server Application Programming Interface (ISAPI) extension. Because scripts are run server-side, they have increased security risk when enabled.

Execute

Allows anything to run. Any file type can be accessed and run. This is the most permissive setting.

Note 

Because the default permissions for all web sites are set to None out of the box, ASP pages will not work without some configuration. To get ASP scripts to work, set the permissions to Scripts. If you are developing on the same box with Visual Studio, it will set this up for you—otherwise, you’ll have to do it manually. You also have to enable ASP in the Web Service Extensions section of the IIS MMC.

Don’t Set Up Write for Your Web Site

If you have execute permissions set up for your site, don’t enable write permission. If you have write enabled and permissions set for Execute, someone can upload an executable to your site and then promptly run it on your server! If you need people to write content to your web site, find another way. You don’t need enabled writes unless you want people to upload files to your site through Hypertext Transfer Protocol (HTTP).

Avoid Basic Authentication

Basic authentication sends the username and password combination in clear text. This is bad, because anyone listening can pick up on that packet and get that username/ password combo. You can encrypt the traffic to get around this, but much stronger options are available, such as Windows Integrated Authentication, which uses a cryptographic exchange to verify the user’s identity. In addition, Digest Authentication uses the user’s Active Directory account to authenticate the user. Or you can use Microsoft’s new .NET Passport authentication, detailed in Chapter 7.

Set Up Logging

It is always a good practice to set up logging for your site. This will track the IP address and username of whoever accesses content on your site. Logging will go a long way toward helping track down someone if they hack into your site.

Unmap Unneeded ISAPI Application Extensions

WS03 ships with a limited number of ISAPI applications enabled, as shown in the Mappings tab of the Application Configuration dialog box in Figure 6-2. The problematic .htr extensions are noticeably missing from IIS 6, as you can see in the figure. The .htr extensions allowed users to change their passwords via the web. These scripts were mapped to ISM.DLL, which had several associated security issues. Microsoft previously recommended that these extensions be disabled. Now, these extensions are completely gone and ISM.DLL doesn’t exist anymore.

Figure 6-2: Mappings tab showing ISAPI application extensions

Here are the ISAPI applications that are included in IIS 6, along with their functions:

• .asa Associated with asp.dll, this extension is for ASP files that have a global or application impact. These are necessary for most ASP sites.

• .asp The big one, ASP is the heart and soul of Microsoft server-side web sites.

• .cdx These files allow for channel definition files. Channels were introduced in IE 4, and they are basically web pages with a channel definition file determining the structure.

• .cer These file types allow ASP to handle certificates from the certificate server.

• .idc These files are used for Internet database connectivity, and they are handled by httpodbc.dll.

• .shtm, .shtml, .stm These file types are all for server-side includes, and they are associated with ssinc.dll, which processes the includes.

Hide the Fact that You’re Using Scripting

Here’s a good way to hide the fact that you’re using ASP: associate .htm files with ASP.dll. IIS could care less what the extension is—it just wants to know what to do with a particular file. Every .htm file will be run through asp.dll, and the ASP content will be processed. However, the page will appear to the end user as just a normal HTML page.

Use SSL for Sensitive Web Sites

The Secure Sockets Layer (SSL) protocol allows you to encrypt content between the browser and web server, thereby preventing anyone from seeing it. Client certificates also verify the identity of the client. SSL and certificates are covered in detail in Chapter 10.

Always Use NTFS Permissions

This almost goes without saying. NT File System (NTFS) allows for security, and FAT (file allocation table) and FAT32 do not. Always put your web sites on NTFS partitions, and lock down the permissions. One great feature of WS03 is that it does not grant everyone full control rights by default. Identify the anonymous Internet user for that machine, and make sure that account is locked out of as much as possible at the file- system level. Unfortunately, you can’t just lock the anonymous user out of everything, because some off-the-shelf programs put dynamic link library (DLL) files in the system32 directory that the anonymous user needs to access. The answer may be to use only authenticated accounts for those types of programs.

Be on the Lookout for Hackers

Firewalls and host-based IDS software can help you identify if someone is trying to hack into your site in real time. These measures can be costly and time-consuming to set up, but if you have a high-profile site, it may well be worth the effort and expense. Firewalls, in addition to restricting what traffic can pass, can also alert you of suspicious behavior. Host-based IDS software runs on the server itself, and it also alerts based on suspicious traffic patterns. Both of these can help you stop unauthorized activity in its tracks.

Try to Hack In

You can attempt to hack into your web site and see how far you get. Applications are available that can assist in determining vulnerabilities on your site. You can use a test server configured exactly like your production server, run a hack program, and see what security vulnerabilities exist. You can then see firsthand how easy or difficult it is to break into your site.

Control IIS Servers

Lastly, one of the best ways to make sure IIS servers are hardened properly is to have them controlled by a specific team of people who are well prepared to make sure IIS servers are properly hardened, locked down, and patched. Many times, it is the “rogue” IIS servers that are the hardest hit by the latest worm to make the rounds on the Internet. Having all the servers configured by the same people ensures consistency, and it means that there is less chance of something slipping through the cracks. Again, many worms hit well-known vulnerabilities for which patches already exist.