Bezpieczny DNS: DNSSEC i DNS over HTTPS (DoH)

System nazw domen (DNS) tłumaczy czytelne dla człowieka nazwy domen na adresy IP. DNS, zaprojektowany w latach 80., powstał bez zabezpieczeń — zapytania i odpowiedzi są przesyłane jawnym tekstem przez port UDP/TCP 53, bez uwierzytelniania. Tworzy to dwie główne podatności: zatruwanie pamięci podręcznej DNS (wstrzykiwanie sfałszowanych odpowiedzi DNS w celu przekierowania użytkowników do złośliwych serwerów) oraz podsłuchiwanie DNS (obserwowanie, o jakie domeny pyta użytkownik, ujawnia jego aktywność w sieci). Odpowiadają na nie dwa standardy: DNSSEC zapobiega fałszowaniu, a DNS over HTTPS (DoH) zapobiega podsłuchiwaniu.

Zatruwanie pamięci podręcznej DNS (atak Kaminsky'ego) wykorzystuje brak uwierzytelniania w protokole DNS. Resolver wysyła zapytanie do autorytatywnego serwera DNS i przechowuje odpowiedź w pamięci podręcznej przez czas określony wartością TTL. Atakujący, który potrafi odgadnąć identyfikator transakcji (16-bitowy i przewidywalny) oraz port źródłowy (używany jako dodatkowe źródło entropii od czasu RFC 5452), może wysyłać sfałszowane odpowiedzi zapisywane przez resolver w pamięci podręcznej, przekierowując wszystkich użytkowników korzystających z tego resolvera do serwera atakującego. Po zatruciu pamięci podręcznej użytkownicy są kierowani do fałszywych serwerów, mimo że wpisali prawidłową domenę. DNSSEC zapobiega temu, podpisując cyfrowo odpowiedzi DNS.

DNSSEC dodaje podpisy kryptograficzne do rekordów DNS, umożliwiając resolverom sprawdzenie, czy odpowiedzi pochodzą od prawidłowego administratora strefy i nie zostały zmodyfikowane. DNSSEC wprowadza nowe typy rekordów: RRSIG (podpis rekordu zasobu, czyli właściwy podpis zbioru rekordów), DNSKEY (klucz publiczny używany do weryfikacji podpisów), DS (podpisujący delegację, łączy klucze strefy nadrzędnej i podrzędnej) oraz NSEC/NSEC3 (uwierzytelnione potwierdzenie nieistnienia — dowodzi, że dana nazwa nie istnieje). DNSSEC tworzy łańcuch zaufania od strefy głównej (podpisanej przez ICANN) przez strefy TLD aż do stref autorytatywnych.

DNSSEC używa dwóch typów kluczy podpisujących. Zone Signing Key (ZSK) podpisuje poszczególne zbiory rekordów DNS (RRSIG) i jest często wymieniany (co miesiąc lub kwartał), aby zapewnić elastyczność operacyjną. Key Signing Key (KSK) podpisuje zbiór rekordów DNSKEY i stanowi kotwicę zaufania dla strefy. KSK jest wymieniany rzadziej (raz w roku), ponieważ przy każdej zmianie KSK strefa nadrzędna musi zostać zaktualizowana o nowy rekord DS — jest to proces wymagający koordynacji. KSK weryfikuje ZSK, a ZSK podpisuje dane. Ta dwuwarstwowa struktura równoważy bezpieczeństwo (częsta wymiana ZSK) z obciążeniem operacyjnym (rzadka wymiana KSK).

DNSSEC ma istotne ograniczenia. Nie szyfruje zapytań DNS — podpisuje jedynie odpowiedzi w celu zapewnienia integralności. Podsłuchujący nadal może zobaczyć wszystkie zapytania DNS, ale nie może sfałszować odpowiedzi. Wyliczanie zawartości strefy: rekordy NSEC (potwierdzające nieistnienie) umożliwiają atakującym przechodzenie po strefie i wyliczenie wszystkich nazw domen w jej obrębie; NSEC3 ogranicza to zagrożenie za pomocą nazw skrótów, ale nie zapewnia pełnej ochrony. Złożoność operacyjna: zarządzanie kluczami, wygasanie podpisów i koordynacja ze strefą nadrzędną powodują znaczne obciążenie operacyjne. Wdrożenie DNSSEC nadal jest niepełne — wiele stref TLD i rejestratorów je obsługuje, ale wiele organizacji jeszcze go nie wdrożyło.

DNS over HTTPS (DoH) szyfruje zapytania DNS wewnątrz HTTPS (RFC 8484), ukrywając ich treść przed obserwatorami sieci. Zapytania są kierowane do resolvera obsługującego DoH pod standardowym adresem URL HTTPS, dzięki czemu ruch DNS staje się nieodróżnialny od innego ruchu HTTPS. Uniemożliwia to dostawcom usług internetowych, pracodawcom i atakującym przechwytującym ruch obserwowanie, o jakie domeny pyta użytkownik — eliminuje to lukę w ochronie prywatności pozostawianą przez DNSSEC. DoH przenosi jednak zaufanie z sieciowego resolvera DNS na dostawcę DoH (zwykle Google 8.8.8.8, Cloudflare 1.1.1.1 lub własny resolver DoH organizacji). Obecnie większość głównych przeglądarek obsługuje DoH natywnie.

DNS over TLS (DoT) (RFC 7858) szyfruje zapytania DNS za pomocą TLS przez dedykowany port TCP 853, zamiast tunelować je przez HTTPS. DoT zapewnia takie same korzyści w zakresie prywatności jak DoH — ukrywa treść zapytań przed podsłuchującymi — ale administratorom sieci łatwiej je wykrywać i filtrować (port 853 zamiast portu 443). Jest to rozwiązanie obosieczne: DoT jest widoczny i może być blokowany przez zapory sieciowe przedsiębiorstwa, natomiast zablokowanie DoH jest trudniejsze bez wpływu na ogólny ruch HTTPS. Resolvery typu stub (na poziomie systemu operacyjnego) częściej korzystają z DoT, a przeglądarki — z DoH.

Szyfrowany DNS stanowi wyzwanie dla środowisk przedsiębiorstw, które polegają na filtrowaniu opartym na DNS i mechanizmach sinkhole. Gdy przeglądarki korzystają z zewnętrznych resolverów DoH, omijane są wewnętrzne mechanizmy kontroli DNS. Środki zaradcze w przedsiębiorstwie: wdrożenie wewnętrznego resolvera DoH/DoT (Cisco Umbrella, Pi-hole z DoH) i skonfigurowanie wszystkich urządzeń tak, aby z niego korzystały; blokowanie adresów IP zewnętrznych resolverów DoH na zaporze (Google 8.8.8.8, Cloudflare 1.1.1.1) na porcie 443; użycie Group Policy do wyłączenia DoH na poziomie przeglądarki na zarządzanych punktach końcowych; oraz zastosowanie reguł transparent proxy, które przechwytują DNS over TLS na porcie 853. Celem jest kierowanie całego ruchu DNS przez kontrolowany resolver bez całkowitego blokowania szyfrowanego DNS.

Kompletna strategia bezpieczeństwa DNS łączy wiele mechanizmów kontroli. DNSSEC dla stref autorytatywnych zapobiega zatruwaniu pamięci podręcznej domeny. Filtrowanie oparte na DNS (Cisco Umbrella, Cloudflare Gateway) blokuje złośliwe domeny na poziomie resolvera. DoH/DoT do kontrolowanego resolvera zapewnia prywatność zapytań bez utraty widoczności filtrowania. Rejestrowanie DNS w systemie SIEM przechwytuje wszystkie zapytania na potrzeby threat huntingu — logi DNS ujawniają ruch C2, eksfiltrację danych przez tunelowanie DNS oraz aktywność związaną z algorytmem generowania domen (DGA) wykorzystywanym przez złośliwe oprogramowanie. Telemetria DNS jest jednym z najcenniejszych dostępnych źródeł danych dotyczących bezpieczeństwa.

Tunelowanie DNS koduje dane wewnątrz zapytań i odpowiedzi DNS w celu eksfiltracji danych lub ustanowienia kanałów C2 przez sieci, w których zablokowano inny wychodzący ruch. Narzędzia takie jak iodine, DNScat i dnscat2 kodują dane w etykietach subdomen (zapytanie o EXFILTRATEDDATA.evil.com) lub rekordach TXT. Wykrywanie obejmuje: nietypowo długie nazwy zapytań DNS (>100 znaków), dużą liczbę zapytań z jednego hosta, zapytania dotyczące nieistniejących domen nadrzędnych, nietypowe typy rekordów (TXT, NULL) oraz analizę entropii etykiet domen (zakodowane dane mają wysoką entropię Shannona). Platformy analityczne bezpieczeństwa DNS automatycznie wykrywają wzorce tunelowania.

Strefy zasad odpowiedzi DNS (RPZ) umożliwiają resolverom DNS stosowanie lokalnych zasad nadpisywania odpowiedzi DNS — w praktyce tworzenie lokalnego sinkhole na poziomie resolvera bez modyfikowania globalnej infrastruktury DNS. Gdy klient wysyła zapytanie dotyczące znanej złośliwej domeny, zasada RPZ zwraca NXDOMAIN, przekierowanie na adres IP sinkhole albo odpowiedź passthrough. Źródła danych RPZ są dostępne u dostawców informacji o zagrożeniach (Spamhaus, SURBL) i można je bezpośrednio importować do resolverów BIND lub Unbound. RPZ jest skutecznym narzędziem ochronnym, ponieważ stosuje filtrowanie na warstwie DNS wobec wszystkich urządzeń w sieci, bez konieczności konfiguracji po stronie klienta.

Sprawdź swoją znajomość zagadnień z egzaminu CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: DNSSEC dodaje do rekordów DNS podpisy kryptograficzne z użyciem par kluczy KSK/ZSK, aby zapobiegać zatruwaniu pamięci podręcznej, ale nie szyfruje zapytań; DNS over HTTPS (DoH) szyfruje zapytania DNS wewnątrz HTTPS, aby zapobiegać podsłuchiwaniu, ale stwarza ryzyko omijania filtrowania w przedsiębiorstwie; natomiast tunelowanie DNS koduje dane w zapytaniach DNS i można je wykrywać na podstawie długości, liczby oraz analizy entropii zapytań. W następnej części omówimy IPsec, protokoły VPN i bezpieczeństwo zdalnego dostępu.