Minimalizacja ryzyka związanego z użyciem DoH i DoT
Ochrona przed DoH i DoT
Czy kontrolujesz swój ruch DNS? Organizacje inwestują dużo czasu, pieniędzy i wysiłków w zapewnienie bezpieczeństwa swoich sieci. Jednak jedną z dziedzin, która często jest pomijana, jest DNS.
Dobrym przeglądem ryzyk związanych z DNS jest na konferencji Infosecurity.
31% badanych klas ransomware używało DNS do wymiany kluczy. Wnioski z badania
31% badanych klas ransomware używało DNS do wymiany kluczy.
Problem jest poważny. Według badawczej laboratorium Palo Alto Networks Unit 42, około 85% złośliwego oprogramowania używa DNS do ustanawiania kanału zarządzania i kontroli, umożliwiając cyberprzestępcom łatwe wprowadzanie złośliwego oprogramowania do twojej sieci oraz kradzież danych. Od czasów swojego powstania ruch DNS był głównie nieszyfrowany i łatwy do monitorowania przez mechanizmy zabezpieczeń NGFW.
Pojawiły się nowe protokoły do DNS, które mają na celu zwiększenie prywatności połączeń DNS. Są one aktywnie wspierane przez wiodących dostawców przeglądarek i innych dostawców oprogramowania. Wkrótce w sieciach korporacyjnych rozpocznie się wzrost zaszyfrowanego ruchu DNS. Szyfrowany ruch DNS, który nie jest odpowiednio analizowany i dozwolony, stanowi zagrożenie dla bezpieczeństwa firmy. Na przykład, takim zagrożeniem są kryptolockery, które używają DNS do wymiany kluczy szyfrowania. Napastnicy obecnie żądają okupu w wysokości kilku milionów dolarów za odzyskanie dostępu do twoich danych. W firmie Garmin, na przykład, zapłacono 10 milionów dolarów.
Przy odpowiedniej konfiguracji NGFW mogą one zablokować lub chronić używanie DNS-over-TLS (DoT) i mogą być używane do zabronienia używania DNS-over-HTTPS (DoH), co pozwala na analizowanie całego ruchu DNS w twojej sieci.
Czym jest zaszyfrowany DNS?
Czym jest DNS
System nazw domen (DNS) przekształca czytelne dla człowieka nazwy domen (na przykład adres ) do adresów IP (na przykład 34.107.151.202). Gdy użytkownik wpisuje nazwę domeny w przeglądarkę, przeglądarka wysyła zapytanie DNS do serwera DNS, prosząc o adres IP powiązany z tą nazwą domeny. W odpowiedzi serwer DNS zwraca adres IP, który będzie używany przez tę przeglądarkę.
Zapytania i odpowiedzi DNS są przesyłane przez sieć jako zwykły tekst w otwartym formacie, co czyni je podatnymi na szpiegowanie lub modyfikację odpowiedzi oraz przekierowanie przeglądarki na złośliwe serwery. Szyfrowanie DNS utrudnia śledzenie zapytań DNS lub ich modyfikację w trakcie przesyłania. Szyfrowanie zapytań i odpowiedzi DNS chroni Cię przed atakiem Man-in-the-Middle, przy jednoczesnym realizowaniu tych samych funkcji, co tradycyjny protokół DNS (system nazw domenowych) w otwartym tekście.
W ciągu ostatnich kilku lat wprowadzono dwa protokoły szyfrowania DNS:
DNS-over-HTTPS (DoH)
DNS-over-TLS (DoT)
Te protokoły mają jedną wspólną cechę: celowo ukrywają zapytania DNS przed jakimkolwiek przechwytywaniem… w tym przed bezpieczeństwem organizacji. Protokóły głównie korzystają z protokołu TLS (Transport Layer Security) do ustanowienia szyfrowanego połączenia między klientem, który wysyła zapytania, a serwerem, który rozwiązuje zapytania DNS, przez port, który zazwyczaj nie jest używany do ruchu DNS.
Prywatność zapytań DNS jest dużą zaletą tych protokołów. Jednak stwarzają one problemy dla działów bezpieczeństwa, które muszą monitorować ruch sieciowy i wykrywać oraz blokować złośliwe połączenia. Ponieważ protokoły różnią się sposobem implementacji, metody analizy będą różne w przypadku DoH i DoT.
DNS over HTTPS (DoH)
DNS w HTTPS
DoH wykorzystuje dobrze znany port 443 do HTTPS, dla którego w RFC wyraźnie zaznaczone jest, że celem jest "mieszanie ruchu DoH z innym ruchem HTTPS w tym samym połączeniu", "utrudnienie analizy ruchu DNS" oraz w ten sposób obejście środków kontroli korporacyjnej ( ). Protokół DoH wykorzystuje szyfrowanie TLS oraz składnię zapytań dostarczoną przez wspólne standardy HTTPS i HTTP/2, dodając zapytania i odpowiedzi DNS na szczycie standardowych zapytań HTTP.
Zagrożenia związane z DoH
Jeśli nie potrafisz odróżnić zwykłego ruchu HTTPS od zapytań DoH, aplikacje w twojej organizacji mogą (i będą) omijać lokalne ustawienia DNS, przekierowując zapytania do zewnętrznych serwerów obsługujących zapytania DoH, co uniemożliwia wszelkie monitorowanie, a więc niszczy możliwość kontroli ruchu DNS. W idealnym przypadku powinieneś kontrolować DoH, korzystając z funkcji deszyfrowania HTTPS.
I w najnowszych wersjach swoich przeglądarek, a obie firmy pracują nad wykorzystywaniem DoH domyślnie dla wszystkich zapytań DNS. integracji DoH ze swoimi systemami operacyjnymi. Minusem jest to, że nie tylko szanowane firmy programistyczne, ale także przestępcy zaczęli wykorzystywać DoH jako środek omijania tradycyjnych zabezpieczeń firewalli korporacyjnych. (Na przykład, zajrzyj do następujących artykułów: , i .) W każdym razie zarówno poprawny, jak i złośliwy ruch DoH pozostaną niewidoczne, pozostawiając organizację ślepą na złośliwe wykorzystanie DoH jako kanału do zarządzania złośliwym oprogramowaniem (C2) i kradzieży poufnych danych.
Zapewnienie widoczności i kontroli ruchu DoH
Jako najlepsze rozwiązanie do kontrolowania DoH zalecamy skonfigurowanie w NGFW deszyfrowania ruchu HTTPS i zablokowanie ruchu DoH (nazwa aplikacji: dns-over-https).
Po pierwsze, upewnij się, że NGFW jest skonfigurowane do deszyfrowania HTTPS, zgodnie z .
Po drugie, stwórz regułę dla ruchu aplikacji »dns-over-https«, jak pokazano poniżej:
Reguła Palo Alto Networks NGFW do blokowania DNS-over-HTTPS
Jako alternatywne rozwiązanie (jeśli twoja organizacja nie wdrożyła jeszcze w pełni deszyfrowania HTTPS) NGFW można skonfigurować do zastosowania działania »zabroń« dla identyfikatora aplikacji »dns-over-https«, ale efekt będzie ograniczony do blokady niektórych dobrze znanych serwerów DoH po ich nazwie domeny, ponieważ bez deszyfrowania HTTPS ruch DoH nie może być w pełni weryfikowany (zob. i wyszukaj frazę »dns-over-https«).
DNS przez TLS (DoT)
DNS wewnątrz TLS
Podczas gdy protokół DoH stara się wmieszać w inny ruch na tym samym porcie, DoT zamiast tego domyślnie korzysta z wyznaczonego portu, zarezerwowanego na tę jedyną okoliczność, jednocześnie specjalnie zakazując używania tego samego portu dla tradycyjnego, niezaszyfrowanego ruchu DNS ( ).
Protokół DoT korzysta z protokołu TLS w celu zapewnienia szyfrowania, które kapsułkuje standardowe zapytania protokołu DNS, z ruchem używającym dobrze znanego portu 853 ( ). Protokół DoT został zaprojektowany, aby ułatwić organizacjom blokowanie ruchu na porcie, lub zgodzić się na jego wykorzystanie, ale włączyć deszyfrowanie na tym porcie.
Zagrożenia związane z DoT
Google zaimplementował DoT w swoim kliencie , przy tym domyślnie włączona jest opcja automatycznego korzystania z DoT, jeśli jest dostępna. Jeśli oceniliście zagrożenia i jesteście gotowi do korzystania z DoT na poziomie organizacyjnym, to administratorzy sieci muszą wyraźnie zezwolić na wychodzący ruch na port 853 przez swój perimeter dla tego nowego protokołu.
Zapewnienie widoczności i kontroli ruchu DoT
Jako najlepsza praktyka kontroli DoT, rekomendujemy dowolną z powyższych metod, w zależności od wymagań waszej organizacji:
Skonfiguruj NGFW do deszyfrowania całego ruchu do portu docelowego 853. Dzięki deszyfrowaniu, DoT będzie wyświetlany jako aplikacja DNS, na którą można zastosować dowolne działanie, na przykład włączyć subskrypcję do kontrolowania domen DGA lub już istniejący i program antyszpiegowski.
Alternatywnie można całkowicie zablokować ruch ‘dns-over-tls’ przez port 853 za pomocą silnika App-ID. Zwykle jest on domyślnie zablokowany, więc nie są wymagane żadne działania (o ile nie zezwoliłeś specjalnie aplikacji ‘dns-over-tls’ lub ruchowi przez port 853).
Źródło: habr.com
