1 the introduction

Since there are no official hardening guidelines for Tomcat 7, ERNW summarized the Settings and made the list in this article. Although there are a number of Settings that can be applied, this article aims to provide a basis for some hardening methods. Settings that may have a significant impact on operating system functionality and require extensive further testing are not listed in this list or are marked as optional.

We’ve marked each of the recommended Settings in this list with “mandatory” or “optional” to clearly indicate which Settings are required (mandatory) or should (optional) from our perspective. “Optional” also means that we recommend that you apply this setting, but it may interfere with essential functionality of the system.

2 Operation and System security

2.1 Patch and Vulnerability Management

Security related Tomcat updates must be installed in a timely manner:

Updates and patches for high-risk or critical priorities must be installed within 10 days.

Medium priority updates and fixes must be installed within 30 days of release.

Low-priority updates must be installed within 90 days of release.

Availability and severity of information about the patch, please see the tomcat.apache.org/lists.html#…

Updates may affect functionality. Tomcat on core/business update may lead to side effects, please see tomcat.apache.org/lists.html#…

2.2 Minimum Tomcat Service Rights

Run the Tomcat application with low privileges on your system. Create a dedicated Tomcat service user that has only a minimal set of privileges (such as no remote login). The use of the operating system repository installer as the least privileged user must be checked to ensure that Tomcat is not running as root/administrator. This must be ensured at the operating system level where the startup mechanism is configured (such as Windows services on Microsoft Windows or RC scripts on Unix) :

Figure 1: Windows service configuration

For details about secure service configurations, see ERNW Windows Hardening Guide

Figure 2: FreeBSD RC script

The specific configuration depends on the Unix system and Tomcat version. For example, Tomcat 7 on FreeBSD no longer supports configuring user accounts in rc.conf, so the user name is hard-coded in the startup script – which is not recommended. On FreeBSD, web and application server running should be based on WWW user identity, may refer to www.freebsd.org/doc/en/book…

Running Tomcat as a low-privileged user may affect some of Tomcat’s functions. For example, a privileged port cannot be set as a listening port. To solve this problem, you can either use a local HTTP proxy on your system (for example, using Apache’s mod_JK module) or define packet forwarding rules so that incoming traffic is forwarded to a non-privileged port that Tomcat listens on.

2.3 Restrict access to the Tomcat folder

The Tomcat folder can be accessed only by Tomcat users, especially tomcathOME /conf/ and {tomcat_HOME}/conf/and tomcathOME /conf/ and {tomcat_HOME}/webapps.

When automatic deployment through the application server is not required, the standard configuration is to set the owner of all Tomcat files to root and the group to which they belong to to Tomcat. Then chmod 740 allows only root users to edit the files and Tomcat users to read the files. The exception is that temporary and working directories should be owned by the Tomcat user rather than root.

This setting affects automatic deployment. (See section 8.5)

3 Management Interface

Tomcat’s main administrative interface is called the Manager application. Although securing the application is critical to the security of the Tomcat server, the application was found to be very exposed in many environments (for example, no network level restrictions were deployed and weak/default login information was used). If possible, administrative tasks should be performed at the operating system level (for example, using RDP or SSH), and Manager applications should be avoided (see also section 8.3). If this is not possible, the Settings described in the following section (and perhaps consider jumpers) should be used in conjunction with a secure authentication mechanism (see also section 4) and encrypted transport (see section 6.3).

3.1 Network Layer Restrictions

If you want to use a Manager application, you should only allow access to its administrative interface from authorized IP addresses.

This can be achieved by the CATALINA_HOME/webapps/manager/meta-inf/context. Do the following Settings in the XML file. The following Settings allow only local hosts and specific IP addresses or IP address segments to access the management interface:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" Allow = "127 \ \. \ \ d + \ \ \ \ d + \ \ \ \ d + | : : 1 | 0:0:0:0:0:0:1-0 | 172 \ \. \ \. 16 16 \ \. \ \ d {1, 3}" / >Copy the code

Host names can also be used:

 <Valve className="org.apache.catalina.valves.RemoteHostValve"
 allow=".*\\.admins\\.domain\\.com" />
Copy the code

Allow and deny support regular expressions (using java.util.regex)

3.2 Minimum Authorization

Based on a given task, only roles can be assigned to users. The roles are as follows, and remember to give only the minimum permissions:

Manager-gui: Access the Web interface

Manager-status: You can access only the Server Status page

Manager-script: you can script the text page and Server Status page

Manager-jmx: access the JMX agent page and Server Status page

4 the certification

The following Settings generally apply to Tomcat-based authentication. But in most environments, this is primarily for Manager applications, so use it as an example. If the deployed application uses Tomcat-based authentication, these Settings apply to that application as well.

4.1 Security Authentication

If the Manager application is to be used, additional authentication mechanisms should also be attached. The authentication mechanism has the following priorities:

1 LDAPS or client certificate

2 Local (based on message digest)

In addition, the authentication process and communication with the Manager application must be secured using SSL (see below).

Account locking must be deployed for local and certificate-based authentication (directory services must also be configured for centralized authentication). To prevent brute force cracking, the authentication domain must be in the locked domain configured as follows:

Edit the CATALINA_HOME/conf/server. XML file and add the lock domain configured as follows:

<Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="5" lockOutTime="30"> <! \-\- AUTHENTICATION REALM --> </Realm>Copy the code
4.2 disable domain

Several domains are not suitable for production use and must be disabled.

Open the file CATALINA_HOME/conf/server. XML, search for MemoryRealm and disable it. JDBCRealm must also be disabled in favor of DataSourceRealm. When using large-scale installations, do not use UserDatabaseRealm and disable it as well.

5 Session Processing

5.1 Session Timeout

Session timeout must be set to 20 minutes for all Web applications.

You can edit the CATALINA_HOME/conf/web. XML file and perform the following configuration:

<session-config>

   <session-timeout>20</session-timeout>

 </session-config>
Copy the code
5.2 HttpOnly flag

Tomcat 7 automatically enables the HttpOnly cookie flag for session cookies. Check the configuration to ensure that this option is disabled.

To enable HttpOnly, you must do the following in CATALINA_BASE/conf/context.xml to apply it globally to all applications:

<Context useHttpOnly=’true’ … />

In cases where session cookies need to be accessed through JavaScript, using HttpOnly may affect application functionality. If your application needs to access HttpOnly cookies through JavaScript, you can define an exception in a separate context in METAINF/context.xml.

5.3 CSRF protection

To protect your application, Tomcat’s cross-site request forgery protection must be enabled. Tomcat 7 provides basic CSRF protection. You can configure a global filter in CATALINA_BASE/conf/web.xml. This filter can be overridden by every application that uses the WEB-INF/web.xml file.

The following Settings must be made:

<filter-mapping>
   <filter-name>CSRFPreventionFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
Copy the code

For detailed instructions and other options, see the Tomcat manual: tomcat.apache.org/tomcat-7.0-…

The use of CSRF protection may affect application functionality, and this must be kept in mind, especially if the application makes heavy use of asynchronous requests.

6 Network Security

6.1 Limiting Listening on Network Interfaces

Instead of having the connector listen for all available network interfaces and IP addresses on the server, have the connector listen for specified network interfaces and IP addresses.

Edit CATALINA_HOME/conf/server. XML to view each Connector and specify the correct IP address:

< Connector port = "TCP \ _PORT" address = "LISTEN \ _IP_ADDRESS"...Copy the code

This prevents the application from accidentally running on an open network interface.

6.2 Limit the allowed network connections

Only required Tomcat ports are open. The default TCP ports are 8080 and 8443. Make sure these ports are configured correctly in Tomcat and existing packet filters that can be installed on your system.

Open the CATALINA_HOME/conf/server. XML file to view the port configuration of each Connector. Remove unwanted ends and connectors.

6.3 Encrypting Network Connections

To protect sensitive applications, such as Manager applications, SSL must be used and configured (also necessary for applications that process sensitive data or provide login capabilities). The first step is to create a trusted certificate to avoid certificate warnings and to provide end users with a way to validate trusted connections.

The second step is to create a certificate keystore that contains the CA, server certificate, and corresponding private key. The password for the keystore should be created as recommended in the previous section “Securing passwords.”

To enable SSL support, you can use the following configuration (the actual configuration depends on the given platform and requirements) and must be in CATALINA_HOME/conf/server.xml:

<Connector protocol="org.apache.coyote.http11.Http11Protocol" port="8443" scheme="https" secure="true" SSLEnabled="true"  sslProtocol="TLS" keystoreFile="path to keystore file" keystorePass="keystore password"/>Copy the code

Specify the SSL encryption modes available by adding the following cipher Suite to the SSL Connector:

<Connector ciphers="SSL\_RSA\_WITH\_RC4\_128\_SHA, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_DHE\_DSS\_WITH\_AES\_128\_CBC\_SHA, SSL\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA, SSL \ _DHE \ _RSA \ _WITH \ _3DES \ _EDE \ _CBC \ _SHA, SSL \ _DHE \ _DSS \ _WITH \ _3DES \ _EDE \ _CBC_SHA "...Copy the code

To force HTTPS for all Web applications hosted on Tomcat, You must include the following before closing each security-constraint tag in each CATALINA_HOME/webapps/$WEBAPP/ web-INF /web. XML file:

 <user-data-constraint>

      <transport-guarantee>CONFIDENTIAL</transport-guarantee>

 <user-data-constraint>
Copy the code

7 Java Runtime

7.1 Java SecurityManager

The Java SecurityManager can limit the functionality of a single application. $the CATALINA_HOME/conf/catalina. The policy file contains the Java SecurityManager use security policy configuration. Once the Catalina.policy file is configured, Tomcat can be started using the SecurityManager and — Security options. For a complete configuration introduction, see the official Tomcat SecurityManager tutorial: tomcat.apache.org/tomcat-7.0-…

Because basically all permission types (such as access to individual files and directories or Java packages) should be configured individually for each application, this can add significantly to the cost of operation. In addition, overly restrictive policy files can affect application functionality.

7.2 Accessing the Java Package

Tomcat can restrict access to certain Java packages. If restricted package access is detected, a security exception is thrown.

Open access restrictions for the Java package, $CATALINA_BASE/conf/catalina. The properties file and add is not allowed to access the bag to package. The access list.

Analyzing Java imports can list which packages are required by which applications. On Unix systems, you can use the following example:

Grep – R import ${tomcat_home} / webapps/WEBAPP

8 General Settings

8.1 Secure the default Settings

Check a few defaults for potential vulnerabilities. Refer to section 9 for the default configurations that cannot be changed.

8.2 Securing the Shutdown Port

If you must enable shutting down Tomcat using a network port on your local Tomcat system, you must use a strong password that is hard to guess.

Edit the CATALINA_HOME/conf/server. XML file and set the closing password.

If this function is not needed, it must be disabled as follows:

Local admin scripts can shut down the server even if the close port is disabled.

8.3 Removing a Default Application

Tomcat may come with some default Web applications. If not necessary, they must be removed.

Remove all default Web applications in ${tomcat_HOME}/webapps. The applications that must be removed are ROOT, Documentation, Examples, Host Manager, and Manager.

The Manager application provides administrative capabilities, such as deploying the application and retrieving log information. These functions should be run using the command line on the local server. However, if the application is absolutely necessary, it must be secured with SSL.

8.4 Customizing error Pages

Because the default error page gives away some internal information (such as the version number and stack trace), you should replace it with a custom error page that contains generic error information (such as an error while processing your request).

Each Web application should contain the following configuration in its web. XML file, which is located in CATALINA_HOME/webapps/$WEB_APP/WEB-INF:

 <error-page>

   <error-code>500</error-code>

   <location>/errorpages/error.html</location>

 </error-page>
 
 <error-page>

   <exception-type>java.lang.Throwable</exception-type> <location>/errorpages/error.html</location>

 </error-page>
Copy the code

In addition, if the Manager application is not removed, you must manually remove the “Tomcat 7” version information from the error page in CATALINA_HOME/webapps/ Manager /WEB-INF/ JSP /.

8.5 Disabling Automatic Deployment

Tomcat allows automatic deployment of applications while Tomcat is running. This feature must be disabled because it may allow malicious or untested applications to be deployed.

Automatic deployment is controlled by the autoDeploy and deployOnStartup properties. If both are false, only the Context defined in server.xml will be deployed, and any changes will require Tomcat to restart. To disable automatic deployment, do the following in the $CATALINA_HOME/conf/server.xml file:

AutoDeploy = "false" deployOnStartup = "false"Copy the code

Web applications may not be trusted in a hosted environment, and you can also set the deployXML attribute to false to ignore context.xml to avoid giving the Web application additional permissions.

9 Appendix: Default Settings

The following is a list of default Settings that cannot be changed and are considered secure by default:

  • The allowTrace value for each Connector in server.xml is either null or set to false.

  • In all context.xml files, set the privileged property to false, except when permissions are required as in the Manager application:

<Context ... Ring = "false" / >Copy the code
  • Make sure the crossContext value is null or set to false. A crossContext value of true may result in malicious applications being allowed to send requests to restricted applications.
<Context ... CrossContext = "false" / >Copy the code

  • Make sure allowLinking is empty or set to false. A allowLinking value of true may lead to directory traversal and source code disclosure vulnerabilities.

<Context... AllowLinking = "false" / >Copy the code

  • Disables writing to the default servlet.

Set DefaultServlet to true in the web. XML file. If the value is false, clients will be allowed to delete or modify static resources on the server and upload new resources. This value should generally not be changed without authentication.

  • Disabling the display list

Set the listings for DefaultServlet to false. This is not only because allowing directory lists to be displayed is considered unsafe, but also because generating directory lists with thousands of files consumes a lot of CPU resources, equivalent to being attacked by a DDoS.

  • When RECYCLE_FACADES is set to true, Tomcat recycles the session facade between requests. This causes information to leak between requests. By default, this parameter is not set. Make sure the startup script you use does not contain the following:

-Dorg.apache.catalina.connector.RECYCLE_FACADES = false

  • Allowing different path separators to be specified on Tomcat may allow an attacker to access an application that would otherwise be blocked by a proxy such as mod_proxy. By default, this parameter is not set.

Make sure the startup script you are using does not contain the following:

-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH = FALSE

-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = FALSE

  • Allows you to specify custom header status messages, enabling an attacker to insert headers as well. This can lead to XSS vulnerabilities. By default, this parameter is not set.

Make sure the startup script you use does not contain the following:

-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = false

-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = FALSE

  • Allows header status messages to be customized, enabling an attacker to insert headers as well. This can lead to XSS vulnerabilities. By default, this parameter is not set.

Ensure that the startup script used does not contain the following:

-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = false