Як 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, які задае яе ў файле юніта, захоўвае сакрэт у чытэльнай канфігурацыі. Калі файл неабходны, абмяжуйце яго службовым уліковым запісам і выдаляйце па заканчэнні сесіі.

Трымайце мяжу прывілеяў свядомай. Працэс, які размаўляе з пастаўшчыком ідэнтычнасці і, магчыма, адкрывае браўзер, павінен працаваць ад імя карыстальніка, якому належыць гэты ўваход. Працэсу, які настройвае маршруты, DNS і прыладу тунеля, можа спатрэбіцца больш прывілеяў. Запуск усяго браўзера ад імя root, каб яго кукі былі даступныя тунелю, якім валодае root, — гэта няправільны абмен, і сучасныя ўстаноўкі OpenConnect могуць перадаваць значэнне праз гэтую мяжу яўна.

Журналяванне заслугоўвае такой жа падазронасці. Падрабязны вывад кліента, дапаможныя скрыпты і дыягностыка шлюза могуць усё паўтараць матэрыял запыту, і не кожны ўзровень журнала зацірае кукі. Запісвайце найменшы запіс памылкі, які вам патрэбны, трымайце яго па-за агульнымі каналамі і правярайце адрэдагаваны ўзор, перш чым далучаць яго да заяўкі.

Праверка і заканчэнне тэрміну ў другой фазе

Другая фаза ўсё яшчэ павінна правяраць сервер. FINGERPRINT, які друкуе --authenticate, — гэта замацаванне сертыфіката ў форме pin-sha256:, і перадача яго выкліку тунеля праз --servercert трымае праверку прывязанай да шлюза, супраць якога вы аўтэнтыфікаваліся. Адключэнне праверкі сертыфіката, каб спрасціць скрыпт, выдаляе адзіны доказ таго, што кукі перадаюцца мэтаваму хосту.

Калі шлюз адхіляе кукі, рашэнне — новы раўнд аўтэнтыфікацыі, а не даўжэйшы кэш. Захоўвайце кукі толькі на час злучэння, выдаляйце часовыя файлы пры выхадзе і выкарыстоўвайце працэс выдалення сесіі пастаўшчыка ідэнтычнасці або шлюза, калі сесія раскрыта або прылада страчана. Кэшаваныя кукі не вызваляюць ад MFA.

Перш чым аўтаматызаваць гэта, праверце чатыры рэчы: тунель працуе пад правільным уліковым запісам, кукі прыходзяць праз stdin, адбітак сертыфіката замацаваны, а сесія адкідаецца, калі тунель зачыняецца. Калі чагосьці з гэтага няма, аўтаматызацыя пашырыла давер да кукі замест таго, каб паўтарыць ручны працэс.