Data Centers

Securing IIS 6.0

IIS 6.0 introduces a whole new set of challenges to a network administrator, not the least of which is security. Here are some of the things you can do to increase IIS security.

Microsoft made several changes to Internet Information Services (IIS) 6.0 to improve security, not the least of which was a complete architectural overhaul. This change, combined with others in IIS function and management, make IIS 6.0 a more secure platform than previous versions. Many of the methods for securing IIS 6.0 are the same as in previous versions, but there are several new methods you can use to secure the server in general and specific sites in particular. Here are the most common methods you can use to secure IIS 6.0.

General server security
There are common threads for securing servers, regardless of the services they are running. Physical security, for example, is often overlooked, particularly by smaller companies. All of your servers should be in a locked room with limited access and proper site preparation for cooling, fire prevention, and power management. You should never leave a server logged on and unattended. You should always log off, but at the very least, press [Ctrl][Alt][Del] and lock the server. You should also use a limited logon account whenever possible and use the Runas command to start processes in the administrator context when your limited account doesn’t provide the necessary privileges for the management task at hand. Also consider implementing a strong password policy, especially for groups with administrative privileges. Deny remote access to the server unless absolutely necessary.

It’s also imperative that you protect the file system, and the only way to ensure such protection is to use NTFS on all partitions on the server as well as on any partitions hosting shared volumes that the server accesses across the network. Take the time to review permissions on all volumes and folders with an eye out for potential security risks. Also remove unnecessary shares, and hide shares by prefixing the share name with $ whenever possible.

Keeping the server up to date is another necessity. This means not only installing security updates and patches as they come along, but also ensuring that the server includes a working virus scrubber that you update at least once a week. A perimeter scrubber that monitors all incoming traffic is a great addition to your network as the first line of defense against viruses and worms, although you should include virus scrubbers on each server and workstation as well.

Finally, use member or standalone servers whenever possible to host IIS and dependent services. Keep IIS off of you domain controllers to improve DC performance but, more important, to ensure that if the server is compromised your domain security isn’t also compromised.

IIS 6.0 global security improvements
There are several changes for IIS 6.0 in Windows Server 2003 that improve server and network security. First, when you install Windows Server 2003, Setup does not install IIS by default (a significant security improvement for Windows Server overall). You can also configure group policy to prevent IIS from being installed. These two changes reduce the chance that IIS will end up on servers where it should not be, thereby reducing the network’s exposure to attack.

When you do install IIS on Windows Server 2003, Setup installs the software in a more secure state than in previous versions. For example, the server is configured by default to serve only static pages, with ASP.NET and CGI disabled. Other services and components are disabled as well, including server-side includes, Internet Data Connector, WebDAV, Internet Printing ISAPI, and Index Server ISAPI. FrontPage Server Extensions are disabled, as is the password change interface. The FTP and SMTP services are also disabled by default.

The architectural changes in IIS 6.0 also make for a more secure platform. Worker processes run in user mode and therefore can’t access privileged items in the kernel. They also run in the context of the Network Service account with relatively low privileges. Built-in ASP functions run in the context of the IUSR_machine account

Your capability to configure application pools enables you to limit the kernel request queue size, limit CPU utilization, and apply other restrictions to help ensure that an attack, when it comes, will have its impact minimized on the server overall. To help combat buffer overflow attacks, IIS 6.0 monitors incoming requests to identify unusually large transaction requests that are indicative of an attack. You can also configure IIS 6.0 to recycle worker processes if they consume too much physical or virtual memory based on limits that you specify on a per-application-pool basis, reducing the impact of memory overflow exploits. Your capability to isolate sites and applications using multiple application pools and to configure recycling parameters for those pools helps reduce the effect of denial-of-service attacks.

IIS 6.0 includes other features and changes to reduce its susceptibility to attacks. For example, IIS 6.0 serves only those file types explicitly defined by the administrator. If a request arrives for an unregistered file type, IIS 6.0 returns a 404.3 error to the client. The server also strips out scripts embedded in incoming requests before processing those requests. Command-line tools are disabled for IIS 6.0 by default, and running executable files is allowed only to members of the Administrators group and to selected built-in accounts, preventing anonymous users from running executable files. In addition, anonymous users are denied write access to Web content by default. Script source access is protected by a new permission, which is disabled by default. All of these features help block or limit the impact of various types of Web server attacks.

Authentication options for IIS 6.0
You’ll find some changes in IIS 6.0 authentication options that also improve site and server security. For example, anonymous authentication no longer requires the Log On Locally right. In addition, sub-authentication—which enables IIS to manage passwords for anonymous accounts, is no longer enabled by default. You can, however, enable it if needed.

UNC pass-through authentication is also changed in IIS 6.0 from previous versions. UNC pass-through authentication enables IIS to access resources stored on other computers through Universal Naming Convention (UNC) paths. UNC paths and UNC pass-through authentication are commonly used to support virtual directories hosted by other computers. If you specify a user name and password for a UNC share, those credentials are used by IIS 6.0 to access the remote resource.

Specifying an incorrect user name or password results in a 500 Internal Server Error to the client when the client tries to access the virtual directory. If no credentials are supplied, IIS 6.0 uses the credentials of the requesting client to access the resource. If the client is accessing the site anonymously, the account assigned for anonymous access (such as IUSR_machine) is used to authenticate on the remote server. If the client has specified account credentials, those credentials are used to access the remote UNC resource.

Also new in IIS 6.0 is support for Advanced Digest Authentication. Advanced Digest Authentication improves security because the MD5 hash is virtually impossible to decrypt. Advanced Digest Authentication provides higher domain security overall, as well, because Windows stores user credentials as an MD5 hash in the Active Directory, eliminating the need to configure the AD to store passwords with reversible encryption. In order to use Advanced Digest Authentication, clients must be running a Web browser that supports HTTP 1.1, must be in the same domain as the server or in a trusted domain, and the domain controller must be running Windows Server 2003. IIS drops back to Digest Authentication if the domain controller is not running Windows Server 2003.

Securing your server and sites
Now that you have some background in the security changes and improvements in IIS 6.0, you can turn your attention to protecting your sites and servers. First, let’s look at enabling and disabling Web service extensions. Open the IIS Manager console from the Administrative Tools folder and click the Web Service Extensions branch in the left pane. The IIS Manager displays the installed and defined extensions in the right pane, as shown in Figure A.

Figure A
You can allow or prohibit services.

To enable or disable a particular extension, select the extension in the list and click Allow or Prohibit, respectively. If you need to support ASP, for example, you will need to enable the Active Server Pages extension. You can also add new extensions from this branch.

Next, turn your attention to configuring application pools to help protect your server against attacks. To configure default application pool properties, right-click the Application Pools branch in the IIS Manager and choose Properties. When you do, you'll see the screen shown in Figure B.

Figure B
Application pools can help protect your server.

In the Memory Recycling area, enable the Maximum Virtual Memory and Maximum Used Memory options and specify the memory limits based on the system’s memory configuration and server load. It’s best to start with the suggested default values and adjust as needed.

Next, click the Health tab and verify that the Enable Rapid-Fail Protection option is enabled. Also click the Identity tab and verify that the default security account is set to Network Service.

Another security-related task you will likely need to accomplish is to configure the file types that IIS 6.0 will support. You do so by modifying the MIME type definitions for the server. You can configure MIME types on a global or site basis. To configure them at the global level, open the IIS Manager console, right-click the server, and choose Properties. On the Internet Information Services tab, click MIME Types to open the MIME Types dialog box. You'll then see the screen shown in Figure C.

Figure C
Configure the file types your server supports.

From here you can edit or remove existing MIME types or create new ones. Bear in mind that the global MIME type are inherited at the virtual server and directory levels. Unless you need to add a type globally, it’s best to add it only at the level where it is required. To manage MIME types for a virtual server, right-click the Web site and choose Properties. Click the HTTP Headers tab and click MIME Types to open the MIME Types dialog box, where you can accomplish the same types of tasks as at the server level. To manage MIME types at the directory level, right-click the physical or virtual directory in the IIS Manager console, choose Properties, click the HTTP Headers tab, and click MIME Types.

At this point, consider authentication requirements for the server and/or sites. To configure UNC pass-through authentication, right-click an existing virtual directory that points to a UNC share and choose Properties. This will display the screen shown in Figure D.

Figure D
You should set authentication on virtual directories.

On the Virtual Directory tab, click Connect As to open the Network Directory Security Credentials dialog box. Here you can specify an explicit set of credentials to be used to access the remote UNC share’s contents. If you want IIS to use the user’s own credentials to authenticate on the remote server, choose the option Always Use The Authenticated User’s Credentials When Validating Access To The Network Directory. Keep in mind that if you enable this option, anonymous users are authenticated with the server’s IIS_machine account. Configure accounts and permissions as necessary on the server hosting the share. Craft your authentication scheme to provide only the bare minimum permissions necessary for each user to perform his or her specific tasks in the folder.

Next, look at the authentication requirements for the Web sites or specific directories that use other than anonymous authentication. Right-click the Web site or directory, choose Properties, and click the Directory Security tab. Then click Edit in the Authentication And Access Control group to open the Authentication Methods dialog box.

To prevent anonymous access, deselect the Enable Anonymous Access option. Select the other authentication methods you need to support from the Authenticated Access group. If you choose Digest Authentication, IIS 6.0 will attempt to use Advanced Digest Authentication and, failing that, will fall back to Digest Authentication. If you choose Digest Authentication or .NET Passport Authentication, you also need to specify the Realm and Default Domain, respectively.

While you have the Directory Security tab open, consider whether you need to impose connection restrictions on the Web site or directory. If you have a directory that should be accessible only by users internal to your LAN, click Edit in the IP Address and Domain Name Restrictions group, then add the individual IP address or subnet ranges of the allowed clients. You can also specify a domain name, but using this option requires a reverse DNS lookup, which imposes server overhead and requires that the clients have their IP addresses appropriately registered in DNS.

You should also verify permissions for each site and virtual directory. Open the site’s or directory’s properties and click the Home Directory or Directory tab. This will display the screen shown in Figure E.

Figure E
Set permissions on the Home Directory.

Ensure that you have not enabled Write permission unless users need to be able to post to the site. Script Source Access and Directory Browsing should be disabled unless specifically needed, and Execute Permissions should be set to None unless you want to enable scripts to execute. Finally, it’s a good idea to remove all of the extra default documents that IIS adds for a site or directory. Click the Documents tab and remove all but the specific default document your site or directory uses.

Securing other functions
When you finish configuring Web site properties, you’re not finished configuring server security. Although IIS 6.0 does not by default enable FTP or SMTP, you should review security for these services, as well. In the case of FTP, I recommend you disable anonymous access for FTP before ever considering taking an FTP site live. If you do want to provide anonymous access for users, create a virtual directory named anonymous and configure that directory’s permissions as needed for anonymous users.

Under this directory, add the directory structure you want anonymous users to see. Disable Write permission in the site’s main folder, and then only after verifying the underlying NTFS permissions of each directory should you enable anonymous access. By creating a virtual directory with the alias "anonymous", you force anonymous users into that virtual directory when they log on. Although they can CD to the site’s root folder, you have disabled Write permission, preventing users from writing to the home directory. Create other virtual directories for authenticated access by other users, matching the virtual directory alias to the user’s name, which will cause the user to be placed in that directory when they log on.

For the SMTP service, review the relay settings to ensure that your server will not be used for unauthorized relay. Open the properties for the virtual server, click the Access tab, and click Relay. Choose the option Only The List Below, then click Add and add the IP address, subnet, or domain hosts that can relay through the server. Keep the list as restricted as possible.

Don’t stop there!
Securing your IIS 6.0 server certainly isn’t a one-click operation. When you finish reviewing all of the security-related properties on the server, turn your attention outward. Add-on applications, network and company policies, firewall configuration, and a host of other non-IIS issues ultimately affect IIS server security. Identifying these and reviewing them in light of overall security can go a long way toward securing your servers and your network.

Editor's Picks

Free Newsletters, In your Inbox