Republished with permission from WatchGuard Technologies, Inc.


How to Harden Your Microsoft Web Server

by David M. Piscitello, President, Core Competence, Inc.

Seasoned riders of mass transportation know enough to avoid "attacks of opportunity" by dressing with discretion: conceal jewelry and designer suits that mark you as having something worth stealing. Keep your Claudia Ciuti boots and Carla Mancini purse in your office and commute with something less obtrusive. Such proactive security measures demonstrably reduce a rider's risk profile by reducing his or her most likely vulnerabilities. Similarly, you can implement basic measures to reduce your organization's risk profile when deploying Web servers on Microsoft platforms. Through conservative configuration and operation of Windows 2000 operating system, Internet Information Services (IIS), and firewall, you can run a secure public Web service.

Harden your host

Too many security policies over-worry firewall configuration and trivialize host security. Firewalls should provide complementary security to the measures an organization has already taken to protect operating and file systems, user accounts and business-critical services from attacks. Many online resources describe how to secure or harden a Windows 2000 Server in considerable detail (see SANS, SystemExperts, and Microsoft for examples). I'll briefly list the steps most often identified:

  1. Install a clean "minimum install" operating system (the SystemExperts white paper is an excellent resource for this step).
  2. Use the NTFS file system.
  3. Eliminate default file system and share permissions.
  4. Disable any protocols (e.g., IPX, NetBIOS) you won't use.
  5. Disable all services except those you intend to offer (e.g., Web) or require to administer the server.
  6. Disable all but the minimum and necessary user accounts, and use the strongest authentication method available within your organization for access to these accounts.
  7. Set up a secure System Policy appropriate for the service you intend to offer.
  8. Use IP and IPSec filters at the server itself and block all but permitted services (this option also protects the server against unauthorized access from hosts behind the firewall).
  9. Make registry changes that protect the server from denial of service attacks (e.g., SYN flood attacks).
  10. Set up Auditing so that you can monitor all activities on the host, and regularly archive logs elsewhere.

Bring the operating system current with service packs, cumulative patches, and security updates. Be aware that Service Pack 3 incorporates Microsoft's controversial Automatic Updates. Some members of the security community continue to criticize this feature as intrusive, and warn that installation of updates to production systems without suitable testing is a questionable practice. You must be the judge of how best to serve your organization in this matter. As with so many security practices, patching is more of an art form than a science

Once you've completed your initial security lock down, audit your server. Use commercial or freeware vulnerability scanners, nmap, Nessus, Microsoft's Security Baseline Analyzer, HFNetChk, and similar tools to confirm you've configured your host as you intended. This is also an excellent time to verify that your auditing is operating as you intended as well. When you're satisfied, move on to securing your IIS environment.

Harden each service you offer

Phil Cox, author of Windows 2000 Security, says, "The best way to secure a system is to use it for one purpose and secure it around that specific purpose… one service, one system." When you choose to run a Web server, prune and tune the host system to operate this service. Like OS security, Web server hardening is a process of eliminating overly permissive defaults and unnecessary and potentially exploitable features. Hardening includes the following:

  1. Set appropriate access controls on virtual directories.
  2. Set appropriate permissions on critical file types, especially those that enable dynamic content (CGIs, scripts, includes).
  3. Set appropriate access controls on log files and enable logging to the fullest extent possible (with due consideration to the performance objectives your Web server must satisfy).
  4. Delete unnecessary sample and test executables and content.

Microsoft provides a ton of documentation on how to Secure IIS Version 5, including a baseline Web server security template, Hisecweb.inf, which you can use as either a reference tool or the basis for constructing a suitable policy of your own. A complementary tool, IIS Lockdown, provides security templates suitable for different server roles; if, for example, you choose to run a site that is entirely composed of static content, Lockdown will disable unnecessary IIS features such as Active Server Pages on your behalf. The URLscan Security Tool is now integrated with IIS Lockdown. This scanning utility examines HTTP requests in real time and blocks known malicious requests that exploit buffer overruns, URL decoding bugs, Code Red, ASP chunked encoding buffer overruns, etc.(for a definition of "chunked encoding," see Microsoft Security Bulletin MS02-018, under Frequently Asked Questions).

Lest I be accused of having drunk too much of the Microsoft KoolAid, there are many equally useful resources on how to secure IIS beyond Microsoft's Web site. I found the three SANS references at the end of this column particularly interesting and helpful.

Once you've completed your Web server lock down, upload your content, then audit your Web server. Some of the Web auditing tools I've mentioned in a previous article will prove helpful here. This is again an excellent time to verify that your Web logging is operating as you intended: if you are logging in W3C format, a freeware Web log analysis tool, Analog, will quickly become your best friend.

When you're satisfied, (re)consider your firewall and Internet access security measures.

Now you're ready to configure your firewall

How you deploy your public Web server depends, among many things, upon the number of interfaces your firewall supports, whether VLANs play a role, and the kind of Network Address Translation you will employ. Block all inbound services other than HTTP (and SSL, if appropriate). Make certain you are blocking any service you expect to use from behind your Internet firewall as a supporting service for your Web presence (e.g., databases and other "back office" application servers) as well as those you'll use for maintenance (FTP, for example). If you must maintain your server from outside your firewall, use VPN technologies like IPSec or SSH. Block all outbound connections except those your content requires (egress filtering). Make use of all denial of service mechanisms your firewall (Firebox Default Packet Handling and Vclass Hacker Protection Options) and Internet access router may provide.


The methods outlined here for preparing IIS for public Web service are not intended to be comprehensive, nor do they yield a bulletproof site. No amount of security configuration, assessment, hardening and scrutiny will provide 100% immunity from attack, any more so than donning a helmet, Kevlar jacket and gas mask will protect a subway commuter from every conceivable criminal or terrorist attack. What these guidelines will provide you is a better risk profile, and an increased likelihood that someone else's Web site will appear as the low hanging fruit. Stay informed, keep current with critical patches, and see that your staff practices secure coding when writing Web content and applications. Monitor for suspicious activity at your Web server, host system, firewall and access router, and you'll be as prepared as any organization can expect to be. ##


Basic IIS 5.0 Default Web Server Security
Terri Carroll
April 11, 2001

Using Microsoft's IIS Lockdown Tool to Protect Your IIS Web Server
Jeff Wichman
January 4, 2002

Securing a Windows 2000 IIS Web Server – Lessons Learned
Harpal Parmar
October 8, 2001

Copyright© 2003, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2003 WatchGuard Technologies, Inc. All rights reserved.