Jak działa DNS i jakie niesie ryzyko

System nazw domenowych (DNS) tłumaczy przyjazne dla człowieka nazwy, takie jak example.com, na adresy IP, na przykład 93.184.216.34. Niemal każda transakcja sieciowa zaczyna się od wyszukania informacji w DNS, co czyni DNS cennym celem ataków.

Jeśli napastnik kontroluje rozwiązywanie nazw lub manipuluje nim, może po cichu przekierować ofiary do złośliwych serwerów, przechwytywać ruch albo eksfiltrować dane bez ingerowania w samą aplikację. Zrozumienie ścieżki rozwiązywania nazw to pierwszy krok do jej ochrony.

Typowe zapytanie rekurencyjne przechodzi przez łańcuch serwerów:

• Resolver typu stub po stronie klienta (system operacyjny).
• Resolver rekurencyjny (u dostawcy internetu lub 8.8.8.8), który wykonuje całą pracę.
• Serwery główne wskazujące serwery TLD.
• Serwery TLD (np. .com) wskazujące serwery autorytatywne.
• Serwery autorytatywne przechowujące właściwe rekordy.

Każdy etap jest potencjalnym punktem przechwycenia lub fałszowania.

Resolver rekurencyjny odpowiada na dowolne zapytanie, podążając w imieniu klienta za delegacjami i zapisując wynik w pamięci podręcznej. Serwer autorytatywny odpowiada wyłącznie za strefy, za które odpowiada, i udostępnia rozstrzygające dane.

Z punktu widzenia bezpieczeństwa otwarte resolvery rekurencyjne mogą być wykorzystywane do ataków wzmacniających, natomiast serwery autorytatywne są celem przejęcia strefy lub konta u rejestratora. Rekurencję należy ograniczyć do własnej sieci.

Rekordy, z którymi spotkają się Państwo podczas analizy:

• A / AAAA — adres IPv4 / IPv6.
• CNAME — alias do innej nazwy (należy uważać na nieaktualne rekordy CNAME prowadzące do przejęcia subdomeny).
• MX — serwery pocztowe.
• NS — delegowanie do serwerów autorytatywnych.
• TXT — dowolny tekst, używany przez SPF i DKIM, a często także nadużywany do tunelowania.

Klasyczny DNS działa przez UDP na porcie 53, a dla dużych odpowiedzi i transferów stref korzysta awaryjnie z TCP 53. UDP nie ustanawia połączenia i jest bezstanowy, więc nie ma uzgadniania potwierdzającego, że odpowiadający serwer jest tym, za który się podaje.

Jedynym powiązaniem zapytania z odpowiedzią są 16-bitowy identyfikator transakcji oraz port źródłowy. To słabe powiązanie jest główną przyczyną fałszowania odpowiedzi i zatruwania pamięci podręcznej.

Aby zmniejszyć obciążenie, resolvery przechowują odpowiedzi w pamięci podręcznej przez czas określony wartością rekordu TTL (czas życia). Odpowiedź z TTL 3600 pozostaje w pamięci podręcznej przez godzinę.

Buforowanie jest mieczem obosiecznym: poprawia wydajność, ale oznacza, że jedna zatruta odpowiedź może być dostarczana wielu ofiarom do czasu wygaśnięcia TTL. Napastnicy często próbują wymusić długie wartości TTL, aby złośliwe wpisy pozostały aktywne jak najdłużej.

DNS udostępnia wiele powierzchni ataku:

• Fałszowanie na trasie — podrabianie odpowiedzi szybciej niż robi to legalny serwer.
• Zatrucie pamięci podręcznej — wstrzykiwanie nieprawidłowych rekordów do pamięci podręcznej resolvera.
• Przejęcie domeny u rejestratora / strefy — odebranie kontroli nad samą domeną.
• Tunelowanie — kodowanie danych w zapytaniach w celu obejścia kontroli ruchu wychodzącego.
• Amplifikacja DDoS — wykorzystywanie otwartych resolverów jako wzmacniaczy i odbijaczy ruchu.

Zwykły DNS nie zapewnia gwarancji integralności ani autentyczności. Odpowiedź jest uznawana za zaufaną, jeśli zgadzają się adres IP źródła, port docelowy, nazwa zapytania i identyfikator transakcji. Wszystkie te wartości może odgadnąć lub zaobserwować napastnik znajdujący się na trasie.

To założenie projektowe (że sieć jest godna zaufania) wyjaśnia, dlaczego istnieją dodatkowe mechanizmy ochrony, takie jak DNSSEC, DNS over TLS (DoT) i DNS over HTTPS (DoH).

Przed atakiem przeciwnicy przeprowadzają rekonesans DNS, aby zmapować zasoby. Błędnie skonfigurowane transfery stref (AXFR) mogą ujawnić wszystkie rekordy. Wyszukiwanie subdomen metodą brute force oraz logi Certificate Transparency ujawniają ukryte hosty.

Należy ograniczyć transfery stref do znanych serwerów secondary i monitorować wzorce masowych zapytań, które sygnalizują rekonesans.

DNS over TLS (port 853) i DNS over HTTPS (port 443) szyfrują zapytanie, dzięki czemu obserwatorzy na trasie nie mogą go odczytać ani zmodyfikować. Ogranicza to fałszowanie i chroni prywatność.

Kompromis z punktu widzenia obrońców polega na tym, że szyfrowany DNS może uniemożliwić własnym systemom filtrowanie i monitorowanie ruchu. Wiele przedsiębiorstw wymusza korzystanie przez klientów z kontrolowanego resolvera DoH/DoT, zamiast pozwalać urządzeniom końcowym wybierać zewnętrzne resolvery.

Praktyczne sposoby wzmocnienia bezpieczeństwa ścieżki rozwiązywania nazw:

• Uruchomić wewnętrzne resolvery rekurencyjne i blokować bezpośredni wychodzący port 53 do internetu.
• Wyłączyć otwartą rekurencję na serwerach autorytatywnych.
• Ograniczyć i rejestrować transfery stref AXFR.
• Zabezpieczyć domenę u rejestratora (blokada rejestru, MFA).
• Monitorować liczbę zapytań i ich entropię pod kątem tunelowania oraz rekonesansu.

Proszę sprawdzić, jak dobrze Państwo rozumieją, dlaczego DNS jest narażony na ataki.

Poznali Państwo, że rozwiązywanie DNS przebiega przez łańcuch od resolvera typu stub, przez serwery główne i TLD, aż po serwery autorytatywne, a odpowiedzi są przechowywane w pamięci podręcznej zgodnie z wartością TTL. Ponieważ klasyczny DNS przez UDP/53 nie zapewnia uwierzytelniania, jest narażony na fałszowanie, zatrucie pamięci podręcznej, przejęcie, tunelowanie i amplifikację.

Najważniejsze zabezpieczenia to zamknięta rekurencja, ograniczone transfery stref, blokady u rejestratora, szyfrowany transport (DoT/DoH) oraz DNSSEC. Następnie szczegółowo omówimy fałszowanie i zatruwanie pamięci podręcznej.