Najlepsze praktyki w zakresie bezpieczeństwa DNS: kompletna lista kontrolna dotycząca wzmocnienia zabezpieczeń

Infrastruktura systemu nazw domenowych (DNS) jest często najbardziej zaufanym elementem sieci przedsiębiorstwa, a mimo to pozostaje jednym z najmniej monitorowanych. Kiedy administratorzy systemów konfigurują rekordy domenowe, zazwyczaj zajmują się następnie zaporami sieciowymi, zabezpieczeniami punktów końcowych lub zarządzaniem tożsamością. Atakujący wiedzą o istnieniu tej luki i w pełni ją wykorzystują.

Jeśli osoba zła przejmie kontrolę nad procesem rozpoznawania nazw domen, może w sposób niezauważalny przekierowywać ruch internetowy, przechwytywać firmowe wiadomości e-mail oraz generować ważne certyfikaty Transport Layer Security (TLS) w Twoim imieniu. Wszystko to udaje jej się osiągnąć bez włamania się do żadnego serwera w Twojej sieci wewnętrznej.

Wdrożenie solidnych zabezpieczeń DNS nie jest opcjonalne w przypadku nowoczesnej infrastruktury. Niniejszy przewodnik zawiera kompletny zestaw najlepszych praktyk dotyczących bezpieczeństwa DNS, które pomogą uniknąć typowych problemów i błędów.

Czym jest bezpieczeństwo DNS?

Bezpieczeństwo DNS to system środków technicznych, protokołów kryptograficznych i zasad administracyjnych mających na celu ochronę integralności, dostępności i poufności usług rozpoznawania nazw domen.

Skuteczne zabezpieczenie systemu DNS nie polega na stosowaniu jednego narzędzia, lecz wymaga wdrożenia środków ochronnych na czterech odrębnych warstwach:

1. Rejestrator i warstwa kont: Obejmuje to zabezpieczenia administracyjne u rejestratora domeny, które zapobiegają nieautoryzowanym transferom domen oraz kradzieży danych uwierzytelniających.
2. Warstwa autorytatywnych serwerów nazw: Są to mechanizmy kontroli infrastruktury, które gwarantują, że oficjalne pliki stref pozostają dostępne, niezmienione i odporne na ataki typu DDoS (Distributed Denial of Service).
3. Warstwa rozpoznawania i warstwa transportowa: Warstwa ta obejmuje protokoły zabezpieczające zapytania DNS przesyłane między klientami końcowymi, serwerami rekurencyjnymi a serwerami autorytatywnymi.
4. Warstwa rekordów zasobów i tożsamości: rekordy kryptograficzne opublikowane w pliku strefy, takie jak rozszerzenia zabezpieczeń systemu nazw domenowych (DNS) oraz rekordy uwierzytelniania poczty elektronicznej, które służą do weryfikacji autentyczności danych domeny.

Dlaczego DNS stanowi cel ataku: powierzchnia ataku

Ponieważ system DNS działa jako zaufana infrastruktura działająca w tle, przestarzałe konfiguracje umożliwiają cyberprzestępcom przeprowadzanie różnego rodzaju ataków.

Przejęcie kontroli nad DNS i włamanie do systemu rejestratora

W przypadku ataku polegającego na przejęciu domeny osoba atakująca uzyskuje dostęp do konta użytkownika u rejestratora domen lub wykorzystuje luki w procedurach rejestratora, aby zmodyfikować delegacje serwerów nazw. Gdy atakujący zmieni rekordy NS tak, by wskazywały na jego fałszywe serwery, przejmuje kontrolę nad całym ruchem przychodzącym do domeny.

Ostatnie kampanie były skierowane przeciwko rejestratorom domen i wykorzystywały ataki typu „credential stuffing” oraz ukierunkowaną inżynierię społeczną. Gdy atakującym uda się przeprowadzić przejęcie kontroli nad DNS, mogą oni natychmiast wygenerować ważne certyfikaty dla domeny głównej użytkownika, korzystając z automatycznych protokołów weryfikacji urzędu certyfikacji (CA).

Fałszowanie adresów DNS i zatruwanie pamięci podręcznej

Tradycyjne zapytania DNS są przesyłane za pośrednictwem niezaszyfrowanego protokołu UDP na porcie 53. Ponieważ standardowe zapytania nie posiadają wbudowanego uwierzytelniania transakcji, osoba atakująca znajdująca się na ścieżce sieciowej może sfałszować pakiety odpowiedzi i wysłać je z powrotem do rekurencyjnego serwera rozdzielczego, zanim udzieli odpowiedzi autorytatywny serwer.

Technika ta, znana jako spoofing DNS, zmusza serwery rekurencyjne do akceptowania fałszywych adresów IP dla wybranych nazw hostów. Gdy program rozpoznający nazwy przechowuje te sfałszowane odpowiedzi w swojej pamięci lokalnej, dochodzi do zatrucia pamięci podręcznej DNS. Każdy użytkownik korzystający z tego programu rozpoznającego nazwy jest przekierowywany na złośliwe strony internetowe do momentu wygaśnięcia wpisu w pamięci podręcznej. Zrozumienie tych wektorów ataku jest bardzo ważne podczas analizy typowych rodzajów ataków DNS.

Wzmocnienie DNS i ataki DDoS

Autorytatywne serwery nazw są głównym celem ataków DDoS opartych na przepustowości. Atakujący często wykorzystują otwarte rekurencyjne serwery rozpoznawania nazw do przeprowadzania ataków amplifikacyjnych typu DNS.

Wysyłając do podatnych na atak serwerów rozpoznających nazwy małe sfałszowane żądania (takie jak zapytania typu ANY lub TXT ) z podfałszowanym adresem IP ofiary jako źródłem, serwery te zwracają ofierze ogromne ilości danych w odpowiedzi. Ten zalew ruchu przeciąża przepustowość sieci i powoduje rozległe przerwy w działaniu usług.

Wiszące rekordy i przejęcie subdomeny

Gdy organizacje przenoszą usługi między dostawcami chmury, inżynierowie systemowi często likwidują zasoby chmurowe, takie jak zasoby Amazon S3, GitHub Pages czy Azure App Services, nie usuwając przy tym odpowiednich rekordów CNAME ze swojej strefy DNS.
To przeoczenie powoduje powstanie „wiszącego” rekordu DNS. Zewnętrzny atakujący może przejąć opuszczony zasób lub instancję aplikacji na platformie dostawcy usług w chmurze, natychmiast uzyskując kontrolę nad subdomeną. Przejęcie subdomeny pozwala atakującym na umieszczanie formularzy phishingowych, przeprowadzanie ataków typu cross-site scripting (XSS) oraz kradzież plików cookie sesji.

Podszywanie się pod adresy e-mail poprzez wykorzystanie słabych wpisów DNS

Dostarczanie wiadomości e-mail w dużym stopniu opiera się na systemie DNS. Jeśli Twoja organizacja nie opublikuje prawidłowo skonfigurowanych rekordów uwierzytelniających, cyberprzestępcy mogą wysyłać wiadomości e-mail, które wyglądają tak, jakby pochodziły z Twojej domeny. Naraża to Twoich partnerów biznesowych, klientów i pracowników na bezpośrednie ataki phishingowe.

Najlepsze praktyki w zakresie bezpieczeństwa DNS: lista kontrolna dotycząca wzmacniania zabezpieczeń

Skorzystaj z tej listy kontrolnej zawierającej instrukcje krok po kroku, aby systematycznie wzmocnić zabezpieczenia infrastruktury domenowej przed przechwyceniem i nadużyciami.

1. Zabezpiecz swoją domenę na poziomie rejestratora

Nieautoryzowane żądania transferu stanowią jedno z największych zagrożeń dla kluczowych zasobów domeny. Należy zastosować w swoich domenach kody statusu „clientTransferProhibited ” i „clientUpdateProhibited ”.

W przypadku domen korporacyjnych o dużej wartości należy zwrócić się do rejestratora z prośbą o aktywację blokady rejestru. Blokada rejestru wymaga weryfikacji w trybie offline, np. potwierdzenia telefonicznego przez wyznaczony personel, zanim będzie można wprowadzić jakiekolwiek zmiany w delegacjach serwerów nazw lub danych kontaktowych administratora w bazie WHOIS.

2. Wprowadź uwierzytelnianie wieloskładnikowe (MFA) i dostęp oparty na rolach w swojej firmie zajmującej się rejestracją domen

Upewnij się, że konta administracyjne u rejestratora domeny i dostawcy usług hostingowych DNS nie opierają się wyłącznie na hasłach. Wprowadź obowiązkowe stosowanie sprzętowego uwierzytelniania wieloskładnikowego (MFA) z wykorzystaniem kluczy bezpieczeństwa zgodnych ze standardem FIDO2 / WebAuthn.

Nie należy przechowywać danych logowania rejestratora we wspólnych skrzynkach pocztowych zespołu. Należy wdrożyć rygorystyczną kontrolę dostępu opartą na rolach (RBAC), tak aby zwykli pracownicy działu IT mieli dostęp wyłącznie w trybie odczytu, a uprawnienia do zarządzania domenami były zarezerwowane dla wyznaczonych administratorów domen.

3. Ograniczenie transferów strefowych (AXFR)

Autorytatywne serwery DNS wykorzystują pełne transfery stref (AXFR) do replikacji danych DNS między serwerami głównymi a pomocniczymi. Jeśli serwer nazw zezwala na nieograniczone żądania AXFR z dowolnego adresu IP, osoby atakujące mogą pobrać cały plik strefy. Naraża to na ujawnienie wewnętrzne struktury nazw hostów, serwery testowe oraz ukrytą infrastrukturę sieciową.

Skonfiguruj swoje główne serwery nazw tak, aby zezwalały na transfery AXFR wyłącznie do konkretnych adresów IP autoryzowanych serwerów nazw pomocniczych. Konfigurację można sprawdzić w wierszu poleceń terminala:

Brak
dig AXFR twojadomena.com @ns1.twojadomena.com

dig AXFR twojadomena.com @ns1.twojadomena.com

Jeśli serwer zwróci pełną listę rekordów DNS zamiast komunikatu o błędzie „Transfer Failed” lub „REFUSED”, oznacza to, że ustawienia transferu strefy są otwarte i należy je natychmiast ograniczyć.

4. Wdrożenie redundantnych serwerów nazw o statusie autorytatywnym w różnych sieciach

Korzystanie z usług jednego dostawcy DNS lub jednego fizycznego centrum danych powoduje powstanie pojedynczego punktu awarii. Jeśli dostawca padnie ofiarą ataku DDoS lub wystąpi awaria sieci, cała Twoja obecność w sieci zostanie unieruchomiona.

Należy wdrożyć co najmniej dwa autorytatywne serwery nazw, hostowane w ramach odrębnych numerów systemów autonomicznych (ASN) oraz w sieciach rozproszonych geograficznie. Zastosowanie modelu autorytatywnego DNS opartego na dwóch dostawcach gwarantuje, że w przypadku awarii infrastruktury u jednego z nich drugi dostawca będzie nadal płynnie obsługiwał zapytania.

5. Wdrożenie protokołu DNSSEC z wykorzystaniem nowoczesnej kryptografii

DNSSEC dodaje podpisy cyfrowe do rekordów DNS. Gdy rekurencyjny serwer rozdzielczy wysyła zapytanie do strefy obsługującej DNSSEC, weryfikuje podpisy kryptograficzne (rekordy RRSIG) w oparciu o łańcuch zaufania sięgający aż do strefy korzeniowej. Pomaga to zapewnić, że odpowiedź nie została zmodyfikowana podczas przesyłania.

Wdrażając protokół DNSSEC, należy postępować zgodnie ze zaktualizowanymi wytycznymi zawartymi w dokumencie NIST SP 800-81r3:

• Należy stosować nowoczesne algorytmy kryptograficzne oparte na krzywych eliptycznych, takie jak ECDSA z krzywą P-256 lub Ed25519, zamiast przestarzałych kluczy RSA. Mniejsze rozmiary kluczy zmniejszają ryzyko fragmentacji pakietów w protokole UDP.
• Należy utrzymywać okres ważności podpisu w przedziale od 5 do 7 dni, aby ograniczyć czas, w którym narażony klucz może stanowić zagrożenie.
• Należy planować wymianę kluczy do podpisu strefowego (ZSK) co 1–3 lata, a klucze do podpisu kluczy (KSK) przechowywać, w miarę możliwości, w bezpiecznych konfiguracjach sprzętowych.

Możesz sprawdzić, czy łańcuch kryptograficzny Twojej domeny jest nienaruszony, sprawdzając ją za pomocą specjalnego narzędzia do sprawdzania zgodności z protokołem DNSSEC.

6. Opublikuj rekord autoryzacji urzędu certyfikacji (CAA)

Rekord CAA to rekord typu DNS TXT, który wyraźnie określa, które urzędy certyfikacji są uprawnione do wydawania publicznych certyfikatów TLS dla danej nazwy domeny.

Jeśli osoba atakująca spróbuje wystąpić do automatycznego urzędu certyfikacji o wydanie nieautoryzowanego certyfikatu dla Twojej domeny, urząd ten musi przed wydaniem certyfikatu sprawdzić Twój publiczny wpis CAA. Jeśli urząd certyfikacji nie figuruje na liście, wydanie certyfikatu zostanie zablokowane.

Aby ograniczyć wydawanie certyfikatów do określonych dostawców, dodaj rekord CAA do swojej domeny głównej:

Brak
yourdomain.com. IN CAA 0 issue „letsencrypt.org”
yourdomain.com. IN CAA 0 issue „digicert.com”
yourdomain.com. IN CAA 0 iodef „mailto:[email protected]”

Parametr „iodef” nakazuje zgodnym urzędom certyfikacji (CA) wysyłanie w czasie rzeczywistym wiadomości e-mail z powiadomieniami do zespołu ds. bezpieczeństwa, jeśli ktoś podejmie próbę wystąpienia o nieautoryzowany certyfikat.

7. Kontrola pod kątem rekordów „wiszących” i „osieroconych”

Regularnie przeglądaj listę opublikowanych rekordów, aby wykryć nieaktualne nazwy hostów. Zwróć szczególną uwagę na rekordy CNAME kierujące do zewnętrznych dostawców usług w chmurze, subdomeny przypisane do wycofanych dostawców poczty elektronicznej oraz nieaktualne rekordy A kierujące do wycofanych adresów IP.
Przed wprowadzeniem zmian strukturalnych sprawdź opublikowane rekordy za pomocą niezawodnego narzędzia do wyszukiwania rekordów DNS. Przeglądanie różnych typów rekordów DNS we wszystkich aktywnych subdomenach pomaga zapobiegać przypadkowemu narażeniu na ataki polegające na przejęciu kontroli nad subdomeną.

8. Ustaw rozsądne wartości TTL i monitoruj okna propagacji

Ustawienia czasu życia (TTL) określają, jak długo rekurencyjne programy rozpoznające nazwy przechowują rekord DNS w pamięci podręcznej, zanim zwrócą się o nową kopię do autorytatywnego serwera nazw.

• Standardowe procedury: Ustaw domyślne wartości TTL w przedziale od 3 600 sekund (1 godzina) do 86 400 sekund (24 godziny). Pozwala to zrównoważyć obciążenie serwera i opóźnienia w realizacji zapytań.
• Przed migracją lub w ramach reagowania na incydent: należy obniżyć wartości TTL do 300 sekund (5 minut) co najmniej 24–48 godzin przed planowanymi zmianami w infrastrukturze.

Wcześniejsze skrócenie wartości TTL gwarantuje szybkie wygaśnięcie danych z pamięci podręcznej we wszystkich globalnych serwerach rozpoznających nazwy, jeśli zajdzie potrzeba przekierowania ruchu z serwera, na którym wystąpiła awaria. Rozprzestrzenianie się zmian w globalnych serwerach rozpoznających nazwy można monitorować za pomocą narzędzia do sprawdzania propagacji DNS w czasie rzeczywistym.

9. Szyfrowanie transmisji między klientem a serwerem rozpoznającym (DoH / DoT / DoQ)

Standardowe zapytania DNS przesyłane w postaci zwykłego tekstu przez port UDP 53 ujawniają nawyki przeglądania stron przez klientów lokalnym podglądaczom, nieuczciwym operatorom sieci Wi-Fi oraz dostawcom usług internetowych zapewniającym tranzyt. Szyfrowanie ścieżki zapytania chroni prywatność użytkownika końcowego i zapobiega manipulacjom w sieci lokalnej.

Nowoczesne sieci korporacyjne obsługują trzy główne standardy szyfrowanego przesyłu danych:

• DNS over TLS (DoT) – Działa na dedykowanym porcie TCP 853. Protokół DoT jest powszechnie stosowany do zabezpieczania transmisji danych między wewnętrznymi punktami końcowymi, lokalnymi serwerami rekursywnymi oraz serwerami nadrzędnymi.
• DNS przez HTTPS (DoH) – hermetyzuje zapytania DNS w ruchu HTTPS na porcie 443, dzięki czemu ruchu związanego z zapytaniami nie da się odróżnić od zwykłego ruchu internetowego.
• DNS przez QUIC (DoQ) – Wykorzystuje protokół QUIC w celu skrócenia opóźnień i poprawy wydajności w przypadku niestabilnych połączeń sieciowych.

Wdrażając szyfrowany DNS w środowiskach korporacyjnych, należy skonfigurować lokalne punkty końcowe klientów za pomocą narzędzi do zarządzania urządzeniami mobilnymi (MDM) tak, aby korzystały z wyznaczonych wewnętrznych, szyfrowanych serwerów rozpoznawania nazw. Należy zablokować w sieciowej zaporze ogniowej nieautoryzowany ruch wychodzący DoT (port 853) oraz publiczne punkty końcowe DoH, aby uniemożliwić aplikacjom ominięcie lokalnego rejestrowania zdarzeń bezpieczeństwa.

10. Zabezpieczenie lokalnego programu do rozpoznawania adresów oraz oprogramowania serwera nazw

Jeśli Twoja organizacja korzysta z własnych rekurencyjnych serwerów nazw lub wewnętrznych instancji BIND, Unbound lub PowerDNS, należy przestrzegać rygorystycznych zasad zabezpieczania serwerów:

• Ogranicz rekurencyjne rozpoznawanie adresów do autoryzowanych wewnętrznych zakresów adresów IP. Otwarte serwery rozpoznawania adresów w publicznej sieci internetowej są często wykorzystywane w atakach typu DDoS z amplifikacją.
• Należy wdrożyć minimalizację QNAME i skonfigurować serwery rozdzielające tak, aby wysyłały do nadrzędnych serwerów autorytatywnych jedynie minimalnie wymagane etykiety domen (RFC 7816). Zapobiega to ujawnianiu pełnych nazw hostów docelowych serwerom autorytatywnym poziomu korzeniowego.
• Główne serwery autorytatywne należy umieścić za ukrytymi adresami IP, które nie figurują w publicznych zestawach rekordów NS. Publiczne serwery pomocnicze pobierają aktualizacje strefy z ukrytego serwera głównego.

11. Wdrożenie stref regulacji ciśnienia (RPZ)

Strefy polityki reagowania, często nazywane zaporami DNS, umożliwiają administratorom rekurencyjnych serwerów rozpoznających nazwy nakładanie niestandardowych źródeł informacji o zagrożeniach na standardowy proces rozpoznawania nazw.

Gdy urządzenie klienckie próbuje przeprowadzić wyszukiwanie domeny, o której wiadomo, że zawiera złośliwe oprogramowanie, serwery typu „command-and-control” (C2) lub strony phishingowe, reguły RPZ przerywają to wyszukiwanie. Moduł rozpoznający domeny zwraca odpowiedź NXDOMAIN lub przekierowuje użytkownika na wewnętrzną stronę blokującą.

12. Wprowadź protokoły uwierzytelniania wiadomości e-mail: SPF, DKIM i DMARC

Protokoły uwierzytelniania wiadomości e-mail to rekordy DNS. Bez wdrożenia protokołów SPF, DKIM i DMARC osoba atakująca może sfałszować tożsamość Twojej domeny w wiadomościach phishingowych, nawet jeśli Twój rejestrator i serwery nazw są całkowicie zabezpieczone.

Monitorowanie DNS: praktyka, którą większość zespołów pomija

Zespoły ds. bezpieczeństwa często wykrywają manipulacje w systemie DNS dopiero po zgłoszeniu przez dział obsługi klienta awarii witryny lub zakłóceń w przepływie wiadomości e-mail. Pasywne konfiguracje powodują powstanie ogromnych „martwych punktów”.

Skuteczne monitorowanie DNS wymaga trzech aktywnych mechanizmów kontroli:

1. Zautomatyzowane monitorowanie integralności plików strefowych: Skonfiguruj automatyczne moduły monitorujące, które przez całą dobę, siedem dni w tygodniu śledzą stan Twoich autorytatywnych plików strefowych. Twój zespół powinien otrzymywać natychmiastowe powiadomienia w przypadku nieoczekiwanych zmian w kluczowych rekordach (takich jak rekordy NS, MX, A lub rekordy TXT poziomu głównego).
2. Powiadomienia o zmianach rekordów MX i NS: Zmiana rekordu MX umożliwia atakującemu przekierowanie przychodzącej poczty przez swoje serwery w celu pozyskania poufnych tokenów służących do resetowania haseł. Powiadomienia o zmianach rekordów MX i NS powinny uruchamiać natychmiastowe procedury postępowania w przypadku incydentów o wysokim priorytecie.
3. Analiza dzienników zapytań DNS: Zintegruj dzienniki systemu Protective DNS (PDNS) z platformą do zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM). Korelacja dzienników zapytań DNS z historią dzierżaw DHCP pozwala analitykom prześledzić złośliwe wyszukiwania domen aż do zainfekowanych urządzeń wewnętrznych.

Uwierzytelnianie wiadomości e-mail jako mechanizm kontroli DNS

Częstym błędem w zakresie bezpieczeństwa DNS jest oddzielanie mechanizmów kontroli ruchu internetowego od mechanizmów kontroli poczty elektronicznej. Protokoły SPF, DKIM i DMARC opierają się wyłącznie na rekordach TXT w systemie DNS w celu publikowania kluczy publicznych i zasad dotyczących nadawców.

• SPF: Publikuje listę adresów IP i serwerów pocztowych uprawnionych do wysyłania wiadomości wychodzących w imieniu Twojej domeny.
• DKIM: Dodaje podpisy kryptograficzne do nagłówków wychodzących wiadomości e-mail. Odbiorcy pobierają odpowiedni klucz publiczny z serwerów DNS Twojej domeny, aby sprawdzić, czy treść wiadomości nie została zmieniona podczas przesyłania.
• DMARC: Łączy protokoły SPF i DKIM. DMARC określa, w jaki sposób serwery pocztowe odbierające mają postępować z wiadomościami e-mail, które nie przeszły uwierzytelnienia.

Ustawienie polityki na wartość „p=reject” powoduje, że serwery pocztowe odbierające wiadomości automatycznie odrzucają nieautoryzowane wiadomości. Zrozumienie swojej aktywnej polityki DMARC pozwala chronić reputację marki w sieciach odbiorczych na całym świecie.

Możesz natychmiast sprawdzić aktualny stan uwierzytelniania poczty e-mail, korzystając z internetowego narzędzia do sprawdzania rekordów DMARC.

Chociaż protokół DMARC zapobiega podszywaniu się pod domeny w wiadomościach e-mail, należy pamiętać, że nie chroni on przed zatruwaniem pamięci podręcznej ani przejęciem subdomen. Kompleksowa strategia obronna wymaga wzmocnienia zarówno sieciowego systemu rozpoznawania adresów DNS, jak i rekordów DNS poczty elektronicznej.

Zarządzany system DNS i filtrowanie na poziomie DNS: gdzie mają zastosowanie

Współczesne przedsiębiorstwa często wdrażają zarządzane platformy DNS oraz filtrowanie zabezpieczeń na poziomie warstwy DNS w celu uproszczenia operacji i zwiększenia widoczności zagrożeń.

Renomowani dostawcy usług zarządzanego DNS

Dostawcy usług DNS typu managed dla przedsiębiorstw obsługują globalne sieci Anycast, które rozdzielają autorytatywny plik strefy użytkownika między setki lokalizacji brzegowych. Infrastruktura Anycast zapewnia wbudowaną ochronę przed atakami DDoS, pochłaniając potężne ataki objętościowe, zanim dotrą one do sieci rdzeniowej użytkownika. Platformy typu managed automatyzują również zarządzanie kluczami DNSSEC oraz utrzymanie rekordów DNS.

Rekurencyjne filtrowanie na poziomie DNS (ochronny DNS)

Rozwiązania z zakresu ochronnego systemu DNS (PDNS) działają na poziomie rekurencyjnego serwera rozdzielczego. Zamiast po prostu odpowiadać na zapytania, rozwiązania PDNS sprawdzają każde żądanie w dynamicznych bazach danych zawierających informacje o zagrożeniach.

Jeśli pracownik kliknie link prowadzący do nowo zarejestrowanej domeny phishingowej lub zainfekowany ładunek spróbuje nawiązać połączenie z serwerem C2, ochronny resolver blokuje rozpoznawanie adresu na warstwie sieciowej.

Ani zarządzany system DNS, ani filtrowanie DNS nie zastępują dbałości o porządek u rejestratora domen ani prawidłowej konfiguracji rekordów. Stanowią one uzupełniające się warstwy w ramach szerszej architektury bezpieczeństwa opartej na modelu „Zero Trust”.

Od czego zacząć audyt: plan działania z ustalonymi priorytetami

Jeśli Twój zespół ds. bezpieczeństwa nie jest w stanie zrealizować wszystkich dwunastu punktów z listy kontrolnej w tym kwartale, skup się najpierw na działaniach o największym znaczeniu. Wykonaj te pięć zadań w podanej kolejności:

1. Należy włączyć opcję „clientTransferProhibited” oraz blokady rejestru we wszystkich domenach głównych. Należy wprowadzić wymóg stosowania kluczy sprzętowych zgodnych ze standardem FIDO2 przez wszystkich użytkowników kont u rejestratorów, aby wyeliminować ryzyko przejęcia kontroli nad kontem.
2. Ogranicz transfery stref AXFR poprzez monitorowanie autorytatywnych serwerów nazw, aby natychmiast zablokować nieograniczone transfery stref.
3. Zrób spis wszystkich opublikowanych rekordów CNAME, porównaj je z aktywnymi zasobami w chmurze i usuń wszystkie osierocone wpisy.
4. Skonfiguruj automatyczne powiadomienia dotyczące rekordów MX i NS, uruchamiając ciągłe monitorowanie rekordów strefy głównej, dzięki czemu Twój zespół będzie natychmiast powiadamiany o nieautoryzowanych zmianach.
5. Sprawdź aktywne źródła poczty, usuń rozbieżności w konfiguracji i zaktualizuj swoją politykę DMARC, aby odrzucać wiadomości wysłane pod fałszywym adresem.

Najczęściej zadawane pytania

Czym jest bezpieczeństwo DNS w uproszczeniu?

Bezpieczeństwo DNS obejmuje protokoły techniczne, mechanizmy kontroli dostępu oraz praktyki administracyjne stosowane w celu ochrony systemu rozpoznawania nazw domen. Gwarantuje ono, że gdy użytkownicy wpisują nazwę domeny w przeglądarce, łączą się z prawdziwymi serwerami, a nie ze złośliwą stroną stworzoną przez atakującego.

Czy protokół DNSSEC szyfruje ruch DNS?

Nie, protokół DNSSEC nie szyfruje zapytań ani odpowiedzi DNS. Standardowe zapytania DNSSEC są przesyłane w postaci zwykłego tekstu. Protokół DNSSEC wykorzystuje podpisy cyfrowe do weryfikacji, czy otrzymane dane DNS są autentyczne i nie zostały zmienione podczas przesyłania. Aby zaszyfrować ruch związany z zapytaniami DNS, należy wdrożyć protokół DNS over HTTPS (DoH), DNS over TLS (DoT) lub DNS over QUIC (DoQ).

Jaka jest różnica między protokołem DNSSEC a protokołem DNS over HTTPS (DoH)?

DNSSEC potwierdza integralność danych na poziomie strefy, gwarantując, że odpowiedź pochodzi od prawdziwego właściciela domeny i nie została zmodyfikowana. DoH szyfruje ścieżkę transmisji między urządzeniem użytkownika końcowego a rekurencyjnym serwerem rozpoznawczym.

Czy przejęcie DNS to to samo, co sfałszowanie DNS?

Nie. Przejęcie kontroli nad DNS polega na uzyskaniu nieuprawnionego dostępu administracyjnego u rejestratora domeny lub dostawcy serwerów nazw w celu zmiany oficjalnych ustawień DNS. Fałszowanie DNS (lub zatruwanie pamięci podręcznej) polega na nakłonieniu rekurencyjnego serwera rozpoznającego adresy do zapisania fałszywych adresów IP w swojej pamięci podręcznej bez zmiany oficjalnych ustawień u rejestratora.

Jak mogę sprawdzić, czy system DNS mojej domeny został naruszony?

Do typowych sygnałów ostrzegawczych należą: nieoczekiwane przekierowania ze strony internetowej, nagły spadek skuteczności dostarczania wiadomości e-mail, nieautoryzowane certyfikaty TLS wydane dla danej domeny lub nieoczekiwane zmiany w rekordach NS, A lub MX wykryte podczas rutynowych kontroli.

Czy SPF, DKIM i DMARC zaliczają się do zabezpieczeń DNS?

Tak. Rekordy SPF, DKIM i DMARC są publikowane bezpośrednio w publicznej strefie DNS Twojej domeny. Ponieważ serwery pocztowe odbierające wysyłają zapytania do systemu DNS w celu zweryfikowania autentyczności nadawcy wiadomości, prawidłowe rekordy uwierzytelniające wiadomości e-mail stanowią kluczowy element zabezpieczeń DNS domeny.

Wniosek

Bezpieczeństwo DNS to nie tylko pojedynczy produkt, który można kupić i zainstalować. Jest to wielopoziomowy zestaw działań obejmujący zarządzanie rejestratorem domen, wzmocnienie zabezpieczeń autorytatywnych serwerów nazw, szyfrowanie transmisji zapytań oraz sprawdzanie integralności rekordów.

Brak monitorowania którejkolwiek warstwy stwarza cyberprzestępcom możliwość przejęcia ruchu sieciowego, przeprowadzenia ataków typu „man-in-the-middle” lub sfałszowania komunikacji firmowej.

Już dziś zacznij wzmacniać bezpieczeństwo infrastruktury swojej domeny, przeprowadzając pełną inwentaryzację aktywnych plików strefy. Skorzystaj z bezpłatnej wyszukiwarki rekordów DNS, aby sprawdzić opublikowane rekordy, a także przetestuj swoją domenę za pomocą narzędzia do sprawdzania rekordów DMARC, aby zapewnić ochronę swojej marki.

• O
• Latest Posts

Milena Baghdasaryan

Specjalista ds. treści w PowerDMARC

Milena jest wykwalifikowaną pisarką i twórczynią treści z ponad 7-letnim doświadczeniem w tworzeniu angażujących treści na temat IT, cyberbezpieczeństwa, wirtualnych wydarzeń i nie tylko. Ma udokumentowane doświadczenie w dostarczaniu wysokiej jakości prac dla międzynarodowych magazynów i jest absolwentką prestiżowych instytucji, takich jak New York University Abu Dhabi, UWC China i College of Europe.

Najnowsze posty autorstwa Milena Baghdasaryan (zobacz wszystkie)

• Najlepsze praktyki w zakresie bezpieczeństwa DNS: kompletna lista kontrolna dotycząca wzmocnienia zabezpieczeń – 7 września 2026 r.
• Dynamiczny SPF, automatyczny SPF czy hostowany SPF: który z nich faktycznie naprawia Twój rekord SPF? – 25 sierpnia 2026 r.
• „Odpowiedz” a „Odpowiedz wszystkim”: zasady etykiety i zagrożenia dla bezpieczeństwa – 14 sierpnia 2026 r.