Как OpenConnect превръща бисквитка от уеб вход в тунел?

OpenConnect свързва два отделни обмена с една краткотрайна стойност: уеб входа и VPN тунела. Първият обмен е обикновен HTTPS: идентификационните данни, кръговото пътуване на SAML или токен отиват до шлюза, а отговорът носи бисквитка за удостоверяване. Вторият обмен представя тази бисквитка на същия шлюз като доказателство, че уеб фазата вече е станала, и едва тогава тунелът се вдига.

По време на входа нищо за тунела не се договаря. Именно това си струва да се разбере, защото повечето грешки в скриптовете приемат, че бисквитката е парола за съхранение или ключ, който защитава трафика, докато в действителност тя е билет за пренасяне на конкретна сесия на шлюза.

Какво разменят клиентът и шлюзът, по ред

Фазата на удостоверяване изглежда като обикновен защитен уеб сайт. OpenConnect изпраща идентификационните данни на потребителя или следва пренасочването на шлюза към доставчик на самоличност, а шлюзът отговаря с документ, който вгражда бисквитката за удостоверяване. В протокола AnyConnect тази стойност пътува в заглавка за бисквитки при следващите заявки, обикновено под име като webvpn, и ръководството я третира като данните, които пренасят сесията напред.

Втората фаза е заявка CONNECT към VPN крайната точка на шлюза с прикачена тази бисквитка. Шлюзът я проверява, задава адрес, и клиентът стартира CSTP върху TLS, а DTLS служи като незадължителен по-бърз път за данни, след като сесията съществува. Едва в този момент се установяват параметрите на тунела, маршрутите, настройките за DNS и ключовете за трафика на сесията. Бисквитката преведе клиента през вратата; тя не шифрова нищо.

Тази последователност обяснява защо съществува openconnect --authenticate. Стартирайте го и той изпълнява уеб фазата, отпечатва малък блок от променливи на обвивката като COOKIE, HOST, CONNECT_URL и FINGERPRINT, след което излиза преди изграждането на какъвто и да е тунел. Скрипт обвивка може после да започне истинската връзка с тези стойности, което е точно разделянето, нужно за разгръщане без графична среда или в два контейнера.

Бисквитката е носител на сесия, а не ключ

Отнасяйте се към стойността така, както бихте се отнасяли към идентификатор на сесия в уеб приложение. Който я държи през живота ѝ, може да поиска от шлюза тунела, на който тази сесия има право, затова тайната ѝ е важна. Но копирането не разкрива трафик, защото поверителността на тунела идва от TLS ръкостискането и производните ключове, а не от низа на бисквитката.

Тя също не е постоянно разрешение. Шлюзът и доставчикът на самоличност решават колко дълго живее сесията, а браузър, който още показва страница с влязъл потребител, не казва нищо за това дали сесията на тунела е още валидна. Повторното свързване след изтичане означава повторение на уеб фазата и създаване на нова бисквитка, и точно това е смисълът на повторното удостоверяване, а не досада, която да се заобикаля с инженерни средства.

Не третирайте бисквитката като универсална замяна на други идентификационни данни. SAML твърдение, парола в браузър и бисквитка, издадена от друга услуга, са различни обекти с различни аудитории, и поставянето на едното в полето на другото обикновено се проваля на шлюза или, което е по-лошо, успява срещу грешната граница на доверие.

Предаване на бисквитката без оставащи копия

Най-безопасното механично предаване в Linux е стандартният вход. --cookie-on-stdin чете стойността от stdin, така че бисквитката никога не се появява в списъка с аргументи на процеса, където всеки локален потребител може да я прочете с ps. Конвейер, който удостоверява в един процес и храни тунела в друг, държи стойността в тръба, а не във файл или променлива на средата.

Аргументите и променливите на средата са по-слаби по различни причини. Аргументът е видим в таблицата на процесите през целия живот на клиента и често попада в историята на обвивката. Променливата на средата се наследява от дъщерните процеси, а systemd unit, който я задава във файла на unit, съхранява тайната в четима конфигурация. Ако все пак е нужен файл, ограничете го до сервизния акаунт и го изтрийте, когато сесията приключи.

Пазете и границата на привилегиите съзнателно. Процесът, който говори с доставчика на самоличност и евентуално отваря браузър, трябва да работи като потребителя, на когото принадлежи този вход. Процесът, който конфигурира маршрути, DNS и устройството на тунела, може да се нуждае от повече привилегии. Пускането на целия браузър като root, за да е достъпна бисквитката му за тунел, собственост на root, е грешна размяна, а съвременните настройки на OpenConnect могат изрично да предадат стойността през тази граница.

Регистрирането заслужава същото подозрение. Подробният изход на клиента, помощните скриптове и диагностиката на шлюза могат да повторят материал от заявката, и не всяко ниво на регистриране скрива бисквитката. Записвайте най-малкия запис за грешка, който ви е нужен, дръжте го извън споделени канали и проверявайте редактиран образец, преди да го прикачите към заявка.

Проверка и изтичане във втората фаза

Втората фаза все още трябва да проверява сървъра. FINGERPRINT, който --authenticate отпечатва, е закрепване на сертификат във формата pin-sha256:, и предаването му към извикването на тунела с --servercert държи проверката закотвена към шлюза, срещу който сте се удостоверили. Изключването на проверката на сертификата, за да се опрости скрипт, премахва единственото доказателство, че бисквитката се предава на предвидения хост.

Когато шлюзът отхвърли бисквитката, решението е нов кръг на удостоверяване, а не по-дълъг кеш. Съхранявайте бисквитката само за живота на връзката, изтривайте временните файлове при изход и използвайте процеса за премахване на сесия на доставчика на самоличност или на шлюза, когато сесия бъде разкрита или устройство бъде загубено. Кешираната бисквитка не е освобождаване от MFA.

Преди да автоматизирате това, проверете четири неща: тунелът работи под правилния акаунт, бисквитката пристига по stdin, отпечатъкът на сертификата е закрепен и сесията се изхвърля, когато тунелът се затвори. Ако липсва някое от тях, автоматизацията е разширила доверието към бисквитката, вместо да възпроизведе ръчния поток.