Close the Doors to Your Web Server

Discover which services leave your IIS machine vulnerable

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:

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.

NetMeeting Remote Desktop Sharing and Internet Connection Sharing
Windows has two remote sharing services: Microsoft NetMeeting Remote Desktop Sharing and Internet Connection Sharing (ICS). Disabling NetMeeting Remote Desktop Sharing prevents someone from using NetMeeting to take over your server. Unless your Web server does double duty as the Internet gateway for users at your company, you shouldn't need to enable ICS. However, this scenario is dangerous because configuring one computer to handle both tasks securely is complex.

Win2K Server Terminal Services, Remote Registry, Telnet, and FTP
Administrators use these services for remote administration. However, malicious intruders also look for them because when these services are improperly configured, they provide remote access to the system console, command prompt, registry, and file system. I regard all these services as dangerous because of the level of access they provide and the history of vulnerabilities discovered, particularly in Telnet and FTP. If you need any of these services, make sure that you understand how to configure them securely so that only appropriate users can access them.

Limiting Terminal Services access. Terminal Services options exist on each user account, and each Terminal Services object has an ACL. Therefore, you must secure Terminal Services connection objects and set Terminal Services —related options on individual user accounts. (For more information about securing Terminal Services, see my four-part Terminal Services series in "Related Reading.")

Limiting Remote Registry access. To limit remote access to the registry, create a new group called RemoteRegistryEditors, then edit the ACL of the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurePipeServerswinreg registry subkey and replace the current entries with RemoteRegistryEditors. (For more information about limiting remote access to the registry, see the Microsoft article "How to Restrict Access to the Registry from a Remote Computer" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q153183.) It doesn't matter whether you grant Read or Full Control permission. After you make this change, only members of the Remote RegistryEditors group will be able to access the registry remotely.

Limiting Telnet access. To limit access to your Telnet service, create a group called TelnetClients and populate it with only those users who should be able to connect through Telnet. When this group is present, Win2K automatically uses it to control Telnet access.

Limiting FTP access. Securing IIS's FTP service is a bit more complicated. If possible, your FTP server shouldn't reside on the same computer as your Web server. Enable FTP only if your Web server must accept file uploads through FTP. For some good tips about FTP security, see Tim Huckaby, "Running an FTP Server on IIS 5.0," http://www.winnetmag.com, InstantDoc ID 16395.

The Server Service
Finally, you might consider disabling the Server service. Microsoft states simply that this service provides file and printer sharing, which is true. If you disable the Server service on a given system, no one will be able to map drives or use printers connected to that system. However, this service also provides administrators with remote access to other Win2K resources managed through the Microsoft Management Console (MMC) Computer Management snap-in, including event logs, local user and group maintenance, services, and scheduled tasks. Even if no user has explicitly shared any folders, the Server service automatically creates hidden administrative shares at the root of each volume, such as C$ for the C drive. You're certainly safer with the Server service disabled, but your ability to administer the IIS server is severely restricted.

Take Advantage of IPSec
Although limiting access to vulnerable services is important, doing so won't protect you against more advanced attacks such as buffer overflows that can provide intruders with the opportunity to run arbitrary code under the system context. Win2K's IP Security (IPSec) feature includes support for the IPSec protocol and flexible policy management, making it easy to block or secure certain types of traffic. IPSec wraps a layer of solid security around otherwise-vulnerable services. With IPSec, you can use simple packet-filter rules to limit which client IP addresses can access given ports. Next month, I'll show you how to limit connections to services such as Terminal Services, Remote Registry, Telnet, and FTP through strong certificate- or shared-secret —based authentication.