Minimalizacja ryzyka stosowania DoH i DoT
Ochrona DoH i DoT
Czy kontrolujesz swój ruch DNS? Organizacje inwestują dużo czasu, pieniędzy i wysiłku w zabezpieczanie swoich sieci. Jednak obszarem, któremu często nie poświęca się wystarczającej uwagi, jest DNS.
Dobrym przeglądem zagrożeń, jakie niesie ze sobą DNS, jest: na konferencji Infosecurity.
31% ankietowanych klas oprogramowania ransomware korzystało z DNS do wymiany kluczy.Wyniki badania
31% ankietowanych klas oprogramowania ransomware korzystało z DNS do wymiany kluczy.
Problem jest poważny. Według laboratorium badawczego Palo Alto Networks Unit 42 około 85% złośliwego oprogramowania wykorzystuje DNS do ustanowienia kanału dowodzenia i kontroli, umożliwiając atakującym łatwe wprowadzenie złośliwego oprogramowania do Twojej sieci, a także kradzież danych. Od samego początku ruch DNS był w dużej mierze niezaszyfrowany i można go łatwo analizować za pomocą mechanizmów bezpieczeństwa NGFW.
Pojawiły się nowe protokoły DNS, których celem jest zwiększenie poufności połączeń DNS. Są aktywnie wspierane przez wiodących dostawców przeglądarek i innych dostawców oprogramowania. Szyfrowany ruch DNS wkrótce zacznie rosnąć w sieciach korporacyjnych. Zaszyfrowany ruch DNS, który nie jest odpowiednio analizowany i rozpoznawany przez narzędzia, stanowi zagrożenie dla bezpieczeństwa firmy. Takim zagrożeniem są na przykład kryptolockery wykorzystujące DNS do wymiany kluczy szyfrujących. Atakujący żądają teraz okupu w wysokości kilku milionów dolarów za przywrócenie dostępu do Twoich danych. Garmin na przykład zapłacił 10 milionów dolarów.
Po prawidłowej konfiguracji NGFW może blokować lub chronić korzystanie z DNS-over-TLS (DoT) i może służyć do blokowania korzystania z DNS-over-HTTPS (DoH), umożliwiając analizę całego ruchu DNS w Twojej sieci.
Co to jest szyfrowany DNS?
Co to jest DNS
System nazw domen (DNS) rozpoznaje nazwy domen czytelne dla człowieka (na przykład adres ) na adresy IP (na przykład 34.107.151.202). Kiedy użytkownik wprowadza nazwę domeny w przeglądarce internetowej, przeglądarka wysyła zapytanie DNS do serwera DNS z prośbą o adres IP powiązany z tą nazwą domeny. W odpowiedzi serwer DNS zwraca adres IP, z którego będzie korzystała ta przeglądarka.
Zapytania i odpowiedzi DNS są przesyłane przez sieć w postaci zwykłego tekstu, niezaszyfrowanego, co naraża ją na szpiegostwo lub zmianę odpowiedzi i przekierowanie przeglądarki na złośliwe serwery. Szyfrowanie DNS utrudnia śledzenie lub zmianę żądań DNS podczas transmisji. Szyfrowanie żądań i odpowiedzi DNS chroni przed atakami typu Man-in-the-Middle, zapewniając jednocześnie tę samą funkcjonalność, co tradycyjny protokół DNS (Domain Name System) w postaci zwykłego tekstu.
W ciągu ostatnich kilku lat wprowadzono dwa protokoły szyfrowania DNS:
-
DNS przez HTTPS (DoH)
-
DNS-over-TLS (DoT)
Protokoły te mają jedną wspólną cechę: celowo ukrywają żądania DNS przed przechwyceniem… a także przed ochroniarzami organizacji. Protokoły te wykorzystują przede wszystkim TLS (Transport Layer Security) do ustanawiania szyfrowanego połączenia między klientem wysyłającym zapytania a serwerem rozwiązującym zapytania DNS za pośrednictwem portu, który zwykle nie jest używany dla ruchu DNS.
Poufność zapytań DNS jest dużym plusem tych protokołów. Stwarzają jednak problemy dla ochroniarzy, którzy muszą monitorować ruch sieciowy oraz wykrywać i blokować złośliwe połączenia. Ponieważ protokoły różnią się implementacją, metody analizy będą się różnić w przypadku DoH i DoT.
DNS przez HTTPS (DoH)
DNS w HTTPS
DoH używa dobrze znanego portu 443 dla protokołu HTTPS, w odniesieniu do którego dokument RFC wyraźnie stwierdza, że jego celem jest „mieszanie ruchu DoH z innym ruchem HTTPS w tym samym połączeniu”, „utrudnianie analizy ruchu DNS” i w ten sposób obchodzenie kontroli korporacyjnych ( ). Protokół DoH wykorzystuje szyfrowanie TLS i składnię żądań zapewnianą przez popularne standardy HTTPS i HTTP/2, dodając żądania i odpowiedzi DNS do standardowych żądań HTTP.
Ryzyko związane z DoH
Jeśli nie potrafisz rozróżnić zwykłego ruchu HTTPS od żądań DoH, aplikacje w Twojej organizacji mogą (i będą) ominąć lokalne ustawienia DNS, przekierowując żądania do serwerów innych firm odpowiadających na żądania DoH, co omija wszelkie monitorowanie, to znaczy niszczy możliwość kontrolować ruch DNS. Idealnie byłoby kontrolować DoH za pomocą funkcji deszyfrowania HTTPS.
И w najnowszej wersji swoich przeglądarek i obie firmy pracują nad domyślnym używaniem DoH dla wszystkich żądań DNS. na temat integracji DoH ze swoimi systemami operacyjnymi. Wadą jest to, że nie tylko renomowani producenci oprogramowania, ale także osoby atakujące zaczęły wykorzystywać DoH w celu ominięcia tradycyjnych korporacyjnych zabezpieczeń firewall. (Na przykład przejrzyj następujące artykuły: , и W obu przypadkach zarówno dobry, jak i złośliwy ruch DoH pozostanie niewykryty, pozostawiając organizację ślepą na złośliwe wykorzystanie DoH jako kanału kontroli złośliwego oprogramowania (C2) i kradzieży wrażliwych danych.
Zapewnienie widoczności i kontroli ruchu DoH
Jako najlepsze rozwiązanie do kontroli DoH zalecamy skonfigurowanie NGFW do deszyfrowania ruchu HTTPS i blokowania ruchu DoH (nazwa aplikacji: dns-over-https).
Najpierw upewnij się, że NGFW jest skonfigurowany do odszyfrowywania HTTPS, zgodnie z .
Następnie utwórz regułę dla ruchu aplikacji „dns-over-https”, jak pokazano poniżej:
Reguła NGFW Palo Alto Networks blokująca DNS-over-HTTPS
Jako tymczasową alternatywę (jeśli Twoja organizacja nie wdrożyła w pełni deszyfrowania HTTPS), NGFW można skonfigurować tak, aby stosował akcję „odmów” wobec identyfikatora aplikacji „dns-over-https”, ale efekt będzie ograniczony do blokowania niektórych dobrze- znanych serwerów DoH według nazwy domeny, zatem bez odszyfrowania HTTPS nie można w pełni sprawdzić ruchu DoH (patrz i wyszukaj „dns-over-https”).
DNS przez TLS (DoT)
DNS w TLS
Podczas gdy protokół DoH ma tendencję do mieszania się z innym ruchem na tym samym porcie, DoT zamiast tego domyślnie używa specjalnego portu zarezerwowanego wyłącznie do tego celu, nawet w szczególności uniemożliwiając używanie tego samego portu przez tradycyjny niezaszyfrowany ruch DNS ( ).
Protokół DoT wykorzystuje TLS do zapewnienia szyfrowania, które hermetyzuje standardowe zapytania protokołu DNS, przy czym ruch wykorzystuje dobrze znany port 853 ( ). Protokół DoT został zaprojektowany, aby ułatwić organizacjom blokowanie ruchu na porcie lub akceptowanie ruchu, ale umożliwienie odszyfrowania na tym porcie.
Ryzyko związane z DoT
Google wdrożyło DoT w swoim kliencie , z domyślnym ustawieniem automatycznego korzystania z DoT, jeśli jest dostępny. Jeśli oceniłeś ryzyko i jesteś gotowy na użycie DoT na poziomie organizacyjnym, musisz poprosić administratorów sieci o wyraźne zezwolenie na ruch wychodzący na porcie 853 przez ich obwód dla tego nowego protokołu.
Zapewnienie widoczności i kontroli ruchu DoT
Jako najlepszą praktykę kontroli DoT zalecamy dowolne z powyższych rozwiązań, w zależności od wymagań Twojej organizacji:
-
Skonfiguruj NGFW do odszyfrowania całego ruchu dla portu docelowego 853. Po odszyfrowaniu ruchu DoT pojawi się jako aplikacja DNS, do której możesz zastosować dowolną akcję, np. włączyć subskrypcję do kontrolowania domen DGA lub już istniejącej i oprogramowanie antyszpiegowskie.
-
Alternatywą jest całkowite zablokowanie przez silnik App-ID ruchu „dns-over-tls” na porcie 853. Zwykle jest to domyślnie blokowane i nie jest wymagane żadne działanie (chyba że wyraźnie zezwolisz na ruch aplikacji lub portu „dns-over-tls” 853).
Źródło: www.habr.com