Apache Tomcat mit SSL absichern


Nachdem ich dir in unserem Tutorial Apache Tomcat zu deinem Webserver & Webcontainer unter Ubuntu 16.04/18.04 gezeigt habe, wie du dir den Apache Tomcat auf deinem Ubuntu installierst und konfigurierst, stelle ich dir zusätzlich dieses Tutorial hier zur Verfügung. Hier erfährst du, wie du den Tomcat Webserver und -container mit SSL absichern kannst. Genau genommen lernst du, wie du einen SSL-fähigen Proxy Server einrichtest, um sicher mit Clients zu verhandeln und Anforderungen an Tomcat zu reichen.

Ohne SSL läuft die gesamte Kommunikation zwischen dem Tomcat-Server und den Clients per default unverschlüsselt ab, ausgenommen sind hierbei Passwörter oder vertraulichen Daten. Es gibt mehr als eine Möglichkeit, wie du SSL in deine Tomcat-Installation integrieren kannst. Um die Möglichkeiten in Betracht zu ziehen, werden wir uns in diesem Tutorial sowohl Apache als auch Nginx widmen.

Vorab: Wozu Reverse Proxy?

Tomcat hat die Fähigkeit, Verbindungen nativ zu verschlüsseln, sodass die Frage aufkommt, wozu eine Reverse-Proxy-Lösung erforderlich/hilfreich ist.

In diesem Zusammenhang spielen die Nachteile eine Rolle, die SSL mit Tomcat mit sich bringen kann. Ich gehe kurz auf einige Nachteile ein:

  • Es kann vorkommen, dass SSL mit Tomcat von bestimmter Software nicht so stark unterstützt wird. Z.B. bietet Let’s Encrypt keine native Möglichkeit, mit Tomcat zu interagieren. Darüber hinaus erfordert das Java-Keystore-Format, dass herkömmliche Zertifikate vor der Verwendung konvertiert werden, was wiederum die Automatisierung erschwert.
  • Zudem werden herkömmliche Webserver häufiger veröffentlicht als Tomcat. Dies kann letztlich erhebliche Auswirkungen auf die Sicherheit deiner Anwendungen haben. Beispielsweise kann die unterstützte Tomcat-SSL-Verschlüsselungssuite schnell veraltet sein, sodass deine Anwendungen nicht optimal geschützt sind. Falls Sicherheitsupdates erforderlich sind, ist es wahrscheinlich einfacher, einen Webserver als deine Tomcat-Installation zu aktualisieren.

Eine Reverse-Proxy-Lösung umgeht solche Probleme, indem einfach ein starker Webserver vor den Tomcat gestellt wird. Der Webserver kann Clientanfragen mit SSL abwickeln. Diese Funktionalität wurde speziell für die Verarbeitung entwickelt.

Der Webserver kann dann Anfragen an Tomcat weiterleiten, die in ihrer normalen, nicht privilegierten Konfiguration ausgeführt werden. Diese Trennung der Anliegen vereinfacht die Konfiguration, auch wenn eine zusätzliche Software ausgeführt werden muss.

HTTP Proxy mit dem mod_jk-Modul deines Apache

Der Apache-Webserver verfügt über ein Modul namens mod_jk, das über das Apache JServ-Protokoll direkt mit Tomcat kommunizieren kann. Ein Connector für dieses Protokoll ist in Tomcat standardmäßig aktiviert, sodass Tomcat per default bereit ist, diese Anforderungen zu bearbeiten.

Bevor wir besprechen können, wie Apache-Webserververbindungen zu Tomcat ausgeführt werden, musst du einen Apache-Webserver installieren und sichern. Infos hierzu findest du in unserem Tutorial Apache2 auf Ubuntu 16.04/18.04 installieren. Anschließend ist es notwendig, dass du SSL auf dem Server einrichtest.

Wenn du einen Domänennamen hast, kannst du den Server am einfachsten mit Let’s Encrypt sichern, das kostenlose, vertrauenswürdige Zertifikate bereitstellt. Folge einfach unserem Tutorial Einen Apache-Server als Reverse-Proxy einrichten mit Ubuntu, um dies einzurichten.

Des Weiteren geht es darum, wie du den Apache-Webserver an deinen Apache Tomcat anschließt. Installiere mit Hilfe des unten eingeblendeten Kommandos das mod_jk-Modul. Der Apache-Webserver verwendet dieses Modul – wie gesagt – zur Kommunikation mit Tomcat über das Apache JServ-Protokoll. Das Modul wird während des Installationsprozesses automatisch aktiviert.

 apt-get install libapache2-mod-jk 

Als nächstes musst du das Modul dann aber noch konfigurieren. Die Hauptkonfigurationsdatei befindet sich unter /etc/libapache2-mod-jk/workers.properties. Öffne diese Datei jetzt im Editor deiner Wahl. Ich tue dies im nano-Editor.

 nano /etc/libapache2-mod-jk/workers.properties 

Suchen im Inhalt der Datei nach der workers.tomcat_home-Anweisung und lege hier dein Tomcat-Installationsverzeichnis fest. Für unsere Tomcat-Installation wäre das dann /opt/tomcat. Speichere das Update des Dateiinhalts mit der Tastenkombination Strg+O und verlasse den nano-Editor mit Strg+X.

 workers.tomcat_home=/opt/tomcat 

Passe den Apache Virtual Host mit mod_jk an den Proxy an

Als Nächstes müssen wir unseren Apache Virtual Host so anpassen, dass Proxy-Anforderungen an unsere Tomcat-Installation gestellt werden.

Wenn du SSL mit Let’s Encrypt eingerichtet hast, hängt der Dateispeicherort davon ab, welche Optionen du während des Zertifikatsvorgangs ausgewählt hast. Du kannst feststellen, welche virtuellen Hosts an der Bereitstellung von SSL-Anforderungen beteiligt sind, indem du Folgendes Kommando benutzt.

 apache2ctl -S 

Das daraufhin generierte Output wird dann so ähnlich aussehen.

 
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/000-default.conf:1)
*:443                  is a NameVirtualHost
         default server example.com (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
         port 443 namevhost example.com (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
         port 443 namevhost www.example.com (/etc/apache2/sites-enabled/default-ssl.conf:2)

. . .

Anhand der Zeilen, die dem SSL-Port 443 zugeordnet sind (Zeilen 3-6 in diesem Beispiel), können wir feststellen, welche virtuellen Hosts-Dateien am Serving dieser Domänen beteiligt sind.

Hier sehen wir, dass sowohl die 000-default-le-ssl.conf-Datei als auch die default-ssl.conf-Datei involviert sind. Du solltest also beide bearbeiten. Deine Ergebnisse werden sich wahrscheinlich unterscheiden.
Öffne die beiden Dateien jeweils im Editor deiner Wahl.


nano /etc/apache2/sites-enabled/000-default-le-ssl.conf

nano /etc/apache2/sites-enabled/default-ssl.conf

Unabhängig davon, welche Dateien du öffnen musst, ist der Vorgang derselbe. Innerhalb der <VirtualHost>-Tags solltest du Folgendes eingeben.


<VirtualHost *:443>

    . . .

    JKMount /* ajp13_worker

    . . .

</VirtualHost>

Speichere das Update mit der Tastenkombination Strg+O und verlasse den nano-Editor mit Strg+X. Wiederhole den obigen Vorgang für alle anderen Dateien, die du identifiziert hast und die bearbeitet werden müssen.
Lasse deine Konfiguration verifizieren.

 apache2ctl configtest 

Wenn du deinem Output “Syntax OK” entnehmen kannst, dann führe einen Neustart deines Apache Webservers durch.

 systemctl restart apache2 

Du solltest jetzt zu deinem Apache Tomcat gelangen, indem du die SSL-Version deiner Site in deinem Webbrowser besuchst (z.B. https://example.com).

HTTP Proxy mit Nginx

Mit Nginx ist das Proxying ebenso einfach wie mich Apache. Nginx verfügt zwar nicht über ein Modul, mit dem das Apache JServ-Protokoll gesprochen werden kann, es kann jedoch seine robusten HTTP-Proxying-Funktionen für die Kommunikation mit Tomcat verwenden.

Bevor wir uns dem widmen, wie Nginx-Verbindungen zu Tomcat hergestellt werden, musst du Nginx installieren, sichern und SSL auf dem Server einrichten.

Wenn du einen Domänennamen hast, kannst du den Server am einfachsten mit Let’s Encrypt sichern, das kostenlose, vertrauenswürdige Zertifikate bereitstellt. Folge unserem Let’s Encrypt Guide für Nginx, in dem du u.a. auch eine Anleitung zur Installation von Nginx findest.
Im Anschluss daran, geht es darum, wie du den Nginx-Webserver an deinen Tomcat anschließt.

Schritt 1: Anpassen der Nginx Server-Blockkonfiguration

Das Einrichten von Nginx als Proxy für Tomcat ist sehr einfach.

Beginne mit dem Öffnen der Server-Blockdatei, die deiner Site zugeordnet ist. Wir gehen davon aus, dass du die default-Serverblockdatei in diesem Tutorial verwendest.

 nano /etc/nginx/sites-available/default 

Im oberen Bereich der Datei musst du einen Upstream-Block hinzufügen. Dadurch werden die Verbindungsdetails beschrieben, sodass Nginx weiß, wo unser Tomcat-Server zuhört. Platziere diese außerhalb eines der in der Datei definierten Serverblöcke, wie im Code-Snippet unten gezeigt.


upstream tomcat {
    server 127.0.0.1:8080 fail_timeout=0;
}

server {

    . . .

Ändere anschließend innerhalb des für Port 443 definierten Serverblocks den Speicherort/Block. Wir möchten alle Anfragen direkt an den gerade definierten Upstream-Block weiterleiten. Kommentiere den aktuellen Inhalt aus und verwende die proxy_pass-Direktive, um an den soeben definierten „Tomcat“ -Upstream zu gelangen.

Wir müssen auch die Konfiguration von proxy_params in diesen Block aufnehmen. Diese Datei definiert viele Details darüber, wie Nginx die Verbindung weiterleitet. Speichere hiernach das Update mit der Tastenkombination Strg+O und verlasse den nano-Editor mit Strg+X.


    server 127.0.0.1:8080 fail_timeout=0;
}

server {

    . . .

    location / {
        #try_files $uri $uri/ =404;
        include proxy_params;
        proxy_pass http://tomcat/;
    }

    . . .
}

Schritt 2: Teste und starte Nginx neu

Teste als Nächstes, ob bei den Konfigurationsänderungen keine Syntaxfehler aufgetreten sind.

 nginx -t 

Wenn keine Fehler gemeldet werden, starte Nginx neu, um deine Änderungen zu implementieren.

 systemctl restart nginx 

Du solltest jetzt in der Lage sein, zu deiner Tomcat-Installation zu gelangen, indem du die SSL-Version deiner Site in deinem Webbrowser besuchst (z.B. https://example.com).

Zugriff auf die Tomcat-Installation einschränken

Jetzt hast du SSL-verschlüsselten Zugriff auf deinen Apache Tomcat. Da alle Anfragen an Tomcat über unseren Proxy übermittelt werden sollen, können wir Tomcat so konfigurieren, dass nur Verbindungen auf der lokalen Loopback-Schnittstelle überwacht werden. Dies stellt sicher, dass externe Parteien nicht versuchen können, direkt Anfragen von Tomcat zu stellen.

Öffne die server.xml-Datei in deinem Tomcat-Konfigurationsverzeichnis, um diese Einstellungen zu ändern.

 nano /opt/tomcat/conf/server.xml 

In dieser Datei müssen wir die Connector-Definitionen ändern. Derzeit sind in der Konfiguration zwei Connectors aktiviert. Eine verarbeitet normale HTTP-Anforderungen an Port 8080, während die andere Apache JServ-Protokollanforderungen an Port 8009 abwickelt. Die Konfiguration sieht etwa wie folgt aus:


...

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
...

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

Um den Zugriff auf die lokale Loopback-Schnittstelle einzuschränken, musst du nur ein „address“ -Attribut auf 127.0.0.1 in jeder dieser Connector-Definitionen hinzufügen. Das Endergebnis sollte so aussehen, wie im folgenden Code-Snippet gezeigt. Speichere mit Strg+O und verlasse den nano-Editor mit Strg+X.


. . .

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               address="127.0.0.1"
               redirectPort="8443" />
. . .

    <Connector port="8009" address="127.0.0.1" protocol="AJP/1.3" redirectPort="8443" />

Führe erneut einen Neustart deines Apache Tomcat durch, sodass die Updates übernommen werden.

 systemctl restart tomcat 

Wenn du unserem Tutorial Apache Tomcat zu deinem Webserver & Webcontainer unter Ubuntu 16.04/18.04 gefolgt bist, solltest du eine ufw-Firewall für deine Installation aktiviert haben.

Da alle unsere Anfragen an Tomcat nun auf die lokale Loopback-Schnittstelle beschränkt sind, können wir die Regel aus unserer Firewall entfernen, die externe Anfragen an Tomcat zulässt.

 ufw delete allow 8080 

Dein Apache Tomcat sollte jetzt nur über deinen Web-Server-Proxy zugänglich sein.

Fazit

Zu diesem Zeitpunkt sollten Verbindungen zu deiner Tomcat-Instanz mithilfe eines Webserverproxys mit SSL verschlüsselt sein. Durch die Konfiguration eines separaten Webserverprozesses kann zwar die Software für die Bereitstellung deiner Anwendungen erhöht werden, die Sicherung des Datenverkehrs wird jedoch erheblich vereinfacht. Es hat mir Spaß gemacht, dir in dieser Sache behilflich gewesen sein zu können. ?

Zurück zur Tutorial Übersicht Back to Tutorial Overview

© 2002-2023 Phox inc. all rights reserved.

© 2002-2023 Phox inc. all rights reserved.