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