Manage Learn to apply best practices and optimize your operations.

IIS server patching best practices

Avoid the complications of IIS server patching by securing a system that is resistant to attacks.

QUESTION: I keep getting conflicting advice about patching my IIS servers. Some people recommend patching live systems for serious vulnerabilities as soon as I can. Others say you must test the patch before putting the server back into production. What should I do?

The best way to address this common problem is to set yourself up so you don't have to address it at all. If the configuration of your system is already resistant to an attack, you don't have to worry about applying new patches.

For example, Code Red attacked a vulnerability in IDQ. DLL, a component used to provide access to Index Server via IIS. Most people don't use Index Server in their Web sites, but IIS enables this functionality by default. Ergo, most IIS servers were vulnerable to Code Red.

This isn't an isolated example, however. In fact, the majority of attacks against IIS servers leverage some component that most businesses don't use (or need). Heck, with a slightly modified installation, an IIS server would be secure against most of the attacks we've seen over the past couple of years. A good start would be to remove all of the script mappings except .asp and .asa; remove the /scripts directory; and move the CMD.EXE program out of its default directory.

But let's assume, for the sake of argument, that you need to install a patch. Now the question becomes when and how? Obviously, the importance of the server in question plays a big part of your decision. Is it mission-critical? Does your company make its living off of it? Will employees, partners or customers be seriously affected if it's not available?

Let's assume it's mission-critical and downtime must be minimized. If you have the benefit (some would say luxury) of a test system that replicates your production system, simply apply the patch there, test your site and see what happens. When you're satisfied, deploy it to the production system. (First, make sure you can restore a backup should it fail.)

If you don't have a test system, you have several options:

  1. Disable the feature that's under attack. Take the Code Red example: How much harm would it have caused to disable Index Server (by removing the script mapping) until you'd had a chance to test the patch?
  2. Filter for the attack, and prevent it from reaching your site. Microsoft recently released a tool called URLScan. For most systems, this tool does a good job of preventing malicious URLs from reaching your site.
  3. Install the patch and hope it doesn't adversely affect your site. Generally speaking, this isn't a good idea. Microsoft has released a number of patches which either cause other problems, don't address the problem correctly or can't hold up under load.

Time Matters

In general, when deciding which of the above options to choose, consider the following:

  1. Does the patch address attacks that are happening right now? Or, is it intended to address a potential attack? If no attack or exploit is currently known, work the update into your normal maintenance schedule and monitor the vulnerability.
  2. What can you do to mitigate the threat? Can you turn off a service, disable a feature or otherwise change the configuration of your system so it's not vulnerable? In most cases, the answer is "Yes."
  3. How much harm is the attack going to cause your system? Or your company's reputation? Or your employees' or customers' use of the site?
  4. Do you have good backups and a plan for responding to a successful attack? Probably the easiest response to a successful attack is to block inbound access to all similar systems. I recommend taking down your internal hubs, segmenting networks and dealing with them in smaller groups. Disable inbound VPN access and other privileged network connections.

It's important to change the way we think about the urgency of patches. None of the patches that have been released for IIS 4.0 or 5.0 had to be installed immediately. Even when Code Red was running rampant, removing the mappings was still more effective and efficient than patching.

By knowing what you have installed, how the system is configured and what component does what on your sites, you'll find yourself in a better position to make intelligent decisions about patches.

About the author:
Russ Cooper is Surgeon General of TruSecure Corp. and editor of the NTBugtraq mailing list.

This was last published in February 2002

Dig Deeper on Microsoft Patch Tuesday and patch management