Best Practices for Secure Web Servers

Lock down your Web server and keep it that way

A Web server is perhaps the most fascinating type of system to defend. In some areas of computer security, you might wonder if all the trouble is really necessary—but you never wonder when it comes to Web sites. These days, your Web site doesn't need to attract the attention of a cyber thief, "hacktivist," or nihilistic script kiddie. Worms such as CodeRed use a mindless algorithm of IP addresses to attack Web sites indiscriminately.

You can use any of several interesting techniques to protect a Web server, and each month I'll introduce you to one of them. But this month, I want to kick this column off with a best-practices topic. I want to show you the two most important steps you can take to protect your Web servers now—keeping up-to-date with hotfixes and service packs and hardening your Web server. If you follow these best practices, you'll reduce your risk of a successful intrusion by a greater factor than anything else I write about. In fact, the latest widely publicized exploits—CodeRed and CodeRedII—were never a threat to those administrators who were already following them.

Keep Up-to-Date with Service Packs and Hotfixes
This advice sounds simple and obvious, but high-profile Web sites are compromised or defaced all the time by exploits for which a fix has been around for weeks or even months. Such sites getting hit again and again is proof that administrators aren't being diligent. Staying on top of security alerts from Microsoft and applying hotfixes takes time, but there's no substitute for this vigilance.

Fortunately, I have a few recommendations to save you time. First, if you haven't already done so, subscribe to the Microsoft Security Notification Service (http://www.microsoft.com/ technet/treeview/default.asp?url=/technet/security/bulletin/notify.asp). Then, each time you receive a bulletin from Microsoft, read the summary of the bulletin to determine whether this vulnerability is relevant to your servers. Check the Affected Software section for any products or services in use on your server. If you're using more than just Windows 2000 and IIS 5.0 or Windows NT and IIS 4.0 (e.g., you've enabled Microsoft Indexing Service or installed Microsoft SQL Server or Microsoft Exchange Server) on your machines, remember to apply patches for those products as well.

Assuming that the bulletin is relevant to one or more of the products or services installed on your server, proceed to the technical details to determine how urgent it is that you install the associated hotfix. The vulnerability might be associated with an obscure feature of IIS or another product or service that you've disabled. If so, you might decide that installing the hotfix is unnecessary. A good example of such a service was the widely publicized May 2001 exploit that involved the Internet Printing Protocol (IPP) Internet Server API (ISAPI) extension. An unchecked buffer in this extension let an attacker run arbitrary code in the system context—the ultimate coup for a bad guy. However, if you had removed the extension, you were immune to the attack.

Some administrators say that best practice is to load all hotfixes in case features are inadvertently reenabled. However, every time you apply a hotfix, you run another risk—destabilizing your Web server. Hotfixes have been known to introduce new bugs, so be sure to familiarize yourself with and even practice uninstalling hotfixes. (As with any system update, back up your server before you install a hotfix.)

Since May, Microsoft has released two cumulative hotfixes for IIS. These cumulative hotfixes are similar to service packs in that they include all previous security hotfixes. I recommend that you apply all cumulative fixes as Microsoft releases them as a fail-safe measure. If the cumulative hotfix doesn't include new hotfixes important to your server, consider waiting a week to determine whether the cumulative hotfix introduces any new bugs. (See Brett Hill, "IIS Informant," page 4, for information about cumulative IIS hotfixes.)

If you're in doubt as to which hotfixes have been loaded on your servers, check out the Microsoft Network Security Hotfix Checker (hfnetchk.exe) tool, which you can download from http://support .microsoft.com/support/kb/articles/q303/2/15 .asp. Using this tool, you can scan your servers for applied hotfixes. The tool then generates a report of missing hotfixes. Also at that URL, you can find a utility called qchain.exe, which lets you install multiple hotfixes with one reboot—a handy utility if you find that you have a lot of hotfixes to catch up on.

Harden Your Web Servers
Keeping systems up-to-date is important because many exploits are problems in Microsoft code that only Microsoft can fix. But how can you increase your immunity to attacks in the first place and reduce the urgency of loading updates from Microsoft? The answer is to harden your Web server.

You can configure your Web servers in many imaginative ways to repulse attacks, but you'll get the most mileage by starting with the basics from the Secure Internet Information Services 5 Checklist and Microsoft Internet Information Server 4.0 Security Checklist (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/ tools/tools.asp). These checklists cover many areas of OS and IIS security, but I want to draw your attention to an extremely important section of these documents—removing unneeded script mappings. This recommendation is one of the most important rules to follow in computer security: If you don't need it, turn it off.

On the same Web site as the checklists, you can also find the IIS Lockdown Tool and the Windows 2000 Internet Server Security Tool (IISLock), which automate many of the steps in the respective checklists. I recommend that you peruse the appropriate checklist, determine which recommendations are appropriate to your server, then perform the step manually to retain control over what's happening to your server. However, if you have many servers to harden or time constraints, you might decide to use the hardening utility. If you do, make sure that you understand what the tool does before you use it. Also be aware that IISLock doesn't make every change in the checklist and can break a server if you don't know what you're doing.

Ongoing Security
If you do nothing else for your Web site's security, I urge you at least to perform an initial hardening of your server and implement an ongoing process to load relevant security hotfixes. When you receive a security bulletin from Microsoft, determine whether it applies to any of the products or services on your server. Then, keep your server baselined by installing any new service packs for Win2K, security rollups for NT (Microsoft has announced no further service packs for NT, but it does periodically release security rollups), and cumulative hotfixes for IIS. You'll not only protect your sites but also prevent your computer from being used to attack other servers on the Web.