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:

1. zweryfikować konfigurację resolvera,

2. sprawdzić logi,

3. porównać odpowiedzi z zaufanymi resolverami,

4. sprawdzić status DNSSEC,

5. wyczyścić cache zgodnie z konfiguracją używanego resolvera,

6. zaktualizować oprogramowanie,

7. sprawdzić dostęp administracyjny,

8. 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.

 

Atak DNS Spoofing a phishing – jak użytkownik może trafić na fałszywą stronę?

Phishing kojarzy się przede wszystkim z podejrzanymi wiadomościami, fałszywymi adresami stron i próbami wyłudzenia danych logowania. W rzeczywistości cyberatak może wykorzystywać również manipulację infrastrukturą sieciową.

Jednym z możliwych elementów takiego scenariusza jest Atak DNS Spoofing.

DNS Spoofing może zostać wykorzystany do skierowania użytkownika pod nieprawidłowy adres IP, podczas gdy użytkownik nadal wpisuje znaną mu nazwę domenową.

Dlaczego DNS ma znaczenie dla phishingu?

DNS można porównać do systemu, który pomaga odnaleźć serwer odpowiadający określonej domenie.

Użytkownik wpisuje:

bank.example

a system DNS zwraca adres IP:

203.0.113.10

Następnie przeglądarka próbuje nawiązać połączenie z tym adresem.

Jeżeli odpowiedź DNS zostanie zmanipulowana, schemat może wyglądać inaczej:

bank.example
     ↓
fałszywy adres IP
     ↓
serwer kontrolowany przez atakującego

To właśnie dlatego bezpieczeństwo DNS ma znaczenie również w kontekście phishingu.

DNS Spoofing nie jest tym samym co phishing

Warto rozróżnić oba pojęcia.

Phishing polega na nakłonieniu użytkownika do wykonania określonej czynności, np. podania hasła.

DNS Spoofing dotyczy manipulowania sposobem rozwiązywania nazw domenowych.

Techniki te mogą jednak zostać połączone.

Przykładowo:

DNS Spoofing
     ↓
fałszywy adres
     ↓
fałszywa strona
     ↓
Phishing
     ↓
kradzież danych

Nie każdy phishing wykorzystuje DNS Spoofing. W praktyce większość kampanii phishingowych wykorzystuje inne mechanizmy, np. podobnie wyglądające domeny.

Fałszywa domena a zmanipulowany DNS

To bardzo ważne rozróżnienie.

W klasycznym phishingu użytkownik może otrzymać link:

https://bank-example-login.com

Domena wygląda podobnie do prawdziwej, ale jest inna.

W przypadku manipulacji DNS użytkownik może natomiast wpisać prawidłową nazwę domeny, a problem może pojawić się podczas jej rozwiązywania.

To dwa zupełnie różne scenariusze.

HTTPS jest bardzo ważną barierą

DNS Spoofing nie oznacza automatycznie możliwości stworzenia wiarygodnej kopii dowolnej strony HTTPS.

Jeżeli użytkownik zostanie skierowany na fałszywy serwer, przeglądarka powinna sprawdzić certyfikat TLS.

Przykładowo:

Użytkownik
    ↓
DNS Spoofing
    ↓
Fałszywy serwer
    ↓
Certyfikat TLS
    ↓
Błąd / ostrzeżenie

Jeżeli pojawia się ostrzeżenie dotyczące certyfikatu, należy przerwać połączenie.

Szczególnie niebezpieczne jest ignorowanie komunikatu tylko dlatego, że strona wygląda znajomo.

Dlaczego użytkownik może nie zauważyć problemu?

Cyberprzestępcy mogą próbować odtworzyć wygląd popularnych usług:

• banków,

• poczty,

• mediów społecznościowych,

• sklepów internetowych,

• systemów firmowych.

Strona może wyglądać niemal identycznie jak oryginał.

Dlatego nie należy oceniać bezpieczeństwa wyłącznie na podstawie wyglądu strony.

Co może wzbudzić podejrzenia?

Warto zwrócić uwagę na:

• ostrzeżenia HTTPS,

• nietypowy adres domeny,

• nieoczekiwane przekierowanie,

• prośbę o ponowne logowanie,

• nietypowe komunikaty,

• brak oczekiwanych elementów strony,

• błędy certyfikatu,

• zmianę zachowania strony po przełączeniu sieci.

Szczególnie interesujący jest przypadek, gdy strona działa prawidłowo w jednej sieci, a w innej zachowuje się nietypowo.

DNS Cache Poisoning

Jednym ze scenariuszy związanych z manipulacją DNS jest DNS Cache Poisoning.

Atakujący próbuje doprowadzić do umieszczenia fałszywej informacji w pamięci podręcznej resolvera.

Jeżeli taka informacja zostanie zaakceptowana, kolejne zapytania mogą otrzymywać nieprawidłową odpowiedź.

Szersze omówienie zagrożeń DNS znajduje się w artykule Ataki na DNS – jak cyberprzestępcy manipulują systemem nazw domen.

Publiczne Wi-Fi zwiększa znaczenie problemu

Publiczna sieć Wi-Fi może być środowiskiem, w którym użytkownik ma mniejszą kontrolę nad konfiguracją sieci.

Dotyczy to między innymi:

• lotnisk,

• hoteli,

• restauracji,

• galerii handlowych,

• dworców,

• konferencji.

Nie oznacza to, że każda publiczna sieć jest zagrożeniem.

Warto jednak zachować większą ostrożność przy logowaniu do ważnych usług.

DNS over HTTPS

DNS over HTTPS może ograniczyć możliwość klasycznej manipulacji zapytaniami DNS w lokalnej sieci.

Zapytanie jest przesyłane przez szyfrowane HTTPS:

Urządzenie
     ↓
HTTPS
     ↓
Resolver DoH

Dzięki temu lokalny atakujący nie może łatwo przechwycić zwykłego zapytania DNS i odpowiedzieć na nie własnym rekordem.

DoH nie jest jednak uniwersalnym rozwiązaniem wszystkich problemów DNS.

DNSSEC

DNSSEC działa na innej zasadzie.

Mechanizm wykorzystuje podpisy kryptograficzne do zapewnienia możliwości weryfikacji danych DNS.

Jeżeli odpowiedź nie przejdzie walidacji, resolver może ją odrzucić.

W ten sposób DNSSEC może utrudnić określone formy manipulacji rekordami DNS.

Więcej informacji znajduje się w materiale Wdrażanie DNSSEC na Windows Server dla integralności i autentyczności zapytań DNS.

MFA ogranicza skutki phishingu

Nawet jeżeli użytkownik poda hasło na fałszywej stronie, dodatkowa warstwa uwierzytelniania może ograniczyć możliwość przejęcia konta.

Dlatego warto korzystać z:

• aplikacji uwierzytelniających,

• kluczy bezpieczeństwa,

• passkeys,

• innych mechanizmów MFA.

Nie należy jednak traktować MFA jako powodu do ignorowania phishingu.

Passkeys a fałszywe strony

Passkeys wykorzystują kryptografię klucza publicznego i są powiązane z odpowiednią domeną.

To ważna różnica względem klasycznych haseł.

Fałszywa strona nie może po prostu otrzymać od użytkownika passkey w postaci tekstowej, ponieważ mechanizm uwierzytelniania działa inaczej.

Nie oznacza to, że rozwiązanie eliminuje wszystkie zagrożenia, ale znacząco zmienia odporność na klasyczne phishingowe kradzieże haseł.

Jak sprawdzić DNS?

Windows:

ipconfig /all

oraz:

nslookup example.com

Linux:

resolvectl status

oraz:

dig example.com

Można porównać odpowiedzi różnych resolverów.

Jeżeli otrzymujemy znacząco różne wyniki, warto sprawdzić, z czego wynika różnica.

Nie każda różnica oznacza atak — może wynikać między innymi z CDN, geolokalizacji czy konfiguracji DNS.

Co zrobić, gdy strona wygląda podejrzanie?

Jeżeli użytkownik ma podejrzenie manipulacji:

1. nie wpisuj danych logowania,

2. zamknij stronę,

3. sprawdź adres domeny,

4. zweryfikuj certyfikat,

5. przełącz się na zaufaną sieć,

6. sprawdź konfigurację DNS,

7. jeśli podałeś hasło — zmień je,

8. sprawdź aktywne sesje konta,

9. włącz MFA.

W przypadku kont firmowych warto również powiadomić administratora bezpieczeństwa.

DNS Spoofing i bankowość

Szczególną ostrożność należy zachować podczas korzystania z:

• bankowości internetowej,

• systemów płatności,

• paneli administracyjnych,

• poczty,

• systemów firmowych.

W takich przypadkach nie należy ignorować żadnych ostrzeżeń bezpieczeństwa.

Jeżeli przeglądarka informuje o problemie z certyfikatem, należy przerwać połączenie.

Najlepsza ochrona jest wielowarstwowa

Nie istnieje jeden mechanizm, który eliminuje wszystkie zagrożenia.

Skuteczna ochrona może wyglądać następująco:

Bezpieczny DNS
      ↓
DNSSEC
      ↓
DoH / DoT
      ↓
HTTPS / TLS
      ↓
MFA / Passkeys
      ↓
Monitoring
      ↓
Świadomość użytkownika

Każda warstwa odpowiada za inny fragment problemu.

Podsumowanie

Atak DNS Spoofing może zostać wykorzystany jako element bardziej złożonego scenariusza phishingowego, w którym użytkownik zostaje skierowany na niewłaściwy serwer.

Nie oznacza to jednak, że sam DNS Spoofing automatycznie pozwala ominąć HTTPS. Certyfikaty TLS, DNSSEC, szyfrowany DNS oraz nowoczesne mechanizmy uwierzytelniania tworzą dodatkowe bariery.

Najważniejszą zasadą pozostaje nieignorowanie ostrzeżeń przeglądarki i dokładne sprawdzanie nietypowego zachowania stron, szczególnie podczas korzystania z publicznych lub niezaufanych sieci.