Let’s look at it from the attacker's point of view: Security vulnerabilities tend to be dependent on software vendor and version. Blind probing might lead to further requests being denied or a system temporarily taken off line.Knowing Web server details greatly increases the efficiency of any attack. If an attacker can target exploits, the chances of successful cracking prior to detection increase significantly. Script kiddies can leverage canned, newly-discovered exploits to do more damage faster by targeting hosts with recognizable signatures. A self-identifying system invites trouble.

The Server Header Tells All

Most Web servers politely identify themselves and the OS to anyone who asks. Using a network query tool like Sam Spade or this Header Check, you can discern the HTTP Server header. Just request a Web site's home page and examine the resulting HTTP headers or "banners" sent back by the server. Among them, you will likely find something like this:

Server: Microsoft-IIS/5.0

There is not much mystery here. Apache's default settings make it no less identifiable:

Server: Apache/2.0.41-dev (UNIX)

You can remove or obscure this HTTP Server header in a variety of ways, depending on your platform. Apache 2.x users who have the mod_headers module loaded can use a simple directive in their httpd.conf file, as follows:

Header set Server "New Server Name Goes Here"

Unfortunately, mod_headers cannot alter the Server header in prior versions of Apache, so 1.3.x users will have to resort to editing the defines in httpd.h and recompiling Apache to get the same result. IIS users can install IISLockDown and use the configuration option in URLScan's INI file for removing or replacing the header. Be careful with URLScan if you are using Cold Fusion application server -- the way the current version replaces the Server header wreaks havoc with CFM pages. In fact, removing the header is the way to go when using URLScan, since if you try replacing the header it moves to the bottom of the header order -- which pretty much gives away that you are running URLScan on IIS.

Unsightly File Extensions

Teaching Software

Displaying file extensions like .asp or .aspx in a site is a clear indication that you are running a Microsoft server and, in general, hiding file extensions is a good practice to mask the technology generating dynamic pages. You can change your application mappings (.asp becomes .htm or .foo, etc.), but such one-to-one mapping can make mixing server-side technologies painful and does nothing to alleviate headaches during site migrations. Doing without file extensions altogether is an even better idea, not only for security but also for ease-of-migration and content negotiation. Apache people will want to take a look at mod_negotiation. Watch out, though, for the Content-Location header in the server's response, which can give away the file extension that is not shown in the URL. You might have to suppress this header separately using mod_headers. In a similar vein, Port80 offers a tool called PageXchanger that allows file extension hiding in IIS.

Half-Baked Cookies

The ASP session ID cookie, used by the Session object to maintain client state, is another dead giveaway:

Set-Cookie: ASPSESSIONIDQGQGGWFC=MGMLNKMDENPEOPIJHPOPEPPB;


You can disable ASP Session State so that this cookie is not placed, but you lose the convenience of using the Session object to maintain client state. You could also create an ISAPI filter to change the names of any session ID cookie. On the other hand, ASP sessions are resource intensive, and turning them off improves the performance and scalability of your ASP application, while also helping to anonymize your server.

Send These to the Recycle Bin

WebDAV: Another way of identifying Microsoft servers is their implementation (from Windows 2000 and IIS 5.0 on) of WebDAV -- the HTTP Extensions for Distributed Authoring and Versioning. WebDAV itself is not unique to Microsoft or IIS; it is a proposed standard (RFC 2518) with an IETF Working Group. Microsoft's WebDAV support, however, adds a lot of information to the headers sent back by the server, especially when an HTTP OPTIONS request is made. If you are not using WebDAV (to support Outlook Web Access or Web Folders, etc.), you can disable it entirely by editing the registry or by using IISLockDown and URLScan.

Public Header: Certain Web servers betray their identity by displaying the Public header in HTTP responses. Few popular Web Servers send this header in response to OPTIONS requests (while almost all respond with the similar Allow header). The presence of Public is a good indication you are connected to either an IIS box or Netscape Enterprise 3.6. The Public header can be removed with a custom ISAPI filter (IIS) or NSAPI plug-in (Netscape).

Integrated Windows Authentication: IIS users should not rely on "Integrated Windows Authentication" -- especially not as a way of hiding anything on the server. This method betrays the very secret it would keep, since a script or visual hacker can identify the Windows box by means of the WWW-Authenticate headers sent by the server. When a file or directory is protected by NT Challenge-Response authentication, one of the authentication headers contains the string "NTLM" (NT LAN Manager) -- a Microsoft-specific form of HTTP authentication.

Click Here to Read the Entire Article....