Jak OpenConnect promění přihlašovací cookie v tunel?

OpenConnect spojuje dvě samostatné výměny jednou krátkodobou hodnotou: webové přihlášení a VPN tunel. První výměna je obyčejné HTTPS: přihlašovací údaje, cesta SAML tam a zpět nebo token jdou k bráně a odpověď nese autentizační cookie. Druhá výměna předkládá tuto cookie stejné bráně jako důkaz, že webová fáze už proběhla, a teprve potom se tunel zvedne.

Během přihlášení se o tunelu nic nevyjednává. To je část, kterou stojí za to pochopit, protože většina chyb ve skriptech předpokládá, že cookie je heslo k uložení nebo klíč, který chrání provoz, zatímco ve skutečnosti je to nosná vstupenka pro konkrétní relaci brány.

Co si klient a brána vyměňují, popořadě

Autentizační fáze vypadá jako běžný chráněný web. OpenConnect posílá uživatelovy přihlašovací údaje nebo následuje přesměrování brány k poskytovateli identity a brána odpovídá dokumentem, který vkládá autentizační cookie. V protokolu AnyConnect tato hodnota putuje v hlavičce cookie u následujících požadavků, obvykle pod jménem jako webvpn, a příručka ji považuje za údaj, který nese relaci dál.

Druhá fáze je požadavek CONNECT na VPN koncový bod brány s přiloženou cookie. Brána ji ověří, přidělí adresu a klient spustí CSTP nad TLS, přičemž DTLS slouží jako volitelná rychlejší datová cesta, jakmile relace existuje. Teprve v tomto okamžiku se stanoví parametry tunelu, trasy, nastavení DNS a provozní klíče relace. Cookie provedla klienta dveřmi; nic nezašifrovala.

Toto pořadí vysvětluje, proč existuje openconnect --authenticate. Spusťte ho a provede webovou fázi, vypíše malý blok proměnných shellu jako COOKIE, HOST, CONNECT_URL a FINGERPRINT a poté skončí dřív, než se postaví jakýkoli tunel. Obalový skript pak může s těmito hodnotami spustit skutečné připojení, což je přesně to rozdělení, které potřebuje nasazení bez grafického rozhraní nebo ve dvou kontejnerech.

Cookie je nositel relace, ne klíč

Zacházejte s hodnotou tak, jak byste zacházeli s identifikátorem relace ve webové aplikaci. Kdo ji po dobu její platnosti drží, může od brány žádat tunel, na který má tato relace nárok, takže její utajení je důležité. Kopírování však provoz neodhalí, protože důvěrnost tunelu pochází z TLS handshake a odvozených klíčů, ne z řetězce cookie.

Není to ani trvalé oprávnění. Brána a poskytovatel identity rozhodují, jak dlouho relace žije, a prohlížeč, který stále zobrazuje přihlášenou stránku, nic neříká o tom, zda je relace tunelu ještě platná. Opětovné připojení po vypršení znamená zopakovat webovou fázi a vytvořit novou cookie, a to je smysl reautentizace, nikoli obtíž, kterou je třeba obejít inženýrsky.

Nepovažujte cookie za univerzální náhradu jiných přihlašovacích údajů. SAML tvrzení, heslo v prohlížeči a cookie vydaná jinou službou jsou různé objekty s různými publiky a vložení jednoho do pole druhého obvykle selže na bráně nebo, což je horší, uspěje proti špatné hranici důvěry.

Předání cookie bez zanechání kopií

Nejbezpečnější mechanické předání na Linuxu je standardní vstup. --cookie-on-stdin čte hodnotu ze stdin, takže cookie se nikdy neobjeví v seznamu argumentů procesu, kde ji každý místní uživatel může přečíst pomocí ps. Roura, která autentizuje v jednom procesu a napájí tunel v jiném, drží hodnotu v rouře místo v souboru nebo proměnné prostředí.

Argumenty a proměnné prostředí jsou slabší z různých důvodů. Argument je viditelný v tabulce procesů po celou dobu života klienta a často skončí v historii shellu. Proměnná prostředí se dědí do podřízených procesů a jednotka systemd, která ji nastavuje v souboru jednotky, ukládá tajemství do čitelné konfigurace. Pokud soubor nutně potřebujete, omezit ho na servisní účet a po skončení relace ho odstraňte.

Hranici oprávnění držte také záměrně. Proces, který mluví s poskytovatelem identity a případně otevírá prohlížeč, by měl běžet jako uživatel, jemuž toto přihlášení patří. Proces, který konfiguruje trasy, DNS a zařízení tunelu, může potřebovat více oprávnění. Spouštět celý prohlížeč jako root, aby byla jeho cookie dostupná tunelu vlastněnému rootem, je špatná výměna a moderní instalace OpenConnect umí hodnotu předat přes tuto hranici výslovně.

I protokolování si zaslouží stejnou nedůvěru. Podrobný výstup klienta, pomocné skripty a diagnostika brány mohou opakovat materiál požadavku a ne každá úroveň protokolu cookie rediguje. Zachyťte nejmenší záznam o chybě, který potřebujete, držte ho mimo sdílené kanály a před přiložením k tiketu zkontrolujte redigovanou ukázku.

Ověření a vypršení ve druhé fázi

Druhá fáze stále musí ověřit server. FINGERPRINT, který --authenticate vypisuje, je připnutí certifikátu ve tvaru pin-sha256:, a jeho předání volání tunelu pomocí --servercert drží kontrolu ukotvenou u brány, proti níž jste se autentizovali. Vypnutí kontroly certifikátů kvůli zjednodušení skriptu odstraní jediný důkaz, že cookie se předává zamýšlenému hostiteli.

Když brána cookie odmítne, řešením je nové kolo autentizace, ne delší mezipaměť. Uchovávejte cookie jen po dobu života připojení, při ukončení mažte dočasné soubory a použijte proces odstranění relace poskytovatele identity nebo brány, když je relace vyzrazena nebo se ztratí zařízení. Uložená cookie není osvobození od MFA.

Než to zautomatizujete, ověřte čtyři věci: tunel běží pod správným účtem, cookie přichází přes stdin, otisk certifikátu je připnutý a relace se zahodí při zavření tunelu. Pokud některá chybí, automatizace rozšířila důvěru v cookie, místo aby zopakovala ruční postup.