Server hardening

For the highest possible security, it is recommended to harden the Tomcat server. This procedure hides or removes all unnecessary access or information to the outside as far as possible. For example, information about the specific version of the server can already provide a potential attacker with information about security gaps known in this version. Apache itself offers an overview of security aspects to be considered on their website. The following is a summary of the most important sub-issues.

Regular updating of the server

Regular updating of the server ensures that any security gaps found within the server can be closed. It should always be in the IT's interest to keep both Tomcat and all the systems involved as up-to-date as possible, both at the level of the application and the operating system.

Removing the default applications

Depending on the installation you choose, the Tomcat server may ship with several standard applications. These are examples, documentation and management tools. If these are not used, it is recommended to remove them. It is sufficient to delete the corresponding applications from the webapps directory of the Tomcat installation. Otherwise, these applications may offer their own attack possibilities or unnecessarily disclose information about the server used. By default, these are the following directories:

• docs... Documentation of the server
• examples... Sample applications
• host-manager... management interface for the administration of virtual hosts
• manager... Management interface for managing the installed applications
• ROOT... root directory with a default welcome page

All these applications are not necessary for the operation of Xima® Formcycle and can therefore usually be removed without any problems.

Removing unnecessary server information from the response headers

Before the required Tomcat version 9, the HTTP header Server was transmitted by default with the information of the Tomcat version used for each HTTP response. This is no longer the case by default, but should also be ensured for all other servers involved (load balancer, firewall, etc.). If this header is nevertheless transmitted by Tomcat, the corresponding value can be defined within the connector of the server.xml (/Path/To/Tomcat/conf/web.xml). An override with an empty value would look like the following example:

There is also the serverRemoveAppProvidedValues attribute which can be used to prevent this header from being set by applications as well. An example configuration looks like this:

Removing Tomcat version from default error pages

By default, the Tomcat server error pages unnecessarily reveal information in the form of the installed version and error details. To prevent this it is possible to disable these sections of the error pages. For this purpose the configuration of the so-called ErrorReportValve can be entered or adapted in the server.xml (/Path/Tomcat/conf/server.xml) under the node Host. If, for example, neither the server information nor details of the actual error are delivered, the following adaptation is recommended:

Use alternative error pages

A further increase in security is provided by the ability to completely change the server's default error pages. For this purpose, attributes for individual HTTP error codes and/or a page for all undefined errors can be specified to the ErrorReportValve entry. The errorCode.nnn attribute is used for this, where nnn corresponds to the HTTP error code. If this is used with 0, the specified page is used for all undefined errors. An example where the HTTP status 404 (resource not found) is redirected to the page 404.html and all other errors are redirected to error.html looks like this:

Additionally or alternatively, the standard errors can usually be handled by intermediate servers such as load balancers or proxies. This allows for a visually more standardized procedure and can also be used in addition to the adaptation within the Tomcat.