Apache Tomcat is the perfect application server for deploying your web applications in production. In fact, it also happens to be the only Java application server that has hardening guidelines published by Center for Internet Security (CIS). CIS publishes hardening guidelines for widely used software to help enterprises protect their deployments. The very fact that they have hardening guidelines for Tomcat is a testament to its widespread popularity and usage.
So, how do you know if your Tomcat installation is secure? Its actually very easy. I will provide step-by-step instructions on evaluating whether your Tomcat is secure. If you find that you need to make changes, you can use Tcat Server to harden your Tomcat instance.
Step 1: Get coffee. Yes, you will need it, because you will be reading a 56-page report.
Step 2: Download the hardening guidelines for Apache Tomcat from Center for Internet Security. (Look for Apache Tomcat Server under Applications.)
Step 3: Follow each step and instructions starting on page 9.
Step 4: Do the audit steps and find your deviation from hardening guidelines.
Step 5: Follow the remediation advice and if applicable to your environment, apply the remediation steps.
As you go through this process, you might have realized that the majority of work is in editing server.xml, web.xml, and logging.properties. For example:
1.4.5 Disable client facing Stack Traces (Level 1, Scorable)
Description:
When a runtime error occurs during request processing, Apache Tomcat will display debugging information to the requestor. It is recommended that such debug information be withheld from the requestor.
Rationale:
Debugging information, such as that found in call stacks, often contains sensitive information that may useful to an attacker. By preventing Tomcat from providing this information, the risk of leaking sensitive information to a potential attacker is reduced.
Remediation:
Perform the following to prevent Tomcat from providing debug information to the requestor during runtime errors:
1. Create a web page that contains the logic or message you wish to invoke when encountering a runtime error. For example purposes, assume this page is located at /error.jsp.
2. Add a child element, <error-page>, to the <web-app> element, in the $CATALINA_HOME/conf/web.xml file.
3. Add a child element, <exception-type>, to the <error-page> element. Set the value of the <exception-type> element to java.lang.Throwable.
4. Add a child element, <location>, to the <error-page> element. Set the value of the <location> element to the location of page created in #1.
How do you edit these configuration files? You have a few options. Option 1 is to manually log in to each box running Tomcat and edit these files manually. Option 2 is to use the Tcat Server console to navigate to each server and edit these files all within the console. Option 2 is easier than Option 1, but it still requires you to do some repetitive work – well, lets leave repetitive work to others.
Option 3 is the best way, as it avoids repetitive work for the majority of changes you need to make. So, whats the secret? Use Tcat Server and create a configuration profile. A configuration profile holds environment variables and configuration files together. You create a profile and apply it to all the Tomcat server instances that you want to harden. Creating a profile is a simple process, as described by Jason in this post. Applying the profile to servers is even easier, as you just select the profile from a drop-down box and click Save.
If you follow these instructions and harden your Tomcat instances, next time an auditor or your information security officer walks into your office demanding that you prove the security of your infrastructure, you can just point them to the profile and show them the settings. And yes, while others running heavy-weight legacy Java EE app servers are sweating and swearing at the auditors, you could relax and get back to doing more productive things. Like drinking coffee.
You can download Tcat Server here. It’s free to download and use in development and pre-production.
