Share via


Security in IIS 6.0

Innovations in Internet Information Services Let You Tightly Guard Secure Data and Server Processes

Wayne Berry

This article assumes you're familiar with IIS

Level of Difficulty123

SUMMARY

Security improvements have been a top priority in the evolution of IIS. IIS 6.0, which will be part of Windows .NET Server, has improved security features and a new approach to server configuration. New security-related tools for IIS, including IIS LockDown, make securing your server against attack easier than ever. The author explains how and why you can shut down services with IIS LockDown. He discusses limiting port access with TCP/IP filtering, controlling how files are served with extension mapping, what's new for Secure Sockets Layer, the use of URLScan, and more.

Contents

Intrusion Prevention
Securing IIS 5.0
What's New in IIS 6.0
Windows .NET Server
SSL Improvements
TCP/IP Filtering
More Security Improvements
Some Assembly Required
Conclusion

As you certainly have noticed, Microsoft is pushing security. Tools recently released for Internet Information Services (IIS) 5.0 and a redesign of security in IIS 6.0 that ships with Windows® .NET Server point in this direction. Security is a broad topic that encompasses authentication, authorization, encryption, and intrusion prevention. While previous versions of IIS have dealt with authentication and encryption, other areas like intrusion and denial of service attack prevention, and Web-based viruses had been left for firewalls to deal with.

In IIS 6.0 and the new tools that shipped for IIS 5.0 there is an emphasis on making the Web server even more secure against attacks. Jeff Prosise covered authentication in his two-part series "ASP.NET Security: An Introductory Guide to Building and Deploying More Secure Sites with ASP.NET and IIS," in the April and May 2002 issues of MSDN® Magazine. This article will discuss intrusion prevention, URLScan, IIS LockDown for IIS 5.0, the new security features of IIS 6.0, and the Web Server functions planned for the upcoming Windows .NET Server.

Intrusion Prevention

Intrusion prevention is the art and science of allowing people to access, execute, and control only the parts of your Web site that you want. In the beginning, Web servers delivered static content and a Web administrator's only true file access concern was to prevent private files from being served to a client. Now that you can execute script on the server, Web administrators must also prevent the execution of uninvited code. Since Web server intrusion happens from both inside and outside a company, Web administrators need to lock down the server from both sides of the firewall to ensure security.

The first step in intrusion prevention is restricting who can put files in the root directory of the Web server; anyone who is able to put an ASP page there can execute it with no additional permissions. Intrusion prevention also means preventing intruders from uploading files via HTTP, WebDAV, or FrontPage® extensions, for the very same reason. Intrusion prevention must also stop an intruder from accessing or modifying restricted files, such as Windows system files.

Intrusion prevention should limit the ability of intruders to make requests outside of the scope of the Web site. For example, a request for an .idc (another type of dynamic file) when there are no IDC files on the Web server can reveal to a hacker that he can find a way to put an .idc file on the server and, since they're not already in use, the administrator has probably not secured against them. Once there, the hacker can execute the .idc file. Another attack that must be prevented is the passing of bogus values in a HTML form to change the execution of the code that processes the form.

Intruders sometimes attack machines by targeting unmonitored running services. An example is a domain server whose default installation included IIS even though it would never be used as a Web server. Since the administrator may not remember to install the latest service pack on a service he's not using, security weaknesses could be exploited.

Here's an example that happened to me. I needed a file from a friend who wanted to upload it via FTP. I started the FTP server that is installed with IIS 5.0 and enabled write privileges for the anonymous account. I knew this was asking for trouble, but he said he would upload it right away. It took him three days to get to it and by that time two people had uploaded full-length movies to my server and were using my bandwidth and server space for free. While my hard drive had a lot of extra room to handle these movies, the hacker could have filled my drive, taking down my server. (Not to mention that I was then in possession of illegal content.)

Port scanners and other hacker tools that find vulnerable machines from a random block of IP addresses allow these types of attacks to happen. I have had machines on my network scanned as often as every 20 minutes.

Keep in mind that my Web site is not huge; it's not even a medium-sized site, which just goes to show that hackers are not only going after the very biggest sites—even the smallest ones are vulnerable for use as launching pads.

So remember, while it's nice that the Web server functionality was installed and ready to go with the default installation of the operating system, having services run that you're not aware of can pose a security problem.

Securing IIS 5.0

Microsoft has recently released two new tools to help IIS 4.0, 5.0, and 5.1 administrators deal with intrusion prevention: IIS LockDown and URLScan. IIS LockDown Wizard has an interface that secures the server by installing URLScan, changing metabase settings, and disabling services that aren't used. URLScan monitors all incoming URLs and prevents requests that are outside of the scope of the Web site.

The IIS LockDown wizard walks the administrator through a series of questions that determine exactly which features should run (as shown in Figure 1).

Figure 1 Server Templates in the LockDown Wizard

Figure 1** Server Templates in the LockDown Wizard **

If you're worried about FrontPage extensions, WebDAV, or a rogue script writing content to your Web server, IIS LockDown will deny write permissions on Web directories to the anonymous account and disable WebDAV (see Figure 2). Administrators who use a fixed dynamic extensions list (such as ASP files only) will find that IIS LockDown will remove .idc, .stm, .printer, and other dynamic script types. IIS LockDown can also restore the IIS metabase and the file system Access Control List (ACL) to the security setting of the default installation and back up the metabase prior to installation just in case the new security settings render your Web site unusable.

Figure 2 Disabling WebDAV

Figure 2** Disabling WebDAV **

In IIS 5.0, the HTTP and SMTP servers install by default and the FTP and NNTP servers are optional, and all can be set to manual start by using the IIS LockDown Wizard. Because servers that don't use these services are open to attacks—from spammers using the SMTP server as an open relay or from hackers looking for free disk space on your FTP server—it's a good idea to shut down services you don't use.

URLScan is an ISAPI Filter that monitors all incoming requests and looks for attacks on the system like those mounted by Code Red or the Nimda virus. Typical attacks include trying to overflow the buffer of the Web server to expose the operating system, or tricking the Web server into running or manipulating files that are not supposed to be accessed.

A buffer overflow risk can be incurred when a programmer allocates a limited amount of memory to a task, and that memory is accessed beyond the assigned range. This can happen when the programmer doesn't make sure that data fits in the allocated space. Since many applications allocate memory for URLs, sending long URLs is a common technique used to produce a buffer overflow. In order to protect applications that might receive such information (IIS, ASP, SSL, compression, custom ISAPI filters, and so on), URLScan prevents URLs that are longer than a preset size from gaining access to these applications. The maximum size of the URL is configurable by the administrator, as are all the settings in URLScan.

URLScan also prevents non-ASCII characters from being used in a request. Typically these characters are sent to the server directly following the buffer overflow. They can consist of precompiled operations that the hacker hopes the Web server will execute. These operations can span all byte ranges. By preventing non-ASCII character submission, you can restrict these types of attacks.

URLScan also allows the Web server administrator to limit the size of query strings processed by the server, as well as the size of the response. Limiting the size of the query string can prevent buffer overflows and restricting the size of the download prevents overload of the system, another common intrusion trick.

URLScan can log any request that breaks the preset rules. This is especially helpful when first implementing URLScan with liberal restrictions; you can use the log file to find legitimate requests that are being denied.

URLScan has an option to return a custom error message for any illegal request. Be careful here, for cunning hackers can elicit error messages to find out what's legal and illegal on your system.

As a side note, one of the easiest ways for internal hackers to access your system is to use the default shares that are installed at the drive level. For example, c$ is a hidden share on every machine running Windows NT® and Windows 2000. This default share can be accessed via a UNC path: \\machinename\c$. Note that removing these shares after installation is highly recommended.

What's New in IIS 6.0

There are three main security changes in IIS 6.0 that will reduce the risk of intrusion. When you install Windows .NET Server, IIS will not be installed unless you request it. Once installed, IIS will serve only static file unless you configure it to serve dynamic content as well. IIS 6.0 is fully locked down by default and includes an easy-to-use user interface for enabling applications. Another security enhancement involves the new request processing architecture in IIS 6.0, which includes process recycling. An administrator can easily install most IIS security hotfixes and new worker process DLLs without interrupting service. Additional isolation features include bandwidth and CPU throttling, and memory-based recycling. These additional features provide an environment for independently securing multiple sites on one Web server.

The default logon type for basic and anonymous authentication in IIS 6.0 has been changed to NETWORK_CLEARTEXT. This is a change from previous versions of IIS, for which the default logon type is INTERACTIVE. This means that users will no longer have interactive logon privileges, so domain controllers will be able to operate as servers while exposing themselves to less risk.

Web server attacks often take advantage of command-line tools that are accessible via the Web server. IIS 6.0 does not allow these programs to be executed.

Hackers often deface Web sites once they gain access. IIS 6.0 provides write protection for content, so anonymous Web users are prevented from overwriting Web content. Upload data limitations allow administrators to limit the data that a malicious user can upload to a server. Timeouts that were previously set too leniently are set to more aggressive defaults in IIS 6.0, and a worker process will now detect and exit a program if a buffer overflow is detected. The core server will even verify that the requested Web content exists before the request is then handed off to an ISAPI extension handler.

More and more customers run multiple applications or sites on one Web server. This puts certain requirements on a Web server. If an ISP hosts two companies (they can even be competitors) on one server, these two Web sites must be completely isolated from each other. IIS 6.0 provides this level of isolation through the configurable worker process identity, CPU and bandwidth throttling, and memory-based recycling.

The worker process runs as NetworkService, which is a new built-in account with limited privileges. One of the most important principles of security is to grant accounts the smallest set of privileges they need for an operation. Since NetworkService has few rights on the underlying system, rogue applications have less of a chance to exploit security vulnerabilities.Along with the IIS 6.0 changes, port filtering was added to Windows .NET Server at the TCP/IP level.

Windows .NET Server

The Windows NT Server family has a long history as a file server, and a more recent history supporting a robust Web server. In Windows 2000, IIS was installed automatically with both the Server and Enterprise versions. With Windows .NET Server, IIS is secured by default when the operating system is installed (more about this lockdown mode later) or not installed at all, depending on your license. So if you're deploying a machine to run a mail server, SQL Server™, or just the operating system itself, you don't need to uninstall IIS to gain the additional security features. IIS ships with all versions of Windows .NET Server; it just needs to be installed as an option.

IIS is also disabled when you upgrade a server to Windows .NET Server, so you have to manually enable it. This prevents accidental installation carryovers from previous OS versions. Domain administrators can prevent users from installing IIS on machines running Windows .NET Server.

SSL Improvements

IIS 6.0 implements several improvements to its software-based SSL implementation. In addition to better performance tuning, IIS 6.0 gives administrators a remotable certification object and selectable crypto-service provider.

You can't manage SSL certificates remotely in IIS 5.0 because the cryptographic service provider (CAPI) certificate store is not remotable. The CertObject, new in IIS 6.0, allows administrators to manage hundreds or, for that matter, thousands of IIS servers with SSL certificates.

If SSL is enabled, performance will drop dramatically because the CPU is required to perform intensive cryptography. In addition to the default CryptoAPI services, you can now plug your own CAPI provider into the system—software or hardware. Accelerator cards let you offload the security processing and improve the throughput of your server.

TCP/IP Filtering

Another security feature is the ability to do TCP/IP port filtering within the network settings of the operating system. Somewhat of a misnomer, since the TCP, IP, and UDP are filtered with a single tool, TCP/IP filtering does provide better security for the Web server.

In Windows 2000, when you set up an IP address any application running on the box could monitor any port on that IP address. This meant that you could install a service or applications that used IP ports that you were not aware of. One example would be an administration Web interface that lived behind port 8080. In other words, someone inside your firewall, or even an application on the box itself, could use ports to expose the box to attacks.

With Windows .NET Server, you can use the Network Setting to limit which ports are open and reduce these kinds of attacks. To do this, open the Internet Protocol (TCP/IP) Settings under Local Area Network Settings. Click on the Advanced Button and select the Options tab. Choose TCP/IP Filtering and click on the Properties button. This brings up the TCP/IP filtering dialog that allows you to enter the ports you want to filter (see Figure 3). There are three port columns that allow you to enter the ports you want to monitor on each protocol.

Figure 3 TCP/IP Filtering

Figure 3** TCP/IP Filtering **

Here you might be tempted to select Permit Only and enter port 80 to limit traffic to Web requests. However, this would not allow you to transfer files to this machine, send e-mail, use SSL, or run your FTP server. So it is best to do a little research before closing down all the ports on the machine. For example, if you are using SSL and running an FTP server, you will also want to add ports 443 and 20, respectively. Since you need to have TCP/IP access to this machine you need to add these ports to both the UDP column and the TCP column. If you want to be able to resolve the name of the SQL Server database from your ASP page via its computer name, like the following

<% Set oConn = Server.CreateObject("ADODB.Connection") oConn.Open "Trusted_Connection=yes;driver=SQL Server; server=SQLMACHINE001;database=MyData;" %>

you are going to need to open the WINS port 137,138,139 (UDP). If you want WebTrends to be able to do reverse DNS translation on your log files, you'll need to open the DNS defaults, ports 42 (UDP), and 53 (TCP/UDP). Regardless of the amount of time it takes to figure out which ports should be secured, it is best to select Permit Only and find those ports, instead of trying to exclude the port specifically. Figure 4 shows a list of commonly used ports.

Figure 4 Some Common TCP/IP Ports

Port Protocol
21 FTP
23 Telnet
25 SMTP
53 DNS
68 DHCP
70 Gopher
80 HTTP
110 POP3
119 NNTP
135 RPC, DNS, DHCP
139 Inbound SMB Sessions
143 IMAP
389 LDAP
443 HTTP (SSL)
445 Inbound SMB Sessions
1433 Microsoft SQL Server
3389 Microsoft Terminal Services
8080 HTTP Alternate

This isn't a replacement for a firewall. Firewalls allow you to restrict ports in both incoming and out-going directions, whereas the TCP/IP filter does not. With TCP/IP filtering you need to open outgoing ports that your ASP code might use even though it opens these ports to incoming requests. Second, a firewall usually does network address translation, allowing you to have a private range of completely hidden IP addresses.

With TCP/IP filtering, you can apply the port restrictions on a per-network-card basis. For example, if you have an internal network card used to access internal resources, like SQL Server, DNS, WINS, and Domain Authentication, and an external network card that communicates with your firewall for Web requests, you could set the port settings differently for each.

More Security Improvements

Passport is integrated into Windows .NET Server as a supported authentication mechanism for IIS 6.0. Once Passport authentication is properly verified, a user can be mapped to the local domain's Active Directory through their Passport identification. A token is created by the Local Security Authority (LSA) for the user, and used by IIS for the HTTP request. Applications and Web sites can use this security model to authorize users locally. The new Constrained Delegation feature of Windows .NET Server (discussed later) also lets apps delegate these credentials.

URL Authorization lets IIS 6.0 provide gatekeeper authorization to specific URLs. Why is this new feature important? ACLs are used to make authorization decisions in IIS 5.0. The problem with the ACL model is that it's object-driven, locking individual files and directories and trying to fulfill the requirements of NTFS. Most Web applications deployed by an enterprise are business applications, making them operation or task-based. The new authorization framework in Windows .NET Server provides the means to fulfill this need. Web apps can use IIS 6.0 URL Authorization along with the Windows .NET Server authorization manager to control access to URLs that comprise a Web app and app-specific tasks and operations, all from a single policy store.

When you provide authorization by URL and not ACL, you need to make sure that the process has the proper rights through a process called delegation. Delegation is the act of allowing server applications to act on behalf of a user on the network. For instance, a Web service application on an intranet might access HR information from a number of servers in the enterprise, then present the consolidated data via HTTP to the user as a Web page. This works especially well when designing an application suite for Windows deployment. There are a number of ways to leverage high-level protocols, such as RPC and DCOM, to carry user context across servers, impersonate the user context, and authorize against objects as the user.

At the same time, delegation provides a number of potential problems. For instance, delegation should not let a service connect to any resource anywhere in a domain. A service should have a limited set of services to which it can connect (maybe a SQL database or a remote file store). Otherwise, a malicious administrator or app could potentially authenticate against any resource in a domain on a client's behalf. A client should also not have to share its credentials with the server.

Constrained delegation is a feature of Windows .NET Server that helps solve these problems. Domain administrators can allow delegation to a limited set of machines and services. Users can arrive at the site through any authentication protocol and still have constrained delegation work for them.

Some Assembly Required

IIS 6.0 is installed in lockdown mode, which means that it will not serve any page unless you explicitly approve particular extensions. This new feature is implemented differently for static files than for dynamic extensions. Static files do not need to execute code between a request and its response. These files include graphics, HTML pages, and cascading style sheets. Dynamic pages, such as ASP and Cold Fusion pages, require execution.

In order to serve static pages with extensions, like .htm, .html, and .gif, those extensions must be listed in the MIME Map, a new configuration setting of the IIS metabase that is unrelated to the operating system's mapping of MIME types to extensions. You add the extensions via the new IIS 6.0 property page; commonly used types are already listed by default.

Controlling which kinds of files can be sent as viewable to the client is a valuable configuration option. To employ it, you use a .inc extension for your include file. Suppose you don't want your include files to be viewable. For example, you have a default.asp file that includes a file called sql.inc. If an intruder knew about the sql.inc file, they could request that file directly from the Web site and it would be returned as a text file. If that file contains the login and password to a SQL Server database, you're toast. You can avoid this type of problem in IIS 6.0, because unless you specify that you want files with the .inc extension to be served, an intruder cannot request them. This brings up another interesting point. You do not have to add extensions of include files to the MIME Map in order to have them included. In other words, you don't have to add your custom include file extension to the MIME map in order for them to work correctly—they just won't be sent to the client as text.

Files with dynamic extensions will not be compiled, executed, or served with the default installation of IIS. In order to have them served, you will need to add their extensions to the Web Service Extensions list. This prevents anyone from calling a page with a dynamic extension that you have not secured against. So, after you upgrade to IIS 6.0, you will need to add the .asp extension in order for your ASP pages to work. However, before you add the extension to the list, you will need to make sure that your computer is safe to run pages. For example, you must prevent strangers from being able to put ASP pages in the root of the Web site. Notice that this is the opposite of what you do with the IIS LockDown tool that shipped with IIS 5.0; with the LockDown tool you disable extensions—with IIS 6.0 you enable them (and can disable them when they're no longer required).

It's interesting to note that when a request is made for an extension that is not permitted, IIS 6.0 returns a "404 file not found" error rather than a "403 access denied" error in the response to the browser, even if the file exists. This limits the amount of information available to potential hackers and keeps them in the dark about which extensions have been restricted.

Conclusion

Notice that the responsibility shifts from the software maker to the administrator with the new installation of IIS 6.0. Now administrators are responsible for what services they enable, so they can turn on services they want to use and not enable any services they don't need.

This push for security is making IIS 6.0 more secure, and tools like IIS LockDown for IIS 5.0 give administrators some of the advantages of IIS 6.0 before they upgrade.

For related articles see:
Configuring Security for Internet Information Server
Microsoft Internet Information Server Security Overview

For background information see:
IIS Lockdown Tool
Internet Information Services (IIS) 5.0
Security

Wayne Berryis the architect of XCache Technologies' XCache, XCompress, and XTune. He is a former Microsoft design engineer, founder of 15 Seconds, and ASP developer. Wayne's expertise includes software design, performance consulting, development, and online business.