Kako OpenConnect spremeni piškotek za prijavo v tunel?

OpenConnect poveže dve ločeni izmenjavi z eno kratkotrajno vrednostjo: spletno prijavo in tunel VPN. Prva izmenjava je običajen HTTPS: poverilnice, pot SAML tja in nazaj ali žeton gredo do prehoda, odgovor pa prinese piškotek za preverjanje pristnosti. Druga izmenjava predloži ta piškotek istemu prehodu kot dokaz, da je spletna faza že potekla, in šele takrat se tunel dvigne.

Med prijavo se o tunelu nič ne dogovarja. Prav to je del, ki se ga splača razumeti, ker večina napak v skriptih domneva, da je piškotek geslo za shranjevanje ali ključ, ki ščiti promet, medtem ko je v resnici nosilna vstopnica za določeno sejo prehoda.

Kaj si odjemalec in prehod izmenjata, po vrsti

Faza preverjanja pristnosti je videti kot običajno zaščiteno spletno mesto. OpenConnect pošlje uporabnikove poverilnice ali sledi preusmeritvi prehoda k ponudniku identitete, prehod pa odgovori z dokumentom, ki vgradi piškotek za preverjanje pristnosti. V protokolu AnyConnect ta vrednost potuje v glavi piškotka pri naslednjih zahtevah, običajno pod imenom, kot je webvpn, in priročnik jo obravnava kot poverilnico, ki nosi sejo naprej.

Druga faza je zahteva CONNECT na končno točko VPN prehoda s priloženim piškotkom. Prehod jo preveri, dodeli naslov, odjemalec pa zažene CSTP nad TLS, pri čemer je DTLS neobvezna hitrejša podatkovna pot, ko seja obstaja. Šele na tej točki se vzpostavijo parametri tunela, poti, nastavitve DNS in prometni ključi seje. Piškotek je odjemalca spustil skozi vrata; ničesar ni šifriral.

To zaporedje pojasnjuje, zakaj obstaja openconnect --authenticate. Zaženite ga in izvede spletno fazo, izpiše majhen blok lupinskih spremenljivk, kot so COOKIE, HOST, CONNECT_URL in FINGERPRINT, nato pa se konča, preden se zgradi kakršen koli tunel. Ovijalni skript lahko nato zagoni pravo povezavo s temi vrednostmi, in to je natanko tista delitev, ki jo potrebuje namestitev brez zaslona ali v dveh vsebnikih.

Piškotek je nosilec seje, ne ključ

Z vrednostjo ravnajte tako, kot bi ravnali z identifikatorjem seje v spletni aplikaciji. Kdor jo ima v njeni življenjski dobi, lahko od prehoda zahteva tunel, do katerega je ta seja upravičena, zato je njena tajnost pomembna. Toda kopiranje ne razkrije prometa, ker zaupnost tunela izhaja iz rokovanja TLS in izpeljanih ključev, ne iz niza piškotka.

Prav tako ni trajno dovoljenje. Prehod in ponudnik identitete odločita, kako dolgo seja živi, in brskalnik, ki še vedno prikazuje prijavljeno stran, ne pove ničesar o tem, ali je seja tunela še veljavna. Ponovna povezava po poteku pomeni ponovitev spletne faze in ustvarjanje svežega piškotka, in prav to je smisel ponovnega preverjanja pristnosti, ne nadloga, ki bi se ji bilo treba izogniti z inženiringom.

Piškotka ne obravnavajte kot univerzalno nadomestilo za druge poverilnice. Trditev SAML, geslo brskalnika in piškotek, ki ga je izdala druga storitev, so različni objekti z različnim občinstvom, in lepljenje enega v polje drugega običajno spodleti pri prehodu ali, kar je slabše, uspe proti napačni meji zaupanja.

Predaja piškotka brez puščanja kopij

Najvarnejša mehanska predaja v Linuxu je standardni vhod. --cookie-on-stdin prebere vrednost s stdin, tako da se piškotek nikoli ne pojavi na seznamu argumentov procesa, kjer ga lahko vsak lokalni uporabnik prebere s ps. Cevovod, ki preverja pristnost v enem procesu in napaja tunel v drugem, drži vrednost v cevi namesto v datoteki ali spremenljivki okolja.

Argumenti in spremenljivke okolja so šibkejši iz različnih razlogov. Argument je viden v tabeli procesov ves čas življenja odjemalca in pogosto konča v zgodovini lupine. Spremenljivka okolja se deduje v podrejene procese, enota systemd, ki jo nastavi v datoteki enote, pa shrani skrivnost v berljivi konfiguraciji. Če je datoteka nujna, jo omejite na servisni račun in jo odstranite, ko se seja konča.

Tudi mejo privilegijev držite namerno. Proces, ki se pogovarja s ponudnikom identitete in morda odpre brskalnik, bi moral teči kot uporabnik, ki mu pripada ta prijava. Proces, ki nastavlja poti, DNS in napravo tunela, lahko potrebuje več privilegijev. Zaganjanje celega brskalnika kot root, da bi bil njegov piškotek na voljo tunelu v lasti root, je napačna zamenjava, in sodobne nastavitve OpenConnect lahko vrednost izrecno predajo čez to mejo.

Tudi beleženje si zasluži enako nezaupljivost. Podroben izhod odjemalca, pomožni skripti in diagnostika prehoda lahko ponovijo gradivo zahteve, in vsaka raven dnevnika ne redigira piškotka. Zajemite najmanjši potrebni zapis o napaki, držite ga zunaj skupnih kanalov in pred prilaganjem vstopnici preglejte redigiran vzorec.

Preverjanje in potek v drugi fazi

Druga faza mora še vedno preveriti strežnik. FINGERPRINT, ki ga izpiše --authenticate, je pripenjanje potrdila v obliki pin-sha256:, in njegova predaja klicu tunela z --servercert ohrani preverjanje zasidrano na prehodu, proti kateremu ste se preverili. Izklop preverjanja potrdil zaradi poenostavitve skripta odstrani edini dokaz, da se piškotek predaja predvidenemu gostitelju.

Ko prehod piškotek zavrne, je rešitev nov krog preverjanja pristnosti, ne daljši predpomnilnik. Piškotek hranite le toliko časa, kolikor traja povezava, ob izhodu izbrišite začasne datoteke in uporabite postopek odstranitve seje ponudnika identitete ali prehoda, ko je seja razkrita ali se naprava izgubi. Shranjen piškotek ni oprostitev od MFA.

Preden to avtomatizirate, preverite štiri stvari: tunel teče pod pravilnim računom, piškotek prispe prek stdin, odtis potrdila je pripet in seja se zavrže, ko se tunel zapre. Če kaj manjka, je avtomatizacija razširila zaupanje v piškotek, namesto da bi ponovila ročni potek.