Lock Down IIS and SQL Server

Microsoft's IIS and SQL Server can provide tempting targets for malicious people. Our security checklist will help you lower your risk of attack.

 By Deann Corum
Page 1 of 2
Print Article

In the first partof our look at securing distributed Windows apps, we covered how authentication and authorization are typically handled in Windows-based applications. Today, we'll cover some very specific recommendations for locking down IIS and SQL, both of which are often a large part of Windows-based distributed application environments.

IIS Specific Security Recommendations
There is a programming 'hook' in IIS known as ISAPI that associates files having certain extensions with DLLs. These are known as ISAPI extensions (define) .

ISAPI extensions handle functions such as Active Server Pages, .NET web services and Web-based printer sharing. However, many of these extensions are not required, particularly if you're still using IIS 5.0 or earlier. The problem is that many of those extensions (filters) are exploitable. The notorious Code Red is an example of just one malicious program that takes advantage of these extensions. Enable only the ISAPI extensions the Web server and application need, and restrict the HTTP options that can be used with each extension. (Server Properties, WWW Service, Edit, Home Directory tab, Configuration)

Configuring ISAPI Options in IIS
(Click for a larger image)

Most IIS installations include some sample applications and scripts that are designed to demonstrate the functionality of the Web server. They are not designed to operate securely, particularly in Version 5.0 or earlier. These can be exploited to allow overwriting of files or remote viewing, and even remote access to other sensitive server information, such as system settings and paths to binaries. You should at least remove the /InetPub/iissamples directory prior to putting any IIS server into production, and either remove, move or restrict access to the /InetPub/AdminScripts directory. The IIS Lockdown Toolis very useful for tightening IIS security.

Any web server installation that is not kept patched and up to date is a prime target for malicious activity. Regular and timely patching of publicly accessible Web servers is crucial.

Web add-ons such as ColdFusion and PHP can introduce vulnerabilities in a web server installation too. Carefully configure these and check the source websites and latest security bulletins for any needed patches or new exploits in these add-ons.

IIS Security Checklist

  1. Apply the latest operating system service packs and security updates for IIS and any applications loaded on the same host. Consider using Automatic Updates to automatically install patches.
  2. Install host-based anti-virus and intrusion detection software. Keep them current on patches and review the log files frequently.
  3. Disable unused script interpreters and remove their binaries. For example; perl, perlscript, vbscript, jscript, javascript, and php.
  4. Use logging and review the logs frequently, preferably through an automated process that summarizes the events and reports exceptions and suspicious events.
  5. Remove or restrict system tools commonly used by attackers to compromise a system. For example; tftp(.exe), ftp(.exe), cmd.exe, bash, net.exe, remote.exe, and telnet(.exe).
  6. Limit the services running on the web server to the HTTP service and its supporting services.
  7. Be aware of and minimize any type of connection into the inner network that enter through public web server(s). Disable File and Printer Sharing and NETBIOS name resolution on Internet-facing systems.
  8. Use a separate DNS server in a DMZ to service Internet-facing Web servers. Direct any unresolvable queries outside the DMZ to other public DNS servers or those of your service provider - never to your internal DNS servers.
  9. Use different account naming conventions and unique passwords on public facing systems than on internal systems. Internet-facing IIS servers should be in a DMZ behind a firewall, with a second firewall between the DMZ and the internal network. Internet-facing IIS servers should not be part of an internal Active Directory (AD) domain or use accounts that are part of an internal AD domain.
  10. Block all TCP ports to the DMZ except 80 or 443, if needed.
  11. Install the operating system on one drive and Web sites on a different drive to help thwart directory traversal attacks.
  12. If you must use RDP (Terminal Services, Remote Desktop Protocol) to administer the server, change the default port of 3389 to something else hackers won't be looking for. (See Microsoft Knowledge Base Article 187623 for details)

Continued on page 2: Tools for Securing IIS

This article was originally published on Sep 30, 2005
Get the Latest Scoop with Networking Update Newsletter