Securing tomcat

Introduction

Most weaknesses in Apache Tomcat come from incorrect or inappropiate configuration. It is nearly always possible to make Tomcat more secure than the default out of the box installation. What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system. Please note that the section ordering is not a representation of the section importance.

Software Versions

The first step is to make sure you are running the latest stable releases of software;

• Java Runtime Environment (JRE) or SDK
• Tomcat
• Third party libraries

This does not mean you have to upgrade all your production servers to a new (and potentially buggy) release which has just been made available to the public. What you must do is download the latest stable bugfix release that has continual support. For the JRE and Tomcat you should be looking at the last digits in the version number (5.5.X) as it represents the bugfix information. The bugs fixed in these releases are publicly available so if you don't upgrade you could be providing attackers with a very easy route to compromise your server.

Installation of Apache Tomcat 5.5

UNIX

• Create a tomcat user/group
• Download and unpack the core distribution (referenced as CATALINA_HOME from now on)
• Change CATALINA_HOME ownership to tomcat user and tomcat group
• Change files in CATALINA_HOME/conf to be readonly
• Make sure tomcat user has read/write access to /tmp and write (yes, only write) access to CATALINA_HOME/log

Windows

• Download the core windows service installer
• Start the installation, click Next and Agree to the licence
• Untick native, documentation, examples and webapps then click Next
• Choose an installation directory (referenced as CATALINA_HOME from now on), preferably on a different drive to the OS.
• Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
• Complete tomcat installation, but do not start service.
• TODO: filesystem security

Common

• Remove everything from CATALINA_HOME/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)
• Remove everything from CATALINA_HOME/server/webapps (host-manager, manager). Note that it can be useful to keep the manager webapp installed if you need the ability to redeploy without restarting Tomcat. If you choose to keep it please read the section on Securing the Manager WebApp.
• Make sure the default servlet is configured not to serve index pages when a welcome file is not present. In CATALINA_HOME/conf/web.xml

 <servlet>
   <servlet-name>default</servlet-name>
   <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
   <init-param>
     <param-name>debug</param-name>
     <param-value>0</param-value>
   </init-param>
   <init-param>
     <param-name>listings</param-name>
     <param-value>false</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
 </servlet>

• Replace default HTTP error pages (i.e. 404) by adding the following into CATALINA_HOME/conf/web.xml. The default HTTP error pages show the full Tomcat version which is unnecessary information disclosure. The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.

 <error-page>
   <error-code>404</error-code>
   <location>/404.jsp</location>
 </error-page>

• Replace default error page (default is stacktrace) by adding the following into CATALINA_HOME/conf/web.xml. The default error page shows a full stacktrace which is a disclosure of sensitive information. The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.

 <error-page>
   <exception-type>java.lang.Exception</exception-type>
   <location>/error.jsp</location>
 </error-page>

• Consider replacing CATALINA_HOME/conf/server.xml with CATALINA_HOME/conf/server-minimal.xml - work out what we lose
• is it easy to remove the version string from the server HTTP header (Apache-Coyote/1.1) ?
• Start Tomcat, deploy your applications into CATALINA_HOME/webapps and hope it works!

Securing Manager WebApp

• By default there are no users with the manager role. To make use of the manager webapp you need to add a new user into the CATALINA_HOME/conf/tomcat-users.xml file.

 <user username="darren" password="ReallyComplexPassword" roles="manager"/>

• Using a valve to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in CATALINA_HOME/conf/Catalina/localhost/manager.xml

 <!-- allow only LAN IPs to connect to the manager webapp -->
 <!-- contrary to the current Tomcat 5.5 documation the value for allow is not a regular expression -->
 <!-- future versions may have to be specificed as 192\.168\.1\.* -->
 <Valve className="org.apache.catalina.valves.RemoteAddrValve"
        allow="192.168.1.*" />

 <!-- allow only LAN hosts to connect to the manager webapp -->
 <!-- contrary to the current Tomcat 5.5 documation the value for allow is not a regular expression -->
 <!-- future versions may have to be specificed as *\.localdomain\.com -->
 <Valve className="org.apache.catalina.valves.RemoteHostValve"
        allow="*.localdomain.com" />

• You can rename the manager webapp to something else, e.g. foobar
  • Move CATALINA_HOME/conf/Catalina/localhost/manager.xml to CATALINA_HOME/conf/Catalina/localhost/foobar.xml
  • Update the docBase attribute within CATALINA_HOME/conf/Catalina/localhost/foobar.xml to ${catalina.home}/server/webapps/foobar
  • Move CATALINA_HOME/server/webapps/manager to CATALINA_HOME/server/webapps/foobar

Logging

• TODO: Audit trails

Encryption

• SSL for password or other sensitive data exchange (bordering on application security, not specific to tomcat)
• SSL for connections (JDBC, LDAP, etc ..)
• The Tomcat documentation clearly explains how to enable SSL.

Java Security

Running Tomcat with a Security Manager

The default Tomcat configuration provides good protection for most requirements, but does not prevent a malicious application from compromising the security of other applications running in the same instance. To prevent this sort of attack, Tomcat can be run with a Security Manager enabled which strictly controls access to server resources. Tomcat documentation has a good section on enabling the Security Manager.

Miscellaneous

• Tomcat Security FAQ

Using Port 80

If you are on a Windows machine you will be able to change the port attribute of the connector within the Catalina service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;

• Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;

• Use Apache running on port 80 and mod_jk (or mod_proxy_ajp) to proxy requests to Tomcat
• Run Tomcat as root, but in a chroot jail
• Use a tool like authbind to enable a non root user to bind to ports below 1024
• Use a port forwarder such as Iptables to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
• Run Squid as a web accelerator in front of Tomcat
• Use JSVC/procrun

Cleartext Passwords in CATALINA_HOME/conf/server.xml

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;

• make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
• make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
• make sure the Tomcat configuration files are only accessible to the tomcat user