VPN üçün bulud təhlükəsizlik qrupu: dinləyicini açın, hamısını yox
Təhlükəsizlik qrupu müştəri ilə daemon arasındakı dörd filitrdən biridir. Əvvəlcə protokolu adlandırın, sonra ACL-i, host firewall-u və yönləndirməni yoxlayın.
VPN serveri işləyir, müştərinin vaxtı bitir və ilk instinkt təhlükəsizlik qrupuna hər şeyə icazə verən qayda əlavə etməkdir. Bu bəzən işlədə bilir və bu, ən pis nəticədir, çünki indi heç kim hansı sərhədin həqiqətən bağlandığını bilmir. Müştəri ilə daemon arasında dörd ayrı filitr var və onlardan yalnız biri təhlükəsizlik qrupudur.
Qaydadan əvvəl protokolu adlandırın
Qayda protokol, port aralığı və mənbədir. WireGuard UDP üzərində dinləyir, adətən 51820. OpenVPN adətən UDP və ya TCP 1194-dür, necə quraşdırıldığından asılı olaraq. IPsec IKE mübadiləsini UDP 500 və 4500 üzərində, üstəlik ESP protokolunun özünü tələb edir; bu port deyil, protokol nömrəsidir. Digər qaydalar TCP olduğu üçün TCP fərz etmək, düzgün görünən və heç nəyə uyğun gəlməyən qaydaya gətirib çıxarır.
Dinləyicini dərslikdən deyil, işləyən xidmətdən oxuyun. Bir ünvana bağlanmış daemon başqa ünvana gələn trafiki qəbul etməyəcək.
Mənbəni bütün internet yerinə dizaynın icazə verdiyi müştəri aralığı ilə məhdudlaşdırın.
Təhlükəsizlik qrupları vəziyyət saxlayır; subnet ACL-ləri saxlamır
Təhlükəsizlik qrupları vəziyyət saxlayır və yalnız icazə verir: icazəli gələn axın cavablarını avtomatik alır və düşünməli rədd qaydası yoxdur. Subnet ACL-ləri vəziyyətsizdir və hər iki istiqamətdə qiymətləndirilir, ona görə uyğun gedən efemer aralığı olmayan gələn icazə yenə də uğursuz olur. Bu fərq konsolda düzgün görünən bir çox qaydanı izah edir.
İşləyən son nöqtəyə hansı siyasətin bağlandığını da təsdiqləyin, çünki instansiyada birdən çox qrup ola bilər və bağlanmamış qrupdakı qayda heç nəyi dəyişmir.
Effektiv siyasət bağlı olanların birliyidir, redaktə etdiyiniz fayl deyil.
Host firewall ayrı bir sərhəddir
Bulud siyasəti trafiki şəbəkə interfeysinə buraxır, sonra əməliyyat sistemi daemonun onu görüb-görməyəcəyinə qərar verir. Defolt rədd siyasəti olan host firewall təhlükəsizlik qrupunun icazə verdiyi paketi atacaq və bulud konsolu heç bir rədd göstərməyəcək, çünki onun heç vaxt fikri olmayıb. Hər ikisini paketin onlarla rastlaşdığı sıra ilə yoxlayın.
Host distribusiya firewall ön hissəsindən istifadə edirsə, profil adını deyil, əsas qaydaları təsdiqləyin, çünki profil aktiv ola bilər, port isə bağlı.
İnterfeysdə tutma paketi hansı sərhədin atdığını göstərir.
Dinləyiciyə icazə vermək müştəriləri yönləndirmək deyil
Müştəri trafikini ötürən VPN şlüzü açıq portdan çoxunu tələb edir. IP yönləndirmə, tunel interfeysindən təyinat şəbəkəsinə axına icazə verən siyasət və çox vaxt interfeysdə mənbə-təyinat yoxlamasının söndürülməsi lazımdır ki, platforma ona ünvanlanmayan trafiki atmaz. Bunların heç birini dinləyici qaydası yaratmır.
İşləyən əl sıxışma ilə pozulmuş məlumat yolu burada ayrılır və buna görə tunel statusu sağlam görünə bilər, halbuki heç nə yüklənmir.
Yönləndirməni öz yoxlaması olan ayrı dəyişiklik kimi düzəldin və qeyd edin ki, ötürən şlüz təyinatı icazə verən çıxış siyasətinə də ehtiyac duyur.
Geri dönüş yolu saxlayın, sonra qaydanı daraldın
Uzaq firewall siyasətini dəyişməzdən əvvəl müstəqil idarəetmə yolunun olduğunu təsdiqləyin: sessiya meneceri, serial konsol və ya bantdankənar şəbəkə kimi. Əgər yeganə idarəetmə yolu redaktə etdiyiniz qaydadan keçirsə, bərpa yolunuz yoxdur. Sonra dar qaydanı tətbiq edin, real müştəridən sınaqdan keçirin və cəhdi server tərəfindəki sübutlarla əlaqələndirin. Eyni maşındakı başqa xidmətin cavabı dinləyiciyə çatıldığının sübutu deyil.
Dar icazə işlədikcə istənilən eksperimental geniş icazəni silin və qaydanın niyə mövcud olduğunu qeyd edin. AWS təhlükəsizlik qruplarının vəziyyət saxlayan davranışını sənədləşdirir və kimsə qısa yol kimi geniş aralıq təklif edəndə istinad ediləcək sənəd budur.
Bağlantını da sənədləşdirin, əks halda əvəz edən interfeys siyasəti səssizcə itirəcək.