ServerMask FAQ




Isn't this just security by obscurity?

No, not in the usual sense. The idea of "security of obscurity" is often justifiably belittled because it amounts to nothing more than hiding known vulnerabilities in the hope that they will not be discovered. This is not what we created ServerMask to do. Rather, ServerMask was designed to help anonymize your Web server, which is one part of a comprehensive defense-in-depth network security strategy.

In a sense, however, server anonymization is about the uses of obscurity for enhancing security. The point is not to hide vulnerabilities rather than fixing them. We assume and recommend that users of ServerMask will keep up to date with the latest hotfixes, security rollups, and services packs -- and that they will operate their servers behind a good, well-administered firewall. The point of ServerMask, along with our other recommendations for stealth and server anonymization, is to prevent the leakage of information that serves no useful purpose for anyone, but only makes it easier for hackers to carry out successful recon and attacks.

All Web servers are vulnerable to attack, and there are plenty of malicious hackers out there. Server anonymization and anti-reconnaissance can give you an edge over would-be attackers by slowing them down and by making their efforts more obvious to detection and security systems. Why not take advantage of it?

back to top


Who uses ServerMask?

Many organizations are using ServerMask, one of our most popular products. We have ServerMask deployed with government, small businesses, financial, e-commerce, and Fortune 500 clients. Of course, we can not mention them by name here. If you would like to speak with a client directly to see how ServerMask has enhanced their security, contact us.

back to top


What is the HTTP Server header?

HTTP stands for Hypertext Transfer Protocol -- the underlying language that lets different kinds of Web software (like browsers and servers) communicate. HTTP headers are small data fields that accompany a Web-based message and help the software that is going to use that message make sense out of it.

For example, request a page using an ordinary Web browser and, along with the request itself, a set of request headers will be sent to the server where the page resides. These headers might look something like this:

Host: www.bigcompany.com
User-Agent: Mozilla 4.0 (Compatible; MSIE; 5.5)
Accept: text/*, text/html, text/html;level=1, */*
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Request headers give the server extra information about the request and the software making it - for example, the User-Agent header can identify the browser (in this case, Internet Explorer 5.5).

The Web server generally sends its own set of headers along with its response. Although browsers usually don't show these headers, if they did you would see something like this:

Server: Microsoft-IIS/5.0
Content-Location: http://www.bigcompany.com/index.htm
Date: Tue, 28 May 2002 23:30:01 GMT
Content-Type: text/html
The Server header (we sometimes refer to it as the "Server name" header for clarification) is an optional header which is usually used to identify the Web server software's vendor and version to the browser or other client making the request. This is the one of the HTTP and IIS signatures that ServerMask lets you control for enhanced security.

back to top


Why should I remove or modify the HTTP Server header?

In the words of the HTTP specification:

Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.

In other words, the Server header can make your server vulnerable to attack because it lets a potential attacker know exactly what you are running. This knowledge greatly simplifies an attacker's job. For example, an attacker might have programmed a bot to search the Web looking for servers from a certain vendor and/or of a certain version, and then trying out attacks known to work against those servers.

To make matters worse, the Microsoft IIS Web server in particular has an undeserved reputation for security vulnerabilities, and this reputation tends to attract attackers -- which is why some industry analysts recommend that businesses using IIS undertake a costly transition to rival Apache Web servers. Even if your security patches are all up to date so that the cheapest hacker tricks won't work on your box, why attract a disproportionate share of that kind of attention by revealing your server (and operating system) software?

This is also why the HTTP specification recommends making the Server header a configurable option, a best practice no matter what Web server you serve with.

back to top


Why should I mask session cookies?

Session cookies give away unique information that can be used to identify your server. ServerMask allows you to mask the actual session cookie name in the HTTP headers as requests are served and then retranslates the obfuscated session cookie so that application servers and scripts can be executed on the server. The process is transparent and does not affect server or Web application performance -- and can be done with ASP, ASP.NET, PHP, JSP, and ColdFusion session cookies.

For example, the ASP session ID cookie, used by the Session object to maintain client state, is a dead giveaway for IIS Web servers, since it contains a string that marks it as having been placed by ASP:

Set-Cookie: ASPSESSIONIDQGQGGWFC=MGMLNKMDENPEOPIJHPOPEPPB
You can disable ASP Session State so that this cookie is not placed, but this will cost you the convenience of using the Session object to maintain client state. Since ASP sessions are resource intensive, turning them off is a well-known tactic for improving the performance and scalability of your ASP application. However you choose to set up your server, ServerMask allows you to continue using the ASP session ID cookie without divulging that you are running IIS -- and allows you to do the same for IIS running ASP, ASP.NET, PHP, JSP, or ColdFusion session cookies.

back to top


Why should I remove other HTTP headers like X-AspNet-Version, Public, and MicrosoftOfficeWebServer?

Certain Web servers betray their identity by displaying other specific headers in HTTP responses from applications servers or other software programs known to be associated with a particular Web server. ServerMask will remove any header value from an IIS Web server response that you enter in the "Remove Headers" tab. By using this option liberally, you can obscure any non-functional HTTP header details that you like, reducing your attack surface in the process.

We have also included many popular IIS-related headers that are removed by default in ServerMask. The X-Powered-By and X-AspNet-Version headers are obvious signs that you are running ASP.NET and therefore some flavor of IIS. Few popular Web servers send the Public 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 and should be masked. ServerMask can also mask the MicrosoftOfficeWebServer header. While this masking will not affect FrontPage publishing, we urge you to test this obfuscation if you are using these server extensions for any other purpose. Other IIS or Windows signature headers like X-MS-Smart-Tags, X-Meta-MSSmartTagsPreventParsing, and IISExport are also removed by default in ServerMask.

back to top


How do the advanced HTTP header anti-reconnaissance options in ServerMask work?

ServerMask now provides a number of advanced server anonymization features that will help to mask IIS from more detail-oriented and knowledgeable hackers. The default settings for these features are designed to be compatible with the great majority of Web sites and applications, but please review each advanced feature before enabling them on a production Web server. Let's take a look at ServerMask's advanced features

  • Mask internal IP addresses with FQDN in Content-Location header: For requests to directories with mapped default pages or when content is served from computers on the network but not on the IIS server that is handling the initial request, the internal IP address location of that content is printed in the HTTP Content-Location header when IIS serves the response. When this option is checked and enabled, ServerMask will attempt to replace these internal, perhaps sensitive, IP addresses with the Fully Qualified Domain Name (FQDN) or the host name for the site for which IIS is delivering the response.
  • Emulate common non-IIS server ETag format: ETags are HTTP headers that a client can consume and then feed back to a server in the If-None-Match request header; if the server resource has not changed, the server will respond with a 304, indicating that the client can use the file originally requested with the ETag, as it has not been modified since the original request. IIS can be fingerprinted via the format of the ETag header in the HTTP responses, but you can use this option in ServerMask to emulate two Apache Web server and one Sun (Netscape Web server) ETag formats for obfuscation. This feature does not break ETag functionality in any way, but please do make sure to test this feature with your Web server set-up.
  • Emulate Apache Web server HTTP headers order: The order of the various headers in an HTTP response can be used to identify a Web server; for instance, the Apache Web server displays all HTTP header data, including the Server header, in a different order than IIS. This header order signature is one reason why URLScan is not a useful anti-reconnaissance tool, as it allows you to remove some headers that are IIS-specific but it actually creates a unique order in IIS header responses that can be fingerprinted. IIS itself also has a unique HTTP header order fingerprint. By using this ServerMask option, HTTP headers will appear in the order that they would in an Apache Web server HTTP response, providing another layer of misdirection. To really confuse hackers, customize a non-standard or unique Server header with ServerMask, and then emulate the Apache HTTP header order. Hackers won't know what to think of your server!
  • Emulate Apache (ALLOW) header format: When an ALLOW method request is made to IIS, the order and format of the HTTP response is a known signature. Use this option to respond as the Apache Web server would respond to this request in terms of header format and order to add further misdirection against potential hackers.
  • Disable WebDAV to remove identifying headers: Another way of identifying Microsoft servers has to do with their implementation (starting in Windows 2000 and IIS 5.0) 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 its own IETF Working Group. However, Microsoft's implementation does provide another means of identifying an IIS server through HTTP header analysis. To see how this works, try the following experiment. Using a command prompt (DOS) window, telnet to a Windows 2000 server running IIS 5.0 on port 80: C:\>telnet myhost.bogus.com 80 Now you will see a blank DOS window with just a blinking cursor. Type in the following line and then press the Enter key twice (You will not see what you type echoed on the screen but don't worry, it will still work -- provided you remember to hit Enter twice.): OPTIONS / HTTP/1.0 What you see next will look something like this: HTTP/1.1 200 OK
    Server: Microsoft-IIS/5.0
    Date: Tue, 24 Sep 2002 17:47:19 GMT
    MS-Author-Via: DAV
    Content-Length: 0
    Accept-Ranges: none
    DASL: <DAV:sql>
    DAV: 1, 2
    Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
    Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
    Cache-Control: private
    As you can see, WebDAV support adds a lot of information to the headers sent back by the server. Even supposing the Server header and other signatures had been hidden or changed using ServerMask, this response to the HTTP OPTIONS method would still have given away the server's identity in the very name of the "MS-Author-Via" header.

    If you are not using WebDAV already (for example to support Outlook Web Access with Exchange server or for publishing to Web folders using Internet Explorer), we recommend disabling WebDAV entirely. This can be accomplished with one click in ServerMask or by editing the registry on Windows 2000. This feature will be disabled on NT 4.0 systems, and on Windows 2003 systems, WebDAV is disabled by default.
back to top


I can use ServerMask to remove file extensions from my source code and URLs? What about PageXchanger?

File extensions referenced throughout your Web site's source code (hackers love the View Source option) and displayed for target pages in the Address bar of a Web browser are dead give-aways for your Web server platform -- if they reference an application server or piece of software related to that Web server. Similar to cookie masking, it is important to mask your file extensions when you are running ASP and ASP.NET if you hope to anonymize fully with ServerMask. This functionality had resided solely in Port80 Software's PageXchanger product -- this tool is still our most feature-rich implementation of content negotiation, but ServerMask provides "good enough" file extension masking functionality that you will not need both tools if anti-reconnaissance is your goal. That said, this feature can cause some challenges if you do not plan for implementation.

Content negotiation is the HTTP specification's method of delivering a Web response based in part on the browser or client's preferences and/or intentions. To serve a page without extensions, we do not have to look for any browser preferences in the HTTP request, but we have to see what the request is for on the server side. File extensions are not as important as they seem. The MIME type indicates what is coming back from a server, not the file extension. This is why you can ask for a file like homepage.asp and yet it appears to be an HTML file to your browser. In short, since ServerMask with this advanced option enabled will serve all of your MIME types (and your Web site's files) properly, and it works with even very old Web browsers (though some pre-1995 browsers may not work). This feature has been thoroughly tested with the major browser types currently used today, and this IIS server module works with browsers from Microsoft, Netscape, Mozilla and more.

The files on your Web server themselves will continue to have their extensions, but the links to them in the source code will not.

For example, HTML like

<a href="product1.html">product 1 specifications</a>

would be changed to

<a href="product1">product 1 specifications</a>

but the file name product1.html would continue to exist in the directory as is.

Similarly, <img src="/portals/0/logo.gif"> would just become <img src="/portals/0/logo">.

Removing the file extension references is easily performed in common HTML editors like HomeSite or Dreamweaver, our w3compiler client desktop tool, or with the included Port80 Software File Extension Stripper utility that can be run from the command line (see the product documentation or the utility itself after installing ServerMask -- StripExt.exe -- to learn more).

One other caveat when you turn on this advanced feature in ServerMask: make sure that you do not have two files in the same target URL directory with the same name (like http://[hostname]/directory/foo.asp and http://[hostname]/directory/foo.htm). In this case, ServerMask may respond with the wrong version of the page when this feature is enabled. To avoid this issue, review your sites names in the process of removing your file extensions from source code to avoid this potential pitfall.

By removing the file extensions for anti-reconnaissance, you will also receive the benefit of easy future technology transfers from, for example, ASP to ASP.NET. As your source code will no longer rely on extensions, you will not have to update links on the Internet with the new URL or lose search engine rankings when your file extensions change, because the reference will be to the file itself, not the technology choice. For more on content negotiation and clean URLs, please review the PageXchanger tool.

back to top


What does the response code anti-reconnaissance option do in the advanced features?

Some of the best hacker reconnaissance tools rely on odd HTTP error and status condition responses that they have discovered in extensive penetration testing, and ServerMask is designed to thwart their efforts.

While we do not want to share a complete list of the types of subtle message and format changes that we employ in ServerMask (as we do not want to make recon easier for the hackers), the tool does modify some 200, 400, 403, 404, 405 and 501 server responses that are used to identify IIS at the HTTP header level. This will not break your pages, but it will overpower some of the most robust hacker scanners available today. One example: use an HTTP analysis tool and make a customized request with HTTP version 5.6 (this specification does not exist yet), and see how ServerMask responds...

back to top


Which default profile (Hide, Emulate or Randomize) should I choose?

Think of these 3 profiles in terms of how aggressively you hide your data. The more aggressive you are the more difficult it is for a hacker or scanner to determine your true server platform. The tradeoff is that there may be compatibility issues. These are unlikely problems, but are something to consider given the complexity of your application and what your security requirements actually are.

You decude whether you want to simply to remove the data (Hide), to misdirect the hacker (Emulate), or to truly anonymize your platform (Randomize). Here's a tip - to add an additional layer of anonymization, use a different profile for each of the various sites you manage.

back to top


Is installing ServerMask all I need to do to make my server anonymous?

Absolutely not -- server anonymization is just one aspect of server security. It is a preemptive measure to keep would-be intruders from identifying your technology platform and exploiting it. The concept is to use obfuscation and misdirection to dissuade or delay a hacker so they can be identified and dealt with by your intrusion detection and firewall systems. In this manner, your server will also be less of a target for hackers trying to test new exploits before Microsoft has issued a security patch.

Always keep up with Microsoft security patches and deploy an overall security strategy that includes server anonymization, firewalls, intrusion detection, and authentication security. Most security issues arise from "not covering all the bases" -- and it only takes one hacker to cause critical damage to your Internet presence and related technology infrastructure. Develop an overall security strategy that fits your business model and make sure that server anonymization is a pillar in that strategy. Even with ServerMask installed, you will need to do a few more things to anonymize your server. We recommend that you implement these IIS security measures in your environment:

  • As with SMTP banners, IIS also displays an FTP banner in its FTP service response. If an FTP server is needed on the computer on which IIS is running, we recommend using an alternate FTP server like RhinoSoft's Serv-U which allows you to mask FTP banner display. RhinoSoft offers free trials for download at their Web site.

  • Default pages of all kinds often contain clues to server identity and should be removed or modified accordingly. Remove or hide such things as default home pages and any server administration pages or Web-based documentation that would give away the OS.

  • Implementing custom 404 and other HTTP error pages is a good practice in general for enhanced user experience on a Web site. Using customized error pages is a good usability practice as well and will avoid displaying server-specific error messages.

  • Even when all these telltale signs are removed from your Web server's application layer, there remain detection vulnerabilities at lower network layers like TCP/IP. In particular, you must be cognizant of the fact that any box with a network connection has a network protocol stack that, if unprotected, is subject to being scanned and thereby identified. The best network scanners (such as Nmap from www.insecure.org) can still ID a Windows (or any other) box by using a variety of techniques to fingerprint the system's TCP stack -- this is why we recommend deploying some form of TCP/IP information leakage protection as well as ServerMask.

  • If possible, avoid using "Integrated Windows Authentication" in IIS Security settings as a way of hiding known default files. This method betrays the very secret it would keep. By requesting known, OS-specific default pages that are hidden in this way, a script or visual hacker can identify the Windows box by means of the WWW-Authenticate headers sent by the server. When the page is protected by NT Challenge-Response authentication, one of the authentication headers will contain the string "NTLM" (for "NT LAN Manager") -- a Microsoft-specific form of HTTP authentication. For anonymization of your IIS server and as a best practice, we recommend using "Basic Authentication" with SSL for hiding known default files or protecting directories.


back to top


Will ServerMask affect my server's performance?

Not noticeably. ServerMask is an extension of your Web server's default functionality, so it must necessarily add some small increment of additional load. In practice, however, ServerMask is so small, and it ties in to the Web server at such a low level, that the additional load is almost imperceptible, even in the test lab where the smallest performance differences can be recorded.

back to top


Will removing or modifying HTTP headers and signatures in Web responses have any negative effect on my Web site or application?

In almost all cases the answer is simple: None at all. Browsers do not rely on the presence or accuracy of these details, and neither do the kind of bots that are probably welcome visitors to your site (search engine crawlers, for example).

This is because Web servers have a relatively simple job, compared to modern browsers -- they only have to implement one simple and stable specification (HTTP), while browsers are responsible for implementing a whole range of complex and evolving specifications and standards (HTML, JavaScript, DOM, CSS, etc.). As a result, there is much less variation among Web servers than among Web browsers. This is why browsers don't need to "sniff" or "sense" the Web server's identity the way some Web applications have to sense the type of browser in order to display content like FLASH correctly.

In fact, almost the only non-malicious reason anyone might want to know what kind of Web server software you are running is to try to market server products to you! Since the type of Web server you have is not information that your Web clients rely upon, there is no harm in concealing or otherwise obfuscating this information.

So why did we qualify our answer by saying "in almost all cases?" Well, it is theoretically possible for someone to write a non-malicious piece of client software that, for some reason, relies on being able to know the type of Web server or one of signatures that ServerMask camouflages. And it's also possible that you might, for some reason, want your Web site or application to support such software. This scenario is both highly unlikely and, chances are, unnecessarily risky -- there are probably other, smarter ways to accomplish whatever it is you are trying to do (instead of leaving your door unlocked so your neighbors can feed your cat or dog, it might be better to make them their own key). But it's certainly a possible scenario and, if it applies to you, then you shouldn't be running ServerMask. After all, you can't simultaneously expose and conceal your server's identity.

back to top


How can I tell if ServerMask is working?

Our free online " target="blank">Header Check tool is a good place to start.

Most of what ServerMask does is visible in the HTTP headers returned by the Web server on which it is operating. While browsers do not ordinarily allow you to inspect these headers, there are a number of tools available online that make it easy to do so. For quickly checking the HTTP headers sent by a Web server, use our Header Check tool or the HTTP analysis packages like ieHTTPHeaders.

To use an HTTP analysis tool, point it at a Web site hosted on your server and visit the site. The HTTP headers will be printed out on screen of most HTTP analysis tools for the requests and the responses generated when you requested a URL, usually below the displayed page in the tool. Try turning ServerMask features on and off, and varying the settings. You should be able to see the expected changes in the value of ServerMask-protected signatures easily (for testing on disabling WebDAV and the Public header, be sure to specify an OPTIONS request method in your HTTP analysis tool, rather than the default GET in most tools; to test ALLOW method responses, specify this method of request in your HTTP analysis tool).

back to top


back to top

ServerMask FAQ




Isn't this just security by obscurity?

No, not in the usual sense. The idea of "security of obscurity" is often justifiably belittled because it amounts to nothing more than hiding known vulnerabilities in the hope that they will not be discovered. This is not what we created ServerMask to do. Rather, ServerMask was designed to help anonymize your Web server, which is one part of a comprehensive defense-in-depth network security strategy.

In a sense, however, server anonymization is about the uses of obscurity for enhancing security. The point is not to hide vulnerabilities rather than fixing them. We assume and recommend that users of ServerMask will keep up to date with the latest hotfixes, security rollups, and services packs -- and that they will operate their servers behind a good, well-administered firewall. The point of ServerMask, along with our other recommendations for stealth and server anonymization, is to prevent the leakage of information that serves no useful purpose for anyone, but only makes it easier for hackers to carry out successful recon and attacks.

All Web servers are vulnerable to attack, and there are plenty of malicious hackers out there. Server anonymization and anti-reconnaissance can give you an edge over would-be attackers by slowing them down and by making their efforts more obvious to detection and security systems. Why not take advantage of it?

back to top


Who uses ServerMask?

Many organizations are using ServerMask, one of our most popular products. We have ServerMask deployed with government, small businesses, financial, e-commerce, and Fortune 500 clients. Of course, we can not mention them by name here. If you would like to speak with a client directly to see how ServerMask has enhanced their security, contact us.

back to top


What is the HTTP Server header?

HTTP stands for Hypertext Transfer Protocol -- the underlying language that lets different kinds of Web software (like browsers and servers) communicate. HTTP headers are small data fields that accompany a Web-based message and help the software that is going to use that message make sense out of it.

For example, request a page using an ordinary Web browser and, along with the request itself, a set of request headers will be sent to the server where the page resides. These headers might look something like this:

Host: www.bigcompany.com
User-Agent: Mozilla 4.0 (Compatible; MSIE; 5.5)
Accept: text/*, text/html, text/html;level=1, */*
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Request headers give the server extra information about the request and the software making it - for example, the User-Agent header can identify the browser (in this case, Internet Explorer 5.5).

The Web server generally sends its own set of headers along with its response. Although browsers usually don't show these headers, if they did you would see something like this:

Server: Microsoft-IIS/5.0
Content-Location: http://www.bigcompany.com/index.htm
Date: Tue, 28 May 2002 23:30:01 GMT
Content-Type: text/html
The Server header (we sometimes refer to it as the "Server name" header for clarification) is an optional header which is usually used to identify the Web server software's vendor and version to the browser or other client making the request. This is the one of the HTTP and IIS signatures that ServerMask lets you control for enhanced security.

back to top


Why should I remove or modify the HTTP Server header?

In the words of the HTTP specification:

Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.

In other words, the Server header can make your server vulnerable to attack because it lets a potential attacker know exactly what you are running. This knowledge greatly simplifies an attacker's job. For example, an attacker might have programmed a bot to search the Web looking for servers from a certain vendor and/or of a certain version, and then trying out attacks known to work against those servers.

To make matters worse, the Microsoft IIS Web server in particular has an undeserved reputation for security vulnerabilities, and this reputation tends to attract attackers -- which is why some industry analysts recommend that businesses using IIS undertake a costly transition to rival Apache Web servers. Even if your security patches are all up to date so that the cheapest hacker tricks won't work on your box, why attract a disproportionate share of that kind of attention by revealing your server (and operating system) software?

This is also why the HTTP specification recommends making the Server header a configurable option, a best practice no matter what Web server you serve with.

back to top


Why should I mask session cookies?

Session cookies give away unique information that can be used to identify your server. ServerMask allows you to mask the actual session cookie name in the HTTP headers as requests are served and then retranslates the obfuscated session cookie so that application servers and scripts can be executed on the server. The process is transparent and does not affect server or Web application performance -- and can be done with ASP, ASP.NET, PHP, JSP, and ColdFusion session cookies.

For example, the ASP session ID cookie, used by the Session object to maintain client state, is a dead giveaway for IIS Web servers, since it contains a string that marks it as having been placed by ASP:

Set-Cookie: ASPSESSIONIDQGQGGWFC=MGMLNKMDENPEOPIJHPOPEPPB
You can disable ASP Session State so that this cookie is not placed, but this will cost you the convenience of using the Session object to maintain client state. Since ASP sessions are resource intensive, turning them off is a well-known tactic for improving the performance and scalability of your ASP application. However you choose to set up your server, ServerMask allows you to continue using the ASP session ID cookie without divulging that you are running IIS -- and allows you to do the same for IIS running ASP, ASP.NET, PHP, JSP, or ColdFusion session cookies.

back to top


Why should I remove other HTTP headers like X-AspNet-Version, Public, and MicrosoftOfficeWebServer?

Certain Web servers betray their identity by displaying other specific headers in HTTP responses from applications servers or other software programs known to be associated with a particular Web server. ServerMask will remove any header value from an IIS Web server response that you enter in the "Remove Headers" tab. By using this option liberally, you can obscure any non-functional HTTP header details that you like, reducing your attack surface in the process.

We have also included many popular IIS-related headers that are removed by default in ServerMask. The X-Powered-By and X-AspNet-Version headers are obvious signs that you are running ASP.NET and therefore some flavor of IIS. Few popular Web servers send the Public 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 and should be masked. ServerMask can also mask the MicrosoftOfficeWebServer header. While this masking will not affect FrontPage publishing, we urge you to test this obfuscation if you are using these server extensions for any other purpose. Other IIS or Windows signature headers like X-MS-Smart-Tags, X-Meta-MSSmartTagsPreventParsing, and IISExport are also removed by default in ServerMask.

back to top


How do the advanced HTTP header anti-reconnaissance options in ServerMask work?

ServerMask now provides a number of advanced server anonymization features that will help to mask IIS from more detail-oriented and knowledgeable hackers. The default settings for these features are designed to be compatible with the great majority of Web sites and applications, but please review each advanced feature before enabling them on a production Web server. Let's take a look at ServerMask's advanced features

  • Mask internal IP addresses with FQDN in Content-Location header: For requests to directories with mapped default pages or when content is served from computers on the network but not on the IIS server that is handling the initial request, the internal IP address location of that content is printed in the HTTP Content-Location header when IIS serves the response. When this option is checked and enabled, ServerMask will attempt to replace these internal, perhaps sensitive, IP addresses with the Fully Qualified Domain Name (FQDN) or the host name for the site for which IIS is delivering the response.
  • Emulate common non-IIS server ETag format: ETags are HTTP headers that a client can consume and then feed back to a server in the If-None-Match request header; if the server resource has not changed, the server will respond with a 304, indicating that the client can use the file originally requested with the ETag, as it has not been modified since the original request. IIS can be fingerprinted via the format of the ETag header in the HTTP responses, but you can use this option in ServerMask to emulate two Apache Web server and one Sun (Netscape Web server) ETag formats for obfuscation. This feature does not break ETag functionality in any way, but please do make sure to test this feature with your Web server set-up.
  • Emulate Apache Web server HTTP headers order: The order of the various headers in an HTTP response can be used to identify a Web server; for instance, the Apache Web server displays all HTTP header data, including the Server header, in a different order than IIS. This header order signature is one reason why URLScan is not a useful anti-reconnaissance tool, as it allows you to remove some headers that are IIS-specific but it actually creates a unique order in IIS header responses that can be fingerprinted. IIS itself also has a unique HTTP header order fingerprint. By using this ServerMask option, HTTP headers will appear in the order that they would in an Apache Web server HTTP response, providing another layer of misdirection. To really confuse hackers, customize a non-standard or unique Server header with ServerMask, and then emulate the Apache HTTP header order. Hackers won't know what to think of your server!
  • Emulate Apache (ALLOW) header format: When an ALLOW method request is made to IIS, the order and format of the HTTP response is a known signature. Use this option to respond as the Apache Web server would respond to this request in terms of header format and order to add further misdirection against potential hackers.
  • Disable WebDAV to remove identifying headers: Another way of identifying Microsoft servers has to do with their implementation (starting in Windows 2000 and IIS 5.0) 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 its own IETF Working Group. However, Microsoft's implementation does provide another means of identifying an IIS server through HTTP header analysis. To see how this works, try the following experiment. Using a command prompt (DOS) window, telnet to a Windows 2000 server running IIS 5.0 on port 80: C:\>telnet myhost.bogus.com 80 Now you will see a blank DOS window with just a blinking cursor. Type in the following line and then press the Enter key twice (You will not see what you type echoed on the screen but don't worry, it will still work -- provided you remember to hit Enter twice.): OPTIONS / HTTP/1.0 What you see next will look something like this: HTTP/1.1 200 OK
    Server: Microsoft-IIS/5.0
    Date: Tue, 24 Sep 2002 17:47:19 GMT
    MS-Author-Via: DAV
    Content-Length: 0
    Accept-Ranges: none
    DASL: <DAV:sql>
    DAV: 1, 2
    Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
    Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
    Cache-Control: private
    As you can see, WebDAV support adds a lot of information to the headers sent back by the server. Even supposing the Server header and other signatures had been hidden or changed using ServerMask, this response to the HTTP OPTIONS method would still have given away the server's identity in the very name of the "MS-Author-Via" header.

    If you are not using WebDAV already (for example to support Outlook Web Access with Exchange server or for publishing to Web folders using Internet Explorer), we recommend disabling WebDAV entirely. This can be accomplished with one click in ServerMask or by editing the registry on Windows 2000. This feature will be disabled on NT 4.0 systems, and on Windows 2003 systems, WebDAV is disabled by default.
back to top


I can use ServerMask to remove file extensions from my source code and URLs? What about PageXchanger?

File extensions referenced throughout your Web site's source code (hackers love the View Source option) and displayed for target pages in the Address bar of a Web browser are dead give-aways for your Web server platform -- if they reference an application server or piece of software related to that Web server. Similar to cookie masking, it is important to mask your file extensions when you are running ASP and ASP.NET if you hope to anonymize fully with ServerMask. This functionality had resided solely in Port80 Software's PageXchanger product -- this tool is still our most feature-rich implementation of content negotiation, but ServerMask provides "good enough" file extension masking functionality that you will not need both tools if anti-reconnaissance is your goal. That said, this feature can cause some challenges if you do not plan for implementation.

Content negotiation is the HTTP specification's method of delivering a Web response based in part on the browser or client's preferences and/or intentions. To serve a page without extensions, we do not have to look for any browser preferences in the HTTP request, but we have to see what the request is for on the server side. File extensions are not as important as they seem. The MIME type indicates what is coming back from a server, not the file extension. This is why you can ask for a file like homepage.asp and yet it appears to be an HTML file to your browser. In short, since ServerMask with this advanced option enabled will serve all of your MIME types (and your Web site's files) properly, and it works with even very old Web browsers (though some pre-1995 browsers may not work). This feature has been thoroughly tested with the major browser types currently used today, and this IIS server module works with browsers from Microsoft, Netscape, Mozilla and more.

The files on your Web server themselves will continue to have their extensions, but the links to them in the source code will not.

For example, HTML like

<a href="product1.html">product 1 specifications</a>

would be changed to

<a href="product1">product 1 specifications</a>

but the file name product1.html would continue to exist in the directory as is.

Similarly, <img src="/portals/0/logo.gif"> would just become <img src="/portals/0/logo">.

Removing the file extension references is easily performed in common HTML editors like HomeSite or Dreamweaver, our w3compiler client desktop tool, or with the included Port80 Software File Extension Stripper utility that can be run from the command line (see the product documentation or the utility itself after installing ServerMask -- StripExt.exe -- to learn more).

One other caveat when you turn on this advanced feature in ServerMask: make sure that you do not have two files in the same target URL directory with the same name (like http://[hostname]/directory/foo.asp and http://[hostname]/directory/foo.htm). In this case, ServerMask may respond with the wrong version of the page when this feature is enabled. To avoid this issue, review your sites names in the process of removing your file extensions from source code to avoid this potential pitfall.

By removing the file extensions for anti-reconnaissance, you will also receive the benefit of easy future technology transfers from, for example, ASP to ASP.NET. As your source code will no longer rely on extensions, you will not have to update links on the Internet with the new URL or lose search engine rankings when your file extensions change, because the reference will be to the file itself, not the technology choice.

back to top


What does the response code anti-reconnaissance option do in the advanced features?

Some of the best hacker reconnaissance tools rely on odd HTTP error and status condition responses that they have discovered in extensive penetration testing, and ServerMask is designed to thwart their efforts.

While we do not want to share a complete list of the types of subtle message and format changes that we employ in ServerMask (as we do not want to make recon easier for the hackers), the tool does modify some 200, 400, 403, 404, 405 and 501 server responses that are used to identify IIS at the HTTP header level. This will not break your pages, but it will overpower some of the most robust hacker scanners available today. One example: use an HTTP analysis tool and make a customized request with HTTP version 5.6 (this specification does not exist yet), and see how ServerMask responds...

back to top


Which default profile (Hide, Emulate or Randomize) should I choose?

Think of these 3 profiles in terms of how aggressively you hide your data. The more aggressive you are the more difficult it is for a hacker or scanner to determine your true server platform. The tradeoff is that there may be compatibility issues. These are unlikely problems, but are something to consider given the complexity of your application and what your security requirements actually are.

You decude whether you want to simply to remove the data (Hide), to misdirect the hacker (Emulate), or to truly anonymize your platform (Randomize). Here's a tip - to add an additional layer of anonymization, use a different profile for each of the various sites you manage.

back to top


Is installing ServerMask all I need to do to make my server anonymous?

Absolutely not -- server anonymization is just one aspect of server security. It is a preemptive measure to keep would-be intruders from identifying your technology platform and exploiting it. The concept is to use obfuscation and misdirection to dissuade or delay a hacker so they can be identified and dealt with by your intrusion detection and firewall systems. In this manner, your server will also be less of a target for hackers trying to test new exploits before Microsoft has issued a security patch.

Always keep up with Microsoft security patches and deploy an overall security strategy that includes server anonymization, firewalls, intrusion detection, and authentication security. Most security issues arise from "not covering all the bases" -- and it only takes one hacker to cause critical damage to your Internet presence and related technology infrastructure. Develop an overall security strategy that fits your business model and make sure that server anonymization is a pillar in that strategy. Even with ServerMask installed, you will need to do a few more things to anonymize your server. We recommend that you implement these IIS security measures in your environment:

  • As with SMTP banners, IIS also displays an FTP banner in its FTP service response. If an FTP server is needed on the computer on which IIS is running, we recommend using an alternate FTP server like RhinoSoft's Serv-U which allows you to mask FTP banner display. RhinoSoft offers free trials for download at their Web site.

  • Default pages of all kinds often contain clues to server identity and should be removed or modified accordingly. Remove or hide such things as default home pages and any server administration pages or Web-based documentation that would give away the OS.

  • Implementing custom 404 and other HTTP error pages is a good practice in general for enhanced user experience on a Web site. Using customized error pages is a good usability practice as well and will avoid displaying server-specific error messages.

  • Even when all these telltale signs are removed from your Web server's application layer, there remain detection vulnerabilities at lower network layers like TCP/IP. In particular, you must be cognizant of the fact that any box with a network connection has a network protocol stack that, if unprotected, is subject to being scanned and thereby identified. The best network scanners (such as Nmap from www.insecure.org) can still ID a Windows (or any other) box by using a variety of techniques to fingerprint the system's TCP stack -- this is why we recommend deploying some form of TCP/IP information leakage protection as well as ServerMask.

  • If possible, avoid using "Integrated Windows Authentication" in IIS Security settings as a way of hiding known default files. This method betrays the very secret it would keep. By requesting known, OS-specific default pages that are hidden in this way, a script or visual hacker can identify the Windows box by means of the WWW-Authenticate headers sent by the server. When the page is protected by NT Challenge-Response authentication, one of the authentication headers will contain the string "NTLM" (for "NT LAN Manager") -- a Microsoft-specific form of HTTP authentication. For anonymization of your IIS server and as a best practice, we recommend using "Basic Authentication" with SSL for hiding known default files or protecting directories.


back to top


Will ServerMask affect my server's performance?

Not noticeably. ServerMask is an extension of your Web server's default functionality, so it must necessarily add some small increment of additional load. In practice, however, ServerMask is so small, and it ties in to the Web server at such a low level, that the additional load is almost imperceptible, even in the test lab where the smallest performance differences can be recorded.

back to top


Will removing or modifying HTTP headers and signatures in Web responses have any negative effect on my Web site or application?

In almost all cases the answer is simple: None at all. Browsers do not rely on the presence or accuracy of these details, and neither do the kind of bots that are probably welcome visitors to your site (search engine crawlers, for example).

This is because Web servers have a relatively simple job, compared to modern browsers -- they only have to implement one simple and stable specification (HTTP), while browsers are responsible for implementing a whole range of complex and evolving specifications and standards (HTML, JavaScript, DOM, CSS, etc.). As a result, there is much less variation among Web servers than among Web browsers. This is why browsers don't need to "sniff" or "sense" the Web server's identity the way some Web applications have to sense the type of browser in order to display content like FLASH correctly.

In fact, almost the only non-malicious reason anyone might want to know what kind of Web server software you are running is to try to market server products to you! Since the type of Web server you have is not information that your Web clients rely upon, there is no harm in concealing or otherwise obfuscating this information.

So why did we qualify our answer by saying "in almost all cases?" Well, it is theoretically possible for someone to write a non-malicious piece of client software that, for some reason, relies on being able to know the type of Web server or one of signatures that ServerMask camouflages. And it's also possible that you might, for some reason, want your Web site or application to support such software. This scenario is both highly unlikely and, chances are, unnecessarily risky -- there are probably other, smarter ways to accomplish whatever it is you are trying to do (instead of leaving your door unlocked so your neighbors can feed your cat or dog, it might be better to make them their own key). But it's certainly a possible scenario and, if it applies to you, then you shouldn't be running ServerMask. After all, you can't simultaneously expose and conceal your server's identity.

back to top


How can I tell if ServerMask is working?

Our free online " target="blank">Header Check tool is a good place to start.

Most of what ServerMask does is visible in the HTTP headers returned by the Web server on which it is operating. While browsers do not ordinarily allow you to inspect these headers, there are a number of tools available online that make it easy to do so. For quickly checking the HTTP headers sent by a Web server, use our Header Check tool or the HTTP analysis packages like ieHTTPHeaders.

To use an HTTP analysis tool, point it at a Web site hosted on your server and visit the site. The HTTP headers will be printed out on screen of most HTTP analysis tools for the requests and the responses generated when you requested a URL, usually below the displayed page in the tool. Try turning ServerMask features on and off, and varying the settings. You should be able to see the expected changes in the value of ServerMask-protected signatures easily (for testing on disabling WebDAV and the Public header, be sure to specify an OPTIONS request method in your HTTP analysis tool, rather than the default GET in most tools; to test ALLOW method responses, specify this method of request in your HTTP analysis tool).

back to top


back to top