Ako sa verejný proxy dostane k súkromnému pôvodu cez VPN

Publikovať stránku cez tunel a dávať používateľom prístup k VPN sú dve rôzne usporiadania, ktoré zdieľajú jeden kábel. V prvom verejný reverzný proxy prijíma požiadavku návštevníka a preposiela ju tunelom k pôvodu, ku ktorému sa nikto nedostane priamo. V druhom sa používateľ musí pripojiť k VPN, kým je aplikácia vôbec dostupná. Zmiešanie oboch opisov je cesta, ktorou súkromný backend napokon skončí verejne vystavený.

Dva modely, ktoré na diagrame vyzerajú rovnako

Nakreslite šípky, kým čokoľvek vyberiete. Model verejného publikovania ide z prehliadača do proxy cez HTTPS, potom z proxy k pôvodu tunelom, a pôvod nikdy neprijme spojenie z internetu. Model iba s VPN ide z klienta do brány a aplikácia je dostupná len zvnútra tejto cesty. Používateľov notebook sedí v tej istej sieti ako aplikácia, a to je celý zmysel tohto modelu.

Modely sa líšia v tom, kto overuje a kde. V prvom je proxy verejným vstupom a preposiela každú prichádzajúcu požiadavku, vrátane nepriateľskej, podľa politiky na ňom nastavenej. V druhom je bránou samotná dostupnosť, čo je hrubé, ale skutočné prijatie.

Kde sa TLS končí a čo vlastne dokazuje

TLS medzi prehliadačom a proxy chráni ten skok a umožňuje prehliadaču overiť stránku, ktorú chcel navštíviť. Ak proxy ukončí TLS, požiadavka existuje v čitateľnej podobe vnútri tohto procesu, kým sa prepošle. Druhá relácia TLS k pôvodu môže chrániť ďalší skok a samostatne overiť koncový bod aplikácie. Ani jedna relácia nerozhoduje, ktorý človek smie aplikáciu používať. Certifikát so zástupným znakom na proxy sa na ten druhý skok tiež nevzťahuje.

Toto je časť, ktorú ľudia zhrnú do slova šifrované. Dôvernosť, integrita a identita servera sú vlastnosti transportu; autorizácia je rozhodnutie aplikácie. Súkromná adresa za tunelom mení kto sa dostane k socketu, nie kto sa smie prihlásiť, keď sa tam dostane.

Verte preposielaným hlavičkám len od proxy

Aplikácie, ktoré logujú alebo autorizujú podľa adresy klienta, zvyčajne čítajú hlavičku, ktorú proxy pridáva. Tá hlavička je len text, takže čokoľvek, čo sa dostane priamo k pôvodu, môže tvrdiť akúkoľvek adresu. Obmedzte pôvod tak, aby sa mohla pripojiť len adresa tunela proxy, a nastavte aplikáciu, aby hlavičku prijímala iba z tejto adresy.

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

Ak tá požiadavka uspeje z hostiteľa, ktorý nie je proxy, pôvod dôveruje hlavičke, ktorú by mal ignorovať. Opravte listener, kým sa dotknete aplikácie. Odmietnutie je oveľa lepší výsledok než riadok v logu s falošnou adresou.

Udržte pôvod dostupný presne z jedného miesta

Pripojte listener pôvodu k adrese tunela alebo ho ohraďte firewallom voči proxy, a potom overte, čo skutočne načúva. Služba spustená s väzbou na všetky rozhrania prijíma spojenia na každom rozhraní, ktoré hostiteľ má, vrátane toho, o ktorom ste zabudli, že je smerovateľné. Tabuľka načúvania je základná pravda, nie konfiguračný súbor, ktorý ste zamýšľali použiť. Ak je väzba na všetky rozhrania zámerná, firewall musí byť aj tak tou komponentou, ktorá ju zužuje.

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

Urobte rovnakú kontrolu pre rozhrania správy, ktoré bývajú tou obvyklou náhodnou expozíciou. Potom oba modely zapíšte oddelene: verejnú stránku cez proxy a administratívne rozhranie dostupné len tunelom. Veta, že server je za VPN, nehovorí nič z toho.