RadSec: TLS वरील RADIUS मुळे WiFi प्रमाणीकरण सुरक्षा कशी सुधारते

RadSec: TLS वरील RADIUS मुळे WiFi प्रमाणीकरण सुरक्षा कशी सुधारते एक Purple एंटरप्राइझ WiFi इंटेलिजन्स ब्रीफिंग अंदाजे रनटाइम: 10 मिनिटे --- [परिचय आणि संदर्भ — अंदाजे 1 मिनिट] Purple एंटरप्राइझ WiFi इंटेलिजन्स सिरीजमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण अशा एका विषयावर चर्चा करत आहोत जो नेटवर्क सुरक्षा आणि ऑपरेशनल जोखमीच्या अगदी छेदनबिंदूवर आहे: RadSec — औपचारिकरित्या RFC 6614 मध्ये परिभाषित केलेले — आणि जर ते आधीपासून नसेल तर ते तुमच्या इन्फ्रास्ट्रक्चर रोडमॅपवर का असले पाहिजे. जर तुम्ही हॉटेल ग्रुप, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील कॅम्पसमध्ये एंटरप्राइझ WiFi साठी जबाबदार असलेले IT व्यवस्थापक, नेटवर्क आर्किटेक्ट किंवा CTO असाल, तर हे ब्रीफिंग तुमच्यासाठी आहे. आम्ही RadSec प्रत्यक्षात काय आहे, पारंपारिक RADIUS प्रोटोकॉल तुम्हाला असुरक्षित का ठेवतो, वास्तविक-जगातील वातावरणात RadSec कसे डिप्लॉय करावे आणि टीम्सना अडकवणाऱ्या त्रुटी कव्हर करणार आहोत. केवळ सिद्धांतासाठी सिद्धांत नाही — तर या तिमाहीत निर्णय घेण्यासाठी तुम्हाला आवश्यक असलेली माहिती. चला तर मग सुरुवात करूया. --- [तांत्रिक सखोल माहिती — अंदाजे 5 मिनिटे] तर, समस्येपासून सुरुवात करूया. RADIUS — रिमोट ऑथेंटिकेशन डायल-इन युझर सर्व्हिस — 1990 च्या दशकापासून एंटरप्राइझ WiFi प्रमाणीकरणाचा कणा आहे. जेव्हा एखादा युझर किंवा डिव्हाइस तुमच्या कॉर्पोरेट किंवा अतिथी WiFi शी कनेक्ट होतो, तेव्हा अ‍ॅक्सेस पॉईंट RADIUS क्लायंट म्हणून काम करतो, प्रमाणीकरण विनंत्या RADIUS सर्व्हरकडे फॉरवर्ड करतो, जो तुमच्या डिरेक्टरीच्या विरूद्ध क्रेडेन्शियल्स प्रमाणित करतो — Active Directory, LDAP, किंवा क्लाउड आयडेंटिटी प्रोव्हायडर — आणि एकतर अ‍ॅक्सेस देतो किंवा नाकारतो. हे 802.1X प्रमाणीकरण मॉडेल आहे जे WPA2-Enterprise आणि WPA3-Enterprise नेटवर्क्सला आधार देते. समस्या अशी आहे की पारंपारिक RADIUS एका वेगळ्या युगासाठी डिझाइन केले गेले होते. ते UDP — युझर डेटाग्राम प्रोटोकॉल — वर पोर्ट्स 1812 आणि 1813 वर चालते. 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 अलायन्सचे OpenRoaming स्टँडर्ड — जे सहभागी ठिकाणांवर अखंड WiFi रोमिंग सक्षम करते — सर्व फेडरेशन ट्रॅफिकसाठी RadSec अनिवार्य करते. जर तुम्ही OpenRoaming-सक्षम पायाभूत सुविधा डिप्लॉय करत असाल, तर RadSec ऐच्छिक नाही; ती एक पूर्वअट आहे. Purple त्याच्या कनेक्ट लायसन्स अंतर्गत 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 पाठवतात. प्रॉक्सी ते कनेक्शन संपुष्टात आणते, TLS टनेलमध्ये RADIUS ट्रॅफिक पुन्हा एन्कॅप्स्युलेट करते आणि 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 मिनिट] शेवटी: पारंपारिक RADIUS मधील खऱ्या सुरक्षा त्रुटीसाठी RadSec हे परिपक्व, मानकांवर आधारित उत्तर आहे. जर तुम्ही मोठ्या प्रमाणावर एंटरप्राइझ WiFi चालवत असाल — एकाधिक साइट्सवर, इंटरनेटवर किंवा PCI DSS किंवा GDPR च्या अधीन असलेल्या वातावरणात — तर प्रश्न RadSec डिप्लॉय करायचे की नाही हा नाही, तर कधी आणि कसे हा आहे. तुमच्या पुढील पायऱ्या: या आठवड्यात तुमच्या RADIUS पायाभूत सुविधांचे ऑडिट करा. तुमचे सर्वाधिक-जोखमीचे ट्रॅफिक फ्लो ओळखा. नेटिव्ह RadSec सपोर्टसाठी तुमचे RADIUS सर्व्हर आणि अ‍ॅक्सेस पॉईंट व्हेंडर डॉक्युमेंटेशन तपासा. जर तुम्ही FreeRADIUS चालवत असाल, तर तुम्ही एका दिवसात टेस्ट RadSec डिप्लॉयमेंट चालू करू शकता. जर तुम्ही Microsoft NPS वर असाल, तर प्रॉक्सी किंवा RadSec-सक्षम सर्व्हरकडे मायग्रेशन मार्गाचे मूल्यांकन सुरू करा. Purple चे प्लॅटफॉर्म एंटरप्राइझ RADIUS पायाभूत सुविधांशी इंटिग्रेट करण्यासाठी डिझाइन केलेले आहे, जे कॉर्पोरेट आणि अतिथी WiFi दोन्ही वातावरणांसाठी सुरक्षित प्रमाणीकरण फ्लोला सपोर्ट करते. जर तुम्हाला समजून घ्यायचे असेल की RadSec तुमच्या विशिष्ट डिप्लॉयमेंटमध्ये कसे बसते, तर Purple टीम तुम्हाला त्यातून मार्गदर्शन करू शकते. ऐकल्याबद्दल धन्यवाद. पुढच्या वेळेपर्यंत. --- स्क्रिप्टचा शेवट