DNS Over HTTPS (DoH): পাবলিক WiFi ফিল্টারিংয়ের জন্য এর প্রভাব

Purple টেকনিক্যাল ব্রিফিংয়ে স্বাগতম। আমি আজকের সেশনের জন্য আপনাদের হোস্ট, এবং আমরা পরবর্তী দশ মিনিট এমন একটি বিষয়ে ব্যয় করতে যাচ্ছি যা এই মুহূর্তে হাজার হাজার পাবলিক WiFi ডিপ্লয়মেন্ট জুড়ে কন্টেন্ট ফিল্টারিং পলিসিগুলোকে নীরবে দুর্বল করে দিচ্ছে — DNS over HTTPS, বা DoH。 আপনি যদি কোনো হোটেল, রিটেইল এস্টেট, স্টেডিয়াম বা পাবলিক সেক্টর ফ্যাসিলিটিতে গেস্ট WiFi পরিচালনা করেন এবং আপনি যদি আপনার নেটওয়ার্ক আর্কিটেকচারে বিশেষভাবে DoH-এর সমাধান না করে থাকেন, তবে আপনার ফিল্টারিং পলিসিতে একটি উল্লেখযোগ্য গ্যাপ থাকার যুক্তিসঙ্গত সম্ভাবনা রয়েছে। আসুন আমরা কাজ করে দেখি সেই গ্যাপটি ঠিক কী, কেন এটি গুরুত্বপূর্ণ এবং আপনি এটি সম্পর্কে কী করতে পারেন。 সেকশন এক — প্রেক্ষাপট এবং প্রবলেম স্টেটমেন্ট。 প্রথাগত DNS ফিল্টারিং কীভাবে কাজ করে তার একটি দ্রুত রিক্যাপ দিয়ে শুরু করা যাক, কারণ বাইপাস মেকানিজম বোঝার জন্য কী বাইপাস করা হচ্ছে তা বোঝা প্রয়োজন。 যখন কোনো গেস্ট ডিভাইস আপনার WiFi-এ কানেক্ট করে এবং কোনো ওয়েবসাইটে ভিজিট করার চেষ্টা করে, তখন এটি প্রথম যে কাজটি করে তা হলো একটি DNS কোয়েরি পাঠানো — মূলত জিজ্ঞাসা করে যে এই ডোমেইনের IP অ্যাড্রেস কী? সেই কোয়েরিটি UDP বা TCP-এর মাধ্যমে পোর্ট 53-এ ট্রাভেল করে। আপনার নেটওয়ার্ক ইনফ্রাস্ট্রাকচার সেই কোয়েরিটি ইন্টারসেপ্ট করে, এটিকে আপনার নির্বাচিত DNS রিভলভারের দিকে রাউট করে এবং সেই রিভলভারটি আপনার ফিল্টারিং পলিসির বিপরীতে ডোমেইনটি চেক করে। যদি ডোমেইনটি কোনো ব্লকলিস্টে থাকে — ম্যালওয়্যার, অ্যাডাল্ট কন্টেন্ট, জুয়া, বা আপনার গ্রহণযোগ্য ব্যবহারের পলিসি যা নির্দিষ্ট করে — রিভলভারটি IP অ্যাড্রেস ফেরত দিতে অস্বীকার করে এবং কানেকশনটি কখনোই ঘটে না。 এটি প্রতিটি DNS-ভিত্তিক কন্টেন্ট ফিল্টারিং ডিপ্লয়মেন্টের ভিত্তি। এটি সাশ্রয়ী, এটি থ্রুপুটকে প্রভাবিত করে না এবং এটি প্রায় এক দশক ধরে ভেন্যু অপারেটরদের জন্য স্ট্যান্ডার্ড অ্যাপ্রোচ হিসেবে রয়েছে。 DNS over HTTPS এই মডেলটিকে ভেঙে দেয়। এখানে কীভাবে তা দেওয়া হলো。 DoH পোর্ট 443-এ স্ট্যান্ডার্ড HTTPS ট্রাফিকের ভেতরে DNS কোয়েরিগুলোকে র‍্যাপ করে। আপনার নেটওয়ার্কের দৃষ্টিকোণ থেকে, এটি অন্য যেকোনো এনক্রিপ্টেড ওয়েব ট্রাফিকের মতোই দেখায়। একজন ব্যবহারকারীর ওয়েবপেজ লোড করা, ভিডিও স্ট্রিম করা বা ব্যাংকিং অ্যাপ অ্যাক্সেস করার থেকে একটি DoH কোয়েরিকে আলাদা করার কোনো উপায় নেই। কোয়েরিটি সরাসরি একটি এক্সটার্নাল DoH রিভলভারের কাছে যায় — Google-এর 8.8.8.8, Cloudflare-এর 1.1.1.1, বা অন্য যেকোনো সংখ্যক — একটি এনক্রিপ্টেড চ্যানেলের মাধ্যমে যা আপনার DNS ফিল্টার ইন্সপেক্ট করতে পারে না。 ফলাফল? আপনার সতর্কতার সাথে কনফিগার করা DNS ফিল্টারিং পলিসি সম্পূর্ণভাবে বাইপাস হয়ে যায়। আপনার রিভলভার কোয়েরিটি না দেখেই ডিভাইসটি সরাসরি ডোমেইনটি রিজলভ করে。 এখন, এটি আপনার গেস্টদের দ্বারা কোনো ইচ্ছাকৃত আক্রমণ নয়। বেশিরভাগ ক্ষেত্রেই এটি সম্পূর্ণ প্যাসিভ। 2020 সাল থেকে Firefox-এ ডিফল্টভাবে DoH এনাবল করা আছে। কনফিগার করা রিভলভার যদি এটি সমর্থন করে তবে Chrome স্বয়ংক্রিয়ভাবে DNS কোয়েরিগুলোকে DoH-এ আপগ্রেড করে। Android 9 এবং এর ওপরের ভার্সনগুলো ডিফল্টভাবে DNS over TLS-এর সাথে Private 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 এন্ডপয়েন্ট ব্যবহার করবে。 আপনার মিটিগেশন স্ট্র্যাটেজির জন্য এই পার্থক্যটি গুরুত্বপূর্ণ, যা আমরা শীঘ্রই আলোচনা করব。 উল্লেখ করার মতো তৃতীয় একটি ভেক্টর রয়েছে: DNS over TLS, বা DoT। এটি পোর্ট 853-এ কাজ করে এবং DNS কোয়েরিগুলোকে HTTPS-এ র‍্যাপ করার পরিবর্তে TLS ব্যবহার করে এনক্রিপ্ট করে। এটি DoH-এর চেয়ে ব্লক করা সহজ কারণ এটি একটি ডেডিকেটেড পোর্ট ব্যবহার করে, তবে Private DNS এনাবল করা Android ডিভাইসগুলোতে এটি ক্রমবর্ধমানভাবে সাধারণ হয়ে উঠছে। আপনার মিটিগেশন স্ট্র্যাটেজিতে উভয়কেই মোকাবেলা করতে হবে。 এখন আসুন কথা বলি কেন এটি একটি কমপ্লায়েন্স এবং অপারেশনাল ঝুঁকি, কেবল একটি টেকনিক্যাল কৌতূহল নয়。 GDPR-এর অধীনে, যদি আপনার গ্রহণযোগ্য ব্যবহারের পলিসিতে বলা থাকে যে আপনি কন্টেন্টের নির্দিষ্ট ক্যাটাগরি ফিল্টার করেন এবং আপনার টেকনিক্যাল কন্ট্রোলগুলো আসলে সেই পলিসি প্রয়োগ করে না, তবে আপনার বিবৃত ডেটা সুরক্ষা এবং কন্টেন্ট গভর্ন্যান্স প্রতিশ্রুতি এবং আপনার প্রকৃত টেকনিক্যাল ইমপ্লিমেন্টেশনের মধ্যে একটি গ্যাপ রয়েছে। আপনি যদি কখনও কোনো রেগুলেটরি ইনকোয়ারি বা ঘটনার সম্মুখীন হন তবে এটি একটি আইনি সমর্থনের সমস্যা。 যুক্তরাজ্যের অনলাইন সেফটি অ্যাক্টের অধীনে, পাবলিক ইন্টারনেট অ্যাক্সেস প্রদানকারী ভেন্যু অপারেটরদের ব্যবহারকারীদের — বিশেষ করে অপ্রাপ্তবয়স্কদের — ক্ষতিকারক কন্টেন্ট থেকে রক্ষা করার বিষয়ে বাধ্যবাধকতা রয়েছে। যদি 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 ট্রাফিক ইন্সপেকশন পলিসির মাধ্যমে রাউট করা হয়েছে তা নিশ্চিত করা。 এখানে অপারেশনাল বিবেচনাটি হলো সার্টিফিকেট ট্রাস্ট। গেস্ট ডিভাইসগুলোতে 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 রিভলভার 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 মনিটরিংয়ে একটি ব্লাইন্ড স্পট ছিল, আপনার কন্টেন্ট ফিল্টারিং কমপ্লায়েন্স সম্পর্কে একটি রেগুলেটরি ইনকোয়ারি — সঠিক মিটিগেশনে বিনিয়োগের চেয়ে উল্লেখযোগ্যভাবে বেশি খরচ হতে পারে。 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 রিভলভার IP-গুলো ব্লক করা, আপনার নেক্সট-জেনারেশন ফায়ারওয়ালে TLS ইন্সপেকশন ইমপ্লিমেন্ট করা এবং পোর্ট 53 ইন্টারসেপশন এনফোর্স করা — ম্যানেজড এবং আনম্যানেজড উভয় গেস্ট ডিভাইসের জন্য ডিফেন্স-ইন-ডেপথ কভারেজ প্রদান করে。 তিন: এটি একটি কমপ্লায়েন্স সমস্যা, কেবল একটি টেকনিক্যাল সমস্যা নয়। GDPR, অনলাইন সেফটি অ্যাক্ট এবং PCI DSS সবগুলোরই সেইসব ভেন্যুর জন্য প্রভাব রয়েছে যেখানে DoH নীরবে কন্টেন্ট ফিল্টারিং পলিসি বাইপাস করছে。 চার: সবচেয়ে সাধারণ ইমপ্লিমেন্টেশন ফেইলিওর হলো অসম্পূর্ণ পোর্ট 53 ইন্টারসেপশন। এটি পরীক্ষা করুন। এটি যাচাই করুন। এটি কাজ করছে বলে ধরে নেবেন না。 পাঁচ: ম্যানেজড DNS ফিল্টারিং সার্ভিসগুলো — Cloudflare Gateway, Cisco Umbrella এবং অনুরূপ — ক্রমবর্ধমানভাবে একটি ম্যানেজড সক্ষমতা হিসেবে DoH বাইপাস ডিটেকশন অন্তর্ভুক্ত করে, যা স্ট্যাটিক ব্লকলিস্ট বজায় রাখার অপারেশনাল ওভারহেড হ্রাস করে。 আজকের Purple টেকনিক্যাল ব্রিফিংয়ের জন্য এটুকুই। আপনি যদি আপনার বর্তমান DNS ফিল্টারিং আর্কিটেকচার অডিট করতে চান বা আপনার ভেন্যু এস্টেট জুড়ে DoH মিটিগেশন ইমপ্লিমেন্ট করতে চান, তবে Purple প্ল্যাটফর্ম সেই ডিপ্লয়মেন্টকে সমর্থন করার জন্য নেটওয়ার্ক ইন্টেলিজেন্স এবং গেস্ট WiFi ম্যানেজমেন্ট লেয়ার প্রদান করে। শোনার জন্য ধন্যবাদ, এবং পরবর্তী সেশনে আপনাদের সাথে দেখা হবে।