Reverse Proxy

Einleitung

Zielstellung

Ziel war der Aufbau eines Reverse Proxy Servers, der in der Lage ist, verschiedene Webserver zu konsolidieren und in einem virtuellen Serverbaum darzustellen. Wesentlicher Aspekt dabei war die Fähigkeit zum Modifizieren von Links in angefragten HTML Dokumenten, sowie Cookie-Domain-Angaben und ggf. auch Fehlerausschriften.

Was ist ein Proxy?

Ein Proxy Server ist ein Dienst, der sich als Vermittler zwischen die klassischen Client-Server-Kommunikationsprotokolle setzen kann und damit mindestens zwei Client-Server-Verbindungen realsiert. Die bekanntesten Proxy Server sind Caching Proxy Server für HTTP Anfragen an das Internet. Ein Kunde eines Internet Service Providers, der dessen HTTP Proxy benutzt, schickt alle HTTP Anfragen nicht direkt an das Internet, sondern nur an den Proxy des Providers. Dieser guckt zunächst in seinem Cache nach, ob dieselbe Anfrage schon einmal gestellt wurde und die HTTP Antwort immer noch aktuell ist. Wenn ja, wird die Antwort aus dem Cache an den Client zurückgegeben und so unnötiger Verkehr im Internet vermieden. Ist die Antwort noch nicht in dessen Cache vorhanden, so initiiert der Proxy eine HTTP Anfrage an das eigentliche Ziel, speichert die Antwort im Cache ab und gibt sie zugleich an den Kunden zurück. Auf diese Weise agiert der HTTP Proxy als Mittler zwischen dem Browser auf dem PC des Kunden und dem Webserver im Internet.

Forward und Reverse Proxy

Es gibt nun ganz unterschiedliche Arten von Proxy Servern. Kategorisiert man nach der Topologie, in der sich der Proxy befindet, so lassen sich zwei Proxy Arten unterscheiden: Forward und Reverse Proxy. Der Forward Proxy ist der klassische Proxy, der als Mittler zwischen einem Client und dem Server agiert. Der Client muß dabei speziell konfiguriert sein, um die eigentliche Anfrage statt an den Server, zunächst über den Proxy zu leiten.

Ein Reverse Proxy ist im Gegensatz dazu meist vor verschiedenen Webserver logisch vorgeschaltet und soll den Zugriff auf diese Beschränken und so mehr Sicherheit geben. Der Client muß hier nicht speziell konfiguriert werden. Für ihn erscheint der Proxy wie ein ganz normaler Server. Hier liegt die Konfiguration viel mehr auf der Proxyseite. Der Proxy muss nun genau wissen, wohin er welche Anfragen leiten muss. Die erhaltenen Antworten muss der Proxy ggf. umschreiben, sich selber als Absender ausgeben und dann an den Client zurückgeben.

Einsatzszenario

Klassischerweise wird ein solcher Proxy zum Erhöhen der Sicherheit eingesetzt. Betrachten wir zum Beispiel das folgende Szenario. Eine Firma ist direkt an das Internet angeschlossen und betreibt einen internen Webserver, auf dem verschiedene Dienste laufen. Genau ein Dienst davon (z.b. http://serverA/dienst1) soll auch im Internet verfügbar sein. Aufgrund der Sensibilität der Daten von dienstN (N = 2,3,4 ....), muß gewährleistet sein, dass diese Dienste nicht vom Internet aus erreichbar sind.

+--------+    +--------+    +----------+
|Internet| -- |Firewall| -- |WebserverA|
+--------+    +--------+    +----------+

Die Lösung, in der Firewall einfach den Port 80 aufzumachen, würde zwar der Anforderung genügen, dass der Webserver auch vom Internet aus erreichbar ist (eine entsprechende Virtual Server Funktionalität vorausgesetzt), aber so wäre auch der dienstN (N= 2,3,4 ...) vom Internet aus erreichbar. Dies ist also keine gute Lösung.

Unter Einsatz von mehr Hardware oder besseren Firewalls können nun verschiedene Lösungsansätze präsentiert werden. Ein Ansatz besteht im Einrichten eines Reverse Proxys in der DMZ der Firma.

+--------+    +--------+    +---------------+    +--------+    +----------+
|Internet| -- |Firewall| -- | Reverse Proxy | -- |Firewall| -- |WebserverA|
+--------+    +--------+    +---------------+    +--------+    +----------+

Von draußen erscheint der Reverse Proxy nun wie ein eigener Webserver. Dessen Konfiguration impliziert aber die Weiterleitung aller Anfragen an den Dienst 1 auf dem WebserverA. (http://reverseProxy ---> http://serverA/dienst1) Diese Weiterleitung passiert für den Client völlig transparent und nur in der DMZ bzw. im Netz der Firma. Durch diese Konfiguration ist garantiert, dass nur der Teilbaum /dienst1 im Internet publiziert wird. Durch das o.g. Setup kann so noch der direkte Zugriff vom Internet auf den Webserver verhindert werden.

Umsetzung

Potentielle Lösungen

Im Umfang dieses Seminars war nur die Evaluation von zwei Lösungen realisierbar. Zum einen handelte es sich dabei um das wohl bekannteste OpenSource Projekt zum Thema Proxy: Squid (http://www.squid-cache.org/). Die andere Lösung ist das Modul mod-proxy, das zusammen mit dem Apache Webserver 2.x ausgeliefert wird. Der komplette Webserver ist von http://www.apache.org herunterladbar.

Squid

Obwohl Squid durch vielfältigeste Konfigurationsmöglichkeiten glänzt und eine großartige Cacheverwaltung hat, so findet sich in der Konfiguationshilfe kein Hinweis darauf, wie man den selektiven Zugriff auf den Webserver realsieren kann. Es kann mit wenig Aufwand ein interner Webserver gecached werden. Dabei findet aber immer ein 1:1 Matching statt, d.h. ein Proxy cached auch nur einen Webserver. Geht man hier in den Bereich der Multi-Backends, so wird nach DNS Informationen getrennt, also z.B. nach den Hostnamen in der Anfrage und nicht nach der URL in der Anfrage. Eine solche Konfiguration konnte ich nicht herstellen.

Mod-Proxy

Wesentlich vielversprechender ist da schon der Funktionsumfang des Moduls mod-proxy der Apache Foundation. Dies gestattet das Proxying von Anfragen, je nach URL bzw. nach Pfad im Serververzeichnis und eignet sich damit bestens zur Realisierung des Projektziels. Zusätzlich sind auch zahlreiche Einstellmöglichkeiten enthalten, um die weiteren kleinen Probleme, wie die Umschreibung von Links bzw. die Änderung von Cookie-Domains, zu lösen. Mod-Proxy kann auch mit SSL Anfragen umgehen und somit auch als SSL Gateway fungieren.

Demonstration / Beispiel

Im Rahmen des Projektes wird damit eine Demonstration aufgebaut, die aus drei Servern besteht, die jeweils unter Ubuntu Server LTS 6.06 laufen. Dort ist jeweils ein Apache Webserver 2.0.55 mit dem mod_proxy Version 2.4 installiert. Es wird unbedingt empfohlen, Apache 2.x zu benutzen, da das im Apache 1.x enthaltene mod_proxy nur HTTP 1.0 beherrscht. In späteren Versionen wird aber auch HTTP 1.1 unterstützt. Ein Upgrade wird hier uneingeschränkt empfohlen.

Der prinzipielle Setup sieht so aus:

                                  +-------+
                                  |ServerA|
                                  +-------+
                                 /
+----------+    +---------------+
| Internet +----+ Reverse Proxy | 
+----------+    +---------------+
                                 \
                                  +-------+
                                  |ServerB|
                                  +-------+

Die Dienste von den Servern A und B sind dort jeweils unter http://serverA bzw. http://serverB erreichbar. Wir nehmen weiter an, dass eine Firewall den direkten Zugriff vom Internet auf die Server unterbindet. Nur ein Zugriff auf den Port 80 des Proxys ist zugelassen.

Die Anfragen an den Proxy werden dann wie folgt weitergeleitet:

• http://revproxy/dienst1 --> http://serverA
• http://revproxy/dienst2 --> http://serverB

Auch Anfragen auf Unterverzeichnisse sollen adequat weitergeleitet werden, also http://revproxy/dienst1/mydir --> http://serverA/mydir Alle anderen Anfragen werden proxy-lokal beantwortet, d.h. es findet keine Weiterleitung statt.