User Tools

Site Tools


user:jan001:ba:reverseproxy

This is an old revision of the document!


Reverse Proxy (NGINX)

Ein Reverse Proxy dient dazu einkommende Anfragen zu verwalten und diese an weitere Applikationen weiter zu leiten (Aivaliotis, 2013). Diese Anfragen folgen meist dem HTTP- bzw. HTTPS-Protokoll, aber sind nicht auf diese beschränkt. Im Allgemeinen wird zwischen 2 verschiedenen Reverse Proxy Arten unterschieden. Zum einen dem Protection Reverse Proxy und zum anderen dem Integration Reverse Proxy. Ein Protection Reverse Proxy ermöglicht es Anfragen gezielt zu filtern und nur gewünschte Anfragen durchzulassen. Ein Integration Reverse Proxy ermöglicht es Anfragen auf viele unterschiedliche Systeme zu verteilen. Im Folgenden wird nur der Intergration Reverse Proxy weiter beachtet, da ein Protection Reverse Proxy nicht zu Einsatz kam. (Sommerlad, 2003)

Probleme bei der Bereitstellung von Webapplikationen

Eine Webapplikation besteht meistens nicht nur aus einem Webserver beziehungsweise Webdienst, welcher alle Aufgaben übernimmt, sondern mehreren. Als Entwickler entstehen schwerwiegende Probleme, wenn versucht wird eine Applikation auf lediglich einem Server zu betreiben. Nach Sommerlad gibt es sieben Punkte die es zu beachten gilt:

  • Man kann eine Webapplikation nicht auf einem Server implementieren, da dies die Komplexität erhöht, die Performance oder Wiederverwendbarkeit verschlechtert.
  • Man möchte die allgemeine Netzwerkstruktur der Webapplikation verstecken, um bei Änderung jener beispielsweise Lesezeichen der Nutzer nicht zu zerstören.
  • Das Backend der Webapplikation muss auch funktionieren, wenn sich die Netzwerkstruktur ändert. Wenn eine Applikation des Backends auf eine andere Maschine verschoben wird, darf das die Anderen Applikationen nicht beeinflussen.
  • Man muss die Möglichkeit haben Teile der Netzwerkstruktur zu ändern, ohne andere Teile zu beeinflussen.
  • Man muss die Möglichkeit haben neue Elemente und somit Funktionalität zur Webapplikation hinzufügen zu können.
  • Man muss die Möglichkeit haben Anfragen zwischen mehreren Hosts aufteilen zu können.
  • Das ganze System sollte lediglich über ein einziges SSL Zertifikat verfügen, da SSL Zertifikate einen hohen Preis haben und deren Erneurung koordiniert werden muss.

Die von Sommerlad genannten Punkte sind von hoher Relevanz. Jedoch ist ein Punkt mittlerweile nicht mehr aktuell. SSL-Zertifikate können mittlerweile auch kostenlos bezogen und automatisch erneuert werden. Siehe Verschlüsselung mit TLS. Ein weiterer Punkt mit hoher Relevanz ist die Ausfallsicherheit. Sollte eine Webapplikation lediglich auf einem Server betrieben werden und dieser fällt aus, dann ist die komplette Applikation folglich nicht mehr erreichbar.

Lösung für die Probleme

Unterschrift Nach Sommerlad ist die Lösung der oben genannten Probleme ein Intergration Reverse Proxy. In DARSTELLUNG SOMMERLAD wird eine beispielhafte Implementation eines solchen gezeigt. Ein Benutzer der Webapplikation ruft diese über das Internet auf. Dabei wird aus der URL klar, welchen bestimmten Bereich der Webapplikation der Benutzer aufrufen möchte, beispielsweise der Katalog unter “/catalog”. Die Anfrage geht dann jedoch nicht direkt an den Server, welcher für den Katalog zuständig ist, sondern zunächst einmal an den Reverse Proxy. Dieser befindet sich in einer Demiliarisierten Zone (DMZ). Diese DMZ ist durch zwei Firewalls von den anderen System und dem Internet getrennt.

Eine Firewall kann sowohl physisch in Form von Hardware, als auch digital in Form von Software vorliegen. Eine Kombination von beiden ist auch möglich. Die Hauptaufgabe einer Firewall ist es das dahinter liegende Netzwerk vor unauthorisierten Zugriffen zu schützen. Eine demiliarisierten Zone liegt weder in noch außerhalb einer solchen Firewall, wobei die Server in der Zone sowohl von internen, als auch externen Benutzern erreicht werden können. Sicherheitsrichtlinen verhindern dabei aber, dass externe Geräte und Nutzer direkt an die internen Server beziehungsweise Nutzer verbinden können. (Rababah, Zhou, Bader, 2018)

Wenn die Anfrage dann den Reverse Proxy erreicht, leitet dieser die Anfrage an den jeweilgen Backend-Server weiter. Antworten von einem der Backend-Server werden dann auch über den Reverse Proxy zurück an den Benutzer geleitet.

Vorteile der Lösung

Die wichtigsten Vorteile der Lösung mit einem Intergration Reverse Proxy, welche relevant sind im Rahmen dieser Arbeit sind, werden im folgenden beleuchtet.

Nur ein Hostname

Einer der wichtigsten Vorteile laut Sommerlad ist es, dass es lediglich einen bekannten Host gibt, und zwar den Reverse Proxy. Für den Nutzer muss lediglich die Adresse von diesem bekannt sein, um eine Webapplikation zu erreichen, welche auf mehreren Servern betrieben wird. Dass lediglich ein Hostname benötigt wird bringt noch weitere Vorteile mit sich. Auch ist die allgemeine Netzwerkstruktur der Webapplikation versteckt. Dies macht es für potenzielle Angreifer schwerer Sicherheitslücken zu finden. Weiterhin ist es so möglich einen Teil der Applikation auf einen anderen Server zu verschieben, ohne dass dies für einen Nutzer auffallen würde.

Verschlüsselung mit TLS

Ein Integration Reverse Proxy ermöglicht es auch alle Verbindungen mit dahinterliegenden Backend-Server mit leiglich einem Zertifikat zu verschlüsseln.

Load Balancing

Double Reverse Proxy

user/jan001/ba/reverseproxy.1612804367.txt.gz · Last modified: 2021/08/24 17:34 (external edit)