Configuring Your Web Server to Not Disclose Its Identity

If you are running a web server, it often shows the world what type of server it is, its version number, and the operating system. This information is available in header fields and can be acquired using a web browser to make a simple HTTP request to any web application. It is often called the web server banner and is ignored by most people with the exception of malicious ones.

Attackers can perform banner grabbing using even simple TCP tools like telnet or netcat. Then they launch targeted attacks against your web server and version. In addition, if a particular web server version is known to be vulnerable to a specific exploit, the attacker would just need to use that exploit as part of their assault on the target web server.

A security tool such as the Acunetix network security scanner would highlight and report that your web server provides such information and would recommend limiting that information. This does not solve any vulnerabilities and thus does not eliminate the need to install updates. However, it makes it more difficult for the attacker who will not know if they are dealing, for example, with Apache on Red Hat Linux, IIS 5.0 on Windows, or nginx on Debian.

The following is an example of the HTTP response 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
Content-Length:226
Connection: close
Content-Type: text/html; charset=iso-8859-1

Limiting Information Provided by Apache

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

  • ServerTokens Prod: This will configure Apache to not send any version numbers in the server response header so that the server line will be: Server: Apache. Prod is the value that provides the least information (product name only). If no ServerTokens directive is provided, it is equivalent to ServerTokens Full (with the result being, for example, Server: Apache/2.4.2 (Unix) PHP/4.2.2)
  • ServerSignature Off: This will ensure that Apache does not display the server version in the footer of server-generated pages. Note that this is the default setting.
  • 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. However, you can change it to whatever you want using modSecurity.

Limiting Information Provided by IIS

The IIS server will also expose its version in 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 set up this configuration on a site-by-site basis, check out the UrlScan Setup article by Microsoft.

  • Enable Metabase Compatibility. Find out how to enable Metabase Compatibility using the Installing Metabase Compatibility Support article by Microsoft.
  • Install UrlScan.
  • Open the UrlScan.ini file with a text editor. The file is usually located in the %windir%\system32\inetsrv\UrlScan 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, which defines configurations for the HttpCoreModule. Uncomment (remove the # symbol) or add the following directive:

server_tokens off;

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

You can also remove the server name. However, since nginx modules cannot be dynamically loaded, you need to recompile nginx from source with the HttpHeadersMoreModule nginx module.

Share this post
Nicky SciberrasNicholas Sciberras Chief Technical Officer
LinkedIn: https://www.linkedin.com/in/nicholas-sciberras/

As the CTO at Acunetix, Nicholas is passionate about IT security and technology at large. Prior to joining Acunetix in 2012, Nicholas spent 12 years at GFI Software, where he managed the email security and anti-spam product lines, led multiple customer service teams and provided technical training.
  • 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:

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

    • 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 https://b.unni.es/ and as a proof of concept, that webserver is using that configuration:

    [root@b ~]# wget -SO- https://b.unni.es/ 2>&1|grep Server:
    Server: Fujitsu WebServer 8.49.9552
    [root@b ~]# wget -SO- https://b.unni.es/ 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- https://b.unni.es/ 2>&1|grep Server:
    Server: Apache/1.3.34 (Debian) PHP/4.4.4-8 DAV/1.0.3
    [root@b ~]# wget -SO- https://b.unni.es/ 2>&1|grep Server:
    Server: TUNIX-httpscreen/4.0

    etc.

    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 (https://en.wikipedia.org/wiki/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.