OpenConnect bir oturum açma çerezini nasıl tünele dönüştürür?

OpenConnect iki ayrı alışverişi tek bir kısa ömürlü değerle birbirine bağlar: web oturum açma ve VPN tüneli. İlk alışveriş sıradan HTTPS'tir: kimlik bilgileri, bir SAML gidiş dönüşü veya bir belirteç ağ geçidine gider ve yanıt bir kimlik doğrulama çerezi taşır. İkinci alışveriş o çerezi aynı ağ geçidine web aşamasının zaten gerçekleştiğinin kanıtı olarak sunar ve ancak o zaman tünel yükselir.

Oturum açma sırasında tünel hakkında hiçbir şey müzakere edilmez. Anlaşılması gereken tam olarak budur, çünkü çoğu betik hatası çerezin saklanacak bir parola ya da trafiği koruyan bir anahtar olduğunu varsayar, oysa gerçekte belirli bir ağ geçidi oturumu için taşıyıcı biletidir.

İstemci ve ağ geçidi sırayla ne alışveriş eder

Kimlik doğrulama aşaması sıradan korumalı bir web sitesi gibi görünür. OpenConnect kullanıcının kimlik bilgilerini gönderir veya ağ geçidinin bir kimlik sağlayıcısına yönlendirmesini izler ve ağ geçidi kimlik doğrulama çerezini gömülü olarak içeren bir belgeyle yanıt verir. AnyConnect protokolünde bu değer sonraki isteklerde bir çerez başlığında yol alır, genellikle webvpn gibi bir ad altında, ve kılavuz onu oturumu ileri taşıyan kimlik bilgisi olarak ele alır.

İkinci aşama, o çerez eklenmiş olarak ağ geçidinin VPN uç noktasına yapılan CONNECT isteğidir. Ağ geçidi onu denetler, bir adres atar ve istemci TLS üzerinde CSTP başlatır; oturum oluştuktan sonra DTLS isteğe bağlı daha hızlı veri yolu olur. Tünel parametreleri, yollar, DNS ayarları ve oturumun trafik anahtarları yalnızca bu noktada belirlenir. Çerez istemciyi kapıdan geçirdi; hiçbir şeyi şifrelemedi.

Bu sıra openconnect --authenticate neden var olduğunu açıklar. Çalıştırın: web aşamasını yapar, COOKIE, HOST, CONNECT_URL ve FINGERPRINT gibi küçük bir kabuk değişkeni bloğu yazdırır ve herhangi bir tünel kurulmadan önce çıkar. Bir sarmalayıcı betik daha sonra o değerlerle gerçek bağlantıyı başlatabilir ve bu tam olarak ekransız veya iki konteynerli bir kurulumun ihtiyaç duyduğu ayrımdır.

Çerez bir oturum taşıyıcısıdır, anahtar değil

Değere bir web uygulamasındaki oturum kimliğine davrandığınız gibi davranın. Onu ömrü boyunca elinde tutan kişi, ağ geçidinden o oturumun hakkı olan tüneli isteyebilir, bu yüzden gizliliği önemlidir. Ancak kopyalamak trafiği açığa çıkarmaz, çünkü tünelin gizliliği TLS el sıkışmasından ve türetilen anahtarlardan gelir, çerez dizesinden değil.

Kalıcı bir yetki de değildir. Oturumun ne kadar yaşayacağına ağ geçidi ve kimlik sağlayıcı karar verir ve hâlâ oturum açılmış bir sayfa gösteren tarayıcı, tünel oturumunun hâlâ geçerli olup olmadığı hakkında hiçbir şey söylemez. Süre dolduktan sonra yeniden bağlanmak, web aşamasını yinelemek ve yeni bir çerez üretmek anlamına gelir; yeniden kimlik doğrulamanın amacı da budur, mühendislikle etrafından dolaşılacak bir sıkıntı değil.

Bir çerezi diğer kimlik bilgilerinin evrensel yerine koyucusu olarak görmeyin. Bir SAML iddiası, bir tarayıcı parolası ve başka bir hizmetin verdiği çerez, farklı hedef kitlelere sahip farklı nesnelerdir ve birini diğerinin alanına yapıştırmak genellikle ağ geçidinde başarısız olur ya da daha kötüsü yanlış güven sınırına karşı başarılı olur.

Çerezi kopya bırakmadan devretmek

Linux'ta en güvenli mekanik devir standart girdidir. --cookie-on-stdin değeri stdin'den okur, böylece çerez sürecin bağımsız değişken listesinde asla görünmez; orada herhangi bir yerel kullanıcı onu ps ile okuyabilir. Bir süreçte kimlik doğrulayıp tüneli başka bir süreçte besleyen boru hattı, değeri dosya veya ortam değişkeni yerine bir boruda tutar.

Bağımsız değişkenler ve ortam değişkenleri farklı nedenlerle daha zayıftır. Bir bağımsız değişken istemcinin tüm ömrü boyunca süreç tablosunda görünür ve çoğu zaman kabuk geçmişine düşer. Bir ortam değişkeni alt süreçlere miras kalır ve onu birim dosyasında ayarlayan systemd birimi sırrı okunabilir bir yapılandırmada saklar. Bir dosya kaçınılmazsa, onu hizmet hesabıyla sınırlayın ve oturum bittiğinde silin.

Ayrıcalık sınırını da bilinçli tutun. Kimlik sağlayıcıyla konuşan ve belki bir tarayıcı açan süreç, o oturum açmanın sahibi olan kullanıcı olarak çalışmalıdır. Yolları, DNS'i ve tünel aygıtını yapılandıran sürecin daha fazla ayrıcalığa ihtiyacı olabilir. Çerezinin root'a ait bir tünel için erişilebilir olması uğruna tüm tarayıcıyı root olarak çalıştırmak yanlış bir değiş tokuştur ve modern OpenConnect kurulumları değeri bu sınırın ötesine açıkça aktarabilir.

Günlükleme de aynı kuşkuyu hak eder. Ayrıntılı istemci çıktısı, yardımcı betikler ve ağ geçidi tanılaması istek malzemesini yineleyebilir ve her günlük düzeyi çerezi gizlemez. İhtiyacınız olan en küçük hata kaydını yakalayın, paylaşılan kanalların dışında tutun ve bir bilete eklemeden önce gizlenmiş bir örneği kontrol edin.

İkinci aşamada doğrulama ve süre sonu

İkinci aşama yine de sunucuyu doğrulamalıdır. --authenticate komutunun yazdırdığı FINGERPRINT, pin-sha256: biçiminde bir sertifika sabitlemesidir ve onu --servercert ile tünel çağrısına vermek denetimi kimlik doğruladığınız ağ geçidine sabitlenmiş tutar. Bir betiği basitleştirmek için sertifika denetimini kapatmak, çerezin amaçlanan ana makineye verildiğine dair tek kanıtı ortadan kaldırır.

Ağ geçidi çerezi reddettiğinde çözüm daha uzun bir önbellek değil, yeni bir kimlik doğrulama turudur. Çerezi yalnızca bağlantının ömrü boyunca saklayın, çıkışta geçici dosyaları silin ve bir oturum açığa çıktığında ya da bir aygıt kaybolduğunda kimlik sağlayıcının veya ağ geçidinin oturum kaldırma sürecini kullanın. Önbelleğe alınmış çerez MFA'dan muafiyet değildir.

Bunu otomatikleştirmeden önce dört şeyi doğrulayın: tünel doğru hesap altında çalışıyor, çerez stdin üzerinden geliyor, sertifikanın parmak izi sabitlenmiş ve tünel kapandığında oturum atılıyor. Bunlardan biri eksikse otomasyon, elle yapılan akışı yeniden üretmek yerine çereze duyulan güveni genişletmiştir.