Նվազագույնի հասցնել DNS-over-TLS (DoT) և DNS-over-HTTPS (DoH) օգտագործման ռիսկերը

Նվազագույնի հասցնելով DoH-ի և DoT-ի օգտագործման ռիսկերը

DoH և DoT պաշտպանություն

Դուք վերահսկու՞մ եք ձեր DNS տրաֆիկը: Կազմակերպությունները շատ ժամանակ, գումար և ջանք են ներդնում իրենց ցանցերն ապահովելու համար: Այնուամենայնիվ, մի տարածք, որը հաճախ բավարար ուշադրություն չի դարձնում, դա DNS-ն է:

DNS-ի հետ կապված ռիսկերի լավ ակնարկ է Verisign շնորհանդես 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) որոշում է մարդու կողմից ընթեռնելի տիրույթի անունները (օրինակ՝ հասցե www.paloaltonetworks.com ) IP հասցեներին (օրինակ՝ 34.107.151.202): Երբ օգտվողը մուտքագրում է տիրույթի անուն վեբ բրաուզերում, զննարկիչը DNS հարցում է ուղարկում DNS սերվերին՝ խնդրելով այդ տիրույթի անվան հետ կապված IP հասցեն: Ի պատասխան՝ DNS սերվերը վերադարձնում է IP հասցեն, որը կօգտագործի այս դիտարկիչը:

DNS հարցումներն ու պատասխանները ցանցով ուղարկվում են պարզ տեքստով, չգաղտնագրված, ինչը խոցելի է դարձնում լրտեսության կամ պատասխանը փոխելու և զննարկիչը վնասակար սերվերներին վերահղելու համար: DNS գաղտնագրումը դժվարացնում է DNS հարցումներին հետևել կամ փոխել փոխանցման ընթացքում: DNS հարցումների և պատասխանների գաղտնագրումը ձեզ պաշտպանում է Man-in-the-Middle հարձակումներից՝ միաժամանակ կատարելով նույն գործառույթը, ինչ ավանդական պարզ տեքստային DNS (Դոմեն Անվան Համակարգ) արձանագրությունը: 

Վերջին մի քանի տարիների ընթացքում ներդրվել են երկու DNS կոդավորման արձանագրություններ.

1. DNS-over-HTTPS (DoH)

2. 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 տրաֆիկի վերլուծությունը» և այդպիսով շրջանցել կորպորատիվ հսկողությունը։ ( RFC 8484 DoH Բաժին 8.1 ) DoH արձանագրությունն օգտագործում է TLS կոդավորումը և հարցումների շարահյուսությունը, որը տրամադրվում է ընդհանուր HTTPS և HTTP/2 ստանդարտներով՝ ավելացնելով DNS հարցումներ և պատասխաններ ստանդարտ HTTP հարցումների վրա:

DoH-ի հետ կապված ռիսկերը

Եթե ​​դուք չեք կարող տարբերակել սովորական HTTPS տրաֆիկը DoH հարցումներից, ապա ձեր կազմակերպության հավելվածները կարող են (և կանեն) շրջանցել տեղական DNS կարգավորումները՝ հարցումները վերահղելով երրորդ կողմի սերվերներին, որոնք արձագանքում են DoH հարցումներին, ինչը շրջանցում է ցանկացած մոնիտորինգ, այսինքն՝ ոչնչացնում է հնարավորությունը։ վերահսկել DNS տրաֆիկը: Իդեալում, դուք պետք է վերահսկեք DoH-ը՝ օգտագործելով HTTPS ապակոդավորման գործառույթները: 

И Google-ը և Mozilla-ն ներդրել են DoH-ի հնարավորությունները իրենց բրաուզերների վերջին տարբերակում, և երկու ընկերություններն էլ աշխատում են լռելյայն օգտագործել DoH բոլոր DNS հարցումների համար: Microsoft-ը նույնպես ծրագրեր է մշակում DoH-ն իրենց օպերացիոն համակարգերում ինտեգրելու մասին: Բացասական կողմն այն է, որ ոչ միայն ծրագրային ապահովման հեղինակավոր ընկերությունները, այլև հարձակվողները սկսել են օգտագործել DoH-ը որպես ավանդական կորպորատիվ firewall-ի միջոցները շրջանցելու միջոց: (Օրինակ, վերանայեք հետևյալ հոդվածները. PsiXBot-ն այժմ օգտագործում է Google DoH-ը , PsiXBot-ը շարունակում է զարգանալ թարմացված DNS ենթակառուցվածքով и Գոդլուա ետնադռան վերլուծություն .) Երկու դեպքում էլ, և՛ լավ, և՛ վնասակար DoH երթևեկությունը կմնա չբացահայտված՝ թողնելով կազմակերպությանը կույր՝ DoH-ի չարամիտ օգտագործումը որպես խողովակ՝ չարամիտ ծրագրերը (C2) վերահսկելու և զգայուն տվյալներ գողանալու համար:

DoH երթեւեկության տեսանելիության և վերահսկողության ապահովում

Որպես DoH կառավարման լավագույն լուծում՝ խորհուրդ ենք տալիս կարգավորել NGFW-ը՝ HTTPS տրաֆիկը վերծանելու և DoH երթևեկությունը արգելափակելու համար (հավելվածի անվանումը՝ dns-over-https): 

Նախ, համոզվեք, որ NGFW-ը կազմաձևված է HTTPS-ի վերծանման համար՝ համաձայն լավագույն ապակոդավորման տեխնիկայի ուղեցույց.

Երկրորդ, ստեղծեք «dns-over-https» հավելվածի տրաֆիկի կանոն, ինչպես ցույց է տրված ստորև.

Palo Alto Networks NGFW կանոն՝ DNS-ը HTTPS-ի միջոցով արգելափակելու համար

Որպես միջանկյալ այլընտրանք (եթե ձեր կազմակերպությունը ամբողջությամբ չի իրականացրել HTTPS ապակոդավորումը), NGFW-ն կարող է կազմաձևվել այնպես, որ կիրառի «մերժման» գործողություն «dns-over-https» հավելվածի ID-ի վրա, սակայն ազդեցությունը կսահմանափակվի որոշակի լավ-արգելափակմամբ: հայտնի DoH սերվերները իրենց տիրույթի անունով, այնպես որ ինչպես առանց HTTPS ապակոդավորման, DoH տրաֆիկը չի կարող ամբողջությամբ ստուգվել (տես  Applipedia Palo Alto Networks-ից   և որոնել «dns-over-https»):

DNS TLS-ով (DoT)

DNS TLS-ի ներսում

Թեև DoH արձանագրությունը հակված է խառնվել նույն նավահանգստի այլ տրաֆիկի հետ, փոխարենը DoT-ն օգտագործում է հատուկ պորտ, որը վերապահված է միայն այդ նպատակով, նույնիսկ հատուկ թույլ չի տալիս նույն նավահանգիստը օգտագործել ավանդական չգաղտնագրված DNS տրաֆիկով ( RFC 7858, Բաժին 3.1 ).

DoT արձանագրությունն օգտագործում է TLS՝ տրամադրելու գաղտնագրում, որը ներառում է ստանդարտ DNS արձանագրության հարցումները՝ երթևեկությամբ՝ օգտագործելով հայտնի պորտը 853 ( RFC 7858 բաժին 6 ) DoT արձանագրությունը ստեղծվել է կազմակերպությունների համար հեշտացնելու երթևեկությունը նավահանգստում արգելափակելը կամ երթևեկությունն ընդունելը, բայց այդ նավահանգստի վերծանումը միացնելու համար:

DoT-ի հետ կապված ռիսկերը

Google-ն իր հաճախորդի մեջ ներդրել է DoT Android 9 Pie և ավելի ուշ , եթե առկա է, ավտոմատ կերպով DoT օգտագործելու լռելյայն կարգավորումով: Եթե ​​դուք գնահատել եք ռիսկերը և պատրաստ եք օգտագործել DoT-ը կազմակերպչական մակարդակում, ապա դուք պետք է ունենաք ցանցային ադմինիստրատորներ, որոնք բացահայտորեն թույլատրեն ելքային երթևեկությունը 853 նավահանգստում իրենց պարագծով այս նոր արձանագրության համար:

DoT տրաֆիկի տեսանելիության և վերահսկողության ապահովում

Որպես DoT վերահսկողության լավագույն պրակտիկա, մենք խորհուրդ ենք տալիս վերը նշվածներից որևէ մեկը՝ ելնելով ձեր կազմակերպության պահանջներից.

• Կազմաձևեք NGFW-ը՝ գաղտնազերծելու ամբողջ տրաֆիկը նպատակակետ 853 նավահանգստի համար: Վերծանելով տրաֆիկը, DoT-ը կհայտնվի որպես DNS հավելված, որի վրա կարող եք կիրառել ցանկացած գործողություն, օրինակ՝ միացնել բաժանորդագրությունը: Palo Alto Networks DNS Security վերահսկելու DGA տիրույթները կամ գոյություն ունեցողը DNS Sinkholing և հակալրտեսող ծրագրերից:

• Այլընտրանքն այն է, որ App-ID շարժիչն ամբողջությամբ արգելափակի «dns-over-tls» երթևեկությունը 853 նավահանգստում: Սա սովորաբար արգելափակված է լռելյայնորեն, որևէ գործողություն չի պահանջվում (եթե դուք հատուկ թույլ չեք տալիս «dns-over-tls» հավելվածը կամ նավահանգստի տրաֆիկը: 853)։

Source: www.habr.com