Protect Your Web Server Against Threats from Within

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:

1. Choose Start, Programs, Administrative Tools, Local Security Policy, then select IP Security Policies on Local Machine, which Figure 1 shows.
2. Create a new security policy and name it Block incoming email. Then, click through the wizard that appears automatically when you create a new policy until you see the Block incoming email Properties dialog box, which Figure 2 shows. Click the Rules tab.
3. Clear the Use Add Wizard check box (which is enabled by default), then click Add twice.
4. Create a new IP filter list called Out going POP and IMAP.
5. Create a rule that blocks packets with a destination port of 110 by clicking Add in the IP Filter List dialog box to launch the IP Filter Wizard.
6. Click Next for the source and destination address; accept the defaults.
7. When the wizard prompts you to select a protocol, specify TCP. Click Next, then select the To this port option and type 110 in the text box. Click Next, then click Finish.

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.

   Previous  [1]  2  Next