OpenConnect кирүү кукисин туннелге кантип айландырат?

OpenConnect эки өзүнчө алмашууну бир кыска мөөнөттүү маани менен байланыштырат: веб кирүү жана VPN туннели. Биринчи алмашуу — кадимки HTTPS: каттоо маалыматтары, SAML айлануусу же токен дарбазага барат, ал эми жооп аутентификация кукисин алып келет. Экинчи алмашуу ошол кукини ошол эле дарбазага веб баскычы мурун болгонун далил катары сунуштайт, ошондон кийин гана туннель көтөрүлөт.

Кирүү учурунда туннель жөнүндө эч нерсе сүйлөшүлбөйт. Так ушуну түшүнүү керек, анткени скрипт каталарынын көбү кукини сакталуучу сырсөз же трафикти коргоочу ачкыч деп эсептейт, бирок чынында ал белгилүү дарбаза сессиясы үчүн алып жүрүүчү билет.

Клиент менен дарбаза кезеги менен эмнени алмашат

Аутентификация баскычы кадимки корголгон веб-сайтка окшош. OpenConnect колдонуучунун каттоо маалыматтарын жөнөтөт же дарбазанын идентификация провайдерине багыттоосун ээрчийт, ал эми дарбаза аутентификация кукисин камтыган документ менен жооп берет. AnyConnect протоколунда бул маани кийинки суроолордо куки аталышында жүрөт, адатта webvpn сыяктуу ат менен, жана колдонмо аны сессияны алдыга алып баруучу каттоо маалыматы деп эсептейт.

Экинчи баскыч — дарбазанын VPN акыркы чекитине ошол куки тиркелген CONNECT суроосу. Дарбаза аны текшерет, дарек берет, ал эми клиент TLS үстүндө CSTP баштайт, сессия пайда болгондон кийин DTLS кошумча ылдамыраак маалымат жолу болот. Туннелдин параметрлери, маршруттар, DNS жөндөөлөрү жана сессиянын трафик ачкычтары ушул учурда гана белгиленет. Куки клиентти эшиктен өткөрдү; ал эч нерсени шифрлаганы жок.

Ушул ырааттуулук openconnect --authenticate эмне үчүн бар экенин түшүндүрөт. Аны иштетиңиз, ал веб баскычын аткарат, COOKIE, HOST, CONNECT_URL жана FINGERPRINT сыяктуу shell өзгөрмөлөрүнүн кичинекей блогун басып чыгарат да, кандайдыр бир туннель курулганга чейин чыгат. Андан кийин каптама скрипт ошол маанилер менен чыныгы туташууну баштай алат, жана бул башсыз же эки контейнердик орнотууга керектүү бөлүнүш.

Куки — сессиянын ташыгычы, ачкыч эмес

Мааниге веб-тиркемедеги сессия идентификаторуна мамиле кылгандай мамиле кылгыла. Аны өмүрүндө кармаган адам дарбазадан ошол сессияга таандык туннелди сурай алат, ошондуктан анын жашыруундугу маанилүү. Бирок көчүрүү трафикти ачпайт, анткени туннелдин купуялуулугу TLS кол алышуусунан жана андан алынган ачкычтардан келет, куки сабынан эмес.

Бул туруктуу уруксат да эмес. Сессия канча жашаарын дарбаза менен идентификация провайдери чечет, ал эми азыр кирген баракты көрсөтүп турган браузер туннель сессиясы дагы жарактуубу дегенди айтпайт. Мөөнөтү бүткөндөн кийин кайра туташуу веб баскычын кайталап, жаңы куки жасоону билдирет, жана кайра аутентификациянын максаты дал ушул, инженерия менен айланып өтүүчү тоскоол эмес.

Кукини башка каттоо маалыматтарынын универсалдуу ордун толтуруучусу деп эсептебегиле. SAML ырастоосу, браузер сырсөзү жана башка кызмат чыгарган куки ар башка аудиториясы бар ар башка объектилер, ал эми бирөөнү экинчисинин талаасына коюу адатта дарбазада ийгиликсиз болот же, андан жаманы, туура эмес ишеним чек арасына каршы ийгиликтүү болот.

Кукини көчүрмө калтырбай өткөрүп берүү

Linux системасында эң коопсуз механикалык өткөрүп берүү — стандарттык киргизүү. --cookie-on-stdin маанини stdin-ден окуйт, ошондуктан куки процесстин аргумент тизмесинде эч качан көрүнбөйт, ал жерде каалаган жергиликтүү колдонуучу аны ps менен окуй алат. Бир процессте аутентификация жасап, экинчисинде туннелди азыктандырган түтүк маанини файлда же чөйрө өзгөрмөсүндө эмес, түтүктө кармайт.

Аргументтер жана чөйрө өзгөрмөлөрү ар башка себептерден улам алсыз. Аргумент клиенттин бүт өмүрүндө процесс таблицасында көрүнүп турат жана көбүнчө shell тарыхына түшөт. Чөйрө өзгөрмөсү бала процесстерге мураска өтөт, ал эми аны бирдик файлында белгилеген systemd бирдиги сырды окула турган конфигурацияда сактайт. Эгер файл сөзсүз керек болсо, аны кызмат эсебине чектеп, сессия бүткөндө жок кылгыла.

Артыкчылык чек арасын да атайылап кармагыла. Идентификация провайдери менен сүйлөшкөн жана балким браузер ачкан процесс ошол кирүүгө ээ колдонуучу катары иштеши керек. Маршруттарды, DNS-ти жана туннель түзмөгүн жөндөгөн процесс көбүрөөк артыкчылык талап кылышы мүмкүн. root ээлик кылган туннелге куки жеткирүү үчүн бүт браузерди root катары иштетүү — туура эмес алмашуу, ал эми заманбап OpenConnect жөндөөлөрү маанини бул чек арадан ачык өткөрүп бере алат.

Журналдоо да ошол эле шекке татыктуу. Кенен клиент чыгарылышы, жардамчы скрипттер жана дарбаза диагностикасы суроонун материалын кайталашы мүмкүн, ал эми ар бир журнал деңгээли кукини жашыра бербейт. Өзүңүзгө керектүү эң кичине ката жазуусун кармагыла, аны жалпы каналдардан тышкары кармагыла жана билетке тиркеерден мурун жашырылган үлгүнү текшергиле.

Экинчи баскычта текшерүү жана мөөнөттүн бүтүшү

Экинчи баскыч серверди дагы текшерүүгө тийиш. --authenticate баскан FINGERPRINT — pin-sha256: түрүндөгү сертификат кадоосу, ал эми аны --servercert менен туннель чакырыгына берүү текшерүүнү сиз аутентификацияланган дарбазага байлап турат. Скриптти жөнөкөйлөтүү үчүн сертификат текшерүүсүн өчүрүү кукинин арналган хостко берилип жатканынын жалгыз далилин жок кылат.

Дарбаза кукини четке какканда чечим — жаңы аутентификация айлампасы, узагыраак кэш эмес. Кукини туташуунун өмүрүнө гана сактагыла, чыгууда убактылуу файлдарды жок кылгыла жана сессия ачыкка чыкканда же түзмөк жоголгондо идентификация провайдеринин же дарбазанын сессияны жок кылуу процессин колдонгула. Кэштелген куки MFA-дан бошотуу эмес.

Муну автоматташтыруудан мурун төрт нерсени текшергиле: туннель туура эсеп менен иштейт, куки stdin аркылуу келет, сертификаттын манжа изи кадалган жана туннель жабылганда сессия ташталат. Ушулардын бири жетишпесе, автоматташтыруу кол менен аткарылуучу агымды кайталагандын ордуна кукиге болгон ишенимди кеңейткен.