Difference between revisions of "Recommended Tomcat Setup"
Lythhishmeh (talk | contribs) (Created page with " == Recommended Apache Tomcat Setup == Fusion Registry 11 is designed to run on a variety of web servers and platforms, although we recommend and support Fusion Registry runn...") |
Lythhishmeh (talk | contribs) |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | [[Category:How_To]] | ||
+ | [[Category:Fusion Registry Install]] | ||
− | + | = Recommended Apache Tomcat Setup = | |
− | Fusion Registry | + | Fusion Registry must be run within a Java Servlet Container. Regnology recommends using Apache Tomcat as the Java Servlet Container, as this has been used during the testing lifecycle of Fusion Registry. The Fusion Registry has only been tested in Apache Tomcat and therefore we cannot guarantee that the Fusion Registry will work with other Java Servlet Containers. |
There are a few things to consider when running Fusion Registry on Apache Tomcat. | There are a few things to consider when running Fusion Registry on Apache Tomcat. | ||
− | + | == Security == | |
− | + | It's worth noting that this is not an exhaustive list of all needed security settings, nor is it a substitute for on-team infrastructure expertise, but for enhanced security, we recommend the following settings: | |
− | + | === server.xml File === | |
− | + | ==== Hiding Stack Traces ==== | |
− | + | By default, Tomcat will display Stack Traces in certain circumstances. We recommend the following change be made to the file: '''server.xml'''. This file is located in the Apache Tomcat Directory ''<Apache Root>/conf'' | |
− | + | Edit the file and and locate the "Host" section. At the end of this section, just before the closing </Host> tag, insert the following: | |
− | + | <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false"/> | |
− | + | This will prevent stack traces from being displayed to the user with HTTP error codes. Tomcat must be restarted for this change to take effect. | |
− | + | === context.xml File === | |
− | ==== | + | ==== Same Site Cookies ==== |
− | + | Since release 11.13 of the Fusion Registry, the product now ships with a default ''context.xml'' file which is located in the META-INF directory in the Fusion Registry directory. This file overrides Tomcat's cookie pre-processor settings and enforces a strict SameSite cookies policy. More information on SameSite cookie security policies can be found [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie here]. This prevents potential vulnerabilities related to Cross-Site Request Forgery (CSRF). | |
+ | |||
+ | No action is required on the deployer's side, but if you want to disable this setting, either change or delete the file. | ||
+ | |||
+ | === web.xml File === | ||
+ | |||
+ | ==== HTTP Strict Transport Security (HSTS) ==== | ||
+ | |||
+ | We recommend the following change be made to the file: '''web.xml'''. This file is located in the Apache Tomcat Directory ''<Apache Root>/conf''. HTTP Strict Transport Security (HSTS) is a standard which forces those connecting to the registry over the internet to only use HTTPs. This can prevent sniffing attacks and MITM (Man in the middle) attacks which could compromise data security. We don't enable HSTS by default in the registry to allow for flexibility in configuration, but we do encourage our users to enable it. | ||
+ | |||
+ | In Tomcat 9.0, HSTS can be enabled by doing the following: | ||
+ | |||
+ | Modify/Update "httpHeaderSecurity" filter within Tomcat web.xml file with following values: | ||
+ | <filter> | ||
+ | <filter-name>httpHeaderSecurity</filter-name> | ||
+ | <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> | ||
+ | <async-supported>true</async-supported> | ||
+ | <init-param> | ||
+ | <param-name>hstsEnabled</param-name> | ||
+ | <param-value>true</param-value> | ||
+ | </init-param> | ||
+ | <init-param> | ||
+ | <param-name>hstsMaxAgeSeconds</param-name> | ||
+ | <param-value>31536000</param-value> | ||
+ | </init-param> | ||
+ | <init-param> | ||
+ | <param-name>hstsIncludeSubDomains</param-name> | ||
+ | <param-value>true</param-value> | ||
+ | </init-param> | ||
+ | </filter> | ||
+ | and uncomment the below section which can be found further down in the web.xml file: | ||
+ | <filter-mapping> | ||
+ | <filter-name>httpHeaderSecurity</filter-name> | ||
+ | <url-pattern>/*</url-pattern> | ||
+ | <dispatcher>REQUEST</dispatcher> | ||
+ | </filter-mapping> | ||
+ | |||
+ | The above filter values represent: | ||
+ | |||
+ | '''hstsEnabled (true)''': HTTP Strict Transport Security (HSTS) header to be added to the response.<br> | ||
+ | '''hstsMaxAgeSeconds (31536000)''': The one year age value that should be used in the HSTS header.<br> | ||
+ | '''hstsIncludeSubDomains (true)''': The includeSubDomains parameter to be included in the HSTS header.<br> | ||
+ | |||
+ | ==== Setting a Maximum HTTP Request Size ==== | ||
+ | |||
+ | We recommend our customers set a limit on the maximum size of the HTTP requests they allow. This is to prevent malicious actors from sending overly large requests with the intent of crashing the registry. This can be done by modifying the '''web.xml''' file. | ||
+ | |||
+ | Under the <code><webapp></code> tag, create a new servlet with the following values: | ||
+ | |||
+ | <servlet> | ||
+ | <multipart-config> | ||
+ | <file-size-threshold>0</file-size-threshold> | ||
+ | <max-file-size>209715200</max-file-size> | ||
+ | <max-request-size>209715200</max-request-size> | ||
+ | </multipart-config> | ||
+ | </servlet> | ||
+ | |||
+ | The above filter values represent: | ||
+ | |||
+ | '''file-size-threshold''': Determines the size threshold over which a file will be flushed to disk instead of being held in memory.<br> | ||
+ | '''max-file-size''': Determines the largest size the server will accept for an uploaded file.<br> | ||
+ | '''max-request-size''': The threshold for the total size of a POST request.<br> | ||
+ | |||
+ | The values are measured in bytes. |
Latest revision as of 13:09, 13 June 2024
Contents
Recommended Apache Tomcat Setup
Fusion Registry must be run within a Java Servlet Container. Regnology recommends using Apache Tomcat as the Java Servlet Container, as this has been used during the testing lifecycle of Fusion Registry. The Fusion Registry has only been tested in Apache Tomcat and therefore we cannot guarantee that the Fusion Registry will work with other Java Servlet Containers.
There are a few things to consider when running Fusion Registry on Apache Tomcat.
Security
It's worth noting that this is not an exhaustive list of all needed security settings, nor is it a substitute for on-team infrastructure expertise, but for enhanced security, we recommend the following settings:
server.xml File
Hiding Stack Traces
By default, Tomcat will display Stack Traces in certain circumstances. We recommend the following change be made to the file: server.xml. This file is located in the Apache Tomcat Directory <Apache Root>/conf
Edit the file and and locate the "Host" section. At the end of this section, just before the closing </Host> tag, insert the following:
<Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false"/>
This will prevent stack traces from being displayed to the user with HTTP error codes. Tomcat must be restarted for this change to take effect.
context.xml File
Same Site Cookies
Since release 11.13 of the Fusion Registry, the product now ships with a default context.xml file which is located in the META-INF directory in the Fusion Registry directory. This file overrides Tomcat's cookie pre-processor settings and enforces a strict SameSite cookies policy. More information on SameSite cookie security policies can be found here. This prevents potential vulnerabilities related to Cross-Site Request Forgery (CSRF).
No action is required on the deployer's side, but if you want to disable this setting, either change or delete the file.
web.xml File
HTTP Strict Transport Security (HSTS)
We recommend the following change be made to the file: web.xml. This file is located in the Apache Tomcat Directory <Apache Root>/conf. HTTP Strict Transport Security (HSTS) is a standard which forces those connecting to the registry over the internet to only use HTTPs. This can prevent sniffing attacks and MITM (Man in the middle) attacks which could compromise data security. We don't enable HSTS by default in the registry to allow for flexibility in configuration, but we do encourage our users to enable it.
In Tomcat 9.0, HSTS can be enabled by doing the following:
Modify/Update "httpHeaderSecurity" filter within Tomcat web.xml file with following values:
<filter> <filter-name>httpHeaderSecurity</filter-name> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> <async-supported>true</async-supported> <init-param> <param-name>hstsEnabled</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>hstsMaxAgeSeconds</param-name> <param-value>31536000</param-value> </init-param> <init-param> <param-name>hstsIncludeSubDomains</param-name> <param-value>true</param-value> </init-param> </filter>
and uncomment the below section which can be found further down in the web.xml file:
<filter-mapping> <filter-name>httpHeaderSecurity</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping>
The above filter values represent:
hstsEnabled (true): HTTP Strict Transport Security (HSTS) header to be added to the response.
hstsMaxAgeSeconds (31536000): The one year age value that should be used in the HSTS header.
hstsIncludeSubDomains (true): The includeSubDomains parameter to be included in the HSTS header.
Setting a Maximum HTTP Request Size
We recommend our customers set a limit on the maximum size of the HTTP requests they allow. This is to prevent malicious actors from sending overly large requests with the intent of crashing the registry. This can be done by modifying the web.xml file.
Under the <webapp>
tag, create a new servlet with the following values:
<servlet> <multipart-config> <file-size-threshold>0</file-size-threshold> <max-file-size>209715200</max-file-size> <max-request-size>209715200</max-request-size> </multipart-config> </servlet>
The above filter values represent:
file-size-threshold: Determines the size threshold over which a file will be flushed to disk instead of being held in memory.
max-file-size: Determines the largest size the server will accept for an uploaded file.
max-request-size: The threshold for the total size of a POST request.
The values are measured in bytes.