Ako OpenConnect premení prihlasovací cookie na tunel?

OpenConnect spája dve samostatné výmeny jednou krátkodobou hodnotou: webové prihlásenie a VPN tunel. Prvá výmena je obyčajné HTTPS: prihlasovacie údaje, cesta SAML tam a späť alebo token idú k bráne a odpoveď nesie autentifikačné cookie. Druhá výmena predkladá toto cookie tej istej bráne ako dôkaz, že webová fáza už prebehla, a až vtedy sa tunel zdvihne.

Počas prihlásenia sa o tuneli nič nevyjednáva. To je časť, ktorú stojí za to pochopiť, pretože väčšina chýb v skriptoch predpokladá, že cookie je heslo na uloženie alebo kľúč, ktorý chráni prevádzku, zatiaľ čo v skutočnosti je to nosná vstupenka pre konkrétnu reláciu brány.

Čo si klient a brána vymieňajú, po poriadku

Autentifikačná fáza vyzerá ako bežná chránená webová stránka. OpenConnect posiela prihlasovacie údaje používateľa alebo nasleduje presmerovanie brány k poskytovateľovi identity, a brána odpovedá dokumentom, ktorý vkladá autentifikačné cookie. V protokole AnyConnect táto hodnota putuje v hlavičke cookie pri ďalších požiadavkách, zvyčajne pod menom ako webvpn, a príručka ju považuje za údaj, ktorý nesie reláciu ďalej.

Druhá fáza je požiadavka CONNECT na VPN koncový bod brány s priloženým cookie. Brána ju overí, pridelí adresu a klient spustí CSTP nad TLS, pričom DTLS slúži ako voliteľná rýchlejšia dátová cesta, keď relácia existuje. Až v tomto okamihu sa stanovia parametre tunela, trasy, nastavenia DNS a prevádzkové kľúče relácie. Cookie previedla klienta dverami; nič nezašifrovala.

Toto poradie vysvetľuje, prečo existuje openconnect --authenticate. Spustite ho a vykoná webovú fázu, vypíše malý blok premenných shellu ako COOKIE, HOST, CONNECT_URL a FINGERPRINT a potom skončí pred zostavením akéhokoľvek tunela. Obalový skript potom môže spustiť skutočné pripojenie s týmito hodnotami, a to je presne to rozdelenie, ktoré potrebuje nasadenie bez obrazovky alebo v dvoch kontajneroch.

Cookie je nositeľ relácie, nie kľúč

Zaobchádzajte s hodnotou tak, ako by ste zaobchádzali s identifikátorom relácie vo webovej aplikácii. Kto ju počas jej života drží, môže od brány žiadať tunel, na ktorý má táto relácia nárok, takže jej utajenie je dôležité. Kopírovanie však prevádzku neodhalí, pretože dôvernosť tunela pochádza z TLS handshake a odvodených kľúčov, nie z reťazca cookie.

Nie je to ani trvalé oprávnenie. Brána a poskytovateľ identity rozhodujú, ako dlho relácia žije, a prehliadač, ktorý stále zobrazuje prihlásenú stránku, nič nehovorí o tom, či je relácia tunela ešte platná. Opätovné pripojenie po vypršaní znamená zopakovať webovú fázu a vytvoriť nové cookie, a to je zmyslom reautentifikácie, nie obťažnosť, ktorú treba obísť inžinierskymi prostriedkami.

Nepovažujte cookie za univerzálnu náhradu iných prihlasovacích údajov. SAML tvrdenie, heslo v prehliadači a cookie vydané inou službou sú rôzne objekty s rôznym publikom, a vloženie jedného do poľa druhého zvyčajne zlyhá na bráne alebo, čo je horšie, uspeje proti nesprávnej hranici dôvery.

Odovzdanie cookie bez zanechania kópií

Najbezpečnejšie mechanické odovzdanie v Linuxe je štandardný vstup. --cookie-on-stdin číta hodnotu zo stdin, takže cookie sa nikdy neobjaví v zozname argumentov procesu, kde ju každý miestny používateľ môže prečítať pomocou ps. Rúra, ktorá autentifikuje v jednom procese a napája tunel v inom, drží hodnotu v rúre namiesto v súbore alebo premennej prostredia.

Argumenty a premenné prostredia sú slabšie z rôznych dôvodov. Argument je viditeľný v tabuľke procesov po celý život klienta a často skončí v histórii shellu. Premenná prostredia sa dedí do podriadených procesov a jednotka systemd, ktorá ju nastavuje v súbore jednotky, ukladá tajomstvo do čitateľnej konfigurácie. Ak je súbor nevyhnutný, obmedzte ho na servisný účet a odstráňte ho po skončení relácie.

Hranicu oprávnení držte tiež zámerne. Proces, ktorý hovorí s poskytovateľom identity a prípadne otvára prehliadač, by mal bežať ako používateľ, ktorému toto prihlásenie patrí. Proces, ktorý konfiguruje trasy, DNS a zariadenie tunela, môže potrebovať viac oprávnení. Spúšťať celý prehliadač ako root, aby bolo jeho cookie dostupné tunelu vlastnenému rootom, je nesprávna výmena, a moderné inštalácie OpenConnect dokážu hodnotu odovzdať cez túto hranicu výslovne.

Aj protokolovanie si zaslúži rovnakú nedôveru. Podrobný výstup klienta, pomocné skripty a diagnostika brány môžu opakovať materiál požiadavky a nie každá úroveň protokolu cookie rediguje. Zachyťte najmenší záznam o chybe, ktorý potrebujete, držte ho mimo zdieľaných kanálov a pred priložením k tiketu skontrolujte redigovanú ukážku.

Overenie a vypršanie v druhej fáze

Druhá fáza stále musí overiť server. FINGERPRINT, ktorý vypisuje --authenticate, je pripnutie certifikátu v tvare pin-sha256:, a jeho odovzdanie volaniu tunela pomocou --servercert udržiava kontrolu ukotvenú pri bráne, proti ktorej ste sa autentifikovali. Vypnutie kontroly certifikátov kvôli zjednodušeniu skriptu odstraňuje jediný dôkaz, že cookie sa odovzdáva zamýšľanému hostiteľovi.

Keď brána cookie odmietne, riešením je nové kolo autentifikácie, nie dlhšia vyrovnávacia pamäť. Uchovávajte cookie len počas života pripojenia, pri ukončení mažte dočasné súbory a použite proces odstránenia relácie poskytovateľa identity alebo brány, keď je relácia prezradená alebo sa stratí zariadenie. Uložené cookie nie je oslobodenie od MFA.

Pred automatizáciou overte štyri veci: tunel beží pod správnym účtom, cookie prichádza cez stdin, odtlačok certifikátu je pripnutý a relácia sa zahodí pri zatvorení tunela. Ak niečo chýba, automatizácia rozšírila dôveru v cookie namiesto toho, aby zopakovala manuálny postup.