DNS Over HTTPS (DoH): Public WiFi Filtering साठीचे परिणाम

Purple च्या टेक्निकल ब्रीफिंगमध्ये आपले स्वागत आहे. मी आजच्या सत्रासाठी तुमचा यजमान आहे, आणि आम्ही पुढील दहा मिनिटे अशा विषयावर घालवणार आहोत जो सध्या हजारो सार्वजनिक WiFi डेव्हलपमेंट्समधील कंटेंट फिल्टरिंग पॉलिसींना हळूहळू कमकुवत करत आहे - DNS over HTTPS, किंवा DoH. जर तुम्ही हॉटेल, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील सुविधेमध्ये गेस्ट WiFi चालवत असाल आणि तुम्ही तुमच्या नेटवर्क आर्किटेक्चरमध्ये विशेषतः DoH चा समावेश केला नसेल, तर तुमच्या फिल्टरिंग पॉलिसीमध्ये एक मोठी त्रुटी असण्याची दाट शक्यता आहे. ती त्रुटी नेमकी काय आहे, ती का महत्त्वाची आहे आणि तुम्ही त्यावर काय करू शकता, हे आपण सविस्तर समजून घेऊया. विभाग एक - संदर्भ आणि समस्येचे विधान. पारंपारिक DNS फिल्टरिंग कसे कार्य करते याच्या संक्षिप्त पुनरावलोकनापासून सुरुवात करूया, कारण बायपास यंत्रणा समजून घेण्यासाठी कशाला बायपास केले जात आहे हे समजून घेणे आवश्यक आहे. जेव्हा एखादे गेस्ट डिव्हाइस तुमच्या WiFi शी कनेक्ट होते आणि एखाद्या वेबसाइटला भेट देण्याचा प्रयत्न करते, तेव्हा ते सर्वात आधी DNS क्वेरी पाठवते - प्रामुख्याने या डोमेनचा IP पत्ता काय आहे हे विचारते. ती क्वेरी पोर्ट ५३ वर UDP किंवा TCP द्वारे प्रवास करते. तुमचे नेटवर्क इन्फ्रास्ट्रक्चर त्या क्वेरीला अडवते, त्याला तुमच्या निवडलेल्या DNS रिझॉल्व्हरकडे पाठवते आणि तो रिझॉल्व्हर तुमच्या फिल्टरिंग पॉलिसीनुसार त्या डोमेनची तपासणी करतो. जर ते डोमेन ब्लॉकलिस्टवर असेल - मालवेअर, प्रौढ कंटेंट, जुगार किंवा तुमच्या स्वीकार्य वापर पॉलिसीमध्ये जे काही निर्दिष्ट केले असेल - तर रिझॉल्व्हर IP पत्ता परत देण्यास नकार देतो आणि कनेक्शन कधीही स्थापित होत नाही. हे प्रत्येक DNS-आधारित कंटेंट फिल्टरिंग डेव्हलपमेंटचा पाया आहे. हे किफायतशीर आहे, याचा थ्रूपुटवर परिणाम होत नाही आणि गेल्या दशकातील बहुतांश काळ व्हेन्यू ऑपरेटर्ससाठी हाच प्रमाणित दृष्टिकोन राहिला आहे. DNS over HTTPS हे मॉडेल मोडीत काढते. ते कसे ते पाहूया. DoH DNS क्वेरींना पोर्ट ४४३ वरील प्रमाणित HTTPS ट्रॅफिकमध्ये गुंडाळते. तुमच्या नेटवर्कच्या दृष्टिकोनातून, हे इतर कोणत्याही एन्क्रिप्टेड वेब ट्रॅफिकसारखेच दिसते. वापरकर्ता वेबपेज लोड करत आहे, व्हिडिओ स्ट्रीम करत आहे किंवा बँकिंग ॲप वापरत आहे यातून DoH क्वेरी वेगळी ओळखण्याचा कोणताही मार्ग नाही. ही क्वेरी थेट बाह्य DoH रिझॉल्व्हरकडे - Google चे ८.८.८.८, Cloudflare चे १.१.१.१ किंवा इतर कोणत्याही पर्यायांकडे - अशा एन्क्रिप्टेड चॅनेलद्वारे जाते ज्याची तुमचे DNS फिल्टर तपासणी करू शकत नाही. याचा परिणाम? तुमची काळजीपूर्वक कॉन्फिगर केलेली DNS फिल्टरिंग पॉलिसी पूर्णपणे बायपास केली जाते. तुमचे रिझॉल्व्हर ती क्वेरी न पाहताही डिव्हाइस थेट डोमेन रिझॉल्व्ह करते. आता, हा तुमच्या पाहुण्यांनी केलेला मुद्दामहून केलेला हल्ला नाही. बहुतेक प्रकरणांमध्ये, हे पूर्णपणे निष्क्रिय असते. Firefox मध्ये २०२० पासून डीफॉल्टनुसार DoH सक्षम केले आहे. जर कॉन्फिगर केलेला रिझॉल्व्हर त्याला सपोर्ट करत असेल तर Chrome स्वयंचलितपणे DNS क्वेरींना DoH मध्ये अपग्रेड करते. Android 9 आणि त्यावरील आवृत्त्या डीफॉल्टनुसार DNS over TLS सह प्रायव्हेट DNS ला सपोर्ट करतात. iOS ने iOS 14 पासून DoH कॉन्फिगरेशन प्रोफाइल्सना सपोर्ट केला आहे. ही मुख्य प्रवाहातील ग्राहक डिव्हाइसेस आहेत जी त्यांच्या निर्मात्यांच्या उद्देशानुसार काम करत आहेत. तुमचे पाहुणे तुमचे फिल्टरिंग बायपास करण्याचा प्रयत्न करत नाहीत. त्यांची डिव्हाइसेस हे स्वयंचलितपणे करत आहेत. विभाग दोन - तांत्रिक सखोल विश्लेषण. चला याच्या मेकॅनिक्समध्ये जाऊया. तुम्हाला क्षेत्रात पाहायला मिळणारे दोन मुख्य DoH अंमलबजावणीचे पॅटर्न आहेत. पहिला प्रकार म्हणजे application-level DoH, जिथे application - सामान्यतः browser - operating system च्या DNS settings पेक्षा स्वतंत्रपणे स्वतःचे DoH configuration व्यवस्थापित करतो. Firefox हे याचे एक उत्कृष्ट उदाहरण आहे. जेव्हा Firefox install केले जाते आणि DoH सक्षम केले जाते, तेव्हा ते system DNS resolver कडे पूर्णपणे दुर्लक्ष करते आणि आपल्या सर्व DNS queries त्याच्या configured DoH provider कडे पाठवते, जे default स्वरूपात Cloudflare असते. तुमचे DHCP-assigned DNS server निरर्थक ठरते. तुमचे port 53 interception rules निरर्थक ठरतात. Firefox port 443 वर संपूर्णपणे स्वतंत्र DNS संभाषण करत असते जे तुम्हाला दिसत नाही. दुसरा प्रकार म्हणजे OS-level DoH, जिथे operating system स्वतः upgrade हाताळते. Chrome आणि Windows 10 आणि 11 हा दृष्टिकोन स्वीकारतात. System चे configured DNS resolver - जे तुमच्या DHCP server द्वारे assign केले गेले आहे - त्याकडे संबंधित DoH endpoint आहे की नाही हे ते तपासतात. असल्यास, ते आपोआप DoH वर upgrade होतात. याला opportunistic DoH म्हटले जाते. जर तुम्ही तुमचे guest DNS server म्हणून 8.8.8.8 assign करत असाल, तर Chrome आपोआप Google चा DoH endpoint वापरेल. जर तुम्ही 1.1.1.1 assign करत असाल, तर ते Cloudflare चा DoH endpoint वापरेल. हा फरक तुमच्या mitigation strategy साठी महत्त्वाचा आहे, ज्याकडे आपण लवकरच वळू. उल्लेख करण्याजोगा तिसरा मार्ग म्हणजे: DNS over TLS, किंवा DoT. हे port 853 वर कार्य करते आणि HTTPS मध्ये गुंडाळण्याऐवजी TLS चा वापर करून DNS queries encrypt करते. DoH च्या तुलनेने याला block करणे सोपे आहे कारण हे एका dedicated port चा वापर करते, परंतु Private DNS सक्षम असलेल्या Android उपकरणांवर हे वाढत्या प्रमाणात सामान्य होत चालले आहे. तुमच्या mitigation strategy मध्ये या दोन्ही गोष्टींचा विचार करणे आवश्यक आहे. आता हे केवळ तांत्रिक कुतूहल नसून compliance आणि operational risk कशी आहे याबद्दल बोलूया. GDPR अंतर्गत, जर तुमचे acceptable use policy असे दर्शवत असेल की तुम्ही विशिष्ट प्रकारच्या content ला filter करता, आणि तुमचे technical controls प्रत्यक्षात त्या policy ची अंमलबजावणी करत नसतील, तर तुमच्या घोषित data protection व content governance वचनबद्धतेमध्ये आणि तुमच्या प्रत्यक्ष technical implementation मध्ये तफावत निर्माण होते. जर तुम्हाला कधी नियामक चौकशी किंवा घटनेचा सामना करावा लागला तर ही एक बचावाची समस्या ठरते. UK च्या Online Safety Act अंतर्गत, सार्वजनिक इंटरनेट सेवा पुरवणाऱ्या venue operators वर वापरकर्त्यांना - विशेषतः अल्पवयीनांना - हानिकारक content पासून सुरक्षित ठेवण्याचे बंधन असते. जर DoH गुपचूपपणे तुमच्या content filtering ला वळसा घालत असेल, तर तुम्ही कदाचित त्या जबाबदाऱ्या पूर्ण करत नाही आहात. PCI-DSS च्या कक्षेत येणाऱ्या venues साठी - विशेषतः जिथे guest WiFi च्या लगतच्या networks वरून payment card data प्रसारित होतो - PCI-DSS version 4.0 ची अशी आवश्यकता आहे की तुम्ही तुमच्या network security controls चा भाग म्हणून DNS traffic चे निरीक्षण आणि नियंत्रण केले पाहिजे. अनियंत्रित DoH traffic ही त्या control framework मधील एक त्रुटी आहे. आणि निव्वळ सुरक्षिततेच्या दृष्टिकोनातून विचार केल्यास, malware द्वारे DoH चा गैरफायदा सक्रियपणे घेतला गेला आहे. Threat actors नी DoH चा वापर command-and-control channel म्हणून केला आहे कारण ते सामान्य HTTPS traffic मध्ये सहज मिसळते. GodLua backdoor ने command-and-control communications साठी DoH चा वापर केला होता. PsiXBot malware ने Google ची DoH service वापरली होती. जर तुमचे security monitoring संशयास्पद क्रियाकलाप शोधण्यासाठी DNS visibility वर अवलंबून असेल, तर DoH चे हे blind spots एक वास्तविक धोका आहेत. विभाग ३ - अंमलबजावणीच्या शिफारसी. चला, आता व्यावहारिक बाबी समजून घेऊया. सुरक्षिततेसाठी तीन मुख्य धोरणे आहेत, आणि बहुतांश ठिकाणांवरील उपयोजनांमध्ये (venue deployments), तुम्हाला या तिन्ही धोरणांचे एकत्रितपणे पालन करावे लागेल. धोरण १: फायरवॉलवर ज्ञात DoH रिझॉल्व्हर एंडपॉइंट्स ब्लॉक करणे. हा तुमचा संरक्षणाचा पहिला मार्ग आहे आणि सर्वात त्वरित अंमलात आणता येणारा पर्याय आहे. Google, Cloudflare, Quad9, NextDNS, AdGuard आणि इतरांसारख्या ज्ञात DoH रिझॉल्व्हर IP पत्त्यांची आणि डोमेन्सची एक ब्लॉकलिस्ट तयार ठेवा - आणि तुमच्या गेस्ट VLAN कडून त्या एंडपॉइंट्सवर जाणाऱ्या आउटबाउंड HTTPS ट्रॅफिकला नकार द्या. IETF आणि विविध सुरक्षा विक्रेते (security vendors) या लिस्ट तयार ठेवतात आणि अपडेट करत असतात. GitHub वरील curl प्रोजेक्ट ज्ञात DoH रिझॉल्व्हर्सची एक विस्तृत लिस्ट ठेवते, जी सुरुवात करण्यासाठी खूप उपयुक्त आहे. हा दृष्टिकोन बहुतांश DoH ट्रॅफिक हाताळतो कारण, Carnegie Mellon च्या Software Engineering Institute च्या संशोधनातून असे दिसून आले आहे की, बहुतेक 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 trust). गेस्ट डिव्हाइसेसवर TLS इन्स्पेक्शन काम करण्यासाठी, त्या डिव्हाइसेसनी तुमच्या इन्स्पेक्शन सर्टिफिकेटवर विश्वास ठेवणे आवश्यक आहे. मॅनेज्ड कॉर्पोरेट डिव्हाइसेसवर, हे सोपे असते - तुम्ही MDM द्वारे सर्टिफिकेट पाठवू शकता. अनमॅनेज्ड गेस्ट डिव्हाइसेसवर, हे अधिक कठीण असते. गेस्ट WiFi साठी व्यावहारिक दृष्टिकोन असा आहे की, युजर्सना कन्टेन्ट फिल्टरिंगच्या हेतूने ट्रॅफिक तपासले जाऊ शकते याची माहिती देण्यासाठी Captive Portal स्वीकृती प्रक्रियेचा वापर करणे, आणि तुमचे प्राथमिक नियंत्रण म्हणून DoH रिझॉल्व्हर ब्लॉकिंग आणि DNS इंटरसेप्शनच्या जोडणीवर विसंबून राहणे, तर अधिक जोखमीच्या वातावरणात TLS इन्स्पेक्शनचा दुय्यम स्तर म्हणून वापर करणे. धोरण ३: सक्तीने DNS इंटरसेप्शन आणि रीडायरेक्ट करणे. UDP आणि TCP पोर्ट ५३ वरील सर्व आउटबाउंड DNS ट्रॅफिक थांबवण्यासाठी (intercept) आणि तुमच्या सुसंगत DNS रिझॉल्व्हरकडे रीडायरेक्ट करण्यासाठी तुमचे फायरवॉल किंवा वायरलेस कंट्रोलर कॉन्फिगर करा. हे DoH थांबवत नाही, परंतु यामुळे हे सुनिश्चित होते की पोर्ट ५३ वर परत जाणारे (fall back) कोणतेही DNS ट्रॅफिक - कारण DoH अयशस्वी झाले किंवा उपलब्ध नव्हते - कॅप्चर आणि फिल्टर केले जाईल. DNS over TLS ला तुमच्या नियंत्रणांना बायपास करण्यापासून रोखण्यासाठी अतिथी VLAN वरून बाऊंड पोर्ट 853 ब्लॉक करण्यासोबत याचे एकत्रिकरण करा. मॅनेज केलेल्या एंडपॉइंट्ससाठी - कॉर्पोरेट डिव्हाइसेस, स्टाफ डिव्हाइसेस - तुमच्याकडे एक अतिरिक्त पर्याय आहे: ब्राउझर आणि 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 रिझॉल्व्हर IP ची स्टॅटिक ब्लॉकलिस्ट राखत असल्यास, ती कालबाह्य होईल. अपडेट प्रक्रिया स्वयंचलित करा किंवा तुमच्यासाठी ही लिस्ट राखणारी DNS फिल्टरिंग सर्व्हिस वापरा. Cloudflare Gateway, Cisco Umbrella आणि तत्सम एंटरप्राइझ DNS सेवांमध्ये मॅनेज्ड क्षमता म्हणून DoH बायपास डिटेक्शन समाविष्ट असते. चौथे: एकाच मिटिगेशन लेयरवर अति-अवलंबित्व. DoH मिटिगेशन ही एक सखोल संरक्षण समस्या आहे. कोणतेही एक नियंत्रण पुरेसे नाही. ज्ञात रिझॉल्व्हर्स ब्लॉक करणे बहुतेक प्रकरणांमध्ये उपयुक्त ठरते. TLS इन्स्पेक्शन एज केसेस हाताळते. DNS इंटरसेप्शन एक सुरक्षा कवच प्रदान करते. या तिन्हींचा थर तयार करा. विभाग पाच - रॅपिड-फायर प्रश्न. DoH मिटिगेशन कायदेशीर गोपनीयता साधनांना खंडित करते का? संभाव्यतः, होय. जर एखादा युझर कायदेशीर गोपनीयता-केंद्रित ब्राउझर कॉन्फिगरेशन चालवत असेल, तर तुमचे DoH ब्लॉकिंग त्यांना तुमचा DNS रिझॉल्व्हर वापरण्यास भाग पाडेल. तुमच्या स्वीकार्य वापर पॉलिसीमध्ये हे स्पष्ट केले पाहिजे की ठिकाणाचा DNS रिझॉल्व्हर हा कंटांन्ट फिल्टरिंगच्या हेतूंसाठी वापरला जातो. ही एक मानक पद्धत आहे आणि कायदेशीररित्या योग्य आहे. माझ्या नेटवर्कमधून डेटा चोरण्यासाठी DoH चा वापर केला जाऊ शकतो का? होय, आणि हा एक खरा थ्रेट व्हेक्टर आहे. DoH वरून DNS टनेलिंग प्रत्यक्ष वापरात दाखवले गेले आहे. तुमच्या नेक्स्ट-जनरेशन फायरवॉलच्या DoH डिटेक्शन क्षमतेमध्ये असामान्यपणे जास्त क्वेरी व्हॉल्यूम किंवा टनेलिंगशी सुसंगत असलेल्या क्वेरी पॅटर्नसाठी अनॉमली डिटेक्शन समाविष्ट असले पाहिजे. DoH वापरणाऱ्या मोबाईल ॲप्सबद्दल काय? हा सर्वात कठीण प्रकार आहे. जे मोबाईल ॲप्स स्वतःची DoH स्टॅक लागू करतात - OS DNS सेटिंग्ज वापरण्याऐवजी - त्यांना TLS तपासणीशिवाय नियंत्रित करणे कठीण आहे. ज्ञात रिझॉल्व्हर ब्लॉकिंग आणि TLS तपासणीचे एकत्रिकरण हा यावरील सर्वोत्तम उपाय आहे. या ठिकाणी WPA3 संबंधित आहे का? WPA3 ओव्हर-द-एअर एन्क्रिप्शन सुधारते आणि फॉरवर्ड गोपनीयता प्रदान करते, जी पाहुण्यांच्या प्रायव्हसीसाठी उत्कृष्ट आहे. परंतु WPA3 हे DoH ची समस्या सोडवत नाही - ती लेयर 7 ॲप्लिकेशन प्रोटोकॉलची समस्या आहे, लेयर 2 वायरलेस सुरक्षेची समस्या नाही. हे वेगवेगळ्या थ्रेट व्हेक्टर्सना हाताळणारे पूरक नियंत्रणे आहेत. विभाग सहा - ROI आणि व्यवसायावरील प्रभाव. मला हा विषय योग्यरित्या हाताळण्याच्या व्यावसायिक बाजूबद्दल सांगून समारोप करू द्या. DoH कडे दुर्लक्ष करण्याची किंमत असममित आहे. एकच घटना - तुमच्या नेटवर्कवर बेकायदेशीर कंटेंट ॲक्सेस करणारा एखादा पाहुणा, तुमच्या DNS मॉनिटरिंगमध्ये त्रुटी असल्यामुळे मालवेअर कॉलबॅक न शोधला जाणे, तुमच्या कंटेंट फिल्टरिंग अनुपालनाबद्दल (compliance) नियामक चौकशी - योग्य उपायांमध्ये केलेल्या गुंतवणुकीपेक्षा लक्षणीयरीत्या जास्त खर्चिक ठरू शकते. २० प्रॉपर्टीजमध्ये कार्यरत असलेल्या हॉटेल समूहासाठी, DoH उपायांच्या अंमलबजावणीमध्ये साधारणपणे फायरवॉल नियम आणि DNS इंटरसेप्शन कॉन्फिगरेशनसाठी प्रति प्रॉपर्टी दोन ते चार तासांचा एकवेळचा प्रयत्न करावा लागतो, तसेच रिझॉल्व्हर ब्लॉकलिस्ट राखण्याचा चालू असलेला ऑपरेशनल ओव्हरहेड - जो तुम्ही व्यवस्थापित DNS फिल्टरिंग सेवा वापरत असल्यास मुख्यत्वे स्वयंचलित असतो. जोखीम कमी करण्याच्या तुलनेत एकूण गुंतवणूक अगदी मर्यादित आहे. PCI DSS अंतर्गत कार्यरत असलेल्या रिटेल चेन्ससाठी, अनुपालनाचा (compliance) फायदा थेट मोजता येण्याजोगा आहे. तुमच्या नेटवर्क सुरक्षा नियंत्रणांमध्ये DoH उपाय समाविष्ट असल्याचे दाखवल्यास PCI DSS ऑडिटमध्ये त्रुटी आढळण्याची जोखीम आणि संबंधित दुरुस्तीचा खर्च कमी होतो. सार्वजनिक क्षेत्रातील ठिकाणे आणि ऑनलाइन सुरक्षा कायद्यांतर्गत (Online Safety Act) कार्यरत असलेल्या ठिकाणांसाठी, कागदोपत्री नोंदवलेले DoH उपाय हे तुम्ही तुमच्या कंटेंट फिल्टरिंग धोरणाची अंमलबजावणी करण्यासाठी वाजवी तांत्रिक पावले उचलल्याचा पुराव्याचा एक भाग आहे. थोडक्यात सांगायचे तर: DoH ही भविष्यातील समस्या नाही. ती सध्याची समस्या आहे. Firefox, Chrome, Android, आणि iOS हे सर्व आत्ताच तुमच्या पाहुण्यांच्या उपकरणांवर DoH-सक्षम कॉन्फिगरेशन्स पाठवत आहेत. जर तुम्ही मागील १२ महिन्यांत DoH बायपास व्हेक्टर्ससाठी तुमच्या DNS फिल्टरिंग आर्किटेक्चरचे ऑडिट केले नसेल, तर ते ऑडिट तुमच्या नजीकच्या काळातील रोडमॅपवर असले पाहिजे. आजच्या ब्रीफिंगमधील मुख्य मुद्दे थोडक्यात सांगण्यासाठी. एक: DoH हे पोर्ट ४४३ वरील HTTPS मध्ये DNS क्वेरी एन्क्रिप्ट करते, ज्यामुळे त्या पारंपारिक पोर्ट ५३ DNS फिल्टरिंगसाठी अदृश्य होतात. मुख्य प्रवाहातील ब्राउझर आणि ऑपरेटिंग सिस्टमवर हे डीफॉल्टनुसार घडत आहे. दोन: त्रि-स्तरीय उपाय धोरण - ज्ञात DoH रिझॉल्व्हर IPs ब्लॉक करणे, तुमच्या नेक्स्ट-जनरेशन फायरवॉलवर TLS तपासणी लागू करणे आणि पोर्ट ५३ इंटरसेप्शन लागू करणे - व्यवस्थापित आणि अव्यवस्थित दोन्ही पाहुण्यांच्या उपकरणांसाठी सखोल संरक्षण (defense-in-depth) कव्हरेज प्रदान करते. तीन: हा केवळ तांत्रिक प्रश्न नसून अनुपालनाचा (compliance) मुद्दा आहे. GDPR, ऑनलाइन सुरक्षा कायदा आणि PCI DSS या सर्वांचे अशा ठिकाणांसाठी परिणाम आहेत जिथे DoH मूकपणे कंटेंट फिल्टरिंग धोरणांना बायपास करत आहे.चार: अंमलबजावणीतील सर्वात सामान्य अपयश म्हणजे अपूर्ण port 53 इंटरसेप्शन. याची चाचणी घ्या. याची पडताळणी करा. हे काम करत आहे असे गृहीत धरू नका. पाच: मॅनेज्ड DNS फिल्टरिंग सेवा - Cloudflare Gateway, Cisco Umbrella आणि तत्सम - यामध्ये व्यवस्थापित क्षमता म्हणून DoH बायपास शोधण्याच्या सुविधेचा वाढत्या प्रमाणात समावेश होत आहे, ज्यामुळे स्टॅटिक ब्लॉकलिस्ट राखण्याचा ऑपरेशनल ओव्हरहेड कमी होतो. आजच्या Purple तांत्रिक माहितीपत्रासाठी (Technical Briefing) एवढेच. आपण आपल्या सध्याच्या DNS फिल्टरिंग आर्किटेक्चरचे ऑडिट करू इच्छित असल्यास किंवा आपल्या संपूर्ण वेन्यू इस्टेटमध्ये DoH कमी करण्याची प्रक्रिया लागू करू इच्छित असल्यास, Purple प्लॅटफॉर्म त्या उपयोजनास सहाय्य करण्यासाठी आवश्यक नेटवर्क इंटेलिजन्स आणि गेस्ट WiFi व्यवस्थापन स्तर प्रदान करतो. ऐकल्याबद्दल धन्यवाद, आणि आम्ही आपल्याला पुढील सत्रात भेटू.