How To Improve Tomcat Security

 

Are you finding yourself tossing and turning in bed, mumbling about security audits and directory traversal?  Is your information security officer the monster that chases you in your dreams?  Good news - it's time to stop losing sleep over the security of your Tomcat installation.  

 

This article will help you get a grip on Tomcat security, from the big picture, to specific hardening guidelines you can implement right away to make your server as secure as possible.  We'll also take a look at how you can use Tcat Server Profiles to make implementing best security practices across large architectures a dream rather than a nightmare.  

 

 

Before we even start discussing the security of your Tomcat, let's establish one thing - Tomcat has an unimpeachable track record for security.  According to the Apache, there has never been a documented breach of Tomcat security that resulted in any damage or data loss.  The open source development community behind Tomcat finds (and patches) vulnerabilities all the time, but if any of these has ever been successfully exploited in a way that caused damage to the target, no one knows about it but the involved parties.

 

So out-of-the-box Apache Tomcat is theoretically secure enough for most production uses, with a great track record to back it up.  This is great news for administrators, but just because you have a great baseline doesn't mean you can sit back and relax just yet.  It just means you have more time to focus on improving your own server's security in the areas where you can have the most impact.  

 

There are four areas where good administrative decisions really have a positive impact on Tomcat's security: following best hardening practices, creating good logging systems, auditing your web application code, and lastly, making these processes as efficient as possible (also known as "preserving your sanity").

 

We'll go over each of these areas in just a bit, but since we'll be counting on them to give us a solid base to build upon, let's stop and take some time to admire the security considerations built into Tomcat out of the box and learn a little about how they work.

 

As Tomcat is an implementation of the Servlet specification, the security design for a given version of Tomcat corresponds to its implemented version of the Java Servlet Specification. For Tomcat 6.x, this is Servlet 2.5, while Tomcat 7 will implement Servlet 3.0.  The requirements and practices found in these Servlet Specifications are in turn based on corresponding Java EE security specifications.

 

All of these technologies use a container-based security model - that is, they all use an architecture consisting of combinations of components deployed to containers, and security is provided on a container-by-container basis.

  

The meaning of "security" can vary from technology to technology.  For implementations of the Java Servlet specification, the overall "security" of an implementation is split into four components, which must all be fully implemented in order for the system to be considered secure.  These components are authentication, access control, integrity, and confidentiality.  Here's how these factors are defined in the Servlet Specification, simplified for this brief overview:

 

Authentication - Any communicating entities must both be able to prove that they are, in fact, the entity they claim to be, and that they are acting on the behalf of other authorized, authenticated entities.

 

Access Control - There must be a way to limit specific interactions with a given resource to specified collections of users or programs.

 

Data Integrity - It must be possible to prove that no third party has modified information being transmitted between two entities during transit.

 

Confidentiality - There must be a way to limit access to a specific piece of information in such a way that only authorized users have access to it.

 

Tomcat ensures that these factors are all covered by using both declarative and programmatic types of security statements.  

 

Declarative security refers to options configured in Catalina's XML configuration files that apply to applications running within a particular Tomcat instance, without requiring any changes to the application itself.  

 

Programmatic security, on the other hand, is configured on a per-application basis using a web.xml file located in the application's "WEB-INF" directory.  These files use hierarchical arrangements of XML elements such as Roles, Security Restraints, URL patterns, and HTTP methods to precisely describe the way in which Tomcat's security is implemented.  Extensive documentation of Tomcat's security implementation is available on the Apache Tomcat project site, accessible here.

 

Properly configuring your web application security settings is vital to making your Tomcat secure, as is making sure that your application code itself does not contribute any additional security risks.  

 

The kinds of security risks you'll have to take into account obviously vary based on the kinds of services you need to expose and the types of application you run.  However, there are a number of best practices that should be followed during the initial configuration of any Tomcat server.  In the next section, we'll take a look at some of these practices, as well as the easiest way to implement them across your entire architecture. 

 

 

Apache Tomcat is a very popular application server; over 60% of all Java-based sites use Tomcat.  In fact, it is so widely used that the Center for Internet Security, an non-profit organization that releases definitive security recommendations for popular software, released a Tomcat security benchmark in 2009.  Tomcat is the first web application server to have its own CIS benchmark.  

 

This document, which you can download from CISecurity.org, should be your first stop on the path to security.  The benchmark is 56 pages long, and there's no filler - just clear, precise, effective directions for hardening your Tomcat server, from big things like proxying and effective use of Tomcat's SecurityManager, to the little things, like getting rid of example applications.  When you're through, the only thing you'll be able to do to make your server any more secure is unplug it and lock it in your basement.

 

 

Let's try an exercise: Go ahead and try implementing the first 15 recommendations provided by CIS.  Now take a quick glance at the rest of them.  What should be becoming clear is that you're going to be editing a lot of XML files by hand.  If you're running more than one Tomcat server, multiply that number.

 

Don't panic!  This is one case where you can actually have your cake and eat it, too.  MuleSoft's Tcat Server allows you to quickly edit Tomcat XML files and create server profiles that can be applied them to as many servers as you want with one click, all through a stable, intuitive web interface.  Tcat Server even includes a reliable restart function that you can activate right from the web console, so applying changes to your server is a breeze.  

 

If you're looking for Enterprise Tomcat security that you can rely upon, your search is over.  Download Tcat Server today, and see the difference for yourself - it's the best practice that helps you follow best practices without sacrificing your sanity.