Kuidas muudab OpenConnect sisselogimisküpsise tunneliks?

OpenConnect seob kaks eraldi vahetust ühe lühiajalise väärtusega: veebi sisselogimise ja VPN-tunneli. Esimene vahetus on tavaline HTTPS: volitused, SAML-i edasi-tagasi käik või luba lähevad lüüsile ning vastus kannab autentimisküpsist. Teine vahetus esitab selle küpsise samale lüüsile tõendina, et veebifaas on juba toimunud, ja alles siis tõuseb tunnel.

Sisselogimise ajal ei peeta tunnelist mingit läbirääkimist. See on osa, mida tasub mõista, sest enamik skriptivigu eeldab, et küpsis on salvestatav parool või võti, mis kaitseb liiklust, kuigi tegelikult on see kandja-pilet kindla lüüsi sessiooni jaoks.

Mida klient ja lüüs järjekorras vahetavad

Autentimisfaas näeb välja nagu tavaline kaitstud veebisait. OpenConnect saadab kasutaja volitused või järgib lüüsi ümbersuunamist identiteedipakkujale ning lüüs vastab dokumendiga, mis põimib autentimisküpsise. AnyConnecti protokollis liigub see väärtus järgmistes päringutes küpsise päises, tavaliselt nime all nagu webvpn, ja käsiraamat käsitleb seda volitusena, mis kannab sessiooni edasi.

Teine faas on CONNECT-päring lüüsi VPN-lõpp-punkti, kusjuures küpsis on külge lisatud. Lüüs kontrollib seda, määrab aadressi ja klient käivitab CSTP üle TLS-i, kusjuures DTLS on valikuline kiirem andmetee, kui sessioon on olemas. Alles selles punktis luuakse tunneli parameetrid, marsruudid, DNS-i seaded ja sessiooni liiklusvõtmed. Küpsis viis kliendi uksest läbi; see ei krüpteerinud midagi.

See järjekord selgitab, miks openconnect --authenticate olemas on. Käivitage see ja see teeb veebifaasi, prindib väikese ploki kestamuutujaid nagu COOKIE, HOST, CONNECT_URL ja FINGERPRINT ning lõpeb siis, enne kui ükski tunnel ehitatakse. Ümbriskript saab seejärel nende väärtustega päris ühenduse käivitada, mis on täpselt see jaotus, mida vajab juurutus ilma graafilise liideseta või kahe konteineri vahel.

Küpsis on sessiooni kandja, mitte võti

Kohelge väärtust nii, nagu kohtleksite sessiooni identifikaatorit veebirakenduses. Kes seda selle eluea jooksul hoiab, saab lüüsilt nõuda tunnelit, millele sellel sessioonil õigus on, seega on selle salajasus oluline. Kopeerimine aga ei paljasta liiklust, sest tunneli konfidentsiaalsus tuleb TLS-i kätlusest ja tuletatud võtmetest, mitte küpsise stringist.

See ei ole ka püsiv luba. Lüüs ja identiteedipakkuja otsustavad, kui kaua sessioon elab, ja brauser, mis näitab endiselt sisselogitud lehte, ei ütle midagi selle kohta, kas tunneli sessioon on veel kehtiv. Pärast aegumist uuesti ühendamine tähendab veebifaasi kordamist ja värske küpsise loomist ning just see ongi uuesti autentimise mõte, mitte tüütus, millest tuleks inseneritööga mööda minna.

Ärge kohelge küpsist teiste volituste universaalse asendajana. SAML-i väide, brauseri parool ja teise teenuse väljastatud küpsis on erinevad objektid erinevate sihtrühmadega ning ühe kleepimine teise väljale ebaõnnestub tavaliselt lüüsil või, mis hullem, õnnestub vale usalduspiiri vastu.

Küpsise üleandmine koopiaid jätmata

Ohutuim mehaaniline üleandmine Linuxis on standardisisend. --cookie-on-stdin loeb väärtuse stdin-ist, nii et küpsis ei ilmu kunagi protsessi argumentide loendis, kus iga kohalik kasutaja saab seda lugeda käsuga ps. Torustik, mis autendib ühes protsessis ja toidab tunnelit teises, hoiab väärtust torus, mitte failis või keskkonnamuutujas.

Argumendid ja keskkonnamuutujad on erinevatel põhjustel nõrgemad. Argument on protsessitabelis nähtav kogu kliendi eluea jooksul ja satub sageli kesta ajalukku. Keskkonnamuutuja pärandub alamprotsessidele ning systemd-i üksus, mis seab selle üksusefailis, hoiab saladust loetavas konfiguratsioonis. Kui fail on hädavajalik, piirake see teenusekontoga ja eemaldage see sessiooni lõppedes.

Hoidke ka õiguste piir teadlikuna. Protsess, mis räägib identiteedipakkujaga ja avab võib-olla brauseri, peaks jooksma kasutajana, kellele see sisselogimine kuulub. Protsess, mis seadistab marsruute, DNS-i ja tunnelseadet, võib vajada rohkem õigusi. Kogu brauseri jooksutamine rootina, et selle küpsis oleks rootile kuuluvale tunnelile kättesaadav, on vale vahetus, ja kaasaegsed OpenConnecti seadistused suudavad väärtuse sellest piirist selgesõnaliselt üle anda.

Logimine väärib sama kahtlust. Üksikasjalik kliendi väljund, abiskriptid ja lüüsi diagnostika võivad kõik päringu materjali korrata ning iga logimistase ei redigeeri küpsist. Jäädvustage väikseim vajalik veakirje, hoidke see jagatud kanalitest eemal ja kontrollige redigeeritud näidist enne, kui kinnitate selle pileti külge.

Kontroll ja aegumine teises faasis

Teine faas peab ikkagi serverit kontrollima. FINGERPRINT, mille --authenticate prindib, on sertifikaadi kinnitus kujul pin-sha256:, ja selle edasiandmine tunneli kutsele valikuga --servercert hoiab kontrolli ankurdatud lüüsi külge, mille vastu te autentisite. Sertifikaadikontrolli väljalülitamine skripti lihtsustamiseks eemaldab ainsa tõendi, et küpsis antakse kavandatud hostile.

Kui lüüs küpsise tagasi lükkab, on lahendus uus autentimisvoor, mitte pikem vahemälu. Hoidke küpsist ainult ühenduse eluea jooksul, kustutage väljumisel ajutised failid ja kasutage identiteedipakkuja või lüüsi sessiooni eemaldamise protsessi, kui sessioon paljastub või seade kaob. Vahemällu salvestatud küpsis ei ole MFA-st vabastus.

Enne selle automatiseerimist kontrollige nelja asja: tunnel jookseb õige kontoga, küpsis saabub stdin-i kaudu, sertifikaadi sõrmejälg on kinnitatud ja sessioon heidetakse kõrvale, kui tunnel sulgub. Kui midagi neist puudub, on automatiseerimine laiendanud usaldust küpsise vastu, selle asemel et käsitsi voogu korrata.