Apache Tomcat 9 STIG
Apache Tomcat 9 Security Technical Implementation Guide. Version v1 r0.1, released Feb. 6, 2020.
TCAT-AS-001300: Idle timeout for management application must be set to 10 minutes.
If manager and host-manager applications have been deleted from the system, this is not a finding. From the Tomcat server as a privileged user, run the following commands: sudo grep -i session-timeout $CATALINA_HOME/webapps/manager/META-INF/web.xml sudo grep -i session-timeout $CATALINA_HOME/conf/web.xml If the session-timeout setting is not configured to be 10 minutes in at least one of these files, this is a finding.
Discussion
Tomcat can set idle session timeouts on a per-application basis. The management application is provided with the Tomcat installation and is used to manage the applications that are installed on the Tomcat Server. Setting the idle timeout for the management application will kill the admin user's session after 10 minutes of inactivity. This will limit the opportunity for unauthorized persons to hijack the admin session. This setting will also affect the default timeout behavior of all hosted web applications. To adjust the individual hosted application settings that are not related to management of the system, modify the individual application web.xml file if application timeout requirements differ from the STIG.
Fix
If the manager and host-manager applications have been deleted from the system, this is not a finding. From the Tomcat server as a privileged user: To affect session timeout for all applications including the management application, edit the $CATALINA_HOME/conf/web.xml file. To affect session timeout for the management application only, edit the $CATALINA_HOME/webapps/manager/META-INF/web.xml file. Locate the session-timeout setting located within the session-config element. Modify the session-timeout setting to be 10 minutes. Save the file. sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000920: ErrorReportValve showServerInfo must be set to false.
As an elevated user on the Tomcat server run the following command: sudo grep -i ErrorReportValve $CATALINA_HOME\conf\server.xml file. If the ErrorReportValve element is not defined and showServerInfo set to "false", this is a finding. EXAMPLE: <Host ...> ... <Valve className="org.apache.catalina.valves.ErrorReportValve" showServerInfo="false"/> ... </Host>
Discussion
The Error Report Valve is a simple error handler for HTTP status codes that will generate and return HTML error pages. It can also be configured to return pre-defined static HTML pages for specific status codes and/or exception types. Disabling showServerInfo will only return the HTTP status code and remove all CSS from the default non-error related HTTP responses.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create or modify an ErrorReportValve <Valve> element nested beneath each <Host> element. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.ErrorReportValve" showServerInfo="false" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001550: Tomcat server must be patched for security vulnerabilities.
Refer to https://tomcat.apache.org/security-9.html and identify the latest secure version of Tomcat with no known vulnerabilities. As a privileged user from the Tomcat server, run the following command: sudo $CATALINA_HOME/bin/version.sh |grep -i server Compare the version running on the system to the latest secure version of Tomcat. If the latest secure version of Tomcat is not installed, this is a finding.
Discussion
Tomcat is constantly being updated to address newly discovered security vulnerabilities. If the Tomcat server is not updated to address these risks, the server could be compromised or a new DoS attack could be successful.
Fix
Follow operational procedures for upgrading Tomcat. Download latest version of Tomcat and install in a test environment. Test applications that are running in production and follow all operations best practices when upgrading the production Tomcat application servers. Update the Tomcat production instance accordingly and ensure corrected builds are installed once tested and verified.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000260: HTTP status code must be logged.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review all <Valve> elements. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> If the pattern= statement does notinclude %s, this is a finding.
Discussion
The access logfile format is defined within a Valve that implements the org.apache.catalina.valves.AccessLogValve interface within the /opt/tomcat/server.xml configuration file: The %s pattern code is included in the pattern element and logs the server response code associated with the event e.g. 200 OK or 400 Bad Request. Including the status pattern in the log configuration provides useful server response information about the event which is critical for troubleshooting and forensic investigations.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Modify the <Valve> element(s) nested within the <Host> element(s). Change the AccessLogValve setting to include %s in the pattern= statement. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001670: RECYCLE_FACADES must be set to true.
From the Tomcat server as a privileged user, run the following command: sudo grep -i recycle_facades /etc/systemd/system/tomcat.service If there are no results, or if the org.apache.catalina.connector. RECYCLE_FACADES is not configured to load at startup, this is a finding.
Discussion
If RECYCLE_FACADES is true or if a security manager is in use, a new facade object will be created for each request. This reduces the chances that a bug in an application might expose data from one request to another. This setting is configured using environment variable settings. For Linux OS flavors other than Ubuntu, use the relevant OS commands. For Ubuntu, this setting can be managed in the /etc/systemd/system/tomcat.service file via the CATALINA_OPTS variable. This setting is defined in the file and referenced during Tomcat startup in order to load Tomcat environment variables. Technically, the tomcat.service referenced in the check and fix could be called a different name, for STIG purposes and to provide a standard setting that can be referred to and obviously is used for Tomcat, tomcat.service was chosen.
Fix
From the Tomcat server as a privileged user: Edit the /etc/systemd/system/tomcat.service file and either add or edit the org.apache.catalina.connector. RECYCLE_FACADES setting. Set the org.apache.catalina.connector. RECYCLE_FACADES=true EXAMPLE: Environment='CATALINA_OPTS -Dorg.apache.catalina.connector. RECYCLE_FACADES=true' Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001330: Multi factor certificate-based tokens (CAC) must be used when accessing the management interface.
If the manager application has been deleted from the Tomcat server, this is not a finding. From the Tomcat server as a privileged user, issue the following command: sudo grep -i auth-method $CATALINA_HOME/webapps/manager/WEB-INF/web.xml If the <Auth-Method> for the web manager application is not set to CLIENT-CERT, this is a finding.
Discussion
Password authentication does not provide sufficient security control when accessing a management interface. DoD has specified that the CAC will be used when authenticating and passwords will only be used when CAC authentication is not a plausible solution. Tomcat provides the ability to do certificate-based authentication and client authentication, therefore the Tomcat server must be configured to use CAC.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/webapps/manager/WEB-INF/web.xml file and modify the auth-method for the manager application security constraint. sudo nano $CATALINA_HOME/webapps/manager/WEB-INF/web.xml Locate <auth-method> contained within the <login-config> section, modify <auth-method> to specify CLIENT-CERT. EXAMPLE: <auth-method>CLIENT-CERT</auth-method> In addition, the connector used for accessing the manager application must be configured to require client authentication by setting clientAuth="true" and the manager application roles must be configured in the LDAP server. Restart the Tomcat server: sudo systemctl restart tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001610: AccessLogValve must be configured per each virtual host.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple virtual hosts on one physical server by using the container attribute. This allows the admin to separate hosted applications according to where the domain the application will be available. Configuring logs on a per-host basis allows for log management that correlates to the virtual host activity. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001240: Files in the $CATALINA_HOME/conf/ folder must have their permissions set to 640.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/conf/* -follow -maxdepth 0 -type f \( \! -perm 640 \) -ls If no files are displayed, this is not a finding. If results indicate any of the file permissions contained in the $CATALINA_HOME/conf folder are not set to 640, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/conf/* -follow -maxdepth 0 -type f -print0 | sudo xargs chmod 640 $CATALINA_HOME/conf/*
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001640: Application servers must use NIST-approved or NSA-approved key management technology and processes.
For the systemd Ubuntu OS, check the tomcat.service file to read the content of the JAVA_OPTS environment variable setting. sudo cat /etc/systemd/system/tomcat.service |grep -i truststore EXAMPLE output: set JAVA_OPTS="-Djavax.net.ssl.trustStore=/path/to/truststore" "-Djavax.net.ssl.trustStorePassword=************" If the variable is not set, use the default location command below. If the variable is set, use the alternate location command below and include the path and truststore file. -Default location: keytool -list -cacerts -v | grep -i issuer -Alternate location: keytool -list -keystore <location of trust store file> -v |grep -i issuer If there are no CA certificates issued by a Certificate Authority (CA) that is part of the DoD PKI/PKE, this is a finding.
Discussion
Class 3 PKI certificates are used for servers and software signing rather than for identifying individuals. Class 4 certificates are used for business-to-business transactions. Utilizing unapproved certificates not issued or approved by DoD or CNS creates an integrity risk. The application server must utilize approved DoD or CNS Class 3 or Class 4 certificates for software signing and business-to-business transactions.
Fix
Obtain and install the DoD PKI CA certificate bundles by accessing the DoD PKI office web site at cyber.mil/pki-pke. Import the DoD CA certificates.
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000370: Files in the $CATALINA_HOME/conf/ folder must have their permissions set to 640.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/conf/* -follow -maxdepth 0 -type f \( \! -perm 640 \) -ls If no files are displayed, this is not a finding. If results indicate any of the file permissions contained in the $CATALINA_HOME/conf folder are not set to 640, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user group tomcat rather than root user group tomcat. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 0027 to maintain these permissions.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/conf/* -follow -maxdepth 0 -type f -print0 | sudo xargs chmod 640 $CATALINA_HOME/conf/*
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000060: Default password for keystore must be changed.
From the Tomcat server console, run the following command to check the keystore: sudo keytool -list -v When prompted for the keystore password, type "changeit". If the contents of the keystore are displayed, this is a finding.
Discussion
Tomcat currently operates only on JKS, PKCS11, or PKCS12 format keystores. The JKS format is Java's standard "Java KeyStore" format, and is the format created by the keytool command-line utility which is included in the JDK. The PKCS12 format is an internet standard, and is managed using OpenSSL or Microsoft's Key-Manager. This requirement only applies to JKS keystores. When a new JKS keystore is created, if a password is not specified during creation the default password used by Tomcat is "changeit" (all lower-case). If the default password is not changed, the keystore is at risk of compromise.
Fix
From the Tomcat server as a privileged user, run the following command: sudo keytool -storepasswd When prompted for the keystore password, select a strong password, minimum 10 characters, mixed case alpha-numeric. Document the password and store in a secured location that is only accessible to authorized personnel.
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-000390: $CATALINA_HOME/bin folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/bin folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions. Note that running Tomcat in a Docker environment can impact how file permissions and user ownership settings are applied. Due to associated Docker configuration complexities, the STIG is scoped for standalone rather than virtual Docker deployments.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/bin
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000380: Jar files in the $CATALINA_HOME/bin/ folder must have their permissions set to 640.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/bin/*jar -follow -maxdepth 0 -type f \( \! -perm 640 \) -ls If there are no results, or if .sh extensions are found, this is not a finding. If results indicate any of the jar file permissions contained in the $CATALINA_HOME/bin folder are not set to 640, this is a finding.
Discussion
Tomcat's file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with the group Tomcat. While root has read/write privileges, tomcat group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/bin/*jar -follow -maxdepth 0 -type f -print0 | sudo xargs chmod 640 $CATALINA_HOME/bin/*jar
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001700: Tomcat users in a management role must be approved by the ISSO.
Review the Tomcat servers System Security Plan/server documentation. Ensure that user accounts and roles with access to Tomcat management features such as the "manager-script" role are documented and approved by the ISSO. If the ISSO has not approved of documented roles and users who have management rights to the Tomcat server, this is a finding.
Discussion
Deploying applications to Tomcat requires a Tomcat user account that is in the "manager-script" role. Any user accounts in a Tomcat management role must be approved by the ISSO.
Fix
Document the users and the roles that have been defined for use with the Tomcat server. Ensure that all users and roles with access to Tomcat management features and capabilities are approved by the ISSO.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001380: Multifactor certificate-based tokens (CAC) must be used when accessing the management interface.
If the manager application has been deleted from the Tomcat server, this is not a finding. From the Tomcat server as a privileged user, issue the following command: sudo grep -i auth-method $CATALINA_HOME/webapps/manager/WEB-INF/web.xml If the <Auth-Method> for the web manager application is not set to CLIENT-CERT, this is a finding.
Discussion
Password authentication does not provide sufficient security control when accessing a management interface. DoD has specified that the CAC will be used when authenticating and passwords will only be used when CAC authentication is not a plausible solution. Tomcat provides the ability to do certificate-based authentication and client authentication, therefore the Tomcat server must be configured to use CAC.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/webapps/manager/WEB-INF/web.xml file and modify the auth-method for the manager application security constraint. sudo nano $CATALINA_HOME/webapps/manager/WEB-INF/web.xml Locate <auth-method> contained within the <login-config> section, modify <auth-method> to specify CLIENT-CERT. EXAMPLE: <auth-method>CLIENT-CERT</auth-method> In addition, the connector used for accessing the manager application must be configured to require client authentication by setting clientAuth="true" and the manager application roles must be configured in the LDAP server. Restart the Tomcat server: sudo systemctl restart tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000470: Stack tracing must be disabled.
From the Tomcat server run the following OS command: sudo cat $CATALINA_HOME/conf/server.xml | grep -i connector Review each connector element, ensure each connector does not have an "allowTrace" setting or ensure the "allowTrace" setting is set to false. <Connector ... allowTrace="false" /> Do the same for each application by checking every $CATALINA_HOME/webapps/<APP_NAME>/WEBINF/web.xml file on the system. sudo cat $CATALINA_HOME/webapps/<APP_NAME>/WEBINF/web.xml |grep -i connector If a connector element in the server.xml file or in any of the <APP NAME>/WEBINF/web.xml files contains the "allow Trace = true" statement, this is a finding.
Discussion
Stack tracing provides debugging information from the application call stacks when a runtime error is encountered. If stack tracing is enabled, Tomcat will provide this call stack information to the requestor which could result in the loss of sensitive information or data that could be used to compromise the system.
Fix
From the Tomcat server as a privileged user, edit the xml files containing the "allow Trace=true" statement. Remove the "allow Trace=true" statement from the affected xml configuration files and restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000280: AccessLogValve must be configured for each application context.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding.
Discussion
Tomcat has the ability to host multiple contexts (applications) on one physical server by using the element. This allows the admin to specify audit log settings on a per application basis. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested within the <Host> element. Specify an AccessLogValve setting in the Valve element with the following pattern statement. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000720: Default password for keystore must be changed.
From the Tomcat server console run the following command to check the keystore: sudo keytool -list -v When prompted for the keystore password, type "changeit". If the contents of the keystore are displayed, this is a finding.
Discussion
Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores. The JKS format is Java's standard "Java KeyStore" format, and is the format created by the keytool command-line utility which is included in the JDK. The PKCS12 format is an internet standard, and is managed using OpenSSL or Microsoft's Key-Manager. When a new JKS keystore is created, if a password is not specified during creation, the default password used by Tomcat is "changeit" (all lowercase). If the default password is not changed, the keystore is at risk of compromise.
Fix
From the Tomcat server as a privileged user: sudo keytool -storepasswd When prompted for the keystore password, select a strong password, minimum 10 characters, mixed case alpha-numeric. Document the password and store in a secured location that is only accessible to authorized personnel.
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-000290: AccessLogValve must be configured per each virtual host.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple virtual hosts on one physical server by using the container attribute. This allows the admin to separate hosted applications according to where the domain the application will be available. Configuring logs on a per-host basis allows for log management that correlates to the virtual host activity. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001490: Secured connectors must use FIPS 140-2-validated cipher algorithms.
From the Tomcat server console, run the following command: sudo grep -i fipsmode $CATALINA_HOME/conf/server.xml. If there are no results displayed or if FIPSMode is not set to FIPSMode="on", this is a finding.
Discussion
If approved cryptographic algorithms are not used, encryption strength cannot be assured. When configuring a connector for secured communications, also select an approved encryption cipher. Examples include but are not limited to: Symmetric Key AES, Triple-DES, Escrowed Encryption Standard Asymmetric Key DSA, RSA, ECDSA Hash Standards *SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 *SHA1 may be used for legacy applications only.
Fix
From the Tomcat server as a privileged user: sudo nano $CATALINA_HOME/conf/server.xml. In the <Listener/> element, locate the AprLifecycleListener, either add or modify the FIPSMode setting and set it to FIPSMode="on". EXAMPLE: <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" FIPSMode="on" /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-000600: Tomcat management applications must use LDAP realm authentication.
If manager and host-manager applications have been deleted from the system, this is not a finding. From the Tomcat server as a privileged user, run the following commands: sudo grep -i -A8 JNDIRealm $CATALINA_HOME/conf/server.xml If the JNDIRealm does not exist or if the JNDIRealm configuration is commented out, this is finding.
Discussion
Using the local user store on a Tomcat installation does not meet a multitude of security control requirements related to user account management. To address this risk, Tomcat must be configured to utilize an LDAP or Active Directory installation that provides a centralized user account store that is configured to meet standard DoD user account management requirements. JNDIRealm is an implementation of the Tomcat Realm interface that looks up users in an LDAP directory server accessed by a JNDI provider (typically, the standard LDAP provider that is available with the JNDI API classes). The realm supports a variety of approaches to using a directory for authentication.
Fix
Identify the server IP that is providing LDAP services and configure the Tomcat user roles schema within LDAP. Refer to the manager and host-manager web.xml files for application specific role information that can be used for setting up the roles for those applications. The default location for these files is: $CATALINA_HOME/webapps/<AppName>/WEB-INF/web.xml From the Tomcat server console as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. Locate the <Realm> element in the server.xml file, add a nested <Realm> element using the JNDIRealm className and configure the associated LDAP settings as per the LDAP server connection requirements. EXAMPLE: This is for illustration purposes only. Modify the LDAP settings on a case-by-case basis as per the individual LDAP server and schema. <Realm className="org.apache.catalina.realm.JNDIRealm" connectionURL="ldaps://localhost:686" userPattern="uid={0},ou=people,dc=myunit,dc=mil" roleBase="ou=groups,dc=myunit,dc=mil" roleName="cn" roleSearch="(uniqueMember={0})" />
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001730: Connector address attribute must be set.
Review SSP documentation for list of approved connectors and associated TCP/IP ports and interfaces. Verify the address attribute is specified for each connector and is set to the network interface specified in the SSP. Execute the following command to find configured Connectors: sudo grep -i -B1 -A5 connector $CATALINA_HOME/conf/server.xml Review results and examine the "address=" field for each connector. If the connector address attribute is not specified as per the SSP, this is a finding.
Discussion
Connectors are how Tomcat receives requests over a network port, passes them to hosted web applications via HTTP or AJP, and then sends back the results to the requestor. The "address" attribute specifies which network interface the connector listens on. If no IP address is specified, the connector will listen on all configured interfaces. Access to the connector must be restricted to only the network interface(s) specified in the System Security Plan (SSP).
Fix
Ensure the address attribute for each connector and the network interfaces are specified in the SSP. Edit the following file From the Tomcat server as a privileged user: $CATALINA_HOME/conf/server.xml Locate each Connector element then edit or add the "address=" field for each connector and specify the appropriate network IP address. The following is an example using a random IP address: EXAMPLE: <Connector port="8443" address="192.168.0.145" ... /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000580: Documentation must be removed.
From the Tomcat server OS type the following command: sudo ls -l $CATALINA_HOME/webapps/docs. If the docs folder exists or contains any content, this is a finding.
Discussion
Tomcat provides documentation and other directories in the default installation which do not serve a production use. These files must be deleted.
Fix
From the Tomcat server OS type the following command: sudo rm -rf $CATALINA_HOME/webapps/docs
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000540: Autodeploy must be disabled.
If the Tomcat system is a development or test system on a non-production network, this requirement is NA. If the SSP associated with the Host contains ISSM documented approvals for AutoDeploy, this is not a finding. From the Tomcat server run the following OS command: sudo cat $CATALINA_HOME/conf/server.xml | grep -i -C2 autodeploy If the command returns no results, this is not a finding. Review the results for the autoDeploy parameter in each Host element. <Host name="YOUR HOST NAME" appbase="webapps" unpackWARs="true" autoDeploy="false"> If autoDeploy ="true", this is a finding.
Discussion
Tomcat allows auto-deployment of applications while Tomcat is running. This can allow untested or malicious applications to be automatically loaded into production. Autodeploy must be disabled in production. This requirement is NA for test and development systems on non-production networks. For DevSecOps application environments, the ISSM may authorize autodeploy functions on a production Tomcat system if the mission need specifies it and an application security vulnerability testing and assurance regimen is included in the DevSecOps process.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. Examine each <Host> </Host> element, if the element contains xpoweredBy="true", modify the statement to read ", xpoweredBy="false". sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001020: LockOutRealms must be used for management of Tomcat.
From the Tomcat server console, run the following command: sudo grep -i LockOutRealm $CATALINA_HOME/conf/server.xml. If there are no results or if the LockOutRealm is not used for the Tomcat management application context, this is a finding.
Discussion
A LockOutRealm adds the ability to lock a user out after multiple failed logins. LockOutRealm is an implementation of the Tomcat Realm interface that extends the CombinedRealm to provide user lock out functionality if there are too many failed authentication attempts in a given period of time. A LockOutRealm is created by wrapping around a standard realm such as a JNDI Directory Realm which connects Tomcat to an LDAP Directory. A Catalina container (Engine, Host, or Context) may contain no more than one Realm element (although this one Realm may itself contain multiple nested Realms). In addition, the Realm associated with an Engine or a Host is automatically inherited by lower-level containers unless the lower level container explicitly defines its own Realm. If no Realm is configured for the Engine, an instance of the Null Realm will be configured for the Engine automatically.
Fix
From the Tomcat server console as a privileged user edit the $CATALINA_HOME/conf/server.xml file sudo nano $CATALINA_HOME/conf/server.xml file Locate or add the LockOutRealm element. Make sure the LockOutRealm element is applied to the management application at a minimum (if the management application is in use on the system). This is done by ensuring the LockOutRealm is nested under the Engine, Host or directly within the management application Context container. EXAMPLE: <Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="5" lockOutTime="600"> ... </Realm>
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001290: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review the <Engine> element. Ensure one AccessLog <Valve> element is nested within the Engine element. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined, this is a finding. EXAMPLE: <Engine name="Standalone" ...> ... <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="catalina_access_log" suffix=".txt" pattern="common"/> ... </Engine>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001480: TLS 1.2 must be used on secured connectors.
From the Tomcat server console, run the following command: sudo cat $CATALINA_HOME/conf/server.xml. Examine each <Connector> </Connector> statement. For every HTTP protocol connector: Verify the SSLEnabledProtocols="TLSv1.2" flag is set on each connector. If the SSLEnabledProtocols setting is not set to TLSv1.2 or greater, this is a finding.
Discussion
Using older versions of TLS introduces security vulnerabilities that exist in the older versions of the protocol. Tomcat by default will use all available versions of the SSL/TLS protocols unless the version is explicitly defined in the SSL configuration attribute for the associated connector. This introduces the opportunity for the client to negotiate the use of an older protocol version and increases the risk of compromise of the Tomcat server. All connectors must use TLS 1.2.
Fix
As a privileged user on the Tomcat server, edit the $CATALINA_HOME/conf/server.xml and modify the <Connector> …</Connector> element. Add the "SSLEnabledProtocols=" flag to the connector or modify the existing flag. Set SSLEnabledProtocols="TLS1.2". Save the server.xml file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000030: HTTP Strict Transport Security (HSTS) must be enabled.
From the Tomcat server console, run the following command: sudo grep -i -A5 -B8 hstsEnable $CATALINA_HOME/conf/web.xml file. If the httpHeaderSecurity filter is commented out or if hstsEnable is not set to "true", this is a finding.
Discussion
HTTP Strict Transport Security (HSTS) instructs web browsers to only use secure connections for all future requests when communicating with a web site. Doing so helps prevent SSL protocol attacks, SSL stripping, cookie hijacking, and other attempts to circumvent SSL protection.
Fix
From the Tomcat server as a privileged user, edit the web.xml file: sudo nano $CATALINA_HOME/conf/web.xml file. Uncomment the existing httpHeaderSecurity filter section or create the filter section using the following code: <filter> <filter-name>httpHeaderSecurity</filter-name> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> <async-supported>true</async-supported> <hstsEnabled>true</hstsEnabled> </filter>
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000180: Role based access controls must be configured for logging.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Application servers utilize role-based access controls in order to specify the individuals who are allowed to configure application component logable events. The application server must be configured to select which personnel are assigned the role of selecting which logable events are to be logged.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000010: The number of allowed simultaneous sessions to the manager application must be limited.
If the manager application is not in use or has been deleted from the system, this is not a finding. From the Tomcat server as an elevated user run the following command: sudo grep -i maxactivesessions $CATALINA_HOME/webapps/manager/ META-INF/context.xml If the maxActiveSesions setting is not configured according to the number of connections defined in the SSP, this is a finding.
Discussion
The manager application provides configuration access to the Tomcat server. Access to the manager application must be limited and that includes the number of sessions allowed to access the management application. A balance must be struck between the number of simultaneous connections allowed to the management application and the number of authorized admins requiring access at any given time. Determine the number of authorized admins requiring simultaneous access and increase the number of allowed simultaneous sessions by a small percentage in order to help prevent potential lockouts. Document that value in the System Security Plan.
Fix
Determine the number of authorized admins requiring simultaneous access and increase the number of allowed simultaneous sessions by a small percentage in order to address potential lockout scenarios. Document that value in the System Security Plan. Review the maxActiveSessions setting in the $CATALINA_HOME/webapps/manager/ META-INF/context.xml configuration file. Configure maxActiveSessions setting according to admin access requirements defined in the SSP. EXAMPLE: <Manager … maxActiveSessions="10" />
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000930: Default error pages for manager application must be customized.
From the Tomcat server console, run the following command: sudo cat $CATALINA_HOME/webapps/manager/WEB-INF/jsp/401.jsp Repeat for the 402.jsp and 403.jsp files. The default error files contain default passwords and user accounts. If the error files contained in this folder are not customized and default account information removed, this is a finding.
Discussion
Default error pages that accompany the manager application provide sensitive information to potential attackers. These error pages provide responses to 401, 402, and 403 error codes and must be modified so the error responses do not provide clients with any sensitive information.
Fix
From the Tomcat server as a privileged user: Use a file editor like nano or vi and edit the 401, 402, and 403 jsp files. Remove sensitive account information and make the files reflect generic error information that assists users but does not provide sensitive data to users. Save the file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001500: Secured connectors must use FIPS 140-2-validated cipher algorithms.
From the Tomcat server console, run the following command: sudo grep -i fipsmode $CATALINA_HOME/conf/server.xml. If there are no results displayed or if FIPSMode is not set to FIPSMode="on", this is a finding.
Discussion
If approved cryptographic algorithms are not used, encryption strength cannot be assured. When configuring a connector for secured communications, also select an approved encryption cipher. Examples include but are not limited to: Symmetric Key AES, Triple-DES, Escrowed Encryption Standard Asymmetric Key DSA, RSA, ECDSA Hash Standards *SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 *SHA1 may be used for legacy applications only.
Fix
From the Tomcat server as a privileged user: sudo nano $CATALINA_HOME/conf/server.xml. In the <Listener> element, locate the AprLifecycleListener, either add or modify the FIPSMode setting and set it to FIPSMode="on" EXAMPLE: <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" FIPSMode="on" /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-000750: Tomcat must use FIPS-validated ciphers on secured connectors.
From the Tomcat server console, run the following command: sudo grep -i fipsmode $CATALINA_HOME/conf/server.xml. If there are no results displayed or if FIPSMode is not set to FIPSMode="on", this is a finding.
Discussion
Connectors are how Tomcat receives requests over a network port, passes them to hosted web applications via HTTP or AJP, and then sends back the results to the requestor. Cryptographic ciphers are associated with the connector to create a secured connector. To ensure encryption strength is adequately maintained, the ciphers used must be FIPS 140-2-validated. Crypto libraries are provided by either the Java instance that Tomcat uses or by the OpenSSL implementation.
Fix
From the Tomcat server as a privileged user: sudo nano $CATALINA_HOME/conf/server.xml. In the <Listener/> element, locate the AprLifecycleListener, either add or modify the FIPSMode setting and set it to FIPSMode="on" EXAMPLE: <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" FIPSMode="on" /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-001710: Hosted applications must be documented in the system security plan.
Review the Tomcat servers System Security Plan/server documentation. Access the Tomcat server and review the $CATALINA_HOME/webapps folder and the $CATALINA_BASE/webapps folder (if they exist). Ensure that all webapps are documented in the SSP. If the applications that are hosted on the Tomcat server are not documented in the SSP, this is a finding.
Discussion
The system administrator must be cognizant of all applications operating on the Tomcat server, and must address any security implications associated with the operation of the applications.
Fix
Document the applications that have an ATO on the Tomcat server. Retain the information in the SSP and present to the auditor in the event of a CCRI.
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001430: Certificates in the trust store must be issued/signed by an approved CA.
For the systemd Ubuntu OS, check the tomcat.service file to read the content of the JAVA_OPTS environment variable setting. sudo cat /etc/systemd/system/tomcat.service |grep -i truststore EXAMPLE output: set JAVA_OPTS="-Djavax.net.ssl.trustStore=/path/to/truststore" "-Djavax.net.ssl.trustStorePassword=************" If the variable is not set, use the default location command below. If the variable is set, use the alternate location command below and include the path and truststore file. -Default location: keytool -list -cacerts -v | grep -i issuer -Alternate location: keytool -list -keystore <location of trust store file> -v |grep -i issuer If there are no CA certificates issued by a Certificate Authority (CA) that is part of the DoD PKI/PKE, this is a finding.
Discussion
Use of self-signed certificates creates a lack of integrity and invalidates the certificate based authentication trust model. Certificates used by production systems must be issued/signed by a trusted Root CA and cannot be self-signed. For systems that communicate with industry partners, the DoD ECA program supports the issuance of DoD-approved certificates to industry partners. For information on the DoD ECA program, refer to the DoD PKI office. Links to their site are available on https://public.cyber.mil.
Fix
Obtain and install the DoD PKI CA certificate bundles by accessing the DoD PKI office web site at https://cyber.mil/pki-pke. Download the certificate bundles and then use certificate management utilities such as keytool or openssl to import the DoD CA certificates into the trust store.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001440: Secured connectors must use FIPS 140-2-validated cipher algorithms.
From the Tomcat server console, run the following command: sudo grep -i fipsmode $CATALINA_HOME/conf/server.xml. If there are no results displayed or if FIPSMode is not set to FIPSMode="on", this is a finding.
Discussion
If approved cryptographic algorithms are not used, encryption strength cannot be assured. When configuring a connector for secured communications, the user must also select an approved encryption cipher. Examples include but are not limited to: Symmetric Key AES, Triple-DES, Escrowed Encryption Standard Asymmetric Key DSA, RSA, ECDSA Hash Standards *SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 *SHA1 may be used for legacy applications only.
Fix
From the Tomcat server as a privileged user: sudo nano $CATALINA_HOME/conf/server.xml. In the <Listener/> element, locate the AprLifecycleListener, either add or modify the FIPSMode setting and set it to FIPSMode="on" EXAMPLE: <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" FIPSMode="on" /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-001680: ALLOW_BACKSLASH must be set to false.
If the ISSO has accepted the risk for enabling the ALLOW_BACKSLASH setting, this requirement is NA. From the Tomcat server as an elevated user, run the following command: sudo grep -i ALLOW_BACKSLASH $CATALINA_HOME/conf/catalina.properties sudo grep -i catalina_opts /etc/systemd/system/tomcat.service If org.apache.catalina.connector. ALLOW_BACKSLASH=true, this is a finding.
Discussion
When Tomcat is installed behind a proxy configured to only allow access to certain Tomcat contexts (web applications), an HTTP request containing "/\../" may allow attackers to work around the proxy restrictions using directory traversal attack methods. If allow_backslash is true the '\' character will be permitted as a path delimiter. The default value for the setting is false but Tomcat should always be configured as if no proxy restricting context access was used and allow_backslash should be set to false to prevent directory traversal style attacks. This setting can create operability issues with non-compliant clients. In order to accommodate a non-compliant client, any deviation from the STIG setting must be approved by the ISSO.
Fix
As a privileged user on the Tomcat server: If the finding is in the catalina.properties file, edit the $CATALINA_HOME/conf/catalina.properties file. sudo nano $CATALINA_HOME/conf/catalina.properties Change the org.apache.catalina.connector.ALLOW_BACKSLASH=true setting to =false. If the finding is in the /etc/systemd/services/tomcat/service file, edit the file using a text editor. sudo nano /etc/systemd/services/tomcat.service Locate the "Environment='CATALINA_OPTS=' line and change the -D.org.apache.catalina.connectorALLOW_BACKSLASH=true setting to =false. Restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001040: LockOutRealms lockOutTime attribute must be set to 600 seconds (10 minutes) for admin users.
From the Tomcat server console, run the following command: sudo grep -i LockOutRealm $CATALINA_HOME/conf/server.xml. If there are no results or if the LockOutRealm lockOutTime setting is not configured to 600 (10 minutes), this is a finding.
Discussion
A LockOutRealm adds the ability to specify a lockout time that prevents further attempts after multiple failed logins. Setting the lockOutTime attribute to 600 will lock out a user account for 10 minutes. Further authentication failures during the lock out time will cause the lock out timer to reset to zero, effectively extending the lockout time. Valid authentication attempts during the lockout period will not succeed but will also not reset the lockout time. LockOutRealm is an implementation of the Tomcat Realm interface that extends the CombinedRealm to provide user lock out functionality if there are too many failed authentication attempts in a given period of time. A LockOutRealm is created by wrapping around a standard realm such as a JNDI Directory Realm which connects Tomcat to an LDAP Directory. A Catalina container (Engine, Host, or Context) may contain no more than one Realm element (although this one Realm may itself contain multiple nested Realms). In addition, the Realm associated with an Engine or a Host is automatically inherited by lower-level containers unless the lower level container explicitly defines its own Realm. If no Realm is configured for the Engine, an instance of the Null Realm will be configured for the Engine automatically.
Fix
From the Tomcat server console as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. sudo nano $CATALINA_HOME/conf/server.xml file Locate or add the LockOutRealm element. Set lockOutTime="600" EXAMPLE: <Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="5" lockOutTime="600"> ... </Realm>
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001320: Multi factor certificate-based tokens (CAC) must be used when accessing the management interface.
If the manager application has been deleted from the Tomcat server, this is not a finding. From the Tomcat server as a privileged user, issue the following command: sudo grep -i auth-method $CATALINA_HOME/webapps/manager/WEB-INF/web.xml If the <Auth-Method> for the web manager application is not set to CLIENT-CERT, this is a finding.
Discussion
Password authentication does not provide sufficient security control when accessing a management interface. DoD has specified that the CAC will be used when authenticating and passwords will only be used when CAC authentication is not a plausible solution. Tomcat provides the ability to do certificate based authentication and client authentication, therefore the Tomcat server must be configured to use CAC.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/webapps/manager/WEB-INF/web.xml file and modify the auth-method for the manager application security constraint. sudo nano $CATALINA_HOME/webapps/manager/WEB-INF/web.xml Locate <auth-method> contained within the <login-config> section, modify <auth-method> to specify CLIENT-CERT. EXAMPLE: <auth-method>CLIENT-CERT</auth-method> In addition, the connector used for accessing the manager application must be configured to require client authentication by setting clientAuth="true" and the manager application roles must be configured in the LDAP server. Restart the Tomcat server: sudo systemctl restart tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001470: Tomcat server must be patched for security vulnerabilities.
Refer to https://tomcat.apache.org/security-9.html and identify the latest secure version of Tomcat with no known vulnerabilities. As a privileged user from the Tomcat server, run the following command: sudo $CATALINA_HOME/bin/version.sh |grep -i server Compare the version running on the system to the latest secure version of Tomcat. If the latest secure version of Tomcat is not installed, this is a finding.
Discussion
Tomcat is constantly being updated to address newly discovered vulnerabilities some of which include Denial-of-Service attacks. To address this risk, the Tomcat admin must ensure the system remains up to date on patches.
Fix
Follow operational procedures for upgrading Tomcat. Download latest version of Tomcat and install in a test environment. Test applications that are running in production and follow all operations best practices when upgrading the production Tomcat application servers. Update the Tomcat production instance accordingly and ensure corrected builds are installed once tested and verified.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000490: The shutdown port must be disabled.
From the Tomcat server run the following OS command: $ sudo grep -i shutdown $CATALINA_HOME/conf/server.xml Ensure the server shutdown port attribute in $CATALINA_HOME/conf/server.xml is set to -1. EXAMPLE: <Server port="-1" shutdown="SHUTDOWN"> If Server port not = "-1" shutdown="SHUTDOWN", this is a finding.
Discussion
Tomcat listens on TCP port 8005 to accept shutdown requests. By connecting to this port and sending the SHUTDOWN command, all applications within Tomcat are halted. The shutdown port is not exposed to the network as it is bound to the loopback interface. Set the shutdown attribute in $CATALINA_HOME/conf/server.xml.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/conf/server.xml file: set the Server port setting to -1 and restart the Tomcat server: <Server port="-1" shutdown="SHUTDOWN"> sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000371: $CATALINA_HOME/conf folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/conf -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/conf folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/conf -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/conf
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000170: Tomcat servers behind a proxy or load balancer must log client IP.
Review the System Security Plan and determine if the Tomcat server resides behind a proxy server or load balancer. If the Tomcat server is not behind a proxy server or load balancer, this requirement is NA. From the Tomcat server run the following command: sudo grep -i RemoteIpValve $CATALINA_HOME/conf/server.xml file. If the results are empty or if the requestAttributesEnabled setting is not configured as "True", this is a finding. sudo grep -i AccessLogValve $CATALINA_HOME/conf/server.xml file. If the requestAttributesEnabled setting is not configured as "True", this is a finding.
Discussion
When running Tomcat behind a load balancer or proxy, default behavior is for Tomcat to log the proxy or load balancer IP address as the client IP. Desired behavior is to log the actual client IP rather than the proxy IP address. The RemoteIpValve logging component instructs Tomcat to grab the HTTP header X-Forwarded-For and use that for access logging. Tomcat will identify 127.0.0.1, class A and class C RFC1918 addresses as internal proxy addresses; however, if the proxy has a routable IP or a class B private network address space (172.16.0.0/12), the user must also verify the "internalProxies setting is configured to reflect the proxy IP address.
Fix
From the Tomcat server as a privileged user: Edit the $CATALINA_HOME/conf/server.xml file. Only execute this first step if the proxy server is using a routable IP address or an RFC 1918 Class B address space: Add or edit the RemoteIpValve and configure the internalProxies setting to reflect the proxy addresses. Modify the AccessLogValve and configure the requestAttributesEnabled setting = "True". EXAMPLE: <Valve className="org.apache.catalina.valves.RemoteIpValve" internalProxies="172.16.0.10|172.16.0.11" /> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="access" suffix=".log" pattern="combined" renameOnRotate="true" requestAttributesEnabled="true" /> Restart Tomcat: sudo systemctl restart tomcat sudo systemctl tomcat daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001600: AccessLogValve must be configured per each virtual host.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple virtual hosts on one physical server by using the container attribute. This allows the admin to separate hosted applications according to where the domain the application will be available. Configuring logs on a per-host basis allows for log management that correlates to the virtual host activity. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000210: AccessLogValve must be configured for each application context.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple contexts (applications) on one physical server by using the element. This allows the admin to specify audit log settings on a per application basis. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001450: Secured connectors must use FIPS 140-2-validated cipher algorithms.
From the Tomcat server console, run the following command: sudo grep -i fipsmode $CATALINA_HOME/conf/server.xml. If there are no results displayed or if FIPSMode is not set to FIPSMode="on", this is a finding.
Discussion
If approved cryptographic algorithms are not used, encryption strength cannot be assured. When configuring a connector for secured communications, also select an approved encryption cipher. Examples include but are not limited to: Symmetric Key AES, Triple-DES, Escrowed Encryption Standard Asymmetric Key DSA, RSA, ECDSA Hash Standards *SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 *SHA1 may be used for legacy applications only.
Fix
From the Tomcat server as a privileged user: sudo nano $CATALINA_HOME/conf/server.xml. In the <Listener/> element, locate the AprLifecycleListener, either add or modify the FIPSMode setting and set it to FIPSMode="on". EXAMPLE: <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" FIPSMode="on" /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-000790: Access to Tomcat manager application must be restricted.
Review system documentation (SSP) and identify the documented management networks as well as the documented client networks. If the manager application has been deleted from the system, this is not a finding. Run the following command as a privileged user: sudo grep -i -A1 "RemoteAddrValve\|RemoteCIDRValve" $CATALINA_HOME/webapps/manager/META-INF/context.xml If there are no results, then no address valves exist and this is a finding. If the Remote Address Valve settings are commented out or not configured to restrict access to localhost or the management network, this is a finding. EXAMPLES: - RemoteAddrValve Localhost only IPV4 and IPV6 example <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/> -Localhost and Management network CIDR block IPV4 and IPV6 example <Valve className="org.apache.catalina.valves.RemoteCIDRValve" allow="127.0.0.1, ::1",192.168.1.0/24/>
Discussion
The Tomcat manager application is used to manage the Tomcat server and the applications that run on Tomcat. By default, the manager application is only accessible via the localhost. Exposing the management application to any network interface that is available to non-administrative personnel leaves the Tomcat server vulnerable to attempts to access the management application. To mitigate this risk, the management application should only be run on the localhost or on network interfaces tied to a dedicated management network. This setting is managed in the $CATALINA_HOME/conf/server.xml file.
Fix
Update system documentation (SSP) and identify the documented management networks as well as the documented client networks. As a privileged user, edit the $CATALINA_HOME/webapps/manager/META-INF/context.xml file. Configure the RemoteAddrValve or RemoteCIDRValve to restrict access to the management application. This can be a restriction to the localhost or to specific management networks or hosts on the management network. Choice of address or CIDR block usage is based on operational requirements. Order is allow from, deny from. See Tomcat Valve component documentation at the Tomcat web site for specific details and additional configuration options. Test the access restrictions once configured to assure compliance. EXAMPLES: - RemoteAddrValve Localhost only IPV4 and IPV6 <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/> -Localhost and Management network CIDR block IPV4 and IPV6 <Valve className="org.apache.catalina.valves.RemoteCIDRValve" allow="127.0.0.1, ::1",192.168.1.0/24/>
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000140: AccessLogValve must be configured for each application context.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple contexts (applications) on one physical server by using the element. This allows the admin to specify audit log settings on a per application basis. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000110: The Java Security Manager must be enabled.
Identify the tomcat systemd startup file which is usually called "tomcat.service" and can be viewed as a link in the /etc/systemd/system/ folder. sudo cat /etc/systemd/system/tomcat.service |grep -i security If the ExecStart parameter does not include the -security flag, this is a finding.
Discussion
The Java SecurityManager is what allows a web browser to run an applet in its own sandbox to prevent untrusted code from accessing files on the local file system, connecting to a host other than the one the applet was loaded from, and so on. In the same way the SecurityManager protects the user from an untrusted applet running in the browser, use of a SecurityManager while running Tomcat can protect the server from trojan servlets, JSPs, JSP beans, tag libraries, or even inadvertent mistakes.
Fix
As an admin user on the Tomcat server, modify the /etc/systemd/system/tomcat.service file and set the "ExecStart" parameter to read: "ExecStart=/opt/tomcat/bin/startup.sh -security" Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000270: The first line of request must be logged.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review all <Valve> elements. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> If the pattern= statement does notinclude "%r", this is a finding.
Discussion
The access logfile format is defined within a Valve that implements the org.apache.catalina.valves.AccessLogValve interface within the /opt/tomcat/server.xml configuration file: The "%r" pattern code is included in the pattern element and logs the first line associated with the event, namely the request method, URL path, query string, and protocol (""" simply specifies a literal double quote). Including the pattern in the log configuration provides useful information about the time of the event which is critical for troubleshooting and forensic investigations.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Modify the <Valve> element(s) nested within the <Host> element(s). Change the AccessLogValve setting to include "%r" in the pattern= statement. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000780: Access to JMX management interface must be restricted.
Review the system security plan and network documentation. Identify the management networks that are used for system management. From the Tomcat server as a privileged user, run the following command: sudo grep -i jmxremote /etc/systemd/system/tomcat.service If there are no results, the JMX process is not being used, and this is not a finding. If output includes jmxremote information, review the -Dcom.sun.management.jmxremote.host setting. Compare the IP address associated with the JMX process with the network information in the SSP. Ensure the IP address space is dedicated for system management purposes. If the IP address that is associated with the JMX process is not dedicated to system management usage, this is a finding. If jmxremote is in use but the host IP address is not specified, this is a finding.
Discussion
Java Management Extensions (JMX) is used to provide programmatic access to Tomcat for management purposes. This includes monitoring and control of java applications running on Tomcat. If network access to the JMX port is not restricted, attackers can gain access to the application used to manage the system.
Fix
Make an operational determination regarding the use of JMX. If JMX management is decided upon, identify the management networks that are used for system management. Update the system security plan and network documentation with the information. Edit the /etc/systemd/system/tomcat.service file. Add or modify the existing CATALINA_OPTS -Dcom.sun.management.jmxremote.host setting. Set the host parameter to an IP address that is only available on a management network. EXAMPLE: CATALINA_OPTS='-Dcom.sun.management.jmxremote.host=192.168.0.150' Restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload Verify jmxmanagement access is restricted to the management network IP address range.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001060: Tomcat user account must be a non-privileged user.
Run the following command to identify the Tomcat process UID: ps -ef | { head -1; grep catalina; } | cut -f1 -d" " Run the following command to obtain the OS user ID tied to the Tomcat process: cat /etc/passwd|grep -i <UID>|cut -f3 -d: If the user ID field of the passwd file is set to < 1000 or = 0, this is a finding.
Discussion
Use a distinct non-privileged user account for running Tomcat. If Tomcat processes are compromised and a privileged user account is used to operate the Tomcat server processes, the entire system becomes compromised. Sample passwd file: tomcat:x:1001:1001::/opt/tomcat/usr/sbin/nologin The user ID is stored in field 3 of the passwd file.
Fix
From the Tomcat server, create a tomcat user by adding a new non-privileged user OS account with the following command: sudo useradd tomcat Edit the systemd tomcat.service file or create one if it does notexist. Use the new "tomcat" user account by setting; USER=tomcat Location of the file should be /etc/systemd/system/tomcat.service Enable the Tomcat service: sudo restorecon /etc/systemd/system/tomcat.service sudo chmod 644 /etc/systemd/system/tomcat.service sudo systemctl enable tomcat.service Start Tomcat: sudo systemctl start tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000100: Connectors must be secured.
From the Tomcat server console, run the following command: sudo cat $CATALINA_HOME/conf/server.xml. Examine each <Connector/> element. For each connector, verify the secure= flag is set to "true" and the scheme= flag is set to "https" on each connector. If the secure flag is not set to "true" and/or the scheme flag is not set to "https" for each HTTP connector element, this is a finding.
Discussion
The unencrypted HTTP protocol does not protect data from interception or alteration which can subject users to eavesdropping, tracking, and the modification of received data. To secure an HTTP connector, both the secure and scheme flags must be set.
Fix
From the Tomcat server as a privileged user, edit the server.xml file. sudo nano $CATALINA_HOME/conf/server.xml. Locate each <Connector/> element which is lacking a secure setting. EXAMPLE Connector: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="443" /> Set or add scheme="https" and secure="true" for each HTTP connector element. EXAMPLE: <Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true".../> Save the server.xml file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl reload-daemon
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000970: Idle timeout for management application must be set to 10 minutes.
If the manager application has been deleted from the system, this is not a finding. From the Tomcat server as a privileged user, run the following commands: sudo grep -i session-timeout $CATALINA_HOME/webapps/manager/META-INF/web.xml sudo grep -i session-timeout $CATALINA_HOME/conf/web.xml If the session-timeout setting is not configured to be 10 minutes in at least one of these files, this is a finding.
Discussion
Tomcat can set idle session timeouts on a per application basis. The management application is provided with the Tomcat installation and is used to manage the applications that are installed on the Tomcat Server. Setting the idle timeout for the management application will kill the admin user's session after 10 minutes of inactivity. This will limit the opportunity for unauthorized persons to hijack the admin session. This setting will also affect the default timeout behavior of all hosted web applications. To adjust the individual hosted application settings that are not related to management of the system, modify the individual application web.xml file if application timeout requirements differ from the STIG.
Fix
If the manager application has been deleted from the system, this is not a finding. From the Tomcat server as a privileged user: To affect session timeout for all applications including the management application, edit the: $CATALINA_HOME/conf/web.xml file. To affect session timeout for the management application only, edit the: $CATALINA_HOME/webapps/manager/META-INF/web.xml file. Locate the session-timeout setting located within the session-config element. Modify the session-timeout setting to be 10 minutes. Save the file. sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001230: $CATALINA_HOME/conf folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/conf -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/conf folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/conf -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/conf
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001660: STRICT_SERVLET_COMPLIANCE must be set to true.
From the Tomcat server as a privileged user, run the following command: sudo grep -i strict_servlet /etc/systemd/system/tomcat.service If there are no results, or if the -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE is not set to true, this is a finding.
Discussion
Strict Servlet Compliance forces Tomcat to adhere to standards specifications including but not limited to RFC2109. RFC2109 sets the standard for HTTP session management. This setting affects several settings which primarily pertain to cookie headers, cookie values, and sessions. Cookies will be parsed for strict adherence to specifications. Note that changing a number of these default settings may break some systems, as some browsers are unable to correctly handle the cookie headers that result from a strict adherence to the specifications. This one setting changes the default values for the following settings: org.apache.catalina.core. ApplicationContext.GET_RESOURCE_REQUIRE_SLASH org.apache.catalina.core. ApplicationDispatcher.WRAP_SAME_OBJECT org.apache.catalina.core. StandardHostValve.ACCESS_SESSION org.apache.catalina.session. StandardSession.ACTIVITY_CHECK org.apache.catalina.session. StandardSession.LAST_ACCESS_AT_START org.apache.tomcat.util.http. ServerCookie.ALWAYS_ADD_EXPIRES org.apache.tomcat.util.http. ServerCookie.FWD_SLASH_IS_SEPARATOR org.apache.tomcat.util.http. ServerCookie.PRESERVE_COOKIE_HEADER org.apache.tomcat.util.http. ServerCookie.STRICT_NAMING The resourceOnlyServlets attribute of any Context element. The tldValidation attribute of any Context element. The useRelativeRedirects attribute of any Context element. The xmlNamespaceAware attribute of any Context element. The xmlValidation attribute of any Context element.
Fix
From the Tomcat server as a privileged user: Edit the /etc/systemd/system/tomcat.service file and either add or edit the org.apache.catalina.STRICT_SERVLET_COMPLIANCE setting. Set the org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true EXAMPLE: CATALINA_OPTS='-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true' Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000020: Secured connectors must be configured to use strong encryption ciphers.
From the Tomcat server console, run the following command: sudo grep -i ciphers $CATALINA_HOME/conf/server.xml. Examine each <Connector> statement that is not a redirect to a secure port. If insecure ciphers are specified, this is a finding.
Discussion
The Tomcat element controls the SSL/TLS protocol and the associated ciphers used. If a strong cipher is not selected, an attacker may be able to circumvent encryption protections that are configured for the connector. Strong ciphers must be employed when configuring a secured connector. The configuration attribute and its values depend on what HTTPS implementation the user is utilizing. The user may be utilizing either Java-based implementation (aka JSSE) with BIO and NIO connectors or OpenSSL-based implementation with APR connector. false
Fix
As a privileged user on the Tomcat server, edit the $CATALINA_HOME/conf/server.xml and modify the <Connector> …</Connector> element. Add the "SSLEnabledProtocols=" flag to the connector or modify the existing flag. Set SSLEnabledProtocols="TLS1.2". Save the server.xml file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl reload-daemon
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000361: Files in the $CATALINA_HOME/logs/ folder must have their permissions set to 640.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/logs/* -follow -maxdepth 0 -type f \( \! -perm 640 \) -ls If no files are displayed, this is not a finding. If results indicate any of the file permissions contained in the $CATALINA_HOME/logs folder are not set to 640, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/logs/* -follow -maxdepth 0 -type f -print0 | sudo xargs chmod 640 $CATALINA_HOME/logs/*
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000800: Tomcat servers must mutually authenticate proxy or load balancer connections.
Review system security plan and/or system architecture documentation and interview the system admin. Identify any proxy servers or load balancers that provide services for the Tomcat server. If there are no load balancers or proxies in use, this is not a finding. If there is a documented risk acceptance for not mutually authenticating proxy of load balancer connections due to operational issues, this is not a finding. Using the aforementioned documentation, identify each Tomcat IP address that is served by a load balancer or proxy. From the Tomcat server as a privileged user, review the $CATALINA_HOME/conf/server.xml file. Review each <Connector> element for the address setting and the clientAuth setting. sudo grep -i -B1 -A5 connector $CATALINA_HOME/conf/server.xml If a connector has a configured IP address that is proxied or load balanced and the clientAuth setting is not "true", this is a finding.
Discussion
Tomcat servers are often placed behind a proxy when exposed to both trusted and untrusted networks. This is done for security and performance reasons. Tomcat does provide an HTTP server that can be configured to make hosted applications available to clients directly. However, this HTTP server has performance limitations and is not intended to be used on an enterprise scale. Exposing this service to untrusted networks also violates the layered security model and creates elevated risk of attack. To address these issues, a proxy or load balancer can be placed in front of the Tomcat server. To ensure the proxied connection is not spoofed, SSL mutual authentication must be employed between Tomcat and the proxy.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. Modify each <Connector> element where the IP address is behind a proxy or load balancer. Set clientAuth="true" then identify the applications that are associated with the connector and edit the associated web.xml files. Assure the <auth-method> is set to CLIENT-CERT.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000190: AccessLogValve must be configured for each application context.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple contexts (applications) on one physical server by using the element. This allows the admin to specify audit log settings on a per application basis. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001200: $CATALINA_HOME folder must be owned by the root user, group tomcat.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME -follow -maxdepth 0 \( ! -user root -o ! -group tomcat \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME folder ownership and group membership is not set to root:tomcat, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have the folder where Tomcat is installed owned by the root user with the group set to tomcat. The CATALINA_HOME environment variable should be set to the location of the root directory of the "binary" distribution of Tomcat.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME -maxdepth 0 \( ! -user root \) | sudo xargs chown root sudo find $CATALINA_HOME -maxdepth 0 \( ! -group tomcat \) | sudo xargs chgrp tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000550: The xpoweredBy attribute must be disabled.
From the Tomcat server run the following OS command: sudo cat $CATALINA_HOME/conf/server.xml |grep -i -C4 xpoweredby. If any connector elements contain xpoweredBy="true", this is a finding.
Discussion
Individual connectors can be configured to display the Tomcat server info to clients. This information can be used to identify Tomcat versions which can be useful to attackers for identifying vulnerable versions of Tomcat. Individual connectors must be checked for the xpoweredBy attribute to ensure they do not pass Tomcat server info to clients.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. Examine each <Connector> </Connector> element, if the element contains xpoweredBy="true", modify the statement to read ", xpoweredBy="false". sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001220: $CATALINA_HOME/conf/ folder must be a owned by root, group tomcat.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/conf -follow -maxdepth 0 \( ! -user root -o ! -group tomcat \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/conf folder ownership and group membership is not set to root:tomcat, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have Tomcat files contained in the conf/ folder as members of the "tomcat" group. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions. Note that running Tomcat in a Docker environment can impact how file permissions and user ownership settings are applied. Due to associated Docker configuration complexities, the STIG is scoped for standalone rather than virtual Docker deployments.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/conf -maxdepth 0 \( ! -user root \) | sudo xargs chown root sudo find $CATALINA_HOME/conf -maxdepth 0 \( ! -group tomcat \) | sudo xargs chgrp tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000680: TLS 1.2 must be used on secured connectors.
From the Tomcat server console, run the following command: sudo cat $CATALINA_HOME/conf/server.xml. Examine each <Connector> </Connector> statement. For every HTTP protocol connector, verify the SSLEnabledProtocols="TLSv1.2" flag is set on each connector. If the SSLEnabledProtocols setting is not set to TLSv1.2 or greater, this is a finding.
Discussion
Encryption is the standard method for protecting data during transmission. If data is not encrypted with a secure protocol such as TLS 1.2, the data can be plainly read (i.e., clear text) and easily compromised. Versions of TLS 1.1 and SSL versions have known vulnerabilities and must not be used.
Fix
As a privileged user on the Tomcat server, edit the $CATALINA_HOME/conf/server.xml and modify the <Connector> …</Connector> element. Add the "SSLEnabledProtocols=" flag to the connector or modify the existing flag. Set SSLEnabledProtocols="TLS1.2". Save the server.xml file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl reload-daemon
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000450: Tomcat user UMASK must be set to 0027.
Reference the system documentation and make relevant changes to the following commands if the system differs: From the Tomcat server command line run the following command: sudo cat /etc/systemd/system/tomcat.service | grep -i umask If the umask is not = 0027, this is a finding.
Discussion
For Unix-based systems, umask settings affect file creation permissions. If the permissions are too loose, newly created log files and applications could be accessible to unauthorized users via the file system. Ensure the Tomcat OS user account has the correct file creation permission settings by validating the OS umask settings for the Tomcat user. Setting umask to 0027 gives the Tomcat user full rights, group users r-x permission, and all others no access. Tomcat will most likely be running as a systemd service. Locate the systemd service file for Tomcat. The default location for the link to the service file is in /etc/systemd/system folder. The service file name should be indicative of the Tomcat process so tomcat.service is the logical name for the service file and is the name referenced by the STIG.
Fix
From the Tomcat server as a privileged user: Use a file editor like nano or vi and edit the /etc/systemd/system/tomcat.service file. Change the "UMask=" setting to 0027. UMask =0027 Save the file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000530: The deployXML attribute must be set to false in hosted environments.
This requirement is NA for test and development systems on non-production networks. For production application environments, the ISSM may authorize autodeploy functions on a production Tomcat system if the mission need specifies it and an application security vulnerability testing and assurance regimen is included in the DevSecOps process or other application development processes and satisfactory results from the latest vulnerability testing are provided to the inspector during readiness review. From the Tomcat server as a privileged user: sudo grep -i deployXML $CATALINA_HOME/conf/server.xml If the deployXML setting is configured as true and there is no documented authorization to allow automatic deployment of applications, this is a finding.
Discussion
The Host element controls deployment. Automatic deployment allows for simpler management, but also makes it easier for an attacker to deploy a malicious application. 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. In a hosted environment where web applications may not be trusted, 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. Note that if the security manager is enabled that the deployXML attribute will default to false. This requirement is NA for test and development systems on non-production networks. For DevSecOps application environments, the ISSM may authorize autodeploy functions on a production Tomcat system if the mission need specifies it and an application security vulnerability testing and assurance regimen is included in the DevSecOps process.
Fix
Document authorization for application auto deployment in the System Security Plan (SSP). From the Tomcat server as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. sudo nano $CATALINA_HOME/conf/server.xml Locate each <host> element in the server xml file and if the deployXML="true" ensure each host is authorized for application auto deployment and document the authorization in the system security plan. If authorization is not provided, set the deployXML="false"
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000590: Applications in privileged mode must be approved by the ISSO.
Individual Context elements may be explicitly defined in an individual file located at /META-INF/context.xml inside the application files or in the $CATALINA_HOME/conf/context.xml file. It is not recommended to store the context element in the server.xml file as changes will require a server restart. The $CATALINA_HOME/conf/context element information will be loaded by all web applications, the META-INF/context.xml will only be loaded by that specific application. On the Tomcat server as a privileged user run the following commands: grep -i privileged $CATALINA_HOME/conf/context.xml Repeat the following command for each installed application: grep -i privileged $CATALINA_HOME/webapps/<application name>META-INF/context.xml If the privileged context attribute is set to true, confirm the application has been approved for privileged mode by the ISSO. If the application is not approved to run in privileged mode, this is a finding.
Discussion
The privileged attribute controls if a context (application) is allowed to use container provided servlets like the Manager servlet. It is false by default and should only be changed for trusted web applications. Set to true to allow the context (application) to use container servlets, like the manager servlet. Use of the privileged attribute will change the context's parent class loader to be the Server class loader rather than the Shared class loader. Note that in a default installation, the Common class loader is used for both the Server and the Shared class loaders. Use of the privileged attribute will change the context's parent class loader to be the Server class loader rather than the Shared class loader.
Fix
On the Tomcat server as a privileged user, modify the relevant context.xml file and set the privileged attribute to false (privileged=false). A restart should not be required if the context element is not maintained in the server.xml file. If privileged mode is required for a particular application, verify trust of application and obtain documented approval from the ISSO. Document the applications that are approved to run in privileged mode and retain approvals in the system security plan (SSP) for CCRI reviews.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000360: $CATALINA_HOME/logs folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/logs -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/logs folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/logs -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/logs
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000710: Keystore file must be protected.
Identify the location of the .keystore file. Refer to system documentation or review the server.xml file for a specified .keystore file location. From the Tomcat server console run the following command to check the server.xml file: sudo grep -i keystorefile $CATALINA_HOME/conf/server.xml Extract the location of the file from the output. Example: [keystorefile=/opt/tomcat/conf/<filename.jks>] sudo ls -la [keystorefile location] If the file permissions are not set to 640 USER:root GROUP:tomcat, this is a finding. If the keystore file is not stored within the tomcat folder path, i.e. [/opt/tomcat/], this is a finding.
Discussion
Keystore file contains authentication information used to access application data and data resources. Access to the file must be protected. The default location is in the .keystore file stored in the home folder of the user account used to run Tomcat although some administrators may choose to locate the file elsewhere. The location will also be specified in the server.xml file.
Fix
Run the following commands on the Tomcat server: sudo chmod 640 [keystorefile] sudo chown root [keystorefile] sudo chgrp tomcat [keystorefile] Store the keystore file in a secured folder, preferably within the Tomcat folder path.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000510: DefaultServlet debug parameter must be disabled.
From the Tomcat server run the following OS command: sudo cat $CATALINA_BASE/conf/web.xml |grep -i -A10 -B2 defaultservlet The above command will include ten lines after and two lines before the occurrence of "defaultservlet". Some systems may require that the user increase the after number (A10) in order to determine the "debug" param-value. If the "debug" param-value for the "DefaultServlet" servlet class does not = 0, this is a finding.
Discussion
The DefaultServlet serves static resources as well as serves the directory listings (if directory listings are enabled). It is declared globally in $CATALINA_BASE/conf/web.xml and by default is configured with the "debug" parameter set to 0, which is disabled. Changing this to a value of 1 or higher sets the servlet to print debug level information. DefaultServlet debug setting must be set to 0 (disabled).
Fix
From the Tomcat server as a privileged user: Edit the $CATALINA_HOME/conf/web.xml file. Examine the <init-param> elements within the <Servletclass> element, if the "debug" <param-value>element is not "0"" change the "debug" <param-value> to read "0". sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000810: Idle timeout for management application must be set to 10 minutes.
If the manager application has been deleted from the system, this is not a finding. From the Tomcat server as a privileged user, run the following commands: sudo grep -i session-timeout $CATALINA_HOME/webapps/manager/META-INF/web.xml sudo grep -i session-timeout $CATALINA_HOME/conf/web.xml If the session-timeout setting is not configured to be 10 minutes in at least one of these files, this is a finding.
Discussion
Tomcat can set idle session timeouts on a per application basis. The management application is provided with the Tomcat installation and is used to manage the applications that are installed on the Tomcat Server. Setting the idle timeout for the management application will kill the admin user's session after 10 minutes of inactivity. This will limit the opportunity for unauthorized persons to hijack the admin session. This setting will also affect the default timeout behavior of all hosted web applications. To adjust the individual hosted application settings that are not related to management of the system, modify the individual application web.xml file if application timeout requirements differ from the STIG.
Fix
If the manager application has been deleted from the system, this is not a finding. From the Tomcat server as a privileged user: To affect session timeout for all applications including the management application, edit the $CATALINA_HOME/conf/web.xml file. To affect session timeout for the management application only, edit the $CATALINA_HOME/webapps/manager/META-INF/web.xml file. Locate the session-timeout setting located within the session-config element. Modify the session-timeout setting to be 10 minutes. Save the file. sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001080: Application user name must be logged.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review all <Valve> elements. If the pattern= statement does notinclude %u, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
The access logfile format is defined within a Valve that implements the org.apache.catalina.valves.AccessLogValve interface within the /opt/tomcat/server.xml configuration file: The %u pattern code is included in the pattern element and logs the username used to authenticate to an application. Including the username pattern in the log configuration provides useful information about the application user who is logging in, which is critical for troubleshooting and forensic investigations.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Modify the <Valve> element that is nested beneath the <Host> element. Change the AccessLogValve setting to include %u in the pattern= statement. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001690: ENFORCE_ENCODING_IN_GET_WRITER must be set to true.
From the Tomcat server as a privileged user, run the following command: sudo grep -i enforce_encoding /etc/systemd/system/tomcat.service If there are no results, or if the org.apache.catalina.connector.response.ENFORCE_ENCODING_IN_GET_WRITER is not enabled, this is a finding.
Discussion
Some clients try to guess the character encoding of text media when the mandated default of ISO-8859-1 should be used. Some browsers will interpret as UTF-7 when the characters are safe for ISO-8859-1. This can create the potential for a XSS attack. To defend against this, enforce_encoding_in_get_writer must be set to true.
Fix
From the Tomcat server as a privileged user: Edit the /etc/systemd/system/tomcat.service file, and either add or edit the org.apache.catalina.connector.response.ENFORCE_ENCODING_IN_GET_WRITER setting. Set the org.apache.catalina.connector.response.ENFORCE_ENCODING_IN_GET_WRITER=true EXAMPLE: Environment='CATALINA_OPTS -Dorg.apache.catalina.connector.response.ENFORCE_ENCODING_IN_GET_WRITER=true' Restart the Tomcat server. sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000080: Cookies must have http-only flag set.
From the Tomcat server console, run the following command: sudo grep -i -B10 -A1 \/cookie-config $CATALINA_HOME/conf/web.xml If the command returns no results or if the <http-only> element is not set to true, this is a finding. EXAMPLE: <session-config> <session-timeout>15</session-timeout> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config>
Discussion
It is possible to steal or manipulate web application session and cookies without having a secure cookie. Configuring the secure flag injects the setting into the response header. The $CATALINA_HOME/conf/web.xml file controls how all applications handle cookies via the element. false
Fix
From the Tomcat server console as a privileged user: Edit the $CATALINA_HOME/conf/web.xml. If the cookie-config section does not exist it must be added. Add or modify the <http-only> setting and set to true. EXAMPLE: <session-config> <session-timeout>15</session-timeout> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config>
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000840: Secured connectors must use FIPS 140-2-validated cipher algorithms.
From the Tomcat server console, run the following command: sudo grep -i fipsmode $CATALINA_HOME/conf/server.xml. If there are no results displayed or if FIPSMode is not set to FIPSMode="on", this is a finding.
Discussion
The HTTP protocol is not session oriented so application servers will use session IDs to track application user sessions. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.
Fix
From the Tomcat server as a privileged user: sudo nano $CATALINA_HOME/conf/server.xml. In the <Listener/> element, locate the AprLifecycleListener, either add or modify the FIPSMode setting and set it to FIPSMode="on". EXAMPLE: <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" FIPSMode="on" /> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000700: DoD root CA certificates must be installed in Tomcat trust store.
For the systemd Ubuntu OS, check the tomcat.service file to read the content of the JAVA_OPTS environment variable setting. sudo cat /etc/systemd/system/tomcat.service |grep -i truststore EXAMPLE output: set JAVA_OPTS="-Djavax.net.ssl.trustStore=/path/to/truststore" "-Djavax.net.ssl.trustStorePassword=************" If the variable is not set, use the default location command below. If the variable is set, use the alternate location command below and include the path and truststore file. -Default location: keytool -list -cacerts -v | grep -i issuer -Alternate location: keytool -list -keystore <location of trust store file> -v |grep -i issuer If there are no CA certificates issued by a Certificate Authority (CA) that is part of the DoD PKI/PKE, this is a finding.
Discussion
Tomcat truststores are used to validate client certificates. On the Ubuntu OS, by default Tomcat uses the "cacerts" file as the CA trust store. The file is located in the /etc/ssl/certs/java/ folder with a link to the file in $JAVA_HOME/lib/security/cacerts. However, this location can be modified by setting the value of the javax.net.ssl.trustStore system property. Setting this property within an OS environment variable will change the location to point to a different trust store. The Java OS environment variables in the systemd Tomcat startup file must be checked in order to identify the location of the trust store on the file system. (The STIG uses the name tomcat.service as a reference, but technically this file can be called anything). If the property is not set, then the default location is used for the truststore.
Fix
Obtain and install the DoD PKI CA certificate bundles by accessing the DoD PKI office web site at cyber.mil/pki-pke. Import the DoD CA certificates.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000480: Diagnostic tracing must be disabled.
From the Tomcat server run the following OS command: sudo cat $CATALINA_HOME/conf/server.xml | grep -i connector Review each connector element, ensure each connector does not have an "allowTrace" setting or ensure the "allowTrace" setting is set to false. <Connector ... allowTrace="false" /> Do the same for each application by checking every $CATALINA_HOME/webapps/<APP_NAME>/WEBINF/web.xml file on the system. sudo cat $CATALINA_HOME/webapps/<APP_NAME>/WEBINF/web.xml |grep -i connector If a connector element in the server.xml file or in any of the <APP NAME>/WEBINF/web.xml files contains the "allow Trace = true" statement, this is a finding.
Discussion
HTTP Trace provides debugging and diagnostics information for a given request. Diagnostic information, such as that found in the response to a Trace request, often contains sensitive information that may useful to an attacker. By preventing Tomcat from providing this information, the risk of leaking sensitive information to a potential attacker is reduced. HTTP trace is configured via the connector elements in the server.xml file. Each connector element represents an endpoint on the tomcat server which receives and responds to client requests so each connector on the server must be evaluated for the HTTP trace setting.
Fix
From the Tomcat server as a privileged user, edit the xml files containing the "allow Trace=true" statement. Remove the "allow Trace=true" statement from the affected xml configuration files and restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001596: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review the <Engine> element. Ensure one AccessLog <Valve> element is nested within the Engine element. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined, this is a finding. EXAMPLE: <Engine name="Standalone" ...> ... <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="catalina_access_log" suffix=".txt" pattern="common"/> ... </Engine>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000300: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000690: LDAP authentication must be secured.
From the Tomcat server as a privileged user, run the following commands: sudo grep -i -A8 JNDIRealm $CATALINA_HOME/conf/server.xml If the JNDIRealm connectionURL setting is not configured to use LDAPS, if it does not exist, or is commented out, this is a finding. EXAMPLE: This is an example. Substitute localhost for the LDAP server IP and configure other LDAP-related settings as well. <Realm className="org.apache.catalina.realm.JNDIRealm" connectionURL="ldaps://localhost:686" ... />
Discussion
LDAP does not provide encryption by default. This can lead to authentication credentials being transmitted across network connections in clear text. To address this risk, Tomcat must be configured to use secure LDAP (LDAPS).
Fix
Identify the server IP that is providing LDAP services and configure the Tomcat user roles schema within LDAP. Refer to the manager and host-manager web.xml files for application specific role information that can be used for setting up the roles for those applications. The default location for these files is: $CATALINA_HOME/webapps/<AppName>/WEB-INF/web.xml From the Tomcat server console as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. Locate the <Realm> element in the server.xml file, add a nested <Realm> element using the JNDIRealm className and configure the associated LDAP settings as per the LDAP server connection requirements. EXAMPLE: This is for illustration purposes only. The user must modify the LDAP settings on a case by case basis as per the individual LDAP server and schema. <Realm className="org.apache.catalina.realm.JNDIRealm" connectionURL="ldaps://localhost:686" userPattern="uid={0},ou=people,dc=myunit,dc=mil" roleBase="ou=groups,dc=myunit,dc=mil" roleName="cn" roleSearch="(uniqueMember={0})" />
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-000050: AccessLogValve must be configured for each application context.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple contexts (applications) on one physical server by using the element. This allows the admin to specify audit log settings on a per application basis. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000410: $CATALINA_HOME/bin folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/bin folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions. Note that running Tomcat under Docker can impact how file permissions and user ownership settings are applied. Due to associated Docker configuration complexities, the STIG is scoped for standalone rather than virtual deployments.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/bin
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000500: Unapproved connectors must be disabled.
Review SSP for list of approved connectors and associated TCP/IP ports. Ensure only approved connectors are present. Execute the following command on the Tomcat server to find configured Connectors: $ grep “Connector” $CATALINA_HOME/conf/server.xml Review results and verify all connectors and their associated network ports are approved in the SSP. If connectors are found but are not approved in the SSP, this is a finding.
Discussion
Connectors are how Tomcat receives requests, passes them to hosted web applications, and then sends back the results to the requestor. Tomcat provides HTTP and Apache JServ Protocol (AJP) connectors and makes these protocols available via configured network ports. Unapproved connectors provide open network connections to either of these protocols and puts the system at risk.
Fix
Obtain ISSO approvals for the configured connectors and document in the SSP. Alternatively, edit the $CATALINA_HOME/conf/server.xml file, remove any unapproved connectors, and restart Tomcat by running the command: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001070: $CATALINA_HOME/bin folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/bin folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions. Note that running Tomcat in a Docker environment can impact how file permissions and user ownership settings are applied. Due to associated Docker configuration complexities, the STIG is scoped for standalone rather than virtual Docker deployments.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/bin
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000160: AccessLogValve must be configured for each application context.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple contexts (applications) on one physical server by using the element. This allows the admin to specify audit log settings on a per application basis. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000230: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element must be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001720: Connectors must be approved by the ISSO.
Review the Tomcat servers System Security Plan/server documentation. Access the Tomcat server and review the server.xml file. grep -i "connector port" $CATALINA_HOME/conf/server.xml Compare the active Connectors and their associated IP ports with the Connectors documented and approved in the SSP. If the Connectors that are configured on the Tomcat server are not approved by the ISSO and documented in the SSP, this is a finding.
Discussion
Connectors are how Tomcat receives requests over a network port, passes them to hosted web applications via HTTP or AJP and then sends back the results to the requestor. A port and a protocol are tied to each connector. Only connectors approved by the ISSO must be installed. ISSO review will consist of validating connector protocol as being secure and required in order for the hosted application to operate. The ISSO will ensure that unnecessary or insecure connector protocols are not enabled. The ISSO will provide documented approval for each connector that will be maintained in the System Security Plan (SSP).
Fix
Document and obtain ISSO approval for the Connectors that are configured on the Tomcat server. Retain the information in the SSP and present to the auditor in the event of a CCRI.
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000940: ErrorReportValve showReport must be set to false.
As an elevated user on the Tomcat server run the following command: sudo grep -i ErrorReportValve $CATALINA_HOME\conf\server.xml file. If the "org.apache.catalina.valves.ErrorReportValve" className is not defined, or if showReport is set to "false", this is a finding. EXAMPLE: <Host ...> ... <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false"/> ... </Host>
Discussion
The Error Report Valve is a simple error handler for HTTP status codes that will generate and return HTML error pages. It can also be configured to return pre-defined static HTML pages for specific status codes and/or exception types. Disabling showReport will result in no error message or stack trace being send to the client. This setting can be tailored on a per-application basis within each application specific web.xml.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create or modify the ErrorReportValve <Valve> element nested beneath each <Host> element, define the ErrorReportValve className, and set "showReport=false". EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" /> </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000610: JMX authentication must be secured.
From the Tomcat server run the following command: sudo grep -I jmxremote.authenticate /etc/systemd/system/tomcat.service If the results are blank, this is not a finding. If the results include: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false, this is a finding.
Discussion
Java Management Extensions (JMX) provides the means to remotely manage the Java VM. When enabling the JMX agent for remote monitoring, the user must enable authentication.
Fix
If using JMX for management of the Tomcat server, start the Tomcat server by adding the following command line flags to the systemd startup scripts in /etc/systemd/system/tomcat.service. Environment='CATALINA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=true' sudo systemctl start tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001030: LockOutRealms failureCount attribute must be set to 5 failed logins for admin users.
From the Tomcat server console, run the following command: sudo grep -i LockOutRealm $CATALINA_HOME/conf/server.xml. If there are no results or if the LockOutRealm failureCount setting is not configured to 5, this is a finding.
Discussion
A LockOutRealm adds the ability to lock a user out after multiple failed logins. Setting the failureCount attribute to 5 will lock out a user account after 5 failed attempts. LockOutRealm is an implementation of the Tomcat Realm interface that extends the CombinedRealm to provide user lock out functionality if there are too many failed authentication attempts in a given period of time. A LockOutRealm is created by wrapping around a standard realm such as a JNDI Directory Realm which connects Tomcat to an LDAP Directory. A Catalina container (Engine, Host, or Context) may contain no more than one Realm element (although this one Realm may itself contain multiple nested Realms). In addition, the Realm associated with an Engine or a Host is automatically inherited by lower-level containers unless the lower level container explicitly defines its own Realm. If no Realm is configured for the Engine, an instance of the Null Realm will be configured for the Engine automatically.
Fix
From the Tomcat server console as a privileged user edit the $CATALINA_HOME/conf/server.xml file sudo nano $CATALINA_HOME/conf/server.xml file Locate or add the LockOutRealm element. Set LockOutRealm failureCount="5" EXAMPLE: <Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="5" lockOutTime="600"> ... </Realm>
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001250: $CATALINA_HOME/logs/ folder must be owned by tomcat user, group tomcat.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/logs -follow -maxdepth 0 \( ! -user tomcat -o ! -group tomcat \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/logs folder ownership and group membership is not set to tomcat:tomcat, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/logs -maxdepth 0 \( ! -user tomcat \) | sudo xargs chown tomcat sudo find $CATALINA_HOME/logs -maxdepth 0 \( ! -group tomcat \) | sudo xargs chgrp tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000860: Clusters must operate on a trusted network.
Review System Security Plan (SSP) documentation determine if the Tomcat server is part of an application server cluster. Also identify Tomcat network interfaces and the proxy/load balancer that front-ends the cluster. From the Tomcat server as a privileged user, run the following command: sudo grep -i -A2 -B2 "Cluster" $CATALINA_HOME/conf/server.xml If the <Cluster/> element is commented out, or there are no results returned, this requirement is NA. If a cluster is in use, run the following command as a privileged user: grep -i EncryptInterceptor $CATALINA_HOME/conf/server.xml file. If the Tomcat server is clustered and the EncryptionInterceptor is not in use or if the cluster traffic is not on a private network or VLAN, this is a finding.
Discussion
Operating a Tomcat cluster on an untrusted network creates potential for unauthorized persons to view or manipulate cluster session traffic. When operating a Tomcat cluster, care must be taken to isolate the cluster traffic from untrusted sources. Options include using a private VLAN, VPN, or IPSEC tunnel or by encrypting cluster traffic by using the EncryptInterceptor. The EncryptInterceptor adds encryption to the channel messages carrying session data between Tomcat cluster nodes. Place the element inside either the container or the container. Placing it in the engine means supporting clustering in all virtual hosts of Tomcat and sharing the messaging component. When the user places the inside the element, the cluster will append the host name of each session manager to the manager's name so that two contexts with the same name (but sitting inside two different hosts) will be distinguishable. false
Fix
Update the System Security Plan (SSP) and document the network interfaces, their related IP addresses, and which interfaces transport Tomcat cluster traffic. Also document which interface is multi-cast enabled if using the McastService membership class versus Static. To obtain the information needed for the SSP: sudo grep -i -A3 "<Membership className" $CATALINA_HOME/conf.server.xml Document the address="<ipAddress>" value. Review the OS routing tables. Identify and document which interface is configured to route the Tomcat class D IP multicast traffic. sudo netstat -r END of Documentation instructions. From the Tomcat server as a privileged user, edit the $CATALINA_HOME/conf/server.xml file. sudo nano $CATALINA_HOME/conf/server.xml Locate the <Interceptor/> element nested within the <Channel/> element. Add the <Interceptor className="org.apache.catalina.tribes.group. interceptors.EncryptInterceptor"/> to the server.xml and save the file. Restart the Tomcat server: sudo systemctl restart tomcat NOTE: The EncryptInterceptor adds encryption to the channel messages carrying session data between nodes. This feature was added in Tomcat 9.0.13. If using the TcpFailureDetector interceptor, the EncryptInterceptor must be inserted into the interceptor chain BEFORE the TcpFailureDetector. When validating cluster members, TcpFailureDetector writes channel data directly to the other members without using the remainder of the interceptor chain, but on the receiving side, the message still goes through the chain (in reverse). Because of this asymmetry, the EncryptInterceptor must execute before the TcpFailureDetector on the sender and after it on the receiver, otherwise message corruption will occur.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001580: AccessLogValve must be configured per each virtual host.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple virtual hosts on one physical server by using the container attribute. This allows the admin to separate hosted applications according to the domain where the application will be available. Configuring logs on a per-host basis allows for log management that correlates to the virtual host activity. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000520: DefaultServlet directory listings parameter must be disabled.
From the Tomcat server run the following OS command: sudo cat $CATALINA_HOME/conf/web.xml |grep -i -A10 -B2 defaultservlet The above command will include ten lines after and two lines before the occurrence of "defaultservlet". Some systems may require that the user increase the after number (A10) in order to determine the "listings" param-value. If the "listings" param-value for the "DefaultServlet" servlet class does not = "false", this is a finding.
Discussion
The DefaultServlet serves static resources as well as directory listings. It is declared globally in $CATALINA_BASE/conf/web.xml and by default is configured with the directory "listings" parameter set to disabled. If no welcome file is present and the "listings" setting is enabled, a directory listing is shown. Directory listings must be disabled.
Fix
From the Tomcat server as a privileged user: Edit the $CATALINA_HOME/conf/web.xml file. Examine the <init-param> elements within the <Servletclass> element, if the "listings" <param-value>element is "true" change the "listings" <param-value> to read "false". sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001280: $CATALINA_HOME/work/ folder must be owned by tomcat user, group tomcat.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/work -follow -maxdepth 0 \( ! -user tomcat -o ! -group tomcat \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/work folder ownership and group membership is not set to tomcat:tomcat, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/work -maxdepth 0 \( ! -user tomcat \) | sudo xargs chown tomcat sudo find $CATALINA_HOME/work -maxdepth 0 \( ! -group tomcat \) | sudo xargs chgrp tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000560: Example applications must be removed.
From the Tomcat server OS type the following command: sudo ls -l $CATALINA_HOME/webapps/examples. If the examples folder exists or contains any content, this is a finding.
Discussion
Tomcat provides example applications, documentation, and other directories in the default installation which do not serve a production use. These files must be deleted.
Fix
From the Tomcat server OS type the following command: sudo rm -rf $CATALINA_HOME/webapps/examples
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000040: TLS 1.2 must be used on secured HTTP connectors.
From the Tomcat server console, run the following command: sudo cat $CATALINA_HOME/conf/server.xml. Examine each <Connector> </Connector> statement. For every HTTP protocol connector: Verify the SSLEnabledProtocols="TLSv1.2" flag is set on each connector. If the SSLEnabledProtocols setting is not set to TLSv1.2 or greater, this is a finding.
Discussion
Using older versions of TLS introduces security vulnerabilities that exist in the older versions of the protocol. Tomcat by default will use all available versions of the SSL/TLS protocols unless the version is explicitly defined in the SSL configuration attribute for the associated connector. This introduces the opportunity for the client to negotiate the use of an older protocol version and increases the risk of compromise of the Tomcat server. All connectors must use TLS 1.2.
Fix
As a privileged user on the Tomcat server, edit the $CATALINA_HOME/conf/server.xml and modify the <Connector> …</Connector> element. Add the "SSLEnabledProtocols=" flag to the connector or modify the existing flag. Set SSLEnabledProtocols="TLS1.2". Save the server.xml file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl reload-daemon
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000950: Tomcat server version must not be sent with warnings and errors.
From the Tomcat server, cd to the $CATALINA_HOME/lib folder. As a privileged user run the following case-sensitive command: sudo jar -xf catalina.jar org/apache/catalina/util/ServerInfo.properties Check the ServerInfo.properties file. sudo grep -i server org/apache/catalina/util/ServerInfo.properties If server.info=Apache Tomcat or server.number=the actual Tomcat version, this is a finding.
Discussion
Remove version string from HTTP error messages by repacking CATALINA_HOME/server/lib/catalina.jar with an updated ServerInfo.properties file. This will modify the server information that is provided in error and warning responses.
Fix
From the Tomcat server, cd to the $CATALINA_HOME/lib folder. As a privileged user run the following case-sensitive command: sudo jar -xf catalina.jar org/apache/catalina/util/ServerInfo.properties Edit the ServerInfo.properties file. sudo nano org/apache/catalina/util/ServerInfo.properties Change server.info and server.number to read: server.info=Nunya server.number=1.2.3.4 Save the ServerInfo.properties file. Run the following command to update the catalina.jar file: sudo jar -uf catalina.jar org/apache/catalina/util/ServerInfo.properties Restart the Tomcat server: sudo systemctl restart tomcat sudo rm -rf opt/
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000240: Date and time of events must be logged.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review all <Valve> elements. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> If the pattern= statement does notinclude %t, this is a finding.
Discussion
The access logfile format is defined within a Valve that implements the org.apache.catalina.valves.AccessLogValve interface within the /opt/tomcat/server.xml configuration file: The %t pattern code is included in the pattern element and logs the date and time of the event. Including the date pattern in the log configuration provides useful information about the time of the event which is critical for troubleshooting and forensic investigations.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Modify the <Valve> element(s) nested within the <Host> element(s). Change the AccessLogValve setting to include %t in the pattern= statement. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001260: $CATALINA_HOME/temp/ folder must be owned by tomcat user, group tomcat.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/temp -follow -maxdepth 0 \( ! -user tomcat -o ! -group tomcat \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/temp folder ownership and group membership is not set to tomcat:tomcat, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/temp -maxdepth 0 \( ! -user tomcat \) | sudo xargs chown tomcat sudo find $CATALINA_HOME/temp -maxdepth 0 \( ! -group tomcat \) | sudo xargs chgrp tomcat
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000070: Cookies must have secure flag set.
From the Tomcat server console, run the following command: sudo grep -i -B10 -A1 \/cookie-config $CATALINA_HOME/conf/web.xml If the command returns no results or if the <secure> element is not set to true, this is a finding. EXAMPLE: <session-config> <session-timeout>15</session-timeout> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config>
Discussion
It is possible to steal or manipulate web application session and cookies without having a secure cookie. Configuring the secure flag injects the setting into the response header. The $CATALINA_HOME/conf/web.xml file controls how all applications handle cookies via the element. false
Fix
From the Tomcat server console as a privileged user: Edit the $CATALINA_HOME/conf/web.xml. If the cookie-config section does not exist it must be added. Add or modify the <secure> setting and set to true. EXAMPLE: <session-config> <session-timeout>15</session-timeout> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config>
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000090: DefaultServlet must be set to readonly for PUT and DELETE.
From the Tomcat server run the following command: sudo cat $CATALINA_HOME/conf/web.xml |grep -i -A5 -B2 defaultservlet If the "readonly" param-value does not exist, this is not a finding. If the "readonly" param-value for the "DefaultServlet" servlet class = "false", this is a finding.
Discussion
The Default servlet (or DefaultServlet) is a special servlet provided with Tomcat, which is called when no other suitable page is found in a particular folder. The DefaultServlet serves static resources as well as directory listings. The DefaultServlet is declared globally in $CATALINA_BASE/conf/web.xml and by default is configured with the "readonly" parameter set to true where HTTP commands like PUT and DELETE are rejected. Changing this to false allows clients to delete or modify static resources on the server and to upload new resources. DefaultServlet readonly must be set to true.
Fix
From the Tomcat server console as a privileged user: Edit the $CATALINA_HOME/conf/web.xml file. If the "readonly" param-value does not exist, it must be created. Change the "readonly" param-value for the "DefaultServlet" servlet class = "true".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000250: Remote hostname must be logged.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review all <Valve> elements. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> If the pattern= statement does notinclude %h, this is a finding.
Discussion
The access logfile format is defined within a Valve that implements the org.apache.catalina.valves.AccessLogValve interface within the /opt/tomcat/server.xml configuration file: The %h pattern code is included in the pattern element and logs the remote hostname. Including the hostname pattern in the log configuration provides useful information about the connecting host that is critical for troubleshooting and forensic investigations.
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Modify the <Valve> element(s) nested within the <Host> element(s). Change the AccessLogValve setting to include %h in the pattern= statement. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000310: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000820: Tomcat must be configured to generate session IDs using a FIPS 140-2 approved random number generator.
From the Tomcat server as a privileged user, run the following command: sudo grep -i recycle_facades /etc/systemd/system/tomcat.service If there are no results, or if the org.apache.catalina.connector. RECYCLE_FACADES is not configured to load at startup, this is a finding.
Discussion
If RECYCLE_FACADES is true or if a security manager is in use, a new facade object will be created for each request. This reduces the chances that a bug in an application might expose data from one request to another. This setting is configured using environment variable settings. For Linux OS flavors other than Ubuntu, use the relevant OS commands. For Ubuntu, this setting can be managed in the /etc/systemd/system/tomcat.service file via the CATALINA_OPTS variable. This setting is defined in the file and referenced during tomcat startup in order to load tomcat environment variables. Technically, the tomcat.service referenced in the check and fix could be called a different name; but for STIG purposes and to provide a standard setting that can be referred to and obviously is used for Tomcat, tomcat.service was chosen.
Fix
From the Tomcat server as a privileged user: edit the /etc/systemd/system/tomcat.service file and either add or edit the org.apache.catalina.connector. RECYCLE_FACADES setting. Set the org.apache.catalina.connector. RECYCLE_FACADES=true. EXAMPLE: Environment='CATALINA_OPTS -Dorg.apache.catalina.connector. RECYCLE_FACADES=true' Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000220: AccessLogValve must be configured per each virtual host.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined for each <Host> element, this is a finding. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host>
Discussion
Tomcat has the ability to host multiple virtual hosts on one physical server by using the element. This allows the admin to separate hosted applications according to where the domain the application will be available. Configuring logs on a per-host basis allows for log management that correlates to the virtual host activity. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME/conf/server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001592: Changes to $CATALINA_HOME/conf/ folder must be logged.
Run the following commands From the Tomcat server as a privileged user: Identify the home folder for the Tomcat server. sudo grep -i -- 'catalina_home\|catalina_base' /etc/systemd/system/tomcat.service Check the audit rules for the Tomcat folders. sudo auditctl -l $CATALINA_HOME/bin |grep -i conf If the results do not include -w $CATALINA_HOME/conf -p wa -k tomcat, or if there are no results, this is a finding.
Discussion
The $CATALINA_HOME/conf folder contains configuration files for the Tomcat Catalina server. To provide forensic evidence in the event of file tampering, changes to contents in this folder must be logged. For Linux OS flavors other than Ubuntu, use the relevant OS commands. This can be done on the Ubuntu OS via the auditctl command. Using the -p wa flag set the permissions flag for a file system watch and logs file attribute and content change events into syslog.
Fix
From the Tomcat server as a privileged user, use the auditctl command. sudo auditctl -w $CATALINA_HOME/conf -p wa -k tomcat Validate the audit watch was created. sudo auditctl -l The user should see: -w $CATALINA_HOME/ -p wa -k tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001570: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review the <Engine> element. Ensure one AccessLog <Valve> element is nested within the Engine element. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined, this is a finding. EXAMPLE: <Engine name="Standalone" ...> ... <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="catalina_access_log" suffix=".txt" pattern="common"/> ... </Engine>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001390: Multifactor certificate-based tokens (CAC) must be used when accessing the management interface.
If the manager application has been deleted from the Tomcat server, this is not a finding. From the Tomcat server as a privileged user, issue the following command: sudo grep -i auth-method $CATALINA_HOME/webapps/manager/WEB-INF/web.xml If the <Auth-Method> for the web manager application is not set to CLIENT-CERT, this is a finding.
Discussion
Password authentication does not provide sufficient security control when accessing a management interface. DoD has specified that the CAC will be used when authenticating and passwords will only be used when CAC authentication is not a plausible solution. Tomcat provides the ability to do certificate-based authentication and client authentication, therefore the Tomcat server must be configured to use CAC.
Fix
From the Tomcat server as a privileged user, edit the $CATALINA_HOME/webapps/manager/WEB-INF/web.xml file and modify the auth-method for the manager application security constraint. sudo nano $CATALINA_HOME/webapps/manager/WEB-INF/web.xml Locate <auth-method> contained within the <login-config> section, modify <auth-method> to specify CLIENT-CERT. EXAMPLE: <auth-method>CLIENT-CERT</auth-method> In addition, the connector used for accessing the manager application must be configured to require client authentication by setting clientAuth="true" and the manager application roles must be configured in the LDAP server. Restart the Tomcat server: sudo systemctl restart tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000570: Tomcat default ROOT web application must be removed.
From the Tomcat server OS type the following command: sudo ls -l $CATALINA_HOME/webapps/ROOT Review the index.jsp file also review the RELEASE-NOTES.txt file. Look for content that describes the application as being licensed by the Apache Software Foundation. Check the index.jsp for other verbiage that indicates the application is part of the Tomcat server. Alternatively, use a web browser and access the default web application and make the determination if the web site application in the ROOT folder is provided with the Apache Tomcat server. If the ROOT web application contains Tomcat default application content, this is a finding.
Discussion
The default ROOT web application includes the version of Tomcat that is being used, links to Tomcat documentation, examples, FAQs, and mailing lists. The default ROOT web application must be removed from a publicly accessible Tomcat instance and a more appropriate default page shown to users. It is acceptable to replace the contents of default ROOT with a new default web application.
Fix
From the Tomcat server OS: Either remove the files contained in $CATALINA_HOME/webapps/ROOT folder or replace the content of the folder with a new application that serves as the new default server application.
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-001560: AccessLogValve must be configured for Catalina engine.
As an elevated user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Review the <Engine> element. Ensure one AccessLog <Valve> element is nested within the Engine element. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not defined, this is a finding. EXAMPLE: <Engine name="Standalone" ...> ... <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="catalina_access_log" suffix=".txt" pattern="common"/> ... </Engine>
Discussion
The container represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for transmission back to the client. The AccessLogValve will log activity for the Catalina service. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with the Service. false
Fix
As a privileged user on the Tomcat server: Edit the $CATALINA_HOME\conf\server.xml file. Create a <Valve> element that is nested beneath the <Host> element containing an AccessLogValve. EXAMPLE: <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> ... <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %t %u "%r" %s %b" /> ... </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001460: The application server, when categorized as a high availability system within RMF, must be in a high-availability (HA) cluster.
This requirement only applies to a system that is categorized as high within the Risk Management Framework (RMF). Review the System Security Plan (SSP) or other system documentation that specifies the operational uptime requirements and RMF system categorization. If the system is categorized as high, from the Tomcat server as a privileged user, run the following command: sudo grep -i -A10 -B2 "Cluster" $CATALINA_HOME/conf/server.xml If the <Cluster/> element is commented out, or no results returned, then the system is not clustered and this is a finding.
Discussion
A MAC I system is a system that handles data vital to the organization's operational readiness or effectiveness of deployed or contingency forces. A MAC I system must maintain the highest level of integrity and availability. By HA clustering the application server, the hosted application and data are given a platform that is load-balanced and provided high-availability.
Fix
From the Tomcat server as a privileged user, modify the $CATALINA_HOME/conf/server.xml file. Uncomment the "<Cluster/> object and configure the system into a cluster as per the Tomcat clustering documentation provided at the Tomcat web site. https://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001590: Changes to $CATALINA_HOME/bin/ folder must be logged.
Run the following commands From the Tomcat server as a privileged user: Identify the home folder for the Tomcat server. sudo grep -i -- 'catalina_home\|catalina_base' /etc/systemd/system/tomcat.service Check the audit rules for the Tomcat folders. sudo auditctl -l $CATALINA_HOME/bin |grep -i bin If the results do not include -w $CATALINA_HOME/bin -p wa -k tomcat, or if there are no results, this is a finding.
Discussion
The $CATALINA_HOME/bin folder contains startup and control scripts for the Tomcat Catalina server. To provide forensic evidence in the event of file tampering, changes to content in this folder must be logged. For Linux OS flavors other than Ubuntu, use the relevant OS commands. This can be done on the Ubuntu OS via the auditctl command. Using the -p wa flag set the permissions flag for a file system watch and logs file attribute and content change events into syslog.
Fix
From the Tomcat server as a privileged user, use the auditctl command. sudo auditctl -w $CATALINA_HOME/bin -p wa -k tomcat Validate the audit watch was created. sudo auditctl -l The user should see: -w $CATALINA_HOME/ -p wa -k tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001270: $CATALINA_HOME/temp folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/temp -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/temp folder permissions are not set to 750, this is a finding.
Discussion
Tomcat's file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with the group Tomcat. While root has read/write privileges, tomcat group only has read and world has no permissions. The exceptions are the logs, temp and work directory that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.
Fix
Run the following commands on the Tomcat server: sudo find $CATALINA_HOME/temp -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/temp
Rating Info
DISA Cat III. NIST impact 2.
Expert Comment
None
TCAT-AS-000630: SSL must be enabled on JMX.
JMX management is configured via the Tomcat CATALINA_OPTS environment variable setting maintained in the /etc/systemd/system/tomcat.service file for Ubuntu systemd UNIX. For other flavors of Linux, this location may vary. As a privileged user from the Tomcat server run the following command: grep -i jmxremote /etc/systemd/system/tomcat.service Review output, if there are no results displayed, jmxremote management extensions are not used, and this requirement is NA. If the JMXremote setting is configured and jmxremote.ssl="false, this is a finding. EXAMPLE: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
Discussion
Java Management Extensions (JMX) provides the means for enterprises to remotely manage the Java VM and can be used in place of the local manager application that comes with Tomcat. JMX management is configured via the Tomcat CATALINA_OPTS setting maintained in the /etc/systemd/system/tomcat.service file for Ubuntu systemd UNIX. For Linux OS flavors other than Ubuntu, use the relevant OS commands. Management tasks such as monitoring and control of applications is accomplished via the jmxremote servlet. If authentication is disabled, an attacker only needs to know the port number in order to manage and control hosted Java applications.
Fix
If using JMX for management of the Tomcat server, start the Tomcat server by adding the following command line flags to the systemd startup scripts in /etc/systemd/system/tomcat.service. Environment='CATALINA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=true' sudo systemctl start tomcat sudo systemctl daemon-reload
Rating Info
DISA Cat I. NIST impact 4.
Expert Comment
None
TCAT-AS-001594: Changes to $CATALINA_HOME/lib/ folder must be logged.
Run the following commands From the Tomcat server as a privileged user: Identify the home folder for the Tomcat server. sudo grep -i -- 'catalina_home\|catalina_base' /etc/systemd/system/tomcat.service Check the audit rules for the Tomcat folders sudo auditctl -l $CATALINA_HOME/bin |grep -i lib If the results do not include -w $CATALINA_HOME/lib -p wa -k tomcat, or if there are no results, this is a finding.
Discussion
The $CATALINA_HOME/lib folder contains library files for the Tomcat Catalina server. These are in the form of java archive (jar) files. To provide forensic evidence in the event of file tampering, changes to contents in this folder must be logged. For Linux OS flavors other than Ubuntu, use the relevant OS commands. This can be done on the Ubuntu OS via the auditctl command. Using the -p wa flag set the permissions flag for a file system watch and logs file attribute and content change events into syslog.
Fix
From the Tomcat server as a privileged user, use the auditctl command. sudo auditctl -w $CATALINA_HOME/lib -p wa -k tomcat Validate the audit watch was created. sudo auditctl -l The user should see: -w $CATALINA_HOME/ -p wa -k tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-001050: Tomcat user account must be set to nologin.
From the command line of the Tomcat server type the following command: sudo cat /etc/passwd|grep -i tomcat If the command/shell field of the passwd file is not set to "/usr/sbin/nologin", this is a finding.
Discussion
When installing Tomcat, a user account is created on the OS. This account is used in order for Tomcat to be able to operate on the OS but does not require the ability to actually log in to the system. Therefore when the account is created, the account must not be provided access to a login shell or other program on the system. This is done by specifying the "nologin" parameter in the command/shell field of the passwd file.
Fix
From the Tomcat command line type the following command: sudo usermod -s /usr/sbin/nologin tomcat
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
TCAT-AS-000400: $CATALINA_HOME/bin folder permissions must be set to 750.
Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d \( \! -perm 750 \) -ls If no folders are displayed, this is not a finding. If results indicate the $CATALINA_HOME/bin folder permissions are not set to 750, this is a finding.
Discussion
Tomcat file permissions must be restricted. The standard configuration is to have all Tomcat files owned by root with group Tomcat. While root has read/write privileges, group only has read permissions, and world has no permissions. The exceptions are the logs, temp, and work directories that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they cannot change the Tomcat configuration, deploy new web applications, or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions. Note that running Tomcat in a Docker environment can impact how file permissions and user ownership settings are applied. Due to associated Docker configuration complexities, the STIG is scoped for standalone rather than virtual Docker deployments.
Fix
Run the following command on the Tomcat server: sudo find $CATALINA_HOME/bin -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_HOME/bin
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None