DNS Over HTTPS (DoH): सार्वजनिक WiFi फिल्टरिंगवरील परिणाम

Purple टेक्निकल ब्रीफिंगमध्ये आपले स्वागत आहे. आजच्या सत्रासाठी मी तुमचा होस्ट आहे, आणि आपण पुढील दहा मिनिटे अशा विषयावर घालवणार आहोत जो सध्या हजारो सार्वजनिक WiFi उपयोजनांमध्ये कंटेंट फिल्टरिंग धोरणांना शांतपणे कमकुवत करत आहे — DNS over HTTPS, किंवा DoH. जर तुम्ही हॉटेल, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील सुविधेत अतिथी WiFi चालवत असाल आणि तुम्ही तुमच्या नेटवर्क आर्किटेक्चरमध्ये DoH चे विशेष निवारण केले नसेल, तर तुमच्या फिल्टरिंग पॉलिसीमध्ये मोठी त्रुटी असण्याची दाट शक्यता आहे. ही त्रुटी नेमकी काय आहे, ती का महत्त्वाची आहे आणि तुम्ही त्याबद्दल काय करू शकता यावर आपण सविस्तर चर्चा करूया. विभाग एक — संदर्भ आणि समस्येचे विधान. पारंपारिक DNS फिल्टरिंग कसे कार्य करते याच्या द्रुत पुनरावलोकनासह प्रारंभ करूया, कारण बायपास यंत्रणा समजून घेण्यासाठी काय बायपास केले जात आहे हे समजून घेणे आवश्यक आहे. जेव्हा एखादे अतिथी डिव्हाइस तुमच्या WiFi शी कनेक्ट होते आणि एखाद्या वेबसाइटला भेट देण्याचा प्रयत्न करते, तेव्हा ते सर्वात आधी DNS क्वेरी पाठवते — मूलतः या डोमेनचा IP पत्ता काय आहे हे विचारते. ती क्वेरी पोर्ट 53 वर UDP किंवा TCP द्वारे प्रवास करते. तुमचे नेटवर्क इन्फ्रास्ट्रक्चर ती क्वेरी इंटरसेप्ट करते, ती तुमच्या निवडलेल्या DNS रिझॉल्व्हरकडे राउट करते आणि तो रिझॉल्व्हर तुमच्या फिल्टरिंग पॉलिसीनुसार डोमेन तपासतो. जर डोमेन ब्लॉकलिस्टवर असेल — मालवेअर, प्रौढ कंटेंट, जुगार, तुमच्या स्वीकार्य वापर धोरणात जे काही नमूद असेल — तर रिझॉल्व्हर IP पत्ता परत करण्यास नकार देतो आणि कनेक्शन कधीच प्रस्थापित होत नाही. हे प्रत्येक DNS-आधारित कंटेंट फिल्टरिंग उपयोजनाचे मूळ आहे. हे किफायतशीर आहे, याचा थ्रूपुटवर परिणाम होत नाही आणि गेल्या दशकातील बहुतांश काळ ठिकाण चालकांसाठी हा मानक दृष्टिकोन राहिला आहे. DNS over HTTPS हे मॉडेल मोडीत काढते. ते कसे ते येथे आहे. DoH पोर्ट 443 वरील मानक HTTPS ट्रॅफिकमध्ये DNS क्वेरी रॅप करते. तुमच्या नेटवर्कच्या दृष्टीकोनातून, हे इतर कोणत्याही एनक्रिप्टेड वेब ट्रॅफिकसारखेच दिसते. वापरकर्त्याने वेबपेज लोड करणे, व्हिडिओ स्ट्रीम करणे किंवा बँकिंग ॲप वापरणे यामधील आणि 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 ने iOS 14 पासून 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 एंडपॉइंट वापरेल. हा फरक तुमच्या शमन धोरणासाठी महत्त्वाचा आहे, ज्याकडे आपण लवकरच वळू. उल्लेख करण्यासारखा तिसरा मार्ग आहे: DNS over TLS, किंवा DoT. हे पोर्ट 853 वर कार्य करते आणि HTTPS मध्ये रॅप करण्याऐवजी TLS वापरून DNS क्वेरी एनक्रिप्ट करते. DoH पेक्षा हे ब्लॉक करणे सोपे आहे कारण ते समर्पित पोर्ट वापरते, परंतु खाजगी DNS सक्षम असलेल्या Android डिव्हाइसेसवर हे वाढत्या प्रमाणात सामान्य आहे. तुमच्या शमन धोरणाने या दोन्हीचे निवारण करणे आवश्यक आहे. आता हे केवळ तांत्रिक कुतूहल नसून अनुपालन (compliance) आणि ऑपरेशनल जोखीम का आहे याबद्दल बोलूया. GDPR अंतर्गत, जर तुमचे स्वीकार्य वापर धोरण असे सांगत असेल की तुम्ही कंटेंटच्या विशिष्ट श्रेणी फिल्टर करता आणि तुमचे तांत्रिक नियंत्रणे प्रत्यक्षात त्या धोरणाची अंमलबजावणी करत नसतील, तर तुमच्या घोषित डेटा संरक्षण आणि कंटेंट गव्हर्नन्स वचनबद्धतेमध्ये आणि तुमच्या वास्तविक तांत्रिक अंमलबजावणीमध्ये तफावत आहे. जर तुम्हाला कधी नियामक चौकशी किंवा घटनेचा सामना करावा लागला तर ही बचावाची समस्या ठरू शकते. UK च्या ऑनलाइन सेफ्टी ॲक्ट अंतर्गत, सार्वजनिक इंटरनेट प्रवेश प्रदान करणाऱ्या ठिकाण चालकांवर वापरकर्त्यांना — विशेषतः अल्पवयीन मुलांना — हानिकारक कंटेंटपासून संरक्षित करण्याचे दायित्व आहे. जर DoH शांतपणे तुमचे कंटेंट फिल्टरिंग बायपास करत असेल, तर तुम्ही कदाचित त्या दायित्वांची पूर्तता करत नसाल. PCI DSS च्या कक्षेत येणाऱ्या ठिकाणांसाठी — विशेषतः जिथे पेमेंट कार्ड डेटा अतिथी WiFi च्या लगतच्या नेटवर्कवरून प्रवाहित होतो — PCI DSS आवृत्ती 4.0 नुसार तुम्ही तुमच्या नेटवर्क सुरक्षा नियंत्रणांचा भाग म्हणून DNS ट्रॅफिकचे निरीक्षण आणि नियंत्रण करणे आवश्यक आहे. अनियंत्रित DoH ट्रॅफिक ही त्या नियंत्रण फ्रेमवर्कमधील एक त्रुटी आहे. आणि निव्वळ सुरक्षेच्या दृष्टिकोनातून, मालवेअरद्वारे DoH चा सक्रियपणे गैरफायदा घेतला गेला आहे. थ्रेट ॲक्टर्सनी DoH चा कमांड-अँड-कंट्रोल चॅनेल म्हणून वापर केला आहे कारण ते सामान्य HTTPS ट्रॅफिकमध्ये मिसळते. GodLua बॅकडोअरने कमांड-अँड-कंट्रोल कम्युनिकेशन्ससाठी DoH चा वापर केला. PsiXBot मालवेअरने Google च्या DoH सेवेचा वापर केला. जर तुमचे सुरक्षा मॉनिटरिंग दुर्भावनापूर्ण क्रियाकलाप शोधण्यासाठी DNS दृश्यमानतेवर अवलंबून असेल, तर DoH ब्लाइंड स्पॉट्स हा एक खरा धोका आहे. विभाग तीन — अंमलबजावणीच्या शिफारसी. चला, व्यावहारिक बनूया. तीन प्राथमिक शमन धोरणे आहेत आणि बहुतेक ठिकाणांच्या उपयोजनांमध्ये, तुम्हाला या तिन्हींची एकत्रित अंमलबजावणी करायची असेल. धोरण एक: फायरवॉलवर ज्ञात 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 trust). अतिथी डिव्हाइसेसवर TLS तपासणी कार्य करण्यासाठी, त्या डिव्हाइसेसनी तुमच्या तपासणी प्रमाणपत्रावर विश्वास ठेवला पाहिजे. व्यवस्थापित कॉर्पोरेट डिव्हाइसेसवर, हे सोपे आहे — तुम्ही MDM द्वारे प्रमाणपत्र पुश करता. अव्यवस्थित अतिथी डिव्हाइसेसवर, हे अधिक क्लिष्ट आहे. अतिथी WiFi साठी व्यावहारिक दृष्टिकोन म्हणजे वापरकर्त्यांना हे सांगण्यासाठी Captive Portal स्वीकार प्रवाह वापरणे की कंटेंट फिल्टरिंगच्या उद्देशाने ट्रॅफिकची तपासणी केली जाऊ शकते, आणि प्राथमिक नियंत्रणे म्हणून DoH रिझॉल्व्हर ब्लॉकिंग आणि DNS इंटरसेप्शनच्या संयोजनावर अवलंबून राहणे, ज्यामध्ये उच्च-जोखीम वातावरणासाठी दुय्यम स्तर म्हणून TLS तपासणी असेल. धोरण तीन: सक्तीने DNS इंटरसेप्शन आणि रीडायरेक्ट करा. UDP आणि TCP पोर्ट 53 वरील सर्व आउटबाउंड DNS ट्रॅफिक इंटरसेप्ट करण्यासाठी आणि तुमच्या सुसंगत DNS रिझॉल्व्हरकडे रीडायरेक्ट करण्यासाठी तुमचे फायरवॉल किंवा वायरलेस कंट्रोलर कॉन्फिगर करा. हे DoH थांबवत नाही, परंतु हे सुनिश्चित करते की जे काही DNS ट्रॅफिक पोर्ट 53 वर परत येते — कारण 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 रिझॉल्व्हर IPs ची स्टॅटिक ब्लॉकलिस्ट ठेवत असाल, तर ती कालबाह्य होईल. अपडेट प्रक्रिया स्वयंचलित करा किंवा तुमच्यासाठी ही यादी ठेवणारी DNS फिल्टरिंग सेवा वापरा. Cloudflare Gateway, Cisco Umbrella आणि तत्सम एंटरप्राइझ DNS सेवांमध्ये व्यवस्थापित क्षमता म्हणून DoH बायपास शोधणे समाविष्ट आहे. चौथे: एकाच शमन स्तरावर जास्त अवलंबून राहणे. DoH शमन ही 'डिफेन्स-इन-डेप्थ' समस्या आहे. कोणतेही एक नियंत्रण पुरेसे नाही. ज्ञात रिझॉल्व्हर्स ब्लॉक करणे बहुतेक प्रकरणांना हाताळते. TLS तपासणी कठीण प्रकरणांना हाताळते. DNS इंटरसेप्शन एक सुरक्षा जाळे प्रदान करते. या तिन्हींचा थर द्या. विभाग पाच — जलद प्रश्नोत्तरे. DoH शमन कायदेशीर गोपनीयता साधनांना खंडित करते का? संभाव्यतः, होय. जर एखादा वापरकर्ता कायदेशीर गोपनीयता-केंद्रित ब्राउझर कॉन्फिगरेशन चालवत असेल, तर तुमचे DoH ब्लॉकिंग त्यांना तुमचा DNS रिझॉल्व्हर वापरण्यास भाग पाडेल. तुमच्या स्वीकार्य वापर धोरणाने हे स्पष्ट केले पाहिजे की कंटेंट फिल्टरिंगच्या उद्देशाने ठिकाणाचा DNS रिझॉल्व्हर वापरला जातो. ही मानक पद्धत आहे आणि कायदेशीररित्या बचावात्मक आहे. माझ्या नेटवर्कमधून डेटा चोरण्यासाठी (exfiltrate) DoH चा वापर केला जाऊ शकतो का? होय, आणि हा एक खरा धोका आहे. DoH वर DNS टनेलिंग प्रत्यक्ष व्यवहारात दाखवले गेले आहे. तुमच्या नेक्स्ट-जनरेशन फायरवॉलच्या DoH शोधण्याच्या क्षमतेमध्ये असामान्यपणे जास्त क्वेरी व्हॉल्यूम किंवा टनेलिंगशी सुसंगत क्वेरी पॅटर्नसाठी विसंगती शोधणे (anomaly detection) समाविष्ट असावे. DoH वापरणाऱ्या मोबाईल ॲप्सचे काय? हे सर्वात कठीण प्रकरण आहे. जे मोबाईल ॲप्स OS DNS सेटिंग्ज वापरण्याऐवजी स्वतःचा DoH स्टॅक लागू करतात — त्यांना TLS तपासणीशिवाय नियंत्रित करणे कठीण आहे. तुमचे सर्वोत्तम शमन म्हणजे ज्ञात रिझॉल्व्हर ब्लॉकिंग आणि TLS तपासणीचे संयोजन. येथे WPA3 प्रासंगिक आहे का? WPA3 ओव्हर-द-एअर एनक्रिप्शन सुधारते आणि फॉरवर्ड गुप्तता प्रदान करते, जे अतिथी गोपनीयतेसाठी उत्कृष्ट आहे. परंतु WPA3 DoH चे निवारण करत नाही — ती लेयर 7 ॲप्लिकेशन प्रोटोकॉलची समस्या आहे, लेयर 2 वायरलेस सुरक्षा समस्या नाही. ती वेगवेगळ्या धोक्यांचे निवारण करणारी पूरक नियंत्रणे आहेत. विभाग सहा — ROI आणि व्यावसायिक प्रभाव. याचे योग्य निवारण करण्यासाठीच्या बिझनेस केससह मी समारोप करतो. DoH चे निवारण न करण्याचा खर्च असममित (asymmetric) आहे. एकच घटना — एखाद्या अतिथीने तुमच्या नेटवर्कवर बेकायदेशीर कंटेंट पाहणे, तुमच्या DNS मॉनिटरिंगमध्ये ब्लाइंड स्पॉट असल्यामुळे मालवेअर कॉलबॅक न शोधला जाणे, तुमच्या कंटेंट फिल्टरिंग अनुपालनाबद्दल नियामक चौकशी — योग्य शमनामधील गुंतवणुकीपेक्षा लक्षणीयरीत्या जास्त खर्चिक ठरू शकते. २० मालमत्तांमध्ये कार्यरत असलेल्या हॉटेल समूहासाठी, DoH शमन तैनात करण्यामध्ये सामान्यतः फायरवॉल नियम आणि DNS इंटरसेप्शन कॉन्फिगरेशनसाठी प्रति मालमत्ता दोन ते चार तासांचा एक-वेळचा कॉन्फिगरेशन प्रयत्न समाविष्ट असतो, तसेच रिझॉल्व्हर ब्लॉकलिस्ट राखण्याचा चालू असलेला ऑपरेशनल ओव्हरहेड असतो — जो तुम्ही व्यवस्थापित DNS फिल्टरिंग सेवा वापरत असल्यास मोठ्या प्रमाणात स्वयंचलित असतो. जोखीम कमी करण्याच्या तुलनेत एकूण गुंतवणूक माफक आहे. PCI DSS अंतर्गत कार्यरत असलेल्या रिटेल चेनसाठी, अनुपालन लाभ थेट मोजता येण्याजोगा आहे. तुमच्या नेटवर्क सुरक्षा नियंत्रणांमध्ये DoH शमन समाविष्ट असल्याचे दर्शविल्याने PCI DSS ऑडिटच्या निष्कर्षाची जोखीम आणि संबंधित निवारण खर्च कमी होतो. सार्वजनिक क्षेत्रातील ठिकाणे आणि ऑनलाइन सेफ्टी ॲक्ट अंतर्गत कार्यरत असलेल्यांसाठी, दस्तऐवजीकरण केलेले DoH शमन हा तुमच्या पुराव्याचा भाग आहे की तुम्ही तुमच्या कंटेंट फिल्टरिंग धोरणाची अंमलबजावणी करण्यासाठी वाजवी तांत्रिक पावले उचलली आहेत. थोडक्यात सांगायचे तर: DoH ही भविष्यातील समस्या नाही. ती सध्याची समस्या आहे. Firefox, Chrome, Android आणि iOS हे सर्व सध्या तुमच्या अतिथींच्या डिव्हाइसेसवर DoH-सक्षम कॉन्फिगरेशन पाठवत आहेत. जर तुम्ही गेल्या १२ महिन्यांत DoH बायपास मार्गांसाठी तुमच्या DNS फिल्टरिंग आर्किटेक्चरचे ऑडिट केले नसेल, तर ते ऑडिट तुमच्या नजीकच्या रोडमॅपवर असले पाहिजे. आजच्या ब्रीफिंगमधील मुख्य मुद्दे थोडक्यात सांगायचे तर. एक: DoH पोर्ट 443 वरील HTTPS मध्ये DNS क्वेरी एनक्रिप्ट करते, ज्यामुळे त्या पारंपारिक पोर्ट 53 DNS फिल्टरिंगला अदृश्य होतात. मुख्य प्रवाहातील ब्राउझर आणि ऑपरेटिंग सिस्टमवर हे डीफॉल्टनुसार घडत आहे. दोन: त्रि-स्तरीय शमन धोरण — ज्ञात DoH रिझॉल्व्हर IPs ब्लॉक करणे, तुमच्या नेक्स्ट-जनरेशन फायरवॉलवर TLS तपासणी लागू करणे आणि पोर्ट 53 इंटरसेप्शन सक्तीने लागू करणे — व्यवस्थापित आणि अव्यवस्थित अतिथी डिव्हाइसेस दोन्हीसाठी 'डिफेन्स-इन-डेप्थ' कव्हरेज प्रदान करते. तीन: हा अनुपालनाचा (compliance) मुद्दा आहे, केवळ तांत्रिक नाही. GDPR, ऑनलाइन सेफ्टी ॲक्ट आणि PCI DSS या सर्वांचे अशा ठिकाणांसाठी परिणाम आहेत जिथे DoH शांतपणे कंटेंट फिल्टरिंग धोरणे बायपास करत आहे. चार: सर्वात सामान्य अंमलबजावणी अपयश म्हणजे अपूर्ण पोर्ट 53 इंटरसेप्शन. त्याची चाचणी घ्या. ते सत्यापित करा. ते कार्य करत आहे असे गृहीत धरू नका. पाच: व्यवस्थापित DNS फिल्टरिंग सेवा — Cloudflare Gateway, Cisco Umbrella आणि तत्सम — वाढत्या प्रमाणात व्यवस्थापित क्षमता म्हणून DoH बायपास शोधणे समाविष्ट करतात, ज्यामुळे स्टॅटिक ब्लॉकलिस्ट राखण्याचा ऑपरेशनल ओव्हरहेड कमी होतो. आजच्या Purple तांत्रिक ब्रीफिंगसाठी एवढेच. जर तुम्ही तुमच्या सध्याच्या DNS फिल्टरिंग आर्किटेक्चरचे ऑडिट करू इच्छित असाल किंवा तुमच्या ठिकाणांवर DoH शमन लागू करू इच्छित असाल, तर Purple प्लॅटफॉर्म त्या उपयोजनास समर्थन देण्यासाठी नेटवर्क इंटेलिजन्स आणि अतिथी WiFi व्यवस्थापन स्तर प्रदान करतो. ऐकल्याबद्दल धन्यवाद, आणि आपण पुढील सत्रात भेटू.