Niyə tcpdump IPsec açıq mətnini yalnız bir istiqamətdə göstərir
Bu asimmetriya tutma nöqtəsinin artefaktıdır, pozulmuş cavab yolu deyil. Linux IPsec gateway-də daxili və xarici trafiki harada axtarmaq lazım olduğu buradadır.
Linux IPsec gateway-in xarici interfeysində tcpdump işə salırsınız və eyni anda iki şey görürsünüz: daxil olan ESP kadrları və dərhal onlardan sonra deşifrə edilmiş daxili paketlər. Xaricə gedən istiqamətdə isə yalnız ESP görünür. Təbii nəticə cavabların göndərilmədiyi və ya IPsec-in bir istiqaməti şifrələyib digərini unutduğu olur. Heç biri doğru deyil.
Gördüyünüz şey tutma nöqtəsidir. Yadro xaricə gedən paketləri cihazın ötürmə yolu onları paket soketinə verməzdən əvvəl çevirir, ona görə soket çıxan daxili formanı heç vaxt görmür. Daxil olan paket əvvəlcə ESP kimi tutulur və deşifrə edilmiş surət yığına yenidən daxil olduqda görünür. Eyni trafik, iki fərqli müşahidə pəncərəsi.
Tutma nöqtəsi nə gördüyünüzü müəyyən edir
Adi interfeysdə AF_PACKET soketi cihaz qatına yaxın yerləşir. Hostdan çıxan paketlər əvvəlcə IPsec çıxış emalından keçir, bu emal daxili TCP seqmentini ESP və ya UDP-4500 datagramına çevirir və yalnız bundan sonra həmin qata çatır. Gələn paketlər naqildən çıxdıqları kimi, hələ şifrəli halda soketə köçürülür, deşifrə olunmuş nəticə isə yığın onu yerli çatdırdıqda və ya yönləndirdikdə sonra görünür.
Bu sıra asimmetriyanı tamamilə izah edir. Bu, istiqamət, siyasət və ya tətbiq davranışı haqqında sübut deyil və belə qəbul edildikdə insanları düzgün göndərilmiş cavabın arxasınca qaçmağa vadar edir. Bu, şəbəkə tarixində anomaliyanı şəbəkənin deyil, alətin yaratdığı azsaylı tapmacalardan biridir.
Filtri nəzərdə tutduğunuz qata uyğunlaşdırın
tcp port 443 kimi bir ifadə daxili TCP bağlantısını seçir. Xaricə gedən istiqamətdə həmin bağlantı soketə müraciət edilən ana qədər artıq ESP-yə çevrilib, ona görə filtr heç nəyə uyğun gəlmir. Qorunan trafiki saymaq istəyirsinizsə, əvəzində xarici formaya görə filtr edin: xam ESP üçün protokol 50, yaxud NAT keçidi işə düşdükdə UDP portu 4500. Hər iki filtr iki peer arasında müqayisə oluna bilən paket sayı verir ki, bu da adətən saymağın səbəbidir. Heç biri daxili sorğunun cavablandırılıb-cavablandırılmadığını demir.
UDP 4500 sayını ESP paket sayı kimi qəbul etməyin. IKE həmin portu NAT-T davamlılıq siqnalları və inkapsullaşdırılmış mübadilə üçün də istifadə edir, ona görə rəqəm ölçmək istədiyiniz məlumat olmayan trafiki də əhatə edir. UDP 500 üzərindəki ilkin IKE mübadiləsi, əgər sual budursa, öz filtrini tələb edir. İdarəetmə trafikini məlumatla qarışdıran rəqəm həm də istənilən bant genişliyi təxminini bilinməyən bir marja ilə səhv edir. Ayrı saylar ayrı suallara cavab verir.
Filtri cavablandırdığı sualın yanında yazın. “Qutudan nə qədər ESP çıxdı” və “veb sorğusu qutudan çıxdımı” fərqli filtrlərlə fərqli ölçmələrdir və bir tutma hər ikisini həll edə bilməz. Bu qeyd olmadan iki nəfər heç vaxt eyni şeyi saymamış rəqəmləri müqayisə edəcək.
Çevrilmədən əvvəl baxın, sonra deyil
Xaricə gedən açıq mətni görməlisinizsə, müşahidə nöqtəsini daha erkənə, IPsec çıxış emalından əvvələ köçürün. NFLOG sizə Netfilter qarmağı verir ki, orada qayda seçilmiş paketləri tcpdump-ın oxuya biləcəyi istifadəçi məkanı soketinə köçürə bilər. strongSwan-ın trafik dump bələdçisi bu yanaşmanı məhz bu səbəbdən sənədləşdirir.
Siyasət uyğunluğu qaydayı yalnız tunelə girmək üzrə olan trafiklə məhdudlaşdırır. -m policy --pol ipsec --dir out qaydayı qutunun göndərdiyi hər paketi loglamaq əvəzinə konkret edən şeydir. Sonra log qrupunu məhdud tutma ilə oxuyun: kiçik snapshot sayı və ölçü limiti diaqnostikanın trafik arxivinə çevrilməsinin qarşısını alır. Məhdud tutma həm də əlaqəsiz yükü özü ilə sürümədən rəyçiyə vermək üçün daha rahatdır. Sayı başlamazdan əvvəl qərarlaşdırın, nə qədər gəldiyini gördükdən sonra deyil.
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'Qarmağı axına uyğun seçin. OUTPUT gateway-in özünün yaratdığı trafiki əhatə edir; LAN müştərisindən keçid əvəzində FORWARD zəncirindən keçir və OUTPUT üzərindəki qayda onu heç vaxt görməyəcək. Yuxarıdakı ünvan və port təsdiqlənmiş test təyinatı üçün yer tutucudur.
Müşahidə nəyi sübut edir
NFLOG loglama hədəfidir, qəbul qərarı deyil. Orada görünən paket onun qarmağa çatdığını və qaydaya uyğun gəldiyini göstərir. Sonrakı filtrin ona icazə verdiyini, cihazın onu ötürdüyünü və ya peer-in nə isə aldığını göstərmir.
Boş log da eyni dərəcədə iki mənalıdır. Qaydanın paket sayğacını yoxlayın, istiqaməti təsdiqləyin, axının həqiqətən IPsec siyasətinə uyğun gəldiyini təsdiqləyin və təyinatı təsdiqləyin. Yalnız hər iki peer-də uyğun gələn sayğac müşahidəni nəticəyə çevirir. Sonra eyni nəzarətli cəhd üçün hər iki peer-də təhlükəsizlik assosiasiyası sayğaclarını müqayisə edin, çünki SA sayğacları nəyin qorunduğunu və göndərildiyini göstərən səlahiyyətli qeyddir.
Daha bir tələ: bu kontekstdə “açıq mətn” IPsec şifrələmə qatından kənar deməkdir. Daxili HTTPS sessiyasının hələ də öz TLS-i var. Deşifrə edilmiş paketin tutulması tətbiqin TLS-ini deşifrə etmir və orada oxunaqlı HTTP görmək tətbiqin əvvəldən HTTPS istifadə etmədiyini bildirir.
Təmizləyin və iki tərəfi müqayisə edin
Müşahidə bitən kimi daxil etdiyiniz qaydayı eynilə, sahibinə görə silin. Loglama qaydasını yerində qoymaq hər uyğun paketdə CPU xərcləyir və səssizcə məlumatların saxlanması problemi yaradır. Zənciri boşaltmaq əvəzinə qaydanı -D ilə təkrarlayaraq silin, çünki o zəncir sizə aid deyil.
iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5Yerləşdirmə istifadəçi məkanı IPsec, XFRM interfeysi və ya apparat offload istifadə edirsə, müşahidə nöqtələri dəyişir və bu resept heç işləməyə bilər. libipsec ilə daxili trafiki izləmək üçün sənədləşdirilmiş yer TUN cihazıdır. Əvvəlcə yolu müəyyən edin, sonra suala cavab verən nöqtəni seçin və iki istiqamətin yalnız çevrilmənin yanlış tərəfinə baxdığınız zaman fərqli görünməsini gözləyin.