Code Red and Proactive Security

By now you've probably have read about the Code Red Web server worm and have loaded the fix on your Internet-connected Microsoft IIS servers. Unlike a typical desktop worm, such as Melissa, the Code Red worm spreads from one Web server to another. After infecting a Web server, Code Red temporarily defaces the home page before creating 99 threads that look for other Web servers to infect. However, because Code Red uses an exploit for which a patch has been available for some time, your systems might be safe. If you've practiced proactive security (e.g., reading Microsoft security bulletins and loading recommended hotfixes on your Windows 2000 IIS servers), you were probably already protected from Code Red before its release.

Let's consider an even more important, strategic way to be proactive about security. Because attackers readily exploit bugs in software components, I frequently encourage users to disable or remove all unneeded computer functionality. If a component isn’t functional on your computer, you're immune to all exploits based on that vulnerable component. At the OS level, you should disable all unneeded services. (To locate my series of articles titled "Dangerous Services," select one of the related articles from the Article Information box at the right.) When you install a product such as IIS, however, you need to realize that it consists of many components that typical installations don’t need. For example, in addition to HTTP Web services, IIS supports SMTP, FTP, and Network News Transfer Protocol (NNTP). Even IIS's core Web server component doesn't need many of the optional features that a typical Web site doesn’t use, such as Internet Printing and Index Server. Web Server Support for Index Server is the feature that contains the unchecked buffer that the Code Red worm exploits.

Unfortunately, when administrators install IIS on Win2K or Windows NT, they choose the typical or full installation options and load unnecessary components—greatly increasing their exposure to each exploit an attacker devises. Although it's helpful to invest in a firewall or Intrusion Detection System (IDS), these programs often lead to a false sense of security. Security is not a product you can buy! Firewalls can’t stop most IIS exploits because the firewalls stop looking at a packet after identifying that it's inbound traffic to the Web server on port 80. Exploits such as Code Red reside in the data portion of a packet. An IDS won’t detect such an exploit until you or your vendor updates the search engine with a new attack signature. (For example, you can find a signature for Code Red from eEye Digital Security to add to your IDS.)

How can you be more proactive? After installing IIS, you should use the IIS Security Checklist to secure your server at both the OS and IIS levels. Depending on whether you’re running Internet Information Services 5.0 on Win2K or Internet Information Server 4.0 on NT, Microsoft provides separate checklists for each version. However, if you're under time constraints, you might find it difficult to make the changes that these documents recommend. Fortunately, you can speed up the process with free scripts available on the Internet. For Win2K computers running IIS 5.0, you can use IISLock from Microsoft. IISLock presents a list of IIS features that typically you don't need and lets you choose the features you want to disable. IISLock does contain several minor flaws, which I explained in "Keeping Up with IIS Security." If you have some NT servers, you’ll be interested in a script written by Russ Cooper, who moderates the NTBugtraq list, devoted to Win2K and NT security problems. Cooper's script disables the risky and usually unnecessary features of a typical NT installation of IIS 4.0. These scripts have protected servers against the two recent high-profile IIS exploits—the Code Red worm and the Internet Printing buffer overflow.

If all Web server administrators simply used one of these scripts after installing IIS, I'm sure that the number of successful IIS exploits would decrease dramatically. Unfortunately, Code Red worm-related attacks on Win2K Server and NT Server Web sites aren't the only IIS exploits that you need to worry about. Don’t forget that both Win2K Pro and NT Workstation also let you install a workstation version of IIS. Depending on how you roll out workstations at your organization, you might have hundreds of computers that you need to patch. Some administrators might think, "Who cares whether an attacker exploits some Web page an employee puts on his workstation?" Unfortunately, defacement isn’t the only risk with a worm like Code Red. After Code Red infects a computer, the worm uses the computer to look for other servers to infect—a hundred at time. (Think of the bandwidth the worm uses when it infects many workstations.) Although it’s currently unknown whether the courts can hold organizations legally responsible for worm attacks that originate from company networks, no one wants to be a springboard for attacks. To beat worms such as Code Red, organizations using the Internet will need to cooperate. Be a good netizen and do your part by practicing proactive security. If you disable unneeded features now, you'll find that you don't need to rush to load the latest component security fix from Microsoft because your systems don’t use that component.