Kā OpenConnect pārvērš pieteikšanās sīkfailu tunelī?

OpenConnect saista divas atsevišķas apmaiņas ar vienu īslaicīgu vērtību: tīmekļa pieteikšanos un VPN tuneli. Pirmā apmaiņa ir parasts HTTPS: akreditācijas dati, SAML ceļojums vai marķieris dodas uz vārteju, un atbilde nes autentifikācijas sīkfailu. Otrā apmaiņa uzrāda šo sīkfailu tai pašai vārtejai kā pierādījumu, ka tīmekļa fāze jau ir notikusi, un tikai tad tunelis ceļas.

Pieteikšanās laikā par tuneli nekas netiek pārrunāts. Tieši to ir vērts saprast, jo lielākā daļa skriptu kļūdu pieņem, ka sīkfails ir saglabājama parole vai atslēga, kas aizsargā datplūsmu, bet patiesībā tas ir nesējbiļete konkrētai vārtejas sesijai.

Ko klients un vārteja apmaina pēc kārtas

Autentifikācijas fāze izskatās kā parasta aizsargāta vietne. OpenConnect nosūta lietotāja akreditācijas datus vai seko vārtejas novirzīšanai uz identitātes nodrošinātāju, un vārteja atbild ar dokumentu, kurā iekļauts autentifikācijas sīkfails. AnyConnect protokolā šī vērtība ceļo sīkfaila galvenē turpmākajos pieprasījumos, parasti ar tādu nosaukumu kā webvpn, un rokasgrāmata to uzskata par akreditācijas datiem, kas nes sesiju uz priekšu.

Otrā fāze ir CONNECT pieprasījums uz vārtejas VPN galapunktu ar šo sīkfailu pievienotu. Vārteja to pārbauda, piešķir adresi, un klients sāk CSTP virs TLS, bet DTLS ir neobligāts ātrāks datu ceļš, tiklīdz sesija pastāv. Tikai šajā brīdī tiek noteikti tuneļa parametri, maršruti, DNS iestatījumi un sesijas datplūsmas atslēgas. Sīkfails palaida klientu pa durvīm; tas neko nešifrēja.

Šī secība izskaidro, kāpēc pastāv openconnect --authenticate. Palaidiet to, un tas veic tīmekļa fāzi, izdrukā nelielu čaulas mainīgo bloku, piemēram, COOKIE, HOST, CONNECT_URL un FINGERPRINT, un pēc tam beidz darbu pirms jebkura tuneļa izveides. Pēc tam ietvara skripts var sākt īsto savienojumu ar šīm vērtībām, un tā ir tieši tā atdalīšana, kas nepieciešama bezgalvas vai divu konteineru izvietošanai.

Sīkfails ir sesijas nesējs, nevis atslēga

Izturieties pret vērtību tā, kā jūs izturētos pret sesijas identifikatoru tīmekļa lietotnē. Ikviens, kam tā pieder tās darbības laikā, var pieprasīt no vārtejas tuneli, uz kuru šai sesijai ir tiesības, tāpēc tās slepenība ir svarīga. Taču kopēšana neatklāj datplūsmu, jo tuneļa konfidencialitāte nāk no TLS rokasspiediena un atvasinātajām atslēgām, nevis no sīkfaila virknes.

Tā arī nav pastāvīga atļauja. Vārteja un identitātes nodrošinātājs izlemj, cik ilgi sesija dzīvo, un pārlūks, kas vēl rāda pieteikto lapu, neko nepasaka par to, vai tuneļa sesija joprojām ir derīga. Atkārtota savienošana pēc termiņa beigām nozīmē atkārtot tīmekļa fāzi un izveidot jaunu sīkfailu, un tā ir atkārtotas autentifikācijas jēga, nevis neērtība, kas jāapiet ar inženiertehniskām metodēm.

Neuzskatiet sīkfailu par universālu citu akreditācijas datu aizstājēju. SAML apgalvojums, pārlūka parole un citas pakalpojuma izsniegts sīkfails ir dažādi objekti ar dažādu auditoriju, un viena ielīmēšana otra laukā parasti neizdodas pie vārtejas vai, kas ir sliktāk, izdodas pret nepareizu uzticības robežu.

Sīkfaila nodošana, neatstājot kopijas

Drošākā mehāniskā nodošana Linux sistēmā ir standarta ievade. --cookie-on-stdin nolasa vērtību no stdin, tāpēc sīkfails nekad neparādās procesa argumentu sarakstā, kur jebkurš vietējais lietotājs to var nolasīt ar ps. Cauruļvads, kas autentificē vienā procesā un baro tuneli citā, glabā vērtību caurulē, nevis failā vai vides mainīgajā.

Argumenti un vides mainīgie ir vājāki dažādu iemeslu dēļ. Arguments ir redzams procesu tabulā visu klienta darbības laiku un bieži nonāk čaulas vēsturē. Vides mainīgais tiek mantots bērnu procesos, un systemd vienība, kas to iestata vienības failā, glabā noslēpumu lasāmā konfigurācijā. Ja fails ir nepieciešams, ierobežojiet to ar pakalpojuma kontu un izdzēsiet, kad sesija beidzas.

Saglabājiet arī privilēģiju robežu apzināti. Procesam, kas runā ar identitātes nodrošinātāju un varbūt atver pārlūku, vajadzētu darboties kā lietotājam, kuram pieder šī pieteikšanās. Procesam, kas konfigurē maršrutus, DNS un tuneļa ierīci, var būt vajadzīgas lielākas privilēģijas. Visa pārlūka palaišana kā root, lai tā sīkfails būtu pieejams root piederīgajam tunelim, ir nepareizs darījums, un mūsdienu OpenConnect iestatījumi var skaidri nodot vērtību pāri šai robežai.

Žurnālēšana ir pelnījusi tādas pašas aizdomas. Detalizēta klienta izvade, palīgskripti un vārtejas diagnostika var atkārtot pieprasījuma materiālu, un ne katrs žurnāla līmenis aizklāj sīkfailu. Ierakstiet mazāko nepieciešamo kļūdas ierakstu, turiet to ārpus kopīgiem kanāliem un pirms pievienošanas biļetei pārbaudiet aizklātu paraugu.

Pārbaude un termiņa beigas otrajā fāzē

Otrajai fāzei joprojām ir jāpārbauda serveris. FINGERPRINT, ko izdrukā --authenticate, ir sertifikāta piesaiste formā pin-sha256:, un tā nodošana tuneļa izsaukumam ar --servercert notur pārbaudi piesaistītu vārtejai, pret kuru jūs autentificējāties. Sertifikātu pārbaudes izslēgšana, lai vienkāršotu skriptu, noņem vienīgo pierādījumu, ka sīkfails tiek nodots paredzētajam resursdatoram.

Kad vārteja noraida sīkfailu, risinājums ir jauns autentifikācijas aplis, nevis garāka kešatmiņa. Glabājiet sīkfailu tikai savienojuma darbības laikā, dzēsiet pagaidu failus izejot un izmantojiet identitātes nodrošinātāja vai vārtejas sesijas noņemšanas procesu, kad sesija tiek atklāta vai ierīce tiek pazaudēta. Kešatmiņā saglabāts sīkfails nav atbrīvojums no MFA.

Pirms šī automatizēšanas pārbaudiet četras lietas: tunelis darbojas ar pareizo kontu, sīkfails ierodas pa stdin, sertifikāta nospiedums ir piesaistīts un sesija tiek izmesta, kad tunelis aizveras. Ja kaut kas no tā trūkst, automatizācija ir paplašinājusi uzticēšanos sīkfailam, nevis atkārtojusi manuālo plūsmu.