Configuring your Web Server to Not Disclose its Identity

If you are running a web server, that web server is probably showing the world what type of server it is, and possibly its version number. This information is ignored by most people, with the exception of hackers, who use this information to launch targeted attacks against your web server and version. In addition, if the version of your web server is known to be vulnerable to a specific exploit, the hacker would just need to use the exploit as part of his attack on your server.

An Acunetix Online network scan would highlight and report that your web server is providing such information, and would recommend limiting the information provided by your web server. This does not solve any vulnerabilities, and thus does not remove the need to install updates, however it makes it slightly more difficult for the hacker.

The following is an example of the header sent from a web server that is exposing too much information:

HTTP/1.1 200 OK
Date: Thu, 12 Jun 2014 14:15:01 GMT
Server: Apache/2.2.21 (Win32) PHP/5.4.7
Connection: close
Content-Type: text/html; charset=iso-8859-1

In this article, we will show you how to configure the 3 most popular web servers, Apache, IIS and nginx, to limit the information provided about the web server application being used.

Limiting information provided by Apache

You can limit the information that Apache presents by creating / editing the following directives in httpd.conf

  • ServerTokens Prod
    This will configure Apache to not send any version numbers in the HTTP header, so that the server line will be: Server: Apache
  • ServerSignature Off
    This will ensure that Apache does not display the server version in the footer of server generated pages.
  • The above solution would still not allow you to hide the fact that you are using Apache, since the Server HTTP header will still say Apache. This can be altered using modSecurity.

Limiting Information provided by IIS

IIS will also expose its version in the HTTP responses.

Microsoft provides URLScan, which can be used to remove server information from HTTP responses sent by IIS. URLScan requires IIS6 Metabase compatibility to work. Additionally, the configuration made to IIS is global. If you want to setup this configuration on a site-by-site basis, check out this article.

  • Enable Metabase Compatibility. Find out how to enable Metabase compatibility.
  • Install URLScan
  • Open the URLScan.ini file with a text editor. The file is usually located in the %WINDIR%System32InetsrvURLscan directory.
  • Search for the key RemoveServerHeader, which by default is set to 0. Set the value to 1 in order to remove the Server header.

Limiting Information provided by nginx

You can limit the information that nginx presents by creating / editing the following directive in nginx.conf.

Find the http section, this section defines configurations for nginx’s HttpCoreModule. Uncomment (remove the ‘#’ symbol) or add the below directive:

server_tokens off;

This will configure nginx not send any version numbers in the HTTP header.

Removing the server name is possible, however, since nginx modules cannot be dynamically loaded, you would need to recompile nginx from source with the HttpHeadersMoreModule nginx module.

Share this post
  • For IIS 7 and above, add an URL Rewrite outboundRule to your website’s web.config file:

    in the node. This does not really remove the Server response header, but empties its result. You can also rewrite it with bogus information if you’d like.

    • Web.config code:

      <outboundRules rewriteBeforeCache=”true”>
      <rule name=”Remove Server header”>
      <match serverVariable=”RESPONSE_Server” pattern=”.+” />
      <action type=”Rewrite” value=”” />

    • Hi,

      You can use Custom Headers to alter the information provided in the Server header. This is explained in the following IBM Technote. Note that the Technote also describes an issue with Server response 400.

  • Hi, can you specify how to manage this with .htaccess on apache? I dont have the httpd.conf file to configure, but i can make changes to the .htaccess file. Many thanks

    • Hi, I believe you should still be able to use ServerSignature Off in your .htaccess file. I would advise you to take a backup of your .htaccess file before you make any changes, just in case something goes wrong.

  • If you’re going to compile nginx from source, you might as well compile the LUA module so that you can randomly change your webserver banner per request.

    Instructions for doing so are on my website and as a proof of concept, that webserver is using that configuration:

    [root@b ~]# wget -SO- 2>&1|grep Server:
    Server: Fujitsu WebServer 8.49.9552
    [root@b ~]# wget -SO- 2>&1|grep Server:
    Server: Apache/2.2.3 (Debian) mod_jk/1.2.18 mod_python/3.2.10 Python/2.4.4 PHP/4.4.4-8+etch4 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
    [root@b ~]# wget -SO- 2>&1|grep Server:
    Server: Apache/1.3.34 (Debian) PHP/4.4.4-8 DAV/1.0.3
    [root@b ~]# wget -SO- 2>&1|grep Server:
    Server: TUNIX-httpscreen/4.0


    Of course, changing your web server’s banner like this adds absolutely no security benefits. It just confuses most automated scanners and the script kiddies, which is always fun. If my daily access logs are any indication, most lazy worm writers don’t bother checking if a vulnerable thing exists on a web server before attempting exploitation.

    That means that if you’re running vulnerable software anywhere on your website but masking that software’s presence using any of these tricks, it doesn’t change the fact that you’re running vulnerable software. It just makes it slightly harder for an attacker to be certain that you’re running that particular vulnerable software. In other words, doing “server_tokens off;”, or “ServerTokens Prod”, or my nginx/LUA trick to prevent advertising your OpenSSL version doesn’t help much if you’re running an older OpenSSL still vulnerable to Heartbleed, and the attacker is blindly attempting to exploit Heartbleed on all Apache/nginx web servers s/he finds regardless of whether or not the OpenSSL version is being displayed in the banner.

    • Thanks for sharing.

      You are you correct – most worms will try to exploit the vulnerability without bothering checking the server version. Ideally the server should always be kept up to date in terms of patches etc. Having said that, why make it easy to hackers who are after a targeted attack?

  • Hello guys, i’m trying to disable my server signature.. i had disable it at my origin server using httaccess code.. but afterward i realize there is some problem.. due to using cloud-flare they have own server signature on cdn service.. getting this “Value: cloudflare-nginx” error for disable it.. guys help me out to disable that server sigunatre …

    • Hi Jee,

      Thanks for your comment.

      Changing settings on your own server in this case will not be enough. This is because your provider is likely acting as a reverse proxy ( to your site.

      If you are concerned about this, perhaps you can get in touch with your provider to see if they support turning the mentioned headers off.

  • Hello,
    There is a typo under “Limiting information provided by Apache”.
    “using” is listed twice in the sentence “This can be altered using using modSecurity.”

  • Hello,
    this is usefull information to secure webserver but what if the attacker using scanner like nmap ??
    some information about version OS and webserver still exist.
    can u provide solution ? maybe another configuration like this article ?

    Thank You

  • We will create articles related to this moving forward, however the above article already provides information which would reduce the information provided following an nmap scan on the server.

  • Isn’t it most useful to ensure one’s server software is properly updates?
    Surely these instructions should not be considered an excuse to run obsolete software with known vulnerabilities, right?

  • Leave a Reply

    Your email address will not be published.