Şifresi çözülen yolu çizin: VPN cihazı politikayı nerede uygular

Satıcı diyagramları genellikle şifreli dinleyicide durur, çünkü genel adresi olan kısım orasıdır. Güvenlik duruşunu belirleyen soru, şifre çözüldükten sonra ne olduğudur; paket sıradan IP'ye dönüşür ve yönlendirme tablosunun izin verdiği her yere ulaşabilir. O bacağı kimse çizmediyse sahibi de yoktur. Aşağıdaki runbook önce onu çizer, sonra şifresi çözülen isteğin gerçekte neyi geçtiğine göre yerleşimleri karşılaştırır.

Paketi şifre çözüldükten sonra çizin, öncesinde değil

Dış yol, satıcıların belgelediği kısımdır: genel bir uç nokta, bağlantıyı kabul eden bir taşıma politikası ve bağlantıyı sonlandıran bir hizmet. İç yol, paketin tünel başlığını kaybettiği anda başlar ve oradan tünelle hiçbir ilgisi olmayan yönlendirme ve filtre kuralları tarafından yönetilir. İkisini aynı sayfaya koyun, çünkü yalnızca birincisini gösteren bir diyagram kabul ile yetkilendirmenin tek karar olduğunu ima eder. Öyle değildir ve çoğu yerleşim tam da aralarındaki boşlukta yanlış yapar.

İç bacağı ok yerine adlandırılmış cihaz türleriyle numaralı bir dizi olarak yazın. Ok, isteğin bir filtreden geçip geçmediğini saklar ve geçmek ya da geçmemek bütün sorudur. Aşağıdaki her adım cihazı ve orada etkili olan kural kümesini adlandırır, böylece eksik bir filtre bir çizgiyle ima edilen bir şey değil, boşluk olarak görünür.

1. Uzak istemci: tüneli oluşturan kullanıcı cihazı.
2. Kenar politikası: dış taşımayı genel dinleyiciye kabul eden kural kümesi.
3. Sonlandıran cihaz: paketi kapsülden çıkarıp sıradan IP'ye teslim eden VPN uç noktası.
4. İç filtre: istemciden hizmete trafiği sınırlayan yönlendirme veya güvenlik grubu kural kümesi.
5. Uygulama ana bilgisayarı: şifresi çözülen isteği alan hizmet.

İki politika, iki sahip

Dış politika kimin tünel kurabileceğini yanıtlar ve sonlandıran hizmete taşımayı kabul eden kurallarda ifade edilir. İç politika, kimliği doğrulanmış bir kullanıcının hangi hizmete ulaşabileceğini yanıtlar ve yönlendirme kurallarında, güvenlik gruplarında ya da uygulamanın kendisinde yaşar. Tek bir cihaz ikisini de barındırabilir ve çok cihazlı bir tasarımda da ikisi vardır. Onları ayrı adlandırmak, bir kullanıcı bir uygulamaya ulaşamadığında hangisinin başarısız olduğunu söylemenizi sağlayan şeydir.

Sertifikalar ve çok faktörlü kimlik doğrulama gibi kabul denetimleri kimliğe yanıt verir, başka hiçbir şeye değil. Yerleşimi belirlemezler ve kullanıcı içeri girdikten sonra kaynak başına izin vermezler.

Yerleşim, isteğin hangi sınırı geçtiğine karar verir

Üç yerleşim yaygındır ve her biri şifresi çözülen isteğin hangi sınırı geçtiğini değiştirir. Onları orada neyin sonlandığına, neyin açık metni görebildiğine, hangi denetimin isteği hâlâ reddedebildiğine ve cihazla birlikte neyin çöktüğüne göre karşılaştırın. Aşağıdaki tablo genel bir soru yerine bu dört sütunu kullanır, çünkü her yanıt ayrı bir tasarım kararıdır.

Üçüncü yerleşim, uygulamayı sessizce ortadan kaldırandır, çünkü korunan segmentteki bir bacak cihaza diyagramın göstermeyebileceği doğrudan bir yol verir. Resmi değil, arayüzleri ve rotaları inceleyin: ip route get 10.20.5.10 paketin hangi arayüzden çıkacağını bildirir ve yanıt çoğu zaman tasarımın varsaydığı değildir. Güvenlik duvarının duruşlar arasındaki trafiği denetleme gibi klasik rolü, aşağıdaki belgede anlatıldığı üzere,NIST SP 800-41 burada yararlı bir sınamadır, çünkü korunan ağa sınırsız bir bacağı olan cihaz fazla bir şey denetlemez. Bir rota sorgusu, sunumdaki diyagramdan daha dürüst bir diyagramdır.

Yönetim, kendi açıkça izin verilen yoluna aittir. Kullanıcıların bir uygulamaya ulaşmasına izin vermek, onların cihazın denetim arayüzüne ulaşmasına izin vermeyi hiçbir zaman gerektirmez ve iki izin farklı kurallardan verilmelidir. İki yolu ayrı ayrı denetleyin, çünkü paylaşılan bir kural hangisinin açıldığını saklar.

Çeviri, alt kuralların neyi görebileceğini değiştirir

Kaynak çevirisi kullanışlıdır ve bilgiyi yok eder. Masquerade sonrasında her istemci cihaz gibi görünür, bu yüzden kullanıcıları ayırt etmek için yazılmış bir alt kural artık bunu yapamaz. Bu yalnızca bir günlük sorunu değil, bir politika sorunudur: istemci adresine göre anahtarlanmış bir kural sessizce ağ geçidine göre anahtarlanmış bir kural olur. Kullanıcı başına politika önemliyse kaynağı koruyun ya da politikayı çeviriden önce uygulayın.

Yanıt yolu da aynı incelemeyi hak eder. Hedefin dönüş paketi için hangi rotayı seçtiğini kaydedin, çünkü asimetrik bir dönüş durum bilgili denetimi atlar ve kurulan sonra tıkanan bir bağlantı üretir. Her iki yön de çizdiğiniz sınırı geçmelidir, yoksa sınır süslemedir.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

İzin verilen ve reddedilen bir işlemi kabul edin

Yönetim ana bilgisayarından değil, gerçek uzak istemciden sınayın, çünkü yönetim ana bilgisayarı genellikle kullanıcının asla bulunmayacağı bir yerde oturur. İzin verilen bir işlem yolun çalıştığını, reddedilen bir işlem ise politikanın hiç değilse bir şey yaptığını kanıtlar. Her yerleşim değişikliğinden sonra ikisini de çalıştırın ve kullandığınız kaynak kimliğini ve hedefi kaydedin. Yalnızca başarıyı kanıtlayan bir sınama, doğru bir kuralı eksik olandan ayıramaz.

Ardından durumu değiştiren durumları sınayın: yeniden bağlanma, anahtar rotasyonunu aşan bir oturum ve cihazın kendi arızası. Güncellemeleri, kapasiteyi ve kurtarmayı aynı düzenin parçası olarak karşılaştırın, çünkü birkaç mantıksal denetimi taşıyan tek bir cihaz, birkaç etiketli tek bir arıza alanıdır. Ortak bir yönetim kimliği veya sınırsız bir rota, oluşturması gereken sınırı alt ederse ikinci kutu da bağımsız değildir.

Uç noktayı, şifresi çözülen yolu ve onu kısıtlayan denetimi belgeleyin. Bu üç satır, uygulama ne adla anılırsa anılsın anlamlı kalır.