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.

Frequently asked questions

THE AUTHOR

Nicholas Sciberras
Principal Program Manager
LinkedIn

As the Principal Program Manager, 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.