Kaip OpenConnect paverčia prisijungimo slapuką tuneliu?

OpenConnect sujungia du atskirus mainus viena trumpalaike reikšme: žiniatinklio prisijungimą ir VPN tunelį. Pirmasis mainas yra įprastas HTTPS: prisijungimo duomenys, SAML kelionė arba žetonas keliauja į tinklą, o atsakymas neša autentifikavimo slapuką. Antrasis mainas pateikia tą slapuką tam pačiam tinklui kaip įrodymą, kad žiniatinklio etapas jau įvyko, ir tik tada pakyla tunelis.

Prisijungimo metu dėl tunelio nieko nederama. Būtent tai verta suprasti, nes dauguma scenarijų klaidų mano, kad slapukas yra saugomas slaptažodis arba raktas, saugantis srautą, nors iš tikrųjų tai yra nešėjo bilietas konkrečiai tinklo sesijai.

Ką klientas ir tinklas keičiasi iš eilės

Autentifikavimo etapas atrodo kaip įprasta apsaugota svetainė. OpenConnect siunčia naudotojo prisijungimo duomenis arba seka tinklo peradresavimą į tapatybės teikėją, o tinklas atsako dokumentu, kuriame įterptas autentifikavimo slapukas. AnyConnect protokole ši reikšmė keliauja slapuko antraštėje vėlesniuose užklausose, paprastai tokiu pavadinimu kaip webvpn, ir vadovas ją laiko prisijungimo duomenimis, kurie neša sesiją į priekį.

Antrasis etapas yra CONNECT užklausa į tinklo VPN galinį tašką su tuo slapuku. Tinklas jį patikrina, priskiria adresą, o klientas paleidžia CSTP per TLS, o DTLS yra pasirenkamas greitesnis duomenų kelias, kai sesija jau egzistuoja. Tik šiuo metu nustatomi tunelio parametrai, maršrutai, DNS nuostatos ir sesijos srauto raktai. Slapukas pravedė klientą pro duris; jis nieko neužšifravo.

Ši seka paaiškina, kodėl egzistuoja openconnect --authenticate. Paleiskite jį ir jis atlieka žiniatinklio etapą, išspausdina nedidelį shell kintamųjų bloką, pavyzdžiui, COOKIE, HOST, CONNECT_URL ir FINGERPRINT, ir tada baigia darbą prieš statant bet kokį tunelį. Tada apvalkalo scenarijus gali pradėti tikrąjį ryšį su tomis reikšmėmis, ir tai yra būtent tas atskyrimas, kurio reikia diegimui be ekrano ar dviejuose konteineriuose.

Slapukas yra sesijos nešėjas, o ne raktas

Elkitės su reikšme taip, kaip elgtumėtės su sesijos identifikatoriumi žiniatinklio programoje. Kas ją turi jos gyvavimo metu, gali paprašyti tinklo tunelio, į kurį ta sesija turi teisę, todėl jos slaptumas svarbus. Tačiau kopijavimas neatskleidžia srauto, nes tunelio konfidencialumas kyla iš TLS rankos paspaudimo ir išvestinių raktų, o ne iš slapuko eilutės.

Tai irgi nėra nuolatinis leidimas. Tinklas ir tapatybės teikėjas nusprendžia, kiek gyvuoja sesija, o naršyklė, kuri dar rodo prisijungusį puslapį, nieko nesako apie tai, ar tunelio sesija dar galioja. Prisijungimas iš naujo po pasibaigimo reiškia pakartoti žiniatinklio etapą ir sukurti naują slapuką, ir būtent tokia yra pakartotinio autentifikavimo prasmė, o ne nepatogumas, kurį reikėtų apeiti inžinerinėmis priemonėmis.

Nelaikykite slapuko visuotiniu kitų prisijungimo duomenų pakaitalu. SAML teiginys, naršyklės slaptažodis ir kito serviso išduotas slapukas yra skirtingi objektai su skirtingomis auditorijomis, o vieno įklijavimas į kito lauką paprastai nepavyksta ties tinklu arba, kas dar blogiau, pavyksta prieš netinkamą pasitikėjimo ribą.

Slapuko perdavimas nepaliekant kopijų

Saugiausias mechaninis perdavimas Linux sistemoje yra standartinė įvestis. --cookie-on-stdin nuskaito reikšmę iš stdin, todėl slapukas niekada neatsiranda proceso argumentų sąraše, kur bet kuris vietinis naudotojas gali jį perskaityti su ps. Dujotiekis, kuris autentifikuoja viename procese ir maitina tunelį kitame, laiko reikšmę vamzdyje, o ne byloje ar aplinkos kintamajame.

Argumentai ir aplinkos kintamieji yra silpnesni dėl skirtingų priežasčių. Argumentas matomas procesų lentelėje per visą kliento gyvavimą ir dažnai patenka į shell istoriją. Aplinkos kintamasis paveldimas vaikų procesų, o systemd įrenginys, kuris jį nustato įrenginio byloje, saugo paslaptį skaitomoje konfigūracijoje. Jei byla būtina, apribokite ją paslaugos paskyra ir pašalinkite pasibaigus sesijai.

Išlaikykite ir privilegijų ribą sąmoningą. Procesas, kuris kalba su tapatybės teikėju ir galbūt atidaro naršyklę, turėtų veikti kaip naudotojas, kuriam priklauso tas prisijungimas. Procesui, kuris konfigūruoja maršrutus, DNS ir tunelio įrenginį, gali prireikti daugiau privilegijų. Visos naršyklės paleidimas kaip root, kad jos slapukas būtų prieinamas root valdomam tuneliui, yra netinkama mainų kaina, o šiuolaikinės OpenConnect sąrankos gali aiškiai perduoti reikšmę per tą ribą.

Žurnalavimas nusipelno to paties įtarumo. Išsami kliento išvestis, pagalbiniai scenarijai ir tinklo diagnostika gali kartoti užklausos medžiagą, ir ne kiekvienas žurnalo lygis paslepia slapuką. Užfiksuokite mažiausią reikalingą klaidos įrašą, laikykite jį už bendrų kanalų ribų ir prieš pridėdami prie bilieto patikrinkite paslėptą pavyzdį.

Patikra ir pasibaigimas antrajame etape

Antrasis etapas vis tiek turi patikrinti serverį. FINGERPRINT, kurį išspausdina --authenticate, yra sertifikato prispaudimas forma pin-sha256:, o jo perdavimas tunelio kvietimui su --servercert išlaiko patikrą prisegtą prie tinklo, prieš kurį autentifikavotės. Sertifikatų patikros išjungimas, siekiant supaprastinti scenarijų, pašalina vienintelį įrodymą, kad slapukas perduodamas numatytam hostui.

Kai tinklas atmeta slapuką, sprendimas yra naujas autentifikavimo ratas, o ne ilgesnė talpykla. Saugokite slapuką tik ryšio gyvavimo metu, ištrinkite laikinas bylas išėjus ir naudokite tapatybės teikėjo arba tinklo sesijos pašalinimo procedūrą, kai sesija atskleidžiama arba pametamas įrenginys. Talpykloje laikomas slapukas nėra MFA išimtis.

Prieš automatizuodami tai patikrinkite keturis dalykus: tunelis veikia su tinkama paskyra, slapukas atkeliauja per stdin, sertifikato piršto atspaudas yra prisegtas, o sesija išmetama, kai tunelis uždaromas. Jei ko nors trūksta, automatizavimas išplėtė pasitikėjimą slapuku, o ne atkartojo rankinį srautą.