Examining General Tomcat Security Principles

Now that you’ve secured your file system against attack, you should consider a few other security issues before tackling Tomcat’s configuration files. All but one of these applies to Windows and Unix.

Retaining Tomcat’s Administration Tools

Because tomcat-users.xml stores your username and password for Tomcat’s management applications, you may want to switch to a different realm, as discussed in could stop or reload your Web applications on demand. Thus, if you use the Tomcat realms that use tomcat-users.xml, you should consider removing the admin and manager Web applications.

If you use the admin application to change server.xml or users in tomcat-users.xml, then you must have write access to the directory. This also means a hacker can write to this directory and carry out any of the commands that the admin tool can and so may be able to add context XML files for malicious code. This also applies to user databases because they need write access to tomcat-users.xml.

If this bothers you, remove the admin tool, should it be installed, and use a JDBC or JNDI realm (or even the memory realm if you want; it doesn’t require write access to any files).

Read-Only webapps Directory

You’ll note that you’ve set read-only permissions on the webapps directory. This is to prevent hackers from modifying your Web applications. This also means, however, that you may not be able to use WAR files when running Tomcat with the tomcat account, since Tomcat won’t be able to expand the WAR into the file system. Thus, you’ll need to unzip the WAR file yourself when you deploy it, run Tomcat as root from the console when you deploy new WAR files for the first time, or set the containing host’s unpackWARs attribute to false.

This also means that Web applications can’t write to their directories. This is recommended in the Servlet specification because it’s assumed that some servlet containers will run unexpanded WAR files and would thus not be able to write changes to the Web application’s file system (it doesn’t have one). This is the case if unpackWARs is set to false.

Securing Your Files

You should review your operating system for any additional files stored on the server that should be secured. You should consider either moving these files to another server or ensuring that the tomcat account doesn’t have any permissions for them. On Windows, add the tomcat user to the Security tab for the file or directory and explicitly click the Deny checkboxes. In Unix, set the permissions for others to nothing (-rwx).

Knowing If You’ve Been Violated

Despite your best efforts, it’s possible that a hacker may exploit Tomcat (or another service) and modify your file system in some unimagined way. Intrusion detection systems can help you detect when your file system has been tampered with. Tripwire is one of these programs, and Red Hat includes instructions for installing and configuring Tripwire in its Official Red Hat Linux Reference Guide.

If you’re not using Red Hat Linux, see http://www.tripwire.com for more information.

Read-Only File Systems

Some operating systems support read-only file systems. In this concept, available only to Unix-like operating systems, you configure two separate file systems. The first file system, a root file system, contains your operating system configured just the way you need it, with a Tomcat daemon. You then make this file system read-only (or for ultimate security, transfer it to a read-only medium, such as a CD or a hard drive that you can make read-only). The second file system is contained on a read-write medium and contains your Tomcat installation and other files that must be modified.

Should you want to take this (highly secure) step, you’ll need to find documentation for your specific operating system. No standard Unix way exists to achieve this functionality. You must exercise caution if you attempt this route; once you mark your root file system as read-only, you’ll need a boot disk to make any changes.