Cyber Security

Apache Tomcat Hardening & Security Guidelines

Sharing is caring!

Hackerbulletin has prepared the most relevant settings into this checklist. While there is a significant amount of controls that can be applied, this document is supposed to provide guidelines of hardening measures.

Least Privilege for the Tomcat Service

Run the Tomcat application server with low privileges on the system. Create a dedicated service user for Tomcat that only has a minimum set of privileges (e.g. remote login with the user must not be allowed).Installations using operating system repositories must be reviewed for the use of a low-privilege user in order to ensure that Tomcat doesn’t run as root/administrative user. Using a less privileged user to run Tomcat might impact the use of certain features Tomcat provides. This can be mitigated by using a local HTTP proxy on the system (e.g. Apache with m od_jk ) or packet forwarding rules that forward incoming traffic to the unprivileged port Tomcat is configured to listen on.

Restrict Access to Tomcat Folder

The Tomcat folders should only be accessible by the tomcat user itself. This is especially valid for the directories ${tomcat_home}/conf/ and ${tomcat_home}/webapps .

When auto-deployment via the application server is not needed, the standard configuration is to have all Tomcat files owned by root with the group set to Tomcat. Then use chmod 740 to only let root edit the files and make them available to read for the Tomcat user. Exceptions are, temporary and work directories that are owned by the Tomcat user rather than root.

Implement Network Level Restrictions
The main administrative interface of Tomcat is the so-called Manager application.If the manager application is used, the administrative interface should only be accessible from authorized IP addresses. This can be accomplished by setting the following configuration options in the file CATALINA_HOME/webapps/manager/META-INF/context.xml inside the Context option.

Implement Secure Authentication

If the Manager application is used, additional authentication mechanisms should be implemented. The authentication mechanisms are prioritized in the following order:
1. LDAPS or client certificates
2. Local (digest based)

Additionally, the authentication procedure and the communication with the manager application must be secured with SSL. For local and certificate based authentication, an account lockout must be enforced. To prevent brute force attacks, the authentication realm in use must be placed within a lockout realm using the following configuration:
Edit the file CATALINA_HOME/conf/server.xml and add the lockout realm with the following option:

There are multiple realms that are not intended for productive use. These realms must be disabled. Open the file CATALINA_HOME/conf/server.xml. Search for the MemoryRealm and disable it. The JDBCRealm must also be disabled. Use the DataSourceRealm instead. When using a large-scale installation, do not use the UserDatabaseRealm and disable it as well.


Implement HttpOnly Flag

Review the configuration to ensure that HttpOnly is enabled.
HttpOnly can be activated with the following configuration option that must be set in CATALINA_BASE/conf/context.xml to be enabled globally on all applications:

Using HttpOnly may break application functionality if access to the session cookies via JavaScript is necessary. If an application needs access to HttpOnly cookies via JavaScript, an exception can be defined in the individual context inside the application files in /METAINF/context.xml.

Implement Session Timeout For Web Application

The session timeout for all web applications must be set to specific time e.g. 30 minutes .

This can be done by editing the file in the CATALINA_HOME/conf/web.xml and setting the following configuration option: 20

Restrict Listening Interfaces

Prevent the connectors from listening on all interfaces/IP addresses available on the server system. Instead, the IP address must be specified.
Edit the file CATALINA_HOME/conf/server.xml. Review every connector and specify the correct IP address:

This prevents applications from accidently being served on an exposed interface

Restrict Allowed Network Connections Only necessary Tomcat ports should open. These default to TCP port 8080 and 8443 . Make sure that these ports are correctly configured in Tomcat and on an existing packet filter that can be installed on the system.
Open the file CATALINA_HOME/conf/server.xml and review every Connector configuration for the correct/desired port assignment. Remove unused ports/connectors.

Encrypt Network Connections

To secure sensitive applications (such as the Manager application), the usage of SSL must be configured (and it is also mandatory for hosted applications that process sensitive data/provide log-in functionality). The first step is the creation of a trustworthy certificate to avoid certificate warning messages, and to offer the end user a way to verify a trustworthy connection.

The second step is the creation of a certificate keystore, containing CA and server certificate and the corresponding private key. The password for the keystore should be created according to the recommendations from the “Ensure password security” subsection above.

The enforcement of SSL only communication must be done in one of the following 2 ways: To force the usage of HTTPS for all Web Applications hosted on the Tomcat, each securityconstraint tag within each CATALINA_HOME/webapps/$WEBAPP/WEB – INF/web.xml must include the following lines right before the closing tag.


Starting Tomcat with a Security Manager

In order to restrict the capabilities of single applications, the Java Security Manager can be used. The security policies implemented by the Java SecurityManager are configured in the file $CATALINA_HOME/conf/catalina.policy. Once the catalina.policy file is configured, Tomcat can be started with a SecurityManager in place by using the –security option.

As basically all kinds of permissions (e.g. access to single files and directories or Java packages) should be configured per application, this control significantly increases operational effort.

Secure Shutdown Port

If the functionality to shut down Tomcat using a network port on the local Tomcat system down is needed, the password must be set to a strong and hard to guess passphrase.
Edit the file CATALINA_HOME/conf/server.xml and set the shutdown passphrase:

If this functionality is not needed, it must be deactivated with the following option

The local management scripts allow a shutdown of the server even if the shutdown port is disabled.

Remove default/unwanted applications

Tomcat comes with a number of default web applications. These must be removed if not absolutely needed. Remove all default web applications from ${tomcat_home}/webapps. Standard applications which must be removed are ROOT , docs , examples , host – manager , and manager .

The manager application provides administrative functionality such as deploying apps and retrieving log information. This should and can be performed using the local server command line interface. However, if this application is absolutely needed, it must be secured using SSL.

Custom Error Pages

As the standard error pages disclose internal information (such as version number and stack traces), they should be replaced by custom error pages using a generic error message like “ An error occurred while processing your request ”.

The following lines must be included in the web.xml of each web application, located in CATALINA_HOME/webapps/$WEB_APP/WEB-INF:500 /errorpages/error.html java.lang.Throwable /errorpages/error.html

In addition, if the manager application has not been removed, the “Tomcat 7” version information must be manually removed from the error pages located in the CATALINA_HOME/webapps/manager/WEB-INF/jsp/.

Disable Automatic Deployment

Tomcat allows automatic deployment of applications while Tomcat is running. This functionality must be disabled as it may allow malicious or untested applications to be deployed.
Automatic deployment is controlled by the autoDeploy and deployOnStartup attributes. If both are false , only Contexts defined in server.xml will be deployed and any changes will require a Tomcat restart.

To disable automatic deployment change the following lines in the $CATALINA_HOME/conf/server.xml file:
autoDeploy=”false” deployOnStartup=”false”.

In a hosted environment where web applications may not be trusted, also set the deployXML attribute to false to ignore any context.xml packaged with the web application that may try to assign increased privileges to the web application.

Patch and Vulnerability Management

Security-relevant Tomcat updates must be installed in a timely manner:
¬ Critical or Important priority updates and patches must be applied within 10 days.
¬ Moderate priority updates and patches are to be deployed within maximum of 30 days after release.
¬ Low priority updates are to be applied after maximum of 90 days after release.

Join The Discussion