{"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\/sk\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimalizace rizik pou\u017e\u00edv\u00e1n\u00ed DNS-over-TLS (DoT) a DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MinimalizaceMinimaliz\u00e1cia riz\u00edk spojen\u00fdch s DoH a DoT<\/p>\n

Ochrana pred DoH a DoT<\/h2>\n

Kontrolujete svoj DNS prenos? Organiz\u00e1cie investuj\u00fa ve\u013ea \u010dasu, pe\u0148az\u00ed a \u00fasilia do zabezpe\u010denia svojich siet\u00ed. Av\u0161ak, jednou z oblast\u00ed, ktorej sa \u010dasto nevenuje dostato\u010dn\u00e1 pozornos\u0165, je DNS. <\/p>\n

Dobr\u00fdm preh\u013eadom riz\u00edk spojen\u00fdch s DNS je prezent\u00e1cia Verisign<\/a><\/noindex> na konferencii Infosecurity. <\/p>\n

\"Minimalizace31 % sk\u00faman\u00fdch tried ransomv\u00e9ru vyu\u017e\u00edvalo DNS na v\u00fdmenu k\u013e\u00fa\u010dov. Zistenia \u0161t\u00fadie<\/p>\n

31 % sk\u00faman\u00fdch tried ransomv\u00e9ru vyu\u017e\u00edvalo DNS na v\u00fdmenu k\u013e\u00fa\u010dov.<\/p>\n

Probl\u00e9m je v\u00e1\u017eny. Pod\u013ea v\u00fdskumnej laborat\u00f3ria Palo Alto Networks Unit 42, pribli\u017ene 85 % \u0161kodliv\u00e9ho softv\u00e9ru vyu\u017e\u00edva DNS na vytvorenie riadiaceho a kontroln\u00e9ho kan\u00e1la, \u010do \u00fato\u010dn\u00edkom umo\u017e\u0148uje \u013eahko zav\u00e1dza\u0165 \u0161kodliv\u00e9 programy do va\u0161ej siete a tie\u017e kradn\u00fa\u0165 \u00fadaje. Od svojho vzniku bol prenos DNS preva\u017ene neza\u0161ifrovan\u00fd a jeho anal\u00fdza ochrann\u00fdmi mechanizmami NGFW bola jednoduch\u00e1. <\/p>\n

Objavili sa nov\u00e9 protokoly pre DNS, zameran\u00e9 na zvy\u0161ovanie d\u00f4vernosti DNS pripojen\u00ed. Akt\u00edvne ich podporuj\u00fa popredn\u00ed poskytovatelia prehliada\u010dov a \u010fal\u0161\u00ed dod\u00e1vatelia softv\u00e9ru. \u010coskoro d\u00f4jde v podnikov\u00fdch sie\u0165ach k n\u00e1rastu \u0161ifrovan\u00e9ho DNS prev\u00e1dzky. \u0160ifrovan\u00fd DNS prev\u00e1dzka, ktor\u00e1 nie je n\u00e1le\u017eite analyzovan\u00e1 a je povolen\u00e1, predstavuje bezpe\u010dnostn\u00fa hrozbu pre spolo\u010dnos\u0165. Napr\u00edklad, takou hrozbou s\u00fa kryptolockery, ktor\u00e9 vyu\u017e\u00edvaj\u00fa DNS na v\u00fdmenu \u0161ifrovac\u00edch k\u013e\u00fa\u010dov. \u00dato\u010dn\u00edci teraz po\u017eaduj\u00fa v\u00fdkupn\u00e9 vo v\u00fd\u0161ke nieko\u013ek\u00fdch mili\u00f3nov dol\u00e1rov za obnovenie pr\u00edstupu k va\u0161im \u00fadajom. V spolo\u010dnosti Garmin napr\u00edklad zaplatili 10 mili\u00f3nov dol\u00e1rov.<\/p>\n

Pri spr\u00e1vnom nastaven\u00ed m\u00f4\u017eu NGFW zakazova\u0165 alebo chr\u00e1ni\u0165 pou\u017e\u00edvanie DNS-over-TLS (DoT) a m\u00f4\u017eu sa pou\u017e\u00edva\u0165 na z\u00e1kaz vyu\u017e\u00edvania DNS-over-HTTPS (DoH), \u010do umo\u017e\u0148uje analyzova\u0165 cel\u00fd DNS prenos vo va\u0161ej sieti.<\/p>\n

\u010co je \u0161ifrovan\u00fd DNS?<\/h2>\n

\u010co je DNS<\/p>\n

Syst\u00e9m dom\u00e9nov\u00fdch mien (DNS) prev\u00e1dza \u010dloveku zrozumite\u013en\u00e9 dom\u00e9nov\u00e9 men\u00e1 (napr\u00edklad adresu www.paloaltonetworks.com<\/a><\/noindex> ) na IP adresu (napr\u00edklad 34.107.151.202). Ke\u010f pou\u017e\u00edvate\u013e zad\u00e1 dom\u00e9nov\u00e9 meno do webov\u00e9ho prehliada\u010da, prehliada\u010d odo\u0161le DNS dopyt na DNS server, aby zistil IP adresu spojen\u00fa s t\u00fdmto dom\u00e9nov\u00fdm menom. V odpovedi DNS server vr\u00e1ti IP adresu, ktor\u00fa prehliada\u010d pou\u017eije.<\/p>\n

DNS dopyty a odpovede s\u00fa pren\u00e1\u0161an\u00e9 sie\u0165ou vo forme be\u017en\u00e9ho textu v neza\u0161ifrovanej podobe, \u010do ich rob\u00ed zranite\u013en\u00fdmi vo\u010di \u0161pehovaniu alebo zmene odpovede a presmerovaniu prehliada\u010da na \u0161kodliv\u00e9 servery. \u0160ifrovanie DNS s\u0165a\u017euje sledovanie DNS dopytov alebo ich zmenu po\u010das prenosu. \u0160ifrovanie DNS dopytov a odpoved\u00ed v\u00e1s chr\u00e1ni pred \u00fatokom typu Man-in-the-Middle, pri\u010dom vykon\u00e1va rovnak\u00e9 funkcie ako tradi\u010dn\u00fd protokol DNS (syst\u00e9m dom\u00e9nov\u00fdch mien) v otvorenom texte. <\/p>\n

V posledn\u00fdch nieko\u013ek\u00fdch rokoch boli zaveden\u00e9 dva protokoly \u0161ifrovania 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

    Tieto protokoly maj\u00fa jednu spolo\u010dn\u00fa \u010drtu: \u00famyselne skr\u00fdvaj\u00fa DNS po\u017eiadavky pred ak\u00fdmko\u013evek zachyten\u00edm\u2026 a aj pred bezpe\u010dnostn\u00fdmi pracovn\u00edkmi organiz\u00e1cie. Protokoly v\u00e4\u010d\u0161inou vyu\u017e\u00edvaj\u00fa protokol TLS (Transport Layer Security) na vytvorenie \u0161ifrovan\u00e9ho spojenia medzi klientom, ktor\u00fd vykon\u00e1va po\u017eiadavky, a serverom, ktor\u00fd rie\u0161i DNS po\u017eiadavky, cez port, ktor\u00fd sa zvy\u010dajne nepou\u017e\u00edva na DNS prev\u00e1dzku.<\/p>\n

    Ochrana s\u00fakromia DNS dopytov je ve\u013ek\u00fdm pozit\u00edvom t\u00fdchto protokolov. Av\u0161ak vytv\u00e1raj\u00fa probl\u00e9my pre bezpe\u010dnostn\u00fdch pracovn\u00edkov, ktor\u00ed musia sledova\u0165 sie\u0165ov\u00fd prenos a odha\u013eova\u0165 a blokova\u0165 \u0161kodliv\u00e9 spojenia. Ke\u010f\u017ee sa protokoly l\u00ed\u0161ia v svojej implement\u00e1cii, met\u00f3dy anal\u00fdzy sa pri DoH a DoT bud\u00fa l\u00ed\u0161i\u0165.<\/p>\n

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

    \"MinimalizaceDNS v r\u00e1mci HTTPS<\/p>\n

    DoH pou\u017e\u00edva dobre zn\u00e1my port 443 pre HTTPS, pre ktor\u00fd je v RFC \u0161pecificky uveden\u00e9, \u017ee \u00falohou je \"zmie\u0161a\u0165 DoH prenos s \u010fal\u0161\u00edm HTTPS prenosom v jednom a tom istom spojen\u00ed\", \"s\u0165a\u017ei\u0165 anal\u00fdzu DNS prenosu\" a tak ob\u00eds\u0165 opatrenia firemnej kontroly ( RFC 8484 DoH, sekcia 8.1<\/a><\/noindex> ). Protokol DoH vyu\u017e\u00edva \u0161ifrovanie TLS a syntax dopytov poskytovan\u00fdch be\u017en\u00fdmi \u0161tandardmi HTTPS a HTTP\/2, pri\u010dom prid\u00e1va dopyty a odpovede DNS nad \u0161tandardn\u00e9 dopyty HTTP.<\/p>\n

    Rizik\u00e1 spojen\u00e9 s DoH<\/h2>\n

    Ak nem\u00f4\u017eete odl\u00ed\u0161i\u0165 be\u017en\u00fd HTTPS prenos od DoH po\u017eiadaviek, aplik\u00e1cie vo va\u0161ej organiz\u00e1cii m\u00f4\u017eu (a bud\u00fa) obch\u00e1dza\u0165 miestne DNS nastavenia, presmerovan\u00edm po\u017eiadaviek na extern\u00e9 servery, ktor\u00e9 odpovedaj\u00fa na DoH po\u017eiadavky, \u010d\u00edm sa obch\u00e1dza ak\u00e9ko\u013evek monitorovanie, teda sa ni\u010d\u00ed mo\u017enos\u0165 kontroly nad DNS prenosom. Ide\u00e1lne by ste mali kontrolova\u0165 DoH pomocou funkci\u00ed de\u0161ifrovania HTTPS. <\/p>\n

    A Google a Mozilla implementovali mo\u017enosti DoH<\/a><\/noindex> v poslednej verzii svojich prehliada\u010dov a obe spolo\u010dnosti pracuj\u00fa na tom, aby DoH bolo predvolen\u00e9 pre v\u0161etky DNS po\u017eiadavky. Microsoft tie\u017e vyv\u00edja pl\u00e1ny<\/a><\/noindex> na integr\u00e1ciu DoH do svojich opera\u010dn\u00fdch syst\u00e9mov. Nev\u00fdhodou je, \u017ee nielen re\u0161pektovan\u00e9 spolo\u010dnosti vyv\u00edjaj\u00face softv\u00e9r, ale aj zlo\u010dinci za\u010dali pou\u017e\u00edva\u0165 DoH ako prostriedok na obch\u00e1dzanie tradi\u010dn\u00fdch opatren\u00ed firewalu. (Napr\u00edklad si pre\u010d\u00edtajte nasleduj\u00face \u010dl\u00e1nky: PsiXBot teraz pou\u017e\u00edva Google DoH<\/a><\/noindex> , PsiXBot sa aj na\u010falej vyv\u00edja s aktualizovanou DNS infra\u0161trukt\u00farou<\/a><\/noindex> a anal\u00fdza backdooru Godlua<\/a><\/noindex> .) V ka\u017edom pr\u00edpade, ako dobr\u00fd, tak aj \u0161kodliv\u00fd DoH prenos zostane nepov\u0161imnut\u00fd, \u010do ponech\u00e1 organiz\u00e1ciu slep\u00fa vo\u010di zneu\u017e\u00edvaniu DoH ako kan\u00e1lu pre riadenie malv\u00e9ru (C2) a kr\u00e1de\u017e citliv\u00fdch \u00fadajov.<\/p>\n

    Zabezpe\u010denie vidite\u013enosti a kontroly DoH prenosu<\/h2>\n

    Ako najlep\u0161ie rie\u0161enie na kontrolu DoH odpor\u00fa\u010dame nastavi\u0165 v NGFW de\u0161ifrovanie HTTPS prenosu a blokovanie DoH prenosu (n\u00e1zov aplik\u00e1cie: dns-over-https). <\/p>\n

    Najsk\u00f4r sa uistite, \u017ee je NGFW nastaven\u00e9 na de\u0161ifrovanie HTTPS, pod\u013ea pr\u00edru\u010dky pre najlep\u0161ie postupy de\u0161ifrovania<\/a><\/noindex>.<\/p>\n

    Po druh\u00e9, vytvorte pravidlo pre prenos aplik\u00e1cie \u201edns-over-https\u201c, ako je uveden\u00e9 ni\u017e\u0161ie:<\/p>\n

    \"MinimalizacePravidlo Palo Alto Networks NGFW na blokovanie DNS-over-HTTPS<\/p>\n

    Ako medzi alternat\u00edvou (ak va\u0161a organiz\u00e1cia plne neimplementovala de\u0161ifrovanie HTTPS) m\u00f4\u017ee by\u0165 NGFW nastaven\u00e9 tak, aby uplatnilo akciu \u201ezablokova\u0165\u201c na identifik\u00e1tor aplik\u00e1cie \u201edns-over-https\u201c, ale \u00fa\u010dinok bude obmedzen\u00fd na blokovanie niektor\u00fdch dobre zn\u00e1mych DoH serverov na z\u00e1klade ich dom\u00e9nov\u00e9ho mena, preto\u017ee bez de\u0161ifrovania HTTPS nie je mo\u017en\u00e9 DoH prenos \u00faplne skontrolova\u0165 (pozri  Applipedia od Palo Alto Networks<\/a><\/noindex>   a vyh\u013eadajte fr\u00e1zu \u201edns-over-https\u201c).<\/p>\n

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

    \"MinimalizaceDNS v r\u00e1mci TLS<\/p>\n

    Zatia\u013e \u010do protokol DoH sa sna\u017e\u00ed mie\u0161a\u0165 s in\u00fdm prenosom na rovnakom porte, DoT namiesto toho predvolene pou\u017e\u00edva \u0161peci\u00e1lny port vyhraden\u00fd pre tento jedin\u00fd \u00fa\u010del, pri\u010dom \u0161peci\u00e1lne zakazuje pou\u017e\u00edvanie toho ist\u00e9ho portu pre tradi\u010dn\u00fd neza\u0161ifrovan\u00fd prenos DNS ( RFC 7858, \u010das\u0165 3.1<\/a><\/noindex> ).<\/p>\n

    Protokol DoT pou\u017e\u00edva protokol TLS na zabezpe\u010denie \u0161ifrovania, ktor\u00e9 enkapsuluje \u0161tandardn\u00e9 po\u017eiadavky protokolu DNS, s prenosom vyu\u017e\u00edvaj\u00facim dobre zn\u00e1my port 853 ( RFC 7858, \u010das\u0165 6<\/a><\/noindex> ). Protokol DoT bol navrhnut\u00fd tak, aby u\u013eah\u010dil organiz\u00e1ci\u00e1m blokovanie prev\u00e1dzky cez port, alebo s\u00fahlasi\u0165 s jeho pou\u017e\u00edvan\u00edm, ale zapn\u00fa\u0165 de\u0161ifrovanie na tomto porte.<\/p>\n

    Rizik\u00e1 spojen\u00e9 s DoT<\/h2>\n

    Google implementoval DoT vo svojom klientovi Android 9 Pie a neskor\u0161\u00edch verzi\u00e1ch<\/a><\/noindex> , pri\u010dom predvolene je zapnut\u00e1 mo\u017enos\u0165 automatick\u00e9ho pou\u017e\u00edvania DoT, ak je k dispoz\u00edcii. Ak ste zhodnotili rizik\u00e1 a ste pripraven\u00ed pou\u017e\u00edva\u0165 DoT na \u00farovni organiz\u00e1cie, spr\u00e1vcovia siet\u00ed by mali v\u00fdslovne povoli\u0165 odch\u00e1dzaj\u00faci prenos na port 853 cez svoj perimetr pre tento nov\u00fd protokol.<\/p>\n

    Zabezpe\u010denie vidite\u013enosti a kontroly prenosu DoT<\/h2>\n

    Ako najlep\u0161iu prax kontroly DoT odpor\u00fa\u010dame niektor\u00e9 z vy\u0161\u0161ie uveden\u00fdch, na z\u00e1klade po\u017eiadaviek va\u0161ej organiz\u00e1cie:<\/p>\n