Jak veřejná proxy dosáhne soukromého původu přes VPN

Publikovat web přes tunel a dávat uživatelům přístup k VPN jsou dvě různá uspořádání, která sdílejí jeden kabel. V prvním veřejná reverzní proxy přijímá požadavek návštěvníka a přeposílá ho tunelem k původu, ke kterému se nikdo nedostane přímo. Ve druhém se uživatel musí připojit k VPN, než je aplikace vůbec dostupná. Smícháním obou popisů vzniká to, že soukromý backend skončí veřejně vystavený.

Dva modely, které na diagramu vypadají stejně

Nakreslete šipky, než cokoli vyberete. Model veřejného publikování jde z prohlížeče do proxy přes HTTPS, potom z proxy k původu tunelem, a původ nikdy nepřijme spojení z internetu. Model pouze s VPN jde z klienta do brány a aplikace je dostupná jen zevnitř této cesty. Uživatelův notebook sedí ve stejné síti jako aplikace, a to je celý smysl tohoto modelu.

Modely se liší v tom, kdo ověřuje identitu a kde. V prvním je proxy veřejný vstup a přeposílá každý příchozí požadavek, včetně nepřátelského, podle politiky na něm nastavené. Ve druhém je branou sama dostupnost, což je hrubé, ale skutečné přijetí.

Kde TLS končí a co vlastně dokazuje

TLS mezi prohlížečem a proxy chrání ten skok a umožňuje prohlížeči ověřit web, který chtěl navštívit. Pokud proxy TLS ukončí, požadavek existuje v čitelné podobě uvnitř tohoto procesu, než je přeposlán. Druhá TLS relace k původu může chránit další skok a samostatně ověřit koncový bod aplikace. Ani jedna relace nerozhoduje, který člověk smí aplikaci používat. Certifikát se zástupným znakem na proxy se na ten druhý skok také nevztahuje.

To je část, kterou lidé sloučí do slova šifrované. Důvěrnost, integrita a identita serveru jsou vlastnosti transportu; autorizace je rozhodnutí aplikace. Soukromá adresa za tunelem mění kdo se dostane k socketu, ne kdo se smí přihlásit, jakmile se tam dostane.

Věřte přeposílaným hlavičkám jen od proxy

Aplikace, které logují nebo autorizují podle adresy klienta, obvykle čtou hlavičku, kterou proxy přidává. Ta hlavička je jen text, takže cokoli, co se dostane přímo k původu, může tvrdit libovolnou adresu. Omezte původ tak, aby se mohla připojit jen adresa tunelu proxy, a nastavte aplikaci, aby hlavičku přijímala pouze z této adresy.

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

Pokud tento požadavek uspěje z hostitele, který není proxy, původ důvěřuje hlavičce, kterou by měl ignorovat. Opravte listener, než se dotknete aplikace. Odmítnutí je mnohem lepší výsledek než řádek v logu s padělanou adresou.

Udržte původ dostupný přesně z jednoho místa

Připoutejte listener původu k adrese tunelu nebo ho ohraďte firewallem vůči proxy, a pak ověřte, co skutečně naslouchá. Služba spuštěná s vazbou na všechna rozhraní přijímá spojení na každém rozhraní, které hostitel má, včetně toho, u kterého jste zapomněli, že je směrovatelné. Tabulka naslouchání je základní pravda, ne konfigurační soubor, který jste zamýšleli použít. Pokud je vazba na všechna rozhraní záměrná, firewall musí být i tak tou komponentou, která ji zužuje.

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

Stejnou kontrolu udělejte pro rozhraní pro správu, která bývají tou obvyklou náhodnou expozicí. Potom oba modely zapište odděleně: veřejný web přes proxy a administrativní rozhraní dostupné jen tunelem. Věta, že server je za VPN, neříká nic z toho.