Şəxsi VPN adları işləmir? Şübhəli DNS yenidən bağlama qorumasıdır
Şəxsi ünvanlara aid cavabları rədd edən həlledici daxili adları pozur, tuneli yox. Cavabı oxuyun, istisnanın əhatəsini məhdudlaşdırın, qorumaları başqa yerdə saxlayın.
Ofis LAN-da daxili ad dərhal cavab verir. VPN qalxdığı anda işləməyi dayandırır, tətbiq vaxt aşımı bildirir, tunel özü isə heç bir şikayət etmədən trafiki ötürməyə davam edir. Dəyişən şey həlledicidir və o həlledicinin şəxsi ünvanlar barədə öz fikri var.
Yenidən bağlama qoruması konkret bir hiyləni dayandırmaq üçün mövcuddur. Qəsdən dərc edilmiş şəxsi ad kifayət qədər oxşar görünür və müdafiə işə düşür.
Siyasəti oxumazdan əvvəl cavabı oxuyun
Adı VPN-in həqiqətən təqdim etdiyi həlledicidən soruşun, evdə noutbukunuzun istifadə etdiyi həlledicidən yox. Cavabı gözlədiyiniz qeydlə müqayisə edin və cavabın boş, rədd edilmiş yoxsa heç kimin planlamadığı ümumi ünvanlarla dolu olduğunu qeyd edin.
Simptomlar üst-üstə düşür, ona görə diaqnozu cavabın forması müəyyən edir. NXDOMAIN itkin qeyddir, REFUSED giriş qaydasıdır, daxili ad üçün ümumi ünvan siyasət və ya bölünmüş DNS xətasıdır, müştərinin istifadə edə bilmədiyi düzgün şəxsi ünvan isə tamamilə başqa problemdir. Rədd edilmiş bağlantı və ya dayanmış sorğu təkbaşına heç nə sübut etmir, buna görə bu biletlərin hər birində ilk əmr yenidən başlatma deyil, axtarış olmalıdır. Nəyisə dəyişməzdən əvvəl cavabı yazın.
Müdafiə əslində nəyi dayandırır
DNS yenidən bağlanması müştəri adı artıq etibarlı saydıqdan sonra onun hara həll olunduğunu dəyişməklə işləyir. Səhifə hücumçunun idarə etdiyi addan yüklənir, cavab şəxsi ünvana çevrilir və brauzer yerli şəbəkədə birbaşa bağlantı qəbul etməyəcəyi bir şeylə danışmağa aldanır. Müdafiə, həlledici heç vaxt şəxsi adlar məkanına xidmət etməyə çağırılmadıqda şəxsi məkana işarə edən cavabları rədd etməkdir. Bütün hücum da bu asimmetriyadır.
dnsmasq məhz bu davranışı, həmçinin domen üzrə istisnaları sənədləşdirir. Onun təlimat səhifəsi rebind-domain-ok seçimini belə ünvanları qanuni qaytara bilən domenləri adlandırmaq üsulu kimi təsvir edir. Bunu nəzərdə tutulan düzəlişin qlobal açar deyil, məhdud icazə olduğuna işarə kimi oxuyun.
İstisnanı adlar məkanı ilə məhdudlaşdırın
Əvvəlcə adlar məkanını, sonra istisnanı düzəldin. Uğursuz adın təşkilatın nəzarət etdiyi domenə aid olduğunu və qeydin qəsdən saxlanıldığını təsdiqləyin. Tanış LAN aralığına sadəcə bənzəyən gözlənilməz ünvan istisna yox, şübhə doğurur, ona görə hər hansı icazə yazmazdan əvvəl zonanın sahibini yoxlayın.
# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1
# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf
Sonra nəzərdə tutulan adları əhatə edən ən dar icazəni əlavə edin: VPN müştərilərinin sorğu göndərdiyi həlledici konfiqurasiyasında bir domen və ya bir delegasiya edilmiş alt domen. Həmin həlledicidəki hər ad üçün qorumaları söndürmək hamısı üçün müdafiəni birdən götürür, o cümlədən ona heç vaxt ehtiyac duymayan adlar üçün.
Bölünmüş DNS eyni qərara aiddir. Şəxsi adlar məkanına yalnız daxili həlledicidə cavab verilməlidirsə, onu orada dərc edin və ümumi həlledicilərə sızmasını dayandırın, beləliklə istisna hər yolu deyil, bir yolu əhatə etsin.
Resursu və müdafiəni yenidən sınayın
Yenidən sorğu göndərin, sonra xidmətə qoşulun və müştərinin nə gördüyünə baxın. İşləyən sessiya ilə düzgün şəxsi cavab istisnanın işə düşdüyünü bildirir. Dayanmış sessiya ilə düzgün cavab marşrutun və ya xidmət kimliyinin növbəti şübhəli olduğunu bildirir.
# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1
# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health
Ümumi adı da eyni həlledici vasitəsilə sınayın. Qoruma istisnadan kənar adlar üçün də işləməlidir və bu yoxlama uğursuz olarsa, dəyişiklik nəzərdə tutulduğundan geniş olub. Sertifikat yoxlamasını hər zaman toxunulmaz saxlayın, çünki düzgün həll olunan ad həm də xidmətin təqdim etdiyi sertifikata uyğun olmalıdır.
Biletdə rədd edilmiş cavabı, domeni, həllediciyi və siyasətin kimə aid olduğunu qeyd edin. Gizli daxili kəsintini kiminsə nəzərdən keçirə biləcəyi konfiqurasiya dəyişikliyinə çevirən məhz bu qeyddir.