Best Practices for Secure Web Servers

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.)