Zədələnmiş hostda təcili kəsicinin nələri əhatə etdiyini necə yoxlamaq

Təcili kəsici işə salın, tunel serverini oflayn vəziyyətə gətirin və maşının hələ nə etdiyini izləyin. Bu test çalışmağa dəyər, çünki firewall-un nə tətbiq etdiyini sizin güman etdiyinizdən ayırır və nəticələr əksər məhsul səhifələrinin təklif etdiyindən daha dardır. Təcili kəsici şəbəkə yollarını idarə edir; cihazda artıq işləyən proqramı idarə etmir. Mən bu ardıcıllığı müştərinin fail-closed olduğunu iddia etdiyi hər maşında keçirirəm və bu, təxminən on dəqiqə çəkir.

Serverdən deyil, müştəridən başlayın

Tətbiq nöqtəsi oturduğunuz hostdur: əməliyyat sisteminin firewall-u, köməkçi xidmət və ya VPN müştərisinin öz sürücüsü. Bu önəmlidir, çünki kəsicinin edə biləcəyi hər şey o təbəqənin görə bildikləri ilə məhdudlaşır. Əgər müştəri bloku marşrut qaydası və işarə ilə tətbiq edirsə, kifayət qədər imtiyazı olan hər şey öz qaydasını əlavə edə bilər; əgər o, nüvə firewall cədvəlindən istifadə edirsə, eyni imtiyaz cədvəli redaktə edə bilər. Şifrin gücü heç vaxt bu suala daxil olmur.

Deməli, ilk müəyyən etməli olan şey bu cihazdakı siyasətin kimə aid olduğu və onun nəyi üstələməyə icazəsinin olduğudur. İdarə olunan iş maşınında cavab adətən təşkilatın son nöqtə agentidir və fərdi VPN tunelin necə konfiqurasiya edildiyindən asılı olmayaraq həmin imkanları aradan qaldırmır.

Birinci addım: əhatə etdiyini düşündüyünüz yollarda bloku təsdiqləyin

Tuneli müştəridə deyil, uzaq tərəfdə söndürün, beləliklə müştəri hələ də qoşulmalı olduğuna inansın. Sonra insanın həqiqətən sınayacağı şeyi sınayın:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Tez və təmiz şəkildə uğursuz olan müştəri istəyirsiniz, brauzerin vaxt aşımına qədər asılı qalan müştəri yox. Asılma adətən paketlərin rədd olunmayan qayda ilə səssizcə atıldığını bildirir və bu məqbuldur, lakin həm də müştərinin ölü interfeysə yönəlmiş köhnə standart marşrut buraxdığını göstərə bilər. Tunel söndürülmüş halda marşrut cədvəlini oxuyun: hələ də tunel cihazına baxan standart marşrutla yalnız yeni çıxan bağlantıları bloklayan firewall qaydası iki fərqli vəziyyətdir və onlardan yalnız biri fail-closed-dur.

Müştərinin allow-LAN seçimi açıq və bağlı halda eyni əmrləri təkrarlayın. Bu açar ən çox sürprizin olduğu yerdir, çünki siyasətin qalan hissəsinin bağlamaq üçün yazıldığı yolu yenidən açır.

İkinci addım: DNS və IPv6-nı ayrı yollar kimi yoxlayın

Ad həlli əksər tətbiqlərdən sağ çıxan boşluqdur, çünki sorğu sistem həlledicisindən başqa bir şeylə çıxa bilər. Həlledici konfiqurasiyanızı nəzərə almayan alətlə soruşun və eyni zamanda v6 tərəfini yoxlayın:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Tunel söndürülmüş halda hər iki ad sorğusuna boş cavablar istədiyiniz nəticədir. Əgər ikinci sorğu cavab verirsə, koda yazılmış həlledici ünvanı əlçatandır və tunel maşından çıxan yeganə yol deyil. Əgər yalnız v6 sorğusu uğurlu olursa, siyasət IPv4-ü əhatə edir və IPv6-nı nəzərə almır, bu da fərqli ünvan ailəsində eyni sızıntıdır.

Brauzerlər bunu kənardan oxumağı çətinləşdirir, çünki DNS over HTTPS üçün qurulmuş brauzer sorğunu HTTPS sorğusu ilə həll edir: sorğu yalnız həmin son nöqtəyə 443 portu qədər bloklanır. Siyasətin yerli alt şəbəkəyə icazə verdiyi hostda həmin sorğu yenə də LAN-dakı həllediciyə çata bilər.

Üçüncü addım: şəbəkə məruz qalmasını son nöqtə məruz qalmasından ayırın

İndi heç bir firewall qaydasının çatmadığı hissə. Təcili kəsici maşından çıxan yolları bloklayır; maşındakı proqramın şifrələnməzdən əvvəl məlumat oxumasını dayandırmır və həmin proqramın tuneldən qanuni şəkildə istifadə etməsini də dayandırmır. Klaviatura qeyd edən, zərərli genişləndirmə, kilidlənmədən qoyulmuş ekran, geniş icazələri olan sinxronlaşdırma müştərisi: bunların hamısı məlumatı kəsicinin məmnuniyyətlə icazə verdiyi bağlantı üzərindən köçürür.

Eyni şey işəgötürənin qəsdən quraşdırdığı monitorinq proqramı üçün də keçərlidir. Marşrutların bloklanması onu aradan qaldırmır və yeni VPN serveri almaq da düzəliş deyil, çünki məruz qalma tuneldən yuxarıda yerləşir.

Bulud hesabına yükləyən clipboard meneceri məsələni kəskin göstərir. Trafik şifrələnir, təyinat icazəlidir və təcili kəsici bütün müddət sağlam vəziyyət bildirir.

Dördüncü addım: testinizin dəstəklədiyi iddianı yazın

Kəsinti testindən sonra konkret faktlar deyə bilərsiniz: hansı tətbiqlər uğursuz oldu, hansı yollar dayandı, DNS və IPv6-nı necə davrandı və tunel düşəndə blok saxladımı. Əməliyyat sisteminin təmiz olduğunu deyə bilməzsiniz və uzaq tərəfdəki bir xidmətin girişinizi gizli saxlayacağını da deyə bilməzsiniz.

İki problemi ayrı saxlayın və hər birinə öz nəzarətini verin:

• Təcili kəsici: müəyyən edilmiş uğursuzluq tələbi, hər müştəri yeniləməsindən sonra təkrarladığınız kəsinti testi ilə təsdiqlənir.
• Cihaz etibarı: dəstəklənən yeniləmələr, etibarlı mənbədən son nöqtə müdafiəsi, izah olunmayan icazələrin və autentifikasiya sorğularının nəzərdən keçirilməsi.
• Hadisə: kompromis şübhəsi olduqda platformanın və ya təşkilatın prosesini izləyin; yeni server təmizləmə addımı deyil.
• Açıqlama: kömək istəyərkən şəxsi açarları və ya tam diaqnostik arxivləri yapışdırmayın, çünki qeydlər və ekran görüntüləri bağlantı ilə eyni sirləri daşıyır.

Növbəti yeniləmədən sonra ardıcıllığı yenidən keçirin, çünki təcili kəsici versiyalarla birlikdə hərəkət edən konfiqurasiyadır. Test, güvəndiyiniz davranışın hələ də əldə etdiyiniz davranış olduğuna dair yeganə sübutunuzdur.