Chapter 6. Securing Tomcat's Administrative Web Apps

Recommended Setups

This chapter is not about Tomcat security in general. It is a HOWTO guide for securing the administration web apps in a simple and efficient way which works well whether or not you also need to secure end-user access to any portion of your web apps; and whether or not you use a httpd front end.

If you are running local Tomcat instance(s) on a personal worksation, and you are assured that nobody else can "get onto" your PC, then the easiest solution by far is to just limit access to the administrative applications to the localhost address. To do this, use the Administrative Application. Drill down to Tomcat Server / Service Host and create a RemoteAddrValve to both Context (/admin) and Context (/manager). Restrict remote addresses to 127.0.0.1. Save and commit.

The remainder of this chapter explains how to require direct Tomcat SSL encryption to just the Tomcat administrative web apps. If you have a httpd front end, the front end can just ignore the administrative web apps. This has the added benefit of avoiding ambiguity and considerable possible points-of-failure when just trying to administer your Tomcat server. Regardless of whether you use distributed httpd front ends, load balancers, etc., if you use URL https://saturn.myco.com:8443, you know that you are administering Tomcat on host "saturn". There is no effect to traffic not involved with teh administrative web apps. Note that this is not the way that SSL encryption is done for normal web apps, where the pipe is encrypted only between the web browser and the httpd front end (although you would have to use a Tomcat SSL plugin Connector if you used httpd front end(s) on remote servers separated by a non-trusted network).

Procedure 6.1. Securing Admin Apps with SSL plus IP Filters

  1. First, create a self-signed certificate using keytool. There are simple examples at http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html. There's no reason to purchase a commercial certificate. Each time that you access the web apps with a new web browser, you just need to view the certificate details to verify that it is the cert that you created. You accept the cert "forever" and that browser won't bother you about it again. (Well, unless your browser looses its saved certification settings, or the certificate expires... for this reason, set the certificate lifetime years in the future).

  2. Add a SSL listener to Tomcat by adding another <Connector> element right beneather your main <Connector> element.

    Example 6.1. SSL Connector Element

        <Connector port="5003" maxHttpHeaderSize="8192"
    			   keystoreFile='conf/tcdirect.store'
    			   keystorePass='xyzabc123' keyAlias='tcdirect'
                   scheme="https" secure="true"/>

    You obviously need to specfiy a port number which is available. The keystoreFile is a path to the key* attributes refer to the key store which you created in the previous step. You also need to add a redirectPort attribute to your original (non-SSL) <Connector> element, with value being the new SSL port number. This tells Tomcat to redirect to our SSL port when encryption is required (as we will require in the next step). Make sure to read-protect this server.xml file for now on, since it now contains a password.

  3. Edit the files CATALINA_HOME/server/webapps/admin/WEB-INF/web.xml and CATALINA_HOME/server/webapps/manager/WEB-INF/web.xml Right before the closing </security-constraint> tag, add the following <user-data-constraint> element.

    Example 6.2. web.xml Element requiring SSL

    	<user-data-constraint>
    		<transport-guarantee>CONFIDENTIAL<transport-guarantee>
    	<user-data-constraint>

  4. Finally, use the Administrative web app itself to restrict access to the source IP addresses of the site administrators. Use the same exact method as described at the top of this page, except instead of restricting to 127.0.0.1, you will restrict to the source addresses for all of the Tomcat administrators. Narrow access as much as possible. If the site administrators have static IP addresses, then use that address list. If DHCP is in use, then find out what subnets the administrators' addresses will be allocated from and use those subnets. In the worse case, you can set the list to all of your company or ISP, which will still exclude most of the hacker population of the world.

    It could well be, however, that you can't narrow the source IPs any more than is already restricted by existing firewalls at your company. If so, just skip this step.