tcpdump neden IPsec açık metnini yalnızca tek yönde gösterir

Bir Linux IPsec ağ geçidinin dış arayüzünde tcpdump çalıştırıyorsunuz ve aynı anda iki şey görüyorsunuz: gelen ESP çerçeveleri ve hemen ardından şifresi çözülmüş iç paketler. Giden yönde yalnızca ESP görünür. Doğal sonuç, yanıtların gönderilmediği veya IPsec'in bir yönü şifreleyip diğerini unuttuğudur. İkisi de doğru değil.

Baktığınız şey bir yakalama noktasıdır. Çekirdek, giden paketleri cihazın iletim yolu bunları paket soketine vermeden önce dönüştürür, bu yüzden soket dışarı çıkan iç biçimi hiç görmez. Gelen yönde paket önce ESP olarak yakalanır ve kapsülden çıkarılmış kopya yeniden yığına girdiğinde görünür hale gelir. Aynı trafik, iki farklı gözlem penceresi.

Ne gördüğünüzü yakalama noktası belirler

Normal bir arayüzde AF_PACKET soketi cihaz katmanına yakın oturur. Ana bilgisayardan çıkan paketler önce IPsec çıkış işlemesinden geçer; bu işlem iç TCP segmentini ESP veya UDP-4500 veri birimine dönüştürür ve ancak ondan sonra o katmana ulaşırlar. Gelen paketler kablodan çıktıkları anda, hâlâ şifreli olarak sokete kopyalanır ve şifresi çözülmüş sonuç, yığın bunu yerel olarak teslim ettiğinde veya ilettiğinde daha sonra görünür.

Bu sıralama asimetriyi tamamen açıklar. Yön, ilke veya uygulama davranışı hakkında bir kanıt değildir ve böyle ele almak, insanları baştan beri doğru gönderilmiş bir yanıtın peşine düşürür. Bu, anormalliği ağın değil aracın yarattığı az sayıdaki ağ bilmecesinden biridir.

Filtreyi amaçladığınız katmanla eşleştirin

tcp port 443 gibi bir ifade iç TCP bağlantısını seçer. Giden yönde bu bağlantı, sokete sorulduğunda çoktan ESP olmuştur, bu yüzden filtre hiçbir şeyle eşleşmez. Korumalı trafiği saymak istiyorsanız bunun yerine dış biçime göre filtreleyin: ham ESP için protokol 50 veya NAT geçişi kullanılıyorsa UDP 4500 numaralı bağlantı noktası. Her iki filtre de iki taraf arasında karşılaştırılabilir bir paket sayısı verir, saymanın nedeni genellikle budur. Hiçbiri iç isteğin yanıtlanıp yanıtlanmadığını söylemez.

UDP 4500 sayısını ESP paket sayısı olarak görmeyin. IKE bu bağlantı noktasını NAT-T canlı tutma iletileri ve kapsüllenmiş değiş tokuş için de kullanır, bu yüzden sayı ölçmek istediğiniz veriler olmayan trafiği de içerir. UDP 500'deki ilk IKE değiş tokuşu, soru buysa kendi filtresini gerektirir. Kontrol trafiğini verilerle karıştıran bir sayı, her bant genişliği tahminini de bilinmeyen bir oranda yanlış yapar. Ayrı sayımlar ayrı soruları yanıtlar.

Filtreyi yanıtladığı sorunun yanına yazın. „Kutudan ne kadar ESP çıktı“ ve „web isteği kutudan çıktı mı“ farklı filtrelerle yapılan farklı ölçümlerdir ve tek bir yakalama ikisini de çözemez. O not olmadan iki kişi hiç aynı şeyi saymamış sayıları karşılaştırır.

Dönüşümden önce gözlemleyin, sonra değil

Giden açık metni görmeniz gerekiyorsa gözlem noktasını daha öne, IPsec çıkış işlemesinden önceye taşıyın. NFLOG size, bir kuralın seçilen paketleri kullanıcı alanındaki bir sokete kopyalayabildiği ve tcpdump'ın okuyabildiği bir Netfilter kancası verir. strongSwan'ın trafik dökümü kılavuzu bu yaklaşımı tam da bu nedenle belgeler.

İlke eşleşmesi kuralı tünele girmek üzere olan trafikle sınırlar. -m policy --pol ipsec --dir out kuralı, kutunun gönderdiği her paketi günlüğe kaydetmek yerine belirli kılan şeydir. Ardından günlük grubunu sınırlı bir yakalamayla okuyun: az sayıda anlık görüntü ve boyut sınırı, tanılamanın bir trafik arşivine dönüşmesini önler. Sınırlı yakalama, ilgisiz yükü peşinde sürüklemeden bir gözden geçirene vermek için de daha kolaydır. Sayıya başlamadan önce karar verin, ne kadar geldiğini gördükten sonra değil.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Akışa uygun kancayı seçin. OUTPUT ağ geçidinin kendisinin ürettiği trafiği kapsar; bir LAN istemcisinden geçiş bunun yerine FORWARD zincirinden geçer ve OUTPUT üzerindeki bir kural bunu asla görmez. Yukarıdaki adres ve bağlantı noktası onaylanmış bir test hedefi için yer tutucudur.

Gözlem neyi kanıtlar

NFLOG bir günlükleme hedefidir, kabul kararı değildir. Orada görünen bir paket kancaya ulaştığını ve kurala uyduğunu gösterir. Daha sonraki bir filtrenin izin verdiğini, cihazın gönderdiğini veya karşı tarafın bir şey aldığını göstermez.

Boş bir günlük de aynı derecede belirsizdir. Kuralın paket sayacını kontrol edin, yönü doğrulayın, akışın gerçekten bir IPsec ilkesine uyduğunu doğrulayın ve hedefi doğrulayın. Yalnızca her iki tarafta eşleşen bir sayaç bir gözlemi sonuca dönüştürür. Ardından aynı kontrollü deneme için her iki taraftaki güvenlik ilişkisi sayaçlarını karşılaştırın, çünkü SA sayaçları neyin korunup gönderildiğinin yetkili kaydıdır.

Bir tuzak daha: bu bağlamda „açık metin“ IPsec şifreleme katmanının dışı anlamına gelir. İç HTTPS oturumunun yine de kendi TLS'i vardır. Kapsülden çıkarılmış paketi yakalamak uygulamanın TLS'ini çözmez ve orada okunabilir HTTP görmek, uygulamanın hiç HTTPS kullanmadığı anlamına gelir.

Temizleyin ve iki ucu karşılaştırın

Gözlem biter bitmez eklediğiniz tam kuralı sahibine göre kaldırın. Bir günlükleme kuralını yerinde bırakmak eşleşen her pakette CPU harcar ve sessizce bir veri saklama sorunu yaratır. Sizin olmayan bir zinciri boşaltmak yerine kuralı -D ile yineleyerek silin.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Dağıtım kullanıcı alanı IPsec, XFRM arayüzü veya donanım yük boşaltması kullanıyorsa gözlem noktaları kayar ve bu tarif hiç geçerli olmayabilir. libipsec ile iç trafiği gözlemlemenin belgelenmiş yeri TUN aygıtıdır. Önce yolu belirleyin, sonra soruyu yanıtlayan noktayı seçin ve iki yönün yalnızca dönüşümün yanlış tarafına baktığınızda farklı görünmesini bekleyin.