Reverse Proxy und Webserver
Alle Reverse-Proxies sind Plugins und müssen zuerst installiert werden.
Warum sollte ein Reverse-Proxy verwendet werden?
Der Paketfilter selbst kann nicht entscheiden, was in Anwendungsprotokollen geschehen soll. Für eine solche Prüfung können Sie Deep Packet Inspection oder einen Reverse Proxy verwenden.
Darüber hinaus kann ein Reverse-Proxy protokollspezifische Zugriffskontrolllisten sowie weitere Prüfungen zum Schutz der dahinter liegenden Anwendung implementieren. Solche Prüfungen sind Malware-, Spam-, Webangriffserkennung und so weiter.
Reverse Proxies unterstützen Sie dabei, häufige Angriffe auf Ihre Webanwendung durch Bots zu verhindern, werden aber nie eine 100-prozentige Erfolgsquote bei der Erkennung von schädlichem Datenverkehr bieten. Insbesondere ein gezielter Angriff wird sehr wahrscheinlich nicht erkannt, weil viel Aufwand betrieben wurde, um eine Erkennung zu verhindern. Verwenden Sie einen Reverse-Proxy nicht als Ersatz / Ausrede dafür, dass Sie die Hauptprobleme wie bekannte Sicherheitslücken in Bibliotheken, veraltete Software oder Sicherheitslücken in Ihrem eigenen Code nicht durch Aktualisieren / Entfernen oder durch Ändern Ihres eigenen Codes beheben.
Unterstützte Reverse Proxies im Schulrouter Plus
ftp-proxy | Ermöglicht FTP |
nginx | HTTP, TCP- und UDP-Streams |
HAProxy | HTTP- und TCP-Streams |
postfix | SMTP (E-Mail) |
relayd | TCP-Streams |
Begriffe
Forward Proxy
Ein Proxy, der von einem Client verwendet wird, um eine Verbindung zum Internet herzustellen. Er wird normalerweise in Unternehmen eingesetzt, um den Datenverkehr auf Malware zu scannen. Weitere Hintergrundinformationen finden Sie auf den spezielleren Seiten (Caching-Proxy).
Reverse Proxy und Webserver
Ein Reverse-Proxy ist eine Software, die eine Anfrage oder eine Verbindung von einem Client entgegennimmt und sie an einen Upstream-Server sendet. Er kann bei Bedarf einige Daten ändern (z. B. HTTP-Header einfügen oder Zugriffskontrolle durchführen). Ein Reverse-Proxy kann für jedes Protokoll generisch sein, wird aber üblicherweise für HTTP(S) verwendet.
Ein Reverse-Proxy muss nicht vollständig wissen, welche Daten er überträgt, er muss nur wissen, welcher Upstream für die Verarbeitung zuständig ist und einige Metadaten, um zu wissen, was er tun soll (z. B. für die Zwischenspeicherung eines Cache-Control-Headers und für die Autorisierung eines Authentifizierungs-Headers in HTTP).
Ein Webserver verarbeitet im Gegensatz zu einem Reverse-Proxy schließlich die Anfrage (der Webserver enthält die Geschäftslogik in der Webanwendung) und sendet je nach Anfrage eine Antwort, die von einem Reverse- (z. B. Varnish, nginx) oder Forward-Proxy (siehe Anti-Virus-Schutz einrichten, Caching-Proxy einrichten) verändert oder zwischengespeichert werden kann. Ein Webserver serviert z. B. eine Datei namens index.html aus dem lokalen Dateisystem oder verarbeitet einen API-Endpunkt und gibt das Ergebnis zurück. Ein Webserver verfügt normalerweise über eine API zum Aufrufen externer Interpreter:
API | Typischer Anwendungsfall | Implementiert bei (Beispiele) |
|---|---|---|
FastCGI | PHP, Rails | PHP-FPM, nginx, Apache HTTPd |
AJP | Java-Anwendungsserver | Tomcat, JBoss, WildFly, Apache HTTPd (mod_jk) |
(U)WSGI | Python | Django über UWSGI |
Andere binden den Interpreter direkt in den Webserver ein, sind in dieser Sprache oder in einer C/C++-Erweiterung geschrieben:
Technologie | Benutzt für |
|---|---|
Fahrgast | Applikationsserver für verschiedene Sprachen |
nginx Einheit | Applikationsserver für verschiedene Sprachen |
Unterwasserschiff (Raw, JBoss, WildFly) | Java-Anwendungsserver |
Apache Tomcat | Java-Anwendungsserver |
Python-Anwendungsserver | |
Apache HTTPd (mit Modulen wie mod_php) | Webserver mit Dolmetschermodulen |
Upstream, Backend
Ein einzelner oder mehrere Server, die für den Lastausgleich der Client-Anfrage verwendet werden können. Alle in einem Upstream verwendeten Server müssen gleich agieren (gleiches Protokoll etc.), müssen aber nicht auf dem gleichen Port laufen.
Upstream-Server, Backend-Server
Dies ist Ihre lauschende Anwendung wie nginx auf Port 80 für HTTP oder Ihr LDAP-Server auf TCP/389.
Frontends (HAProxy) und HTTP(S)/Stream Server (nginx)
Dies sind die Konfigurationen für die Ports, die für eingehende Verbindungen verwendet werden. Wenn Sie z. B. einen Port an TCP/80 (Standardport von HTTP) binden, können Sie entscheiden, was mit dieser Anfrage geschehen soll. Das Gleiche gilt für Verbindungen.
TLS und SSL
TLS hat SSL abgelöst und dient zum Schutz des Anwendungsprotokolls gegen eine Vielzahl von Angriffen wie Schnüffeln oder Datenmanipulation (z. B. Ad-Injection, Redirects, Manipulation von heruntergeladenen Dateien wie Executables).
Moderne Clients und Server sollten TLS 1.2 und TLS 1.3 unterstützen. Alle anderen sollten deaktiviert sein.
TLS - Verschiedene Möglichkeiten der Nutzung
1) Unterbrechung der Verbindung an der Firewall (Down- und Upstream verwenden TLS)
In diesem Setup haben wir zwei TLS-geschützte Verbindungen. Eine vom Client zur Firewall, und eine von der Firewall zum Backend.
Der Vorteil dieses Setups ist, dass Sie es für die Weiterleitung auf der Basis von Pfaden oder anderen Eigenschaften verwenden können und dem Client ein anderes Zertifikat präsentieren können. Sie können z. B. ein internes Zertifikat auf dem Server verwenden und der Reverse-Proxy präsentiert dem Client ein wahrscheinlich vertrauenswürdiges Zertifikat wie eines von Let’s Encrypt. Dies vereinfacht die Handhabung von Zertifikaten, da der Upstream-Client ungültig (z. B. veraltet) sein kann. Bitte beachten Sie, dass es nicht empfohlen wird, die Zertifikatsüberprüfung im Upstream zu deaktivieren, aber es kann in einigen Setups erforderlich sein.
2) Entschlüsseln eines verschlüsselten Upstreams (Downstream einfach, Upstream TLS-geschützt)
Dieses Setup macht in den meisten Fällen nicht viel Sinn. Sie kann den Vorteil haben, wenn Sie Probleme mit einer Software haben, die einen nicht verschlüsselten Port nicht zulässt, aber ein spezieller interner Client diesen nicht unterstützt. Zum Beispiel muss ein Rechner mit einem Server sprechen, kann aber kein TLS verwenden, weil die Hardware es nicht unterstützt. Wenn Sie das brauchen, stellen Sie es nicht über das Internet zur Verfügung, weil es wahrscheinlich einen Grund gibt, dass der vorgeschaltete Server nur TLS unterstützt.
3) TLS Offloading (Downstream ist TLS-geschützt, Upstream ist einfach)
Dieser Aufbau sollte bevorzugt werden, wenn er unterstützt wird. Es hat den Vorteil, dass es TLS für den Client vollständig unterstützt, während es nicht viel Leistung benötigt, um einen TLS-Handshake im eigenen Rechenzentrum durchzuführen.
Sie sollten dies nicht für Upstream-Server verwenden, die über nicht vertrauenswürdige Newtworks erreichbar sind. Verwenden Sie in solchen Fällen (1) oder (4).
(4) TLS-Durchschleifen
In diesem Modus durchläuft der Proxy nur die Verbindung und hat keinen Zugriff auf die verschlüsselte Nutzlast. Sie können nicht auf irgendetwas des Protokolls selbst abgestimmt werden. Sie können einige Erweiterungs-Header wie SNI verwenden, um zu entscheiden, welcher Upstream verwendet wird. Diese Einstellung wird empfohlen, wenn Sie nur einige verbesserte Routing-Entscheidungen wünschen, die besser sind als einfaches NAT.
Ein Reverse-Proxy kann trotzdem auf den verschlüsselten Inhalt zugreifen, wenn er den privaten Schlüssel des Servers hat und eine Chiffre ohne PFS verwendet wird. In anderen Fällen kann die Verbindung nur entschlüsselt werden, wenn einer der Peers den Schlüssel hinterlegt. Firefox unterstützt dies über die Umgebung SSLKEYLOGFILE. Dies wird von den Schulrouter Plus-Plugins nicht unterstützt.