Securing your IIS 6.0 installation is an important task. The amount of work required can vary greatly depending on the complexity of your application as well as your infrastructure and how these combine with your need to secure content.
Too often, Web server security is seen as merely a series of steps taken to tighten access to the server. But at Microsoft, the policy is to implement defense-in-depth. This begins with an actual written policy that describes the actions to take should you be hacked. Securing your IIS installation is just one of several tactics, but it is an important one. In this column, I’ll cover nine important steps you can take to get a lot of security improvements with little impact on your applications, administration tasks, or Web server. Keep in mind that these tips are based on my experience and not necessarily Microsoft practice.
1. Place your content on a non-system drive
Let’s say your Web site files are stored at C:\inetpub\wwwroot. IIS receives a request for http://website/../../. What folder is IIS going to deliver from? In this case, it’s the root of the C drive, as “..” is a valid file system command that says move up one directory level (this is sometimes referred to as the parent path as it represents a path of the parent folder without knowing the actual name).
This is no different than opening a command window in the same folder and typing “cd..”. As a result, the URL http://website/../../winnt/system32/cmd.exe is often found in IIS log files. This attack will fail when using the latest versions of Internet Explorer® as they will not permit “..” in a URL, but attackers will use other HTTP clients to try to circumvent this failsafe. Of course, IIS 6.0 also includes protections against this sort of attack. IIS will utilize a canonicalization routine to map the URL back to the intended file to ensure that the user does not leave the root path of the site. Nevertheless, placing Web content on a non-system drive is an extra safeguard you can put in place to protect your system data should an attacker somehow circumvent these built-in countermeasures.
2. Disable Parent Paths
There’s more than one way to do a directory traversal attack. As a result, it is best to ensure that parent paths are disabled. In IIS 6.0, the ability to use parent paths in files and ASP scripts is disabled by default, and it’s best to keep it that way to prevent attackers from injecting code into your applications that may allow them to browse your directory structure. Be sure to have your developers write code that does not make use of “..” in a URL or script when at all possible.
3. Check and Double-check Your NTFS Permissions
Proper access control lists (ACLs) on your files are the bedrock of your Web server security. You can harden all you want but if you mess up here, the game is over. So here’s how you should set permissions. Execute permission is needed for binary executables such as DLLs and EXEs. You should set Read permission for static content and scripts. You may have thought scripts required the Execute permission, but they don’t so you should not allow it. Only grant Write permission to security principals and resources that require it. Anywhere you permit Write and Execute, monitor for appropriate content. Create a group for users who need to publish to a Web site and assign Write permissions to the group. This makes administration easier.
Systernals provides a great tool called AccessEnum for helping you inspect your permissions. For more information, see sysinternals.com/Utilities/AccessEnum.html.
4. Know the Group Membership of the Anonymous User and Enforce Restrictive Permissions
The IUSR account (named IUSR_servername) is the account user to provide anonymous access to Web content. Created during the installation of IIS, IUSR is unique to each server. When anonymous access is enabled and NTFS permissions allow the kind of access requested (for example, Read permission for the IUSR account), IIS will access the content as if the request were made by someone who logged on as the IUSR user. This involves some sleight of hand behind the scenes that can get a bit involved. In a nutshell, though, IIS knows the password of the IUSR account and uses that password to automatically log the user onto the server.
Just like any user, the IUSR account has some group memberships. Giving permissions to any of these groups gives the IUSR account access to the content. The default memberships are: Everyone, Users, Guests, Authenticated Users, Network, Domain Users (if IIS is on a domain controller), and Web Anonymous Users (if the IIS portion of the Security Configuration Wizard has been run).
You can verify membership by using the W3Who.dll program from the IIS 5.0 Resource Kit. This ISAPI executable will report on the group memberships and rights of whoever invokes it. Put this file in a folder that has NTFS execute permissions for the IUSR account and allow anonymous access. Also configure the folder to allow Execute in the IIS manager and permit the executable to run in the Web Service Extensions configuration. Then invoke the DLL directly by typing http://servername/folder/w3who.dll to get the report.
If you don’t have a Web Anonymous Users group on your Web server, you should create one and add the IUSR account to this group. You can then take the extra measure of denying Write and or Execute permissions to this group in strategic locations. One of the key benefits of this approach is that you can add more users to the Web Anonymous Users group thereby enforcing more restrictive permissions on those special users who may try to poke around where they don’t belong.
5. Limit Ports Exposed to an Untrusted Network
Each open port on a Web server has a specific service listening for incoming requests. Typically, IIS listens on port 80 for HTTP and 443 for HTTPs connections. IIS has no requirement for any ports to be open other than those you want to use to communicate with the client. An attacker will find all the ports your server has open and attempt to exploit the listening service. As a result, it is very important to reduce the number of ports and services you expose to an untrusted network to the bare minimum.
The IIS server will typically communicate with a firewall which is designed to filter out all traffic that does not conform to a specific set of rules. Firewalls are highly reliable devices in general, but can be compromised due to misconfiguration or exploitation just like any other device. To practice defense-in-depth, design your site as if the firewall were local on the IIS server.
There are three techniques available aside from using commercial software. You can disable unnecessary services, use Windows® Firewall for port filtering, or use IPSec for port filtering, encryption, and authentication. Here’s what you need to do.
You can disable unnecessary services in the Service console. There you will notice that Windows Server™ 2003 has fewer services enabled by default than Windows 2000 did, but you should verify the services that are running to ensure they are all necessary in your environment and disable any that are not.
There is some risk involved as you may disable a service that is required by your server for purposes other than delivering Web content. The Security Configuration Wizard that is installed with Service Pack 1 (SP1) will help you safely reduce the number of services used by your server. You can do even more fine tuning if you take some time to study what these services do.
The most complete documentation I’ve found on disabling services is “The Threats and Countermeasures Guide”. You’ll find a complete list of the services installed, what they do, and what ports they use in the Services section. This is a must-have reference.
You can also disable File and Print Sharing and in some cases the Client for Microsoft Networks (as shown in Figure 1). This works well when you have a network card dedicated to communicating to the untrusted network that is restricted to Internet protocols.
Figure 1 Disable Services
Figure 1 Disable Services
Typically you will want your IIS server to communicate with other devices on the network to provide additional services for administration, authentication, database access, and monitoring. These services require additional ports and services to be available over the network. In this situation, you will want two networks available to IIS. One network connects to the firewall that receives requests from an untrusted network and has a minimum number of ports and services exposed. The other is the network that has been designed for secure internal communication, and can allow more services to be enabled. In this situation, it is very important to monitor IIS carefully so that if the server were to be compromised, the attack would quickly be identified to prevent the attacker from gaining access to the back-end network.
If you use Windows Firewall (see Figure 2), included with SP1, for port filtering you’ll find that it’s easy to restrict the ports exposed by the server. You can also specify which IP addresses the server will accept connections from. This allows you to create a rule that says “only communicate with the firewall’s IP address on ports 80 and 443.” When you implement port filtering in this way, you further reduce the exposure of ports to the untrusted network. In addition, by requiring IIS to communicate only with a specific IP address, such as a firewall, you help to prevent attacks that would redirect the IIS traffic to another device that may have been compromised by an attacker. You access the Windows Firewall settings by clicking the Advanced tab in the network interface properties. You can also use the Netsh command-line tool to configure the Windows Firewall from a command prompt or a script. You can find more information on Netsh by taking a look at “Help: Administering Windows Firewall with Netsh”.
Figure 2 Windows Firewall
Your third choice, as I mentioned, is to use IPSec for port filtering, encryption, and authentication between servers. IPSec is great for securing connections to back-end network devices and has more capabilities than Windows Firewall. For details see “How To: Use IPSec to Provide Secure Communication Between Two Servers”.
Share This
