Мінімізацыя рызык выкарыстання DoH і DoT
Абарона ад DoH і DoT
Ці кантралюеце вы свой DNS трафік? Арганізацыі ўкладваюць шмат часу, грошай і намаганняў у гарантаванне бяспекі сваіх сетак. Аднак, адной з абласцей, якой часта не надаецца належнай увагі, з'яўляецца DNS.
Добрым аглядам рызык, якія прыносіць DNS з'яўляецца на канферэнцыі Infosecurity.
31% абследаваных класаў праграм-вымагальнікаў выкарыстоўвалі DNS для абмену ключамі. Высновы даследавання
31% абследаваных класаў праграм-вымагальнікаў выкарыстоўвалі DNS для абмену ключамі.
Праблема сур'ёзная. Па дадзеных даследчай лабараторыі Palo Alto Networks Unit 42, прыкладна 85% шкоднасных праграм выкарыстоўваюць DNS для ўсталявання канала кіравання і кантролю, дазваляючы зламыснікам лёгка ўкараняць шкоднасныя праграмы ў вашу сетку, а таксама выкрадаць дадзеныя. З моманту свайго стварэння трафік DNS у асноўным быў незашыфраваным і яго лёгка можна было аналізаваць ахоўнымі механізмамі NGFW.
З'явіліся новыя пратаколы для DNS, накіраваныя на падвышэнне канфідэнцыйнасці DNS злучэнняў. Яны актыўна падтрымліваюцца кіроўнымі пастаўшчыкамі браўзэраў і іншымі пастаўшчыкамі праграмнага забеспячэння. Хутка ў карпаратыўных сетках пачнецца рост зашыфраванага DNS-трафіку. Зашыфраваны трафік DNS, які не аналізуецца сродкамі належным чынам і дазволены, уяўляе пагрозу бяспецы для кампаніі. Напрыклад, такой пагрозай з'яўляюцца крыпталокеры, якія выкарыстоўваюць DNS для абмену ключамі шыфравання. Атакуючыя зараз патрабуюць выкуп у некалькі мільёнаў даляраў за аднаўленне доступу да вашых дадзеных. У кампаніі Garmin, напрыклад, заплацілі 10 мільёнаў долараў.
Пры правільнай наладзе NGFW могуць забараняць або абараняць выкарыстанне DNS-over-TLS (DoT) і могуць выкарыстоўвацца для забароны выкарыстання DNS-over-HTTPS (DoH), што дазваляе аналізаваць увесь трафік DNS у вашай сетцы.
Што такое зашыфраваны DNS?
Што такое DNS
Сістэма даменных імёнаў (DNS) пераўтворыць лёгкачытальныя чалавеку даменныя імёны (напрыклад, адрас ) у IP-адрасы (напрыклад, у 34.107.151.202). Калі карыстач уводзіць даменнае імя ў вэб-браўзэры, браўзэр адпраўляе DNS-запыт на DNS-сервер, запытваючы IP-адрас, злучаны з гэтым даменным імем. У адказ DNS-сервер вяртае IP-адрас, які будзе выкарыстоўваць гэты браўзэр.
Запыты і адказы DNS перасылаюцца па сетцы ў выглядзе звычайнага тэксту ў незашыфраваным выглядзе, што робіць яго ўразлівым для шпіянажу або змены адказу і перанакіраванні браўзэра на шкоднасныя сервера. Шыфраванне DNS абцяжарвае адсочванне DNS-запытаў ці іх змена падчас перадачы. Шыфраванне DNS запытаў і адказаў абараняе вас ад нападу Man-in-the-Middle, выконваючы пры гэтым тыя ж функцыі, што і традыцыйны пратакол DNS (сістэма даменных імёнаў) з адчыненым тэкстам.
За апошнія некалькі гадоў былі ўкаранёны два пратаколы шыфравання DNS:
-
DNS-over-HTTPS (DoH)
-
DNS-over-TLS (DoT)
Гэтыя пратаколы маюць адну агульную рысу: наўмысна хаваюць DNS-запыты ад любога перахопу і ад бяспечнікаў арганізацыі ў тым ліку. Пратаколы ў асноўным выкарыстоўваюць пратакол TLS (Transport Layer Security) для ўсталявання зашыфраванага злучэння паміж кліентам, які выконвае запыты, і серверам, якія дазваляюць запыты DNS, праз порт, які звычайна не выкарыстоўваецца для трафіку DNS.
Канфідэнцыяльнасць запытаў DNS з'яўляецца вялікім плюсам гэтых пратаколаў. Аднак, яны ствараюць праблемы бяспечнікам, якія павінны сачыць за сеткавым трафікам і выяўляць і блакаваць шкоднасныя злучэнні. Паколькі пратаколы адрозніваюцца па сваёй рэалізацыі, метады аналізу будуць адрознівацца ў DoH і DoT.
DNS праз HTTPS (DoH)
DNS ўнутры HTTPS
DoH выкарыстоўвае добра вядомы порт 443 для HTTPS, для якога ў RFC адмыслова паказана, што задача складаецца ў тым, каб "змяшаць трафік DoH з іншым трафікам HTTPS у адным і тым жа злучэнні", "ускладніць аналіз трафіку DNS" і, такім чынам, абысці меры карпаратыўнага кантролю ( ). Пратакол DoH выкарыстоўвае шыфраванне TLS і сінтаксіс запытаў, які прадстаўляецца агульнымі стандартамі HTTPS і HTTP/2, дадаючы запыты і адказы DNS па-над стандартнымі запытамі HTTP.
Рызыкі, звязаныя з DoH
Калі вы не можаце адрозніць звычайны HTTPS-трафік ад запытаў DoH, то прыкладанні ўсярэдзіне вашай арганізацыі могуць (і будуць) абыходзіць лакальныя налады DNS, перанакіроўваючы запыты на іншыя серверы якія адказваюць на запыты DoH, што абыходзіць любы маніторынг, гэта значыць знішчае магчымасць кантролю за DNS трафікам. У ідэале вы павінны кантраляваць DoH выкарыстоўваючы функцыі расшыфравання HTTPS.
И у апошняй версіі сваіх браўзэраў, і абедзве кампаніі працуюць над выкарыстаннем DoH па змаўчанні для ўсіх запытаў DNS. па інтэграцыі DoH у свае аперацыйныя сістэмы. Мінусам з'яўляецца тое, што не толькі паважаныя кампаніі-распрацоўшчыкі праграмнага забеспячэння, але і зламыснікі пачалі выкарыстоўваць DoH як сродак абыходу традыцыйных мер карпаратыўнага міжсеткавага экрана. ( Напрыклад, праглядзіце наступныя артыкулы: , и .) У любым выпадку, як добры, так і шкоднасны трафік DoH застанецца незаўважаным, пакінуўшы арганізацыю сляпой да зламыснага выкарыстання DoH у якасці канала для кіравання шкоднасным ПА (C2) і крадзяжы канфідэнцыйных дадзеных.
Забеспячэнне бачнасці і кантролю трафіку DoH
У якасці найлепшага рашэння для кантролю DoH мы рэкамендуем наладзіць у NGFW расшыфроўку трафіку HTTPS і блакаванне трафіку DoH (назва дадатку: dns-over-https).
Па-першае, пераканайцеся, што NGFW настроены для расшыфроўкі HTTPS, паводле .
Па-другое, стварыце правіла для трафіку прыкладання "dns-over-https", як паказана ніжэй:
Правіла Palo Alto Networks NGFW для блакавання DNS-over-HTTPS
У якасці прамежкавай альтэрнатывы (калі ваша арганізацыя не цалкам рэалізавала расшыфраванне HTTPS) NGFW можна наладзіць для ўжывання дзеянні "забараніць" да ідэнтыфікатара прыкладання "dns-over-https", але эфект будзе абмежаваны блакіроўкай пэўных добра вядомых сервераў DoH па іх даменным імі, так як без расшыфравання HTTPS трафік DoH не можа быць цалкам правераны (гл. і выканайце пошук па фразе «dns-over-https»).
DNS over TLS (DoT)
DNS ўнутры TLS
У той час як пратакол DoH імкнецца змешвацца з іншым трафікам на тым жа порце, DoT замест гэтага па змаўчанні выкарыстоўвае спецыяльны порт, зарэзерваваны для гэтай адзінай мэты, нават спецыяльна забараняючы выкарыстанне таго ж порта для традыцыйнага незашыфраванага трафіку DNS ( ).
Пратакол DoT выкарыстоўвае пратакол TLS для забеспячэння шыфравання, инкапсулирующего стандартныя запыты пратаколу DNS, з трафікам, выкарыстоўвалым добра вядомы порт 853 ( ). Пратакол DoT быў распрацаваны, каб спрасціць арганізацыям блакаваць трафік па порце, альбо згаджацца на яго выкарыстанне, але ўключыць расшыфроўку на гэтым порце.
Рызыкі, звязаныя з DoT
Google рэалізаваў DoT у сваім кліенце , пры гэтым па змаўчанні ўключана настройка аўтаматычнага выкарыстання DoT, калі ён даступны. Калі вы ацанілі рыскі і гатовыя да выкарыстання DoT на ўзроўні арганізацыі, то трэба, каб сеткавыя адміністратары відавочна дазвалялі выходны трафік на порт 853 праз свой перыметр для гэтага новага пратаколу.
Забеспячэнне бачнасці і кантролю трафіку DoT
У якасці найлепшай методыкі кантролю за DoT мы рэкамендуем любое з вышэйпералічанага, зыходзячы з патрабаванняў вашай арганізацыі:
-
Наладзьце NGFW для расшыфравання ўсяго трафіку для порта прызначэння 853. Дзякуючы расшыфраванню трафіку, DoT будзе адлюстроўвацца як прыкладанне DNS, да якога вы можаце прымяніць любое дзеянне, напрыклад, уключыць падпіску для кантролю DGA даменаў ці ўжо наяўны і anti-spyware.
-
У якасці альтэрнатывы можна цалкам заблакаваць рухавічком App-ID трафік 'dns-over-tls' праз порт 853. Звычайна ён заблакаваны па змаўчанні, ніякіх дзеянняў не патрабуецца (калі вы спецыяльна не дазволілі прыкладанне 'dns-over-tls' або трафік праз порт 853).
Крыніца: habr.com