मुख्य मजकुराकडे जा
मराठी

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

हा अधिकृत तांत्रिक संदर्भ पारंपारिक RADIUS ट्रॅफिकला TLS एन्क्रिप्शनमध्ये वेढून RadSec (RFC 6614) एंटरप्राइझ WiFi ऑथेंटिकेशन कसे सुरक्षित करते हे स्पष्ट करतो. IT मॅनेजर्स आणि नेटवर्क आर्किटेक्ट्ससाठी डिझाइन केलेल्या या संदर्भामध्ये आर्किटेक्चर, डिप्लोयमेंट स्ट्रॅटेजीज आणि कॉर्पोरेट आणि गेस्ट नेटवर्क्सवरील अनएन्क्रिप्टेड UDP RADIUS ट्रॅफिकच्या जोखमी कमी करण्यासाठी व्यावहारिक पायऱ्यांचा समावेश आहे.

Iain Jewitt द्वारेप्रकाशित अद्ययावत केले
📖 4 मिनिट वाचन831 शब्द2 सोडवलेली उदाहरणे3 सराव प्रश्न8 महत्वाच्या व्याख्या

Video overview

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा
RadSec: RADIUS over TLS मुळे WiFi ऑथेंटिकेशन सुरक्षा कशी सुधारते Purple Enterprise WiFi इंटेलिजन्स ब्रीफिंग अंदाजे वेळ: 10 मिनिटे --- [प्रस्तावना आणि संदर्भ - अंदाजे 1 मिनिट] Purple Enterprise WiFi इंटेलिजन्स मालिकेत आपले स्वागत आहे. मी तुमचा होस्ट आहे आणि आज आपण एका अशा विषयावर चर्चा करत आहोत जो थेट नेटवर्क सुरक्षा आणि ऑपरेशनल रिस्कच्या केंद्रस्थानी आहे: RadSec - औपचारिकपणे RFC 6614 मध्ये परिभाषित - आणि जर हा तुमच्या इन्फ्रास्ट्रक्चर रोडमॅपवर अद्याप नसेल, तर तो का असायला हवा. जर तुम्ही हॉटेल ग्रुप, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील कॅम्पसमध्ये एंटरप्राइझ WiFi साठी जबाबदार असलेले IT मॅनेजर, नेटवर्क आर्किटेक्ट किंवा CTO असाल, तर हे ब्रीफिंग तुमच्यासाठी आहे. RadSec नेमके काय आहे, पारंपारिक RADIUS प्रोटोकॉल तुम्हाला कसा उघडा पाडतो, वास्तविक जगात RadSec कसे तैनात करावे आणि टीम्स ज्या चुका करतात त्या आपण कव्हर करणार आहोत. केवळ सिद्धांतासाठी सिद्धांत नाही - या तिमाहीत निर्णय घेण्यासाठी तुम्हाला आवश्यक असलेली माहिती आम्ही देणार आहोत. चला तर मग, सुरुवात करूया. --- [तांत्रिक सखोल विश्लेषण - अंदाजे 5 मिनिटे] तर, समस्येपासून सुरुवात करूया. RADIUS - Remote Authentication Dial-In User Service - हे 1990 च्या दशकापासून एंटरप्राइझ WiFi ऑथेंटिकेशनचा कणा राहिले आहे. जेव्हा एखादा युझर किंवा डिव्हाइस तुमच्या कॉर्पोरेट किंवा गेस्ट WiFi ला कनेक्ट होते, तेव्हा ॲक्सेस पॉइंट एक RADIUS क्लायंट म्हणून काम करतो, ऑथेंटिकेशन विनंत्या RADIUS सर्व्हरकडे फॉरवर्ड करतो, जो तुमच्या डिरेक्टरी - Active Directory, LDAP किंवा क्लाउड आयडेंटिटी प्रोव्हाइडर - नुसार क्रेडेंशियल्स सत्यापित करतो आणि प्रवेश मंजूर किंवा नाकारतो. हे 802.1X ऑथेंटिकेशन मॉडेल आहे जे WPA2 आणि WPA3 एंटरप्राइझ नेटवर्कला आधार देते. अडचण अशी आहे की पारंपारिक RADIUS एका वेगळ्या युगासाठी डिझाइन केले गेले होते. हे UDP वर - User Datagram Protocol - पोर्ट्स 1812 आणि 1813 वर चालते. UDP हे कनेक्शन नसलेले आहे, ज्याचा अर्थ असा आहे की यात कोणताही हँडशेक नाही, कोणतेही सेशन स्टेट नाही आणि सर्वात महत्त्वाचे म्हणजे, कोणतेही मूळ एन्क्रिप्शन नाही. तुमच्या ॲक्सेस पॉइंट आणि तुमच्या RADIUS सर्व्हरमधील एकमेव संरक्षण म्हणजे सामायिक गुपित (shared secret) - मूलतः एक पासवर्ड - ज्याचा वापर MD5 हॅशिंग वापरून ट्रान्झिटमध्ये युझरचा पासवर्ड अस्पष्ट करण्यासाठी केला जातो. MD5, आपल्यापैकी बहुतेकांना माहीत असेल की, क्रिप्टोग्राफिकदृष्ट्या निकामी झाले आहे. हे अनेक वर्षांपासून निकामी झाले आहे. प्रॅक्टिकली याचा अर्थ काय? याचा अर्थ असा की कोणत्याही नेटवर्क सेगमेंटवर जिथे एखादा आक्रमणकर्ता RADIUS ट्रॅफिक थांबवू शकतो - आणि यामध्ये तडजोड केलेले स्विचेस, तुमच्या मॅनेजमेंट VLAN वरील बनावट डिव्हाइसेस किंवा रिमोट ॲक्सेस पॉइंट आणि क्लाउड-होस्ट केलेल्या RADIUS सर्व्हरमधील कोणताही पॉइंट समाविष्ट आहे - ते ऑथेंटिकेशनचे आदानप्रदान कॅप्चर करू शकतात, सामायिक गुपितावर ऑफलाइन डिक्शनरी अटॅकचा प्रयत्न करू शकतात आणि काही कॉन्फिगरेशन्समध्ये, युझर क्रेडेंशियल्स पूर्णपणे उघड करू शकतात. 200 मालमत्तांमध्ये गेस्ट WiFi चालवणाऱ्या हॉटेल ग्रुपसाठी किंवा सार्वजनिक इंटरनेटद्वारे केंद्रीय RADIUS सर्व्हरवर बॅकहाॉलिंग करणाऱ्या प्रत्येक स्टोअरमध्ये ॲक्सेस पॉइंट्स असलेल्या रिटेल चेनसाठी, हा केवळ सैद्धांतिक धोका नाही. हा एक जिवंत हल्ला करण्याचा मार्ग (attack surface) आहे.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 ला नेटिव्हली सपोर्ट करत नाही, जी 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 सर्व्हर क्लाउडमध्ये होस्ट केलेला असतो किंवा सार्वजनिक इंटरनेटद्वारे ॲक्सेस केला जातो तेव्हा हे विशेषतः उपयुक्त ठरते. प्रमाणपत्र व्यवस्थापन (Certificate management) ही ऑपरेशनल गुंतागुंत आहे ज्यासाठी तुम्हाला नियोजन करावे लागेल. म्युच्युअल TLS साठी वापरली जाणारी X.509 प्रमाणपत्रे जारी करण्यासाठी आणि व्यवस्थापित करण्यासाठी तुम्हाला PKI - पब्लिक की इन्फ्रास्ट्रक्चर - ची आवश्यकता असेल. याचा अर्थ प्रमाणपत्र प्राधिकरण (Certificate Authority), प्रत्येक 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 चे काही कनेक्शनलेस गुणधर्म राखून एनक्रिप्शन जोडते. हे RadSec over TLS च्या तुलनेत कमी प्रमाणात तैनात केले जाते परंतु हाय-थ्रुपुट वातावरणात लॅटन्सीची चिंता असल्यास याचे मूल्यांकन करणे फायदेशीर ठरते. "याचा रोमिंग परफॉर्मन्सवर कसा परिणाम होतो?" RadSec चे TCP कनेक्शन सतत सुरू असते, जे पुढील ऑथेंटिकेशन विनंत्यांसाठी कनेक्शन सेटअप ओव्हरहेड कमी करून फेडरेटेड वातावरणात रोमिंग परफॉर्मन्स प्रत्यक्षात सुधारू शकते. - [सारांश आणि पुढील पायऱ्या - साधारण १ मिनिट] थोडक्यात सांगायचे तर: पारंपारिक RADIUS मधील खऱ्या सुरक्षेच्या त्रुटीवर RadSec हे एक परिपक्व, मानकांवर आधारित उत्तर आहे. जर तुम्ही मोठ्या प्रमाणावर - एकाधिक साइट्सवर, इंटरनेटवर किंवा PCI-DSS किंवा GDPR च्या अधीन असलेल्या वातावरणात एंटरप्राइझ WiFi चालवत असाल - तर RadSec तैनात करायचे की नाही हा प्रश्न नसून, ते कधी आणि कसे करायचे हा प्रश्न आहे. तुमच्या पुढील पायऱ्या: या आठवड्यात तुमच्या RADIUS इन्फ्रास्ट्रक्चरचे ऑडिट करा. तुमचे सर्वाधिक जोखीम असलेले ट्रॅफिक फ्लो ओळखा. नेटिव्ह RadSec सपोर्टसाठी तुमचे RADIUS सर्व्हर आणि ऍक्सेस पॉइंट व्हेंडरचे दस्तऐवजीकरण तपासा. जर तुम्ही FreeRADIUS चालवत असाल, तर तुम्ही एका दिवसात चाचणी RadSec तैनात करू शकता. जर तुम्ही Microsoft NPS वर असाल, तर प्रॉक्सीचे किंवा RadSec-सक्षम सर्व्हरवर स्थलांतरित होण्याच्या मार्गाचे मूल्यांकन करण्यास सुरुवात करा. Purple चे प्लॅटफॉर्म कॉर्पोरेट आणि गेस्ट WiFi दोन्ही वातावरणासाठी सुरक्षित ऑथेंटिकेशन फ्लोला सपोर्ट करत एंटरप्राइझ RADIUS इन्फ्रास्ट्रक्चरशी समाकलित होण्यासाठी डिझाइन केले आहे. तुमच्या विशिष्ट तैनातीमध्ये RadSec कसे बसेल हे तुम्हाला समजून घ्यायचे असल्यास, Purple टीम तुम्हाला त्याबद्दल मार्गदर्शन करू शकते. ऐकल्याबद्दल धन्यवाद. पुढील वेळेपर्यंत निरोप. - स्क्रिप्ट समाप्त

आमच्या मुख्य मालिकेचा भाग: Enterprise WiFi Security Guide →

RFC 6614 Architecture ToolCloud RADIUS over TLS 1.3

RadSec Architecture Advisor: RADIUS over TLS Evaluator

Model TCP port 2083 TLS encapsulation overhead against legacy UDP RADIUS across WAN circuits. Calculate EAP-TLS handshake latencies, eliminate packet fragmentation black holes, and audit RFC 6614 trust.

Legacy UDP Latency (WAN)
302 ms
Includes 144 ms UDP timeout penalty
RadSec TLS Latency
160 ms
Fast TCP ACK recovery without timeout stalls
Handshake Latency Savings
47% faster
Saves 142 ms per EAP-TLS negotiation
At 0.5% packet loss, 4% of EAP-TLS exchanges lose at least one of their 9 packets. On UDP each loss waits out a 3,200 ms retransmit timer; on TCP a fast retransmit recovers it inside one or two round trips.
RFC 6614 PKI Posture
4 / 5 controls
One load-bearing control missing

Protocol Architecture: RadSec (RFC 6614) vs Legacy RADIUS (RFC 2865)

Security & Network VectorRadSec (RFC 6614 / TLS 1.3)Legacy RADIUS (RFC 2865 / UDP)
Transport & PortTCP Port 2083 (Stateful stream)UDP Ports 1812 / 1813 (Stateless datagrams)
Payload CryptographyTLS 1.3 Mutual Authentication (mTLS) with AEAD ciphersPre-Shared Key with MD5 hashing (RFC 2865 BlastRADIUS exposure)
MTU & Packet FragmentationTCP PMTU Discovery eliminates UDP fragmentation black holesLarge EAP-TLS certificate chains fragment over 1500 bytes and drop on WAN
Firewall Traversal & NATSingle outbound TCP connection; state table persists cleanlyRequires bi-directional UDP NAT pinholes prone to 30s timeout aging
Packet Loss RecoveryTCP fast retransmission within 1 to 2 RTTs (~70 ms)Controller retry timeout (typically 3,000 to 5,000 ms per drop)
Connection ModelLong-lived persistent TCP connection pool with keep-alivePer-packet datagrams with independent identifier tracking
Why BlastRADIUS (CVE-2024-3596) Mandates RadSec for WAN Authentications

The BlastRADIUS vulnerability exploits MD5 collisions in standard RFC 2865 Access-Request packets to forge an Access-Accept without the shared secret. RadSec protects the entire RADIUS protocol inside TLS 1.3 encryption, rendering man-in-the-middle packet injection impossible across untrusted internet WAN links.

Migrating Enterprise WiFi to Cloud RADIUS & RadSec?

Purple Cloud RADIUS delivers turnkey RFC 6614 RadSec termination, automated Intune and Jamf SCEP certificate enrolment, and zero on-prem server maintenance.

Security Guide →
Useful? Link to this tool

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

मुख्य सारांश (Executive Summary)

UDP (पोर्ट्स 1812/1813) वरील पारंपारिक RADIUS हे आधुनिक एंटरप्राइझ थ्रेट लँडस्केपसाठी डिझाइन केलेले नव्हते. केवळ शेअर केलेल्या गुपितावर (shared secret) आणि MD5 हॅशिंगवर अवलंबून राहिल्याने, ते ऑथेंटिकेशन क्रेडेंशियल्स आणि सेशन ॲट्रिब्यूट्स इंटरसेप्शनसाठी असुरक्षित ठेवते, विशेषतः जेव्हा ते सार्वजनिक नेटवर्क किंवा हॉस्पिटॅलिटी आणि रिटेल चेन्स सारख्या मोठ्या वितरित इस्टेटमधून प्रवास करतात. RadSec (TLS वर RADIUS, RFC 6614) हे पोर्ट 2083 वर TCP-आधारित TLS 1.3 टनेलमध्ये RADIUS ट्रॅफिक सुरक्षितपणे एन्कॅप्स्युलेट करून ही मूलभूत सुरक्षेची त्रुटी दूर करते.

CTO आणि नेटवर्क आर्किटेक्ट्ससाठी, RadSec तैनात करणे ही आता केवळ एक सर्वोत्तम पद्धत राहिलेली नाही - तर कॉर्पोरेट WiFi चे संरक्षण करण्यासाठी, PCI DSS 4.0 अनुपालन राखण्यासाठी आणि OpenRoaming सारख्या आधुनिक फेडरेटेड रोमिंग फ्रेमवर्कमध्ये भाग घेण्यासाठी ही एक अत्यंत महत्त्वाची आवश्यकता आहे. हे मार्गदर्शक तुमच्या ऑथेंटिकेशन इन्फ्रास्ट्रक्चरला सुरक्षित करण्यासाठी आर्किटेक्चर, अंमलबजावणीचे पॅटर्न आणि ऑपरेशनल आवश्यकतांचा तपशील देते.

तांत्रिक सखोल माहिती: RADIUS विरुद्ध RadSec

पारंपारिक RADIUS मधील असुरक्षितता

प्रमाणित 802.1X डिप्लॉयमेंटमध्ये, ॲक्सेस पॉइंट (ऑथेंटिकेटर) क्लायंट क्रेडेंशियल्स RADIUS सर्व्हरकडे (ऑथेंटिकेशन सर्व्हर) फॉरवर्ड करतो. पारंपारिक RADIUS मध्ये, हा पेलोड UDP वर पाठवला जातो. याचे एकमेव संरक्षण म्हणजे MD5 द्वारे पासवर्ड अस्पष्ट करण्यासाठी वापरली जाणारी प्री-शेअर्ड की (PSK) होय.

हे आर्किटेक्चर तीन गंभीर धोके निर्माण करते:

  1. ट्रान्सपोर्ट एन्क्रिप्शनचा अभाव: युझर ॲट्रिब्यूट्स, MAC ॲड्रेस आणि सेशन डेटा क्लिअरटेक्स्ट (cleartext) मध्ये ट्रान्समिट केला जातो.
  2. क्रिप्टोग्राफिक कमकुवतपणा: हल्लेखोराने ट्रॅफिक कॅप्चर केल्यास MD5 हे ऑफलाइन डिक्शनरी हल्ल्यांना बळी पडू शकते.
  3. परस्पर ऑथेंटिकेशनचा अभाव (No Mutual Authentication): ॲक्सेस पॉइंट क्रिप्टोग्राफिक पद्धतीने सत्यापित करू शकत नाही की तो कायदेशीर RADIUS सर्व्हरशी बोलत आहे, ज्यामुळे बनावट सर्व्हर हल्ले सुलभ होतात.

RadSec आर्किटेक्चर (RFC 6614)

RadSec ट्रान्सपोर्ट लेयरला UDP वरून TCP वर हलवून आणि संपूर्ण पेलोडला TLS मध्ये सुरक्षित करून या त्रुटींचे निवारण करते.

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

  • ट्रान्सपोर्ट: TCP पोर्ट 2083 विश्वसनीय डिलिव्हरी आणि स्टेटफुल कनेक्शन्स सुनिश्चित करते, ज्यामुळे हाय-लेटन्सी वातावरणात कार्यप्रदर्शन सुधारते.
  • एन्क्रिप्शन: TLS 1.2 किंवा 1.3 सर्व RADIUS ॲट्रिब्यूट्सचे मजबूत, एंड-टू-एंड एन्क्रिप्शन प्रदान करते.
  • परस्पर ऑथेंटिकेशन (Mutual Authentication): RADIUS क्लायंट (किंवा प्रॉक्सी) आणि सर्व्हर दोघांनीही विश्वसनीय सर्टिफिकेट ऑथॉरिटी (CA) द्वारे जारी केलेले वैध X.509 सर्टिफिकेट सादर करणे आवश्यक आहे. शेअर केलेले गुपित केवळ बॅकवर्ड सुसंगततेसाठी ठेवले जाते; TLS वास्तविक सुरक्षा प्रदान करते.ही आर्किटेक्चर डिस्ट्रिब्युटेड वातावरणासाठी अत्यंत आवश्यक आहे, जसे की Retail चेन्स किंवा Hospitality ठिकाणे, जेथे ॲक्सेस पॉइंट्स पब्लिक इंटरनेटद्वारे सेंट्रल किंवा क्लाउड-होस्ट केलेल्या RADIUS सर्व्हरकडे बॅकहॉल ऑथेंटिकेशन विनंत्या पाठवतात.

तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.

इम्प्लीमेंटेशन मार्गदर्शक

RadSec तैनात करणे सामान्यतः दोनपैकी एका पॅटर्नचे अनुसरण करते: मूळ सपोर्ट (Native Support) किंवा प्रॉक्सी-आधारित (Proxy-based).

पॅटर्न १: नेटिव्ह RadSec

जर तुमचे इन्फ्रास्ट्रक्चर याला मूळ स्वरूपात सपोर्ट करत असेल (उदा. FreeRADIUS 3.0+, Cisco ISE, Aruba ClearPass), तर तुम्ही थेट RADIUS सर्व्हर आणि ॲक्सेस पॉइंट्स/कंट्रोलर्सवर TLS सर्टिफिकेट्स कॉन्फिगर करता. हे एजपासून कोअरपर्यंत खरी एंड-टू-एंड एन्क्रिप्शन प्रदान करते.

पॅटर्न २: RadSec प्रॉक्सी

बरेच लेगसी RADIUS सर्व्हर (विशेषतः Microsoft NPS) RadSec ला मूळ स्वरूपात सपोर्ट करत नाहीत. अशा वातावरणात, एक प्रॉक्सी (जसे की radsecproxy) तैनात केली जाते.

१. स्थानिक टप्पा (Local Leg): AP स्थानिक प्रॉक्सीला मानक UDP RADIUS पाठवतो. २. WAN टप्पा (WAN Leg): प्रॉक्सी हे ट्रॅफिक TLS मध्ये एन्कॅप्स्युलेट करते आणि TCP 2083 द्वारे अपस्ट्रीम सर्व्हरकडे पाठवते.

हा पॅटर्न तुम्हाला लेगसी इन्फ्रास्ट्रक्चर न बदलता वाईड-एरिया ट्रॅफिक सुरक्षित करण्याची परवानगी देतो.

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

Purple सोबत इंटिग्रेशन

Purple चे Guest WiFi आणि WiFi Analytics प्लॅटफॉर्म्स एंटरप्राइझ RADIUS इन्फ्रास्ट्रक्चरसोबत अखंडपणे इंटिग्रेट होतात. Connect लायसन्स अंतर्गत, Purple हे OpenRoaming साठी मोफत ओळख प्रदाता (identity provider) म्हणून काम करते, जिथे ठिकाणे आणि सेंट्रल हब दरम्यान फेडरेशन ट्रॅफिक सुरक्षित करण्यासाठी RadSec ही एक अनिवार्य आवश्यकता आहे.

सर्वोत्तम पद्धती

१. सर्टिफिकेट लाइफसायकल मॅनेजमेंट: म्युच्युअल TLS वैध सर्टिफिकेट्सवर अवलंबून असते. ऑटोमेटेड रिन्यूअल (उदा. ACME द्वारे) आणि कडक मॉनिटरिंग लागू करा. एक्स्पायर झालेले सर्टिफिकेट संपूर्ण ऑथेंटिकेशन आउटेजचे कारण बनेल. २. फायरवॉल कॉन्फिगरेशन: TCP पोर्ट 2083 ठिकाणाहून आउटबाउंड आणि RADIUS सर्व्हरला इनबाउंड दोन्हीसाठी स्पष्टपणे अनुमती दिलेला असल्याची खात्री करा. सध्याचे UDP 1812 नियम लागू होतील असे गृहीत धरू नका. ३. उच्च-जोखमीच्या ट्रॅफिकला प्राधान्य द्या: स्थानिक व्यवस्थापन VLANs कडे जाण्यापूर्वी पब्लिक इंटरनेट किंवा असुरक्षित WANs पार करणाऱ्या लिंक्सवर तैनाती सुरू करा.

एज सुरक्षित करण्याबद्दल अधिक माहितीसाठी, आमचे Access Point Security: Your 2026 Enterprise Guide हे मार्गदर्शक वाचा.

ट्रबलशूटिंग आणि जोखीम निवारण

जेव्हा RadSec अयशस्वी होते, तेव्हा ती क्वचितच ऑथेंटिकेशनची समस्या असते; ती जवळजवळ नेहमीच TLS किंवा TCP ची समस्या असते.

  • लक्षण: ॲक्सेस पॉइंट्स RADIUS सर्व्हरपासून डिस्कनेक्ट झालेले दिसतात.
    • तपासा: TCP 2083 साठी फायरवॉल नियम. पारंपारिक RADIUS UDP वापरते; नेटवर्क टीम्स वारंवार TCP पोर्ट उघडण्यास विसरतात.
  • लक्षण: TCP कनेक्शन स्थापित होते, परंतु ऑथेंटिकेशन त्वरित अयशस्वी होते.
    • तपासा: प्रमाणपत्र पडताळणी. Common Name (CN) किंवा Subject Alternative Name (SAN) जुळत असल्याचे, प्रमाणपत्राची मुदत संपलेली नसल्याचे आणि क्लायंट स्वाक्षरी करणाऱ्या CA वर विश्वास ठेवत असल्याची खात्री करा. हँडशेकची त्रुटी शोधण्यासाठी openssl s_client -connect <server>:2083 वापरा.

तुमचे नेटवर्कचे मूलभूत घटक भक्कम असल्याची खात्री करा. आमच्या Protect Your Network with Strong DNS and Security वरील सल्ल्याचे पुनरावलोकन करा.

ROI आणि व्यावसायिक प्रभाव

RadSec लागू करणे ही एक जोखीम कमी करणारी गुंतवणूक आहे. डेटा चोरी टाळणे, अनुपालन दंड (PCI DSS, GDPR), आणि प्रतिष्ठेचे नुकसान रोखणे यावर याचा ROI मोजला जातो. शिवाय, हे OpenRoaming सारख्या आधुनिक रोमिंग फेडरेशनमध्ये सहभागी होण्यास सक्षम करते, जे Healthcare आणि Transport वातावरणात पाहुण्यांच्या अनुभवामध्ये लक्षणीय सुधारणा करू शकते.

ब्रीफिंग ऐका

RadSec उपयोजित करण्याच्या कार्यात्मक वास्तवाचा अधिक सखोल अभ्यास करण्यासाठी, आमचे १० मिनिटांचे तांत्रिक ब्रीफिंग ऐका:

क्लायंट डिव्हाइसेसवरील विशिष्ट कॉन्फिगरेशन चरणांसाठी, How to Set Up Enterprise WiFi on iOS and macOS with 802.1X पहा.

महत्वाच्या व्याख्या

RadSec

RADIUS प्रोटोकॉलचा एक विस्तार जो RADIUS ट्रॅफिकला TCP पोर्ट 2083 वर TLS टनेलमध्ये सुरक्षित करतो.

असुरक्षित नेटवर्क्समधून जाताना ऑथेंटिकेशन ट्रॅफिक सुरक्षित करण्यासाठी वापरले जाते, ज्यामुळे क्रेडेंशियल चोरी रोखली जाते.

Mutual TLS (mTLS)

एक सुरक्षा प्रक्रिया जिथे क्लायंट आणि सर्व्हर दोघेही एन्क्रिप्टेड कनेक्शन स्थापित करण्यापूर्वी एकमेकांची ओळख पडताळण्यासाठी X.509 सर्टिफिकेट्स सादर करतात.

RadSec चे मुख्य ऑथेंटिकेशन मेकॅनिझम, जे स्टॅटिक शेअर्ड सिक्रेट्सवरील अवलंबित्व संपुष्टात आणते.

802.1X

पोर्ट-आधारित नेटवर्क ॲक्सेस कंट्रोलसाठीचे IEEE मानकीकरण, जे LAN किंवा WLAN ला कनेक्ट करू पाहणाऱ्या डिव्हाइसेसचे ऑथेंटिकेशन करण्यासाठी वापरले जाते.

डिरेक्टरीच्या तुलनेत युझर क्रेडेंशियल्स प्रमाणित करण्यासाठी RADIUS (आणि पर्यायाने RadSec) वर अवलंबून असणारे फ्रेमवर्क.

radsecproxy

एक ओपन-सोर्स डीमन जे प्रॉक्सी म्हणून काम करते आणि मानक UDP RADIUS ट्रॅफिकला RadSec (TCP वरील TLS) मध्ये आणि उलट रूपांतरित करते.

जेव्हा ॲक्सेस पॉईंट्स किंवा Microsoft NPS सारख्या जुन्या RADIUS सर्व्हर्समध्ये मूळ RadSec सपोर्ट नसतो तेव्हा तैनात केले जाते.

OpenRoaming

WiFi Alliance द्वारे विकसित केलेले एक फेडरेशन मानक जे वापरकर्त्यांना जगभरातील सहभागी WiFi नेटवर्क्सशी अखंड आणि सुरक्षितपणे कनेक्ट होऊ देते.

OpenRoaming हे ठिकाणे आणि ओळख पुरवठादार यांच्यातील ऑथेंटिकेशन ट्रॅफिक सुरक्षित करण्यासाठी RadSec च्या वापराला अनिवार्य करते.

Shared Secret

पारंपारिक RADIUS मध्ये पासवर्ड लपवण्यासाठी आणि विनंत्यांचे स्त्रोत पडताळण्यासाठी वापरली जाणारी एक स्टॅटिक टेक्स्ट स्ट्रिंग.

मागील आवृत्त्यांशी सुसंगततेसाठी RadSec कॉन्फिगरेशनमध्ये तांत्रिकदृष्ट्या अद्याप उपस्थित असले, तरी TLS एन्क्रिप्शनमुळे याची जागा घेतली गेली आहे.

FreeRADIUS

एक मोठ्या प्रमाणावर तैनात केलेले ओपन-सोर्स RADIUS सर्व्हर जे RadSec साठी मूळ सपोर्ट प्रदान करते.

त्याच्या लवचिकतेमुळे आणि मूळ TLS क्षमतेमुळे बहुधा एंटरप्राइझ वातावरणात आणि रोमिंग फेडरेशन्समध्ये वापरले जाते.

PKI (Public Key Infrastructure)

डिजिटल प्रमाणपत्रे तयार करण्यासाठी, व्यवस्थापित करण्यासाठी, वितरित करण्यासाठी आणि रद्द करण्यासाठी आवश्यक असलेल्या भूमिका, धोरणे आणि सॉफ्टवेअरची रचना.

RadSec तैनात करण्यासाठी आवश्यक पूर्वअट, कारण तुम्ही सर्व RADIUS क्लायंट्स आणि सर्व्हर्ससाठी सर्टिफिकेट्स जारी आणि व्यवस्थापित करणे आवश्यक आहे.

सोडवलेली उदाहरणे

२००-प्रॉपर्टी असलेली एक हॉटेल साखळी कर्मचाऱ्यांच्या ऑथेंटिकेशनसाठी मध्यवर्ती पातळीवर Microsoft NPS वापरते. प्रत्येक हॉटेलमधील ॲक्सेस पॉईंट्स सध्या UDP 1812 द्वारे जाहीर इंटरनेटवरून RADIUS विनंत्या पाठवतात. CTO ने सर्व ऑथेंटिकेशन ट्रॅफिकसाठी एन्क्रिप्शन अनिवार्य केले आहे, परंतु या वर्षात NPS बदलणे शक्य नाही.

प्रत्येक हॉटेलच्या ठिकाणी एक RadSec प्रॉक्सी (उदा. radsecproxy) आणि मध्यवर्ती डेटा सेंटरमध्ये NPS सर्व्हर्सच्या समोर एक संबंधित प्रॉक्सी तैनात करा. स्थानिक APs स्थानिक प्रॉक्सीकडे UDP RADIUS पाठवतात. स्थानिक प्रॉक्सी संपूर्ण इंटरनेटवर मध्यवर्ती प्रॉक्सीला TCP 2083 द्वारे परस्पर TLS टनेल स्थापित करते. मध्यवर्ती प्रॉक्सी हे TLS टनेल समाप्त करते आणि NPS सर्व्हरकडे मानक UDP RADIUS फॉरवर्ड करते.

परीक्षकाचे भाष्य: हा दृष्टिकोन मुख्य Microsoft NPS इन्फ्रास्ट्रक्चर पूर्णपणे न बदलता - ज्यासाठी मोठा खर्च आणि व्यत्यय आला असता - असुरक्षित WAN वर ऑथेंटिकेशन डेटा एन्क्रिप्ट करण्याचे प्राथमिक सुरक्षा ध्येय साध्य करतो. हे प्रॉक्सींसाठी सर्टिफिकेट मॅनेजमेंटचे अतिरिक्त काम निर्माण करते, जे ऑटोमेटेड असणे आवश्यक आहे.

एक मोठे विद्यापीठ भेट देणाऱ्या अभ्यासकांसाठी अखंड प्रवेश देण्यासाठी त्यांच्या कॅम्पसमध्ये OpenRoaming तैनात करत आहे. ते FreeRADIUS 3.0 वापरत आहेत.

FreeRADIUS मध्ये मूळ RadSec सक्षम करा. OpenRoaming फेडरेशनद्वारे विश्वासार्ह असलेल्या CA कडून X.509 सर्टिफिकेट्स जनरेट करा. फेडरेशन हब्सना येणाऱ्या आणि जाणाऱ्या TCP 2083 ट्रॅफिकला अनुमती देण्यासाठी कॅम्पस फायरवॉल कॉन्फिगर करा. सर्व फेडरेशन-बाउंड ऑथेंटिकेशन विनंत्यांसाठी RadSec वापरण्यासाठी वायरलेस LAN कंट्रोलर्स कॉन्फिगर करा.

परीक्षकाचे भाष्य: FreeRADIUS मूळतः RadSec ला सपोर्ट करत असल्याने, कोणत्याही प्रॉक्सीची आवश्यकता नाही. हे सर्वात सुटसुटीत आर्किटेक्चर आहे. येथील महत्त्वाची बाब म्हणजे सर्टिफिकेट्स हे OpenRoaming फेडरेशनच्या विशिष्ट PKI आवश्यकतांशी सुसंगत असणे सुनिश्चित करणे ही आहे.

सराव प्रश्न

Q1. तुमच्या टीमने तुमच्या रिमोट ब्रांच ॲक्सेस पॉइंट्स आणि तुमच्या सेंट्रल FreeRADIUS सर्व्हर दरम्यान नेटिव्ह RadSec तैनात केले आहे. APs सर्व्हरला पिंग करू शकतात, परंतु ऑथेंटिकेशन विनंत्या पूर्णपणे टाईम आऊट होत आहेत आणि RADIUS लॉगमध्ये कोणतीही ट्रॅफिक दिसत नाही.

टीप: RadSec हे पारंपारिक RADIUS पेक्षा वेगळा ट्रान्सपोर्ट प्रोटोकॉल आणि पोर्ट वापरते.

नमुना उत्तर पहा

फायरवॉल बहुधा TCP पोर्ट 2083 ब्लॉक करत आहे. पारंपारिक RADIUS ची सवय असलेल्या नेटवर्क टीम्स सहसा फक्त UDP पोर्ट 1812/1813 ला परवानगी देतात. तुम्ही ब्रांचमधून आउटबाउंड आणि RADIUS सर्व्हरवर इनबाउंड जाणाऱ्या TCP 2083 ला स्पष्टपणे परवानगी दिली पाहिजे.

Q2. तुम्ही रिटेल क्लायंटच्या WiFi आर्किटेक्चरचे ऑडिट करत आहात. ते मध्यवर्ती पद्धतीने Microsoft NPS वापरतात. त्यांच्या स्टोअरचे APs इंटरनेटवर IPsec VPN द्वारे ऑथेंटिकेशन विनंत्या पाठवतात. येथे RadSec आवश्यक आहे का?

टीप: आधीपासूनच अस्तित्वात असलेल्या एन्क्रिप्शनच्या लेयर्सचा विचार करा.

नमुना उत्तर पहा

RadSec वापरणे ही सर्वोत्तम पद्धत असली तरी, IPsec VPN आधीपासूनच असुरक्षित इंटरनेटवर UDP RADIUS ट्रॅफिकसाठी ट्रान्सपोर्ट लेयर एन्क्रिप्शन प्रदान करत आहे. येथे RadSec तैनात केल्याने सखोल सुरक्षा (defence-in-depth) मिळेल, परंतु ट्रॅफिक थेट इंटरनेटवरून जात असण्याच्या तुलनेत हे कमी तातडीचे आहे.

Q3. यशस्वी RadSec प्रॉक्सी तैनातीनंतर एका आठवड्याने, संपूर्ण एंटरप्राइझमधील सर्व WiFi ऑथेंटिकेशन सोमवारी सकाळी 09:00 वाजता एकाच वेळी अयशस्वी होते. नेटवर्क टीमने पुष्टी केली की फायरवॉल नियम बदललेले नाहीत.

टीप: स्वतः TLS टनेलसाठी मुख्य ऑथेंटिकेशन यंत्रणा काय आहे?

नमुना उत्तर पहा

म्युच्युअल TLS ऑथेंटिकेशनसाठी वापरली जाणारी X.509 प्रमाणपत्रे बहुधा कालबाह्य झाली आहेत. जेव्हा प्रमाणपत्रे कालबाह्य होतात, तेव्हा TLS हँडशेक अयशस्वी होतो, TCP कनेक्शन खंडित होते आणि RADIUS ट्रॅफिक प्रवाहित होऊ शकत नाही. हे टाळण्यासाठी स्वयंचलित प्रमाणपत्र देखरेख आणि रोटेशन लागू करा.

वारंवार विचारले जाणारे प्रश्न

RadSec (RFC 6614) म्हणजे काय आणि ते जुन्या RADIUS पेक्षा वेगळे कसे आहे?

RadSec हे सुरक्षित TLS 1.3 टनेलच्या आत TCP पोर्ट 2083 वर मानक RADIUS ऑथेंटिकेशन, ऑथोरायझेशन आणि अकाउंटिंग (AAA) डेटाग्राम्स एन्कॅप्स्युलेट करते. जुना RADIUS (RFC 2865) हा MD5-हॅश केलेल्या शेअर्ड सिक्रेट्ससह कनेक्शन नसलेल्या UDP पोर्ट्स 1812 आणि 1813 वर अवलंबून असतो, ज्यामुळे पॅकेट्स चोरीला जाणे, पॅकेट्समध्ये बदल होणे आणि UDP फ्रॅगमेंटेशनचा धोका वाढतो. RadSec हे वायरलेस कंट्रोलर्स आणि क्लाउड RADIUS सर्व्हर दरम्यान म्युच्युअल TLS (mTLS) प्रमाणपत्र पडताळणी, कनेक्शन कीप-अलाईव्ह आणि एन्क्रिप्टेड WAN ट्रान्सपोर्ट सादर करते.

RadSec हे BlastRADIUS सुरक्षेच्या त्रुटीपासून एंटरप्राइझ WiFi चे संरक्षण कसे करते?

BlastRADIUS (CVE-2024-3596) हे जुन्या RFC 2865 Access-Request पॅकेट्समधील MD5 क्रिप्टोग्राफिक कोलिझन्सचा गैरफायदा घेते, ज्यामुळे WAN मार्गावरील आक्रमणकर्ते शेअर्ड सिक्रेट माहित नसतानाही वैध Access-Accept प्रतिसाद तयार करू शकतात. RadSec संपूर्ण RADIUS सत्राला एका ऑथेंटिकेटेड, एन्क्रिप्टेड TLS 1.3 स्ट्रीममध्ये सुरक्षित करत असल्याने, आक्रमणकर्ते पॅकेट पेलोड किंवा ॲट्रिब्युट्स तपासू शकत नाहीत किंवा फेरफार करू शकत नाहीत, ज्यामुळे MD5 बनावटगिरी आणि मॅन-इन-द-मिडल हल्ले निष्प्रभ होतात.

RadSec मुळे WAN लिंक्सवरील EAP-TLS पॅकेट फ्रॅगमेंटेशनच्या समस्या का दूर होतात?

सर्टिफिकेट-आधारित 802.1X EAP-TLS ऑथेंटिकेशनमध्ये, क्लायंट आणि इंटरमीडिएट सर्टिफिकेट चेन्स वारंवार मानक 1500-बाईट इथरनेट MTU पेक्षा जास्त असतात. UDP वर, फ्रॅगमेंट झालेले RADIUS पॅकेट्स हे इंटरनेट सर्व्हिस प्रोव्हाइडर्स, कॉर्पोरेट फायरबॉल्स आणि करिअर NAT गेटवेजद्वारे नियमितपणे ड्रॉप केले जातात. RadSec हे TCP Path MTU Discovery (PMTU) आणि TCP सेगमेंटेशनचा वापर करते, ज्यामुळे पॅकेट गमावल्याशिवाय किंवा कंट्रोलर टाइमआउट न होता मोठ्या सर्टिफिकेट चेन्स अखंडपणे ट्रान्सफर होतात.

RadSec मधील पर्सिस्टंट TCP कनेक्शन पूलिंग ऑथेंटिकेशन लेटन्सी कशी कमी करते?

प्रत्येक ऑथेंटिकेशन विनंतीसाठी नवीन TCP थ्री-वे हँडशेक आणि TLS की एक्स्चेंज करण्याऐवजी, आधुनिक एंटरप्राइझ कंट्रोलर्स आणि RadSec प्रॉक्सीज निरंतर कनेक्शन पूल स्थापित करतात. एकदा स्थापित झाल्यावर, एकाधिक 802.1X ऑथेंटिकेशन्स ओपन TLS सॉकेटचा पुन्हा वापर करतात. जर WAN वर एखादे पॅकेट ड्रॉप झाले, तर TCP सिलेक्टिव्ह ॲकनॉलेजमेंट (SACK) गमावलेला सेगमेंट १ ते २ राउंड ट्रिप्समध्ये (~७०ms) पुन्हा ट्रान्समिट करते, ज्यामुळे UDP RADIUS मध्ये सामान्य असणारा बहु-सेकंदांचा ॲप्लिकेशन टाइमआउट टळतो.

RadSec तैनात करण्यासाठी कोणते म्युच्युअल सर्टिफिकेट ऑथेंटिकेशन (mTLS) आवश्यक आहे?

RFC 6614 हे द्विदिश X.509 सर्टिफिकेट व्हॅलिडेशन अनिवार्य करते. वायरलेस ॲक्सेस कंट्रोलर एका विश्वसनीय एंटरप्राइझ CA बंडलचा वापर करून क्लाउड RADIUS FQDN (radius1.purplewifi.net) च्या विरूद्ध सर्व्हर सर्टिफिकेट Subject Alternative Name (SAN) ची पडताळणी करतो. याउलट, क्लाउड RADIUS सर्व्हर कंट्रोलर क्लायंट सर्टिफिकेट आणि प्रायव्हेट की ची पडताळणी करतो, ज्यामुळे केवळ अधिकृत नेटवर्क हार्डवेअरच ऑथेंटिकेशन विनंत्या सबमिट करू शकतात याची खात्री होते.

RadSec तैनातीसाठी कोणते फायरवॉल नियम आणि नेटवर्क पोर्ट्स आवश्यक आहेत?

नेटवर्क ॲडमिनिस्ट्रेटर्सनी वायरलेस LAN कंट्रोलर्स किंवा एज ॲक्सेस पॉइंट्सपासून क्लाउड RADIUS एंडपॉइंट्सपर्यंत आउटबाउंड TCP पोर्ट 2083 ट्रॅफिकला परवानगी देणे आवश्यक आहे. जुन्या UDP RADIUS च्या विपरीत, ज्यासाठी UDP 1812 आणि 1813 वर स्टेटफुल NAT पिनहोल्स आवश्यक असतात आणि जे निष्क्रियतेच्या ३० सेकंदांनंतर वारंवार कालबाह्य होतात, RadSec स्वयंचलित ॲप्लिकेशन-लेअर कीप-अलाईव्ह प्रोब्सद्वारे राखलेल्या सिंगल आउटबाउंड TCP स्ट्रीमचा वापर करते.

या मालिकेमध्ये पुढे वाचा

CIPA compliance: venue operators साठी compliance checklist

तुमचे WiFi CIPA च्या बंधनात येते की नाही हे तुम्ही ठरवू शकाल, त्यानंतर नेटवर्कचे वर्गीकरण करू शकाल, Purple Shield द्वारे DNS रूट करू शकाल आणि बायपास मार्ग बंद करू शकाल. Form 486 किंवा Form 479 प्रमाणपत्रासाठी कोणते पुरावे ठेवावे हे देखील तुम्हाला समजेल. ही checklist प्रत्येक आवश्यकतेला एक मालक नियुक्त करते, जेणेकरून तुमच्या पुढील फंडिंग वर्षाच्या प्रमाणपत्रात काहीही सुटणार नाही.

मार्गदर्शिका वाचा →

WPA3 transition mode कनेक्शन बिघाड: Cisco Meraki, HPE Aruba आणि Ruckus साठी एक उपयोजन चेकलिस्ट

डिव्हाइसेस WPA3 SAE transition mode SSID वर का अयशस्वी होत आहेत याचे निदान करण्यासाठी आणि ते Cisco Meraki, HPE Aruba किंवा Ruckus वर दुरुस्त करण्यासाठी या चेकलिस्टचा वापर करा. तुम्ही 802.11 स्टेटस कोडचे त्यांच्या कारणांशी मिलान कराल, PMF, 802.11r आणि 6GHz च्या समस्या वेगळ्या कराल आणि फक्त WPA3-only SSID वर कधी स्थलांतरित व्हायचे ते ठरवाल.

मार्गदर्शिका वाचा →

सर्वोत्तम DNS filtering: व्यवसायांसाठी एक व्यापक मार्गदर्शक

हे तांत्रिक संदर्भ मार्गदर्शक स्पष्ट करते की कशा प्रकारे एंटरप्राइझ DNS filtering हे कनेक्शन स्थापित होण्यापूर्वीच, रेझोल्युशन लेयरवर दुर्भावनापूर्ण डोमेन्स ब्लॉक करून सार्वजनिक नेटवर्क सुरक्षित करते. हे IT संचालक, नेटवर्क आर्किटेक्ट आणि वेन्यू ऑपरेशन्स टीम्सना डेप्युलॉयमेंट आर्किटेक्चर, फायरवॉल कॉन्फिगरेशन आणि आवश्यक कंप्लायन्स संदर्भ प्रदान करते जे त्यांना हॉस्पिटॅलिटी, रिटेल आणि सार्वजनिक क्षेत्रातील वातावरणात Guest WiFi सुरक्षित करण्यासाठी आवश्यक आहेत. Purple Shield हे 80,000 पेक्षा जास्त लाईव्ह वेन्यूजमध्ये DNS स्तरावर मालवेअर, बॉटनेट्स आणि अयोग्य कंटेंट ब्लॉक करते.

मार्गदर्शिका वाचा →

तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.