Hoe een openbare proxy via een VPN bij een private origin komt

Een website via een tunnel publiceren en gebruikers VPN-toegang geven zijn twee verschillende opstellingen die één kabel delen. Bij de eerste neemt een openbare reverse proxy het verzoek van de bezoeker aan en stuurt het via de tunnel door naar een origin die niemand rechtstreeks kan bereiken. Bij de tweede moet de gebruiker lid worden van de VPN voordat de applicatie überhaupt bereikbaar is. De twee beschrijvingen door elkaar halen is hoe een private backend uiteindelijk publiek wordt blootgesteld.

Twee modellen die er op een diagram hetzelfde uitzien

Teken de pijlen voordat je iets kiest. Een openbaar publicatiemodel loopt van browser naar proxy over HTTPS, dan van proxy naar origin door de tunnel, en de origin accepteert nooit een verbinding van het internet. Een alleen-VPN-model loopt van client naar gateway, en de applicatie is alleen van binnen dat pad bereikbaar. De laptop van de gebruiker staat op hetzelfde netwerk als de applicatie, en dat is het hele punt van dat model.

De modellen verschillen in wie authenticeert en waar. Bij de eerste is de proxy de openbare ingang en stuurt elk verzoek door dat binnenkomt, ook een vijandig verzoek, volgens het beleid dat erop is geconfigureerd. Bij de tweede is de bereikbaarheid zelf de poort, wat een grove maar echte toelating is.

Waar TLS stopt, en wat het werkelijk bewijst

TLS tussen browser en proxy beschermt die sprong en laat de browser de site verifiëren die hij wilde bezoeken. Als de proxy TLS beëindigt, bestaat het verzoek in leesbare vorm binnen dat proces voordat het wordt doorgestuurd. Een tweede TLS-sessie naar de origin kan de volgende sprong beschermen en het eindpunt van de applicatie apart verifiëren. Geen van beide sessies bepaalt welk mens de applicatie mag gebruiken. Een wildcard-certificaat op de proxy strekt zich ook niet uit tot die tweede sprong.

Dit is het deel dat mensen samenvatten in het woord versleuteld. Vertrouwelijkheid, integriteit en serveridentiteit zijn transporteigenschappen; autorisatie is een applicatiebeslissing. Een privéadres achter een tunnel verandert wie de socket kan bereiken, niet wie mag inloggen als hij dat doet.

Vertrouw doorgestuurde headers alleen van de proxy

Applicaties die loggen of autoriseren op het clientadres lezen meestal een header die de proxy toevoegt. Die header is alleen tekst, dus alles wat de origin rechtstreeks kan bereiken kan elk adres claimen dat het wil. Beperk de origin zodat alleen het tunneladres van de proxy kan verbinden, en configureer de applicatie om de header alleen van dat adres te accepteren.

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

Als dat verzoek slaagt vanaf een host die niet de proxy is, vertrouwt de origin een header die hij zou moeten negeren. Repareer de listener voordat je de applicatie aanraakt. Een weigering is een veel beter resultaat dan een logregel met een vervalst adres.

Houd de origin vanaf precies één plek bereikbaar

Bind de listener van de origin aan het tunneladres of scherm hem af met een firewall naar de proxy, en bevestig dan wat er werkelijk luistert. Een dienst die met een wildcard-binding is gestart, accepteert verbindingen op elke interface die de host heeft, ook een waarvan je was vergeten dat hij routeerbaar is. De luistertabel is de grondwaarheid, niet het configuratiebestand dat je wilde toepassen. Als de wildcard-binding opzettelijk is, moet de firewall nog steeds het onderdeel zijn dat hem vernauwt.

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

Doe dezelfde beoordeling voor beheerinterfaces, dat zijn de gebruikelijke toevallige blootstellingen. Schrijf daarna de twee modellen apart op: de openbare site via de proxy, en de beheerinterface die alleen via de tunnel bereikbaar is. De zin dat de server achter een VPN staat zegt niets van dat alles.