Many reports of new tools for breaking into IIS servers have surfaced. How can I secure my IIS servers against intruders who use sophisticated tools to break into servers?
Your question doesn't have a one-size-fits-all answer. You can be certain that if you have an IIS server on the Internet, that server is being scanned, probed, and fingerprinted several times a day. Many best practices aren't optional anymore. The Internet isn't a safe place, and you have to prepare your servers as if they were under siege.
In addition to firewall technology, I insist on intrusion-detection systems. Intrusion-detection software looks for specific types of traffic, such as a Cult of the Dead Cow's Back Orifice or Symantec's pcAnywhere ping, a port scan, or an attempt to use a remote procedure call (RPC) to connect to the server. I have one Web server that gets about 10 to 20 probes daily; some of those probes come from users with clearly malicious intent who are looking for a Trojan horse host.
Cracker tools are like viruses in that they constantly mutate and become more resistant to known cures, or fixes. Thus, your intrusion-detection software needs to keep up with the mutating, more complex cracker tools. Your intrusion-detection software also needs to keep up with new cracker tools, such as Sir Dystic's new tool called SMBRelay. Server Message Block (SMB) is a high-level protocol used in Microsoft networks to communicate among computers, usually to transfer files or information about the file system. This tool captures password hashes between the client and the server, then (to oversimplify) uses port 139 on the server to intercept the authenticated connection. Here's the strategy for protecting yourself against an SMB attack, according to the SANS Windows Security Digest Vol. 4, No. 4 (reprinted here with permission):
- Remove or disable the Server service (File and Print Services for Microsoft Networks) on all machines that don't need it.
- SMBRelay will capture the credentials that are passed automatically when the client connects. Those credentials are the credentials that the currently logged-on user used to log on. By ensuring that users don't log on as an Administrator, you minimize the impact those credentials can have.
- The tool needs the client to initiate the connection to the attacker's server. Beware of HTML links to URLs such as file://<ip address here> or "\\<ip address>\share.
- Ensure that you block both incoming and outgoing SMB transmissions at the firewall by blocking ports 139 and 445 TCP and UDP at the firewall.
- Disable LanMan hashes on the network by setting the LMCompatibilityLevel on your clients to 3. This setting directs your server to use only NTLMv2 hashing. (Note that this setting can cause problems with Windows 9x clients or Windows NT 4.0 systems that don't have Service Pack 4—SP4—or later.)
- Disable storing of LanMan hashes. On Windows 2000, you can disable storing of LanMan hashes completely by creating the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NoLMHash registry subkey.
Most of these recommendations are a good idea on any IIS server that's on a public network. See "IIS Security Resources" for some great resources about how to secure an IIS server.
| IIS SECURITY RESOURCES |
|
Many good IIS security resources are available. Here are a few to get you started. CARL DENOWH "SECURING IIS ON WINDOWS 2000" http://www.sans.org/infosecFAQ/win2000/sec_IIS.htm FREE PAPER ABOUT THE WINDOWS 2000 SECURITY HANDBOOK http://www.systemexperts.com/win2k.shtml MICHAEL HOWARD Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press, 2000) JASON MORRIS "STEP-BY-STEP GUIDE TO SECURING WINDOWS 2000 SERVER USING THE SECURITY CONFIGURATION & ANALYSIS TOOL" http://www.sans.org/infosecFAQ/win2000/hardening.htm "SECURE INTERNET INFORMATION SERVICES 5 CHECKLIST" AND "IIS 4.0 SECURITY CHECKLIST" http://www.microsoft.com/technet/security/tools.asp |
