Reverse Proxy
Vermittler vor den eigenen Servern
Die Idee und ihr Nutzen
Ein Kunde öffnet das Schadenportal seiner Versicherung im Browser unter der Adresse schaden.beispiel.de. Das Schadenportal läuft aber nicht auf einem einzigen Rechner, sondern auf zwei internen Portalservern, deren Adressen der Kunde weder kennt noch kennen soll. Auf beiden Portalservern läuft dasselbe Programm des Schadenportals, deshalb kann jeder der beiden Portalserver jede Anfrage beantworten. Ein eigenes Programm nimmt unter der öffentlichen Adresse alle Anfragen der Kunden entgegen, leitet jede an einen der internen Portalserver weiter und gibt dessen Antwort an den Browser zurück. Zusätzlich kann dieses Programm für alle Portalserver gemeinsam die Verschlüsselung der Verbindung zum Kunden übernehmen oder häufig abgerufene Antworten zwischenspeichern. Ein solches Programm heißt Reverse Proxy. Proxy heißt auf Deutsch Stellvertreter, denn der Reverse Proxy nimmt die Anfragen stellvertretend für die internen Portalserver an.
Wie funktioniert es?
Der Browser des Kunden fordert unter schaden.beispiel.de die Akte zu Schaden 4711 an. Unter dieser öffentlichen Adresse antwortet nicht ein Portalserver, sondern der Reverse Proxy. Der Reverse Proxy nimmt die Anfrage an und wählt Portalserver 2, weil Portalserver 2 gerade weniger zu tun hat. Portalserver 2 prüft selbst, ob der Kunde angemeldet ist und ob Schaden 4711 zu diesem Kunden gehört, lädt die Akte und antwortet dem Reverse Proxy. Der Reverse Proxy gibt die Antwort an den Browser des Kunden weiter. Damit der Reverse Proxy keinen ausgefallenen Portalserver wählt, schickt er den Portalservern regelmäßig Prüfanfragen, kurze Anfragen, an deren Antwort er erkennt, ob ein Portalserver noch arbeitet. Eine Stunde später fällt Portalserver 2 aus und antwortet nicht mehr auf die Prüfanfragen. Der Reverse Proxy lässt Portalserver 2 deshalb bei der Auswahl aus. Der Kunde schickt seine nächste Anfrage an dieselbe Adresse, und der Reverse Proxy leitet sie an Portalserver 1 weiter. Die Antwort kommt wieder über den Reverse Proxy zurück, und der Kunde bemerkt den Wechsel nicht.
Der Reverse Proxy gehört dem Betreiber des Schadenportals und nimmt die Anfragen aus den Browsern der Kunden für die internen Portalserver an. Das unterscheidet den Reverse Proxy von einem gewöhnlichen Proxy, also einem Vermittlungsprogramm, das zum Beispiel eine Firma für ihre Mitarbeitenden betreibt und über das deren Browser ins Internet gehen. Das englische Wort reverse heißt umgekehrt: Der Reverse Proxy vertritt nicht die Nutzer, sondern die Server. Nach welchen Regeln der Reverse Proxy einen Portalserver wählt und welche Zusatzaufgaben er übernimmt, legt der Betreiber bei der Einrichtung fest. Eine dieser Zusatzaufgaben ist das Entschlüsseln: Der Reverse Proxy nimmt die verschlüsselte Verbindung zum Kunden an und entschlüsselt sie. Dafür braucht der Reverse Proxy das Zertifikat von schaden.beispiel.de, den digitalen Echtheitsnachweis der Adresse. Das Zertifikat ist dann nur auf dem Reverse Proxy hinterlegt, nicht auf den Portalservern. Der Reverse Proxy kann außerdem die Zahl der Anfragen pro Absender begrenzen oder häufig abgerufene Inhalte wie Bilder zwischenspeichern. Auch die Verbindung, über die der Reverse Proxy die Anfragen an die Portalserver weiterleitet, muss verschlüsselt sein, wenn das interne Netz nicht vertrauenswürdig ist. Fachliche Regeln kennt der Reverse Proxy nicht. Ob ein angemeldeter Kunde eine bestimmte Schadenakte sehen darf, prüft weiterhin der Portalserver oder ein Baustein, der ausdrücklich dafür eingerichtet ist.
Der Reverse Proxy garantiert nicht, dass das Schadenportal erreichbar bleibt. Auf einen anderen Portalserver leitet der Reverse Proxy nur dann um, wenn Prüfanfragen und Umleitung eingerichtet sind.
Reverse Proxy: eine öffentliche Adresse, zwei interne Portalserver
Wann ist es sinnvoll und wann nicht?
Ein Reverse Proxy lohnt sich
- Mehrere interne Server sollen unter einer gemeinsamen Adresse erreichbar sein. Würde der Browser einen bestimmten Portalserver direkt ansprechen, müsste er dessen Adresse kennen. Fiele dieser Portalserver aus, kämen die Anfragen des Kunden nicht mehr an. Kommt ein dritter Portalserver hinzu, ändert der Betreiber nur die Regeln des Reverse Proxy, und die Kunden brauchen keine neue Adresse.
- Der Betreiber möchte Verschlüsselung, Zertifikat und Zugangsregeln nur auf dem Reverse Proxy festlegen. Regelt jeder Portalserver das einzeln, muss der Betreiber zum Beispiel das Zertifikat auf jedem Portalserver erneuern. Vergisst der Betreiber das auf Portalserver 1, sieht jeder Kunde, dessen Anfrage an Portalserver 1 geht, eine Warnung im Browser.
- Die internen Server sollen aus dem Internet nicht direkt erreichbar sein, und ihre Adressen sollen den Kunden verborgen bleiben. Ohne Reverse Proxy braucht jeder Portalserver eine öffentliche Adresse, und ein Angreifer kann seine Anfragen direkt an jeden Portalserver schicken. Nur Anfragen, die der Reverse Proxy durchlässt, gelangen ins interne Netz.
Ein Reverse Proxy ist nicht das Richtige
- Eine Anwendung läuft auf einem einzigen Server, und Verschlüsselung und Zertifikat lassen sich auf diesem Server einrichten. Ein Reverse Proxy hätte dann keinen zweiten Server, an den er Anfragen weiterleiten könnte. Dann richtet der Betreiber Verschlüsselung und Zertifikat direkt auf diesem Server ein, und der Browser spricht den Server direkt an. Ein weiteres Programm, das installiert, überwacht und mit Sicherheitsupdates versorgt werden muss, entfällt.
- Der Betreiber kann für einen eigenen Reverse Proxy keinen Ausfallschutz aufbauen und betreiben. Ein einzelner eigener Reverse Proxy ohne Ersatz würde bei einem Ausfall das ganze Schadenportal unerreichbar machen, obwohl beide Portalserver laufen. Dann mietet der Betreiber einen Reverse Proxy bei einem Anbieter, der Rechenzentren betreibt und den Ausfallschutz selbst übernimmt.
- Es sollen nur Anfragen auf mehrere gleichartige Server verteilt werden. Dann richtet der Betreiber einen reinen Lastverteiler nach Load Balancing ein. Der Lastverteiler nimmt jede Netzverbindung an und reicht sie an einen der Server weiter, ohne die Anfragen selbst zu lesen. Deshalb braucht der Lastverteiler weder das Zertifikat noch Regeln für einzelne Adressen. Die Verschlüsselung übernehmen dann die Server selbst, und jeder Server braucht das Zertifikat. Zwischenspeichern oder nach dem Inhalt einer Anfrage weiterleiten kann der Lastverteiler nicht.
- Programme von außen brauchen Zugang zu vielen Diensten, und jede Anfrage soll auf ihre Anmeldung geprüft werden. Der Reverse Proxy des Schadenportals prüft keine Anmeldung, also müsste jeder Dienst die Anmeldung selbst prüfen. Dann richtet der Betreiber ein API Gateway ein, einen Reverse Proxy mit zusätzlichen Aufgaben für Programmschnittstellen. Das API Gateway prüft bei jeder Anfrage die Anmeldung, begrenzt die Zahl der Anfragen je angemeldetem Programm und leitet je nach Anfrage an den zuständigen Dienst weiter. Kein Dienst muss die Anmeldung dann selbst prüfen.
Nachteile und typische Fehler
Jede Anfrage läuft durch den Reverse Proxy, also über einen zusätzlichen Zwischenschritt. Der Reverse Proxy braucht deshalb einen eigenen Ausfallschutz. Das kann ein zweiter Reverse Proxy sein, der bei einem Ausfall übernimmt. Außerdem müssen Weiterleitungsregeln, Prüfanfragen und Zertifikate gepflegt werden. Die Portalserver sehen nur noch den Reverse Proxy als Absender. Damit sie die Netzadresse des Kunden erfahren, muss der Reverse Proxy diese Adresse in einem zusätzlichen Feld der Anfrage weitergeben, und die Portalserver müssen dieses Feld auswerten. Eine Einstellung am Reverse Proxy gilt für alle Verbindungen zugleich. Das erleichtert die Pflege, macht aber auch jeden Fehler in dieser Einstellung zu einem Fehler für alle Kunden.
Typische Fehler und woran man sie erkennt:
- Ausfall des Reverse Proxy: Der einzige Reverse Proxy fällt aus, und das gesamte Schadenportal ist nicht erreichbar, obwohl beide Portalserver laufen. Erkennbar ist das an Verbindungsfehlern aller Kunden bei gleichzeitig unauffälligen Portalservern.
- Falsche Weiterleitungsregel: Die Weiterleitungsregel für einen Teil der Adressen des Schadenportals, etwa für das Hochladen von Dokumenten, zeigt noch auf einen Server, den der Betreiber abgeschaltet hat. Der Reverse Proxy schickt diese Anfragen weiter an den abgeschalteten Server. Erkennbar ist das an Fehlermeldungen für bestimmte Adressen des Schadenportals, während andere Seiten funktionieren.
- Verlorene Kundenadresse: Der Reverse Proxy gibt die Netzadresse des Kunden nicht weiter, und die Portalserver protokollieren für alle Anfragen nur die Adresse des Reverse Proxy. Sperrt ein Portalserver einen Absender wegen zu vieler Anfragen, sperrt er damit den Reverse Proxy und so alle Kunden. Erkennbar ist das an Protokollen, in denen jede Anfrage vom selben Absender zu kommen scheint, und an Sperren gegen Missbrauch, die plötzlich alle Kunden treffen.
- Unsichere Verschlüsselung: Am Reverse Proxy ist ein veraltetes Verschlüsselungsverfahren erlaubt oder ein abgelaufenes Zertifikat hinterlegt. Das gefährdet alle Verbindungen auf einmal. Erkennbar ist das an Warnungen im Browser der Kunden oder an Befunden von Sicherheitsprüfungen der öffentlichen Adresse.
- Fehlende Prüfanfragen: Prüfanfragen sind nicht eingerichtet, und der Reverse Proxy schickt nach dem Ausfall von Portalserver 2 weiterhin Anfragen dorthin. Erkennbar ist das an Fehlern für einen Teil der Kunden, solange ein Portalserver ausgefallen ist, während andere Kunden normal arbeiten.
Weiterführend
Verwandte Ansätze
- Forward Proxy: der gewöhnliche Proxy, der die ausgehenden Anfragen der eigenen Rechner ins Internet vermittelt. Der Reverse Proxy nimmt dagegen die Anfragen für die eigenen Server an und vertritt sie.
- Health Checks: beschreibt die regelmäßigen Prüfanfragen, an denen der Reverse Proxy erkennt, dass Portalserver 2 ausgefallen ist.
- Content Delivery Network: verteilt Kopien von Bildern und anderen Dateien auf viele Server an verschiedenen Orten. Ein Content Delivery Network übernimmt das Zwischenspeichern, das ein einzelner Reverse Proxy nur an einem Ort leisten kann.
Quellen
- IETF: RFC 9110, HTTP Semantics: Norm für das Webprotokoll HTTP. Sie unterscheidet den Proxy, den der Nutzer wählt, vom Gateway, auch Reverse Proxy genannt, das gegenüber dem Browser als Server auftritt und Anfragen an interne Server weitergibt.
- NGINX: NGINX Reverse Proxy: Dokumentation eines verbreiteten Reverse Proxy. Sie zeigt das Weiterleiten an einen Server oder eine Servergruppe und wie die Netzadresse des Kunden an den Server weitergegeben wird.
- IETF: RFC 7239, Forwarded HTTP Extension: Norm für ein Feld der Anfrage, mit dem ein Proxy Angaben wie die Netzadresse des Kunden weitergibt, die sonst beim Weiterleiten verloren gehen.