Close the Doors to Your Web Server

I find it valuable to separate network attacks on IIS servers into two groups: those that are HTTP specific (i.e., ports 80 and 443) and those that aren't related to HTTP (e.g., attacks on other services running on the server, such as Telnet or FTP). I'll discuss HTTP attacks in a future article; this month, I show you how attackers might find other ways into your server and what you can do to prevent it.

The Doorway to Your Server
Services are the doorway to your server from the network. I could begin by listing services that are obviously dangerous and should be disabled, but let's approach the matter of services from the opposite direction. (For more information about particularly vulnerable services, see "Related Reading," page 16.) A time-honored rule for securing a server on an untrusted network is to disable all unnecessary services. Doing so offers several advantages, including less drain on resources and—more important—protection against yet-to-be-discovered attacks. Even if a service doesn't offer direct access to system resources, it might expose a system to buffer-overflow attacks and Denial of Service (DoS) attacks. (In a buffer-overflow attack, the attacker sends to a service a request that exceeds the allocated sizes of buffers in the protocol that that service is using. The attack tricks the target computer into running the attacker's code.) In addition, the fewer services you enable, the fewer security hotfixes you'll have to load when new vulnerabilities are discovered. (Note that a second school of thought about hotfix application is that you should apply all hotfixes in sequence as Microsoft releases them. In this way, you keep services patched in case they're enabled, and you avoid problems that hidden hotfix dependencies might cause.)

Table 1 lists services required on a standalone IIS 5.0 server. You can probably disable all other services that your environment doesn't specifically require. Before you disable services, however, make sure that you check the documented requirements for any third-party applications or components installed on your Web server. For example, GFI's LANguard Security Event Log Monitor requires that you enable Microsoft Message Queue Services (MSMQ). In addition, check each service's dependencies. To do so, follow these steps:

1. Right-click My Computer, then select Manage.
2. Expand the Services and Applications node.
3. Right-click a service, then select Properties.
4. Click the Dependencies tab, which Figure 1 shows.

If you're still in doubt about a service and can't determine from the documentation what it does, follow the best practice of maintaining a test or development Web server that has a copy of the applications and Web site, then disabling the services you think you don't need. Put your Web site through a full complement of tests, transactions, and operations to determine whether you've broken anything.

Several services pose definite risks. I outline a few of the more vulnerable services here. Disable these services or, better yet, uninstall them, if possible. Uninstalling particularly vulnerable or problematic services is valuable if you subscribe to the philosophy of foregoing patches to disabled components in the interest of stability. If unpatched services are uninstalled rather than enabled, they can't be enabled by accident.

The SMTP Service
The SMTP service makes your server vulnerable to SMTP-based DoS attacks and buffer-overflow exploits, and it can provide intruders with a route for spamming. I ran a simple Internet search for "SMTP buffer overflow" that revealed several SMTP-overflow bugs in many SMTP vendors' products, which goes to show that just because Microsoft hasn't published an SMTP-related exploit doesn't mean that one doesn't exist. (If your company or ISP already has an SMTP server available, you might not need to expose your Web server to SMTP attacks.)

Indexing Service
Microsoft Indexing Service has been the source of some IIS-related exploits. The default Indexing Service configuration indexes far more than you probably want (e.g., new Web sites). So, if you need Indexing Service, make sure that you configure it to index public content only. One of my clients accidentally configured his intranet Web server to index the entire volume, which included confidential personnel documents that an innocent user's search disclosed. Of course, better file permissions could have prevented such a disclosure, but this example enforces my point.