Protect Your Web Server Against Threats from Within

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.