{"id":97349,"date":"2020-10-17T14:42:14","date_gmt":"2020-10-17T12:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh"},"modified":"2020-10-17T14:42:14","modified_gmt":"2020-10-17T12:42:14","slug":"minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimalizacja ryzyka zwi\u0105zanego z u\u017cyciem DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MinimalizacjaMinimalizacja ryzyka zwi\u0105zanego z u\u017cyciem DoH i DoT<\/p>\n

Ochrona przed DoH i DoT<\/h2>\n

Czy kontrolujesz sw\u00f3j ruch DNS? Organizacje inwestuj\u0105 du\u017co czasu, pieni\u0119dzy i wysi\u0142k\u00f3w w zapewnienie bezpiecze\u0144stwa swoich sieci. Jednak jedn\u0105 z dziedzin, kt\u00f3ra cz\u0119sto jest pomijana, jest DNS. <\/p>\n

Dobrym przegl\u0105dem ryzyk zwi\u0105zanych z DNS jest prezentacja Verisign<\/a><\/noindex> na konferencji Infosecurity. <\/p>\n

\"Minimalizacja31% badanych klas ransomware u\u017cywa\u0142o DNS do wymiany kluczy. Wnioski z badania<\/p>\n

31% badanych klas ransomware u\u017cywa\u0142o DNS do wymiany kluczy.<\/p>\n

Problem jest powa\u017cny. Wed\u0142ug badawczej laboratorium Palo Alto Networks Unit 42, oko\u0142o 85% z\u0142o\u015bliwego oprogramowania u\u017cywa DNS do ustanawiania kana\u0142u zarz\u0105dzania i kontroli, umo\u017cliwiaj\u0105c cyberprzest\u0119pcom \u0142atwe wprowadzanie z\u0142o\u015bliwego oprogramowania do twojej sieci oraz kradzie\u017c danych. Od czas\u00f3w swojego powstania ruch DNS by\u0142 g\u0142\u00f3wnie nieszyfrowany i \u0142atwy do monitorowania przez mechanizmy zabezpiecze\u0144 NGFW. <\/p>\n

Pojawi\u0142y si\u0119 nowe protoko\u0142y dla DNS, maj\u0105ce na celu zwi\u0119kszenie prywatno\u015bci po\u0142\u0105cze\u0144 DNS. S\u0105 one aktywnie wspierane przez wiod\u0105cych dostawc\u00f3w przegl\u0105darek oraz innych dostawc\u00f3w oprogramowania. Wkr\u00f3tce w sieciach korporacyjnych nast\u0105pi wzrost zaszyfrowanego ruchu DNS. Zaszyfrowany ruch DNS, kt\u00f3ry nie jest odpowiednio analizowany i dozwolony, stanowi zagro\u017cenie dla bezpiecze\u0144stwa firmy. Przyk\u0142adem takiego zagro\u017cenia s\u0105 kryptolokery, kt\u00f3re wykorzystuj\u0105 DNS do wymiany kluczy szyfrowania. Napastnicy teraz \u017c\u0105daj\u0105 okup\u00f3w w wysoko\u015bci kilku milion\u00f3w dolar\u00f3w za przywr\u00f3cenie dost\u0119pu do Twoich danych. W firmie Garmin na przyk\u0142ad zap\u0142acono 10 milion\u00f3w dolar\u00f3w.<\/p>\n

Przy odpowiedniej konfiguracji NGFW mog\u0105 one zablokowa\u0107 lub chroni\u0107 u\u017cywanie DNS-over-TLS (DoT) i mog\u0105 by\u0107 u\u017cywane do zabronienia u\u017cywania DNS-over-HTTPS (DoH), co pozwala na analizowanie ca\u0142ego ruchu DNS w twojej sieci.<\/p>\n

Czym jest zaszyfrowany DNS?<\/h2>\n

Czym jest DNS<\/p>\n

System nazw domen (DNS) przekszta\u0142ca czytelne dla cz\u0142owieka nazwy domen (na przyk\u0142ad adres www.paloaltonetworks.com<\/a><\/noindex> ) do adres\u00f3w IP (na przyk\u0142ad 34.107.151.202). Gdy u\u017cytkownik wpisuje nazw\u0119 domeny w przegl\u0105dark\u0119, przegl\u0105darka wysy\u0142a zapytanie DNS do serwera DNS, prosz\u0105c o adres IP powi\u0105zany z t\u0105 nazw\u0105 domeny. W odpowiedzi serwer DNS zwraca adres IP, kt\u00f3ry b\u0119dzie u\u017cywany przez t\u0119 przegl\u0105dark\u0119.<\/p>\n

Zapytania i odpowiedzi DNS s\u0105 przesy\u0142ane przez sie\u0107 jako zwyk\u0142y tekst w otwartym formacie, co czyni je podatnymi na szpiegowanie lub modyfikacj\u0119 odpowiedzi oraz przekierowanie przegl\u0105darki na z\u0142o\u015bliwe serwery. Szyfrowanie DNS utrudnia \u015bledzenie zapyta\u0144 DNS lub ich modyfikacj\u0119 w trakcie przesy\u0142ania. Szyfrowanie zapyta\u0144 i odpowiedzi DNS chroni Ci\u0119 przed atakiem Man-in-the-Middle, przy jednoczesnym realizowaniu tych samych funkcji, co tradycyjny protok\u00f3\u0142 DNS (system nazw domenowych) w otwartym tek\u015bcie. <\/p>\n

W ci\u0105gu ostatnich kilku lat wprowadzono dwa protoko\u0142y szyfrowania DNS:<\/p>\n

    \n
  1. \n

    DNS-over-HTTPS (DoH)<\/p>\n<\/li>\n

  2. \n

    DNS-over-TLS (DoT) <\/p>\n<\/li>\n<\/ol>\n

    Te protoko\u0142y maj\u0105 jeden wsp\u00f3lny mianownik: celowo ukrywaj\u0105 zapytania DNS przed jakimkolwiek przechwyceniem\u2026 w tym r\u00f3wnie\u017c przed osobami odpowiedzialnymi za bezpiecze\u0144stwo w organizacji. Protoko\u0142y g\u0142\u00f3wnie wykorzystuj\u0105 protok\u00f3\u0142 TLS (Transport Layer Security) do nawi\u0105zania szyfrowanego po\u0142\u0105czenia mi\u0119dzy klientem, kt\u00f3ry wysy\u0142a zapytania, a serwerem, kt\u00f3ry rozwi\u0105zuje zapytania DNS, przez port, kt\u00f3ry zwykle nie jest u\u017cywany do ruchu DNS.<\/p>\n

    Prywatno\u015b\u0107 zapyta\u0144 DNS jest du\u017c\u0105 zalet\u0105 tych protoko\u0142\u00f3w. Jednak stwarzaj\u0105 one problemy dla dzia\u0142\u00f3w bezpiecze\u0144stwa, kt\u00f3re musz\u0105 monitorowa\u0107 ruch sieciowy i wykrywa\u0107 oraz blokowa\u0107 z\u0142o\u015bliwe po\u0142\u0105czenia. Poniewa\u017c protoko\u0142y r\u00f3\u017cni\u0105 si\u0119 sposobem implementacji, metody analizy b\u0119d\u0105 r\u00f3\u017cne w przypadku DoH i DoT.<\/p>\n

    DNS over HTTPS (DoH)<\/h2>\n

    \"MinimalizacjaDNS w HTTPS<\/p>\n

    DoH wykorzystuje dobrze znany port 443 do HTTPS, dla kt\u00f3rego w RFC wyra\u017anie zaznaczone jest, \u017ce celem jest \"mieszanie ruchu DoH z innym ruchem HTTPS w tym samym po\u0142\u0105czeniu\", \"utrudnienie analizy ruchu DNS\" oraz w ten spos\u00f3b obej\u015bcie \u015brodk\u00f3w kontroli korporacyjnej ( RFC 8484 DoH, sekcja 8.1<\/a><\/noindex> ). Protok\u00f3\u0142 DoH wykorzystuje szyfrowanie TLS oraz sk\u0142adni\u0119 zapyta\u0144 dostarczon\u0105 przez wsp\u00f3lne standardy HTTPS i HTTP\/2, dodaj\u0105c zapytania i odpowiedzi DNS na szczycie standardowych zapyta\u0144 HTTP.<\/p>\n

    Zagro\u017cenia zwi\u0105zane z DoH<\/h2>\n

    Je\u015bli nie potrafisz odr\u00f3\u017cni\u0107 zwyk\u0142ego ruchu HTTPS od zapyta\u0144 DoH, aplikacje w twojej organizacji mog\u0105 (i b\u0119d\u0105) omija\u0107 lokalne ustawienia DNS, przekierowuj\u0105c zapytania do zewn\u0119trznych serwer\u00f3w obs\u0142uguj\u0105cych zapytania DoH, co uniemo\u017cliwia wszelkie monitorowanie, a wi\u0119c niszczy mo\u017cliwo\u015b\u0107 kontroli ruchu DNS. W idealnym przypadku powiniene\u015b kontrolowa\u0107 DoH, korzystaj\u0105c z funkcji deszyfrowania HTTPS. <\/p>\n

    I Google i Mozilla wdro\u017cy\u0142y funkcjonalno\u015bci DoH<\/a><\/noindex> w najnowszych wersjach swoich przegl\u0105darek, a obie firmy pracuj\u0105 nad wykorzystywaniem DoH domy\u015blnie dla wszystkich zapyta\u0144 DNS. Microsoft r\u00f3wnie\u017c opracowuje plany<\/a><\/noindex> integracji DoH ze swoimi systemami operacyjnymi. Minusem jest to, \u017ce nie tylko szanowane firmy programistyczne, ale tak\u017ce przest\u0119pcy zacz\u0119li wykorzystywa\u0107 DoH jako \u015brodek omijania tradycyjnych zabezpiecze\u0144 firewalli korporacyjnych. (Na przyk\u0142ad, zajrzyj do nast\u0119puj\u0105cych artyku\u0142\u00f3w: PsiXBot teraz korzysta z Google DoH<\/a><\/noindex> , PsiXBot nadal si\u0119 rozwija z zaktualizowan\u0105 infrastruktur\u0105 DNS<\/a><\/noindex> i analiza backdoora Godlua<\/a><\/noindex> .) W ka\u017cdym razie zar\u00f3wno poprawny, jak i z\u0142o\u015bliwy ruch DoH pozostan\u0105 niewidoczne, pozostawiaj\u0105c organizacj\u0119 \u015blep\u0105 na z\u0142o\u015bliwe wykorzystanie DoH jako kana\u0142u do zarz\u0105dzania z\u0142o\u015bliwym oprogramowaniem (C2) i kradzie\u017cy poufnych danych.<\/p>\n

    Zapewnienie widoczno\u015bci i kontroli ruchu DoH<\/h2>\n

    Jako najlepsze rozwi\u0105zanie do kontrolowania DoH zalecamy skonfigurowanie w NGFW deszyfrowania ruchu HTTPS i zablokowanie ruchu DoH (nazwa aplikacji: dns-over-https). <\/p>\n

    Po pierwsze, upewnij si\u0119, \u017ce NGFW jest skonfigurowane do deszyfrowania HTTPS, zgodnie z przewodnikiem najlepszych praktyk deszyfrowania<\/a><\/noindex>.<\/p>\n

    Po drugie, stw\u00f3rz regu\u0142\u0119 dla ruchu aplikacji \u00bbdns-over-https\u00ab, jak pokazano poni\u017cej:<\/p>\n

    \"MinimalizacjaRegu\u0142a Palo Alto Networks NGFW do blokowania DNS-over-HTTPS<\/p>\n

    Jako alternatywne rozwi\u0105zanie (je\u015bli twoja organizacja nie wdro\u017cy\u0142a jeszcze w pe\u0142ni deszyfrowania HTTPS) NGFW mo\u017cna skonfigurowa\u0107 do zastosowania dzia\u0142ania \u00bbzabro\u0144\u00ab dla identyfikatora aplikacji \u00bbdns-over-https\u00ab, ale efekt b\u0119dzie ograniczony do blokady niekt\u00f3rych dobrze znanych serwer\u00f3w DoH po ich nazwie domeny, poniewa\u017c bez deszyfrowania HTTPS ruch DoH nie mo\u017ce by\u0107 w pe\u0142ni weryfikowany (zob.  Applipedia od Palo Alto Networks<\/a><\/noindex>   i wyszukaj fraz\u0119 \u00bbdns-over-https\u00ab).<\/p>\n

    DNS przez TLS (DoT)<\/h2>\n

    \"MinimalizacjaDNS wewn\u0105trz TLS<\/p>\n

    Podczas gdy protok\u00f3\u0142 DoH stara si\u0119 wmiesza\u0107 w inny ruch na tym samym porcie, DoT zamiast tego domy\u015blnie korzysta z wyznaczonego portu, zarezerwowanego na t\u0119 jedyn\u0105 okoliczno\u015b\u0107, jednocze\u015bnie specjalnie zakazuj\u0105c u\u017cywania tego samego portu dla tradycyjnego, niezaszyfrowanego ruchu DNS ( RFC 7858, rozdzia\u0142 3.1<\/a><\/noindex> ).<\/p>\n

    Protok\u00f3\u0142 DoT korzysta z protoko\u0142u TLS w celu zapewnienia szyfrowania, kt\u00f3re kapsu\u0142kuje standardowe zapytania protoko\u0142u DNS, z ruchem u\u017cywaj\u0105cym dobrze znanego portu 853 ( RFC 7858, rozdzia\u0142 6<\/a><\/noindex> ). Protok\u00f3\u0142 DoT zosta\u0142 zaprojektowany w celu uproszczenia organizacjom blokowania ruchu przez port lub zaakceptowania jego u\u017cycia, a nast\u0119pnie w\u0142\u0105czenia deszyfrowania na tym porcie.<\/p>\n

    Zagro\u017cenia zwi\u0105zane z DoT<\/h2>\n

    Google zaimplementowa\u0142 DoT w swoim kliencie Android 9 Pie i nowszych wersjach<\/a><\/noindex> , przy tym domy\u015blnie w\u0142\u0105czona jest opcja automatycznego korzystania z DoT, je\u015bli jest dost\u0119pna. Je\u015bli ocenili\u015bcie zagro\u017cenia i jeste\u015bcie gotowi do korzystania z DoT na poziomie organizacyjnym, to administratorzy sieci musz\u0105 wyra\u017anie zezwoli\u0107 na wychodz\u0105cy ruch na port 853 przez sw\u00f3j perimeter dla tego nowego protoko\u0142u.<\/p>\n

    Zapewnienie widoczno\u015bci i kontroli ruchu DoT<\/h2>\n

    Jako najlepsza praktyka kontroli DoT, rekomendujemy dowoln\u0105 z powy\u017cszych metod, w zale\u017cno\u015bci od wymaga\u0144 waszej organizacji:<\/p>\n