DNS Over HTTPS (DoH): Public WiFi Filtering पर प्रभाव

Purple Technical Briefing में आपका स्वागत है। आज के सत्र के लिए मैं आपका होस्ट हूँ, और हम अगले दस मिनट एक ऐसे विषय पर बिताने जा रहे हैं जो अभी हजारों सार्वजनिक WiFi डिप्लॉयमेंट में कंटेंट फ़िल्टरिंग नीतियों को चुपचाप कमजोर कर रहा है - DNS over HTTPS, या DoH। यदि आप किसी होटल, रिटेल एस्टेट, स्टेडियम, या सार्वजनिक क्षेत्र की सुविधा में गेस्ट WiFi चला रहे हैं, और आपने अपने नेटवर्क आर्किटेक्चर में विशेष रूप से DoH का समाधान नहीं किया है, तो इस बात की पूरी संभावना है कि आपकी फ़िल्टरिंग नीति में एक महत्वपूर्ण अंतर है। आइए ठीक से समझें कि वह अंतर क्या है, यह क्यों मायने रखता है, और आप इसके बारे में क्या कर सकते हैं। खंड एक - संदर्भ और समस्या विवरण। आइए पारंपरिक DNS फ़िल्टरिंग कैसे काम करती है, इसके एक त्वरित सारांश के साथ शुरुआत करें, क्योंकि बाईपास तंत्र को समझने के लिए यह समझना आवश्यक है कि किसे बाईपास किया जा रहा है। जब कोई गेस्ट डिवाइस आपके WiFi से कनेक्ट होता है और किसी वेबसाइट पर जाने का प्रयास करता है, तो सबसे पहले वह एक DNS क्वेरी भेजता है - मूल रूप से यह पूछता है कि इस डोमेन का IP एड्रेस क्या है? वह क्वेरी पोर्ट 53 पर UDP या TCP के माध्यम से यात्रा करती है। आपका नेटवर्क इन्फ्रास्ट्रक्चर उस क्वेरी को इंटरसेप्ट करता है, उसे आपके चुने हुए DNS रिज़ॉल्वर पर रूट करता है, और वह रिज़ॉल्वर आपकी फ़िल्टरिंग नीति के विरुद्ध डोमेन की जाँच करता है। यदि डोमेन ब्लॉकलिस्ट पर है - मैलवेयर, एडल्ट कंटेंट, जुआ, या जो कुछ भी आपकी स्वीकार्य उपयोग नीति निर्दिष्ट करती है - तो रिज़ॉल्वर IP एड्रेस वापस करने से इनकार कर देता है, और कनेक्शन कभी नहीं हो पाता है। यह प्रत्येक DNS-आधारित कंटेंट फ़िल्टरिंग डिप्लॉयमेंट का आधार है। यह लागत प्रभावी है, यह थ्रूपुट को प्रभावित नहीं करता है, और यह लगभग एक दशक से वेन्यू ऑपरेटरों के लिए मानक दृष्टिकोण रहा है। DNS over HTTPS इस मॉडल को तोड़ता है। यहाँ बताया गया है कि कैसे। DoH, DNS क्वेरीज़ को पोर्ट 443 पर मानक HTTPS ट्रैफ़िक के अंदर रैप करता है। आपके नेटवर्क के दृष्टिकोण से, यह किसी भी अन्य एन्क्रिप्टेड वेब ट्रैफ़िक के समान दिखता है। उपयोगकर्ता द्वारा वेबपेज लोड करने, वीडियो स्ट्रीम करने, या बैंकिंग ऐप एक्सेस करने से DoH क्वेरी को अलग करने का कोई तरीका नहीं है। क्वेरी सीधे एक बाहरी DoH रिज़ॉल्वर पर जाती है - जैसे Google का 8.8.8.8, Cloudflare का 1.1.1.1, या कई अन्य - एक एन्क्रिप्टेड चैनल के माध्यम से जिसे आपका DNS फ़िल्टर जांच नहीं सकता है। परिणाम? आपकी सावधानीपूर्वक कॉन्फ़िगर की गई DNS फ़िल्टरिंग नीति पूरी तरह से बाईपास हो जाती है। डिवाइस आपके रिज़ॉल्वर द्वारा क्वेरी को देखे बिना ही डोमेन को सीधे रिज़ॉल्व कर लेता है। अब, यह आपके मेहमानों द्वारा किया गया कोई जानबूझकर किया गया हमला नहीं है। अधिकांश मामलों में, यह पूरी तरह से निष्क्रिय है। Firefox में 2020 से डिफ़ॉल्ट रूप से DoH सक्षम है। यदि कॉन्फ़िगर किया गया रिज़ॉल्वर इसका समर्थन करता है तो Chrome स्वचालित रूप से DNS क्वेरीज़ को DoH में अपग्रेड कर देता है। Android 9 और उससे ऊपर के संस्करण डिफ़ॉल्ट रूप से DNS over TLS के साथ प्राइवेट DNS का समर्थन करते हैं। iOS 14 से iOS ने DoH कॉन्फ़िगरेशन प्रोफाइल का समर्थन किया है। ये मुख्यधारा के उपभोक्ता उपकरण हैं जो वही कर रहे हैं जो उनके निर्माताओं ने चाहा था। आपके मेहमान आपकी फ़िल्टरिंग को बायपास करने की कोशिश नहीं कर रहे हैं। उनके उपकरण बस इसे स्वचालित रूप से कर रहे हैं। खंड दो - तकनीकी गहन विश्लेषण। आइए यांत्रिकी को समझें। दो प्राथमिक DoH कार्यान्वयन पैटर्न हैं जो आपको इस क्षेत्र में देखने को मिलेंगे। पहला ऐप्लीकेशन-स्तर का DoH है, जहां ऐप्लीकेशन - आमतौर पर एक ब्राउज़र - ऑपरेटिंग सिस्टम की DNS सेटिंग्स से स्वतंत्र रूप से अपना स्वयं का DoH कॉन्फ़िगरेशन बनाए रखता है। Firefox इसका सबसे सटीक उदाहरण है। जब Firefox इंस्टॉल होता है और DoH सक्षम होता है, तो यह सिस्टम DNS रिज़ॉल्वर की पूरी तरह से उपेक्षा करता है और अपने सभी DNS प्रश्नों को अपने कॉन्फ़िगर किए गए DoH प्रदाता को भेजता है, जो कि डिफ़ॉल्ट रूप से Cloudflare है। आपके DHCP द्वारा असाइन किए गए DNS सर्वर का कोई महत्व नहीं रह जाता है। आपके पोर्ट 53 इंटरसेप्शन नियम अप्रासंगिक हो जाते हैं। Firefox पोर्ट 443 पर पूरी तरह से अलग DNS संवाद कर रहा होता है जिसे आप देख नहीं सकते। दूसरा पैटर्न OS-स्तर का DoH है, जहां ऑपरेटिंग सिस्टम स्वयं अपग्रेड को संभालता है। Chrome और Windows 10 और 11 यह दृष्टिकोण अपनाते हैं। वे जांचते हैं कि क्या सिस्टम का कॉन्फ़िगर किया गया DNS रिज़ॉल्वर - जो आपके DHCP सर्वर द्वारा असाइन किया गया है - उसका एक संगत DoH एंडपॉइंट है। यदि ऐसा है, तो वे स्वचालित रूप से DoH पर अपग्रेड हो जाते हैं। इसे ऑपर्च्यूनिस्टिक DoH कहा जाता है। यदि आप अपने गेस्ट DNS सर्वर के रूप में 8.8.8.8 असाइन कर रहे हैं, तो Chrome स्वचालित रूप से Google के DoH एंडपॉइंट का उपयोग करेगा। यदि आप 1.1.1.1 असाइन कर रहे हैं, तो यह Cloudflare के DoH एंडपॉइंट का उपयोग करेगा। यह अंतर आपकी शमन रणनीति (mitigation strategy) के लिए महत्वपूर्ण है, जिस पर हम जल्द ही चर्चा करेंगे। एक तीसरा वेक्टर भी उल्लेख के योग्य है: DNS over TLS, या DoT। यह पोर्ट 853 पर काम करता है और DNS प्रश्नों को HTTPS में रैप करने के बजाय TLS का उपयोग करके एन्क्रिप्ट करता है। DoH की तुलना में इसे ब्लॉक करना आसान है क्योंकि यह एक समर्पित पोर्ट का उपयोग करता है, लेकिन Android डिवाइसों पर प्राइवेट DNS सक्षम होने के साथ यह तेज़ी से आम हो रहा है। आपकी शमन रणनीति को इन दोनों को संबोधित करने की आवश्यकता है। अब बात करते हैं कि यह केवल एक तकनीकी जिज्ञासा नहीं, बल्कि एक अनुपालन (compliance) और परिचालन जोखिम क्यों है। GDPR के तहत, यदि आपकी स्वीकार्य उपयोग नीति (acceptable use policy) यह कहती है कि आप कुछ श्रेणियों की सामग्री को फ़िल्टर करते हैं, और आपके तकनीकी नियंत्रण वास्तव में उस नीति को लागू नहीं करते हैं, तो आपके घोषित डेटा सुरक्षा और सामग्री नियंत्रण प्रतिबद्धताओं तथा आपके वास्तविक तकनीकी कार्यान्वयन के बीच एक अंतर होता है। यदि आपको कभी नियामक पूछताछ या किसी घटना का सामना करना पड़ता है तो यह एक बचाव संबंधी समस्या है। UK के Online Safety Act के तहत, सार्वजनिक इंटरनेट एक्सेस प्रदान करने वाले वेन्यू ऑपरेटरों के पास उपयोगकर्ताओं - विशेष रूप से नाबालिगों - को हानिकारक सामग्री से बचाने की ज़िम्मेदारियां होती हैं। यदि DoH चुपचाप आपकी सामग्री फ़िल्टरिंग को बायपास कर रहा है, तो हो सकता है कि आप उन दायित्वों को पूरा न कर रहे हों। उन वेन्यू के लिए जो PCI-DSS के दायरे में आते हैं - विशेष रूप से वे जहां भुगतान कार्ड डेटा गेस्ट WiFi के निकटवर्ती नेटवर्क पर प्रवाहित होता है - PCI-DSS संस्करण 4.0 की आवश्यकता है कि आप अपने नेटवर्क सुरक्षा नियंत्रणों के हिस्से के रूप में DNS ट्रैफ़िक की निगरानी और नियंत्रण करें। अनमॉनीटर किया गया DoH ट्रैफ़िक उस नियंत्रण ढांचे में एक कमी है। और पूरी तरह से सुरक्षा के दृष्टिकोण से, DoH का मैलवेयर द्वारा सक्रिय रूप से दुरुपयोग किया गया है। थ्रेट एक्टर्स ने DoH का उपयोग कमांड-एंड-कंट्रोल चैनल के रूप में किया है क्योंकि यह सामान्य HTTPS ट्रैफ़िक में मिल जाता है। GodLua बैकडोर ने कमांड-एंड-कंट्रोल कम्युनिकेशन्स के लिए DoH का उपयोग किया। PsiXBot मैलवेयर ने Google की DoH सेवा का उपयोग किया। यदि आपकी सुरक्षा निगरानी दुर्भावनापूर्ण गतिविधि का पता लगाने के लिए DNS दृश्यता पर निर्भर करती है, तो DoH ब्लाइंड स्पॉट्स एक वास्तविक खतरा हैं।धारा तीन - कार्यान्वयन की सिफारिशें। ठीक है, आइए व्यावहारिक बनें। तीन प्राथमिक सुरक्षा रणनीतियाँ हैं, और अधिकांश स्थान परिनियोजन (venue deployments) में, आप इन तीनों को एक साथ मिलाकर लागू करना चाहेंगे। रणनीति एक: फ़ायरवॉल पर ज्ञात DoH रिज़ॉल्वर एंडपॉइंट्स को ब्लॉक करें। यह आपकी सुरक्षा की पहली पंक्ति है और सबसे तुरंत लागू की जाने वाली रणनीति है। ज्ञात DoH रिज़ॉल्वर IP पतों और डोमेन - Google, Cloudflare, Quad9, NextDNS, AdGuard, और अन्य - की एक ब्लॉकलिस्ट बनाए रखें और अपने गेस्ट VLAN से उन एंडपॉइंट्स पर जाने वाले आउटबाउंड HTTPS ट्रैफ़िक को ब्लॉक करें। IETF और विभिन्न सुरक्षा विक्रेता इन सूचियों को प्रकाशित और अपडेट करते हैं। GitHub पर curl प्रोजेक्ट ज्ञात DoH रिज़ॉल्वर की एक व्यापक सूची बनाए रखता है जो एक अच्छा शुरुआती बिंदु है। यह दृष्टिकोण अधिकांश DoH ट्रैफ़िक को संभालता है क्योंकि, जैसा कि कार्नेगी मेलन के सॉफ्टवेयर इंजीनियरिंग संस्थान के शोध से पता चला है, अधिकांश DoH ट्रैफ़िक कम संख्या में जाने-माने रिज़ॉल्वर पर जाता है। ऐसे उपयोगकर्ता जो कस्टम DoH रिज़ॉल्वर को कॉन्फ़िगर करने के लिए DNS के बारे में पर्याप्त जानते हैं, वे बहुत कम संख्या में हैं। इस दृष्टिकोण की सीमा यह है कि यह एक ब्लॉकलिस्ट है, और ब्लॉकलिस्ट को रखरखाव की आवश्यकता होती है। नए DoH रिज़ॉल्वर नियमित रूप से दिखाई देते हैं। लेकिन अन्य रणनीतियों के साथ मिलकर, यह मजबूत सुरक्षा प्रदान करता है। रणनीति दो: आपके नेक्स्ट-जनरेशन फ़ायरवॉल पर TLS निरीक्षण। Palo Alto Networks, Fortinet, Check Point, और Cisco Firepower सहित विक्रेताओं के नेक्स्ट-जनरेशन फ़ायरवॉल TLS निरीक्षण का समर्थन करते हैं - जिसे SSL निरीक्षण या डीप पैकेट निरीक्षण भी कहा जाता है। सक्षम होने पर, फ़ायरवॉल HTTPS ट्रैफ़िक के लिए मैन-इन-द-मिडल के रूप में कार्य करता है, इसे डिक्रिप्ट करता है, पेलोड का निरीक्षण करता है, और भेजने से पहले इसे फिर से एन्क्रिप्ट करता है। यह फ़ायरवॉल को DoH ट्रैफ़िक की पहचान करने की अनुमति देता है, भले ही वह किसी अज्ञात रिज़ॉल्वर पर जा रहा हो। Palo Alto का App-ID विशेष रूप से DoH ट्रैफ़िक की पहचान कर सकता है और उस पर नीति लागू कर सकता है। Fortinet के FortiGate में भी इसी तरह की क्षमता है। मुख्य कॉन्फ़िगरेशन चरण यह सुनिश्चित करना है कि आपके गेस्ट VLAN ट्रैफ़िक को निरीक्षण नीति के माध्यम से रूट किया जाए। यहाँ परिचालन संबंधी विचार प्रमाणपत्र (certificate) का विश्वास है। गेस्ट डिवाइस पर TLS निरीक्षण काम करने के लिए, उन डिवाइस को आपके निरीक्षण प्रमाणपत्र पर भरोसा करने की आवश्यकता होती है। प्रबंधित कॉर्पोरेट डिवाइस पर, यह सीधा है - आप MDM के माध्यम से प्रमाणपत्र को पुश करते हैं। अप्रबंधित गेस्ट डिवाइस पर, यह अधिक जटिल है। गेस्ट WiFi के लिए व्यावहारिक दृष्टिकोण Captive Portal स्वीकृति प्रवाह का उपयोग करके उपयोगकर्ताओं को सूचित करना है कि कंटेंट फ़िल्टरिंग उद्देश्यों के लिए ट्रैफ़िक का निरीक्षण किया जा सकता है, और अधिक जोखिम वाले वातावरण के लिए द्वितीयक परत के रूप में TLS निरीक्षण के साथ, आपके प्राथमिक नियंत्रणों के रूप में DoH रिज़ॉल्वर ब्लॉकिंग और DNS इंटरसेप्शन के संयोजन पर निर्भर रहना है। रणनीति तीन: DNS इंटरसेप्शन और रीडायरेक्ट को बाध्य करें। UDP और TCP पोर्ट 53 पर सभी आउटबाउंड DNS ट्रैफ़िक को इंटरसेप्ट करने और इसे अपने अनुपालन वाले DNS रिज़ॉल्वर पर रीडायरेक्ट करने के लिए अपने फ़ायरवॉल या वायरलेस कंट्रोलर को कॉन्फ़िगर करें। यह DoH को नहीं रोकता है, लेकिन यह सुनिश्चित करता है कि कोई भी DNS ट्रैफ़िक जो पोर्ट 53 पर वापस आता है - क्योंकि DoH विफल हो गया था या उपलब्ध नहीं था - उसे कैप्चर और फ़िल्टर किया जाए। इसे गेस्ट VLAN से आउटबाउंड पोर्ट 853 को ब्लॉक करने के साथ कंबाइन करें ताकि DNS over TLS आपके नियंत्रणों को बायपास न कर सके। मैनेज्ड एंडपॉइंट्स - कॉर्पोरेट डिवाइसेज, स्टाफ डिवाइसेज - के लिए आपके पास एक अतिरिक्त विकल्प है: ब्राउज़र और OS स्तर पर DoH को अक्षम करने के लिए ग्रुप पॉलिसी या MDM कॉन्फ़िगरेशन। Firefox में, network.trr.mode प्रेफरेंस को 5 पर सेट करने से DoH पूरी तरह से अक्षम हो जाता है। Chrome में, disable-features equals DnsOverHttps फ्लैग समान काम करता है। Windows 10 और 11 में DoH व्यवहार को नियंत्रित करने के लिए ग्रुप पॉलिसी सेटिंग्स हैं। यह मैनेज्ड डिवाइसेज के लिए सबसे विश्वसनीय नियंत्रण है, लेकिन यह अनमैनेज्ड गेस्ट डिवाइसेज पर लागू नहीं होता है। चौथा भाग - इम्प्लीमेंटेशन की कमियां। कुछ चीजें जो आमतौर पर फील्ड में गलत हो जाती हैं। सबसे आम विफलता मोड अपूर्ण पोर्ट 53 इंटरसेप्शन है। टीमें अपने DNS फ़िल्टरिंग सर्विस को सही ढंग से कॉन्फ़िगर करती हैं लेकिन फ़ायरवॉल नियम जोड़ना भूल जाती हैं जो सभी आउटबाउंड पोर्ट 53 ट्रैफ़िक को रीडायरेक्ट करता है। हार्डकोडेड DNS सेटिंग्स - 8.8.8.8, 1.1.1.1 - वाले डिवाइसेज फ़िल्टर को पूरी तरह से बायपास कर देते हैं। हमेशा सत्यापित करें कि यह नियम लागू है और एक हार्डकोडेड DNS सर्वर के साथ एक टेस्ट डिवाइस को कॉन्फ़िगर करके इसका परीक्षण करें और पुष्टि करें कि फ़िल्टर किए गए डोमेन अभी भी ब्लॉक हैं। दूसरी आम विफलता IPv6 का ध्यान न रखना है। IPv6 पर DNS क्वेरीज़ तेजी से आम हो रही हैं, और कई फ़ायरवॉल नियम केवल IPv4 के लिए लिखे गए हैं। सुनिश्चित करें कि आपका पोर्ट 53 इंटरसेप्शन और DoH रिजॉल्वर ब्लॉकलिस्ट दोनों IPv4 और IPv6 एड्रेस को कवर करते हैं। तीसरा: पुरानी DoH रिजॉल्वर ब्लॉकलिस्ट। यदि आप DoH रिजॉल्वर IPs की एक स्टेटिक ब्लॉकलिस्ट बनाए रख रहे हैं, तो यह पुरानी हो जाएगी। अपडेट प्रक्रिया को ऑटोमेट करें या ऐसी DNS फ़िल्टरिंग सर्विस का उपयोग करें जो आपके लिए इस लिस्ट को बनाए रखती है। Cloudflare Gateway, Cisco Umbrella, और इसी तरह की एंटरप्राइज DNS सर्विसेज़ में एक मैनेज्ड क्षमता के रूप में DoH बायपास डिटेक्शन शामिल है। चौथा: केवल एक मिटिगेशन लेयर पर अत्यधिक निर्भरता। DoH मिटिगेशन एक डिफेंस-इन-डेप्थ समस्या है। कोई भी एक नियंत्रण पर्याप्त नहीं है। ज्ञात रिजॉल्वर को ब्लॉक करना अधिकांश मामलों को संभालता है। TLS इन्सपेक्शन एज केसेज को संभालता है। DNS इंटरसेप्शन एक सुरक्षा नेट प्रदान करता है। तीनों को लेयर करें। पांचवां भाग - त्वरित प्रश्नोत्तर। क्या DoH मिटिगेशन वैध प्राइवेसी टूल्स को बाधित करता है? संभावित रूप से, हाँ। यदि कोई यूजर एक वैध प्राइवेसी-केंद्रित ब्राउज़र कॉन्फ़िगरेशन चला रहा है, तो आपका DoH ब्लॉकिंग उन्हें आपके DNS रिजॉल्वर का उपयोग करने के लिए मजबूर करेगा। आपकी स्वीकार्य उपयोग नीति (एक्सेप्टेबल यूज़ पॉलिसी) में यह स्पष्ट होना चाहिए कि वेन्यू के DNS रिजॉल्वर का उपयोग कंटेंट फ़िल्टरिंग उद्देश्यों के लिए किया जाता है। यह मानक अभ्यास है और कानूनी रूप से बचाव योग्य है। क्या DoH का उपयोग मेरे नेटवर्क से डेटा एक्सफिल्ट्रेट करने के लिए किया जा सकता है? हाँ, और यह एक वास्तविक थ्रेट वेक्टर है। DoH पर DNS टनलिंग का प्रदर्शन वास्तविक दुनिया में किया गया है। आपके नेक्स्ट-जेनरेशन फ़ायरवॉल की DoH डिटेक्शन क्षमता में असामान्य रूप से उच्च क्वेरी वॉल्यूम या टनलिंग के अनुरूप क्वेरी पैटर्न के लिए विसंगति डिटेक्शन (एनोमली डिटेक्शन) शामिल होना चाहिए। उन मोबाइल ऐप्स का क्या जो DoH का उपयोग करते हैं? यह सबसे कठिन मामला है। मोबाइल ऐप्स जो OS DNS सेटिंग्स का उपयोग करने के बजाय अपने स्वयं के DoH स्टैक को लागू करते हैं - उन्हें TLS inspection के बिना नियंत्रित करना कठिन है। आपका सबसे अच्छा समाधान ज्ञात रिज़ॉल्वर ब्लॉकिंग और TLS inspection का संयोजन है। क्या यहाँ WPA3 प्रासंगिक है? WPA3 ओवर-द-एयर एन्क्रिप्शन में सुधार करता है और फॉरवर्ड सीक्रेसी प्रदान करता है, जो अतिथि गोपनीयता के लिए उत्कृष्ट है। लेकिन WPA3 DoH का समाधान नहीं करता है - यह लेयर 7 एप्लिकेशन प्रोटोकॉल का मुद्दा है, न कि लेयर 2 वायरलेस सुरक्षा का मुद्दा। वे विभिन्न थ्रेट वेक्टर्स का समाधान करने वाले पूरक नियंत्रण हैं। अनुभाग छह - ROI और व्यावसायिक प्रभाव। मुझे इसे उचित रूप से हल करने के व्यावसायिक मामले के साथ समाप्त करने दें। DoH का समाधान न करने की लागत विषम है। एक अकेली घटना - आपके नेटवर्क पर अवैध सामग्री तक पहुँचने वाला कोई अतिथि, आपके DNS मॉनिटरिंग में ब्लाइंड स्पॉट होने के कारण मैलवेयर कॉलबैक का पता न चल पाना, आपके कंटेंट फ़िल्टरिंग अनुपालन के बारे में एक नियामक पूछताछ - उचित समाधान में निवेश की तुलना में काफी अधिक महंगी हो सकती है। 20 संपत्तियों में काम करने वाले एक होटल समूह के लिए, DoH समाधान को तैनात करने में आम तौर पर फ़ायरवॉल नियमों और DNS इंटरसेप्शन कॉन्फ़िगरेशन के लिए प्रति संपत्ति दो से चार घंटे का एक बार का कॉन्फ़िगरेशन प्रयास शामिल होता है, साथ ही रिज़ॉल्वर ब्लॉकलिस्ट को बनाए रखने का एक निरंतर परिचालन ओवरहेड शामिल होता है - जो कि यदि आप एक प्रबंधित DNS फ़िल्टरिंग सेवा का उपयोग कर रहे हैं तो काफी हद तक स्वचालित है। जोखिम में कमी की तुलना में कुल निवेश मामूली है। PCI-DSS के तहत काम करने वाली रिटेल श्रृंखलाओं के लिए, अनुपालन लाभ सीधे तौर पर मापने योग्य है। यह प्रदर्शित करना कि आपके नेटवर्क सुरक्षा नियंत्रणों में DoH समाधान शामिल है, PCI-DSS ऑडिट निष्कर्ष और संबंधित सुधारात्मक लागतों के जोखिम को कम करता है। सार्वजनिक क्षेत्र के स्थानों और ऑनलाइन सुरक्षा अधिनियम के तहत काम करने वाले स्थानों के लिए, प्रलेखित DoH समाधान आपके साक्ष्य का हिस्सा है कि आपने अपनी कंटेंट फ़िल्टरिंग नीति को लागू करने के लिए उचित तकनीकी कदम उठाए हैं। मुख्य बात: DoH कोई भविष्य की समस्या नहीं है। यह वर्तमान की समस्या है। Firefox, Chrome, Android, और iOS सभी अभी आपके अतिथियों के उपकरणों पर DoH-सक्षम कॉन्फ़िगरेशन भेज रहे हैं। यदि आपने पिछले 12 महीनों में DoH बाईपास वेक्टर्स के लिए अपने DNS फ़िल्टरिंग आर्किटेक्चर का ऑडिट नहीं किया है, तो वह ऑडिट आपके निकट-अवधि के रोडमैप पर होना चाहिए। आज की ब्रीफिंग के मुख्य निष्कर्षों को संक्षेप में प्रस्तुत करने के लिए। एक: DoH पोर्ट 443 पर HTTPS के भीतर DNS प्रश्नों को एन्क्रिप्ट करता है, जिससे वे पारंपरिक पोर्ट 53 DNS फ़िल्टरिंग के लिए अदृश्य हो जाते हैं। यह मुख्यधारा के ब्राउज़रों और ऑपरेटिंग सिस्टम पर डिफ़ॉल्ट रूप से हो रहा है। दो: तीन-परत वाली समाधान रणनीति - ज्ञात DoH रिज़ॉल्वर IPs को ब्लॉक करना, आपके नेक्स्ट-जनरेशन फ़ायरवॉल पर TLS inspection लागू करना, और पोर्ट 53 इंटरसेप्शन लागू करना - प्रबंधित और अप्रबंधित दोनों अतिथि उपकरणों के लिए गहन सुरक्षा कवरेज प्रदान करती है। तीन: यह केवल एक तकनीकी मुद्दा नहीं बल्कि एक अनुपालन मुद्दा भी है। GDPR, ऑनलाइन सुरक्षा अधिनियम और PCI-DSS सभी के उन स्थानों के लिए निहितार्थ हैं जहां DoH चुपचाप कंटेंट फ़िल्टरिंग नीतियों को बायपास कर रहा है। चार: सबसे आम कार्यान्वयन विफलता अधूरी port 53 इंटरसेप्शन है। इसका परीक्षण करें। इसे सत्यापित करें। यह मानकर न चलें कि यह काम कर रहा है। पाँच: Managed DNS फ़िल्टरिंग सेवाएँ - Cloudflare Gateway, Cisco Umbrella, और समान - तेजी से एक प्रबंधित क्षमता के रूप में DoH बाईपास डिटेक्शन को शामिल कर रही हैं, जो स्टेटिक ब्लॉकलिस्ट को बनाए रखने के परिचालन ओवरहेड को कम करती है। आज के Purple तकनीकी ब्रीफिंग के लिए बस इतना ही। यदि आप अपने वर्तमान DNS फ़िल्टरिंग आर्किटेक्चर का ऑडिट करना चाहते हैं या अपने वेन्यू एस्टेट में DoH न्यूनीकरण को लागू करना चाहते हैं, तो Purple प्लेटफ़ॉर्म उस परिनियोजन का समर्थन करने के लिए नेटवर्क इंटेलिजेंस और गेस्ट WiFi प्रबंधन लेयर प्रदान करता है। सुनने के लिए धन्यवाद, और हम आपसे अगले सत्र में मिलेंगे।