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

RadSec: TLS के साथ RADIUS ऑथेंटिकेशन ट्रैफिक को सुरक्षित करना। एक Purple टेक्निकल ब्रीफिंग। परिचय और संदर्भ। इस Purple टेक्निकल ब्रीफिंग में आपका स्वागत है। मैं आपको RadSec — RADIUS over TLS — के बारे में बताऊंगा कि यह क्या है, यह अभी क्यों महत्वपूर्ण है, और आप इसे वास्तव में कैसे डिप्लॉय करते हैं। यह सीधे तौर पर उन नेटवर्क आर्किटेक्ट्स और सुरक्षा इंजीनियरों के लिए है जो या तो आज क्लाउड RADIUS चला रहे हैं या वहां जाने की योजना बना रहे हैं। यदि आप अभी भी UDP और एक शेयर्ड सीक्रेट के साथ ऑन-प्रिमाइसेस RADIUS सर्वर चला रहे हैं, तो यह ब्रीफिंग आपके लिए है। आइए इसकी पृष्ठभूमि तैयार करें। RADIUS तीस से अधिक वर्षों से नेटवर्क ऑथेंटिकेशन की रीढ़ रहा है। यह 802.1X, WPA2-Enterprise, WPA3-Enterprise और आज प्रोडक्शन में लगभग हर कैप्टिव पोर्टल सिस्टम का आधार है। RFC 2865 में परिभाषित यह प्रोटोकॉल स्वयं एक ऐसे युग में डिज़ाइन किया गया था जब इंटरनेट बहुत अलग जगह थी। आपके NAS डिवाइसेज — आपके एक्सेस पॉइंट्स, स्विच और कंट्रोलर्स — और आपके RADIUS सर्वर के बीच ऑथेंटिकेशन ट्रैफिक UDP पर चलता था, ऑथेंटिकेशन के लिए पोर्ट 1812, अकाउंटिंग के लिए पोर्ट 1813। और वह ट्रैफिक? काफी हद तक अनएन्क्रिप्टेड। एकमात्र सुरक्षा एक शेयर्ड सीक्रेट थी जिसका उपयोग यूजर पासवर्ड एट्रिब्यूट को ऑब्फस्केट करने के लिए किया जाता था, और इसके भी अच्छी तरह से प्रलेखित (well-documented) कमजोरियां हैं। वर्षों तक, यह स्वीकार्य था क्योंकि RADIUS ट्रैफिक प्राइवेट, नियंत्रित नेटवर्क पर रहता था। आपके NAS डिवाइस और आपका RADIUS सर्वर एक ही LAN पर थे, या एक समर्पित MPLS सर्किट के माध्यम से जुड़े थे। अटैक सरफेस प्रबंधनीय था। लेकिन दुनिया बदल गई है। क्लाउड-नेटिव इंफ्रास्ट्रक्चर, डिस्ट्रीब्यूटेड वेन्यू डिप्लॉयमेंट, SD-WAN ओवरले और क्लाउड RADIUS सेवाओं में बदलाव ने थ्रेट मॉडल को मौलिक रूप से बदल दिया है। आपका ऑथेंटिकेशन ट्रैफिक अब पब्लिक इंटरनेट से होकर गुजर रहा है, या सबसे अच्छे रूप में, ऐसे शेयर्ड इंफ्रास्ट्रक्चर से जिसे आप पूरी तरह से नियंत्रित नहीं करते हैं। यहीं पर RadSec काम आता है। तकनीकी गहन विश्लेषण। RFC 6614 में औपचारिक रूप से परिभाषित RadSec, RADIUS over TLS है। अवधारणा सीधी है: UDP पर RADIUS पैकेट भेजने के बजाय, आप उन्हें TCP पर एक TLS कनेक्शन के भीतर एनकैप्सुलेट करते हैं। परिणाम यह है कि आपके NAS और आपके RADIUS सर्वर के बीच सभी ऑथेंटिकेशन और अकाउंटिंग ट्रैफिक पूरी तरह से एन्क्रिप्टेड, म्यूचुअली ऑथेंटिकेटेड और इंटीग्रिटी-प्रोटेक्टेड होता है। RFC 7360 इसे DTLS — UDP पर डेटाग्राम TLS — तक विस्तारित करता है, जो एन्क्रिप्शन जोड़ते हुए मूल UDP ट्रांसपोर्ट की कुछ लेटेंसी विशेषताओं को सुरक्षित रखता है। अधिकांश एंटरप्राइज डिप्लॉयमेंट के लिए, TCP पर TLS सही विकल्प है। बड़े स्टेडियम डिप्लॉयमेंट जैसे हाई-थ्रूपुट, लेटेंसी-सेंसिटिव वातावरण में DTLS पर विचार करना उचित है। आइए मैकेनिक्स के बारे में बात करते हैं। RadSec TCP पोर्ट 2083 पर काम करता है, जो इस प्रोटोकॉल के लिए IANA-असाइन किया गया पोर्ट है। जब कोई NAS डिवाइस RadSec कनेक्शन शुरू करता है, तो यह पोर्ट 2083 पर RADIUS सर्वर के लिए एक TCP कनेक्शन खोलता है और एक TLS हैंडशेक करता है। यह हैंडशेक म्यूचुअल होता है — क्लाइंट, यानी आपका NAS, और सर्वर दोनों X.509 सर्टिफिकेट प्रस्तुत करते हैं। सर्वर के सर्टिफिकेट को एक विश्वसनीय CA के खिलाफ वैलिडेट किया जाता है। क्लाइंट सर्टिफिकेट RADIUS सर्वर पर NAS की पहचान करता है। एक बार TLS सेशन स्थापित हो जाने के बाद, RADIUS पैकेट उस एन्क्रिप्टेड टनल के भीतर ठीक उसी तरह प्रवाहित होते हैं जैसे वे UDP पर होते, लेकिन अब पूर्ण गोपनीयता, अखंडता और रीप्ले सुरक्षा के साथ। यह तीन महत्वपूर्ण तरीकों से पारंपरिक RADIUS से एक महत्वपूर्ण बदलाव है। पहला, ट्रांसपोर्ट TCP है, UDP नहीं। इसका मतलब है कि आपको विश्वसनीय, क्रमित डिलीवरी मिलती है। खोए हुए पैकेट स्वचालित रूप से रीट्रांसमिट हो जाते हैं। दूसरा, दोनों एंडपॉइंट्स का ऑथेंटिकेशन सर्टिफिकेट-आधारित है, शेयर्ड-सीक्रेट-आधारित नहीं। यह कमजोर या समझौता किए गए शेयर्ड सीक्रेट्स पर आधारित हमलों के एक पूरे वर्ग को समाप्त करता है। तीसरा, पूरा RADIUS पैकेट एन्क्रिप्टेड होता, न कि केवल पासवर्ड एट्रिब्यूट। इसका मतलब है कि यूजरनेम, सेशन आइडेंटिफायर्स और सभी RADIUS एट्रिब्यूट्स ट्रांजिट में सुरक्षित हैं। सर्टिफिकेट मैनेजमेंट के दृष्टिकोण से, आपको अपने RADIUS सर्वर और अपने NAS डिवाइस दोनों के लिए सर्टिफिकेट जारी करने और प्रबंधित करने के लिए एक PKI — एक पब्लिक की इंफ्रास्ट्रक्चर — की आवश्यकता होती है। व्यवहार में, अधिकांश क्लाउड RADIUS प्रदाता, जिसमें Purple का क्लाउड-नेटिव ऑथेंटिकेशन इंफ्रास्ट्रक्चर शामिल है, आपके लिए सर्वर-साइड सर्टिफिकेट मैनेजमेंट संभालते हैं। आपकी जिम्मेदारी आपके NAS डिवाइसेज को क्लाइंट सर्टिफिकेट प्रोविजन करने की है। बड़े पैमाने पर डिप्लॉयमेंट के लिए, इसे आमतौर पर आपके नेटवर्क मैनेजमेंट प्लेटफॉर्म या एक समर्पित सर्टिफिकेट मैनेजमेंट सिस्टम के माध्यम से संभाला जाता है। सर्टिफिकेट में कम से कम RSA 2048-बिट या ECDSA P-256 का उपयोग होना चाहिए, जिसकी वैधता अवधि परिचालन ओवरहेड को सुरक्षा स्वच्छता के खिलाफ संतुलित करती है — बारह महीने एक उचित डिफॉल्ट है। अब, आइए उस वैकल्पिक दृष्टिकोण के साथ तुलना को संबोधित करें जिसका उपयोग आज कई संगठन करते हैं: RADIUS ट्रैफिक की सुरक्षा के लिए IPsec टनल या VPN ओवरले। IPsec पूरी तरह से वैध दृष्टिकोण है, लेकिन यह एक अलग लेयर पर काम करता है। आप दो एंडपॉइंट्स के बीच सभी ट्रैफिक को एन्क्रिप्ट कर रहे हैं, जो जटिलता जोड़ता है — आपको टनल के लिए IKE, प्री-शेयर्ड कीज़ या सर्टिफिकेट को प्रबंधित करने की आवश्यकता होती है, और संभावित रूप से सैकड़ों साइटों पर टनल स्टेट को बनाए रखने का परिचालन ओवरहेड होता है। RadSec अधिक सर्जिकल है। यह विशेष रूप से RADIUS प्रोटोकॉल ट्रैफिक को एन्क्रिप्ट करता है, एप्लीकेशन लेयर पर काम करता है, और सीधे आपके RADIUS इंफ्रास्ट्रक्चर के साथ इंटीग्रेट होता है। क्लाउड RADIUS डिप्लॉयमेंट के लिए जहां आप डिस्ट्रीब्यूटेड वेन्यू पर कई NAS डिवाइसेज को एक सेंट्रलाइज्ड क्लाउड सर्वर से जोड़ रहे हैं, RadSec आर्किटेक्चरल रूप से अधिक साफ-सुथरा और परिचालन रूप से सरल है। मुझे आपको यह समझाने दें कि व्यवहार में मल्टी-साइट डिप्लॉयमेंट कैसा दिखता है। आपके पास एक क्लाउड RADIUS सर्वर है — मान लें कि यह Purple का प्लेटफॉर्म है — जिसके पास एक विश्वसनीय CA से वैध TLS सर्टिफिकेट है। आपके पास तीन वेन्यू प्रकार हैं: एक होटल प्रॉपर्टी, एक रिटेल स्टोर और एक कॉन्फ्रेंस सेंटर। प्रत्येक में NAS डिवाइस हैं — एक्सेस पॉइंट्स, स्विच या वायरलेस LAN कंट्रोलर। प्रत्येक NAS डिवाइस को RadSec सर्वर एड्रेस, पोर्ट 2083 और एक क्लाइंट सर्टिफिकेट के साथ कॉन्फ़िगर किया जाना चाहिए। NAS, TLS कनेक्शन शुरू करता है, म्यूचुअल हैंडशेक पूरा होता है, और उस बिंदु से आगे, उस वेन्यू पर मेहमानों और कर्मचारियों के लिए सभी 802.1X ऑथेंटिकेशन ट्रैफिक क्लाउड RADIUS सर्वर पर एन्क्रिप्टेड प्रवाहित होता है। यदि TLS कनेक्शन टूट जाता है — मान लें, नेटवर्क व्यवधान के कारण — तो NAS इसे स्वचालित रूप से फिर से स्थापित करता है। यह पर्सिस्टेंट कनेक्शन मॉडल वास्तव में हाई-वॉल्यूम डिप्लॉयमेंट के लिए UDP की तुलना में अधिक कुशल है क्योंकि आप प्रति-पैकेट प्रोसेसिंग के ओवरहेड से बचते हैं। फ़ायरवॉल की तरफ, आपको अपने NAS मैनेजमेंट नेटवर्क से अपने RADIUS सर्वर के IP एड्रेस या FQDN पर पोर्ट 2083 पर आउटबाउंड TCP की अनुमति देनी होगी। यदि आप एक सख्त इग्रेस पॉलिसी चला रहे हैं, तो आप रिटर्न ट्रैफिक की भी अनुमति देना चाहेंगे। यह IPsec फ़ायरवॉल नियमों को प्रबंधित करने की तुलना में सरल है, जिसके लिए अक्सर UDP 500 और 4500 पर ESP प्रोटोकॉल अपवादों और IKE की आवश्यकता होती है। कार्यान्वयन सिफारिशें और नुकसान। आइए बात करते हैं कि RadSec डिप्लॉयमेंट में वास्तव में क्या गलत होता है, क्योंकि कुछ लगातार विफलता मोड हैं जो मैं संगठनों में देखता हूं। पहली और सबसे आम समस्या सर्टिफिकेट चेन वैलिडेशन विफलताएं हैं। आपके NAS डिवाइस को उस CA पर भरोसा करने की आवश्यकता है जिसने RADIUS सर्वर के सर्टिफिकेट पर हस्ताक्षर किए हैं। यदि आप एक प्रसिद्ध सार्वजनिक CA — DigiCert, Let's Encrypt, Sectigo — के सर्टिफिकेट के साथ क्लाउड RADIUS प्रदाता का उपयोग कर रहे हैं, तो अधिकांश आधुनिक NAS डिवाइस आउट ऑफ द बॉक्स इस पर भरोसा करेंगे। लेकिन यदि आप एक आंतरिक CA का उपयोग कर रहे हैं, तो आपको प्रत्येक NAS डिवाइस पर CA सर्टिफिकेट पुश करना होगा। प्रारंभिक डिप्लॉयमेंट के दौरान अक्सर इसकी अनदेखी की जाती है और यह TLS हैंडशेक विफलताओं के रूप में सामने आता है जो कनेक्टिविटी समस्याओं की तरह दिखती हैं। दूसरा नुकसान सर्टिफिकेट की समाप्ति (expiry) है। शेयर्ड सीक्रेट्स के विपरीत, जो समाप्त नहीं होते हैं, सर्टिफिकेट की एक निश्चित वैधता अवधि होती है। यदि आपका RADIUS सर्वर सर्टिफिकेट समाप्त हो जाता है, तो आपके एस्टेट का प्रत्येक NAS डिवाइस एक साथ ऑथेंटिकेट करने में विफल हो जाएगा। आपको सर्टिफिकेट लाइफसाइकिल मैनेजमेंट की आवश्यकता है — जहां संभव हो स्वचालित रिन्यूअल, और समाप्ति से काफी पहले अलर्ट के साथ निगरानी। नब्बे दिन का नोटिस न्यूनतम है; तीस दिन बेहतर है। तीसरी समस्या NAS डिवाइस कम्पैटिबिलिटी है। सभी NAS डिवाइस मूल रूप से RadSec का समर्थन नहीं करते हैं। पुराने Cisco IOS संस्करण, कुछ लेगेसी Aruba कंट्रोलर और कुछ उपभोक्ता-ग्रेड एक्सेस पॉइंट्स में RadSec समर्थन नहीं है। RadSec डिप्लॉयमेंट के लिए प्रतिबद्ध होने से पहले, कम्पैटिबिलिटी के लिए अपने NAS एस्टेट का ऑडिट करें। Cisco IOS-XE 16.x और बाद के संस्करण, Aruba AOS-CX, Ruckus SmartZone और Juniper EX श्रृंखला सभी में ठोस RadSec समर्थन है। उन डिवाइसेज के लिए जो मूल रूप से RadSec का समर्थन नहीं करते हैं, एक RadSec प्रॉक्सी — `radsecproxy` जैसा एक ओपन-सोर्स विकल्प — इस अंतर को पाट सकता है, लेगेसी डिवाइसेज से UDP RADIUS स्वीकार कर सकता है और इसे TLS पर क्लाउड RADIUS सर्वर पर फॉरवर्ड कर सकता है। चौथा विचार कनेक्शन पर्सिस्टेंस और कीपअलाइव्स है। RadSec पर्सिस्टेंट TCP कनेक्शन का उपयोग करता, लेकिन आक्रामक टाइमआउट पॉलिसियों वाले फ़ायरवॉल और NAT डिवाइस निष्क्रिय कनेक्शनों को चुपचाप छोड़ सकते हैं। अपने RadSec कनेक्शनों पर TCP कीपअलाइव कॉन्फ़िगर करें — समय से पहले कनेक्शन टूटने से रोकने के लिए आमतौर पर साठ सेकंड का कीपअलाइव अंतराल पर्याप्त होता है। अधिकांश RADIUS सर्वर कार्यान्वयन और NAS डिवाइस इस कॉन्फ़िगरेशन का समर्थन करते हैं। Cisco IOS-XE के लिए, RadSec कॉन्फ़िगरेशन इस तरह दिखता है। आप अपने क्लाउड RADIUS एंडपॉइंट के पते के साथ एक RADIUS सर्वर परिभाषित करते हैं, TLS को ट्रांसपोर्ट के रूप में निर्दिष्ट करते हैं, अपने ट्रस्टपॉइंट को संदर्भित करते हैं — जो डिवाइस पर सर्टिफिकेट स्टोर है — और डेस्टिनेशन पोर्ट को 2083 पर सेट करते हैं। फिर आप अपने AAA सर्वर समूह कॉन्फ़िगरेशन में इस सर्वर को संदर्भित करते हैं। विवरण प्लेटफ़ॉर्म संस्करण के अनुसार भिन्न होते हैं, लेकिन तार्किक संरचना सभी वेंडर्स में सुसंगत है। Aruba कंट्रोलर्स के लिए जो AOS चला रहे हैं, आप RadSec विकल्प सक्षम करके RADIUS सर्वर को कॉन्फ़िगर करते हैं, सर्वर वैलिडेशन के लिए CA सर्टिफिकेट निर्दिष्ट करते हैं, और वैकल्पिक रूप से म्यूचुअल TLS के लिए एक क्लाइंट सर्टिफिकेट कॉन्फ़िगर करते हैं। Aruba का कार्यान्वयन परिपक्व और अच्छी तरह से प्रलेखित है। रैपिड-फायर प्रश्न और उत्तर। आइए उन प्रश्नों पर नज़र डालें जो मुझसे RadSec के बारे में सबसे अक्सर पूछे जाते हैं। क्या RadSec लेटेंसी बढ़ाता है? TLS हैंडशेक प्रारंभिक कनेक्शन स्थापना पर एक छोटा ओवरहेड जोड़ता है — आमतौर पर 100 मिलीसेकंड से कम। एक बार कनेक्शन स्थापित हो जाने के बाद, प्रति-पैकेट ओवरहेड नगण्य होता है। 802.1X ऑथेंटिकेशन के लिए, जहां हैंडशेक प्रति सेशन एक बार होता है, यह कोई महत्वपूर्ण चिंता नहीं है। क्या मैं पारंपरिक UDP RADIUS के साथ RadSec चला सकता हूँ? हाँ। अधिकांश RADIUS सर्वर एक साथ दोनों का समर्थन करते हैं। माइग्रेशन के दौरान, आप उन साइटों के लिए RadSec चला सकते हैं जो इसका समर्थन करती हैं और लेगेसी साइटों के लिए UDP पर वापस जा सकते हैं। यह अनुशंसित माइग्रेशन दृष्टिकोण है। क्या PCI-DSS अनुपालन के लिए RadSec आवश्यक है? PCI-DSS संस्करण 4.0 की आवश्यकता है कि ट्रांजिट में ऑथेंटिकेशन ट्रैफिक सुरक्षित होना चाहिए। RADIUS-आधारित ऑथेंटिकेशन के लिए इस आवश्यकता को पूरा करने के सबसे सीधे तरीकों में से एक RadSec है। यदि आप ऐसे नेटवर्क पर कार्ड भुगतान संसाधित कर रहे हैं जो RADIUS ऑथेंटिकेशन का उपयोग करता है, तो RadSec आपके अनुपालन रोडमैप पर होना चाहिए। क्या RadSec EAP के साथ काम करता है? हाँ। EAP — एक्सटेंसिबल ऑथेंटिकेशन प्रोटोकॉल — RADIUS के भीतर एनकैप्सुलेटेड होता है, इसलिए EAP-TLS, PEAP, EAP-TTLS सभी RadSec पर पारदर्शी रूप से काम करते हैं। EAP एक्सचेंज स्वयं अप्रभावित रहता है। RADIUS अकाउंटिंग के बारे में क्या? RFC 6614 ऑथेंटिकेशन और अकाउंटिंग ट्रैफिक दोनों को कवर करता है। आपका अकाउंटिंग डेटा — सेशन स्टार्ट, स्टॉप और अंतरिम अपडेट रिकॉर्ड — भी पोर्ट 2083 पर उसी TLS कनेक्शन पर एन्क्रिप्टेड होता है। सारांश और अगले कदम। इसे एक साथ लाने के लिए: किसी भी डिप्लॉयमेंट में जहां ऑथेंटिकेशन ट्रैफिक ऐसे इंफ्रास्ट्रक्चर को पार करता है जिसे आप पूरी तरह से नियंत्रित नहीं करते हैं, RADIUS के लिए RadSec सही ट्रांसपोर्ट लेयर है। इसका मतलब है क्लाउड RADIUS, वहु-साइट डिप्लॉयमेंट, SD-WAN वातावरण, और कोई भी परिदृश्य जहां RADIUS ट्रैफिक पब्लिक इंटरनेट या शेयर्ड कैरियर इंफ्रास्ट्रक्चर से होकर गुजरता है। आपकी टीम के लिए मुख्य कार्य हैं: पहला, RadSec कम्पैटिबिलिटी के लिए अपने NAS एस्टेट का ऑडिट करें और उन डिवाइसेज की पहचान करें जिन्हें प्रॉक्सी की आवश्यकता होगी। दूसरा, अपने क्लाउड RADIUS प्रदाता से संपर्क करें — या उन प्रदाताओं का मूल्यांकन करें जो मूल रूप से RadSec का समर्थन करते हैं — और उनके सर्टिफिकेट मैनेजमेंट दृष्टिकोण को समझें। तीसरा, लाइव होने से पहले एक सर्टिफिकेट लाइफसाइकिल मैनेजमेंट प्रक्रिया स्थापित करें। चौथा, अपने NAS मैनेजमेंट नेटवर्क से आउटबाउंड TCP 2083 की अनुमति देने के लिए अपने फ़ायरवॉल नियमों को अपडेट करें। पांचवां, प्रोडक्शन में रोल आउट करने से पहले एक स्टेजिंग वातावरण में अपने RadSec कॉन्फ़िगरेशन का परीक्षण करें, लोड के तहत सर्टिफिकेट चेन वैलिडेशन और कनेक्शन पर्सिस्टेंस पर विशेष ध्यान दें। डिस्ट्रीब्यूटेड वेन्यू पर गेस्ट WiFi और ऑथेंटिकेशन के लिए Purple के प्लेटफॉर्म को चलाने वाले संगठनों के लिए, क्लाउड RADIUS कनेक्टिविटी के लिए RadSec अनुशंसित ट्रांसपोर्ट है। यह Purple के क्लाउड-नेटिव आर्किटेक्चर के साथ संरेखित है और यह सुनिश्चित करता है कि आपके वेन्यू और प्लेटफॉर्म के बीच बहने वाला ऑथेंटिकेशन डेटा पूरी तरह से सुरक्षित है — जो आपकी सुरक्षा स्थिति और GDPR और PCI-DSS के तहत आपके अनुपालन दायित्वों दोनों के लिए मायने रखता है। यदि आप डिप्लॉयमेंट की योजना बना रहे हैं या अपने विशिष्ट आर्किटेक्चर पर चर्चा करना चाहते हैं, तो Purple टीम सही शुरुआती बिंदु है। यह RadSec पर एक Purple टेक्निकल ब्रीफिंग थी। सुनने के लिए धन्यवाद।