Luki w zabezpieczeniach systemu DNS: 10 typowych słabych punktów i sposoby ich usunięcia

Luka w zabezpieczeniach DNS to słaby punkt w konfiguracji, hostingu lub zarządzaniu usługą DNS domeny, który może zostać wykorzystany przez atakującego, np. otwarty serwer rozpoznający, brakujący podpis DNSSEC lub zapomniany rekord CNAME. Większość tych słabych punktów wynika raczej z błędów konfiguracji i nieaktualnych rekordów niż z wad oprogramowania, co oznacza, że można je wykryć i naprawić, zanim dojdzie do incydentu.

Czym są luki w zabezpieczeniach DNS?

Luka w zabezpieczeniach systemu DNS to wada operacyjna, architektoniczna lub konfiguracyjna w implementacji systemu nazw domenowych (DNS), która zagraża poufności, integralności lub dostępności ruchu sieciowego.

Słabe punkty te zazwyczaj występują na czterech kluczowych poziomach operacyjnych:

1. Rejestrator i zarządzanie kontami: Wspólne dane uwierzytelniające, brak uwierzytelniania wieloskładnikowego oraz brak blokad rejestru, co naraża kontrolę nad serwerami nazw na zagrożenie.
2. Autorytatywne serwery nazw: Liberalne zasady transferu stref, niezałatane demony serwerowe, brak limitów częstotliwości zapytań lub brak redundancji dostawców.
3. Serwery rozpoznawania nazw i transport: Rekursywne serwery nazw dostępne w publicznej sieci internetowej, niezaszyfrowana transmisja za pośrednictwem protokołu UDP w postaci zwykłego tekstu lub słabo losowe identyfikatory transakcji.
4. Wpisy DNS: Osierocone wpisy CNAME wskazujące na wycofaną z eksploatacji infrastrukturę, brakujące łańcuchy kryptograficzne DNSSEC lub brakujące wpisy dotyczące poczty elektronicznej i certyfikatów.

Ważne jest, aby odróżnić luki w zabezpieczeniach od ataków. Luka w zabezpieczeniach to podstawowa wada lub błędna konfiguracja występująca w danym systemie. Atak to celowe wykorzystanie tej słabości przez złośliwą stronę trzecią. Zrozumienie tej różnicy pozwala zespołom ds. bezpieczeństwa wyeliminować słabe punkty, zanim ataki DNS mają szansę się zmaterializować.

10 typowych luk w zabezpieczeniach systemu DNS

Poniższe dziesięć luk w zabezpieczeniach to najczęściej występujące problemy wykrywane w korporacyjnych wdrożeniach systemu DNS.

1. Otwarte serwery DNS {#open-dns-resolvers}

Otwarty serwer rekurencyjny to serwer DNS podłączony do publicznej sieci internetowej, który obsługuje zapytania rekurencyjne od wszystkich użytkowników, a nie ogranicza się wyłącznie do autoryzowanych klientów lokalnych.

• Co to umożliwia: Atakujący podszywają się pod adres IP źródłowy ofiary i wysyłają zapytania do otwartych serwerów DNS, generując ogromne ilości danych w odpowiedzi, które przeciążają ofiarę w ramach rozproszonego ataki typu DDoS z amplifikacją ataki typu DDoS z wykorzystaniem amplifikacji DNS.
• Jak to sprawdzić: Wykonaj zapytanie dotyczące adresu publicznego serwera z sieci zewnętrznej:

dig @<your-server-ip> example.com

• Jeśli serwer zwróci odpowiedź zawierającą ustawioną flagą „ra” (dostępna rekurencja), Twój program rozpoznający nazwy jest podatny na nieautoryzowaną rekurencję publiczną.
• Rozwiązanie: Całkowicie wyłącz rekurencję na serwerach autorytatywnych lub ogranicz ją do zaufanych zakresów adresów IP i podsieci, korzystając z list kontroli dostępu zgodnie z naszymi najlepsych praktyk w zakresie bezpieczeństwa DNS.

2. Brak lub uszkodzenie DNSSEC

DNSSEC (Domain Name System Security Extensions) wykorzystuje podpisy kryptograficzne do weryfikacji autentyczności danych DNS. Działanie bez DNSSEC lub dopuszczenie do sytuacji, w której konfiguracje kryptograficzne pozwalają na obejście wygasłych rekordów RRSIG lub niezgodnych rekordów DS u rejestratora, powoduje, że wyniki rozpoznawania pozostają niezweryfikowane.

• Co to umożliwia: Bez weryfikacji kryptograficznej rekurencyjne programy rozpoznające nazwy mogą akceptować sfałszowane pakiety odpowiedzi wprowadzone przez atakujących na ścieżce sieciowej, co prowadzi do zatruciem pamięci podręcznej i przekierowanie ruchu.
• Jak to sprawdzić: Sprawdź łańcuch kryptograficzny swojej domeny za pomocą naszego bezpłatnego narzędzia do sprawdzania DNSSEC dostępnego w przeglądarce narzędzia do sprawdzania DNSSEClub dowiedz się, w jaki sposób podpisy wiążą rekordy, zapoznając się z naszym przewodnikiem dotyczącym DNSSEC.
• Rozwiązanie: Podpisz pliki strefowe, opublikuj pasujące rekordy Delegation Signer (DS) u rejestratora domen oraz wdroż procedury automatycznej wymiany kluczy, aby zapobiec przerwom w walidacji.

3. Przeniesienia w strefie bez ograniczeń (AXFR)

Asynchroniczny transfer pełny (AXFR) to mechanizm protokołowy służący do synchronizacji danych strefy między głównym a pomocniczym serwerem nazw. Nieograniczony transfer strefy pozwala każdemu użytkownikowi w Internecie na żądanie i pobranie całego pliku strefy.

• Co to umożliwia: Wyciek informacji rozpoznawczych. Przeciwnicy uzyskują pełny obraz Twojej cyfrowej powierzchni ataku, ujawniając wewnętrzne konwencje nazewnictwa, serwery przejściowe, bramy VPN oraz niepubliczne subdomeny.
• Jak to sprawdzić: Spróbuj wysłać zapytanie o transfer strefy bezpośrednio do autorytatywnego serwera nazw:

dig AXFR example.com @ns1.example.com

• Bezpieczny serwer odpowiada komunikatem Przesyłanie nie powiodło się lub odrzuca połączenie. Jeśli polecenie zwróci pełną listę rekordów, oznacza to, że ustawienia przesyłania są otwarte.
• Rozwiązanie: Ogranicz żądania AXFR wyłącznie do konkretnych adresów IP należących do uwierzytelnionych serwerów nazw drugorzędnych poprzez zastosowanie rygorystycznych list kontroli dostępu (ACL).

4. Nieprzypisane rekordy DNS

Wpis DNS typu „dangling” pojawia się, gdy wpis w strefie (np. rekord CNAME, A lub NS) wskazuje na zewnętrzny zasób w chmurze, serwer hostingowy lub zasób pamięci masowej, który został wycofany z użytku lub usunięty bez usunięcia odpowiadającego mu wskaźnika DNS.

• Co to umożliwia: Osoby stanowiące zagrożenie identyfikują porzuconą nazwę docelową, przydzielają dokładnie tę nazwę zasobu na platformie dostawcy (takiej jak AWS, Azure, GitHub Pages lub Heroku) i przejmują kontrolę nad Twoją subdomeną w ramach przejęcie subdomeny. 
• Jak to sprawdzić: Wyeksportuj swoją strefę, korzystając z naszej kompleksowej narzędzia do wyszukiwania rekordów DNS i upewnij się, że każdy zewnętrzny punkt końcowy, cel CNAME oraz host w chmurze pozostaje aktywnie przypisany do Twojej organizacji.
• Rozwiązanie: Wprowadź zautomatyzowane procedury wycofywania z eksploatacji, aby usuwać pasujące rekordy DNS w momencie wycofania infrastruktury chmurowej lub usług internetowych stron trzecich.

5. Niskie bezpieczeństwo konta u rejestratora

Rejestratorzy domen zarządzają delegacjami serwerów nazw najwyższego poziomu dla Twoich domen. Zabezpieczenie portalu rejestratora za pomocą uwierzytelnienia jednoczynnikowego, współdzielonych skrzynek pocztowych administratorów lub brak aktywacji zabezpieczeń na poziomie rejestratora tworzy pojedynczy punkt awarii.

• Co to umożliwia: Atakujący przejmują dane logowania do rejestratora, modyfikują delegacje autorytatywnych serwerów nazw i przekierowują cały globalny ruch internetowy oraz pocztowy do złośliwej infrastruktury w ramach niszczycielskiego porwaniem DNS .
• Jak to sprawdzić: Sprawdź konsolę rejestratora, aby zweryfikować, czy stosowane jest uwierzytelnianie wieloskładnikowe oparte na sprzęcie czy na aplikacji uwierzytelnianie wieloskładnikowe jest wymuszane na wszystkich stanowiskach administratorów oraz czy flagi „Registry Lock” lub „Registrar Lock” są aktywne.
• Rozwiązanie: Wprowadź uwierzytelnianie wieloskładnikowe dla wszystkich logowań do rejestratorów, zastosuj kody statusu blokady rejestru (Registry Lock) w przypadku krytycznych domen oraz ustanów dedykowany dostęp oparty na rolach w przedsiębiorstwie.

6. Nieprawidłowo skonfigurowane serwery DNS i mechanizmy kontroli dostępu

Standardowe wdrożenia oprogramowania często zawierają szerokie uprawnienia dostępu, interfejsy administracyjne otwarte na Internet oraz informacje o wersji wyświetlane w odpowiedzi na proste zapytania testowe.

• Co to umożliwia: Atakujący wykrywają oprogramowanie serwera i poziomy aktualizacji poprzez zapytania typu „banner”, takie jak version.bind, identyfikują niezałatane luki i wykorzystują słabe mechanizmy kontroli dostępu do manipulowania parametrami konfiguracyjnymi. Zapoznaj się z naszym podstawowym przewodnikiem na temat czym jest serwer DNS , aby zrozumieć podstawowe zasady bezpiecznej eksploatacji.
• Jak to sprawdzić: Wprowadź polecenie wywołujące ciąg identyfikacyjny serwera z terminala:

dig version.bind CHAOS TXT @ns1.example.com

• Zabezpieczony serwer ukrywa te informacje lub zwraca ogólną odpowiedź.
• Rozwiązanie: Ukryj ciągi znaków określające wersję serwera, ogranicz dostęp do interfejsów zarządzania do administracyjnych sieci VPN, wdroż ograniczenie szybkości odpowiedzi (RRL) oraz egzekwuj zasadę minimalnych uprawnień we wszystkich plikach konfiguracyjnych.

7. Pojedynczy punkt awarii w hostingu DNS

Umieszczenie wszystkich serwerów nazw o charakterze autorytatywnym u jednego dostawcy usług DNS lub wdrożenie serwerów nazw w ramach tego samego fizycznego systemu autonomicznego (AS) powoduje niebezpieczną niestabilność operacyjną.

• Jakie są tego skutki: Ukierunkowany atak DDoS, awaria dostawcy usług lub błąd routingu całkowicie unieruchamiają Twoje autorytatywne serwery nazw, uniemożliwiając dostęp do Twoich stron internetowych, interfejsów API i firmowej poczty elektronicznej, co pokazała szeroko zakrojona awaria serwisu Dyn w 2016 roku. 
• Jak to sprawdzić: Sprawdź rekordy NS swojej domeny, aby upewnić się, czy serwery nazw wskazują na odrębne bloki sieciowe i niezależne systemy autonomiczne.
• Rozwiązanie: Wdrożenie architektury pomocniczego serwera DNS z dwoma dostawcami, rozdzielającej autorytatywne rozpoznawanie adresów między dwie oddzielne, geograficznie rozproszone usługi DNS.

8. Nieszyfrowany ruch DNS

Tradycyjne zapytania i odpowiedzi DNS są przesyłane przez port 53 za pomocą protokołów UDP i TCP w postaci zwykłego tekstu. Bez szyfrowania każde wyszukiwanie domeny jest widoczne dla sieci lokalnych, dostawców usług internetowych oraz operatorów tranzytowych.

• Co to umożliwia: Podsłuchiwanie na trasie, tworzenie profili użytkowników oraz manipulowanie danymi na trasie, gdzie osoby atakujące sieć przechwytują zapytania w postaci zwykłego tekstu i zwracają fałszywe odpowiedzi.
• Jak to sprawdzić: Sprawdź ustawienia punktu końcowego i routera, aby upewnić się, czy rozpoznawanie nazw domen odbywa się za pośrednictwem protokołów DNS over HTTPS (DoH), DNS over TLS (DoT) lub DNS over QUIC (DoQ), a nie poprzez zwykły port UDP 53.
• Rozwiązanie: Skonfiguruj lokalne serwery nazw, punkty końcowe i serwery przekazujące tak, aby wymuszały stosowanie nowoczesnego szyfrowania transportu przy użyciu standardowych TLS.

9. Niezałatane oprogramowanie DNS

Demony DNS, takie jak BIND, Unbound, PowerDNS i Windows Server DNS, wymagają regularnego instalowania poprawek. Korzystanie ze starszych wersji tych demonów naraża sieci na znane luki w zabezpieczeniach udokumentowane w publicznych bazach danych CVE.

• Co umożliwia: Zdalne wykonanie kodu, uszkodzenie pamięci oraz ataki wykorzystujące złożoność algorytmów, które powodują zawieszenie serwerów nazw, takie jak luka KeyTrap (CVE-2023-50387) w silnikach walidacji DNSSEC lub wektor zatruwania pamięci podręcznej DNS SAD (CVE-2020-25705).
• Jak to sprawdzić: Porównaj ciągi znaków kompilacji uruchomionych demonów z komunikatami bezpieczeństwa dostawców i zasubskrybuj kanały powiadomień od głównych twórców oprogramowania DNS.
• Rozwiązanie: Należy przestrzegać harmonogramów aktualizacji, izolować usługi DNS w kontenerach o ograniczonym dostępie lub w minimalnych środowiskach operacyjnych oraz weryfikować kompilacje pod kątem aktualnych wydanych poprawek bezpieczeństwa.

10. Brakujące dokumenty dotyczące bezpieczeństwa i korespondencji e-mailowej

Brak opublikowania odpowiednich wpisów zabezpieczających w pliku strefy DNS naraża domenę na nieautoryzowane wydawanie certyfikatów oraz fałszowanie adresów nadawców w wychodzących wiadomościach e-mail.

• Co to umożliwia: Bez rekordu CAAżadna publiczna instytucja certyfikująca nie może wystawiać certyfikatów SSL/TLS dla Twojej nazwy domeny. Podobnie, pominięcie zasad SPF, DKIM oraz rygorystycznych zasad DMARC umożliwia spamerom wysyłanie fałszywych wiadomości, podszywając się bezpośrednio pod Twoją markę.
• Jak to sprawdzić: Sprawdź poprawność swoich aktualnych ustawień zabezpieczeń, korzystając z naszego bezpłatnego narzędzia do sprawdzania CAA, sprawdź zasady uwierzytelniania za pomocą naszego narzędzia do sprawdzania rekordów DMARClub przeprowadź kompleksową ocenę za pomocą narzędzia do analizy domeny.
• Rozwiązanie: Opublikuj restrykcyjne rekordy CAA zawierające szczegółowe informacje o autoryzowanych wydawcach certyfikatów i wdrażaj protokół DMARC przy p=reject we wszystkich domenach i subdomenach organizacji.

Zagrożenia związane z bezpieczeństwem DNS: ile kosztują cię te słabe punkty

Nieusunięcie luk w zabezpieczeniach systemu DNS naraża przedsiębiorstwo na bezpośrednie ryzyko w obszarach finansowym, operacyjnym i regulacyjnym.

• Przerwy w działaniu i utracone przychody: Konfiguracje oparte na jednym dostawcy oraz nieograniczone ryzyko wzmocnienia sygnału sprzyjają awariom, które powodują wyłączenie serwisów internetowych i platform handlowych.
• Przechwytywanie danych uwierzytelniających i fałszywe przekierowania: Zatrucie pamięci podręcznej i przejęcie kontroli nad DNS przekierowują użytkowników na serwery wyglądające jak oryginalne, których celem jest pozyskanie danych logowania do systemów firmowych.
• Wyciek danych korporacyjnych: Nieograniczone serwery rozpoznające adresy oraz nieprawidłowo skonfigurowane serwery przekazujące umożliwiają atakującym ominięcie zapór sieciowych i wyciek danych wewnętrznych.
• Podszywanie się pod markę i przejęcie firmowej poczty elektronicznej: Brak rekordów SPF, DKIM i DMARC umożliwia atakującym oszukiwanie klientów, partnerów i pracowników za pomocą sfałszowanych wiadomości e-mail.
• Generowanie fałszywych certyfikatów: Pominięcie rekordów CAA zwiększa prawdopodobieństwo utworzenia fałszywych certyfikatów TLS, co podważa założenia dotyczące bezpieczeństwa transmisji.
• Niepowodzenia audytowe i kary regulacyjne: Niezarządzane zasoby DNS często naruszają obowiązkowe wymogi kontrolne określone w standardach SOC 2, ISO 27001 i PCI DSS.

W poniższej tabeli przedstawiono, w jaki sposób typowe luki w konfiguracji systemu DNS odpowiadają bezpośrednio wektorom cyberataków, które umożliwiają:

Jak sprawdzić, czy Twoja domena ma luki w zabezpieczeniach DNS 

Przeprowadzenie ustrukturyzowanego audytu w całym środowisku domenowym pozwala wykryć błędy konfiguracji, zanim zauważą je osoby o złych zamiarach:

1. Przeprowadź wstępne skanowanie domeny: Wprowadź swoją domenę typu apex do naszego bezpłatnego narzędzia do analizy domen, aby sprawdzić ogólny stan bezpieczeństwa i zidentyfikować brakujące ustawienia.
2. Sprawdź swój łańcuch DNSSEC: Przetestuj klucze główne i delegowane za pomocą naszego narzędzia do sprawdzania DNSSEC, aby upewnić się, że podpisy są prawidłowe, a klucze nie straciły ważności.
3. Test authoritative zone transfer restrictions: Execute dig AXFR example.com @<nameserver> against every authoritative host to confirm that public zone dumping is rejected.
4. Sprawdź uprawnienia do rekurencji: Wyślij zapytanie do serwerów autorytatywnych spoza zakresu adresów IP Twojej firmy, aby upewnić się, że rozdzielczość rekurencyjna jest wyłączona.
5. Sprawdź rekordy strefy aktywnej pod kątem wskaźników zwisających: Wyeksportuj wszystkie opublikowane wpisy za pomocą naszej funkcji wyszukiwania rekordów DNS i upewnij się, że wszystkie zewnętrzne zasoby w chmurze oraz docelowe rekordy CNAME pozostają prawidłowe.
6. Sprawdź zabezpieczenia certyfikatów i poczty elektronicznej: Przeprowadź audyt autoryzowanych urzędów certyfikacji za pomocą naszego narzędzia do sprawdzania rekordów CAA oraz zweryfikuj zasady egzekwowania za pomocą naszego narzędzia do sprawdzania rekordów DMARC.
7. Sprawdź ustawienia zabezpieczeń rejestratora: Przeprowadź audyt list dostępu administracyjnego, sprawdź, czy wdrożono uwierzytelnianie wieloskładnikowe, oraz upewnij się, że blokady rejestru pozostają włączone.

Jednorazowy audyt infrastruktury daje ogólny obraz jej aktualnego stanu, jednak aby zapewnić stałą widoczność, konieczne jest ciągłe monitorowanie bezpieczeństwa DNS w celu wykrywania odchyleń w czasie rzeczywistym.

Jak usunąć luki w zabezpieczeniach DNS

Usuwanie luk w zabezpieczeniach systemu DNS wymaga skupienia się w pierwszej kolejności na konfiguracjach administracyjnych i strukturalnych o dużym wpływie:

1. Zabezpiecz warstwę zarządzania: Wprowadź uwierzytelnianie wieloskładnikowe w portalach rejestratorów domen i chmurowych usług DNS, przypisz role z minimalnymi uprawnieniami oraz natychmiast włącz zabezpieczenia blokady rejestratora.
2. Ogranicz ekspozycję sieci: Ogranicz transfery stref wyłącznie do wyznaczonych dodatkowych adresów IP, wyłącz rekurencję na serwerach autorytatywnych i wdroż ograniczenia przepustowości.
3. Usuń osierocone rekordy: Usuń nieaktualne rekordy CNAME, A i NS wskazujące na porzuconą infrastrukturę lub wycofane aplikacje chmurowe innych dostawców.
4. Wprowadź weryfikację kryptograficzną: Podpisz swoje strefy za pomocą DNSSEC, zweryfikuj rekordy DS rejestratora oraz wprowadź rygorystyczne uwierzytelnianie wiadomości e-mail za pomocą protokołów DMARC, SPF i DKIM.

Aby zapoznać się z naszym pełnym procesem wzmacniania zabezpieczeń administracyjnych, przeczytaj oficjalne wytyczne NIST dotyczące bezpieczeństwa DNS.

Najczęściej zadawane pytania

Jaka jest najczęstsza luka w zabezpieczeniach systemu DNS?

Najczęstszą luką w zabezpieczeniach systemu DNS jest nieprawidłowa konfiguracja. Zbyt liberalne ustawienia, takie jak otwarte rekurencyjne serwery DNS, nieautoryzowane transfery stref, zapomniane „wiszące” rekordy oraz słabe mechanizmy kontroli dostępu administracyjnego, są przyczyną znacznie większej liczby incydentów związanych z bezpieczeństwem niż ataki typu „zero-day” wykorzystujące luki w oprogramowaniu.

Jaka jest różnica między luką w zabezpieczeniach DNS a atakiem na DNS?

Luka w zabezpieczeniach systemu DNS to ukryta słabość, nieprawidłowa konfiguracja lub luka architektoniczna w systemie domenowym. Atak na system DNS to aktywna próba wykorzystania tej luki przez atakującego w celu kradzieży danych, przekierowania ruchu lub spowodowania przestoju. 

Czy port 53 stanowi zagrożenie dla bezpieczeństwa?

Port 53 nie jest z natury złośliwy; jest to standardowy port dla protokołu DNS w sieciach UDP i TCP. Jednak pozostawienie portu 53 otwartego dla zapytań rekurencyjnych od ogółu użytkowników sprawia, że serwer staje się otwartym serwerem rozpoznającym nazwy, podatnym na ataki amplifikacyjne i inwigilację.

Jak często należy przeprowadzać audyt systemu DNS pod kątem luk w zabezpieczeniach?

Należy na bieżąco przeprowadzać audyt konfiguracji DNS. Chociaż ręczne przeglądy uprawnień rejestratorów i plików stref powinny odbywać się co najmniej raz na kwartał, zaleca się stosowanie automatycznego monitorowania, aby wykrywać nieautoryzowane zmiany rekordów, wygasające certyfikaty i „wiszące” nazwy hostów natychmiast po ich pojawieniu się.

Słowa końcowe

Luki w zabezpieczeniach systemu DNS dają atakującym możliwość przechwytywania ruchu sieciowego, przeprowadzania ataków typu „odmowa usługi” oraz podszywania się pod marki przedsiębiorstw. Ponieważ większość problemów związanych z bezpieczeństwem DNS wynika raczej z rutynowych niedopatrzeń administracyjnych i niepożądanych zmian w konfiguracji niż z wykorzystania luk typu „zero-day”, proaktywne audyty i regularna konserwacja znacznie ograniczają ogólną powierzchnię ataku.