Atak DNS Spoofing a DNS Cache Poisoning – jak chronić resolver DNS?
DNS jest jednym z fundamentów działania Internetu. Każdego dnia urządzenia wykonują ogromną liczbę zapytań, aby zamienić nazwy domen na adresy IP. Jeżeli mechanizm ten zostanie zmanipulowany, użytkownik może zostać skierowany do niewłaściwego serwera.
Atak DNS Spoofing może być realizowany na różnych etapach obsługi zapytania DNS. Jednym z istotnych zagrożeń jest DNS Cache Poisoning, czyli zatruwanie pamięci podręcznej resolvera.
Czym jest DNS Cache Poisoning?
Resolver DNS przechowuje część otrzymanych odpowiedzi w pamięci podręcznej. Dzięki temu kolejne zapytania dotyczące tej samej domeny mogą zostać obsłużone szybciej.
Przykładowo:
Klient
↓
Resolver DNS
↓
Zapytanie: example.com
↓
Adres IP
↓
Cache
Jeżeli do pamięci podręcznej trafi nieprawidłowa informacja, kolejne urządzenia korzystające z tego resolvera mogą otrzymywać błędny adres.
Jak wygląda scenariusz ataku?
W uproszczeniu atakujący próbuje doprowadzić do zaakceptowania fałszywej odpowiedzi DNS.
Normalnie:
Klient → Resolver → Prawidłowa odpowiedź
W przypadku manipulacji:
Klient → Resolver
↑
fałszywa odpowiedź
Jeżeli resolver zaakceptuje zmanipulowane dane, mogą one zostać zapisane w cache.
Wtedy problem nie dotyczy już tylko jednego urządzenia.
Dlaczego cache jest ważny?
Cache poprawia wydajność DNS, ale jednocześnie zwiększa znaczenie poprawności przechowywanych danych.
Jeżeli prawidłowa odpowiedź wygląda tak:
example.com → 203.0.113.10
a w pamięci pojawi się:
example.com → 203.0.113.99
kolejne zapytania mogą otrzymywać nieprawidłowy adres aż do wygaśnięcia wpisu zgodnie z TTL lub jego usunięcia.
DNS Spoofing a Cache Poisoning
Pojęcia te są ze sobą powiązane, ale nie zawsze oznaczają dokładnie to samo.
DNS Spoofing jest szerszym określeniem manipulowania odpowiedziami DNS.
DNS Cache Poisoning koncentruje się na wprowadzeniu fałszywych danych do pamięci podręcznej resolvera.
Więcej informacji o różnych sposobach manipulowania DNS można znaleźć w artykule Ataki na DNS – jak cyberprzestępcy manipulują systemem nazw domen.
Resolver jest kluczowym elementem infrastruktury
Resolver może być uruchomiony:
na routerze,
na serwerze Linux,
na Windows Server,
w infrastrukturze operatora,
w chmurze,
jako zewnętrzna usługa DNS.
W środowisku firmowym resolver powinien być traktowany jako istotny element bezpieczeństwa infrastruktury.
Jego kompromitacja może wpływać na dużą liczbę użytkowników.
DNSSEC jako ochrona przed manipulacją
Jednym z najważniejszych mechanizmów zwiększających wiarygodność odpowiedzi DNS jest DNSSEC.
DNSSEC wykorzystuje podpisy kryptograficzne umożliwiające walidację danych.
W uproszczeniu:
Domena
↓
Rekord DNS
↓
Podpis kryptograficzny
↓
Walidacja
↓
Odpowiedź
Jeżeli odpowiedź nie przejdzie poprawnie procesu walidacji, resolver może ją odrzucić.
Więcej informacji na temat DNSSEC można znaleźć w materiale Wdrażanie DNSSEC na Windows Server dla integralności i autentyczności zapytań DNS.
TTL i czas życia wpisów
Każdy rekord DNS może posiadać wartość TTL, czyli Time To Live.
Przykład:
example.com
TTL: 3600
Oznacza to, że odpowiedź może być przechowywana przez określony czas.
TTL wpływa więc między innymi na:
wydajność DNS,
częstotliwość zapytań,
propagację zmian,
czas przechowywania danych w cache.
Nie należy jednak zakładać, że niski TTL sam w sobie zabezpiecza przed DNS Cache Poisoning.
Randomizacja portów źródłowych
Nowoczesne resolvery stosują różne mechanizmy utrudniające przewidzenie parametrów zapytania DNS.
Jednym z nich jest randomizacja portu źródłowego.
W połączeniu z innymi mechanizmami zwiększa to trudność skutecznego wstrzyknięcia fałszywej odpowiedzi.
Randomizacja identyfikatora zapytania
DNS wykorzystuje również identyfikator zapytania.
Resolver może losować jego wartość, aby utrudnić atakującemu przewidzenie parametrów potrzebnych do zaakceptowania fałszywej odpowiedzi.
Współczesne implementacje stosują więcej niż jeden mechanizm ochronny.
DNS over HTTPS
DNS over HTTPS szyfruje komunikację pomiędzy klientem a resolverem.
Schemat może wyglądać tak:
Klient
↓
HTTPS
↓
Resolver DoH
Dzięki temu lokalny atakujący ma znacznie mniejszą możliwość klasycznego przechwytywania niezabezpieczonych zapytań DNS.
DoH nie zastępuje jednak DNSSEC.
Oba mechanizmy rozwiązują różne problemy.
DNS over TLS
Podobną funkcję zapewnia DNS over TLS.
W tym przypadku zapytania DNS są przesyłane przez szyfrowany kanał TLS.
Można więc wyróżnić:
DoH / DoT
→ ochrona transportu
DNSSEC
→ walidacja danych DNS
W dobrze zaprojektowanej infrastrukturze technologie te mogą się uzupełniać.
Czy HTTPS chroni przed DNS Spoofing?
HTTPS może znacząco ograniczyć skutki manipulacji DNS.
Załóżmy, że użytkownik zostanie skierowany na fałszywy adres IP.
Przeglądarka nadal powinna sprawdzić certyfikat TLS.
Jeżeli certyfikat nie odpowiada domenie, pojawi się ostrzeżenie.
Schemat:
DNS Spoofing
↓
Fałszywy adres
↓
HTTPS
↓
Weryfikacja certyfikatu
↓
Ostrzeżenie
Dlatego użytkownik nigdy nie powinien ignorować ostrzeżeń dotyczących certyfikatów.
Co może wskazywać na problem?
Administrator może zauważyć:
nieoczekiwane odpowiedzi DNS,
zmiany rekordów,
nietypowe domeny,
błędy DNSSEC,
nagłe zmiany konfiguracji resolvera,
anomalie w logach,
zwiększoną liczbę zapytań,
nieznane serwery DNS.
Ważna jest analiza wielu źródeł informacji jednocześnie.
Monitoring resolvera
Bezpieczeństwo DNS nie powinno kończyć się na konfiguracji.
Warto monitorować:
liczbę zapytań,
typy rekordów,
błędy walidacji DNSSEC,
nietypowe domeny,
odpowiedzi NXDOMAIN,
nietypowe wzorce ruchu,
zmiany konfiguracji.
Pozwala to szybciej zauważyć anomalie.
DNS w Windows Server
W środowiskach Windows Server DNS często jest mocno powiązany z Active Directory.
Dlatego nieautoryzowana zmiana konfiguracji DNS może mieć wpływ na znacznie więcej niż dostęp do stron internetowych.
Problemy z DNS mogą wpływać również na:
lokalizowanie kontrolerów domeny,
uwierzytelnianie,
działanie usług sieciowych,
komunikację pomiędzy serwerami,
działanie aplikacji firmowych.
Z tego powodu serwery DNS powinny być odpowiednio monitorowane i aktualizowane.
DNS w Linuxie
Popularne implementacje resolverów DNS w środowiskach Linux mogą być konfigurowane zgodnie z wymaganiami konkretnej infrastruktury.
Administrator powinien zwrócić uwagę na:
źródła zapytań,
dozwolone interfejsy,
recursion,
forwarding,
cache,
DNSSEC,
logowanie,
aktualizacje.
Niepotrzebne udostępnianie rekursywnego resolvera do Internetu zwiększa powierzchnię ataku.
Open Resolver – dlaczego to problem?
Resolver skonfigurowany jako otwarty dla dowolnego użytkownika Internetu może zostać wykorzystany do nadużyć.
Może między innymi stać się elementem ataków DDoS wykorzystujących DNS jako mechanizm amplifikacji.
Dlatego resolver powinien odpowiadać tylko tym klientom, którzy rzeczywiście powinni mieć do niego dostęp.
Segmentacja resolverów
W większych sieciach można rozdzielić funkcje DNS.
Przykładowo:
Sieć użytkowników
↓
Resolver lokalny
↓
Forwarder
↓
Internet DNS
Takie podejście pozwala lepiej kontrolować ruch DNS i prowadzić monitoring.
Co zrobić po podejrzeniu zatrucia cache?
Jeżeli administrator podejrzewa DNS Cache Poisoning, powinien między innymi:
zweryfikować konfigurację resolvera,
sprawdzić logi,
porównać odpowiedzi z zaufanymi resolverami,
sprawdzić status DNSSEC,
wyczyścić cache zgodnie z konfiguracją używanego resolvera,
zaktualizować oprogramowanie,
sprawdzić dostęp administracyjny,
przeanalizować źródło nietypowych zapytań.
Samo wyczyszczenie cache może usunąć objaw, ale niekoniecznie przyczynę problemu.
Bezpieczeństwo DNS jest procesem
Resolver nie powinien być konfigurowany raz i pozostawiany bez kontroli.
Warto regularnie:
aktualizować oprogramowanie,
przeglądać konfigurację,
monitorować logi,
kontrolować dostęp administracyjny,
testować DNSSEC,
sprawdzać reguły firewalla,
analizować nietypowy ruch.
Podsumowanie
Atak DNS Spoofing może przyjmować różne formy, a DNS Cache Poisoning jest jednym ze scenariuszy, w którym fałszywe dane mogą zostać zapisane w pamięci podręcznej resolvera.
Ochrona wymaga kilku warstw. DNSSEC pozwala weryfikować autentyczność danych, DoH i DoT chronią transport zapytań, a odpowiednia konfiguracja resolvera ogranicza możliwość jego nadużycia.
Równie ważne są monitoring, aktualizacje oraz kontrola dostępu administracyjnego.
Bezpieczny DNS powinien być traktowany jako element całej infrastruktury bezpieczeństwa, a nie tylko usługa odpowiedzialna za tłumaczenie nazw domen na adresy IP.
