Wie ein öffentlicher Proxy über ein VPN einen privaten Ursprung erreicht

Eine Website über einen Tunnel zu veröffentlichen und Benutzern VPN-Zugang zu geben, sind zwei verschiedene Anordnungen, die sich ein Kabel teilen. Bei der ersten nimmt ein öffentlicher Reverse-Proxy die Anfrage des Besuchers an und leitet sie über den Tunnel an einen Ursprung weiter, den niemand direkt erreichen kann. Bei der zweiten muss der Benutzer dem VPN beitreten, bevor die Anwendung überhaupt erreichbar ist. Beide Beschreibungen zu vermischen ist der Weg, auf dem ein privates Backend am Ende öffentlich exponiert wird.

Zwei Modelle, die auf einem Diagramm gleich aussehen

Zeichnen Sie die Pfeile, bevor Sie etwas auswählen. Ein öffentliches Veröffentlichungsmodell läuft vom Browser zum Proxy über HTTPS, dann vom Proxy zum Ursprung durch den Tunnel, und der Ursprung nimmt niemals eine Verbindung aus dem Internet an. Ein reines VPN-Modell läuft vom Client zum Gateway, und die Anwendung ist nur von innerhalb dieses Pfades erreichbar. Der Laptop des Benutzers sitzt im selben Netzwerk wie die Anwendung, und das ist der ganze Sinn dieses Modells.

Die Modelle unterscheiden sich darin, wer authentifiziert und wo. Beim ersten ist der Proxy der öffentliche Einstieg, und er leitet jede eintreffende Anfrage weiter, auch eine feindliche, vorbehaltlich der darauf konfigurierten Richtlinie. Beim zweiten ist die Erreichbarkeit selbst das Tor, was eine grobe, aber echte Zulassung ist.

Wo TLS endet und was es tatsächlich beweist

TLS zwischen Browser und Proxy schützt diesen Sprung und lässt den Browser die Website verifizieren, die er besuchen wollte. Wenn der Proxy TLS beendet, existiert die Anfrage in lesbarer Form innerhalb dieses Prozesses, bevor sie weitergeleitet wird. Eine zweite TLS-Sitzung zum Ursprung kann den nächsten Sprung schützen und den Anwendungsendpunkt getrennt verifizieren. Keine der Sitzungen entscheidet, welcher Mensch die Anwendung nutzen darf. Ein Wildcard-Zertifikat auf dem Proxy erstreckt sich auch nicht auf diesen zweiten Sprung.

Das ist der Teil, den Leute in das Wort verschlüsselt zusammenfassen. Vertraulichkeit, Integrität und Serveridentität sind Transporteigenschaften; Autorisierung ist eine Anwendungsentscheidung. Eine private Adresse hinter einem Tunnel ändert wer den Socket erreichen kann, nicht wer sich anmelden darf, wenn er es tut.

Vertrauen Sie weitergeleiteten Headern nur vom Proxy

Anwendungen, die auf die Client-Adresse loggen oder autorisieren, lesen normalerweise einen Header, den der Proxy hinzufügt. Dieser Header ist nur Text, also kann alles, was den Ursprung direkt erreichen kann, jede beliebige Adresse behaupten. Beschränken Sie den Ursprung so, dass nur die Tunneladresse des Proxys sich verbinden darf, und konfigurieren Sie die Anwendung so, dass sie den Header nur von dieser Adresse akzeptiert.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Wenn diese Anfrage von einem Host aus gelingt, der nicht der Proxy ist, vertraut der Ursprung einem Header, den er ignorieren sollte. Reparieren Sie den Listener, bevor Sie die Anwendung anfassen. Eine Ablehnung ist ein viel besseres Ergebnis als eine Logzeile mit einer gefälschten Adresse.

Halten Sie den Ursprung von genau einer Stelle aus erreichbar

Binden Sie den Listener des Ursprungs an die Tunneladresse oder schirmen Sie ihn mit einer Firewall zum Proxy ab, und bestätigen Sie dann, was tatsächlich lauscht. Ein Dienst, der mit einer Wildcard-Bindung gestartet wurde, nimmt Verbindungen auf jeder Schnittstelle an, die der Host hat, auch auf einer, von der Sie vergessen haben, dass sie routbar ist. Die Lauschtabelle ist die Grundwahrheit, nicht die Konfigurationsdatei, die Sie anwenden wollten. Wenn die Wildcard-Bindung beabsichtigt ist, muss die Firewall trotzdem die Komponente sein, die sie einschränkt.

ss -ltnp | grep -E ':(80|443)'

Machen Sie dieselbe Prüfung für Verwaltungsschnittstellen, die die übliche versehentliche Exposition sind. Schreiben Sie dann die beiden Modelle getrennt auf: die öffentliche Website durch den Proxy und die Verwaltungsschnittstelle, die nur durch den Tunnel erreichbar ist. Der Satz, dass der Server hinter einem VPN steht, sagt nichts davon.