Bezpieczeństwo DNS to zbiór środków kontroli, które zapewniają poprawność, dostępność i kontrolę nad systemem DNS Twojej domeny, dzięki czemu osoby atakujące nie mogą przekierowywać ruchu, podszywać się pod Twoją domenę ani spowodować jej wyłączenia.
Poniżej wyjaśniamy, dlaczego bezpieczeństwo DNS ma fundamentalne znaczenie dla nowoczesnej infrastruktury, wyjaśniamy różnicę między ogólnym bezpieczeństwem DNS a protokołem DNSSEC, przedstawiamy praktyczną 12-punktową listę kontrolną dotyczącą wzmocnienia zabezpieczeń oraz opracowujemy plan z ustalonymi priorytetami, wskazujący, co należy naprawić w pierwszej kolejności.
Czym jest bezpieczeństwo DNS?
DNS działa w tle każdego żądania internetowego, wywołania API i dostarczenia wiadomości e-mail, jednak został stworzony bez wbudowanego uwierzytelniania ani weryfikacji kryptograficznej. Bezpieczeństwo DNS obejmuje zasady, konfiguracje, protokoły i praktyki monitorowania niezbędne do ochrony nazw domen i infrastruktury serwerów nazw przed nieuprawnioną ingerencją, podsłuchem i zakłóceniami w działaniu.
Skuteczne zabezpieczenie systemu DNS wymaga nie tylko jednego narzędzia, ale także ochrony na czterech odrębnych warstwach operacyjnych:
- Warstwa rejestratora: Elementy kontroli zapewniające bezpieczeństwo rejestracji domeny, danych dotyczących własności domeny oraz danych uwierzytelniających dostępu administracyjnego, aby zapobiegać nieuprawnionemu przejęciu konta.
- Warstwa autorytatywnych serwerów nazw: Środki zabezpieczające zastosowane w serwerach autorytatywnych, na których hostowane są publiczne pliki strefowe, zapewniające niezawodną dostępność, nadmiarowość oraz kontrolowane transfery stref.
- Warstwa protokołów i warstwa transportowa: Środki stosowane w odniesieniu do rekurencyjnych serwerów rozpoznawania nazw oraz ruchu zapytań, chroniące żądania wyszukiwania przed podsłuchem na trasie, modyfikacją oraz manipulacją lokalną pamięcią podręczną.
- Warstwa rekordów i tożsamości: Rekordy kryptograficzne i zasady bezpieczeństwa opublikowane w Twojej strefie, w tym podpisy DNSSEC, zasady autoryzacji urzędów certyfikacji (CA) oraz standardy uwierzytelniania poczty elektronicznej.
Większość naruszeń bezpieczeństwa ma swój początek w słabym punkcie jednej z tych warstw, któremu można było zapobiec. Zrozumienie, w jaki sposób warstwy te współdziałają, pomaga zespołom ds. bezpieczeństwa wyeliminować ukryte luki w zabezpieczeniach DNS , zanim złośliwi użytkownicy je wykryją i wykorzystają. Organizacje stosujące formalne programy zgodności mogą również zapoznać się z wytyczne NIST dotyczące bezpieczeństwa DNS dotyczących federalnych wymagań podstawowych.
Dlaczego bezpieczeństwo DNS jest ważne?
Ponieważ podstawowy protokół systemu nazw domenowych (DNS) przesyła zapytania w postaci zwykłego tekstu bez kryptograficznej weryfikacji pochodzenia, surowy ruch DNS z natury rzeczy opiera się na zaufaniu do otrzymywanych odpowiedzi. Organizacje często przeznaczają znaczne środki na zapory sieciowe, zapory aplikacji internetowych (WAF) oraz agenty wykrywające na punktach końcowych, pozostawiając jednocześnie swoje strefy DNS w dużej mierze bez nadzoru.
Gdy atakujący manipulują systemem DNS, całkowicie omijają zabezpieczenia obwodowe. Przejęcie kontroli nad strefą DNS pozwala atakującemu przekierowywać korporacyjny ruch internetowy na złośliwe repliki, wydawać ważne certyfikaty TLS w imieniu Twojej marki lub przechwytywać poufną korespondencję e-mailową, nie mając przy tym żadnego dostępu do fizycznych serwerów sieciowych.
Bez kompleksowych zabezpieczeń DNS organizacje narażone są na poważne zagrożenia:
- Przejęcie kontroli nad DNS i przejęcie kontroli nad rejestratorem: Atakujący przejmują dane uwierzytelniające rejestratora lub wykorzystują socjotechnikę, aby przekierować autorytatywne serwery nazw na fałszywe hosty.
- Fałszowanie adresów DNS oraz zatrucie pamięci podręcznej: Atakujący wprowadzają fałszywe rekordy zasobów do podatnych na ataki rekurencyjnych serwerów nazw, przekierowując użytkowników do stron służących do wykradania danych uwierzytelniających.
- Wzmocnienie ataku DNS i DDoS: Wykorzystuje się otwarte rekurencyjne serwery nazw, aby odsyłać odpowiedzi o dużej objętości w kierunku ofiary, co powoduje przeciążenie przepustowości i unieruchomienie całych usług.
- Wiszące rekordy i przejęcie subdomeny: Osierocone rekordy DNS wskazujące na wyłączone zasoby w chmurze lub zasoby hostingowe są przejmowane przez podmioty zewnętrzne w celu umieszczania złośliwych treści pod marką użytkownika.
- Fałszowanie adresów e-mail poprzez słabe zapisy DNS: Brakujące lub nieprawidłowo skonfigurowane zasady SPF, DKIM i DMARC umożliwiają oszustom wysyłanie wiadomości e-mail typu spear phishing, które rzekomo pochodzą z domeny Twojej firmy.
Aby zapoznać się ze szczegółowym opisem metod ataków, zapoznaj się z naszym przewodnikiem po 10 rodzajów ataków na system DNSoraz przetestuj swoją domenę za pomocą naszego bezpłatnego narzędzia do sprawdzania DNSSEC.
Bezpieczeństwo DNS a DNSSEC
Częstym błędnym przekonaniem wśród zespołów IT jest traktowanie pojęć „bezpieczeństwo DNS” i „DNSSEC” jako synonimów. Nie są one jednak synonimami.
DNSSEC (Domain Name System Security Extensions) to konkretny środek techniczny w ramach szerszego systemu zabezpieczeń. DNSSEC wykorzystuje kryptografię klucza publicznego do cyfrowego podpisywania rekordów DNS w pliku strefy. Gdy program rozpoznający sprawdzający weryfikuje podpisaną domenę, porównuje podpis z łańcuchem zaufania prowadzącym do strefy korzeniowej, upewniając się, że otrzymana odpowiedź nie została zmieniona podczas przesyłania.
Kompleksowe zabezpieczenia DNS obejmują cały cykl zarządzania oraz architekturę ochronną. Chociaż protokół DNSSEC zapewnia autentyczność i integralność rekordów, nie eliminuje on wszystkich zagrożeń:
- DNSSEC nie szyfruje ruchu związanego z zapytaniami ani nie zapewnia poufności przed osobami podsłuchującymi.
- DNSSEC nie powstrzymuje atakujących, którzy przejmują kontrolę nad kontem u rejestratora i zmieniają publiczne rekordy delegacji.
- DNSSEC nie ogranicza ataków DDoS typu wolumetrycznego ani nie zapobiega udziałowi otwartych serwerów nazw w burzach amplifikacyjnych.
- DNSSEC nie wykrywa nieaktualnych rekordów CNAME wskazujących na wycofane zasoby chmurowe stron trzecich.
DNSSEC stanowi obowiązkowy element wzmocnionej infrastruktury, ale musi funkcjonować w połączeniu z blokadami rejestratorów, szyfrowaniem transmisji, rygorystyczną kontrolą poczty elektronicznej oraz ciągłym monitorowaniem stref. Dowiedz się więcej o tym, jak działa weryfikacja kryptograficzna, z naszego przewodnika po DNSSEC.
Najlepsze praktyki w zakresie bezpieczeństwa DNS: lista kontrolna dotycząca wzmacniania zabezpieczeń
Zabezpieczenie domeny wymaga uporządkowanych i powtarzalnych praktyk operacyjnych. Poniższa lista kontrolna obejmuje 12 kluczowych środków kontroli, pogrupowanych według warstw infrastruktury i stopnia złożoności wdrożenia.
| Najlepsze praktyki | Warstwa | Poziom wysiłku |
|---|---|---|
| Zabezpiecz swoją domenę na poziomie rejestratora | Sekretarz | Niski |
| Wprowadź uwierzytelnianie wieloskładnikowe (MFA) oraz dostęp oparty na rolach w swojej firmie zajmującej się rejestracją domen | Sekretarz | Niski |
| Ograniczenie transferów strefowych (AXFR) | Serwer nazw | Niski |
| Wdrożenie redundantnych serwerów nazw pełniących funkcję serwerów autorytatywnych | Serwer nazw | Średni |
| Wdrożenie protokołu DNSSEC z wykorzystaniem nowoczesnej kryptografii | Rejestr i tożsamość | Średni |
| Opublikuj rekord autoryzacji urzędu certyfikacji (CAA) | Rejestr i tożsamość | Niski |
| Kontrola w zakresie rekordów „wiszących” i „osieroconych” | Rejestr i tożsamość | Średni |
| Ustaw odpowiednie wartości TTL i monitoruj okna propagacji | Serwer nazw | Niski |
| Szyfrowanie transmisji między klientem a serwerem rozpoznającym (DoH / DoT / DoQ) | Rozdzielczość i transport | Średni |
| Zabezpieczenie lokalnego modułu rozpoznawania adresów i oprogramowania serwera nazw | Rozdzielczość i transport | High |
| Wdrożenie stref regulacji ciśnienia (RPZ) | Rozdzielczość i transport | Średni |
| Wprowadź protokoły uwierzytelniania wiadomości e-mail: SPF, DKIM i DMARC | Rejestr i tożsamość | Średni |
1. Zabezpiecz swoją domenę na poziomie rejestratora
Nieautoryzowane żądania transferu stanowią jedno z największych zagrożeń dla kluczowych zasobów domeny. Zastosuj clientTransferProhibited oraz clientUpdateProhibited do swoich domen.
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 uwierzytelnianie wieloskładnikowe oparte na sprzęcie uwierzytelnianie wieloskładnikowe (MFA) z wykorzystaniem kluczy bezpieczeństwa 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:
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, poddając ją analizie za pomocą specjalnego narzędzia narzędzia do sprawdzania DNSSEC.
6. Opublikuj rekord autoryzacji urzędu certyfikacji (CAA)
A rekord CAA umożliwia właścicielom domen określenie, które urzędy certyfikacji (CA) są uprawnione do wydawania cyfrowych certyfikatów TLS dla ich domen i subdomen.
Przed wydaniem certyfikatu publiczne urzędy certyfikacji muszą sprawdzić w systemie DNS domeny, czy istnieją rekordy CAA. Jeśli rekord CAA istnieje, tylko wyznaczone podmioty (na przykład Let’s Encrypt lub DigiCert) mogą realizować wnioski o wydanie certyfikatu. Zapobiega to sytuacji, w której nieuczciwi pracownicy lub zainfekowane systemy stron trzecich składają wnioski o nieautoryzowane certyfikaty za pośrednictwem niezatwierdzonych dostawców.
W rekordzie CAA umieść tag „iodef”, wskazujący na aktywną skrzynkę pocztową osoby kontaktowej ds. bezpieczeństwa, aby otrzymywać natychmiastowe powiadomienia w przypadku, gdy nieautoryzowany certyfikator otrzyma żądanie certyfikatu dla Twojej domeny. Sprawdź poprawność składni rekordu za pomocą naszego narzędzia do sprawdzania rekordów CAA.
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, korzystając z niezawodnego narzędzia do wyszukiwania . Należy sprawdzić różne rodzajó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 operacje: Ustaw domyślne wartości TTL w zakresie 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 przypadku reagowania na incydent: Zmniejsz 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. Można monitorować, w jaki sposób zmiany rozprzestrzeniają się wśród globalnych serwerów rozpoznających nazwy, korzystając z narzędzia do sprawdzania propagacji DNS w czasie rzeczywistym narzędzia do sprawdzania propagacji DNS.
9. Szyfrowanie transmisji między klientem a serwerem rozpoznającym (DoH / DoT / DoQ)
Standardowe zapytania DNS są przesyłane w postaci niezaszyfrowanego tekstu przez port 53 protokołów UDP i TCP, co naraża użytkowników na lokalną inwigilację, śledzenie przez dostawców usług internetowych, podsłuchiwanie oraz manipulację danymi na poszczególnych przeskokach w sieci lokalnej.
Nowoczesne protokoły zabezpieczają odcinek transmisji między klientem a serwerem rozpoznającym domeny przy użyciu sprawdzonych rozwiązań kryptograficznych:
- DNS przez HTTPS (DoH): Opakowuje żądania DNS w standardowe sesje HTTPS na porcie 443, ukrywając ruch związany z zapytaniami wśród rutynowych żądań internetowych.
- DNS przez TLS (DoT): Kieruje zapytania DNS przez dedykowany, szyfrowany tunel TLS na porcie 853, izolując transakcje DNS i zapewniając jednocześnie silne uwierzytelnianie punktów końcowych. Aby zrozumieć, w jaki sposób protokoły szyfrujące chronią strumienie transportowe, przeczytaj nasz przewodnik na temat różnicy między SSL a TLS.
- DNS przez QUIC (DoQ): Przesyła zapytania przez protokół QUIC (port UDP 853), minimalizując obciążenie związane z nawiązywaniem połączenia i eliminując blokowanie na początku kolejki.
Skonfiguruj wewnętrzne punkty końcowe przedsiębiorstwa, systemy operacyjne oraz lokalne serwery przekazujące w sieci tak, aby przekierowywały zapytania o rozpoznawanie adresów wyłącznie przez bezpieczne serwery rozpoznawania adresów, które wymuszają stosowanie protokołów DoH lub DoT.
10. Zabezpieczenie lokalnego programu do rozpoznawania adresów oraz oprogramowania serwera nazw
Jeśli Twoja organizacja utrzymuje wewnętrzne serwery rozdzielające działające rekurencyjnie lub zarządza dedykowanymi instancjami autorytatywnych serwerów nazw przy użyciu oprogramowania BIND, Unbound, PowerDNS lub usługi DNS systemu Windows Server, należy stosować rygorystyczne praktyki wzmacniania bezpieczeństwa systemu:
- Wyłącz otwartą rekurencję: Należy upewnić się, że rekurencyjne serwery nazw przetwarzają wyłącznie zapytania pochodzące z zaufanych zakresów adresów sieci wewnętrznej. Pozostawienie serwerów nazw otwartych na dowolne zapytania z Internetu naraża infrastrukturę na ataki amplifikacyjne przeprowadzane za pośrednictwem otwartych serwerów nazw.
- Oddzielne role: Nigdy nie należy uruchamiać autorytatywnego hostingu i rekurencyjnego rozpoznawania nazw na tej samej instancji oprogramowania serwerowego.
- Stosuj aktualizacje zabezpieczeń na bieżąco: Zapisz się do list z poradami dotyczącymi bezpieczeństwa od dostawców oprogramowania. W starszych pakietach DNS regularnie wykrywane są luki w zabezpieczeniach, takie jak błędy pamięci podręcznej, błędy bufora i wycieki pamięci. Na bieżąco śledź i aktualizuj oprogramowanie DNS, które nie zostało jeszcze załatane.
- Ukrywanie wersji oprogramowania: Wyłącz publiczne zapytania o wersję (takie jak zapytanie CHAOS TXT „version.bind” w BIND), aby uniemożliwić skanerom rozpoznawczym uzyskanie informacji o konkretnej kompilacji oprogramowania.
- Włącz ograniczenie częstotliwości odpowiedzi (RRL): Wprowadź RRL na serwerach autorytatywnych, aby ograniczyć szybkie, powtarzające się zalewy zapytań skierowanych do identycznych domen, co ograniczy udział w atakach typu reflection.
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 rozpoznać domenę, o której wiadomo, że zawiera złośliwe oprogramowanie, serwery dowodzenia i kontroli (C2) lub strony phishingowe, reguły RPZ przerywają proces wyszukiwania. Moduł rozpoznawania zwraca kod odpowiedź typu NXDOMAIN lub przekierowuje użytkownika na wewnętrzną stronę blokującą.
12. Wprowadź protokoły uwierzytelniania wiadomości e-mail: SPF, DKIM i DMARC
Uwierzytelnianie wiadomości e-mail odbywa się bezpośrednio za pośrednictwem specjalnych rekordów TXT opublikowanych w strefie DNS. Bez odpowiednio skonfigurowanych rekordów e-mailowych każdy zewnętrzny nadawca może wysyłać fałszywe wiadomości e-mail, podając jako źródło Twoją nazwę domeny.
Kompleksowa strategia ochrony poczty elektronicznej wymaga trzech powiązanych ze sobą standardów:
- SPF (Sender Policy Framework): Publikuje autoryzowaną listę adresów IP serwerów oraz zewnętrznych dostawców usług przekaźnikowych, którzy mają prawo wysyłać wiadomości e-mail w imieniu Twojej domeny. Zapoznaj się z podstawowymi pojęciami w naszym przewodniku dotyczącym SPF, DKIM i DMARC.
- DKIM (DomainKeys Identified Mail): Wykorzystuje kryptografię klucza publicznego do dołączania podpisu cyfrowego do nagłówków wychodzących wiadomości e-mail. Klucz publiczny publikuje się w strefie DNS, co pozwala odbiorcom zweryfikować, czy treść wiadomości nie została zmieniona podczas przesyłania.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Ujednolica protokoły SPF i DKIM w ramach scentralizowanej polityki opublikowanej w pliku _dmarc. DMARC zapewnia wgląd w aktywność wysyłkową i instruuje serwery pocztowe odbiorców, jak postępować z wiadomościami e-mail, które nie są zgodne z polityką.
Przejście na obowiązkową polityki DMARC (p=quarantine lub p=reject) gwarantuje, że serwery pocztowe odbiorców odrzucają lub izolują nieautoryzowane wiadomości wysyłane pod Twoją tożsamością. Sprawdź swoją aktualną konfigurację za pomocą naszego narzędzia do sprawdzania rekordów DMARCi postępuj zgodnie z naszym przewodnikiem technicznym, aby opublikować rekord DMARC.
Monitorowanie DNS: praktyka, którą większość zespołów pomija
Wdrażanie środków bezpieczeństwa nie jest działaniem jednorazowym. Rekordy DNS ulegają z czasem zmianom, ponieważ zespoły uruchamiają tymczasowe kampanie marketingowe, dostosowują dostawców usług poczty elektronicznej, zmieniają delegatów serwerów nazw oraz wycofują przestarzałą infrastrukturę. Bez zautomatyzowanego monitorowania nieautoryzowane zmiany lub niezamierzone błędy w konfiguracji mogą pozostawać niewykryte przez wiele miesięcy.
Systematyczny proces monitorowania DNS powinien na bieżąco śledzić:
- Zmiany dotyczące serwerów nazw i delegacji: Natychmiastowe wykrywanie modyfikacji rekordów NS lub rekordów typu „glue” w strefie nadrzędnej, które mogą wskazywać na przejęcie konta.
- Odchylenia w ustawieniach MX i SPF: Wgląd w nowo opublikowaną korespondencję e-mailową lub zmiany w mechanizmach nadawców SPF.
- Stan weryfikacji DNSSEC: Zautomatyzowane kontrole potwierdzające, że podpisy kluczy, rekordy RRSIG i łańcuchy DS pozostają aktywne i nie wygasły.
- Wykorzystanie luki w zabezpieczeniach funkcji Zone Transfer: Rejestrowanie powtarzających się prób wysyłania żądań transferu AXFR z zewnętrznych, nieautoryzowanych sieci.
- Rejestracja i wygaśnięcie certyfikatów: Proaktywne śledzenie terminów odnowienia domen oraz okresów ważności publicznych certyfikatów SSL/TLS w celu zapobiegania przypadkowym utratom.
- Aktywacje domen podobnych: Monitorowanie nowo zarejestrowanych domen zawierających homografy lub błędy ortograficzne, które tworzą aktywne rekordy MX w celu podszywania się pod Twoją markę.
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
Wprowadzenie poprawek w portfelu domen w odniesieniu do wszystkich 12 punktów z listy kontrolnej może wydawać się przytłaczającym zadaniem. Postępuj zgodnie z poniższym harmonogramem ustalonym według priorytetów, aby najpierw zająć się krytycznymi lukami w zabezpieczeniach:
- Dzień 1: Zabezpieczenie własności konta
- Włącz uwierzytelnianie wieloskładnikowe (MFA) oparte na sprzęcie w portalu rejestratora domen.
- Włącz blokadę rejestratora dla wszystkich zarejestrowanych domen.
- Usuń nieaktywne, nieprzypisane konta administratorów.
- Dzień 2: Zabezpieczenie trasy ruchu podstawowego
- Ogranicz transfery stref (AXFR) wyłącznie do zweryfikowanych serwerów nazw drugorzędnych.
- Przeszukaj swoje publiczne pliki stref pod kątem nieprzypisanych rekordów CNAME, A lub NS, które wskazują na nieprzypisane usługi w chmurze.
- Należy wyłączyć rekurencję otwartą na wszystkich korporacyjnych serwerach nazw połączonych z Internetem.
- Tydzień 1: Wdrożenie tożsamości kryptograficznej
- Opublikuj rekord CAA, w którym wskażesz wybrane przez siebie urzędy certyfikacji.
- Skonfiguruj i podpisz swoje strefy produkcyjne przy użyciu nowoczesnych algorytmów DNSSEC, zapewniając, że rekordy DS zostaną potwierdzone w rejestrze nadrzędnym.
- Tydzień 2: Wprowadzenie uwierzytelniania wiadomości e-mail
- Sprawdź swoje aktywne mechanizmy SPF i usuń dostawców, z których usług nie korzystasz.
- Wprowadź klucze DKIM we wszystkich bramkach poczty wychodzącej.
- Opublikuj rekord DMARC i skonfiguruj raportowanie w celu monitorowania zgodności procesu uwierzytelniania.
- W trakcie realizacji: Wprowadzenie ciągłego monitorowania
- Automatycznie śledź zmiany w historii, daty wygaśnięcia certyfikatów oraz stan poprawności podpisów DNSSEC.
Nie wiesz, na czym stoisz? Skorzystaj z naszego bezpłatnego narzędzie do analizy domeny , aby ocenić kondycję swojej domeny.
Najczęściej zadawane pytania
Jaka jest najważniejsza praktyka w zakresie bezpieczeństwa DNS?
Wprowadzenie rygorystycznych środków kontroli dostępu do rejestratora, w tym uwierzytelniania wieloskładnikowego opartego na sprzęcie oraz blokad rejestratora lub rejestru, jest najważniejszym ze wszystkich środków bezpieczeństwa. Jeśli osoba zła przejmie kontrolę nad kontem rejestratora, może całkowicie zastąpić autorytatywne serwery nazw, co sprawi, że wszystkie konfiguracje stref niższego szczebla oraz klucze DNSSEC staną się bezużyteczne.
Jak sprawdzić, czy mój serwer DNS został przejęty?
Oznaki przejęcia DNS obejmują nagły spadek ruchu na legalnych stronach internetowych, nieoczekiwane komunikaty ostrzegawcze dotyczące certyfikatów SSL/TLS wyświetlane użytkownikom, nieautoryzowane zmiany w dziennikach audytowych rejestratora, niewyjaśnione odrzucenia wiadomości e-mail oraz sytuacje, w których zewnętrzne serwery rozpoznawania nazw zwracają nieznane adresy IP dla danej domeny.
Czy zabezpieczenia DNS są niezbędne wyłącznie w przypadku dużych przedsiębiorstw?
Nie. Sprawcy cyberataków często atakują małe i średnie organizacje, ponieważ ich portale rejestracyjne i strefy DNS są często pozostawione bez nadzoru. Atakujący rutynowo przejmują domeny małych firm w celu prowadzenia kampanii phishingowych, hostowania złośliwych łańcuchów przekierowań oraz podszywania się pod kadrę kierowniczą przedsiębiorstw.
Czy protokół DNSSEC szyfruje zapytania DNS?
Nie. Protokół DNSSEC zapewnia integralność danych oraz kryptograficzne uwierzytelnianie pochodzenia, potwierdzając, że otrzymany rekord DNS pochodzi od prawowitego właściciela i nie został zmieniony podczas przesyłania. Nie szyfruje on jednak zapytań DNS ani nie zapewnia poufności. Szyfrowanie ruchu zapytań wymaga zastosowania protokołów transportowych, takich jak DNS over HTTPS (DoH) lub DNS over TLS (DoT).
Jaka jest różnica między zabezpieczeniami DNS typu autorytatywnego a rekurencyjnego?
Bezpieczeństwo autorytatywnego systemu DNS koncentruje się na ochronie opublikowanych rekordów domeny, dostępności serwerów nazw oraz plików strefowych, tak aby użytkownicy na całym świecie otrzymywali prawidłowe odpowiedzi dotyczące oferowanych usług. Bezpieczeństwo rekurencyjnego systemu DNS skupia się na ochronie urządzeń klienckich w sieci przed otrzymywaniem sfałszowanych odpowiedzi, blokowaniu złośliwych domen oraz szyfrowaniu połączeń z zewnętrznymi serwerami rozpoznającymi nazwy.
Jak często organizacja powinna przeprowadzać audyt swoich rekordów DNS?
Organizacje powinny przeprowadzać audyt plików stref publicznych co najmniej raz na kwartał w celu usunięcia nieaktualnych nazw hostów oraz wyeliminowania „wiszących” odnośników. Należy jednak codziennie uruchamiać automatyczne monitorowanie, aby na bieżąco wykrywać nieautoryzowane zmiany wpisów, modyfikacje serwerów nazw lub wygasające klucze DNSSEC.
Czy serwer DNS 1.1.1.1 jest bezpieczny?
Tak. Publiczny serwer DNS Cloudflare o adresie 1.1.1.1 jest bezpieczny i obsługuje nowoczesne, szyfrowane protokoły transportowe, w tym DNS over HTTPS (DoH), DNS over TLS (DoT) oraz weryfikację DNSSEC. Zapewnia również rygorystyczną ochronę prywatności, zobowiązując się do usuwania logów zapytań użytkowników w ciągu 24 godzin.
Czy zabezpieczenia DNS to to samo co VPN?
Nie. Sieć VPN (Virtual Private Network) tworzy zaszyfrowany tunel dla całego ruchu sieciowego między Twoim urządzeniem a zdalną siecią prywatną, ukrywając Twój adres IP przed serwerami docelowymi. Zabezpieczenia DNS chronią w szczególności proces przekształcania nazw domen na adresy IP, gwarantując, że Twoje zapytania są autentyczne, zabezpieczone przed manipulacją i odporne na spoofing.
Słowa końcowe
Zabezpieczenie systemu nazw domenowych (DNS) stanowi nieodzowny element współczesnych praktyk w zakresie cyberbezpieczeństwa. W przypadku braku odpowiedniego zarządzania system DNS stwarza rozległą powierzchnię ataku, która umożliwia atakującym ominięcie tradycyjnych zabezpieczeń punktów końcowych, zapór sieciowych i aplikacji internetowych.
Dzięki systematycznemu stosowaniu tej 12-punktowej listy kontrolnej dotyczącej zabezpieczeń, zabezpieczeniu konta u rejestratora, wdrożeniu protokołu DNSSEC oraz wprowadzeniu rygorystycznego uwierzytelniania wiadomości e-mail Twoja organizacja zapewni sobie solidną ochronę przed przejęciem ruchu, podszywaniem się pod markę oraz kosztownymi zakłóceniami w świadczeniu usług.