Manche Proxies kennen Möglichkeiten, um dieses Problem zu umgehen. SNIProxy lässt sich in einem transparenten Modus betreiben, in dem die Quell-Adresse der Verbindungen beibehalten wird.

SNIProxy im transparenten Modus

SNIProxy in den transparenten Modus zu versetzen ist auf den ersten Blick ganz einfach: Über die Konfigurationsdirektive source client im passenden Listener teilt man dem SNIProxy mit, er möchte doch bitte als Quell-Adresse für die Verbindungen gegen innen die ursprüngliche IP des Clients verwenden, z.B. so:

listen 192.168.1.15 80 {
   proto http
   source client
....

Als Beispiel verwenden wir 192.168.1.15 als IP für den Proxy. Es gibt dabei allerdings die eine oder andere Hürde zu umschiffen:

• Der transparente Modus funktioniert nur bei Listenern, die nur eine IP-Version verwenden. Es ist also notwendig, separate Listener für IPv4- und IPv6-Verbindungen einzurichten. In obigem Beispiel geben wir explizit die Adresse an, auf die der Listener hören soll, d.h. wir legen uns in diesem Beispiel auf IPv4 fest.
• Die Antwort-Pakete der Webserver, auf die SNIProxy weiterverbindet, müssen durch den Proxy-Rechner geroutet werden. Im einfachsten Fall wird dieser als Router aufgesetzt und die Webserver erhalten ihn als Default-Gateway.
• Auf dem Proxy-Rechner selbst muss per IPTables dafür gesorgt werden, dass die Pakete auch tatsächlich durch den transparenten Proxy laufen.
   

iptables und Policy Route auf dem Proxy-Rechner

Damit der Transparentmodus richtig funktioniert, müssen Pakete passend geleitet werden. Dies geschieht durch eine separate Routing-Tabelle, auf die Pakete per Markierung durch iptables geleitet werden:

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Auf dem Proxy-Rechner muss ausserdem Forwarding eingeschaltet sein, z.B. durch folgende Einträge in /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Webtraffic auf den Webservern durch den Proxy umleiten

Im einfachsten Fall wird ganz einfach die Default-Route der Webserver auf den Proxy gelegt. Das ist nicht immer praktikabel. Eine Variante davon ist, lediglich die Antworten des Webservers über den Proxy umzuleiten. Auch dies gelingt mit einer Policy-Route und einer iptables-Markierung, etwa so:

iptables -t mangle -A OUTPUT -p tcp --sport 443 -j MARK --set-mark 0x8
iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 0x8

ip rule add fwmark 8 lookup 101
ip route add 192.168.1.15 dev eth0 table 101
ip route add default via 192.168.1.15 table 101

Auch hier gegen wir als Beispiel wieder vom auf der Adresse 192.168.1.15 laufenden Proxy aus und leiten alle ausgehenden Pakete mit Quellport 80 oder 443 auf diesen um.

Im Grunde genommen ein Mittelsmann. Im Umfeld von Computern ist das Konzept weitgehend identisch. Ein Web-Proxy ist einfach ein Stück Software, das eine HTTP-Anfrage für Sie weiterleitet.

Was ist ein Proxy?

Google definiert einen Proxy als

ein Befugter eine andere Person zu vertreten

HTTP-Proxies sind eine wesentliche Komponente bei der täglichen Nutzung des Internets – Load Balancer, Router, Contentbeschleuniger, Content-Protection-Systeme, das sind alles einfache Beispiele für Web-Proxies und sie alle fungieren als Vermittler, um Ihre HTTP-Anfragen dorthin zu senden, wo sie hin müssen, sie anonymisieren Anfragen, routen Netzwerkverkehr, beschleunigen das Netz und erfüllen viele andere Anwendungszwecke.

Wenn es darauf ankommt, fallen die meisten Web-Proxys in zwei Lager:

1. Reverse-Proxies – Ein Reverse-Proxy ist in der Regel ein nach innen gerichteter Proxy, der als Frontend zur Kontrolle und zum Schutz des Zugriffs auf Server in einem privaten Netzwerk verwendet wird. Ein Reverse-Proxy führt in der Regel auch Aufgaben wie Load-Balancing, Authentifizierung, Entschlüsselung oder Caching aus.

2. Forward-Proxies – Ein Forward-Proxy ist ein nach aussen ins Internet gerichteter Proxy, der verwendet wird, um aus einer Vielzahl von Quellen abzurufen.

Betrachten wir diese beiden Typen im Detail.

Was ist ein Reverse-Proxy

Sie verwenden wahrscheinlich einen Reverse-Proxy, um diesen Inhalt anzuzeigen. Wenn Sie eine Anfrage an den Server stellen, der diesen Blog-Post bedient, geht er durch einen Load Balancer. Dieser Load Balancer ist einer der Reverse-Proxy-Typen.

Reverse-Proxies sitzen vor einem von mehreren Servern und verteilen Anfragen an diese Server. Häufige Beispiele dafür sind das proxy_pass-Modul von Nginx, HAProxy, Squid und AWS‘ ELB.

Ein Reverse-Proxy empfängt eine Anfrage von einem Client im Internet und holt die angeforderten Ressourcen von einem von mehreren Servern, die dahinter stehen. Für den Client ist kein Wissen über die Server (oft auch Upstream-Server genannt) erforderlich, die den ursprünglichen Inhalt bereitstellen, und sie können nach Bedarf geändert werden, ohne dass die externen Clients von dieser Änderung wissen müssen. Der Reverse Proxy allein verarbeitet diese Informationen.

Als Teil dieser Bearbeitung der Anfrage bietet der Reverse-Proxy oft zusätzliche Funktionalität, wie z.B. SSL-Terminierung, die Durchführung von Authentifizierung und/oder Autorisierung, Beschleunigung (Caching oder Komprimierung) von Inhalten oder das Umschreiben von Anfrage und/oder Antwort.

Das Wort «reverse» im Namen Reverse-Proxy hat keine besondere Bedeutung, es wird nur verwendet um auf die Natur des Reverse-Proxys als Umkehrung des Forward-Proxys hinzuweisen. Letzteres hat – wie Sie anschliessend lesen werden – tatsächlich eine Bedeutung.

Was ist ein Forward-Proxy

Forward-Proxies werden häufig verwendet, um den Datenverkehr aus Netzwerken zu steuern. Wenn Sie eine Anfrage über den Proxy senden, leitet er Ihre Anfrage an die gewünschte Website weiter, daher der Name «Forward-Proxy» (“weiterleitender Proxy”).

Eine gängige Aufgabe eines Forward-Proxys ist es, sowohl den Zugriff auf das Internet zu steuern, indem bestimmte Attribute überprüft werden, während die Anfrage bearbeitet wird. Wenn Sie sich in einem Unternehmensnetzwerk befinden und es Ihnen untersagt ist, auf ein soziales Netzwerk wie facebook.com zuzugreifen, wird dies oft die Aufgabe eines Forward-Proxys sein. Der Forward-Proxy ist in der Lage, den Host-Teil der Anfrage zu inspizieren, und da in einem Unternehmensnetzwerk der Datenverkehr oft gezwungen ist, über den Proxy zu fließen, wird er alle Anfragen ablehnen, die den verbotenen Host verwenden.

Eine ähnliche Implementierung wie die obige scannt den ausgehenden Inhalt der Payload, während sie durch den Proxy geht. Dies kann für eine Vielzahl von Datenschutzanwendungen genutzt werden, z.B. zur Data Loss Prevention oder zur Überprüfung von Inhalten auf bösartige Software.

Ein weiterer häufiger Anwendungsfall für einen Forward-Proxy ist die Anonymisierung der Stelle, von der die Anfrage ursprünglich kam.

Der Forward-Proxy befindet sich zwischen den Anfragen des Benutzers und dem Internet. Wenn der Forward-Proxy eine Anforderung an einen Host sendet, sieht der Host-Computer die IP-Adresse des Forward-Proxy und nicht die des Benutzers. Dies wird häufig verwendet, um IP-Anonymisierung durchzuführen und ist ein wesentliches Merkmal von VPNs.

Layer 7 versus layer 3

Meistens bezieht sich der Begriff «Proxy» auf eine Layer-7-Anwendung auf dem OSI-Referenzmodell. Eine weitere Möglichkeit des Proxying ist jedoch über Layer-3 und ist bekannt als Network Address Translation (NAT). Der Unterschied zwischen diesen beiden Proxy-Technologien besteht in der Schicht, in der sie arbeiten, und der Vorgehensweise bei der Konfiguration der Proxy-Clients und Proxy-Server.

Layer-7-Proxies sind besser geeignet, wenn Sie den Inhalt der Anfrage überprüfen, um ein Routing durchzuführen oder anderweitig den Inhalt der Anfrage zu verändern.

Dieser Artikel wurde ursprünglich publiziert auf Very Good Security.

Siehe auch

• https://www.youtube.com/watch?v=s25cSWkGD38
• https://www.quora.com/Whats-the-difference-between-a-reverse-proxy-and-forward-proxy
• http://www.jscape.com/blog/bid/87783/Forward-Proxy-vs-Reverse-Proxy
• https://www.citrix.com/blogs/2010/10/04/reverse-vs-forward-proxy/
• https://www.google.com/search?q=forward+versus+reverse+proxy
• http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#forwardreverse

• mehrere Webserver stellen Websites/Webanwendungen/Webdienste zur Verfügung
• aus Sicht des Anwenders/Netztopologie sollen all diese zum einem einzigen Knoten zusammengefasst sein – z.B. aus Gründen der Sicherheit, der Flexibiliät (Umzug von Webdiensten ohne DNS-Änderungen), oder Adressknappheit
• nebst unverschlüsseltem HTTP soll unbedingt auch HTTPS unterstützt werden

Ansatz: Reverse Proxy

Die logische Antwort auf eine solche Herausforderung stellt ein Reverse Proxy dar, der aus Sicht von ausserhalb alle Web-Anfragen per HTTP und HTTPS entgegennimmt und diese an die internen Server weiterreicht. Typischerweise kommen hier Produkte wie Apache oder NGINX zum Einsatz.

Der klassische Ansatz hat auch Nachteile:

• alle Requests werden zweifach bearbeitet, einmal vom Proxy, einmal vom eigentlichen Webserver
• Inkompatibilitäten machen dem Admin das Leben schwer
• die Latenz steigt, die Performance leidet
• sehr flexible Lösung mit entsprechend aufwändiger Konfiguration
• SSL-Zertifikate und -Schlüssel müssen auf dem Reverse-Proxy vorliegen (das kann auch ein Vorteil sein)

leichtgewichtige Variante: Reverse Proxying mit SNIProxy

SNIProxy ist ein simpler Proxy mit sehr überschaubarem Funktionsumfang und entsprechend einfacher Konfiguration. Als "Border Proxy" zwischen Anwender/Anwendung und Webserver erlaubt er es, abhängig vom Servernamen ("Virtual Host") Requests 1:1 an den dazu passenden Webserver weiterzureichen – und zwar sowohl HTTP- als auch HTTPS-basierte. Anders als vollwertige Reverse Proxies verarbeitet er selber die Anfragen nicht, sondern reicht sie unverändert an den jeweiligen Webserver durch. Sämtliche typischen Kompatibilitätsprobleme entfallen und Probleme mit Performance oder Latenz entfallen.

Da der SNIProxy auch SSL-Verkehr nicht selber auswertet, sondern lediglich den per SNI übermittelten Servernamen auswertet und den Aufbau der SSL-Verbindung dem Zielserver überlässt, benötigt er keinerlei SSL-Konfiguration – diese wird wie gewohnt auf den eigentlichen Webservern durchgeführt.

Natürlich sind auf Grund der einfachen Funktion auch die Einsatzszenarien begrenzt. Z.B. erlaubt SNIProxy nicht:

• URLs umzuschreiben
• Requests vorzufiltern und etwaige gefährliche Requests bereits auf dem Proxy zu blockieren

Eine simple Konfiguration von SNIProxy könnte so aussehen:

user daemon

pidfile /var/run/sniproxy.pid

listen 80 {
   proto http
   table hosts
   access_log {
     filename /var/log/sniproxy/access.log
   }
}

listen 443 {
   proto tls
   table hosts
   access_log {
     filename /var/log/sniproxy/access.log
   }
}

table hosts {
   server1.example  192.168.1.13
   server2.example 192.168.1.14
}

D.h. SNIProxy hört auf die Ports 80 und 443 und leitet Anfragen abhängig vom vom Client angesprochenen Servernamen auf die internen Adressen 192.168.1.13 oder 192.168.1.14 um (auf denselben Port wie beim urspr. Request).

IP-Adresse loggen / transparenter Proxy

Ein Problem, das im Zusammenhang mit Reverse Proxies regelmässig auftritt, ist, dass es für den Webserver hinter dem Proxy so aussieht, als würde der Request vom Proxy selbst kommen. Entsprechend landet in den Log-Files des Webservers die IP-Adresse des Proxies, Mechanismen wie Sperren bei wiederholt falschen Login-Versuchen o.ä. betreffen alle Requests, und last-but-not-least sind Logauswertungen mit Tools wie Webalizer oder AWStats relativ nutzlos.

SNIProxy bietet als Ausweg aus diesem Dilemma die Möglichkeit an, Verbindungen so durchzuschleifen, dass aus Sicht des Webservers der Zugriff von der Original-IP des Clients aus erfolgt. In einem der nächsten Beiträge hier werden wir ein entsprechendes Setup beschreiben.