Sådan når en offentlig proxy en privat oprindelse gennem en VPN

At udgive et websted gennem en tunnel og at give brugere VPN-adgang er to forskellige arrangementer, der deler et kabel. I det første accepterer en offentlig omvendt proxy besøgendes anmodning og videresender den gennem tunnelen til en oprindelse, som ingen kan nå direkte. I det andet skal brugeren tilslutte sig VPN’en, før applikationen overhovedet er tilgængelig. At blande de to beskrivelser er måden, hvorpå en privat backend ender med at blive offentligt blotlagt.

To modeller, der ser ens ud på et diagram

Tegn pilene, før du vælger noget. En offentlig udgivelsesmodel går fra browser til proxy over HTTPS, derefter fra proxy til oprindelse gennem tunnelen, og oprindelsen accepterer aldrig en forbindelse fra internettet. En VPN-kun-model går fra klient til gateway, og applikationen er kun tilgængelig indefra den vej. Brugerens bærbare computer sidder på samme netværk som applikationen, og det er hele pointen med den model.

Modellerne adskiller sig i, hvem der autentificerer, og hvor. I det første er proxyen den offentlige indgang, og den videresender enhver anmodning, der ankommer, også en fjendtlig, underlagt den politik, der er konfigureret på den. I det andet er tilgængeligheden selv porten, hvilket er groft men reel adgang.

Hvor TLS stopper, og hvad det egentlig beviser

TLS mellem browser og proxy beskytter det hop og lader browseren verificere det websted, den havde til hensigt at besøge. Hvis proxyen afslutter TLS, findes anmodningen i læsbar form inde i den proces, før den videresendes. En anden TLS-session til oprindelsen kan beskytte det næste hop og verificere applikationens endepunkt separat. Ingen af sessionerne afgør, hvilket menneske der må bruge applikationen. Et wildcard-certifikat på proxyen strækker sig heller ikke til det andet hop.

Det er den del, folk samler i ordet krypteret. Fortrolighed, integritet og serveridentitet er transportegenskaber; autorisation er en applikationsbeslutning. En privat adresse bag en tunnel ændrer hvem der kan nå soklen, ikke hvem der må logge ind, når de gør det.

Stol kun på videresendte headere fra proxyen

Applikationer, der logger eller autoriserer på klientadressen, læser normalt en header, som proxyen tilføjer. Den header er bare tekst, så alt, der kan nå oprindelsen direkte, kan hævde enhver adresse, det ønsker. Begræns oprindelsen, så kun proxyens tunneladresse kan forbinde, og konfigurer applikationen til kun at acceptere headeren fra den adresse.

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

Hvis den anmodning lykkes fra en vært, der ikke er proxyen, stoler oprindelsen på en header, den burde ignorere. Ret lytteren, før du rører applikationen. Et afslag er et meget bedre resultat end en loglinje med en forfalsket adresse.

Hold oprindelsen tilgængelig fra præcis ét sted

Bind oprindelsens lytter til tunneladressen, eller sæt en firewall op mod proxyen, og bekræft derefter, hvad der faktisk lytter. En tjeneste startet med wildcard-binding accepterer forbindelser på hver grænseflade, værten har, inklusive en, du havde glemt var rutbar. Lytningstabellen er den grundlæggende sandhed, ikke den konfigurationsfil, du havde til hensigt at anvende. Hvis wildcard-bindingen er bevidst, skal firewallen stadig være den komponent, der indsnævrer den.

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

Gør den samme gennemgang for administrationsgrænseflader, som er den sædvanlige utilsigtede eksponering. Skriv derefter de to modeller ned hver for sig: det offentlige websted gennem proxyen og administrationsgrænsefladen, der kun er tilgængelig gennem tunnelen. Sætningen om, at serveren er bag en VPN, siger intet af det.