RadSec: RADIUS over TLS कैसे WiFi ऑथेंटिकेशन सिक्योरिटी को बेहतर बनाता है

RadSec: RADIUS over TLS कैसे WiFi ऑथेंटिकेशन सिक्योरिटी को बेहतर बनाता है एक Purple एंटरप्राइज़ WiFi इंटेलिजेंस ब्रीफ़िंग अनुमानित रनटाइम: 10 मिनट --- [परिचय और संदर्भ — लगभग 1 मिनट] Purple एंटरप्राइज़ WiFi इंटेलिजेंस सीरीज़ में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम एक ऐसे विषय पर चर्चा कर रहे हैं जो नेटवर्क सुरक्षा और ऑपरेशनल जोखिम के बिल्कुल चौराहे पर है: RadSec — जिसे औपचारिक रूप से RFC 6614 में परिभाषित किया गया है — और यदि यह पहले से नहीं है तो इसे आपके इंफ्रास्ट्रक्चर रोडमैप पर क्यों होना चाहिए। यदि आप एक IT प्रबंधक, नेटवर्क आर्किटेक्ट, या CTO हैं जो किसी होटल समूह, रिटेल एस्टेट, स्टेडियम या सार्वजनिक क्षेत्र के कैंपस में एंटरप्राइज़ WiFi के लिए ज़िम्मेदार हैं, तो यह ब्रीफ़िंग आपके लिए है। हम कवर करने जा रहे हैं कि RadSec वास्तव में क्या है, पारंपरिक RADIUS प्रोटोकॉल आपको असुरक्षित क्यों छोड़ देता है, वास्तविक दुनिया के वातावरण में RadSec को कैसे डिप्लॉय किया जाए, और वे कमियाँ जो टीमों को फँसाती हैं। केवल सिद्धांत के लिए कोई सिद्धांत नहीं — बस वह जानकारी जो आपको इस तिमाही में निर्णय लेने के लिए चाहिए। आइए इसमें गोता लगाएँ। --- [तकनीकी डीप-डाइव — लगभग 5 मिनट] तो, आइए समस्या से शुरू करते हैं। RADIUS — रिमोट ऑथेंटिकेशन डायल-इन यूज़र सर्विस — 1990 के दशक से एंटरप्राइज़ WiFi ऑथेंटिकेशन की रीढ़ रहा है। जब कोई यूज़र या डिवाइस आपके कॉर्पोरेट या गेस्ट WiFi से कनेक्ट होता है, तो एक्सेस पॉइंट RADIUS क्लाइंट के रूप में कार्य करता है, जो ऑथेंटिकेशन अनुरोधों को RADIUS सर्वर पर फॉरवर्ड करता है, जो आपकी डायरेक्टरी — Active Directory, LDAP, या क्लाउड आइडेंटिटी प्रोवाइडर — के विरुद्ध क्रेडेंशियल्स को मान्य करता है और एक्सेस प्रदान करता है या अस्वीकार करता है। यह 802.1X ऑथेंटिकेशन मॉडल है जो WPA2-Enterprise और WPA3-Enterprise नेटवर्क को रेखांकित करता है。 समस्या यह है कि पारंपरिक RADIUS को एक अलग युग के लिए डिज़ाइन किया गया था। यह पोर्ट 1812 और 1813 पर UDP — यूज़र डेटाग्राम प्रोटोकॉल — पर चलता है। UDP कनेक्शनलेस है, जिसका अर्थ है कि कोई हैंडशेक नहीं है, कोई सेशन स्टेट नहीं है, और गंभीर रूप से, कोई नेटिव एन्क्रिप्शन नहीं है। आपके एक्सेस पॉइंट और आपके RADIUS सर्वर के बीच एकमात्र सुरक्षा एक शेयर्ड सीक्रेट है — अनिवार्य रूप से एक पासवर्ड — जिसका उपयोग MD5 हैशिंग का उपयोग करके ट्रांज़िट में यूज़र के पासवर्ड को अस्पष्ट करने के लिए किया जाता है। MD5, जैसा कि आप में से अधिकांश लोग जानते होंगे, क्रिप्टोग्राफ़िक रूप से टूट चुका है। यह सालों से टूटा हुआ है。 व्यवहार में इसका क्या अर्थ है? इसका मतलब है कि किसी भी नेटवर्क सेगमेंट पर जहाँ कोई हमलावर RADIUS ट्रैफ़िक को इंटरसेप्ट कर सकता है — और इसमें कॉम्प्रोमाइज़्ड स्विच, आपके मैनेजमेंट VLAN पर रोग (rogue) डिवाइस, या रिमोट एक्सेस पॉइंट और क्लाउड-होस्टेड RADIUS सर्वर के बीच का कोई भी बिंदु शामिल है — वे संभावित रूप से ऑथेंटिकेशन एक्सचेंजों को कैप्चर कर सकते हैं, शेयर्ड सीक्रेट के विरुद्ध ऑफ़लाइन डिक्शनरी हमलों का प्रयास कर सकते हैं, और कुछ कॉन्फ़िगरेशन में, यूज़र क्रेडेंशियल्स को पूरी तरह से उजागर कर सकते हैं。 200 संपत्तियों में गेस्ट WiFi चलाने वाले होटल समूह के लिए, या सार्वजनिक इंटरनेट पर एक केंद्रीय RADIUS सर्वर पर बैकहॉल करने वाले प्रत्येक स्टोर में एक्सेस पॉइंट वाली रिटेल चेन के लिए, यह कोई सैद्धांतिक जोखिम नहीं है। यह एक लाइव अटैक सरफेस है。 RadSec बिल्कुल यही हल करता है। RadSec — जिसे RFC 6614 में परिभाषित किया गया है और RFC 7360 द्वारा अपडेट किया गया है — RADIUS ट्रैफ़िक को TLS टनल के अंदर रैप करता है। UDP के बजाय, यह पोर्ट 2083 पर TCP का उपयोग करता है। शेयर्ड सीक्रेट और MD5 के बजाय, यह X.509 सर्टिफ़िकेट के साथ म्यूचुअल TLS ऑथेंटिकेशन का उपयोग करता है। RADIUS क्लाइंट और RADIUS सर्वर दोनों सर्टिफ़िकेट प्रस्तुत करते हैं, एक-दूसरे की पहचान सत्यापित करते हैं, और किसी भी ऑथेंटिकेशन डेटा का आदान-प्रदान होने से पहले एक एन्क्रिप्टेड सेशन स्थापित करते हैं। TLS 1.3 वर्तमान अनुशंसित संस्करण है, जो फॉरवर्ड सीक्रेसी प्रदान करता है और कई लेगेसी सिफर कमज़ोरियों को समाप्त करता है。 इसका व्यावहारिक प्रभाव महत्वपूर्ण है। क्रेडेंशियल डेटा, यूज़र एट्रिब्यूट्स और सेशन टोकन एक्सेस पॉइंट — या RadSec प्रॉक्सी — और RADIUS सर्वर के बीच एंड-टू-एंड एन्क्रिप्टेड होते हैं। वायर पर ट्रैफ़िक को इंटरसेप्ट करने वाले हमलावर को केवल एन्क्रिप्टेड TLS रिकॉर्ड दिखाई देते हैं। शेयर्ड सीक्रेट अभी भी बैकवर्ड कम्पैटिबिलिटी के लिए मौजूद है, लेकिन यह अब कोई सार्थक सुरक्षा कार्य नहीं कर रहा है — TLS भार वहन कर रहा है。 यहाँ एक और आयाम है जो तेज़ी से प्रासंगिक हो रहा है: रोमिंग। पूरे यूरोप और उसके बाहर विश्वविद्यालयों और शोध संस्थानों द्वारा उपयोग किया जाने वाला Eduroam फ़ेडरेशन, अपने अंतर-संस्थागत रोमिंग इंफ्रास्ट्रक्चर के हिस्से के रूप में वर्षों से RadSec चला रहा है। हाल ही में, Wi-Fi Alliance का OpenRoaming मानक — जो भाग लेने वाले वेन्यू में निर्बाध WiFi रोमिंग को सक्षम बनाता है — सभी फ़ेडरेशन ट्रैफ़िक के लिए RadSec को अनिवार्य करता है। यदि आप OpenRoaming-सक्षम इंफ्रास्ट्रक्चर डिप्लॉय कर रहे हैं, तो RadSec वैकल्पिक नहीं है; यह एक पूर्वापेक्षा है। Purple अपने कनेक्ट (Connect) लाइसेंस के तहत OpenRoaming का समर्थन करता है, जो फ़ेडरेशन के भीतर एक आइडेंटिटी प्रोवाइडर के रूप में कार्य करता है, और RadSec उस सुरक्षित रोमिंग फैब्रिक के संचालन के केंद्र में है。 अनुपालन के दृष्टिकोण से, RadSec PCI DSS 4.0 के लिए तेज़ी से प्रासंगिक है, जो ट्रांज़िट में ऑथेंटिकेशन डेटा की सुरक्षा के आसपास की आवश्यकताओं को कड़ा करता है। यदि आपका WiFi इंफ्रास्ट्रक्चर पेमेंट कार्ड वातावरण को छूता है — और रिटेल और हॉस्पिटैलिटी में, यह अक्सर होता है — तो पारंपरिक RADIUS में एन्क्रिप्शन गैप एक ऐसी खामी है जो कभी भी सामने आ सकती है। GDPR को भी व्यक्तिगत डेटा की सुरक्षा के लिए उचित तकनीकी उपायों की आवश्यकता होती है; आपके नेटवर्क पर अनएन्क्रिप्टेड रूप से बहने वाले यूज़र क्रेडेंशियल्स और सेशन मेटाडेटा का डेटा सुरक्षा ऑडिट में बचाव करना कठिन है。 अब आर्किटेक्चर के बारे में बात करते हैं। RadSec के लिए दो प्राथमिक डिप्लॉयमेंट पैटर्न हैं。 पहला आपके RADIUS सर्वर और एक्सेस पॉइंट पर नेटिव RadSec सपोर्ट है। FreeRADIUS 3.0 और इसके बाद के संस्करण नेटिव रूप से RadSec का समर्थन करते हैं। वर्तमान रिलीज़ के अनुसार Microsoft NPS नेटिव रूप से RadSec का समर्थन नहीं करता है, जो Windows-केंद्रित इंफ्रास्ट्रक्चर चलाने वाले संगठनों के लिए एक महत्वपूर्ण बाधा है। Cisco ISE RadSec का समर्थन करता है। Aruba ClearPass RadSec का समर्थन करता है। यदि आपका RADIUS सर्वर और आपका एक्सेस पॉइंट वेंडर दोनों नेटिव रूप से RadSec का समर्थन करते हैं, तो यह सबसे साफ़ रास्ता है — दोनों सिरों पर TLS सर्टिफ़िकेट कॉन्फ़िगर करें, अपने फ़ायरवॉल पर TCP 2083 खोलें, और आप RADIUS ट्रैफ़िक को एंड-टू-एंड एन्क्रिप्ट कर रहे हैं。 दूसरा पैटर्न RadSec प्रॉक्सी है। व्यवहार में यह अधिक सामान्य डिप्लॉयमेंट है, विशेष रूप से लेगेसी RADIUS इंफ्रास्ट्रक्चर या मिक्स्ड-वेंडर वातावरण वाले संगठनों के लिए। एक RadSec प्रॉक्सी — radsecproxy सबसे व्यापक रूप से डिप्लॉय किया गया ओपन-सोर्स इम्प्लीमेंटेशन है — आपके एक्सेस पॉइंट और आपके RADIUS सर्वर के बीच बैठता है। एक्सेस पॉइंट लोकल नेटवर्क पर प्रॉक्सी को UDP पर मानक RADIUS भेजते हैं। प्रॉक्सी उस कनेक्शन को समाप्त करता है, RADIUS ट्रैफ़िक को TLS टनल के अंदर फिर से एनकैप्सुलेट करता है, और इसे TCP 2083 पर अपस्ट्रीम RADIUS सर्वर पर फॉरवर्ड करता है। यह दृष्टिकोण आपको अपने RADIUS सर्वर को बदले बिना मौजूदा इंफ्रास्ट्रक्चर में RadSec जोड़ने देता है, और यह विशेष रूप से तब उपयोगी होता है जब आपका RADIUS सर्वर क्लाउड में होस्ट किया गया हो या सार्वजनिक इंटरनेट पर एक्सेस किया गया हो。 सर्टिफ़िकेट मैनेजमेंट वह ऑपरेशनल जटिलता है जिसके लिए आपको योजना बनाने की आवश्यकता है। म्यूचुअल TLS के लिए उपयोग किए जाने वाले X.509 सर्टिफ़िकेट जारी करने और प्रबंधित करने के लिए आपको एक PKI — पब्लिक की इंफ्रास्ट्रक्चर — की आवश्यकता होगी। इसका मतलब है एक सर्टिफ़िकेट अथॉरिटी, प्रत्येक RADIUS क्लाइंट और सर्वर के लिए सर्टिफ़िकेट जारी करना, और एक्सपायरी से पहले सर्टिफ़िकेट रोटेशन की प्रक्रिया। बिना ध्यान दिए एक्सपायर होने वाले सर्टिफ़िकेट आपके नेटवर्क पर हर यूज़र के लिए एक साथ ऑथेंटिकेशन को तोड़ देंगे — और यह एक ऐसा परिदृश्य है जिससे आप बचना चाहते हैं। ACME या अपने CA के API का उपयोग करके सर्टिफ़िकेट रिन्यूअल को स्वचालित करें, और एक्सपायरी डेट से काफ़ी पहले मॉनिटरिंग अलर्ट सेट करें。 --- [इम्प्लीमेंटेशन सिफ़ारिशें और कमियाँ — लगभग 2 मिनट] मैं आपको व्यावहारिक सिफ़ारिशें देता हूँ。 पहला: डिप्लॉय करने से पहले ऑडिट करें। अपने वातावरण में प्रत्येक RADIUS क्लाइंट — एक्सेस पॉइंट, VPN कंसंट्रेटर, 802.1X करने वाले स्विच — और प्रत्येक RADIUS सर्वर को मैप करें। समझें कि कौन से नेटिव रूप से RadSec का समर्थन करते हैं और किसके लिए प्रॉक्सी की आवश्यकता होगी। यह ऑडिट आमतौर पर उन लेगेसी डिवाइस को सामने लाता है जो TLS का बिल्कुल भी समर्थन नहीं करते हैं, और उन्हें आपके रिप्लेसमेंट रोडमैप पर होना चाहिए。 दूसरा: सबसे अधिक जोखिम वाले ट्रैफ़िक से शुरू करें। यदि आपके पास सार्वजनिक इंटरनेट को पार करने वाला RADIUS ट्रैफ़िक है — रिमोट साइट्स, क्लाउड-होस्टेड RADIUS, मल्टी-प्रॉपर्टी होटल समूह — तो यह आपकी पहली प्राथमिकता है। अच्छी तरह से सेगमेंट किए गए मैनेजमेंट VLAN पर लोकल RADIUS ट्रैफ़िक कम जोखिम वाला है, लेकिन इसे अभी भी रोडमैप पर होना चाहिए。 तीसरा: गो-लाइव से पहले म्यूचुअल TLS का अच्छी तरह से परीक्षण करें। RadSec डिप्लॉयमेंट में सबसे आम विफलता मोड सर्टिफ़िकेट वैलिडेशन त्रुटियाँ हैं — बेमेल कॉमन नेम, एक्सपायर हो चुके इंटरमीडिएट सर्टिफ़िकेट, या ऐसे क्लाइंट जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने वाले CA पर भरोसा नहीं करते हैं। प्रोडक्शन ट्रैफ़िक को कट ओवर करने से पहले TLS हैंडशेक का परीक्षण करने के लिए openssl s_client का उपयोग करें。 चौथा: मॉनिटरिंग की उपेक्षा न करें। RadSec एक TCP कनेक्शन लेयर जोड़ता है जो पारंपरिक RADIUS में नहीं है। TCP कनेक्शन विफलताएँ, TLS हैंडशेक टाइमआउट और सर्टिफ़िकेट त्रुटियाँ आपके यूज़र्स के लिए ऑथेंटिकेशन विफलताओं के रूप में प्रकट होंगी। सुनिश्चित करें कि आपके RADIUS सर्वर लॉग और आपके प्रॉक्सी लॉग आपके SIEM या मॉनिटरिंग प्लेटफ़ॉर्म में फ़ीड कर रहे हैं ताकि आप ऑथेंटिकेशन पॉलिसी समस्या से RadSec कनेक्टिविटी समस्या को अलग कर सकें。 मैं जो कमी सबसे अधिक देखता हूँ वह है संगठनों द्वारा सर्वर साइड पर RadSec डिप्लॉय करना लेकिन अपने फ़ायरवॉल नियमों को अपडेट करना भूल जाना। प्रत्येक RADIUS क्लाइंट और RADIUS सर्वर या प्रॉक्सी के बीच TCP 2083 खुला होना चाहिए। यदि आप UDP 1812 नियमों को प्रबंधित करने के अभ्यस्त हैं, तो फ़ायरवॉल परिवर्तन प्रक्रिया में TCP 2083 छूट सकता है。 --- [रैपिड-फ़ायर Q&A — लगभग 1 मिनट] मैं कुछ ऐसे प्रश्नों पर नज़र डालता हूँ जो मैं नियमित रूप से सुनता हूँ。 "क्या RadSec 802.1X को प्रतिस्थापित करता है?" नहीं। RadSec एक्सेस पॉइंट और RADIUS सर्वर के बीच ट्रांसपोर्ट लेयर को सुरक्षित करता है। 802.1X क्लाइंट डिवाइस और एक्सेस पॉइंट के बीच ऑथेंटिकेशन फ्रेमवर्क है। वे अलग-अलग लेयर्स पर काम करते हैं और पूरक हैं。 "क्या RadSec सभी एक्सेस पॉइंट वेंडर्स पर समर्थित है?" सार्वभौमिक रूप से नहीं। Cisco, Aruba, Ruckus और Meraki सभी में RadSec सपोर्ट के अलग-अलग स्तर हैं — अपना विशिष्ट फ़र्मवेयर संस्करण जाँचें। जहाँ नेटिव सपोर्ट अनुपस्थित है, वहाँ RadSec प्रॉक्सी आपका समाधान है。 "DTLS के बारे में क्या — RADIUS over DTLS?" RFC 7360 RADIUS over DTLS को परिभाषित करता है, जो TCP के बजाय UDP का उपयोग करता है, एन्क्रिप्शन जोड़ते हुए पारंपरिक RADIUS की कुछ कनेक्शनलेस विशेषताओं को संरक्षित करता है। यह TLS पर RadSec की तुलना में कम व्यापक रूप से डिप्लॉय किया गया है, लेकिन यदि हाई-थ्रूपुट वातावरण में लेटेंसी एक चिंता का विषय है तो इसका मूल्यांकन करना उचित है。 "यह रोमिंग प्रदर्शन को कैसे प्रभावित करता है?" RadSec का TCP कनेक्शन पर्सिस्टेंट है, जो वास्तव में बाद के ऑथेंटिकेशन अनुरोधों के लिए कनेक्शन सेटअप ओवरहेड को कम करके फ़ेडरेटेड वातावरण में रोमिंग प्रदर्शन में सुधार कर सकता है。 --- [सारांश और अगले कदम — लगभग 1 मिनट] समापन के लिए: RadSec पारंपरिक RADIUS में एक वास्तविक सुरक्षा अंतर का परिपक्व, मानक-आधारित उत्तर है। यदि आप बड़े पैमाने पर एंटरप्राइज़ WiFi चला रहे हैं — कई साइटों पर, इंटरनेट पर, या PCI DSS या GDPR के अधीन वातावरण में — तो सवाल यह नहीं है कि RadSec को डिप्लॉय किया जाए या नहीं, बल्कि यह है कि कब और कैसे。 आपके अगले कदम: इस सप्ताह अपने RADIUS इंफ्रास्ट्रक्चर का ऑडिट करें। अपने सबसे अधिक जोखिम वाले ट्रैफ़िक प्रवाह की पहचान करें। नेटिव RadSec सपोर्ट के लिए अपने RADIUS सर्वर और एक्सेस पॉइंट वेंडर दस्तावेज़ों की जाँच करें। यदि आप FreeRADIUS चला रहे हैं, तो आप एक दिन में एक टेस्ट RadSec डिप्लॉयमेंट चला सकते हैं। यदि आप Microsoft NPS पर हैं, तो प्रॉक्सी या RadSec-सक्षम सर्वर के माइग्रेशन पथ का मूल्यांकन करना शुरू करें。 Purple का प्लेटफ़ॉर्म एंटरप्राइज़ RADIUS इंफ्रास्ट्रक्चर के साथ इंटीग्रेट करने के लिए डिज़ाइन किया गया है, जो कॉर्पोरेट और गेस्ट WiFi दोनों वातावरणों के लिए सुरक्षित ऑथेंटिकेशन प्रवाह का समर्थन करता है। यदि आप समझना चाहते हैं कि RadSec आपके विशिष्ट डिप्लॉयमेंट में कैसे फिट बैठता है, तो Purple टीम आपको इसके बारे में बता सकती है。 सुनने के लिए धन्यवाद। अगली बार तक के लिए。 --- स्क्रिप्ट का अंत