DNS over HTTPS – jak szyfrowany DNS omija ochronę firmy

Czym jest DNS over HTTPS i DNS over TLS

Klasyczny DNS działa jak książka telefoniczna internetu - zamienia nazwę domeny, na przykład sklep.pl, na adres IP serwera. Problem w tym, że tradycyjne zapytania DNS wędrują w sieci bez żadnego szyfrowania, w czystym tekście. Każdy, kto ma dostęp do ruchu sieciowego - w tym administrator IT, ale też potencjalny atakujący - widzi, jakie domeny odpytuje dane urządzenie.

DNS over HTTPS (DoH) i DNS over TLS (DoT) to protokoły, które szyfrują te zapytania. DoH dodatkowo maskuje ruch DNS pod standardowym ruchem HTTPS na porcie 443 - tym samym, którym przesyłane są zwykłe strony WWW. To sprawia, że z perspektywy firmowego firewalla zapytanie DNS wygląda identycznie jak wejście na stronę banku.

Sama idea jest dobra - chroni prywatność użytkowników przed podsłuchiwaniem przez dostawców internetu czy operatorów publicznych sieci Wi-Fi. Problem zaczyna się, gdy to szyfrowanie omija także mechanizmy bezpieczeństwa, które firma sama wdrożyła we własnej sieci.

Dlaczego przeglądarki i systemy włączają DoH domyślnie

To nie jest odległy scenariusz - to dzieje się już teraz, często bez wiedzy administratora. Google Chrome i Microsoft Edge od kilku lat automatycznie przełączają się na DoH, jeśli wykryją, że skonfigurowany serwer DNS wspiera ten protokół. Mozilla Firefox poszła dalej i w wielu regionach domyślnie kieruje zapytania DNS do własnego, zewnętrznego resolvera DoH, całkowicie z pominięciem ustawień systemowych.

Systemy operacyjne idą w tym samym kierunku. Windows 11 od kilku aktualizacji rozwija natywne wsparcie dla DoH na poziomie systemu, a Android i iOS umożliwiają użytkownikowi ręczne włączenie prywatnego DNS w kilka sekund, w ustawieniach dostępnych dla każdego pracownika.

• Pracownik może nieświadomie włączyć szyfrowany DNS w przeglądarce, klikając jedną opcję w ustawieniach prywatności.
• Aktualizacja systemu lub przeglądarki może zmienić domyślne zachowanie bez informowania o tym działu IT.
• Aplikacje mobilne i niektóre programy coraz częściej mają wbudowaną obsługę DoH niezależną od ustawień systemowych.

Efekt jest taki, że nawet firma, która nigdy nie podjęła decyzji o wdrożeniu szyfrowanego DNS, może mieć część ruchu, który już z niego korzysta.

Jak DoH omija firmowe filtry i zabezpieczenia sieci

Wiele popularnych zabezpieczeń sieciowych w małych i średnich firmach opiera się właśnie na analizie zapytań DNS. Filtry treści, ochrona przed phishingiem, blokowanie znanych domen ransomware czy systemy rodzicielskiej kontroli w sieci gościnnej - wszystko to zwykle działa na poziomie klasycznego DNS, sprawdzając, o jaką domenę pyta urządzenie, i blokując zapytanie, jeśli domena jest podejrzana.

Kiedy zapytanie DNS jest zaszyfrowane i schowane w ruchu HTTPS, firewall czy router nie widzi już nazwy domeny - widzi tylko połączenie do zewnętrznego serwera DoH, np. Google lub Cloudflare, które z zewnątrz wygląda jak zwykłe przeglądanie strony. Filtr DNS staje się w praktyce ślepy na ruch, który powinien analizować.

To samo mechanizm, z którego korzystają cyberprzestępcy. Coraz częściej malware i infostealery komunikują się z serwerami dowodzenia właśnie przez DoH, dokładnie po to, by ukryć złośliwe domeny przed systemami wykrywania opartymi na DNS. Zablokowanie takiego ruchu wymaga już analizy na innym poziomie niż prosta lista zablokowanych domen.

Realne ryzyko dla firm MŚP

Dla małej firmy, która nie ma dedykowanego zespołu bezpieczeństwa, utrata widoczności w ruchu DNS to często problem niezauważony aż do momentu incydentu. Kilka konkretnych konsekwencji, z którymi warto się liczyć:

• Utrata skuteczności filtrowania DNS - inwestycja w usługę filtrowania treści lub ochronę przed phishingiem na poziomie DNS przestaje działać dla części ruchu, bez żadnego ostrzeżenia.
• Niewidoczne shadow IT - pracownicy mogą omijać blokady stron rozrywkowych lub niebezpiecznych bez wiedzy działu IT.
• Trudniejsza analiza incydentów - logi DNS są jednym z podstawowych źródeł podczas dochodzenia po ataku. Jeśli część zapytań jest zaszyfrowana i wychodzi poza kontrolowany resolver, ślad po ataku staje się trudniejszy do zrekonstruowania.
• Nowa droga dla malware - złośliwe oprogramowanie komunikujące się przez DoH z serwerami command-and-control jest trudniejsze do wykrycia klasycznymi metodami.

Nie oznacza to, że szyfrowanie DNS jest złe - w sieci publicznej czy dla użytkownika prywatnego to realna korzyść dla prywatności. Problem polega na tym, że firma musi decydować, gdzie i jak to szyfrowanie działa w jej sieci, a nie zostawiać tę decyzję przeglądarce czy systemowi operacyjnemu.

Jak kontrolować DoH w firmowej sieci

Dobra wiadomość - kontrolę nad szyfrowanym DNS można odzyskać bez rezygnowania z bezpieczeństwa, jakie daje szyfrowanie. Kilka sprawdzonych podejść dla MŚP:

• Wyłączenie DoH w przeglądarkach przez polityki grupowe - Chrome, Edge i Firefox pozwalają administratorowi wymusić konkretny tryb DNS przez GPO lub Intune, zamiast pozwalać każdemu pracownikowi decydować samodzielnie.
• Blokowanie znanych publicznych resolverów DoH na firewallu - można zablokować ruch do popularnych zewnętrznych serwerów DoH, zmuszając urządzenia do korzystania z resolvera wskazanego przez firmę.
• Wdrożenie DoH lub DoT na poziomie firmowego resolvera - najlepsze rozwiązanie to nie walka z szyfrowaniem, a przejęcie go. Firmowy serwer DNS może sam obsługiwać zapytania przez DoH lub DoT, zachowując przy tym pełną widoczność i filtrowanie, ponieważ szyfrowanie kończy się na własnej infrastrukturze, a nie na serwerze Google czy Cloudflare.
• Monitorowanie ruchu do portu 443 pod kątem anomalii DNS - rozwiązania typu audyt bezpieczeństwa sieci pomagają wykryć, które urządzenia i aplikacje faktycznie korzystają z szyfrowanego DNS i dokąd wysyłają zapytania.

W praktyce najskuteczniejsza jest kombinacja tych metod, dopasowana do wielkości firmy i posiadanej infrastruktury sieciowej.