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.
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
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
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
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" ..... server="APPSRV"
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
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.
server.number parameters are shown
in Figure 5.
Figure 5. Parameters for server.info and server.number
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 server.number=188.8.131.52
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:
- Open a Telnet session to your modified Tomcat server on the port the server listens on:
#> telnet 192.168.237.119 8080
- When the server responds, transmit a request for the options it supports:
#> OPTIONS / HTTP/1.1 #> HOST: 192.168.237.119 #> [ENTER]
- 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
- 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:
- 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
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!
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.
- Securing Tomcat: More about securing Tomcat web servers.
- How (and why) to disable Apache server signature on your web pages: A guide to blocking banner grabbing on an Apache server.
- "Web server security" (developerWorks, September 2002): Learn how to secure dynamic content on an Apache HTTP Server.
- Apache Tomcat 7 — Security Considerations: Get security information and tips for configuring Tomcat 7.
- Visit the Security On developerWorks blog to learn about new security-related how-to guides, articles, and demo videos.
- Sign up for the weekly Security On developerWorks newsletter for the latest security headlines.
- Follow @dwsecurity to get updates from the developerWorks Security zone in realtime.
Dig deeper into Security on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Pragmatic, intelligent, risk-based IT Security practices.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.