RadSec: TLS पर RADIUS किस प्रकार WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है

RadSec: TLS पर RADIUS किस प्रकार 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 पर नकली उपकरण, या रिमोट एक्सेस पॉइंट और क्लाउड-होस्टेड 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 छूट सकता है। --- [रैपिड-फायर प्रश्नोत्तर — लगभग 1 मिनट] आइए मैं कुछ ऐसे सवालों पर नज़र डालूँ जो मैं नियमित रूप से सुनता हूँ। "क्या RadSec 802.1X को प्रतिस्थापित करता है?" नहीं। RadSec एक्सेस पॉइंट और RADIUS सर्वर के बीच ट्रांसपोर्ट लेयर को सुरक्षित करता है। 802.1X क्लाइंट डिवाइस और एक्सेस पॉइंट के बीच ऑथेंटिकेशन फ्रेमवर्क है। वे विभिन्न परतों पर काम करते हैं और एक-दूसरे के पूरक हैं। "क्या सभी एक्सेस पॉइंट विक्रेताओं पर RadSec समर्थित है?" सार्वभौमिक रूप से नहीं। Cisco, Aruba, Ruckus, और Meraki सभी के पास RadSec समर्थन के विभिन्न स्तर हैं — अपने विशिष्ट फर्मवेयर संस्करण की जांच करें। जहाँ नेटिव सपोर्ट अनुपस्थित है, वहाँ RadSec प्रॉक्सी आपका समाधान है। "DTLS — DTLS पर RADIUS के बारे में क्या?" RFC 7360 DTLS पर RADIUS को परिभाषित करता है, जो 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 टीम आपको इसके बारे में विस्तार से बता सकती है। सुनने के लिए धन्यवाद। अगली बार तक। --- स्क्रिप्ट का अंत