Eliminate banner grabbing in Apache Tomcat

Don't let your Tomcat installation be a cyber snitch

Banner grabbing is often the first step before a full-blown cyber attack, but it's easy to prevent. Learn how to secure your Apache Tomcat installation against version-based exploits by overriding the default parameters in your Server.xml and ServerInfo.properties files.


Manuel Alejandro Peña Sánchez (psmapad@gmail.com), IT Security Specialist, Freelance

Manuel Alejandro Peña Sánchez is an IT security specialist with 13 years of experience. He specializes in translating technical issues to management teams, and vice versa. He is frequently named a valued business associate and advisor by the IT leaders he consults for.

02 December 2013

Also available in Russian Japanese

Creating a security culture

Companies move applications to the web to improve customer interactions, lower business processing costs, and speed outcomes. But doing so also increases vulnerabilities—unless security is an integral component of the application development process. To learn more about creating a culture of security in your organization, download and read "Secure Web Applications: Creating a Security Culture."

Apache Tomcat is one of the most popular open source web servers in the world, used in both large-scale production environments and smaller start-up and experimental implementations. Unfortunately, Tomcat's popularity has also made it a target for hackers looking to discover and exploit security vulnerabilities, especially in older versions of the web server.

In this article, I demonstrate a three-step procedure for securing your Tomcat web server against banner grabbing, the technique hackers use to discover valuable information about an application or enterprise architecture, which they may then be able to use in a cyber attack.

Apache HTTP Server

While there is a lot of information about preventing banner grabbing on Apache HTTP Server (see Resources), very little has been documented about securing Tomcat against similar attacks. Therefore, this article focuses on Apache Tomcat.

I'll start with a short introduction to banner grabbing, then show you how to defend your Tomcat web server against it. Note that the instructions are for any version of Tomcat running in a Linux® or Windows® environment.

What is banner grabbing?

You are probably familiar with the following image, a view into a host application (in this case Tomcat web server) accessed through an SSH terminal and a simple Telnet command:

Figure 1. A server host request
Screenshot of a server host request.

If an attacker wants to look for vulnerabilities in a system, banner grabbing is an easy way to do it. As shown in Figure 1, the banner (that is, the text displayed by the host server) reveals the software that the system is running, including the version number. The attacker can then look for known vulnerabilities in that version, which he or she could exploit. By default, application servers display this information on request.

Attackers can also look at web server error pages for vulnerable, system-level information. Figure 2 shows a web browser view that has redirected to a server error page, where the server's version number is displayed.

Figure 2. A Tomcat error page
Screenshot of a Tomcat error page.

Banner grabbing is remarkably easy to do, which is why it is often the first step for a hacker seeking to find and exploit application vulnerabilities.

How to eliminate banner grabbing

Note: Before changing anything about your Tomcat server implementation, be sure to back up your files.

In this section, I demonstrate a three-part procedure for eliminating banner grabbing in your Tomcat web server implementations. Essentially, you'll block your Tomcat server's response to a Telnet or other command. The procedure is very easy.

Step 1. Edit your server.xml file

The server.xml file is normally located in the root path of your Tomcat installation. For a binary installation it would be located in /etc/tomcat"X", where X indicates the server version. So in a Debian Linux installation with a Tomcat binary package installation, the server.xml file location would be /etc/tomcat6/server.xml. If you downloaded the TAR file from the Apache homepage and extracted the server.xml file in /opt, the location would be /opt/apache-tomcat-"X"/conf/server.xml. In some cases, this path would be named $CATALINA_HOME, so the file location would be $CATALINA_HOME/server.xml.

You can run the following command to easily find the path of your server.xml file:

#> find / -name server.xml

Next, find the connector port line in the server.xml file. The line displayed in Figure 3 tells Tomcat what port the service listens on.

Figure 3. Connector port
Screenshot of the connector port line in the console.

Add a server parameter to this line to specify how you want Tomcat to respond when a user asks for the system version. Here's an example:

    <Connector port="8080" .....

Put anything you'd like in the server parameter: Apache, APPSRV, server, MyTeam, and so on. The only rule is that the value cannot be empty and that it should not reveal the information the hacker is looking for.

Figure 4. New server parameter
Screenshot of the new server parameter.

After you've made the change to your server.xml file, save it and exit your file editor. With this first step you have successfully prevented Tomcat from revealing its server version to anyone who asks.

Step 2. Edit your ServerInfo.properties

Next, you'll configure your Tomcat server so that it doesn't reveal its version in publicly accessible error reports. This is a slightly more complex step, but not too difficult.

First, find the catalina.jar file in your Tomcat installation and extract the ServerInfo.properties file from it. The catalina.jar file is typically located in a binary installation in /usr/share/tomcat"X"/lib. In the case of a TAR file installation it will be on Tomcat's root installation path in the lib directory.

So, in a Debian Linux installation with a Tomcat binary installation, the catalina.jar file will be in /usr/share/tomcat6/lib/catalina.jar. If you downloaded the TAR file from the Apache homepage and extracted the catalina.jar in /opt, the location would be $CATALINA_HOME/lib/catalina.jar.

You can easily search for the file path by running the following command:

#> find / -name catalina.jar

Before you continue, make sure that you back up your catalina.jar file.

Next, to extract the ServerInfo.properties file from catalina.jar, run the following:

#>  jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties

This command instructs jar to extract the ServerInfo.properties file that is located in /org/apache/catalina/util inside catalina.jar.

The file's server.info and server.number parameters are shown in Figure 5.

Figure 5. Parameters for server.info and server.number
A screenshot of the server.info and server.number paramters in the console.

You can change these values to anything you like or delete a value. For instance, you could change the following parameters:

server.info=Apache Tomcat 6.0.x.x/x

to these:


When you're happy with the changes, save the file and exit. You will still need to compress the modified file to catalina.jar, which you can do with the following command:

 #>  jar uf catalina.jar  org/apache/catalina/util/ServerInfo.properties

Note that you can delete the org directory after you've replaced it with your modified one.

Your Apache Tomcat installation is now configured to resist banner grabbing from common error messages.

Step 3. Restart Apache Tomcat

The last thing you'll do is to restart Apache Tomcat. For a binary installation, run the following command:

#> /etc/init.d/tomcat6 restart


#> service tomcat6 restart

For an extracted TAR file, run this command:

#> . /$CATALINA_HOME/bin/shutdown.sh
#> . /$CATALINA_HOME/bin/startup.sh

To verify the changes to your Tomcat installation, do the following:

  1. Open a Telnet session to your modified Tomcat server on the port the server listens on:
    #> telnet 8080
  2. When the server responds, transmit a request for the options it supports:
    #> OPTIONS / HTTP/1.1
    #> HOST:
    #> [ENTER]
  3. The server response will look similar to Figure 6, displaying the server parameter values that you updated in the server.xml file:
    Figure 6. Verify the new host server response
    A screenshot of the new server response.
  4. Now open your browser and redirect it to the main page of your Tomcat installation, adding a page request that could cause an error, like this one:
  5. Tomcat will not recognize the URL and will send an error message, but one that does not reveal any information about the server version:
    Figure 7. Verify the new error message response
    A screenshot of the new error message.

From the banner message in Figure 7, an attacker would see that the server installation was Apache, but not the particular server or version that was running. Success!

In conclusion

Keeping your Tomcat server installation up to date is the best way to secure your applications against known server exploits. Overriding Tomcat's default banner behavior to hide version information is also effective. It will keep hackers from easily formulating a cyber attack, which could help you sleep better at night.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Security on developerWorks

Zone=Security, Java technology
ArticleTitle=Eliminate banner grabbing in Apache Tomcat