Safeguarding IIS from Attack

Microsoft IIS holds an unusual position in a networking infrastructure: As code running in user mode that's deeply integrated with the OS, IIS uses Internet protocols to deliver applications and content to remote users. To secure IIS, you need to consider every aspect of the installation, including the network, application, server, and OS. And speaking as someone who has been there, you'll have a new appreciation for the word defense when you're finished with the process.

You'd be surprised at how much money companies spend to secure their servers only to fail to protect those same systems from someone gaining physical access and using a 3.5" disk to boot the machine. For the sake of this article, I assume you don't need a refresher on physical access, unpatched systems, password complexity, and changing default passwords on administrative systems (e.g., system monitors, shopping carts). Still, someone isn't getting the message because these items continue to rank among the most common methods of gaining unauthorized access to servers; for more details, see The SysAdmin, Audit, Network, Security (SANS) Institute's article "The Twenty Most Critical Internet Security Vulnerabilities (Updated) — The Experts' Consensus" (http://www.sans.org/top20). However, if you want more information about the basics of IIS security, I suggest you read "Best Practices for Secure Web Servers," December 2001, http://www.windowswebsolutions.com, InstantDoc ID 22972.

After you've established a good understanding of basic IIS security, you're ready to move on to more advanced topics such as controlling the process identity, port filtering, disabling Web Distributed Authoring and Versioning (WebDAV), and using the URLScan security tool. Let's clarify a few persistent myths about IIS security and examine some of the most useful Microsoft-based tools and techniques for hardening your Web servers.

IIS Security Folklore
One of the first things you need to learn about IIS security is that not everything you read is true. In fact, one of the reasons I began sharing my IIS expertise was the significant amount of misinformation available from various sources, including Microsoft. Let's examine a few examples of this misinformation.

Anonymous user requires log-on-locally privilege. Perhaps you've read that the IUSR_ account that IIS uses for anonymous authentication requires the right to log on locally. This information is available in the IIS Help files and on the Microsoft Web site, including the Microsoft article "HOW TO: Set Basic NTFS Permissions for IIS 5.0" (http://support.microsoft.com/?kbid=271071). Users often advise their colleagues about this requirement in support groups and on bulletin boards. However, unless the IIS server resides on a domain controller (DC), this requirement isn't true. The type of authentication that occurs by default with an anonymous user results in a network logon that doesn't require the log-on-locally privilege (for a detailed explanation about this network logon, see "IIS Informant: Clarifying Inaccurate Information About Anonymous Authentication," http://www.windowswebsolutions.com, InstantDoc ID 24845).

From a security perspective, denying an anonymous user the right to log on locally is a good practice because it prevents someone from using the anonymous user account to obtain a local logon, which would let the user have more privileges on the network than a network logon. For example, a hacker who uses the IUSR account to log on through Windows 2000 Server Terminal Services would be in an interactive logon session and, therefore, able to access other network resources. Understanding the differences between a local logon and a network logon can take a while to learn but is well worth the study for IIS administrators and is essential for a solid understanding of server security. For a brief authentication overview, see http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/prdp_log_csky.asp and Michael Howard's Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press), page 107.

Users need Change permissions on log files. The Secure Internet Information Services 5 Checklist at http://www.microsoft.com/technet/security/tools/chklist/iis5chk.asp contains some excellent suggestions and one really bad idea, namely to allow the Everyone group Read, Write, and Change permissions on the IIS-generated log files (%systemroot%system32logfiles). I studied this suggestion for some time to make sure I wasn't missing the point, but allowing these permissions to the Everyone group won't prevent malicious users from deleting log files to cover their tracks, as the checklist implies. The correct advice is to allow only Full Control permissions on the log files to the Administrators and System groups. The only exception to this rule is if you use a custom logging object that writes IIS log files. In that rare circumstance, you might need to allow Change permissions.

Active Server Pages (ASP) requires the NTFS Execute permission. Many Microsoft and non-Microsoft documents include suggested NTFS permissions for IIS content. Most of these documents state that scripts require the NTFS Execute permission. This advice violates the important security best practice known as the principle of least privilege. In general, any script mapped to a script engine requires only the NTFS Read permission.

IIS administrators face a challenging task of weeding out the truths from the half-truths. Knowing that some misinformation comes from Microsoft doesn't make this task any easier. Still, being aware of the steps you need to take to secure your Web servers will help. Let's examine a few truths.

Controlling the Process Identity
One of the cardinal rules of server security is that all processes have a security context, which means that every program running on the server runs as an entity. That entity might be the logged-on user or a built-in account (e.g., System), but every process has an identity. As a security-conscious IIS administrator, you should always know the identity of the process that hosts your Web application. Table 1 provides details about the IIS process model and associated identities.

A hacker can use several methods to gain access to the process identity. A buffer-overflow attack on your application or Web server might provide the attacker with the security context of the process identity. Another method takes advantage of the RevertToSelf function that an executable can call. If the hacker can invoke such an executable, the application will then run as the process identity. Note in Table 1 that in Internet Information Services (IIS) 5.0 and Internet Information Server (IIS) 4.0, Inetinfo runs as the System account. Consequently, from a security perspective, you should avoid running applications "in process" (i.e., running in the Inetinfo process as much as possible). In IIS 6.0, Web applications don't run with the System identity unless you explicitly configure them to do so or you've configured the server to run in IIS 5.0 mode.

As an administrator, you can't prevent a program from using the process identity, but you can inspect a binary to determine whether it calls RevertToSelf. To inspect an executable, you can use the DumpBin utility, which comes with most development languages. Use the following command:

dumpbin /imports executable name | find "RevertToSelf"

For more information about validating executable content, see the Secure Internet Information Services 5 Checklist.

Port Filtering
Although the subject of port filtering is beyond the scope of this article, you need to be aware of some basics. For example, the only port that IIS requires to function is port 80—anything else is for additional functionality. You'll likely require TCP port 443 for Secure Sockets Layer (SSL) security, TCP/UDP port 53 for DNS, TCP port 25 for SMTP, and possibly other ports to support your business needs. You should allow communications only for services that you require and never expose the Microsoft networking ports (TCP/UDP ports 137, 138, 139, and 445) to an untrusted network. The networking ports, in particular, and the related services that use them provide a veritable cornucopia of attack surfaces. When you're configuring IIS, I suggest that you start with port 80 and a determined attitude that you won't open any other ports unless you have a bona fide business reason to do so. Of course, many sites rely on firewalls for port filtering, but I prefer to configure IIS servers in the demilitarized zone (DMZ) as if a hacker had penetrated the firewall. Host-based defense, as it's sometimes called, is an important layer in an in-depth security strategy.

My favorite tool for port filtering is the IP Security (IPSec) utility—it works well, it's free, and you can run it from a command line. IPSec's main purpose isn't port filtering but rather creating point-to-point mutually authenticated and encrypted connections. For example, let's say you create an IPSec connection between IIS and an Internet Security and Acceleration (ISA) Server 2000 firewall and create anther connection from the ISA Server 2000 firewall to a Microsoft SQL Server system. You can configure these connections to mutually authenticate with certificates and encrypt all traffic. If a hacker gains access to a computer in the DMZ, the hacker won't be able to contact the SQL Server machine, which requires that a certificate stored on the IIS server be set to the SQL Server machine from the IIS servers' IP address and won't be able to sniff the encrypted traffic. IPSec provides strong protection, and I recommend that you check it out.

IPSec can also implement state-aware port filtering. For example, if your IIS server address is 1.1.1.1 and that server connects to your SQL Server machine on 1.1.1.2, you can configure 1.1.1.1 to talk only to 1.1.1.2 and use only port 1433—for more details, see the Microsoft article "INF: TCP Ports Needed for Communication to SQL Server Through a Firewall" (http://support.microsoft.com/?kbid=287932). Similarly, you can configure the IIS public IP address to use only port 80 and any other required ports. IPSec is smart enough to allow outbound connections in response to requests on port 80. IPSec also lets you block port 80 outbound traffic so that you can't use Microsoft Internet Explorer (IE) to browse from the IIS server, a common security precaution.

Although the IPSec user interface requires some study, the Microsoft article "Building and Configuring More Secure Web Sites" (http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp) provides a detailed description. Joel Scambray and Stuart McClure also provide a good explanation of the benefits of using IPSec with IIS in their book Hacking Exposed Windows 2000 (McGraw-Hill Osborne, 2001).

To create IPSec rules for Win2K, you can use the Ipsecpol command-line utility, which is available from Microsoft at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/ipsecpol-o.asp. For example, to create a rule that allows only inbound traffic on port 80, you'd type

Ipsecpol \servername —x —w REG —p  "Port80Only" —r "BlockEverything" —nBLOCK —f 0+*
Ipsecpol \servername —x —w REG —p  "Port80Only" —r "Allow80" —n PASS 0:80+*::TCP

If you use IPSec port filtering, make sure you read the Microsoft article "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios" (http://support.microsoft.com/?kbid=811832) to see whether you should add the NoDefaultExempt registry setting on your server. If you don't add this setting and IPSec sees traffic coming from or going to port 88, the server will ignore your filters. This exempted behavior is designed to keep Kerberos working even if you specifically block the Kerberos ports. The registry setting, when present and set to 1, disables this exemption. I recently discovered that applying Win2K Service Pack 4 (SP4) installs this registry setting. For information regarding commonly used ports in Win2K, see the table titled Default Port Assignments for Common Services at http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cnfc/cnfc_por_simw.asp.

Disabling WebDAV
Few topics are more confusing than using WebDAV with IIS. WebDAV is an Internet Engineering Task Force (IETF) Request for Comments (RFC) standard (http://www.ietf.org/rfc/rfc2518.txt) that lets you create a client-side Web folder that uses a URL to map to an IIS server. You can then drag content to the folder to publish information on the Web server. Both IIS 6.0 and IIS 5.0 support this functionality.

WebDAV first came into prominent view with Microsoft servers with the release of Win2K. Still, many administrators don't realize WebDAV's potential power and potential risks. Of course, any capability that offers as much functionality as WebDAV is ripe for exploitation. As a result, it's no surprise that numerous security fixes have emerged that involve httpext.dll, the HTTP extensions that implement WebDAV.

My primary complaint about WebDAV, as implemented on Win2K servers, is that it installs by default with IIS, leaving you no way to turn it off in the IIS UI. Although Win2K administrators must live with these shortcomings, Windows Server 2003 administrators who install IIS 6.0 will be glad to know that WebDAV is disabled by default and that you can enable or disable it by using the Web Service Extensions node of the IIS console.

Some confusion surrounds the specific techniques for enabling and disabling WebDAV in Win2K because Microsoft produced three different methods for disabling WebDAV over time, each with its own advantages and disadvantages. Still, Microsoft recommends all three methods in various publications.

Deny Everyone the Execute permission on httpext.dll. To address the first serious WebDAV exploits, Microsoft recommended denying the Execute permission on the httpext.dll file. The IIS Lockdown tool takes this approach to disable WebDAV. However, this approach introduces two concerns. First, you must deny the Execute permission on all servers and make this change when you create a new server. Second, denying the Execute permission doesn't entirely disable WebDAV, as documented in the Microsoft article "Locking Down WebDAV Through ACL Still Allows PUT and DELETE Requests" (http://support.microsoft.com/?kbid=307934).

Add the DisableWebDAV registry setting. On a Win2K SP2 system or later, you can navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVCParameters registry subkey, add the DisableWebDAV setting, and assign it a value of 1 to disable WebDAV. This is an effective solution, but you must make this change on all your systems.

Use URLScan to block WebDAV verbs. In terms of advanced IIS security, the strongest advice I can give is to implement the URLScan security tool on your IIS servers. This tool does much more than disable WebDAV, so let's take a closer look at URLScan.

Implementing URLScan
URLScan is an Internet Server API (ISAPI) filter that runs on IIS 6.0, IIS 5.0, and IIS 4.0. When you install the IIS Lockdown tool on IIS 5.0 or IIS 4.0, you can optionally install URLScan 2.0. However, I suggest that you update to version 2.5, which adds some capability. You can download various versions of URLScan from the Microsoft Web site. By the time you read this, Microsoft should have released the URLScan installer for IIS 6.0. You have less reason to use URLScan on IIS 6.0 because IIS 6.0 includes most of the protection that the utility offers.

URLScan compares the incoming URL with rules that you configure in urlscan.ini (located with the urlscan.dll in %systemroot%system32inetsrvurlscan) and allows or rejects the request according to those rules. For example, you can configure URLScan to allow only requests for files that end with file extensions that you specify. Such a simple rule would defeat many of the most famous IIS exploits.

You can also configure URLScan to reject all requests that contain certain HTTP headers, such as the WebDAV headers in the following urlscan.ini file segment (thanks to Mark Burnett for his enhancements to this list):

[DenyHeaders] Translate: DAV: Depth: Destination: If: Label: Lock-Token: Overwrite: TimeOut: TimeType: DAVTimeOutVal: Other:

URLScan can also deny URLs that

You can use URLScan to log all rejected requests to a log file, then parse the log with Log Parser Tool 2.0, which is available at http://www.microsoft.com/downloads, or Log Parser Tool 2.1, which comes with the Microsoft Windows Server 2003 Resource Kit; send all rejected requests to a custom .asp page for processing; accept requests but log specific events as if they were rejected requests; and remove or change the server banner that IIS sends to the client.

Regarding URLScan's ability to deny URLs that exceed a specific length, most IIS URLs are short when compared to the length of a URL required to successfully cause a buffer overflow. By studying the length of the URLs required for your Web sites and enforcing a URLScan rule that rejects all requests that exceed your requirements, you're substantially increasing the security of your server. This one rule can prevent many attacks because you're forcing the hacker to come up with a URL that meets certain requirements (e.g., ending with a particular file extension; containing only specified HTTP verbs; not containing components such as high-order bits, extra dots, or slashes; being less than 400 characters in length).

The list of URLScan's capabilities is impressive for a binary with such a small footprint, no known vulnerabilities, and a negligible effect on performance. Remember that aside from changing the server banner (and the potential effect on applications that rely on the banner), URLScan only rejects requests to the server—the utility doesn't interfere with your applications or suddenly cause your Web server to become unstable. You can easily remove URLScan or place it into monitor mode, which causes URLScan to record but not enforce rejections.

Defense, Defense, Defense
When you're defending your Web servers against would-be hackers, it's essential to understand process identity so that you know how your applications interact with your NTFS permissions. Port filtering at your firewalls is also crucial, but you can use IPSec to implement host-based defense in the event your firewall is misconfigured, breached, or another server in the DMZ is compromised. Also, controlling WebDAV access to your servers is important, and URLScan lets you configure rules to help lock down IIS. Of all these suggestions, implementing URLScan and restricting the length of the URL are the most useful defensive measures you can implement. With all these tools to work with, hackers are shifting their attacks from the Web server toward the applications they deliver—but that's another story.