Sinn eines Reverse Proxy

Commerzpunk

Hallo,
ich lese immer wieder "Reverse Proxy".
Grundsätzliche habe ich verstanden, was er macht und traue mir auch zu dies einzurichten.
Mich reizt der Gedanke "das macht es sicherer".

Im Moment laufen bei mir 2, 3 Dienste, die ich über DDNS von außen erreichen kann, dies einfach per Port Forwarding am Router.

Die grundsätzliche Erklärung für Reverse Proxy, und warum es sicher ist, lautet nach meinem Verständnis ja: Anstatt direkt auf den sensiblen Port 80 zuzugreifen, leitet der Reverse Proxy den nach außen offenen Port 8089 nach innen auf den zu schützenden Port 80 um. Dazu stellen sich mir 2 Fragen, weswegen ich wahrscheinlich Reverse Proxy nicht verstehe:

1. Warum ist es sicherer Port 8089 zu verwenden anstatt 80, bzw. warum werde ich über 8089 nicht gehackt?
2. Was unterscheidet den Reverse Proxy 8089 > 80 vom Port Forwardung am Router 8089 > 80 bzw. warum ist das eine besser als das andere?

Danke für Erhellung und Berichte aus der Praxis

DaVu

https://de.wikipedia.org/wiki/Reverse_Proxy

Das erklärt schon ziemlich viel

edit:

Das ist vielleicht noch besser:

https://www.ionos.de/digitalguide/s…-reverse-proxy/

Commerzpunk

Hm, danke für deine Mühe, jedoch erklärt es für nicht nicht meine beiden Fragen.

Was ein RP macht habe ich schon verstanden, ich erkenne nur die Vorteile bzgl. Sicherheit, gerade im Vergleich zu Port Forwarding, nicht.

Liest sich wie „genau das gleiche nur viel komplizierter einzurichten“

DaVu

Über einen Proxy kannst du mehrere Services über die gleiche IP und den gleichen Port verfügbar machen. Bei Portforwarding an deinem Router müsstest du mehrere Porst benutzen um verschiedene Services dahinter zu erreichen. Dem Proxy kannst du, je nach Aufruf, gewisse Dienste zuweisen.

Portfarwarding ist nicht viel was anderes wie destination NAT oder auch reverse NAT. Ein Router übersetzt die eine IP des ankommenden Pakets und sendet es unkontrolliert an eine Ziel-IP in deinem Netzwerk ohne zu wissen, welche Applikation dahinter läuft. Das ist dem Router egal, wenn er Portforwarding macht. Ein Proxy arbeitet im OSI-Modell auf einem anderen Layer als Portforwarding es macht und ist so besser auf die Applikation zu konfigurieren. Du kannst Paket-Control machen, noch ne Firewall dazu schalten, den Inhalt cachen um deine Server zu entlasten, ein einzelnes Zertifikat verwenden (was auch zur Sicherheit gehört, wenn du dem Zertifikat vertrauen kannst, weil du es entweder selbst ausgestellt oder irgendwo gekauft hast).

Und es gilt...je weniger Ports du offen hast, desto sicherer ist das

Steht aber auch verallgemeinert in den Links oben

buers

Noch ein paar andere Aspekte. Normalerweise will man keinen Server/Service (der direkt schützenswerte Daten hat oder auch mit anderen Servern direkt kommuniziert, die solche Daten haben direkt von außen zugänglich machen. Es darf einfach nicht möglich sein, vom Internet auf den Datenbank-Server zu kommen.

Traditionell hat man beispielsweise oft einen Webserver (der als nicht so gefährdet galt, wenn er wirklich nur traditioneller Webserver ist, und sonst nix) in eine DMZ verfrachtet, d.h. der hatte im professionellen Umfeld oft 2 Netze, eines zur äußeren Firewall Richtung Router/Internet, eines zur inneren Firewall Richtung echte Backends, sagen wir ein Datenbank-Server oder vielleicht davor noch sowas wie ein Weblogic Application Server. Administrativer Zugang (sagen wir ssh) würde auf der von außen erreichbaren Netzschnittstelle gar nicht möglich sein.

Mit dem Reverse-Proxy holst du den Webserver auch noch hinter die innere Firewall, stellst den Proxy dafür in die DMZ. Ein potentielle Angreifer hat also im ersten Schritt keine Chance, nahe an Daten zu kommen von außen.

Es ist auch zu bedenken, dass typischerweise hinter der inneren Firewall normalerweise mehr Kommunikation erlaubt ist (sein muss, Webserver muss mit DB kommunizieren, DB mit NAS, ...). Wobei in einer professionellen Umgebung auch diese Kommunikation typischerweise über externe Firewalls und verschiedene Subnetze kontrolliert wird. Es sind dann vielleicht mehrere Webserver hinter einem Loadbalancer in einem Subnetz, die Backends, die dem Webserver die Daten liefern, in einem anderen Subnetz. Subnetz-Übergang (OSI L3) immer über Firewall.

Vieles von dem kann man allerdings typischerweise im Home-Netz nicht erreichen. Dennoch bleibt eine weitere Hürde zu den "wertvolleren schützenswerteren" Systemen.

Jetzt mitmachen!