Apache Tomcat Application Sever 9 Security Technical Implementation Guide

Version

TCAT-AS-000070

Vuln IDs

V-222932
V-102447

Rule IDs

SV-222932r615938_rule
SV-111395

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_BASE/conf/web.xml file controls how all applications handle cookies via the element.

Checks: C-24604r426240_chk

From the Tomcat server console, run the following command: sudo grep -i -B10 -A1 \/cookie-config $CATALINA_BASE/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>

Fix: F-24593r426241_fix

From the Tomcat server console as a privileged user: edit the $CATALINA_BASE/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>

b

Cookies must have http-only flag set.

AC-3 - Medium - CCI-000213 - V-222933 - SV-222933r615938_rule

RMF Control

AC-3

Severity

M

CCI

Version

TCAT-AS-000080

Vuln IDs

V-222933
V-102449

Rule IDs

SV-222933r615938_rule
SV-111397

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_BASE/conf/web.xml file controls how all applications handle cookies via the element.

Checks: C-24605r426243_chk

From the Tomcat server console, run the following command: sudo grep -i -B10 -A1 \/cookie-config $CATALINA_BASE/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>

Fix: F-24594r426244_fix

From the Tomcat server console as a privileged user: edit the $CATALINA_BASE/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>

b

DefaultServlet must be set to readonly for PUT and DELETE.

AC-3 - Medium - CCI-000213 - V-222934 - SV-222934r615938_rule

RMF Control

AC-3

Severity

M

CCI

Version

TCAT-AS-000090

Vuln IDs

V-222934
V-102451

Rule IDs

SV-222934r615938_rule
SV-111399

The DefaultServlet is a servlet provided with Tomcat. It is called when no other suitable page can be displayed to the client. The DefaultServlet serves static resources as well as directory listings and is declared globally in $CATALINA_BASE/conf/web.xml. By default, Tomcat behaves as if the DefaultServlet is set to "true" (HTTP commands like PUT and DELETE are rejected). However, the readonly parameter is not in the web.xml file by default so to ensure proper configuration and system operation, the "readonly" parameter in web.xml must be created and set to "true". Creating the setting in web.xml provides assurances the system is operating as required. Changing the readonly parameter to false could allow clients to delete or modify static resources on the server and upload new resources.

Checks: C-24606r622485_chk

From the Tomcat server run the following command: sudo cat $CATALINA_BASE/conf/web.xml |grep -i -A5 -B2 defaultservlet If the "readonly" param-value for the "DefaultServlet" servlet class = "false" or does not exist, this is a finding.

Fix: F-24595r622486_fix

From the Tomcat server console as a privileged user: Edit the $CATALINA_BASE/conf/web.xml file. If the "readonly" param-value does not exist, it must be created. Ensure the "readonly" param-value for the "DefaultServlet" servlet class = "true".

b

Connectors must be secured.

AC-3 - Medium - CCI-000213 - V-222935 - SV-222935r615938_rule

RMF Control

AC-3

Severity

M

CCI

Version

TCAT-AS-000100

Vuln IDs

V-222935
V-102453

Rule IDs

SV-222935r615938_rule
SV-111401

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.

Checks: C-24607r426249_chk

From the Tomcat server console, run the following command: sudo cat $CATALINA_BASE/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.

Fix: F-24596r426250_fix

From the Tomcat server as a privileged user, edit the server.xml file. sudo nano $CATALINA_BASE/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

b

The Java Security Manager must be enabled.

AC-3 - Medium - CCI-000213 - V-222936 - SV-222936r615938_rule

RMF Control

AC-3

Severity

M

CCI

Version

TCAT-AS-000110

Vuln IDs

V-222936
V-102455

Rule IDs

SV-222936r615938_rule
SV-111403

The Java Security Manager (JSM) is what protects the Tomcat server from trojan servlets, JSPs, JSP beans, tag libraries, or even from inadvertent mistakes. The JSM works the same way a client's web browser isolates a running web application via a sandbox, the difference being the sandbox is running on the server rather than the client. To ensure application operability, JSM security policies must be set to allow the hosted application access to the underlying system based on individual application requirements. The JSM settings cannot be determined at the STIG level and will vary based on each hosted application. Examples include setting JSM policy to allow an application to write to folders on the server or to initiate network connections to other servers via TCP/IP. Because the JSM isolates application code to prevent an application from adversely accessing resources on the underlying Tomcat server, care must be taken to ensure the JSM policies are configured properly. Allowing untrusted web applications to run on the Tomcat server without a JSM policy that limits access to server resources creates a risk of compromise to the server. Ideally, the JSM policy is implemented and tested during the application development phase. This is when the application resource requirements are best identified and documented so the correct JSM policy can be implemented in the production environment. Creating the correct JSM policy can be a challenge when installing commercial software that does not provide the policy as part of the installation process or via documentation. This is due to the fact that the critical application access requirements to the system will typically not be known to the system administrator. In these cases, running the JSM can result in failure for some application functionality (e.g., an application might not be able to write logs to a particular folder on the system or communicate with other systems as intended). When faced with application functionality failures, the typical troubleshooting approach for the system administrator to follow is to install the application in a test environment, set the $CATALINA_POLICY setting to debug, and identify failure events in the logs. This can aid in identifying what privileges the application requires. From there the JSM policies can be set, tested, documented, and transferred to production. If these actions do not address all of the issues, the Risk Management Framework processes come into effect and a risk acceptance for this requirement must be obtained from the ISSO. For additional technical information on the security manager and available JSM policy settings, refer to the Security Manager How-To on the Apache Tomcat version 9 website.

Checks: C-24608r426252_chk

Review system documentation. Identify the tomcat systemd startup file which for STIG purposes is called "tomcat.service" and can be viewed as a link in the /etc/systemd/system/ folder. Run the following command: sudo cat /etc/systemd/system/tomcat.service |grep -i security If there is a documented and approved risk acceptance for not operating the Security Manager, the finding can be reduced to a CAT III. If the ExecStart parameter does not include the -security flag, this is a finding.

Fix: F-24597r426253_fix

Refer to the vulnerability discussion of this requirement for additional information. Install the application in a test environment and determine the application access requirements. Test and document the Java Security Manager policy and then transfer the JSM policy to the $CATALINA_BASE/conf/catalina.properties file. If operating multiple instances of Tomcat, use $CATALINA_BASE in place of $CATALINA_HOME as per standard Tomcat practice. 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" sudo systemctl restart tomcat sudo systemctl daemon-reload

b

Tomcat servers behind a proxy or load balancer must log client IP.

AU-12 - Medium - CCI-000169 - V-222937 - SV-222937r615938_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000169

Version

TCAT-AS-000170

Vuln IDs

V-222937
V-102457

Rule IDs

SV-222937r615938_rule
SV-111405

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.

Checks: C-24609r426255_chk

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_BASE/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_BASE/conf/server.xml file. If the requestAttributesEnabled setting is not configured as "True", this is a finding.

Fix: F-24598r426256_fix

From the Tomcat server as a privileged user: Edit the $CATALINA_BASE/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

b

AccessLogValve must be configured per each virtual host.

AU-3 - Medium - CCI-000130 - V-222938 - SV-222938r615938_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

TCAT-AS-000180

Vuln IDs

V-222938
V-102603

Rule IDs

SV-222938r615938_rule
SV-111549

Application servers utilize role-based access controls in order to specify the individuals who are allowed to configure application component loggable events. The application server must be configured to select which personnel are assigned the role of selecting which loggable events are to be logged. Satisfies: SRG-APP-000090-AS-000051, SRG-APP-000095-AS-000056, SRG-APP-000100-AS-000063, SRG-APP-000101-AS-000072, SRG-APP-000503-AS-000228, SRG-APP-000505-AS-000230, SRG-APP-000506-AS-000231

Checks: C-24610r426258_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/conf/server.xml file. Review for all <Host> elements. If a <Valve className="org.apache.catalina.valves.AccessLogValve" .../> element is not nested within 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 &quot;%r&quot; %s %b" /> ... </Host>

Fix: F-24599r426259_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

b

Date and time of events must be logged.

AU-3 - Medium - CCI-000131 - V-222939 - SV-222939r615938_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000131

Version

TCAT-AS-000240

Vuln IDs

V-222939
V-102461

Rule IDs

SV-222939r615938_rule
SV-111407

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.

Checks: C-24611r426261_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/conf/server.xml file. Review all "Valve" elements. If the pattern= statement does not include %t, 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 &quot;%r&quot; %s %b" /> ... </Host>

Fix: F-24600r426262_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

b

Remote hostname must be logged.

AU-3 - Medium - CCI-000132 - V-222940 - SV-222940r615938_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000132

Version

TCAT-AS-000250

Vuln IDs

V-222940
V-102463

Rule IDs

SV-222940r615938_rule
SV-111409

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.

Checks: C-24612r426264_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/conf/server.xml file. Review all "Valve" elements. If the pattern= statement does not include %h, 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 &quot;%r&quot; %s %b" /> ... </Host>

Fix: F-24601r426265_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

a

HTTP status code must be logged.

AU-3 - Low - CCI-000132 - V-222941 - SV-222941r615938_rule

RMF Control

AU-3

Severity

L

CCI

CCI-000132

Version

TCAT-AS-000260

Vuln IDs

V-222941
V-102465

Rule IDs

SV-222941r615938_rule
SV-111411

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.

Checks: C-24613r426267_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/conf/server.xml file. Review all "Valve" elements. If the pattern= statement does not include %s, 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 &quot;%r&quot; %s %b" /> ... </Host>

Fix: F-24602r426268_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

b

The first line of request must be logged.

AU-3 - Medium - CCI-000132 - V-222942 - SV-222942r615938_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000132

Version

TCAT-AS-000270

Vuln IDs

V-222942
V-102467

Rule IDs

SV-222942r615938_rule
SV-111413

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.

Checks: C-24614r426270_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/conf/server.xml file. Review all "Valve" elements. If the pattern= statement does not include &quot;%r&quot;, 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 &quot;%r&quot; %s %b" /> ... </Host>

Fix: F-24603r426271_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

b

$CATALINA_BASE/logs folder permissions must be set to 750.

AU-9 - Medium - CCI-000162 - V-222943 - SV-222943r615938_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000162

Version

TCAT-AS-000360

Vuln IDs

V-222943
V-102469

Rule IDs

SV-222943r615938_rule
SV-111415

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 0027 to maintain these permissions.

Checks: C-24615r426273_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/logs -follow -maxdepth 0 -type d $ \! -perm 750 $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/logs folder permissions are not set to 750, this is a finding.

Fix: F-24604r426274_fix

If operational/application requirements specify different file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following command on the Tomcat server: sudo find $CATALINA_BASE/logs -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_BASE/logs

b

Files in the $CATALINA_BASE/logs/ folder must have their permissions set to 640.

AU-9 - Medium - CCI-000162 - V-222944 - SV-222944r615938_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000162

Version

TCAT-AS-000361

Vuln IDs

V-222944
V-102471

Rule IDs

SV-222944r615938_rule
SV-111417

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 0027 to maintain these permissions.

Checks: C-24616r426276_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/logs/* -follow -maxdepth 0 -type f $ \! -perm 640 $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no files are displayed, this is not a finding. If results indicate any of the file permissions contained in the $CATALINA_BASE/logs folder are not set to 640, this is a finding.

Fix: F-24605r426277_fix

If operational/application requirements specify different file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following command on the Tomcat server: sudo find $CATALINA_BASE/logs/* -follow -maxdepth 0 -type f -print0 | sudo xargs chmod 640 $CATALINA_BASE/logs/*

b

Files in the $CATALINA_BASE/conf/ folder must have their permissions set to 640.

AU-9 - Medium - CCI-000163 - V-222945 - SV-222945r615938_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000163

Version

TCAT-AS-000370

Vuln IDs

V-222945
V-102473

Rule IDs

SV-222945r615938_rule
SV-111419

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. If the ISSM determines the operational need to allow application admins access to change the Tomcat configuration outweighs the risk of limiting that access, then they can change the group membership to accommodate. Ownership must not be changed. The ISSM should take the exposure of the system to high risk networks into account. Satisfies: SRG-APP-000119-AS-000079, SRG-APP-000380-AS-000088

Checks: C-24617r426279_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/conf/* -follow -maxdepth 0 -type f $ \! -perm 640 $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no files are displayed, this is not a finding. If results indicate any of the file permissions contained in the $CATALINA_BASE/conf folder are not set to 640, this is a finding.

Fix: F-24606r426280_fix

If operational/application requirements specify different file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following command on the Tomcat server: sudo find $CATALINA_BASE/conf/* -follow -maxdepth 0 -type f -print0 | sudo xargs chmod 640 $CATALINA_BASE/conf/*

b

$CATALINA_BASE/conf folder permissions must be set to 750.

AU-9 - Medium - CCI-000163 - V-222946 - SV-222946r754839_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000163

Version

TCAT-AS-000371

Vuln IDs

V-222946
V-102605

Rule IDs

SV-222946r754839_rule
SV-111551

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 0027 to maintain these permissions. If the ISSM determines the operational need to allow application admins access to change the Tomcat configuration outweighs the risk of limiting that access, then they can change the group membership to accommodate. Ownership must not be changed. The ISSM should take the exposure of the system to high risk networks into account. Satisfies: SRG-APP-000119-AS-000079, SRG-APP-000380-AS-000088

Checks: C-24618r426282_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/conf -follow -maxdepth 0 -type d $ \! -perm 750 $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/conf folder permissions are not set to 750, this is a finding.

Fix: F-24607r426283_fix

If operational/application requirements specify different file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following command on the Tomcat server: sudo find $CATALINA_BASE/conf -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_BASE/conf

b

Jar files in the $CATALINA_HOME/bin/ folder must have their permissions set to 640.

AU-9 - Medium - CCI-000164 - V-222947 - SV-222947r754840_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000164

Version

TCAT-AS-000380

Vuln IDs

V-222947
V-102477

Rule IDs

SV-222947r754840_rule
SV-111421

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 0027 to maintain these permissions.

Checks: C-24619r426285_chk

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.

Fix: F-24608r426286_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

b

$CATALINA_HOME/bin folder permissions must be set to 750.

AU-9 - Medium - CCI-001493 - V-222948 - SV-222948r754841_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001493

Version

TCAT-AS-000390

Vuln IDs

V-222948
V-102607

Rule IDs

SV-222948r754841_rule
SV-111553

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 0027 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. Satisfies: SRG-APP-000121-AS-000081, SRG-APP-000122-AS-000082, SRG-APP-000123-AS-000083, SRG-APP-000340-AS-000185

Checks: C-24620r426288_chk

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.

Fix: F-24609r426289_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

b

Tomcat user UMASK must be set to 0027.

CM-5 - Medium - CCI-001499 - V-222949 - SV-222949r615938_rule

RMF Control

CM-5

Severity

M

CCI

CCI-001499

Version

TCAT-AS-000450

Vuln IDs

V-222949
V-102481

Rule IDs

SV-222949r615938_rule
SV-111423

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.

Checks: C-24621r426291_chk

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.

Fix: F-24610r426292_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

b

Stack tracing must be disabled.

CM-7 - Medium - CCI-000381 - V-222950 - SV-222950r615938_rule

RMF Control

CM-7

Severity

M

CCI

Version

TCAT-AS-000470

Vuln IDs

V-222950
V-102483

Rule IDs

SV-222950r615938_rule
SV-111425

Stack tracing provides debugging information from the application call stacks when a runtime error is encountered. If stack tracing is left 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. As with all STIG settings, it is acceptable to temporarily enable for troubleshooting and debugging purposes but the setting must not be left enabled after troubleshooting tasks have been completed.

Checks: C-24622r426294_chk

From the Tomcat server run the following OS command: sudo cat $CATALINA_BASE/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_BASE/webapps/<APP_NAME>/WEBINF/web.xml file on the system. sudo cat $CATALINA_BASE/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.

Fix: F-24611r426295_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

b

The shutdown port must be disabled.

CM-7 - Medium - CCI-000381 - V-222951 - SV-222951r615938_rule

RMF Control

CM-7

Severity

M

CCI

Version

TCAT-AS-000490

Vuln IDs

V-222951
V-102485

Rule IDs

SV-222951r615938_rule
SV-111427

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_BASE/conf/server.xml.

Checks: C-24623r426297_chk

From the Tomcat server run the following OS command: $ sudo grep -i shutdown $CATALINA_BASE/conf/server.xml Ensure the server shutdown port attribute in $CATALINA_BASE/conf/server.xml is set to -1. EXAMPLE: <Server port="-1" shutdown="SHUTDOWN"> If Server port not = "-1" shutdown="SHUTDOWN", this is a finding.

Fix: F-24612r426298_fix

From the Tomcat server as a privileged user, edit the $CATALINA_BASE/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

b

Unapproved connectors must be disabled.

CM-7 - Medium - CCI-000381 - V-222952 - SV-222952r615938_rule

RMF Control

CM-7

Severity

M

CCI

Version

TCAT-AS-000500

Vuln IDs

V-222952
V-102487

Rule IDs

SV-222952r615938_rule
SV-111429

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 put the system at risk.

Checks: C-24624r426300_chk

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_BASE/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.

Fix: F-24613r426301_fix

Obtain ISSO approvals for the configured connectors and document in the SSP. Alternatively, edit the $CATALINA_BASE/conf/server.xml file, remove any unapproved connectors, and restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload

a

DefaultServlet debug parameter must be disabled.

CM-7 - Low - CCI-000381 - V-222953 - SV-222953r615938_rule

RMF Control

CM-7

Severity

L

CCI

Version

TCAT-AS-000510

Vuln IDs

V-222953
V-102489

Rule IDs

SV-222953r615938_rule
SV-111431

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).

Checks: C-24625r426303_chk

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.

Fix: F-24614r426304_fix

From the Tomcat server as a privileged user: Edit the $CATALINA_BASE/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

a

DefaultServlet directory listings parameter must be disabled.

CM-7 - Low - CCI-000381 - V-222954 - SV-222954r615938_rule

RMF Control

CM-7

Severity

L

CCI

Version

TCAT-AS-000520

Vuln IDs

V-222954
V-102491

Rule IDs

SV-222954r615938_rule
SV-111433

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.

Checks: C-24626r426306_chk

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 "listings" param-value. If the "listings" param-value for the "DefaultServlet" servlet class does not = "false", this is a finding.

Fix: F-24615r426307_fix

From the Tomcat server as a privileged user: Edit the $CATALINA_BASE/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

b

The deployXML attribute must be set to false in hosted environments.

CM-7 - Medium - CCI-000381 - V-222955 - SV-222955r615938_rule

RMF Control

CM-7

Severity

M

CCI

Version

TCAT-AS-000530

Vuln IDs

V-222955
V-102493

Rule IDs

SV-222955r615938_rule
SV-111435

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.

Checks: C-24627r426309_chk

If the SSP associated with the Host contains ISSM documented approvals for deployXML, this is not a finding. From the Tomcat server as a privileged user: sudo grep -i deployXML $CATALINA_BASE/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.

Fix: F-24616r426310_fix

Document authorization for application auto deployment in the System Security Plan (SSP). From the Tomcat server as a privileged user, edit the $CATALINA_BASE/conf/server.xml file. sudo nano $CATALINA_BASE/conf/server.xml Locate each <host> element in the server xml file. 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".

b

Autodeploy must be disabled.

CM-7 - Medium - CCI-000381 - V-222956 - SV-222956r615938_rule

RMF Control

CM-7

Severity

M

CCI

Version

TCAT-AS-000540

Vuln IDs

V-222956
V-102495

Rule IDs

SV-222956r615938_rule
SV-111437

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.

Checks: C-24628r426312_chk

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_BASE/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.

Fix: F-24617r426313_fix

From the Tomcat server as a privileged user, edit the $CATALINA_BASE/conf/server.xml file. Examine each <Host> </Host> element, if the element contains autoDeploy="true", modify the statement to read ", autoDeploy="false". sudo systemctl restart tomcat sudo systemctl daemon-reload

a

xpoweredBy attribute must be disabled.

CM-7 - Low - CCI-000381 - V-222957 - SV-222957r615938_rule

RMF Control

CM-7

Severity

L

CCI

Version

TCAT-AS-000550

Vuln IDs

V-222957
V-102497

Rule IDs

SV-222957r615938_rule
SV-111439

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.

Checks: C-24629r426315_chk

From the Tomcat server run the following OS command: sudo cat $CATALINA_BASE/conf/server.xml |grep -i -C4 xpoweredby. If any connector elements contain xpoweredBy="true", this is a finding.

Fix: F-24618r426316_fix

From the Tomcat server as a privileged user, edit the $CATALINA_BASE/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

a

Example applications must be removed.

CM-7 - Low - CCI-000381 - V-222958 - SV-222958r615938_rule

RMF Control

CM-7

Severity

L

CCI

Version

TCAT-AS-000560

Vuln IDs

V-222958
V-102499

Rule IDs

SV-222958r615938_rule
SV-111441

Tomcat provides example applications, documentation, and other directories in the default installation which do not serve a production use. These files must be deleted.

Checks: C-24630r426318_chk

From the Tomcat server OS type the following command: sudo ls -l $CATALINA_BASE/webapps/examples. If the examples folder exists or contains any content, this is a finding.

Fix: F-24619r426319_fix

From the Tomcat server OS type the following command: sudo rm -rf $CATALINA_BASE/webapps/examples

a

Tomcat default ROOT web application must be removed.

CM-7 - Low - CCI-000381 - V-222959 - SV-222959r615938_rule

RMF Control

CM-7

Severity

L

CCI

Version

TCAT-AS-000570

Vuln IDs

V-222959
V-102501

Rule IDs

SV-222959r615938_rule
SV-111443

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. WARNING: Removing the ROOT folder without replacing the content with valid web based content will result in an error page being displayed to the browser when the browser lands on the default page.

Checks: C-24631r426321_chk

From the Tomcat server OS type the following command: sudo ls -l $CATALINA_BASE/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 determine if the website 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.

Fix: F-24620r426322_fix

WARNING: Removing the ROOT folder without replacing the content with valid web based content will result in an error page being displayed to the browser when the browser lands on the default page. From the Tomcat server OS: Either remove the files contained in $CATALINA_BASE/webapps/ROOT folder or replace the content of the folder with a new application that serves as the new default server application.

a

Documentation must be removed.

CM-7 - Low - CCI-000381 - V-222960 - SV-222960r615938_rule

RMF Control

CM-7

Severity

L

CCI

Version

TCAT-AS-000580

Vuln IDs

V-222960
V-102503

Rule IDs

SV-222960r615938_rule
SV-111445

Tomcat provides documentation and other directories in the default installation which do not serve a production use. These files must be deleted.

Checks: C-24632r426324_chk

From the Tomcat server OS type the following command: sudo ls -l $CATALINA_BASE/webapps/docs. If the docs folder exists or contains any content, this is a finding.

Fix: F-24621r426325_fix

From the Tomcat server OS type the following command: sudo rm -rf $CATALINA_BASE/webapps/docs

b

Applications in privileged mode must be approved by the ISSO.

CM-7 - Medium - CCI-000382 - V-222961 - SV-222961r615938_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000382

Version

TCAT-AS-000590

Vuln IDs

V-222961
V-102505

Rule IDs

SV-222961r615938_rule
SV-111447

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.

Checks: C-24633r426327_chk

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_BASE/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_BASE/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_BASE/conf/context.xml Repeat the following command for each installed application: grep -i privileged $CATALINA_BASE/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.

Fix: F-24622r426328_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.

b

Tomcat management applications must use LDAP realm authentication.

IA-2 - Medium - CCI-000764 - V-222962 - SV-222962r615938_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000764

Version

TCAT-AS-000600

Vuln IDs

V-222962
V-102507

Rule IDs

SV-222962r615938_rule
SV-111449

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.

Checks: C-24634r426330_chk

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_BASE/conf/server.xml If the JNDIRealm does not exist or if the JNDIRealm configuration is commented out, this is finding.

Fix: F-24623r426331_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_BASE/webapps/<AppName>/WEB-INF/web.xml From the Tomcat server console as a privileged user, edit the $CATALINA_BASE/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})" />

b

JMX authentication must be secured.

IA-2 - Medium - CCI-000765 - V-222963 - SV-222963r615938_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000765

Version

TCAT-AS-000610

Vuln IDs

V-222963
V-102509

Rule IDs

SV-222963r615938_rule
SV-111451

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.

Checks: C-24635r426333_chk

From the Tomcat server run the following command: sudo grep -I jmxremote.authenticate /etc/systemd/system/tomcat.service sudo ps -ef |grep -i jmxremote If the results are blank, this is not a finding. If the results include: -Dcom.sun.management.jmxremote.authenticate=false, this is a finding.

Fix: F-24624r426334_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

c

TLS must be enabled on JMX.

IA-2 - High - CCI-000770 - V-222964 - SV-222964r615938_rule

RMF Control

IA-2

Severity

H

CCI

CCI-000770

Version

TCAT-AS-000630

Vuln IDs

V-222964
V-102511

Rule IDs

SV-222964r615938_rule
SV-111565

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.

Checks: C-24636r426336_chk

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

Fix: F-24625r426337_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

c

LDAP authentication must be secured.

IA-5 - High - CCI-000197 - V-222965 - SV-222965r615938_rule

RMF Control

IA-5

Severity

H

CCI

CCI-000197

Version

TCAT-AS-000690

Vuln IDs

V-222965
V-102513

Rule IDs

SV-222965r615938_rule
SV-111455

JNDIRealm is an implementation of the Tomcat Realm interface. Tomcat uses the JNDIRealm to look up users in an LDAP directory server. The realm's connection to the directory is defined by the 'connectionURL' configuration attribute. This attribute is usually an LDAP URL that specifies the domain name of the directory server to connect to. The LDAP URL 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).

Checks: C-24637r426339_chk

From the Tomcat server as a privileged user, run the following commands: sudo grep -i -A8 JNDIRealm $CATALINA_BASE/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" ... />

Fix: F-24626r426340_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_BASE/webapps/<AppName>/WEB-INF/web.xml From the Tomcat server console as a privileged user, edit the $CATALINA_BASE/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 your 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})" />

b

DoD root CA certificates must be installed in Tomcat trust store.

IA-5 - Medium - CCI-000185 - V-222966 - SV-222966r616155_rule

RMF Control

IA-5

Severity

M

CCI

CCI-000185

Version

TCAT-AS-000700

Vuln IDs

V-222966
V-102515

Rule IDs

SV-222966r616155_rule
SV-111457

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.

Checks: C-24638r587942_chk

This is a mutual authentication requirement where both the Tomcat server and the client are required to authenticate themselves via mutual TLS. Review system security plan and other system documentation. If the system has no connections requiring mutual authentication (e.g., proxy servers or other hosts specified in the system documentation), this requirement is NA. 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.

Fix: F-24627r426343_fix

Obtain and install the DoD PKI CA certificate bundles by accessing the DoD PKI office website at cyber.mil/pki-pke. Import the DoD CA certificates.

b

Keystore file must be protected.

IA-5 - Medium - CCI-000186 - V-222967 - SV-222967r615938_rule

RMF Control

IA-5

Severity

M

CCI

CCI-000186

Version

TCAT-AS-000710

Vuln IDs

V-222967
V-102517

Rule IDs

SV-222967r615938_rule
SV-111459

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.

Checks: C-24639r426345_chk

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_BASE/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.

Fix: F-24628r426346_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 within the Tomcat folder path.

c

Tomcat must use FIPS-validated ciphers on secured connectors.

IA-7 - High - CCI-000803 - V-222968 - SV-222968r615938_rule

RMF Control

IA-7

Severity

H

CCI

CCI-000803

Version

TCAT-AS-000750

Vuln IDs

V-222968
V-102609

Rule IDs

SV-222968r615938_rule
SV-111567

Connectors are how Tomcat receives requests over a network port, passes them to hosted web applications via HTTP or AJP, and then sends the results back 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. The FIPS-validated crypto libraries are not provided by Tomcat; they are included as part of the Java instance and the underlying Operating System. The STIG checks to ensure the FIPSMode setting is enabled for the connector and also checks the logs for FIPS errors, which indicates FIPS non-compliance at the OS or Java layers. The administrator is responsible for ensuring the OS and Java instance selected for the Tomcat installation provide and enable these FIPS modules so Tomcat can be configured to use them. Satisfies: SRG-APP-000224-AS-000152, SRG-APP-000428-AS-000265, SRG-APP-000429-AS-000157, SRG-APP-000439-AS-000274, SRG-APP-000440-AS-000167

Checks: C-24640r426348_chk

From the Tomcat server console, run the following two commands to verify Tomcat server is configured to use FIPS: sudo grep -i fipsmode $CATALINA_BASE/conf/server.xml sudo grep -i fipsmode $CATALINA_BASE/logs/catalina.out If server.xml does not contain FIPSMode="on", or if catalina.out contains the error "failed to set property[FIPSMODE] to [on]", this is a finding.

Fix: F-24629r426349_fix

In addition to configuring Tomcat, the admin must also configure the underlying OS and Java engine to use FIPS validated encryption modules. This fix instructs how to enable FIPSMode within Tomcat, the OS and Java engine must be configured to use the FIPS validated modules according to the chosen OS and Java engine. From the Tomcat server as a privileged user: sudo nano $CATALINA_BASE/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

b

Access to JMX management interface must be restricted.

SC-2 - Medium - CCI-001082 - V-222969 - SV-222969r615938_rule

RMF Control

SC-2

Severity

M

CCI

CCI-001082

Version

TCAT-AS-000780

Vuln IDs

V-222969
V-102521

Rule IDs

SV-222969r615938_rule
SV-111461

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.

Checks: C-24641r426351_chk

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 sudo ps -ef |grep -i jmxremote 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.

Fix: F-24630r426352_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.

b

Access to Tomcat manager application must be restricted.

SC-2 - Medium - CCI-001082 - V-222970 - SV-222970r615938_rule

RMF Control

SC-2

Severity

M

CCI

CCI-001082

Version

TCAT-AS-000790

Vuln IDs

V-222970
V-102523

Rule IDs

SV-222970r615938_rule
SV-111463

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_BASE/conf/server.xml file.

Checks: C-24642r426354_chk

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_BASE/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/>

Fix: F-24631r426355_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_BASE/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 website 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/>

b

Tomcat servers must mutually authenticate proxy or load balancer connections.

SC-23 - Medium - CCI-001184 - V-222971 - SV-222971r615938_rule

RMF Control

SC-23

Severity

M

CCI

CCI-001184

Version

TCAT-AS-000800

Vuln IDs

V-222971
V-102525

Rule IDs

SV-222971r615938_rule
SV-111465

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. Not all Tomcat systems will have an RMF system categorization that warrants mutual authentication protections. The site must determine if mutual authentication is warranted based on their system RMF categorization and data protection requirements. If the site determines that MA is not a requirement, they can document a risk acceptance for not mutually authenticating proxy or load balancer connections due to operational issues, or when the RMF system categorization does not warrant the added level of protection.

Checks: C-24643r426357_chk

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 or load balancer connections due to operational issues, or RMF system categorization 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_BASE/conf/server.xml file. Review each <Connector> element for the address setting and the clientAuth setting. sudo grep -i -B1 -A5 connector $CATALINA_BASE/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.

Fix: F-24632r426358_fix

From the Tomcat server as a privileged user, edit the $CATALINA_BASE/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.

a

Tomcat must be configured to limit data exposure between applications.

SC-23 - Low - CCI-001664 - V-222973 - SV-222973r615938_rule

RMF Control

SC-23

Severity

L

CCI

CCI-001664

Version

TCAT-AS-000820

Vuln IDs

V-222973
V-102529

Rule IDs

SV-222973r615938_rule
SV-111469

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.

Checks: C-24645r426363_chk

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 ="true", this is a finding.

Fix: F-24634r426364_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

b

Clusters must operate on a trusted network.

SC-24 - Medium - CCI-001190 - V-222974 - SV-222974r615938_rule

RMF Control

SC-24

Severity

M

CCI

CCI-001190

Version

TCAT-AS-000860

Vuln IDs

V-222974
V-102531

Rule IDs

SV-222974r615938_rule
SV-111471

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.

Checks: C-24646r426366_chk

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_BASE/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_BASE/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.

Fix: F-24635r426367_fix

Update the System Security Plan (SSP) and document the network interface, 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_BASE/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_BASE/conf/server.xml file. sudo nano $CATALINA_BASE/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.

b

ErrorReportValve showServerInfo must be set to false.

SI-11 - Medium - CCI-001312 - V-222975 - SV-222975r615938_rule

RMF Control

SI-11

Severity

M

CCI

CCI-001312

Version

TCAT-AS-000920

Vuln IDs

V-222975
V-102533

Rule IDs

SV-222975r615938_rule
SV-111473

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.

Checks: C-24647r426369_chk

As an elevated user on the Tomcat server run the following command: sudo grep -i ErrorReportValve $CATALINA_BASE/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>

Fix: F-24636r426370_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

a

Default error pages for manager application must be customized.

SI-11 - Low - CCI-001314 - V-222976 - SV-222976r615938_rule

RMF Control

SI-11

Severity

L

CCI

CCI-001314

Version

TCAT-AS-000930

Vuln IDs

V-222976
V-102535

Rule IDs

SV-222976r615938_rule
SV-111475

Default error pages that accompany the manager application provide educational information on how to configure user accounts and groups for accessing the manager application. These error pages provide responses to 401 (Unauthorized), 403 (Forbidden), and 404 (Not Found) JSP error codes and should not exist on production systems.

Checks: C-24648r426372_chk

From the Tomcat server console, run the following command: sudo cat $CATALINA_BASE/webapps/manager/WEB-INF/jsp/401.jsp Repeat for the 402.jsp and 403.jsp files. The default error files contain sample passwords and user accounts. If the error files contained in this folder are not customized and sample information removed, this is a finding.

Fix: F-24637r426373_fix

From the Tomcat server as a privileged user: sudo cd $CATALINA_BASE/webapps/manager/WEB-INF/jsp/ Use a file editor like nano or vi and edit the 401, 402, and 403 jsp files. Remove account information and make the files reflect generic error information that assists users but does not provide sample data to users. Save the file and restart Tomcat: sudo systemctl restart tomcat sudo systemctl daemon-reload

b

ErrorReportValve showReport must be set to false.

SI-11 - Medium - CCI-001314 - V-222977 - SV-222977r615938_rule

RMF Control

SI-11

Severity

M

CCI

CCI-001314

Version

TCAT-AS-000940

Vuln IDs

V-222977
V-102537

Rule IDs

SV-222977r615938_rule
SV-111477

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.

Checks: C-24649r426375_chk

As an elevated user on the Tomcat server run the following command: sudo grep -i ErrorReportValve $CATALINA_BASE/conf/server.xml file. If the ErrorReportValve element is not defined and showReport set to "false", this is a finding. EXAMPLE: <Host ...> ... <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false"/> ... </Host>

Fix: F-24638r426376_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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" showReport="false" /> </Host> Restart the Tomcat server: sudo systemctl restart tomcat sudo systemctl daemon-reload

a

Tomcat server version must not be sent with warnings and errors.

SI-11 - Low - CCI-001314 - V-222978 - SV-222978r615938_rule

RMF Control

SI-11

Severity

L

CCI

CCI-001314

Version

TCAT-AS-000950

Vuln IDs

V-222978
V-102539

Rule IDs

SV-222978r615938_rule
SV-111479

A first order of attack is to identify vulnerable servers and services. Removing version information that would otherwise be provided when a client requests version data or receives an error message can limit automated attack attempts. Remove or replace the 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.

Checks: C-24650r426378_chk

From the Tomcat server, cd to the $CATALINA_HOME/bin folder. Run the version.sh command and identify the following information that is provided: Server version: Server built: Server number: EXAMPLE: Server version: Apache Tomcat Server built: July 4 2019 14:20:06 UTC Server number: 9.0.22.0 If additional version information is required, refer to the Apache Tomcat version 9 change log on the Apache Tomcat website for historical version information. Google "Apache Tomcat 9 changelog". If server.info="Apache Tomcat" or server.number=the valid Tomcat version, this is a finding.

Fix: F-24639r426379_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=<Enter Some Random Name or Value> server.number=<Enter Some Random number> EXAMPLE: server.info="Standard Server" server.number=1.0.2.11 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 $CATALINA_HOME/lib/org

b

Idle timeout for management application must be set to 10 minutes.

IA-11 - Medium - CCI-002038 - V-222979 - SV-222979r615938_rule

RMF Control

IA-11

Severity

M

CCI

CCI-002038

Version

TCAT-AS-000970

Vuln IDs

V-222979
V-102541

Rule IDs

SV-222979r615938_rule
SV-111481

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. Satisfies: SRG-APP-000389, SRG-APP-000220

Checks: C-24651r426381_chk

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_BASE/webapps/manager/META-INF/web.xml sudo grep -i session-timeout $CATALINA_BASE/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.

Fix: F-24640r622488_fix

From the Tomcat server as a privileged user: To affect session timeout for all applications including the management application, edit the: $CATALINA_BASE/conf/web.xml file. To affect session timeout for the management application only, edit the: $CATALINA_BASE/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

b

LockOutRealms must be used for management of Tomcat.

AC-17 - Medium - CCI-002314 - V-222980 - SV-222980r615938_rule

RMF Control

AC-17

Severity

M

CCI

CCI-002314

Version

TCAT-AS-001020

Vuln IDs

V-222980
V-102543

Rule IDs

SV-222980r615938_rule
SV-111483

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.

Checks: C-24652r426384_chk

From the Tomcat server console, run the following command: sudo grep -i LockOutRealm $CATALINA_BASE/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.

Fix: F-24641r426385_fix

From the Tomcat server console as a privileged user edit the $CATALINA_BASE/conf/server.xml file. sudo nano $CATALINA_BASE/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>

b

LockOutRealms failureCount attribute must be set to 5 failed logins for admin users.

AC-17 - Medium - CCI-002322 - V-222981 - SV-222981r615938_rule

RMF Control

AC-17

Severity

M

CCI

CCI-002322

Version

TCAT-AS-001030

Vuln IDs

V-222981
V-102545

Rule IDs

SV-222981r615938_rule
SV-111485

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.

Checks: C-24653r426387_chk

From the Tomcat server console, run the following command: sudo grep -i LockOutRealm $CATALINA_BASE/conf/server.xml. If there are no results or if the LockOutRealm failureCount setting is not configured to 5, this is a finding.

Fix: F-24642r426388_fix

From the Tomcat server console as a privileged user edit the $CATALINA_BASE/conf/server.xml file. sudo nano $CATALINA_BASE/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>

a

LockOutRealms lockOutTime attribute must be set to 600 seconds (10 minutes) for admin users.

AC-17 - Low - CCI-002322 - V-222982 - SV-222982r615938_rule

RMF Control

AC-17

Severity

L

CCI

CCI-002322

Version

TCAT-AS-001040

Vuln IDs

V-222982
V-102547

Rule IDs

SV-222982r615938_rule
SV-111487

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.

Checks: C-24654r426390_chk

From the Tomcat server console, run the following command: sudo grep -i LockOutRealm $CATALINA_BASE/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.

Fix: F-24643r426391_fix

From the Tomcat server console as a privileged user, edit the $CATALINA_BASE/conf/server.xml file. sudo nano $CATALINA_BASE/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>

b

Tomcat user account must be set to nologin.

AC-6 - Medium - CCI-002235 - V-222983 - SV-222983r615938_rule

RMF Control

AC-6

Severity

M

CCI

CCI-002235

Version

TCAT-AS-001050

Vuln IDs

V-222983
V-102549

Rule IDs

SV-222983r615938_rule
SV-111489

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.

Checks: C-24655r426393_chk

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.

Fix: F-24644r426394_fix

From the Tomcat command line type the following command: sudo usermod -s /usr/sbin/nologin tomcat

b

Tomcat user account must be a non-privileged user.

AC-6 - Medium - CCI-002235 - V-222984 - SV-222984r615938_rule

RMF Control

AC-6

Severity

M

CCI

CCI-002235

Version

TCAT-AS-001060

Vuln IDs

V-222984
V-102551

Rule IDs

SV-222984r615938_rule
SV-111491

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.

Checks: C-24656r426396_chk

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.

Fix: F-24645r426397_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 not exist. 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

a

Application user name must be logged.

AC-6 - Low - CCI-002234 - V-222985 - SV-222985r615938_rule

RMF Control

AC-6

Severity

L

CCI

CCI-002234

Version

TCAT-AS-001080

Vuln IDs

V-222985
V-102553

Rule IDs

SV-222985r615938_rule
SV-111493

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.

Checks: C-24657r426399_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/conf/server.xml file. Review all "Valve" elements. If the pattern= statement does not include %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 &quot;%r&quot; %s %b" /> ... </Host>

Fix: F-24646r426400_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

b

$CATALINA_HOME folder must be owned by the root user, group tomcat.

CM-5 - Medium - CCI-001813 - V-222986 - SV-222986r615938_rule

RMF Control

CM-5

Severity

M

CCI

Version

TCAT-AS-001200

Vuln IDs

V-222986
V-102555

Rule IDs

SV-222986r615938_rule
SV-111495

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.

Checks: C-24658r426402_chk

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.

Fix: F-24647r426403_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

b

$CATALINA_BASE/conf/ folder must be owned by root, group tomcat.

CM-5 - Medium - CCI-001813 - V-222987 - SV-222987r754842_rule

RMF Control

CM-5

Severity

M

CCI

Version

TCAT-AS-001220

Vuln IDs

V-222987
V-102557

Rule IDs

SV-222987r754842_rule
SV-111497

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 0027 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. If the ISSM determines the operational need to allow application admins access to change the Tomcat configuration outweighs the risk of limiting that access, then they can change the group membership to accommodate. Ownership must not be changed. The ISSM should take the exposure of the system to high risk networks into account.

Checks: C-24659r426405_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/conf -follow -maxdepth 0 $ ! -user root -o ! -group tomcat $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the group permissions are set in accordance with the risk acceptance. Ownership must not be changed. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/conf folder ownership and group membership is not set to root:tomcat, this is a finding.

Fix: F-24648r426406_fix

If operational/application requirements specify different group file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Ownership must not be changed. Run the following commands on the Tomcat server: sudo find $CATALINA_BASE/conf -maxdepth 0 $ ! -user root $ | sudo xargs chown root sudo find $CATALINA_BASE/conf -maxdepth 0 $ ! -group tomcat $ | sudo xargs chgrp tomcat

b

$CATALINA_BASE/logs/ folder must be owned by tomcat user, group tomcat.

CM-5 - Medium - CCI-001813 - V-222988 - SV-222988r754843_rule

RMF Control

CM-5

Severity

M

CCI

Version

TCAT-AS-001250

Vuln IDs

V-222988
V-102559

Rule IDs

SV-222988r754843_rule
SV-111499

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 0027 to maintain these permissions.

Checks: C-24660r426408_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/logs -follow -maxdepth 0 $ ! -user tomcat -o ! -group tomcat $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/logs folder ownership and group membership is not set to tomcat:tomcat, this is a finding.

Fix: F-24649r426409_fix

If operational/application requirements specify different group file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following commands on the Tomcat server: sudo find $CATALINA_BASE/logs -maxdepth 0 $ ! -user tomcat $ | sudo xargs chown tomcat sudo find $CATALINA_BASE/logs -maxdepth 0 $ ! -group tomcat $ | sudo xargs chgrp tomcat

a

$CATALINA_BASE/temp/ folder must be owned by tomcat user, group tomcat.

CM-5 - Low - CCI-001813 - V-222989 - SV-222989r754844_rule

RMF Control

CM-5

Severity

L

CCI

Version

TCAT-AS-001260

Vuln IDs

V-222989
V-102561

Rule IDs

SV-222989r754844_rule
SV-111501

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 0027 to maintain these permissions. If operational needs require application administrators to be able to change application configurations, the group permissions can be modified to allow specific application admins the access they require with an ISSM risk acceptance. Ownership may not change. The exposure of the system to high risk networks should always be taken into account.

Checks: C-24661r426411_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/temp -follow -maxdepth 0 $ ! -user tomcat -o ! -group tomcat $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/temp folder ownership and group membership is not set to tomcat:tomcat, this is a finding.

Fix: F-24650r426412_fix

If operational/application requirements specify different file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following commands on the Tomcat server: sudo find $CATALINA_BASE/temp -maxdepth 0 $ ! -user tomcat $ | sudo xargs chown tomcat sudo find $CATALINA_BASE/temp -maxdepth 0 $ ! -group tomcat $ | sudo xargs chgrp tomcat

a

$CATALINA_BASE/temp folder permissions must be set to 750.

CM-5 - Low - CCI-001813 - V-222990 - SV-222990r754845_rule

RMF Control

CM-5

Severity

L

CCI

Version

TCAT-AS-001270

Vuln IDs

V-222990
V-102563

Rule IDs

SV-222990r754845_rule
SV-111503

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 0027 to maintain these permissions. If operational needs require application administrators to be able to change application configurations, the group permissions can be modified to allow specific application admins the access they require with an ISSM risk acceptance. Ownership may not change.

Checks: C-24662r426414_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/temp -follow -maxdepth 0 -type d $ \! -perm 750 $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/temp folder permissions are not set to 750, this is a finding.

Fix: F-24651r426415_fix

If operational/application requirements specify different file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following commands on the Tomcat server: sudo find $CATALINA_BASE/temp -follow -maxdepth 0 -type d -print0 | sudo xargs chmod 750 $CATALINA_BASE/temp

b

$CATALINA_BASE/work/ folder must be owned by tomcat user, group tomcat.

CM-5 - Medium - CCI-001813 - V-222991 - SV-222991r754846_rule

RMF Control

CM-5

Severity

M

CCI

Version

TCAT-AS-001280

Vuln IDs

V-222991
V-102565

Rule IDs

SV-222991r754846_rule
SV-111505

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 0027 to maintain these permissions. If operational needs require application administrators to be able to change application configurations, the group permissions can be modified to allow specific application admins the access they require with an ISSM risk acceptance. Ownership may not change.

Checks: C-24663r426417_chk

Access the Tomcat server from the command line and execute the following OS command: sudo find $CATALINA_BASE/work -follow -maxdepth 0 $ ! -user tomcat -o ! -group tomcat $ -ls If ISSM risk acceptance specifies deviation from requirement based on operational/application needs, this is not a finding if the permissions are set in accordance with the risk acceptance. If no folders are displayed, this is not a finding. If results indicate the $CATALINA_BASE/work folder ownership and group membership is not set to tomcat:tomcat, this is a finding.

Fix: F-24652r426418_fix

If operational/application requirements specify different group file permissions, obtain ISSM risk acceptance and set permissions according to risk acceptance. Run the following commands on the Tomcat server: sudo find $CATALINA_BASE/work -maxdepth 0 $ ! -user tomcat $ | sudo xargs chown tomcat sudo find $CATALINA_BASE/work -maxdepth 0 $ ! -group tomcat $ | sudo xargs chgrp tomcat

b

Multifactor certificate-based tokens (CAC) must be used when accessing the management interface.

IA-2 - Medium - CCI-001953 - V-222993 - SV-222993r615938_rule

RMF Control

IA-2

Severity

M

CCI

CCI-001953

Version

TCAT-AS-001320

Vuln IDs

V-222993
V-102569

Rule IDs

SV-222993r615938_rule
SV-111509

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. Satisfies: SRG-APP-000391-AS-000239, SRG-APP-000392-AS-000240, SRG-APP-000402-AS-000247, SRG-APP-000403-AS-000248

Checks: C-24665r426423_chk

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_BASE/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.

Fix: F-24654r426424_fix

From the Tomcat server as a privileged user, edit the $CATALINA_BASE/webapps/manager/WEB-INF/web.xml file and modify the auth-method for the manager application security constraint. sudo nano $CATALINA_BASE/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

b

Certificates in the trust store must be issued/signed by an approved CA.

SC-23 - Medium - CCI-002470 - V-222994 - SV-222994r615938_rule

RMF Control

SC-23

Severity

M

CCI

CCI-002470

Version

TCAT-AS-001430

Vuln IDs

V-222994
V-102571

Rule IDs

SV-222994r615938_rule
SV-111511

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.

Checks: C-24666r426426_chk

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.

Fix: F-24655r426427_fix

Obtain and install the DoD PKI CA certificate bundles by accessing the DoD PKI office website 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.

b

The application server, when categorized as a high availability system within RMF, must be in a high-availability (HA) cluster.

SC-5 - Medium - CCI-002385 - V-222995 - SV-222995r615938_rule

RMF Control

SC-5

Severity

M

CCI

CCI-002385

Version

TCAT-AS-001460

Vuln IDs

V-222995
V-102573

Rule IDs

SV-222995r615938_rule
SV-111513

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.

Checks: C-24667r426429_chk

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_BASE/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.

Fix: F-24656r426430_fix

From the Tomcat server as a privileged user, modify the $CATALINA_BASE/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 website. https://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html

b

Tomcat server must be patched for security vulnerabilities.

SC-5 - Medium - CCI-002385 - V-222996 - SV-222996r615938_rule

RMF Control

SC-5

Severity

M

CCI

CCI-002385

Version

TCAT-AS-001470

Vuln IDs

V-222996
V-102575

Rule IDs

SV-222996r615938_rule
SV-111515

Tomcat is constantly being updated to address newly discovered vulnerabilities, some of which include denial-of-service attacks. To address this risk, the Tomcat administrator must ensure the system remains up to date on patches. Satisfies: SRG-APP-000435-AS-000163, SRG-APP-000456-AS-000266

Checks: C-24668r426432_chk

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.

Fix: F-24657r426433_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.

b

AccessLogValve must be configured for Catalina engine.

AU-12 - Medium - CCI-000172 - V-222997 - SV-222997r615938_rule

RMF Control

AU-12

Severity

M

CCI

Version

TCAT-AS-001560

Vuln IDs

V-222997
V-102577

Rule IDs

SV-222997r615938_rule
SV-111517

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. Satisfies: SRG-APP-000495-AS-000220, SRG-APP-000381-AS-000089, SRG-APP-000499-AS-000224, SRG-APP-000504-AS-000229

Checks: C-24669r426435_chk

As an elevated user on the Tomcat server: Edit the $CATALINA_BASE/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>

Fix: F-24658r426436_fix

As a privileged user on the Tomcat server: Edit the $CATALINA_BASE/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

b

Changes to $CATALINA_HOME/bin/ folder must be logged.

AU-12 - Medium - CCI-000172 - V-222998 - SV-222998r615938_rule

RMF Control

AU-12

Severity

M

CCI

Version

TCAT-AS-001590

Vuln IDs

V-222998
V-102579

Rule IDs

SV-222998r615938_rule
SV-111519

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.

Checks: C-24670r426438_chk

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.

Fix: F-24659r426439_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

b

Changes to $CATALINA_BASE/conf/ folder must be logged.

AU-12 - Medium - CCI-000172 - V-222999 - SV-222999r615938_rule

RMF Control

AU-12

Severity

M

CCI

Version

TCAT-AS-001591

Vuln IDs

V-222999
V-102581

Rule IDs

SV-222999r615938_rule
SV-111521

The $CATALINA_BASE/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.

Checks: C-24671r426441_chk

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_BASE/conf -p wa -k tomcat, or if there are no results, this is a finding.

Fix: F-24660r426442_fix

From the Tomcat server as a privileged user, use the auditctl command. sudo auditctl -w $CATALINA_BASE/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

b

Changes to $CATALINA_HOME/lib/ folder must be logged.

AU-12 - Medium - CCI-000172 - V-223000 - SV-223000r615938_rule

RMF Control

AU-12

Severity

M

CCI

Version

TCAT-AS-001592

Vuln IDs

V-223000
V-102583

Rule IDs

SV-223000r615938_rule
SV-111523

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.

Checks: C-24672r426444_chk

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.

Fix: F-24661r426445_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

a

Application servers must use NIST-approved or NSA-approved key management technology and processes.

SC-13 - Low - CCI-002450 - V-223001 - SV-223001r615938_rule

RMF Control

SC-13

Severity

L

CCI

CCI-002450

Version

TCAT-AS-001640

Vuln IDs

V-223001
V-102585

Rule IDs

SV-223001r615938_rule
SV-111525

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.

Checks: C-24673r426447_chk

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.

Fix: F-24662r426448_fix

Obtain and install the DoD PKI CA certificate bundles by accessing the DoD PKI office website at cyber.mil/pki-pke. Import the DoD CA certificates.

a

STRICT_SERVLET_COMPLIANCE must be set to true.

CM-6 - Low - CCI-000366 - V-223002 - SV-223002r615938_rule

RMF Control

CM-6

Severity

L

CCI

Version

TCAT-AS-001660

Vuln IDs

V-223002
V-102587

Rule IDs

SV-223002r615938_rule
SV-111527

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.

Checks: C-24674r426450_chk

If the system has an ISSM risk acceptance for operational issues that arise due to this setting, this is not a finding. 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.

Fix: F-24663r426451_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

a

RECYCLE_FACADES must be set to true.

CM-6 - Low - CCI-000366 - V-223003 - SV-223003r615938_rule

RMF Control

CM-6

Severity

L

CCI

Version

TCAT-AS-001670

Vuln IDs

V-223003
V-102589

Rule IDs

SV-223003r615938_rule
SV-111529

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.

Checks: C-24675r426453_chk

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 ="true", this is a finding.

Fix: F-24664r426454_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

b

ALLOW_BACKSLASH must be set to false.

CM-6 - Medium - CCI-000366 - V-223004 - SV-223004r615938_rule

RMF Control

CM-6

Severity

M

CCI

Version

TCAT-AS-001680

Vuln IDs

V-223004
V-102591

Rule IDs

SV-223004r615938_rule
SV-111531

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.

Checks: C-24676r426456_chk

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_BASE/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.

Fix: F-24665r426457_fix

As a privileged user on the Tomcat server: If the finding is in the catalina.properties file, edit the $CATALINA_BASE/conf/catalina.properties file. sudo nano $CATALINA_BASE/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 by running the following commands: sudo systemctl restart tomcat sudo systemctl daemon-reload

b

ENFORCE_ENCODING_IN_GET_WRITER must be set to true.

CM-6 - Medium - CCI-000366 - V-223005 - SV-223005r615938_rule

RMF Control

CM-6

Severity

M

CCI

Version

TCAT-AS-001690

Vuln IDs

V-223005
V-102593

Rule IDs

SV-223005r615938_rule
SV-111533

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.

Checks: C-24677r426459_chk

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 ="true", this is a finding.

Fix: F-24666r426460_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

b

Tomcat users in a management role must be approved by the ISSO.

CM-6 - Medium - CCI-000366 - V-223006 - SV-223006r615938_rule

RMF Control

CM-6

Severity

M

CCI

Version

TCAT-AS-001700

Vuln IDs

V-223006
V-102595

Rule IDs

SV-223006r615938_rule
SV-111535

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.

Checks: C-24678r426462_chk

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.

Fix: F-24667r426463_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.

a

Hosted applications must be documented in the system security plan.

CM-6 - Low - CCI-000366 - V-223007 - SV-223007r615938_rule

RMF Control

CM-6

Severity

L

CCI

Version

TCAT-AS-001710

Vuln IDs

V-223007
V-102597

Rule IDs

SV-223007r615938_rule
SV-111537

The ISSM/ISSO must be cognizant of all applications operating on the Tomcat server, and must address any security implications associated with the operation of the applications. If unknown/undocumented applications are operating on the Tomcat server, these applications increase risk for the system due to not being managed, patched or monitored for unapproved activity on the system.

Checks: C-24679r426465_chk

Review the Tomcat servers System Security Plan/server documentation. Access the Tomcat server and review the $CATALINA_BASE/webapps folder. 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.

Fix: F-24668r426466_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.

a

Connectors must be approved by the ISSO.

CM-6 - Low - CCI-000366 - V-223008 - SV-223008r615938_rule

RMF Control

CM-6

Severity

L

CCI

Version

TCAT-AS-001720

Vuln IDs

V-223008
V-102599

Rule IDs

SV-223008r615938_rule
SV-111539

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).

Checks: C-24680r426468_chk

Review the Tomcat servers System Security Plan/server documentation. Access the Tomcat server and review the server.xml file. grep -i "connector port" $CATALINA_BASE/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.

Fix: F-24669r426469_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.

a

Connector address attribute must be set.

CM-6 - Low - CCI-000366 - V-223009 - SV-223009r615938_rule

RMF Control

CM-6

Severity

L

CCI