RadSec: RADIUS over TLS मुळे WiFi ऑथेंटिकेशन सुरक्षा कशी सुधारते

RadSec: RADIUS over TLS मुळे WiFi ऑथेंटिकेशन सुरक्षा कशी सुधारते एक Purple एंटरप्राइझ WiFi इंटेलिजन्स ब्रिफिंग अंदाजे वेळ: १० मिनिटे --- [परिचय आणि संदर्भ — अंदाजे १ मिनिट] Purple एंटरप्राइझ WiFi इंटेलिजन्स सिरीजमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण नेटवर्क सुरक्षा आणि ऑपरेशनल जोखीम यांच्या अगदी मध्यभागी असलेल्या विषयावर चर्चा करत आहोत: RadSec — औपचारिकपणे RFC 6614 मध्ये परिभाषित केलेले — आणि जर ते तुमच्या इन्फ्रास्ट्रक्चर रोडमॅपवर नसेल, तर ते का असावे. जर तुम्ही हॉटेल ग्रुप, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील कॅम्पसमध्ये एंटरप्राइझ WiFi साठी जबाबदार असलेले IT मॅनेजर, नेटवर्क आर्किटेक्ट किंवा CTO असाल, तर हे ब्रिफिंग तुमच्यासाठी आहे. आम्ही RadSec प्रत्यक्षात काय आहे, पारंपारिक RADIUS प्रोटोकॉल तुम्हाला कसा असुरक्षित ठेवतो, वास्तविक वातावरणात RadSec कसे तैनात करावे आणि टीम्स ज्या चुका करतात त्या कव्हर करणार आहोत. केवळ सिद्धांतासाठी सिद्धांत नाही — तर या तिमाहीत निर्णय घेण्यासाठी तुम्हाला आवश्यक असलेली माहिती. चला तर मग, सुरू करूया. --- [तांत्रिक सखोल विश्लेषण — अंदाजे ५ मिनिटे] तर, समस्येपासून सुरुवात करूया. RADIUS — रिमोट ऑथेंटिकेशन डायल-इन युझर सर्व्हिस — १९९० च्या दशकापासून एंटरप्राइझ WiFi ऑथेंटिकेशनचा कणा राहिली आहे. जेव्हा एखादा युझर किंवा डिव्हाइस तुमच्या कॉर्पोरेट किंवा गेस्ट WiFi शी कनेक्ट होते, तेव्हा ॲक्सेस पॉइंट RADIUS क्लायंट म्हणून काम करतो, ऑथेंटिकेशन विनंत्या RADIUS सर्व्हरकडे फॉरवर्ड करतो, जो तुमच्या डिरेक्टरीच्या — Active Directory, LDAP किंवा क्लाउड आयडेंटिटी प्रोव्हाइडरच्या — विरूद्ध क्रेडेंशियल्स व्हॅलिडेट करतो आणि एकतर प्रवेश देतो किंवा नाकारतो. हे 802.1X ऑथेंटिकेशन मॉडेल आहे जे WPA2-Enterprise आणि WPA3-Enterprise नेटवर्कला आधार देते. समस्या अशी आहे की पारंपारिक RADIUS एका वेगळ्या युगासाठी डिझाइन केले गेले होते. हे पोर्ट्स 1812 आणि 1813 वर UDP — युझर डेटाग्राम प्रोटोकॉल — वर चालते. UDP हे कनेक्शनलेस आहे, ज्याचा अर्थ असा आहे की कोणताही हँडशेक नाही, सेशन स्टेट नाही आणि सर्वात महत्त्वाचे म्हणजे, कोणतेही नेटिव्ह एन्क्रिप्शन नाही. तुमच्या ॲक्सेस पॉइंट आणि तुमच्या RADIUS सर्व्हरमधील एकमेव संरक्षण म्हणजे एक शेअर्ड सिक्रेट — मूलतः एक पासवर्ड — जो MD5 हॅशिंगचा वापर करून ट्रान्झिटमध्ये युझरचा पासवर्ड अस्पष्ट करण्यासाठी वापरला जातो. MD5, तुमच्यापैकी बहुतेकांना माहीत असेलच की, क्रिप्टोग्राफिकदृष्ट्या निरुपयोगी झाले आहे. ते वर्षानुवर्षे कमकुवत राहिले आहे. व्यावहारिक भाषेत याचा अर्थ काय आहे? याचा अर्थ असा आहे की कोणत्याही नेटवर्क सेगमेंटवर जिथे एखादा हल्लेखोर RADIUS ट्रॅफिक इंटरसेप्ट करू शकतो — आणि यामध्ये तडजोड केलेले स्विचेस, तुमच्या व्यवस्थापन VLAN वरील अनधिकृत डिव्हाइसेस किंवा रिमोट ॲक्सेस पॉइंट आणि क्लाउड-होस्ट केलेल्या RADIUS सर्व्हरमधील कोणताही पॉइंट समाविष्ट आहे — ते ऑथेंटिकेशन एक्सचेंज कॅप्चर करू शकतात, शेअर्ड सिक्रेटच्या विरूद्ध ऑफलाइन डिक्शनरी हल्ल्यांचा प्रयत्न करू शकतात आणि काही कॉन्फिगरेशनमध्ये, युझर क्रेडेंशियल्स पूर्णपणे उघड करू शकतात. २०० प्रॉपर्टीजमध्ये गेस्ट 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 हे त्या सुरक्षित रोमिंग फॅब्रिकच्या कार्यपद्धतीसाठी केंद्रस्थानी आहे. अनुपालनाच्या (compliance) दृष्टिकोनातून, RadSec हे PCI DSS 4.0 साठी वाढत्या प्रमाणात संबंधित आहे, जे ट्रान्झिटमधील ऑथेंटिकेशन डेटाच्या संरक्षणाभोवतीच्या आवश्यकता कडक करते. जर तुमचे WiFi इन्फ्रास्ट्रक्चर पेमेंट कार्ड वातावरणाला स्पर्श करत असेल — आणि रिटेल आणि हॉस्पिटॅलिटीमध्ये ते वारंवार करते — तर पारंपारिक RADIUS मधील एन्क्रिप्शनची कमतरता ही एक मोठी त्रुटी ठरू शकते. GDPR ला देखील वैयक्तिक डेटा सुरक्षित ठेवण्यासाठी योग्य तांत्रिक उपायांची आवश्यकता असते; तुमच्या नेटवर्कवर अनएन्क्रिप्टेड वाहणारे युझर क्रेडेंशियल्स आणि सेशन मेटाडेटा डेटा प्रोटेक्शन ऑडिटमध्ये सुरक्षित ठेवणे कठीण आहे. आता आर्किटेक्चरबद्दल बोलूया. RadSec साठी दोन मुख्य डिप्लॉयमेंट पॅटर्न आहेत. पहिला म्हणजे तुमच्या RADIUS सर्व्हर आणि ॲक्सेस पॉइंट्सवर नेटिव्ह RadSec सपोर्ट. FreeRADIUS 3.0 आणि त्यावरील आवृत्त्या RadSec ला नेटिव्हली सपोर्ट करतात. Microsoft NPS सध्याच्या रिलीजमध्ये RadSec ला नेटिव्हली सपोर्ट करत नाही, जी विंडोज-केंद्रित इन्फ्रास्ट्रक्चर चालवणाऱ्या संस्थांसाठी एक मोठी मर्यादा आहे. 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 चा वापर करून स्वयंचलित सर्टिफिकेट नूतनीकरण करा आणि कालबाह्यतेच्या तारखेच्या बरेच आधी मॉनिटरिंग अलर्ट सेट करा. --- [इम्प्लीमेंटेशन शिफारसी आणि त्रुटी — अंदाजे २ मिनिटे] मी तुम्हाला व्यावहारिक शिफारसी देतो. पहिले: तैनात करण्यापूर्वी ऑडिट करा. तुमच्या वातावरणातील प्रत्येक 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 सुटू शकते. --- [रॅपिड-फायर प्रश्नोत्तरे — अंदाजे १ मिनिट] मला नियमितपणे ऐकू येणाऱ्या काही प्रश्नांचा आढावा घेऊया. "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 कनेक्शन पर्सिस्टंट (सतत) असते, जे पुढील ऑथेंटिकेशन विनंत्यांसाठी कनेक्शन सेटअप ओव्हरहेड कमी करून फेडरेटेड वातावरणात रोमिंग परफॉर्मन्स प्रत्यक्षात सुधारू शकते. --- [सारांश आणि पुढील पावले — अंदाजे १ मिनिट] थोडक्यात सांगायचे तर: पारंपारिक RADIUS मधील वास्तविक सुरक्षा त्रुटीवर RadSec हे परिपक्व, मानकांवर आधारित उत्तर आहे. जर तुम्ही मोठ्या प्रमाणावर एंटरप्राइझ WiFi चालवत असाल — अनेक साइट्सवर, इंटरनेटवर किंवा PCI DSS किंवा GDPR च्या अधीन असलेल्या वातावरणात — तर प्रश्न RadSec तैनात करायचा की नाही हा नाही, तर तो कधी आणि कसा करायचा हा आहे. तुमची पुढील पावले: या आठवड्यात तुमच्या RADIUS इन्फ्रास्ट्रक्चरचे ऑडिट करा. तुमच्या सर्वात जास्त जोखीम असलेल्या ट्रॅफिक फ्लोची ओळख पटवा. नेटिव्ह RadSec सपोर्टसाठी censure तुमचे RADIUS सर्व्हर आणि ॲक्सेस पॉइंट व्हेंडरचे दस्तऐवज तपासा. जर तुम्ही FreeRADIUS चालवत असाल, तर तुम्ही एका दिवसात चाचणी RadSec डिप्लॉयमेंट सुरू करू शकता. जर तुम्ही Microsoft NPS वर असाल, तर प्रॉक्सी किंवा RadSec-सक्षम सर्व्हरवर स्थलांतरित होण्याच्या मार्गाचे मूल्यांकन करणे सुरू करा. Purple चे प्लॅटफॉर्म एंटरप्राइझ RADIUS इन्फ्रास्ट्रक्चरसह इंटिग्रेट करण्यासाठी डिझाइन केले आहे, जे कॉर्पोरेट आणि गेस्ट WiFi दोन्ही वातावरणासाठी सुरक्षित ऑथेंटिकेशन फ्लोला सपोर्ट करते. जर तुम्हाला तुमच्या विशिष्ट डिप्लॉयमेंटमध्ये RadSec कसे बसते हे समजून घ्यायचे असेल, तर Purple टीम तुम्हाला यामध्ये मदत करू शकते. ऐकल्याबद्दल धन्यवाद. पुन्हा भेटू. --- END OF SCRIPT