Protect Your Web Server Against Threats from Within

What Nimda can teach us

Protecting your Web server against sophisticated worms such as Nimda takes more than just securing the server. The Nimda worm had at least six attack vectors, which made it especially virulent, and Nimda infected many fully patched servers by nontraditional means (e.g., through shared folders and Web pages). Therefore, looking at how you can protect against Nimda is helpful for determining how to protect your servers against similar attacks in the future. (No matter what else you do, you should always have a company policy in place to update virus signatures at least daily.)

Nimda used IIS vulnerabilities to infect computers in a way similar to CodeRedII. However, if these vulnerabilities had been the only concern, simply staying up-to-date on security hotfixes would have protected a Web server. Worms such as Nimda also use indirect methods of propagation and can jump from trusted workstations to your Web server or infect your Web server through seemingly innocuous activities such as browsing the Web. I'll show you the more notable ways in which Nimda infects computers—through email, Web browsers, and file systems—and provide proactive measures—including using IP Security (IPSec) and Windows 2000's Run As feature—that you can take to protect your Web servers.

Protecting Against Email Propagation
One way Nimda propagates is through email attachments. Thus, you should prohibit reading email on Web servers. Nimda infected many Web servers simply because someone logged on to the Web server, opened an email client, and checked email. You probably don't use your Web servers for checking email, but I've known shops in which stubborn night operators insisted on browsing the Web and checking email from the servers they monitored rather than walking over to a private workstation.

To prevent someone from reading email from your Web server, you can delete Microsoft Outlook Express, but what if someone installs another email client? Implement an IPSec policy on your Web server that denies outgoing packets to port 110 for POP mail and to ports 143 and 993 for IMAP. To set up such a policy, follow these steps:

The new rule will appear in the IP Filter List dialog box, which Figure 3 shows. Repeat these steps for ports 143, 993, and any other ports you use for email in your internal network, then close the IP Filter List dialog box. In the New Rule Properties dialog box, click the IP Filter List tab and select your new IP Filter List, as Figure 4 shows. Next, click the Filter Action tab and select the Block option, as Figure 5, page 16, shows.

Protecting Against Web-Browser Propagation
Another activity you should prohibit is Web browsing from your IIS Web server. After infecting a Web server, Nimda added a few lines of code to every Web content file (e.g., .html, .asp), which propagated Nimda to Web clients. Again, Nimda infected Web servers simply because someone was Web browsing while logged on to the Web server and happened to view a file from an Internet or intranet server that Nimda had already infected.

Deleting Microsoft Internet Explorer (IE) from a server is more problematic than deleting Outlook Express, so I recommend adding to your IPSec Policy another filter that blocks packets with destination port 80. If you need to be able to browse your local Web server, IPSec won't interfere.

Although IE 6.x and IE 5.5 are immune to Nimda, that doesn't guarantee that those versions will be immune to the next attack. Following the best practice of using the strictest possible security options and disabling all unneeded features often automatically protects your servers against yet-to-be-discovered exploits.

Protecting Against File-System Propagation
A final way that Nimda propagates is through the file system. In addition to the Web content­related files that I described earlier, Nimda replaces applications on the infected computer with Trojan versions and copies itself to every folder on the computer. If someone on another computer accessed one of those files, Nimda infects that user's computer as well.

A Web server can become infected through file-system propagation in several ways. A user who maintains Web content on the server might be using an infected PC; the virus then spreads to the Web server when that user copies files from the infected PC to the Web server. Like viruses, Nimda can spread if Web content is developed on an infected file server, then copied to the Web server. Therefore, you must limit how many workstations and file servers are involved in maintaining a Web site by implementing a more formal development environment. Then, on those few development computers, follow some basic rules to reduce opportunities for worms or viruses to spread to them and thus to your Web server.

First, lock down IE and your email client by disabling dangerous features such as JavaScript. (For more information about securing IE, see my six-part series beginning with "Internet Explorer Security Options, Part 1," http://www.secadministrator.com, InstantDoc ID 20468.) A locked-down IE and email-client configuration will reduce the likelihood of getting the worm through Web browsing.

Next, make sure that all workstations involved in maintaining your Web server run Win2K, which is less vulnerable to worms contracted through file-system propagation. To ensure that your Win2K system is even less vulnerable, make sure that users are members of only the Users group on their local workstations, not the Power Users or Administrators group. As members of the Users group on their local machine, users have limited access to the OS and other folders; if a worm makes it past the locked-down IE and email-client configuration, it won't be able to propagate as widely.

For maximum security, create two accounts for anyone who maintains Web content or accesses the Web server. For example, a user would have an everyday account called John for activities such as Web browsing outside the company's Web sites and reading email. But that user would also have another account called John-WEB, which would have access to the Web server and any folders on other servers on which Web content is developed. You would then explicitly deny the John account access to anything related to your Web site. One way to deny this access is to limit all members of the Users group to read-only access. Then, you could make the John_ WEB account a member of a group called Web_Authors that has Change privileges to all Web content. Users can log on to their everyday account and work as usual until they need to access something related to the Web server, such as running Microsoft FrontPage. At that point, instead of simply clicking the FrontPage desktop shortcut, they will press Shift and right-click the shortcut, then select Run As. (This little-known feature lets you run an application under a different account without logging off.) A worm can spread only to files it can access, given whatever user account the worm runs under. If someone using the John account accidentally executes Nimda from a Web-browsing session, email, or some other application, the worm won't be able to propagate to Web content files or the Web server because you've explicitly denied such access to that account.