Mask Your Web Server for Enhanced Security
Masking
or anonymizing a Web server involves removing identifying details that
intruders could use to detect your OS and Web server vendor and
version. This information, while providing little or no utility to
legitimate users, is often the starting place for crackers, blackhat
hackers and "script kiddies". This article explores some ways you can
minimize the risk of such detection. Most of the following examples
focus on Microsoft’s Internet Information Server (IIS), since it has
been most widely lambasted for its vulnerabilities, but some Apache
detection countermeasures are also covered. While IIS users probably
have the most vested interest here, server anonymization is relevant to
anyone responsible for administering a Web server.
Crackers Start Here. Shouldn’t You?
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.
Port80
Software has developed an IIS server module called ServerMask to combat
the majority of issues explored here for the Windows Web Server.
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
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.
Get Your Headers Straight
The number and sequence of your HTTP headers and the presence or
absence of certain platform-specific headers provide handy ways for
more sophisticated hackers to fingerprint your Web server. A relatively
unexplored area of server profiling, this will become a more common
exploit as administrators start to implement countermeasures against
obvious HTTP vulnerabilities like the Server header. For IIS users, a
custom ISAPI filter can alter the Microsoft-specific header order or
sequence to emulate, say, a default Apache installation. Apache users
can accomplish any header order emulation they wish by experimenting
with the location and order of Header directives in mod_headers.
Whose Default is That?
Default messages, pages and scripts of all kinds often contain clues to
server identity, and these should be removed or modified accordingly.
Software behind the Web server often bubbles error messages back
through the HTTP request/response cycle, and customized HTTP errors can
mask application server, database server, Web server and OS identity.
For IIS, CustomError makes it easy for developers to deploy custom 404
and other HTTP error pages. This article shows how to implement custom
HTTP errors in Apache. Avoid this on a development server, since, when
done properly, it prevents database and server-side scripting errors
from being seen -- making it tough for developers to debug their
applications! Remove or hide any Web or application server
administration pages, scripts or documentation installed under your
server's Web root, and make sure to replace those default home pages.
