Tomcat Server Härtung

Ich hatte das Glück, dass ich vor Kurzem ein Tomcat-basiertes Finanzsystem implementiert habe, das im Anschluss von Ethical Hackern einem Penetration Test unterzogen wurde. Die Tips der Profis waren dabei enorm hilfreich, sodass ich sie hier für zukünftige Installationen dokumentiert habe. Anleitungen zur Härtung einer Tomcat Installation gibt es viele und auch ein CIS Benchmark, allerdings sind die meisten Anleitungen sehr Linux-lastig. Meine Installation ist jedoch Windows-basiert, sodass hier teilweise eigene Einstellungen erforderlich sind.

Die folgenden Härtungen basieren auf Tomcat 8.0 auf einem Windows Server 2016 System.

Installation

Schon bei der Installation der Komponenten von Tomcat beginnt die Härtung. Es sollten je nach Anforderung der Anwendung nur die zwingend notwendigen Komponenten installiert werden. Normalerweise sind dies:

• Tomcat
  • Tomcat Core
  • Tomcat Service Startup
• ggf. Start Menu Items

In den seltensten Fällen werden darüber hinaus folgende Komponenten benötigt, die, wenn sie aktiv sind, zusätzliche Angriffsfläche für Hacker bieten:

• Tomcat
  • Tomcat Native
• Documentation
• Manager
• Host Manager
• Examples

Auf diese Komponenten sollte man daher bei der Installation schon verzichten.

Windows Service

Nach der Installation läuft der Tomcat Windows Service standarmäßig im .\LocalSystem Kontext, also unter dem User mit uneingeschränktem Trust-Level und mit den höchsten Rechten auf einem Windows System. Wird der Tomcat von einem Angreifer gekapert, lässt sich auf diesem Weg eine Metasploit Shell deployen, mit dem der Angreifer dann uneingeschränkten Zugang auf das ganze System hat. Daher sollte man den Dienst zwingend zumindest auf NT AUTHORITY\LocalService ändern oder auf einen eigenen Service Account umkonfigurieren, der im besten Fall lediglich normale Standard User Rechte hat und der Rechte bei Bedarf explizit zugewiesen bekommt.

HTTPS

Wie ein entsprechendes Zertifikat erstellt und ein HTTPS-Connector angelegt wird, habe ich in diesem vorherigen Artikel erklärt.

HSTS

HSTS ist ein Sicherheitsmechanismus für HTTPS Verbindungen, der mittels Header den Client Browser anweist, zukünftig für eine definierte Zeit ausschließlich verschlüsselte Verbindungen für die aufgerufene Domain und ggf. Subdomain zu nutzen. Details dazu findet man auch bei Wikipedia. Die HSTS Konfiguration erfolgt in der Datei $CATALINA_HOME\conf\web.xml. Das folgende Beispiel aktiviert HSTS, HSTS Preload und weitere sinnvolle Einstellungen.

<web-app>
   ...
   <filter>
      <filter-name>HTTP Header Security Filter</filter-name>
      <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
      <init-param>
         <param-name>hstsEnabled</param-name>
         <param-value>true</param-value>
      </init-param>
      <init-param>
         <param-name>hstsIncludeSubDomains</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>hstsPreload</param-name>
         <param-value>true</param-value>
      </init-param>
      <init-param>
         <param-name>antiClickJackingEnabled</param-name>
         <param-value>false</param-value>
      </init-param>
      <init-param>
         <param-name>xssProtectionEnabled</param-name>
         <param-value>false</param-value>
      </init-param>
      <init-param>
         <param-name>blockContentTypeSniffingEnabled</param-name>
         <param-value>false</param-value>
      </init-param>
   </filter>
   <filter-mapping>
      <filter-name>HTTP Header Security Filter</filter-name>
      <url-pattern>/*</url-pattern>
   </filter-mapping>
   ... 
</web-app>

Shutdown Port und Shutdown Command

Über den Shutdown Port und das Shutdown Command kann eine Tomcat Instanz heruntergefahren werden, indem eine Telnet Verbindung zum Port aufgebaut und der Shutdown Befehl ausgeführt wird (standardmäßig: SHUTDOWN). Da Port und Command allgemein bekannt sind, sollte man dies manuell ändern. Die beiden Parameter werden in der Datei $CATALINA_HOME\conf\server.xml angepasst. Die vorhandene Werte werden z.B. mit folgenden Einstellungen überschrieben:

<Server port="8666" shutdown="IDONTLIKETOMCAT">
</Server>

HTTP Options

Standardmäßig sind nach der Tomcat Installation alle HTTP-Options aktiv. Darunter auch OPTIONS, TRACE, PUT und DELETE. Besonders die letzten Beiden bergen die Gefahr eine Datenmanipulation und in der Regel sind alle vier Optionen nicht erforderlich und können deaktiviert, bzw. auf eine Fehlerseite umgeleitet werden.

Hierzu wird ein Security Constraint in der Datei $CATALINA_HOME\conf\web.xml angelegt, der die Methoden beschränkt.

<web-app>
   ...
   <security-constraint>
      <web-resource-collection>
         <web-resource-name><strong>restricted methods</strong></web-resource-name>
         <url-pattern>/*</url-pattern>
         <http-method>PUT</http-method>
         <http-method>DELETE</http-method>
         <http-method>OPTIONS</http-method>
         <http-method>TRACE</http-method>
      </web-resource-collection>
      <auth-constraint />
   </security-constraint>
   ...
</web-app>

Cookie HttpOnly/Secure Flags

Die Cookie HttpOnly/Secure Flags werden in in der Datei $CATALINA_HOME\conf\web.xml konfiguriert.

<session-config>
   ...
   <cookie-config>
      <http-only>true</http-only>
      <secure>true</secure>
   </cookie-config>
   ...
</session-config>

Error Pages

Die Rückgabe von Error Pages gibt Angreifern die Möglichkeit, Rückschlüsse auf Angriffspunkte zu ziehen. Daher sollte eine allgemeine, nichtssagende Error Page für alle gängigen Fehlercodes angelegt und konfiguriert werden, sowohl für die normalen Error Codes, als auch die Java Error Codes, die über den Tomcat ausgegeben werden. Dazu legt man einfach eine HTML codierte .jsp-Datei mit unverfänglichem Inhalt an, z.B. $CATALINA_HOME\webapps\ROOT\error.jsp, und hinterlegt diese als Error Page in der Datei $CATALINA_HOME\conf\web.xml mit folgenden Einträgen:

<web-app>
   ... 
   <error-page>
      <error-code>404</error-code> 
      <location>/error.jsp</location>
   </error-page>
   <error-page>
      <error-code>403</error-code>
      <location>/error.jsp</location>
   </error-page>
   <error-page> 
      <error-code>500</error-code> 
      <location>/error.jsp</location>
      <exception-type>java.lang.Exception</exception-type> 
      <location>/error.jsp</location>
      <exception-type>java.lang.Throwable</exception-type> 
      <location>/error.jsp</location>
   </error-page>
   ...
</web-app>

Tracing

Die Tracing Funktion wird in der Datei $CATALINA_HOME\conf\server.xml konfiguriert. Standardmäßig ist der Parameter nicht angelegt, aber aktiv. Zur Deaktivierung wird der Parameter wie folgt für jeden relevanten Connector konfiguriert:

<Connector
   ...
      allowTrace="false"
   ...
/>

HTTP Server Banner

Der HTTP Server Banner ermöglicht es Angreifern, den Webservice zu identifizieren, mit dem die Anwendung bereitgestellt wird. Daher konfigurieren wir die Datei $CATALINA_HOME\conf\web.xml so um, dass ein leerer Wert zurückgegeben wird. Dazu muss ein Parameter in den entsprechenden Connector eingefügt werden.

<connector
   ...
   server=" "
   ...
/>

Redirect

Befindet sich die Webanwendung nicht im Root-Verzeichnis des Tomcat, sondern in einem Unterordner, empfiehlt es sich, einen direkten Redirect vom Root-Verzeichnis ins Unterverzeichnis zu konfigurieren. Dazu reicht eine einfache HTML Datei (z.B. index.html), die im Root-Verzeichnis des Tomcat abgelegt wird. Die Datei muss selbstverständlich als Startdatei konfiguriert sein.

<html>
    <head>
        <meta http-equiv="refresh" content="0;URL=/<Subfolder>/">
    </head>
    <body>
    </body>
</html>

Der Redirect kann auch auf eine tiefere Ordnerstruktur eingerichtet werden (z.B. /<Subfolder1>/<Subfolder2>/)