DNS to nie detal techniczny, lecz usługa krytyczna dla biznesu
Gdy pracownik wpisuje adres strony lub aplikacja łączy się z usługą w chmurze, system DNS tłumaczy nazwę domeny na adres IP właściwego serwera. Bez tego mechanizmu przestają działać poczta, VPN, serwisy internetowe, systemy sprzedażowe i wiele usług wewnętrznych. Z perspektywy biznesu DNS jest więc wspólnym punktem zależności dla niemal całej działalności cyfrowej.
Ta centralna rola ma dwie strony. Jeżeli DNS jest niedostępny, organizacja może doświadczyć przestoju porównywalnego z awarią sieci. Jeżeli odpowiedź DNS zostanie zmanipulowana, użytkownik może trafić do fałszywego serwisu, mimo że wpisał poprawny adres. Jeżeli zaś ruch DNS pozostaje poza kontrolą, firma traci możliwość zauważenia części prób phishingu, komunikacji z serwerami sterującymi złośliwym oprogramowaniem oraz wyprowadzania danych.
Dlatego pytanie zarządu nie powinno brzmieć: „Czy serwery DNS działają?”, lecz: „Czy DNS ogranicza ryzyko, zapewnia widoczność i ma zaprojektowaną odporność?”. To różnica między zwykłym utrzymywaniem usługi a świadomym zarządzaniem ryzykiem operacyjnym.
Protective DNS: zatrzymać zagrożenie, zanim dojdzie do połączenia
Protective DNS, czyli bezpieczny DNS, analizuje zapytania i odpowiedzi w czasie rzeczywistym. Porównuje domeny z informacjami o znanych zagrożeniach i może zablokować próbę wejścia na stronę phishingową, połączenie z infrastrukturą przestępczą lub domeną wykorzystywaną przez malware. Dzieje się to na bardzo wczesnym etapie, zanim komputer nawiąże właściwe połączenie z niebezpiecznym serwerem.
Dla firmy oznacza to dodatkową warstwę ochrony obejmującą komputery, telefony, serwery, urządzenia IoT i zasoby chmurowe. CSIRT KNF wskazuje, że w polskich warunkach rozsądnym minimum jest lista złośliwych domen CERT Polska. Warto uzupełnić ją o niezależne źródło, ponieważ różni dostawcy widzą inne fragmenty internetu.
To ostatnie ma znaczenie biznesowe. Zbyt agresywna polityka może zablokować legalną domenę potrzebną sprzedaży, księgowości lub obsłudze klienta. Wdrożenie powinno więc obejmować mechanizm szybkich wyjątków, właściciela decyzji oraz testy wpływu na procesy. Bezpieczeństwo nie może być budowane kosztem niekontrolowanych przerw w pracy.
Najpierw odzyskaj kontrolę nad ruchem
Nawet najlepsza usługa ochronna nie pomoże, jeśli pracownicy, przeglądarki lub aplikacje mogą korzystać z dowolnych publicznych serwerów DNS. Ponadto wiele przeglądarek domyślnie włącza szyfrowany DNS do serwerów własnego dostawcy, pomijając lokalną infrastrukturę bezpieczeństwa. W takim przypadku część ruchu omija firmowe zasady, logowanie i mechanizmy blokowania. Organizacja widzi tylko fragment obrazu, a niewidocznego ryzyka nie potrafi skutecznie ograniczyć.
Dlatego najważniejszym krokiem jest skierowanie ruchu DNS przez firmowy, autoryzowany punkt kontroli. Może to być lokalny resolver (serwer, który na żądanie urządzenia odnajduje adres IP przypisany do nazwy domeny, aby umożliwić połączenie z właściwą stroną lub usługą), usługa chmurowa albo rozwiązanie hybrydowe. Równolegle należy ograniczyć możliwość bezpośredniego korzystania z zewnętrznych usług DNS oraz odpowiednio skonfigurować przeglądarki i urządzenia mobilne, które potrafią samodzielnie włączać szyfrowane połączenia do publicznych dostawców.
Nie chodzi o blokowanie szyfrowania jako takiego. Chodzi o to, aby szyfrowany ruch trafiał do resolvera zatwierdzonego przez organizację, a nie do przypadkowej usługi wybranej przez użytkownika lub aplikację. Środki zaradcze są konkretne: blokada wychodzącego ruchu DNS (porty UDP/TCP 53) poza autoryzowane serwery firmowe, blokada nieautoryzowanego ruchu szyfrowanego (DoT na porcie 853, DoQ, DoH), blokowanie domen znanych publicznych serwerów DoH oraz wymuszanie konfiguracji przeglądarek i urządzeń mobilnych przez MDM lub GPO. To zwykłe zmiany konfiguracyjne, a nie zakup nowego systemu - kategoria „wysoki wpływ, niska trudność wdrożenia".
Logi DNS: zapis sygnałów, które poprzedzają incydent
Zapytania DNS często pozostawiają ślad, zanim atak stanie się widoczny w innych systemach. Mogą pokazać, że komputer próbował połączyć się z domeną phishingową, z serwerem sterującym malware albo z nietypowym adresem używanym do wyprowadzania danych. Z tego powodu logi DNS są cennym źródłem dla zespołów reagowania na incydenty i analiz powłamaniowych.
Samo gromadzenie logów nie wystarczy. Trzeba je powiązać z danymi z DHCP, urządzeń końcowych i firewalli, aby ustalić źródło zapytania. Integracja z SIEM i SOAR ułatwia wykrywanie wzorców i przyspiesza reakcję. Pełny zapis logów oznacza jednak koszty, dlatego retencja powinna wynikać z wymagań prawnych, potrzeb dochodzeniowych i budżetu. Minimum jest jednoznaczne: zapytania do domen złośliwych lub niedozwolonych należy rejestrować zawsze. Rekomendowany jest format DNSTAP, tańszy operacyjnie od klasycznego logowania zapytań.
Szyfrowanie i DNSSEC: dwa uzupełniające się mechanizmy
W rozmowach o DNS często mieszają się te dwa pojęcia. Szyfrowany DNS, na przykład DoH, DoT lub DoQ, chroni poufność kanału komunikacji między urządzeniem a resolverem. Utrudnia podsłuchiwanie zapytań i ich podmienianie po drodze. DNSSEC to podpisy cyfrowe dodawane do danych DNS, które chronią autentyczność i integralność samych danych DNS, pozwalając odbiorcy sprawdzić, czy odpowiedź pochodzi z właściwego źródła i nie została zmieniona. Nie ukrywa jednak treści zapytań.
Jeden mechanizm nie zastępuje drugiego. Firma może szyfrować połączenie do niekontrolowanego resolvera i stracić widoczność. Może też stosować DNSSEC bez szyfrowania, potwierdzając prawdziwość odpowiedzi, ale nadal ujawniając zapytania. Dlatego oba rozwiązania powinny się uzupełniać. Szyfrowanie należy wdrażać na kontrolowanych odcinkach, z logowaniem na zatwierdzonych resolverach i telemetrią z urządzeń końcowych. To decyzja techniczna wynikająca z oceny ryzyka, a nie proste włączenie funkcji.
Odporność DNS to odporność całej firmy
Awaria DNS potrafi zatrzymać procesy, mimo że same aplikacje i łącza działają prawidłowo. Organizacja powinna więc utrzymywać co najmniej serwer podstawowy i zapasowy dla każdej strefy, rozdzielone sieciowo, a najlepiej również geograficznie. Raport rekomenduje model „hidden primary”: główny serwer, na którym wprowadza się zmiany, nie jest bezpośrednio widoczny w internecie, a publicznie odpowiadają serwery wtórne.
Serwer dostępny z internetu nie powinien jednocześnie publikować firmowych danych DNS i wykonywać zapytań w imieniu użytkowników. Rozdzielenie ról ogranicza powierzchnię ataku. Odporność wymaga też kontrolowanych transferów danych, uwierzytelniania, monitoringu oraz testów przełączenia.
Higiena domen: małe zaniedbania, realne straty
Nie każdy incydent DNS zaczyna się od zaawansowanego ataku. Czasem wystarczy zapomniany rekord wskazujący na nieużywaną usługę chmurową, błędne przekierowanie albo publiczna informacja zdradzająca elementy infrastruktury. Takie pozostałości mogą umożliwić przejęcie subdomeny, ułatwić rekonesans albo podważyć wiarygodność marki. Należy zwrócić szczególną uwagę na:
- Porzucone rekordy - wpis wskazujący na zasób w chmurze, z którego firma już nie korzysta. Atakujący może go zarejestrować i przejąć kontrolę nad adresem należącym formalnie do firmy. Antidotum: automatyczny audyt i usuwanie zbędnych rekordów.
- Domeny łudząco podobne (typosquatting, homoglify) - przestępcy rejestrują nazwy przypominające firmową, by oszukiwać klientów i pracowników. Zaleca się monitorowanie takich rejestracji oraz defensywną rejestrację najbardziej ryzykownych wariantów. To ochrona marki, nie tylko infrastruktury.
- Nadmiar informacji publicznych - firmy publikują czasem w DNS dane o systemach operacyjnych, lokalizacji, osobach kontaktowych, a nawet wewnętrzne adresy IP. Atakujący dostaje mapę infrastruktury bez włamania. Rekomendacja: cykliczny audyt publicznych rekordów. Wpisy niezbędne dla poczty (SPF, DKIM, DMARC) zostają, reszta wymaga uzasadnienia.
Potrzebny jest cykliczny, najlepiej automatyczny audyt publicznych rekordów oraz proces usuwania wpisów bez właściciela biznesowego. Każda istotna domena i subdomena powinna mieć opiekuna, cel i termin przeglądu. Warto też monitorować rejestracje nazw podobnych do marki, wykorzystywanych w phishingu. Bez współpracy IT, bezpieczeństwa, marketingu, działu prawnego i właścicieli usług skaner jedynie utworzy listę problemów, których nikt nie usunie.
Chmura, własna infrastruktura czy model hybrydowy?
Nie istnieje jeden model właściwy dla wszystkich.
Rozwiązanie lokalne (własne serwery DNS) daje większą kontrolę nad politykami i danymi, ale wymaga kompetencji i utrzymania.
Chmura zapewnia większą skalę i bogatszą analitykę, lecz zwiększa zależność od dostawcy, koszty subskrypcji i ryzyko profilowania organizacji na podstawie jej zapytań DNS. Historia zapytań ujawnia, z jakich narzędzi firma korzysta, z kim rozmawia i co planuje. Stąd wskazówka: jeśli chmura, to z konfiguracją i logami na terenie Unii Europejskiej.
Model hybrydowy jest zwykle najlepszym kompromisem. Może połączyć oba podejścia: chmura daje rozbudowaną ochronę, a mechanizmy lokalne utrzymują podstawowe filtrowanie podczas awarii. Wybór powinien uwzględniać miejsce przetwarzania logów, regulacje, latencję, plan wyjścia od dostawcy i zachowanie systemu w razie niedostępności. Dla danych wrażliwych znaczenie mają też warunki umowne i przetwarzanie w UE.
Zarząd nie musi wybierać konkretnej technologii, ale powinien zatwierdzić kryteria. Kluczowe pytanie brzmi: czy w sytuacji awarii lub sporu z dostawcą firma zachowa minimalną ochronę i zdolność działania, czy przejdzie w tryb „fail-open”, w którym ruch jest przepuszczany bez filtrowania?
Realistyczna roadmapa: zacząć od wysokiego wpływu
Największą wartość przynoszą działania, które budują kontrolę i widoczność.
- Pierwszy etap (minimum) powinien objąć inwentaryzację DNS, wyznaczenie właściciela usługi, centralny firmowy serwer DNS, ograniczenie korzystania z publicznych serwerów DNS oraz podstawowe filtrowanie z użyciem list reputacyjnych. Równolegle warto wprowadzić minimalne logowanie zdarzeń bezpieczeństwa i procedurę szybkiej obsługi błędnych blokad.
- W drugim etapie (rozszerzenie) logi należy połączyć z SIEM, danymi z DHCP, firewalli i urządzeń końcowych. To dobry moment na kontrolę ustawień DoH, wdrożenie walidacji DNSSEC, audyt publicznych rekordów i monitoring domen podobnych do marki, a także wymuszanie konfiguracji przez MDM/GPO. Organizacja powinna również ustalić wskaźniki: udział ruchu przechodzącego przez autoryzowane resolvery, czas obsługi wyjątku, liczbę zablokowanych prób oraz pokrycie logowaniem.
- Trzeci etap (dojrzałość) to rozwinięta detekcja anomalii i prób wyprowadzania danych przez DNS, automatyzacja reakcji, rozwiązania hybrydowe oraz regularne testy odporności. Dopiero na tym poziomie warto inwestować w najbardziej zaawansowane mechanizmy (polityki per segment sieci i typ urządzenia), jeśli ich koszt odpowiada profilowi ryzyka firmy.
Taka kolejność ogranicza ryzyko projektu, pozwala szybko uzyskać pierwsze efekty i buduje podstawę pod dalsze inwestycje. Najgorszym wariantem jest zakup zaawansowanego narzędzia bez centralizacji ruchu, kompletnej telemetrii i przypisanej odpowiedzialności.
Pięć pytań, które kierownictwo powinno zadać działowi IT
- Czy cały ruch DNS przechodzi przez nasze serwery i czy potrafimy to udowodnić pomiarem, a nie samą deklaracją?
- Czy potrafimy szybko ustalić, które urządzenie próbowało połączyć się ze złośliwą domeną?
- Czy blokujemy domeny z listy CERT Polska i niezależnego źródła oraz kto odblokuje domenę kontrahenta przy fałszywym alarmie?
- Kiedy ostatnio audytowaliśmy publiczne rekordy DNS pod kątem zapomnianych wpisów i nadmiarowych informacji?
- Czy monitorujemy rejestracje domen podobnych do naszej i wiemy, co zrobimy, gdy zostaną użyte przeciwko naszym klientom?
Jeśli na któreś z tych pytań nie ma jasnej, udokumentowanej odpowiedzi, organizacja ma konkretną lukę do zamknięcia.
Podsumowanie
DNS jest jedną z niewielu warstw bezpieczeństwa o wyraźnie korzystnym stosunku efektu do nakładu. Duża część rekomendacji CSIRT KNF to zmiany konfiguracyjne i porządkowe, a nie inwestycje kapitałowe, które chronią przed najczęstszym scenariuszem strat: pracownikiem, który kliknął podejrzany link lub załącznik. DNS nie musi pozostać niewidocznym źródłem ryzyka. Może stać się relatywnie prostą, szeroko działającą warstwą ochrony - pod warunkiem, że firma potraktuje go jako usługę krytyczną, połączy technologię z procesami i będzie rozwijać zabezpieczenia etapami.
