Republished with permission from
WatchGuard Technologies, Inc.
IIS Server Camouflage
by David M. Piscitello, President, Core Competence, Inc.
Just about every company opens TCP Port 80/HTTP to the Internet for some Web-based application. Thus, many companies, wittingly or not, leak useful tidbits of information that attackers gather to refine their attack plan, such as what kind of Web server you're running and what addresses your servers use. Today, we'll examine information attackers can gather from basic Web requests, and consider what you can do to make it just a little harder for them to learn about your Internet Information Services (IIS) server.
How IIS Leaks Web Information
Left completely unattended, your Web presence reveals some things about your Web server environment:
Why is revealing this information dangerous?
Revealing Web server and operating system type reduces the effort an attacker must exert to lock in on a target. This, in turn, reduces your opportunity to detect and record evidence of an attacker's activities. Revealing IP addresses allows an attacker to learn more about your company's internal network topology: are you hosting your servers in your own shop or outsourcing to a hosting company? Are you assigning client addresses on the same subnet as your servers? Leaving your response header composition in its defaults reveals Web server type, as do the default error messages of most Web server applications. Finally, making use of certain file extensions other than the ubiquitous .html and .pdf are dead giveaways that you are using IIS. The most obvious is .asp, Active Server Pages. The companion ASP session cookie ID clearly brands itself as well.
Plugging Basic Leaks
With a little effort, you can block many of the leaks I've mentioned.
Begin by scrubbing the information attackers can glean from the response messages your IIS server generates when a visitor accesses .html pages at your Web site. In a previous column, I described how to harden your IIS server using the IISlockdown and URLscan tools. In your URLscan.ini file, prevent IIS from including the HTTP header that identifies your Web server as "IIS" by setting the parameter RemoveServerHeader to a value of one (1). You can also use the AlternateServerName parameter to return a custom string. Some site administrators use the string "Apache/1.3.12" to mislead attackers; others encode a warning regarding appropriate use.
To prevent IIS from revealing your server's IP address, configure your server to return its Fully Qualified Domain Name (FQDN) in the Content-Location header. Microsoft Knowledge Base Article 218180 explains how to modify the IIS metabase to change the default behavior and return the FQDN, which in most cases, resolves to the public address of your Web server. The article also explains how to create a custom header for Content-Location, for those of you who are using Active Server Pages.
Creating custom error messages and pages is relatively simple, and, as David Gammell's article explains, has useful purposes other than concealing your Web server type. The process for IIS is easily performed using the IIS Management Console. Create the page you want to associate with an error, put it in a publicly accessible folder on your server, then map this new page to the HTTP Error (e.g., 403 Access Forbidden, 404 URL Not Found), using the Custom HTTP Errors tab of your Web server's Properties page. For one example of a Custom 404 page, visit here.
These next steps fall somewhere between being thorough and compulsive: I mention them so you can appreciate the extent to which some site administrators go to obscure their server.
Advanced server camouflaging techniques are required to thwart Web fingerprinting. You can create a custom ISAPI filter, a dynamic link library (DLL) your IIS server calls each time it responds to a client request. The ISAPI filter you create should customize the way headers are composed in HTTP responses so that an attacker can't identify the server you are running. You might also, as this Michael Mullins column suggests, choose to change the application mappings on your server to hide the file extensions which reveal your server is IIS. (Wayne Berry explains how to map .asp extensions to .html here. He also conveniently provides an example of a simple ISAPI filter.)
If you are going these extra miles, consider writing an ISAPI filter that rewrites URLs so your directory structure and file organization are not revealed. Better yet, try the free, "Lite" version of the utility ISAPI_Rewrite.
Opinions differ regarding the efficacy of these and similar measures site administrators can take to camouflage Web servers. Yes, this is a flavor of security through obscurity, and yes, motivated and persistent attackers are likely to discover you are running IIS, so yes, these measures are imperfect. Think of these measures as another layer of security that buys you response time. History is replete with stories describing how delaying tactics, feinting maneuvers and misinformation altered the outcome of a battle. To me, the compelling question is not, Why bother? The question is, Why not bother?
Copyright© 2004, 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 - 2004
WatchGuard Technologies, Inc. All rights reserved.