Securing Tomcats Default Configuration

Securing Tomcat’s Default Configuration

In this section, you’ll tighten up the default installation by editing the configuration files and managing the Web applications that come with Tomcat. This will remove some of the most vulnerable entry points for attacks against the server.

As detailed earlier, the admin application and user databases are the main causes of concern. If you don’t use either of these, then you may keep and use the manager application, if you have considered the previous options. Without access to the manager password or write access to server.xml, a hacker can’t access the manager application.

If you don’t take these steps, it’s safer to place the manager folder and its contents outside of Tomcat’s directory structure (you should consider doing this anyway). This means an intruder can’t enable it by just adding an entry to tomcat-users.xml. However, it’s still possible to enable the application by modifying the server.xml file and modifying the manager context’s docBase attribute. As long as the manager folder is on the same machine as the server installation, it’s possible to set up the manager again (though it’s more difficult if you have appropriate permissions set).

You should always remove the example Web applications (jsp-examples and servlets-examples) on a development server. They aren’t necessary for Tomcat to run and take up disk space if nothing else. Likewise, unless you’re using WebDAV, you should remove the webdav Web application.

The Tomcat documentation is now provided as a Web application named tomcat-docs, which is an entirely static Web application with no JSP pages or servlets. Whether you leave this in place is up to you, as it may be useful for developers to have a local copy of the documentation, whether to save network traffic or in case of problems connecting to the outside world.

It may also be worth disabling the default ROOT Web application if you don’t have one of your own. If your applications will be accessed by a Web application context name, then it may be worth replacing the contents of the ROOT folder with an empty index.html file. You can then supply an empty Web application that would show access restriction error messages to clients who attempt to access the directory.

Alternatively, you can also disable unauthorized access to the Web application. Thus, it’s possible to restrict access to the ROOT application to internal clients, such as the developer group, using valves or filters.