កាត់បន្ថយហានិភ័យនៃការប្រើប្រាស់ DNS-over-TLS (DoT) និង DNS-over-HTTPS (DoH)

កាត់បន្ថយហានិភ័យនៃការប្រើប្រាស់ DoH និង DoT

ការការពារ DoH និង DoT

តើអ្នកគ្រប់គ្រងចរាចរណ៍ DNS របស់អ្នកទេ? ស្ថាប័ននានាវិនិយោគពេលវេលា ប្រាក់ និងការខិតខំប្រឹងប្រែងជាច្រើនក្នុងការធានាបណ្តាញរបស់ពួកគេ។ ទោះយ៉ាងណាក៏ដោយ តំបន់មួយដែលជារឿយៗមិនទទួលបានការយកចិត្តទុកដាក់គ្រប់គ្រាន់គឺ DNS ។

ទិដ្ឋភាពទូទៅដ៏ល្អនៃហានិភ័យដែល DNS នាំមកគឺ ការបង្ហាញ Verisign នៅឯសន្និសិទ Infosecurity ។

31% នៃថ្នាក់ ransomware ដែលបានស្ទង់មតិបានប្រើ DNS សម្រាប់ការផ្លាស់ប្តូរគន្លឹះ។ ការស្រាវជ្រាវ

31% នៃថ្នាក់ ransomware ដែលបានស្ទង់មតិបានប្រើ DNS សម្រាប់ការផ្លាស់ប្តូរសោ។

បញ្ហាគឺធ្ងន់ធ្ងរ។ យោងតាមមន្ទីរពិសោធន៍ស្រាវជ្រាវ Palo Alto Networks Unit 42 ប្រហែល 85% នៃមេរោគប្រើប្រាស់ DNS ដើម្បីបង្កើតបណ្តាញបញ្ជា និងគ្រប់គ្រង ដែលអនុញ្ញាតឱ្យអ្នកវាយប្រហារបញ្ចូលមេរោគយ៉ាងងាយស្រួលចូលទៅក្នុងបណ្តាញរបស់អ្នក ក៏ដូចជាលួចទិន្នន័យផងដែរ។ ចាប់តាំងពីការចាប់ផ្តើមរបស់វា ចរាចរ DNS មិនត្រូវបានអ៊ិនគ្រីបយ៉ាងទូលំទូលាយ ហើយអាចត្រូវបានវិភាគយ៉ាងងាយស្រួលដោយយន្តការសុវត្ថិភាព NGFW ។ 

ពិធីការថ្មីសម្រាប់ DNS បានលេចឡើងក្នុងគោលបំណងបង្កើនការសម្ងាត់នៃការតភ្ជាប់ DNS ។ ពួកគេត្រូវបានគាំទ្រយ៉ាងសកម្មដោយអ្នកលក់កម្មវិធីរុករកឈានមុខគេ និងអ្នកលក់កម្មវិធីផ្សេងទៀត។ ចរាចរណ៍ DNS ដែលបានអ៊ិនគ្រីបនឹងចាប់ផ្តើមរីកចម្រើនឆាប់ៗនេះនៅក្នុងបណ្តាញសាជីវកម្ម។ ចរាចរណ៍ DNS ដែលបានអ៊ិនគ្រីបដែលមិនត្រូវបានវិភាគ និងដោះស្រាយឱ្យបានត្រឹមត្រូវដោយឧបករណ៍ បង្កហានិភ័យសុវត្ថិភាពដល់ក្រុមហ៊ុន។ ឧទាហរណ៍ ការគំរាមកំហែងបែបនេះគឺ cryptolockers ដែលប្រើ DNS ដើម្បីផ្លាស់ប្តូរសោអ៊ិនគ្រីប។ ឥឡូវនេះ អ្នកវាយប្រហារកំពុងទាមទារតម្លៃលោះជាច្រើនលានដុល្លារ ដើម្បីស្ដារការចូលប្រើទិន្នន័យរបស់អ្នក។ ជាឧទាហរណ៍ Garmin បានបង់ប្រាក់ចំនួន 10 លានដុល្លារ។

នៅពេលដែលបានកំណត់រចនាសម្ព័ន្ធត្រឹមត្រូវ NGFWs អាចបដិសេធ ឬការពារការប្រើប្រាស់ 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 plaintext (Domain Name System) protocol។ 

ប៉ុន្មានឆ្នាំចុងក្រោយនេះ ពិធីការអ៊ិនគ្រីប 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 ជាមធ្យោបាយនៃការរំលងវិធានការជញ្ជាំងភ្លើងសាជីវកម្មប្រពៃណី។ (ឧទាហរណ៍ សូមពិនិត្យមើលអត្ថបទខាងក្រោម៖ ឥឡូវនេះ PsiXBot ប្រើ Google DoH , PsiXBot បន្តវិវឌ្ឍន៍ជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធ DNS ដែលបានធ្វើបច្ចុប្បន្នភាព и Godlua ការវិភាគផ្ទៃខាងក្រោយ .) ក្នុងករណីណាក៏ដោយ ទាំងចរាចរ 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 មិនអាចត្រូវបានត្រួតពិនិត្យពេញលេញទេ (សូមមើល  Applipedia ពី Palo Alto Networks   ហើយស្វែងរក "dns-over-https") ។

DNS លើ TLS (DoT)

DNS នៅខាងក្នុង TLS

ខណៈពេលដែលពិធីការ DoH មានទំនោរទៅលាយជាមួយនឹងចរាចរផ្សេងទៀតនៅលើច្រកដូចគ្នា ជំនួសមកវិញ DoT កំណត់លំនាំដើមក្នុងការប្រើប្រាស់ច្រកពិសេសដែលបានបម្រុងទុកសម្រាប់គោលបំណងតែមួយគត់នោះ សូម្បីតែជាពិសេសមិនអនុញ្ញាតឱ្យច្រកដូចគ្នាពីការប្រើប្រាស់ដោយចរាចរ DNS ដែលមិនមានការអ៊ិនគ្រីបបែបប្រពៃណី ( RFC 7858 ផ្នែក 3.1 ).

ពិធីការ DoT ប្រើ TLS ដើម្បីផ្តល់នូវការអ៊ិនគ្រីបដែលបង្កប់នូវសំណួរស្តង់ដារ DNS protocol ជាមួយនឹងចរាចរដោយប្រើច្រកល្បី 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 និងប្រឆាំង spyware ។

• ជម្រើសមួយទៀតគឺត្រូវមានម៉ាស៊ីន App-ID ទប់ស្កាត់ចរាចរណ៍ 'dns-over-tls' ទាំងស្រុងនៅលើច្រក 853។ ជាធម្មតាវាត្រូវបានរារាំងតាមលំនាំដើម គ្មានសកម្មភាពណាមួយត្រូវបានទាមទារទេ (លុះត្រាតែអ្នកអនុញ្ញាតជាពិសេសកម្មវិធី ឬច្រក 'dns-over-tls' ចរាចរណ៍ ៨៥៣) ។

ប្រភព: www.habr.com