OpenConnect giriş kukisini necə tunelə çevirir?

OpenConnect iki ayrı mübadiləni bir qısaömürlü dəyərlə birləşdirir: veb girişi və VPN tuneli. Birinci mübadilə adi HTTPS-dir: etimad məlumatları, SAML gediş-dönüşü və ya token şlüza gedir, cavab isə autentifikasiya kukisini daşıyır. İkinci mübadilə həmin kukini eyni şlüza veb mərhələsinin artıq baş verdiyinin sübutu kimi təqdim edir və yalnız bundan sonra tunel qalxır.

Giriş zamanı tunellə bağlı heç nə danışılmır. Anlamağa dəyər hissə elə budur, çünki skript səhvlərinin çoxu kukini saxlanılacaq parol və ya trafiki qoruyan açar hesab edir, halbuki o, müəyyən bir şlüz sessiyası üçün daşıyıcı biletdir.

Müştəri ilə şlüz ardıcıllıqla nə mübadilə edir

Autentifikasiya mərhələsi adi qorunan veb sayta bənzəyir. OpenConnect istifadəçinin etimad məlumatlarını göndərir və ya şlüzün kimlik provayderinə yönləndirməsini izləyir, şlüz isə autentifikasiya kukisini daxil edən sənədlə cavab verir. AnyConnect protokolunda bu dəyər sonrakı sorğularda kuki başlığında gedir, adətən webvpn kimi bir ad altında, və təlimat onu sessiyanı irəli aparan etimad sənədi kimi qəbul edir.

İkinci mərhələ həmin kuki əlavə olunmuş şlüzün VPN son nöqtəsinə CONNECT sorğusudur. Şlüz onu yoxlayır, ünvan təyin edir və müştəri TLS üzərindən CSTP başladır, sessiya yarandıqdan sonra DTLS isteğe bağlı daha sürətli məlumat yolu kimi çıxış edir. Yalnız bu anda tunel parametrləri, marşrutlar, DNS ayarları və sessiyanın trafik açarları qurulur. Kuki müştərini qapıdan keçirdi; heç nəyi şifrələmədi.

Bu ardıcıllıq openconnect --authenticate əmrinin niyə mövcud olduğunu izah edir. Onu işə salın: veb mərhələsini yerinə yetirir, COOKIE, HOST, CONNECT_URL və FINGERPRINT kimi kiçik bir shell dəyişənləri bloku çap edir və hər hansı tunel qurulmadan çıxır. Sonra sarğı skripti bu dəyərlərlə real bağlantını başlada bilər; bu da başsız və ya iki konteynerli yerləşdirmənin istədiyi bölgüdür.

Kuki açardan deyil, sessiya daşıyıcısıdır

Dəyərə veb tətbiqindəki sessiya identifikatoru kimi yanaşın. Kim onu ömrü boyu saxlayırsa, şlüzdən həmin sessiyanın haqqı olan tuneli istəyə bilər, ona görə məxfilik vacibdir. Amma onu kopyalamaq trafiki açmır, çünki tunelin məxfiliyi TLS əl sıxmasından və törəmə açarlardan gəlir, kuki sətrindən deyil.

O həm də daimi icazə deyil. Sessiyanın nə qədər yaşayacağına şlüz və kimlik provayderi qərar verir, hələ də daxil olmuş səhifə göstərən brauzer isə tunel sessiyasının hələ qüvvədə olub-olmadığı barədə heç nə demir. Müddət bitdikdən sonra yenidən qoşulmaq veb mərhələsini təkrarlamaq və təzə kuki yaratmaq deməkdir; yenidən autentifikasiyanın məqsədi də budur, ətrafından yan keçiləcək bir əngəl deyil.

Kukini digər etimad məlumatları üçün universal əvəz kimi qəbul etməyin. SAML təsdiqi, brauzer parolu və başqa xidmətin verdiyi kuki fərqli auditoriyalara malik fərqli obyektlərdir və birini digərinin sahəsinə yapışdırmaq adətən şlüzdə uğursuz olur və ya daha pisi, yanlış etimad sərhədi qarşısında uğur qazanır.

Kukini nüsxə qoymadan ötürmək

Linuxda ən təhlükəsiz mexaniki təhvil standart girişdir. --cookie-on-stdin dəyəri stdin-dən oxuyur, beləliklə kuki prosesin arqument siyahısında görünmür, orada istənilən yerli istifadəçi onu ps ilə oxuya bilərdi. Bir prosesdə autentifikasiya edib tuneli başqa prosesdə qidalandıran boru xətti dəyəri faylda və ya mühit dəyişənində deyil, boruda saxlayır.

Arqumentlər və mühit dəyişənləri müxtəlif səbəblərdən daha zəifdir. Arqument müştərinin ömrü boyu proses cədvəlində görünür və çox vaxt shell tarixçəsinə düşür. Mühit dəyişəni alt proseslərə miras qalır və onu unit faylında təyin edən systemd uniti sirri oxuna bilən konfiqurasiyada saxlayır. Fayl mütləqdirsə, onu xidmət hesabı ilə məhdudlaşdırın və sessiya bitəndə silin.

İmtiyaz sərhədini də qəsdən saxlayın. Kimlik provayderi ilə danışan və bəlkə brauzer açan proses həmin girişin sahibi olan istifadəçi kimi işləməlidir. Marşrutları, DNS-i və tunel cihazını konfiqurasiya edən prosesə daha çox imtiyaz lazım ola bilər. Kukisi root-a məxsus tunelə çatmaq üçün bütün brauzeri root kimi işlətmək səhv mübadilədir və müasir OpenConnect qurğuları dəyəri bu sərhəddən açıq şəkildə keçirə bilər.

Jurnallaşdırma da eyni şübhəyə layiqdir. Ətraflı müştəri çıxışı, köməkçi skriptlər və şlüz diaqnostikası sorğu materialını təkrar edə bilər və hər jurnal səviyyəsi kukini gizlətmir. Lazım olan ən kiçik xəta qeydini götürün, onu ortaq kanallardan kənarda saxlayın və bileti əlavə etməzdən əvvəl gizlədilmiş nümunəyə baxın.

İkinci mərhələdə yoxlama və müddətin bitməsi

İkinci mərhələ hələ də serveri yoxlamalıdır. --authenticate çap etdiyi FINGERPRINT pin-sha256: formasında sertifikat sancaqlamasıdır və onu --servercert ilə tunel çağırışına ötürmək yoxlamanı autentifikasiyadan keçdiyiniz şlüzə bağlı saxlayır. Skripti sadələşdirmək üçün sertifikat yoxlamasını söndürmək kukinin nəzərdə tutulan hosta verildiyinə dair yeganə sübutu aradan qaldırır.

Şlüz kukini rədd etdikdə həll daha uzun keş deyil, yeni autentifikasiya raundudur. Kukini yalnız bağlantının ömrü boyu saxlayın, çıxışda müvəqqəti faylları silin və sessiya ifşa olunduqda və ya cihaz itdikdə kimlik provayderinin və ya şlüzün sessiya silmə prosesindən istifadə edin. Keşlənmiş kuki MFA-dan azadetmə deyil.

Bunu avtomatlaşdırmadan əvvəl dörd şeyi yoxlayın: tunel düzgün hesabla işləyir, kuki stdin ilə gəlir, sertifikat barmaq izi bərkidilib və tunel bağlananda sessiya atılır. Bunlardan biri yoxdursa, avtomatlaşdırma əl axınını təkrar etmək əvəzinə kukiyə olan etimadı genişləndirib.