TunnelCrack və TunnelVision: hər biri əslində nəyi pozur

İki tədqiqat adı tuneldən çıxan istənilən VPN trafiki üçün bir-birinin yerinə işlədilir, halbuki onların arxasındakı mexanizmlər eyni deyil. TunnelCrack marşrutlaşdırma istisnasının iki ailəsini təsvir edir; TunnelVision isə son nöqtədə DHCP ilə verilən marşrutu təsvir edir. Heç biri şifrələməni pozmur və heç biri konkret müştəri buraxılışının bugün nə etdiyini sizə demir. Beş yoxlama mexanizmləri başlıqdan ayırır.

Birinci addım: nəzərdən keçirdiyiniz mexanizmin adını qoyun

2023-cü ilin avqustunda açıqlanan TunnelCrack iki hücum ailəsini təsvir edir. Yerli şəbəkə halında müştərinin yerli şəbəkəyə aid saydığı trafik yerli giriş istisnasından istifadə edir və tuneldən çıxır. Server ünvanı halında müştərinin VPN serverinin özünə çatmaq üçün ehtiyac duyduğu marşrut tuneldən kənardadır və həmin ünvanı idarə edən rəqib bu istisnadan sui-istifadə edə bilər.

TunnelVision DHCP ilə verilən sinifsiz statik marşrutlar haqqında ayrı bir hesabatdır. Zərərli DHCP serveri son nöqtəyə trafikin hansı yolla getdiyini dəyişən marşrutlar verə bilər, o cümlədən VPN serverinə doğru yolu. Hesabat əlaqəli marşrutlaşdırma effektləri üzrə əvvəlki işi qeyd edir ki, bu da əsas mexanizmin addan daha qədim olduğunu xatırladır.

Adları öz mexanizmlərinə bağlı saxlayın. Digəri xəbərlərdə olduğu üçün birinə düzəliş tətbiq etmək — yoxlamanın əhatəsiz hərəkət yaratmasının yoludur.

İkinci addım: yerli giriş istisnasına baxın

Əksər müştərilər tunel açıq ikən printerlərin, yayımın və fayl paylaşımının işləməsi üçün yerli şəbəkə trafikini istisna edir. Bu istisna təhlükəsizlik dəyəri olan siyasət qərarıdır: eyni şəbəkədəki rəqib özünü yerli host kimi təqdim edə bilər və ona çatan trafik heç vaxt tunelə daxil olmamışdır.

Yerləşdirilmiş profilə bu istisna ümumiyyətlə lazımdırmı, soruşun. Yerli kəşfdən heç vaxt istifadə etməyən uzaq işçi qüvvəsi onu çox vaxt söndürə bilər və qalan yerli xidmətlərə sənədləşdirilmiş yol ilə çatmaq olar. İstisna tələb olunduğu yerdə onu yerli trafik adlandırmaq əvəzinə hansı təyinatları əhatə etdiyini deyin.

Yoxlama konfiqurasiya sualıdır, paket tutma deyil. Profil parametrini və yerləşdirdiyiniz buraxılışın müştəri sənədlərini oxuyun, çünki standart məhsullar arasında və eyni məhsulun versiyaları arasında fərqlənir. Cavabı profilin yanına yazın ki, növbəti baxıcı onu davranışdan çıxarmasın. Heç kimin sənədləşdirmədiyi istisna, heç kimin nəzərdən keçirmədiyi istisnadır.

Üçüncü addım: server ünvanının necə öyrənildiyinə baxın

Müştəri hər hansı tunel yaranmazdan əvvəl VPN serverinə çatmalıdır, ona görə də bu təyinat dizayn üzrə tuneldən kənara yönəldilir. Ünvan bir addan öyrənilirsə, həll mərhələsi etimad yolunun bir hissəsidir və həmin sorğuya cavab verə bilən rəqib müştərini idarə etdiyi hosta yönəldə bilər.

Ünvanı bərkitmək, düzgün adla təsdiqlənmiş sertifikatdan istifadə etmək və təsdiqlənməmiş serverə geri dönməyi rədd etmək — hamısı məruz qalmanı azaldır. Heç biri serverə tuneldən kənarda çatmaq ehtiyacını aradan qaldırmır; onlar həmin ünvana kimin cavab verə biləcəyini dəyişir.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

Marşrut axtarışı müştərinin server ünvanı üçün istifadə edəcəyi interfeysi göstərir və bu, istisnanın konkret formasıdır. Əgər bu axtarış tunel interfeysini qaytarırsa, müştəri tuneli ümumiyyətlə qura bilməz, ona görə də kənar marşrut gözlənilir və sual yalnız onun təyinatının necə seçildiyidir.

Dördüncü addım: DHCP ilə verilən marşrutlara baxın

Sinifsiz statik marşrutlar DHCP serverinə marşrut cədvəli qeydlərini paylamağa imkan verir və son nöqtə onları adətən soruşmadan qəbul edir. Rəqibin qanuni serverdən daha sürətli DHCP cavabı verə bildiyi şəbəkədə bu qeydlər istifadəçinin tunelin içində olduğunu düşündüyü trafiki yönləndirə bilər.

Son nöqtədəki marşrutları gözlədiyiniz marşrutlarla müqayisə edin. Tunel açıq ikən yerli şlüza işarə edən standart marşrut və ya geniş prefiks — araşdırmağa dəyən əlamətdir və heç bir hücum trafiki olmadan görünür.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Son parametr bir çox müştərinin və platformanın müəyyən formada təqdim etdiyi son nöqtə tərəfli nəzarətdir: şəbəkə tərəfindən verilən marşrutları nəzərə almamaq. Avtomatik marşrut qəbulunu söndürmək güzəştdir, çünki korporativ DHCP serverindən gələn qanuni bölünmüş marşrutlaşdırmanı da söndürür, ona görə bunu qlobal deyil, şəbəkə sinfi üzrə qərarlaşdırın.

Beşinci addım: bildirişi cari buraxılışdan ayırın

Dərc edilmiş hücum müəyyən vaxtda müəyyən müştəri versiyalarında müşahidə edilən davranışı təsvir edir. O, qarşınızdakı noutbukun təsirləndiyini sübut etmir və düzəldildiyini də sübut etmir. Hər iki iddia faktiki buraxılış nömrəsini və satıcının cari bildirişini tələb edir.

Müştəri versiyasını, platformanı, yuxarıdakı istisnaları idarə edən profil parametrlərini və yoxladığınız tarixi qeyd edin. Bu qeyd dürüst şəkildə köhnəlir, VPN-in TunnelCrack üçün yamaqlandığını deyən qeyd isə yox. Müştəri yeniləndikcə onu yenidən oxuyun, çünki profil standartı toxunmadığınız versiya altında dəyişə bilər.

Doğrulama apararkən təsdiqlənmiş planı öz son nöqtənizə və zərərsiz təyinatına qarşı istifadə edin. Paylaşılan şəbəkədə digər istifadəçilərə qarşı hücumu təkrar etmək test deyil və müşahidəni asanlaşdırmaq üçün peer yoxlamasını və ya tətbiq şifrələməsini söndürmək ölçməyə çalışdığınız qorumanı aradan qaldırır.

Sonda tətbiq səviyyəli qorumanı nəzərdə saxlayın. Marşrutlaşdırma istisnası tunelin daşıyacağı trafiki açığa çıxara bilər və tətbiqdəki TLS həmin trafiki ucdan uca qoruyur. İki qat bir-birindən asılı olmayaraq sıradan çıxır, buna görə də qoşulmuş idarəetmə kanalı hər axının nəzərdə tutulan yolla getdiyinə dəlil deyil.