Tiefgehende Betrachtung: Was ist ein Forward Proxy?

Wir verwenden häufig NGINX oder Apache als Load Balancer und Reverse-Proxy-Server, selbst wenn externer Netzwerkverkehr über diese Software weitergeleitet wird, um die eigentlichen Dienste im internen Netzwerk zu erreichen. Während es einen Reverse-Proxy gibt, existiert auch ein Forward-Proxy. Lassen Sie uns ihre Funktionalitäten näher betrachten.

Reverse Proxy

Vom OSI-Modell zu Proxy-Servern

Beim Zugriff auf Internetdienste verwenden wir in der Regel das HTTP-Protokoll, das auf der Schicht 7 des OSI-Modells arbeitet. Bekannte Komponenten dieses Protokolls wie Hostnamen, Pfade und Abfrageparameter sind Teile dieser Schicht. Das HTTP-Protokoll basiert auf TCP- oder UDP-Protokollen, die auf der Schicht 4 des OSI-Modells arbeiten, und die Konzepte der Ports, die während des Dienstzugriffs verwendet werden, existieren innerhalb dieser Protokolle. Weiterhin basieren sowohl TCP als auch UDP auf dem Internet Protocol (IP), das auf der Schicht 3 des OSI-Modells arbeitet, wo IP-Adressen als „Hausnummern“ des Internets dienen.

Wenn wir ein IP-Netzwerk verwenden, um auf das Internet zuzugreifen, ist das IP-Protokoll dafür verantwortlich, das Ziel zu adressieren, Datenpakete gemäß den Regeln zu kapseln und sie von der Quelladresse zur Zieladresse innerhalb des IP-Netzwerks weiterzuleiten. Beispielsweise reist der Netzwerkverkehr vom lokalen Netzwerk eines Besuchers über das vom ISP bereitgestellte Gateway-Gerät, verbindet sich mit dem Netzwerk des ISP, bevor er auf die Dienste eines Ressourcenanbieters zugreift.

An diesem Punkt verwenden wir ein Gateway, um auf das Internet zuzugreifen. Wenn wir über Proxy-Server sprechen, können wir eine Parallele zum IP-Netzwerk ziehen. Proxy-Server fungieren als Gateways, die die Lücke überbrücken, um Clients beim Zugriff auf Dienste zu unterstützen. Sie arbeiten im Wesentlichen zwischen der Schicht 4 und der Schicht 7 des OSI-Modells und fallen tatsächlich unter die Schicht 5 des OSI-Modells.

API7-OSI Modell

Zwecke von Proxy-Servern

Proxy-Server werden typischerweise für die folgenden Zwecke eingesetzt:

Zentralisierter Ausgang für den Zugriff auf das interne Netzwerk

Unternehmen haben oft bestimmte Anforderungen an die Informationssicherheit, wie Zugriffskontrolle und Verkehrsprotokollierung. Mit der Verbreitung von verschlüsseltem Verkehr wie HTTPS, der den Netzwerkverkehr unter Passwörtern verbirgt, wird es schwierig, diesen an der Netzwerkgrenze zu protokollieren und zu überprüfen, was das Risiko von Lecks erhöht. Die Existenz eines Proxy-Servers dient als einheitlicher Verkehrsausgang, der als Vermittler fungiert, um die Aufgaben der Verkehrsüberprüfung zu übernehmen.

Neben menschenorientierten Zwecken können Proxy-Dienste auch als Ausgang für programmatische Dienste dienen, die auf das externe Netzwerk zugreifen. Beispielsweise, wenn ein Dienstleister Webhook-Funktionalität anbietet, muss er den Verkehr über einen festen Ausgang leiten, indem er eine einzelne feste IP-Adresse oder einen Bereich fester IP-Adressen verwendet. Dies erleichtert es dem Empfänger von Webhook-Aufrufen, diese korrekt in der Firewall zu whitelisten. Wenn dies nicht geschieht, sind beide Seiten von Webhook-Aufrufen potenziellen Sicherheitsrisiken ausgesetzt.

Verbergen der Identität des Besuchers

Manchmal möchten Internetnutzer ihre Identität, wie ihre IP-Adresse, verbergen. In solchen Fällen kommen transparente Proxy-Server ins Spiel. Der Client verbindet sich zunächst mit dem Proxy-Server, gibt die echte Dienstadresse an, zu der er eine Verbindung herstellen möchte, und greift dann über den Proxy-Server mit dem HTTPS-Protokoll auf den Zielservice zu. Die Anwesenheit des Proxy-Servers stellt sicher, dass die Identität des Clients verborgen bleibt, während die Verwendung eines verschlüsselten Protokolls garantiert, dass der Proxy-Server während dieses Prozesses keine Daten stehlen kann.

Forward Proxy

HTTP-basierter Proxy

Auf Proxy-Servern begegnen wir typischerweise HTTP-basierten HTTP-Proxys und binärbasierten Protokollen wie SOCKS 4/5. Sie erfüllen ähnliche Funktionen, aber mit unterschiedlichen Implementierungsmethoden. Konzentrieren wir uns auf HTTP-basierte Proxys.

In den frühen Stadien der Protokollimplementierung war der Verkehr auf HTTP hauptsächlich Klartext. Diese Transparenz ermöglichte es Proxy-Servern in der Mitte zwischen Client und Dienst, URLs und Anfrageinhalte mühelos zu analysieren. Durch DNS-Auflösung und ähnliche Prozesse konnte der Proxy eine Verbindung zum Dienst mit seiner eigenen Netzwerkadresse herstellen und so den Client verbergen.

Ein Beispiel für einen solchen Aufruf ist wie folgt:

GET http://example.com/resource HTTP/1.1
Proxy-Authorization: Basic encoded-credentials

Der Proxy-Server versteht die Adresse, auf die der Client zugreifen möchte, und sendet eine Anfrage an den Dienst, um eine Antwort zu erhalten, die dann an den Client zurückgegeben wird.

HTTP/1.1 200 OK
Content-Type: text/html
...
body blahblah
...

Dies stellt die einfachste Implementierungsform eines HTTP-Proxy-Servers dar. Allerdings beobachten wir Nachteile: Der Proxy-Server verarbeitet den Client-Verkehr im Klartext, was ein potenzielles Sicherheitsrisiko darstellt, da er den Benutzerverkehr während der Weiterleitung aufzeichnen könnte. Daher ist die Berücksichtigung von Verschlüsselungsmethoden notwendig, um die Sicherheit zu gewährleisten.

Komplexe Funktionsweise von HTTPS-Verkehr und Proxy-Servern

Mit der Zunahme des Anteils von HTTPS-verschlüsseltem Verkehr innerhalb des gesamten HTTP-Verkehrs müssen sich Proxy-Server an dieses Szenario anpassen.

Es ergibt sich jedoch eine Herausforderung: Der vom Client an den Dienstleister gesendete Verkehr ist nun verschlüsselt. Der Proxy-Server kann nicht verstehen, auf welche Ressource der Client zugreift, da der Verkehr durch einen Schlüsselverhandlungsmechanismus basierend auf asymmetrischen Verschlüsselungsalgorithmen zwischen Client und Dienstleister geschützt ist, und der nachfolgende verschlüsselte Verkehr symmetrische Schlüssel verwendet, die von einem Man-in-the-Middle während der Kommunikation nicht erlangt werden können. Der grundlegende Zweck von TLS besteht darin, die Möglichkeit von Man-in-the-Middle-Angriffen zu verhindern.

Wie funktioniert also der Proxy-Server in diesem Fall?

Dies ist im Vergleich zur vorherigen Methode der Klartext-Anfrageanalyse komplexer. Das HTTP-Protokoll führte eine spezielle Anfragemethode CONNECT ein. Der Client verwendet diese Methode, um eine erste Anfrage an den Proxy-Server zu senden:

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: Basic encoded-credentials

Der Client sendet eine CONNECT-Anfrage an den Proxy-Server, einschließlich der Domain oder IP-Adresse und des Ports, zu dem der Client eine Verbindung herstellen möchte. Nach Erhalt der Anfrage stellt der Proxy-Server eine TCP-Verbindung mit dem Zielservice her und speichert die Port-Zuordnung zwischen Client und Dienst. Anschließend kann der Client die korrekte Anfrage an den Proxy-Server senden, der den Verkehr unverändert an den Dienst weiterleitet, ohne zu versuchen, die Daten zu analysieren. Daher ist die verschlüsselte Kommunikation von HTTPS zuverlässig.

Dieser Mechanismus ist im Vergleich zu Klartext-HTTP-Proxys vielseitiger. Sobald die erste HTTP-Anfrage den Proxy-Server über die Informationen zur Herstellung einer Verbindung informiert, wird er im Wesentlichen zu einem transparenten Proxy-Kanal. Er kann die Kommunikation sowohl für HTTPS als auch für TCP-Binärverkehr (wie SSH) über den Proxy-Server ermöglichen.