Relevant Technologies: Tightening IIS

Back to Article List

Tightening IIS
By Brien Posey
June 2, 2002

Your Web Server is Exposed
Few components in your network are as important to secure as your Web server. That’s because your Web server is exposed to the outside world (even if through a firewall), and could potentially be attacked at any given moment. Unfortunately, there are literally hundreds of different things that must be done in order to achieve a truly secure Web server. In this article, I’ll share some of the more important hardening procedures with you.

You Must Also Secure Windows
As you look for ways to secure IIS, you must remember that Web servers, particularly IIS, are modular in nature. Simply securing IIS isn’t enough. You must also make sure that the underlying Windows operating system is secure. Additionally, you must work to secure any network links to the IIS server and any firewalls that stand between your IIS Server and the outside world. As you can see, this can quickly become a very big job.

Put Your IIS Server on a Completely Separate Network
One of the most important aspects in network security is the way that you position your Web server within your organization. I personally recommend placing your IIS servers on a completely separate network from your normal private network. The idea is that if your Web servers have their own Internet connection, firewall, cabling, hubs, etc., and have absolutely no physical or logical link to your normal private network, then it would be physically impossible for a hacker to exploit a weakness in your Web server in order to gain access to your private network.

Although this is an ideal architecture, it may not be practical or feasible because of business needs. For example, your company may not have the budget to buy all of the extra hardware, or to pay for two separate Internet connections. Additionally, if your Web servers are connected to a dedicated network that’s completely cut off from the rest of the company, then only workstations that are connected directly to that network are capable of updating the Web site. Therefore, if you have a lot of users who collectively update the site, or if your Web site pulls data from another server (such as a SQL server), then isolating the Web servers doesn’t make sense.

Regardless of whether you’ve isolated your Web servers or not, you should never allow an IIS server to be a domain controller. Domain controllers contain sensitive account information. You don’t want this account information to exist anywhere on a server that’s exposed to the outside world. The idea is that if the server’s security were to be compromised, then you don’t want the hacker to gain account information.

Protect Your User Accounts
Suppose for a moment that you were able to set up IIS on a dedicated network containing nothing but your IIS servers, a domain controller, and maybe a workstation or two that are used for updating the Web site. Guarding user account information is just as critical on this small network as it on your enterprise network.

There are two different schools of thought on user account security on small networks. One school of thought consists of the idea that the fewer user accounts that exist, the tighter the security will be. If you subscribe to this idea, then your dedicated network will probably have the Administrator account, the IUSR_servername account, and maybe one other account that’s used for maintenance purposes.

The only problem with this approach is that if a hacker were to somehow gain access to your account information, it would be extremely obvious which account did what. This is where the other school of thought comes into play. Some people tend to think that it’s a good idea to create several hundred bogus user accounts, and then disable them. They then rename the Administrator account and the IUSR_servername accounts to something that will blend in with the bogus accounts. Doing so makes it harder for a hacker to determine which accounts are the real ones (although hacker utilities do exist that will tell you the name of the Administrator account).

Both of these methods have advantages and disadvantages. Therefore, neither of them is clearly the correct choice. I recommend using the method that you feel most comfortable with.

Administrative Passwords
The subject of password security has pretty much been beaten to death over the last fifteen years or so. Therefore, I won’t bore you with things like password length or tell you to change your passwords often. What I will tell you is that there’s a utility in the Windows NT and Windows 2000 Server Resource Kit called PASSPROP, that you can use to enforce password complexity. For example, you can use the utility to insure that passwords are made up of letters, numbers, and symbols, not just letters.

Another area that needs to be addressed is the administrative password. Earlier, I said that I recommend making your IIS server a member server in an isolated domain. What you may not realize though is that member servers contain a local administrative account that can be used to log directly into the system, rather than into the domain. This password is set during the initial Windows 2000 installation process. I strongly recommend setting the local administrative account to something that’s different from the domain administrative account. That way, if someone does exploit the server to get the password, the password will only work on that one server, and your domain’s security will not be compromised.

Another step that I recommend taking is to use a different administrative password in your isolated domain then you use for the rest of your network. By doing so, you insure that no one can use the password from one domain to access another.

Services and Applications
By far one of the biggest security holes on any server are unnecessary services and applications. Remember that services and applications are made up of binary code. Statistically, the more code that’s running on your system, the greater the chance that there will be a security weakness in the code. Therefore, think minimalism when deploying servers.

If you take the approach of using an isolated domain, then the domain will have two kinds of servers, Web servers and domain controllers. There are specific things that you should look for on each.

On both the Web servers and the domain controllers, I recommend opening the Control Panel and then double clicking on the Add / Remove Programs icon. Now, remove any programs that aren’t absolutely essential. Be sure to remove things like the Windows 2000 Support Tools and the Terminal Services, unless you really need them.

Now, click on the Add / Remove Windows Components icon. You’ll now see a list of all of the various components that Windows has installed. Again, think minimalism. For example, although applications such as Paint and Notepad usually aren’t associated with security problems, I recommend going ahead and removing them, because you never know if a security flaw could be discovered tomorrow. While on this screen, you should also make absolutely sure that IIS isn’t installed on your domain controllers.

Once you’ve removed any unused applications, close the Add / Remove Programs window, and select the Services command from the Administrative Tools menu. You’ll now see a list of all of the services that are running on the system. After verifying that your system is running correctly and that all necessary services have been started, disable any services that aren’t presently started. I then recommend going through the list of services and evaluating each service to see if it’s really necessary. If you find an unnecessary service running, then you should stop the service and then disable it.

W3C Logging
Once you’ve disabled anything that isn’t necessary, I recommend enabling W3C logging on your IIS servers. The idea being W3C logging is that it will force IIS to log more information than what’s typically seen through the event viewer. The W3C logging information contains such information as who has visited your site and when. You can also tell what resources the various people have attempted to access and what actions that they have attempted to take. For example, you could tell if someone has been trying to overwrite your files. Once you have this information, you could block the IP address or the domain of the would be hacker.

To enable W3C logging, open the Internet Service Manager and right click on your default Web site. Next, select the Properties command from the context menu to reveal the Web site’s properties sheet. Finally, select the Enable Logging check box on the properties sheet’s Web Site tab, and the select W3C Extended Log File Format from the Active Log Format drop down list.

Double Checking Yourself
Once you’ve worked through the security tips that I’ve provided you with, it’s a good idea to conduct a thorough security audit. As I said earlier, there are hundreds of ways to enhance security on a Web server. However, there are two particular tools that you can use to make the job of tightening security easier. The first of these tools is the IIS Lockdown Tool.

The IIS Lockdown Tool
The IIS Lockdown Tool is a utility provided by Microsoft that’s designed to reduce the risk of a security breach by turning off anything that’s unused. The tool contains templates that tell it which services are required for the various Microsoft products, such as IIS or Exchange Server. By using the process of elimination, the utility is able to tell you which services should be disabled. Additionally, the utility also supports disabling individual IIS services such as HTTP or FTP. You can download the IIS Lockdown Tool from www.microsoft.com/WINDOWS2000/downloads/recommended/iislockdown/default.asp.

Microsoft Baseline Security Analyzer
The other tool that I recommend using is the Microsoft Baseline Security Analyzer. The Microsoft Baseline Security Analyzer (MBSA) is designed to be a replacement for the Personal Security Advisor tool. It’s job is to scan your server looking for security vulnerabilities.

From an IIS prospective, the utility checks to see if version 2.1 of the IIS Lockdown Tool has been run on the server. It also checks to see if IIS is running on a domain controller and if W3C logging is enabled. Additionally, the utility tests the vulnerability of the Administrator password and any service account passwords that may be in use (such as the IUSR_servername account).

What makes the MBSA so cool is that it isn’t an IIS specific tool. Instead, it’s designed to assess security from a total system standpoint. For example, when testing the underlying Windows operating system, the utility tests for the existence of unnecessary and insecure share points. And checks to see if there are any potentially risky group membership or password issues. There’s no way that I can list all of the tests that the MBSA performs in the space that I’ve got to work with, but let me just say that the utility tests Windows, IIS, SQL and Internet Explorer.

By far the most beneficial feature found in the MBSA is the ability to test for the presence of hot fixes and service packs. As you may know, Microsoft routinely releases hot fixes and service packs for its various products. Unfortunately, unless there’s a major problem, there is no big announcement to herald the birth of a new hot fix. Therefore, up until now, it’s been necessary to frequently check the Microsoft Web site for new patches. The problem is that these patches tend to be scattered. There’s one location for Windows patches, another for Exchange patches, etc. The MBSA queries a Microsoft database as to the recommended hot fixes and service packs for the products that were detected on your system. The utility then generates a report telling you which of these recommended fixes were installed and which ones need to be added. The utility even provides you with a link that you can use to download the fix. Best of all, because the patch database is online, Microsoft can update it every time a new fix is released. Therefore, if you run the MBSA utility often, you can be assured of always having the latest patches.

The MBSA is available for download directly from Microsoft.

The utility can be installed on Windows 2000 and Windows XP systems and can be used to detect security problems on Windows XP, Windows 2000 and Windows NT 4.0 systems.

Conclusion
Securing a Web server is a difficult task. However, by following my recommendations and by using the tools that Microsoft provides you, you can make this huge task a little easier.