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

RadSec: TLS के साथ RADIUS ऑथेंटिकेशन ट्रैफ़िक को सुरक्षित करना। एक Purple तकनीकी ब्रीफिंग। परिचय और संदर्भ। इस Purple तकनीकी ब्रीफिंग में स्वागत है। मैं आपको RadSec — TLS पर RADIUS — के बारे में बताऊंगा कि यह क्या है, यह अभी क्यों महत्वपूर्ण है, और आप इसे वास्तव में कैसे डिप्लॉय करते हैं। यह सीधे तौर पर उन नेटवर्क आर्किटेक्ट्स और सुरक्षा इंजीनियरों के लिए है जो या तो आज क्लाउड RADIUS चला रहे हैं या वहां जाने की योजना बना रहे हैं। यदि आप अभी भी UDP और एक साझा रहस्य (shared secret) के साथ ऑन-प्रिमाइसेस RADIUS सर्वर चला रहे हैं, तो यह ब्रीफिंग आपके लिए है। आइए पृष्ठभूमि तैयार करें। RADIUS तीस से अधिक वर्षों से नेटवर्क ऑथेंटिकेशन की रीढ़ रहा है। यह 802.1X, WPA2-Enterprise, WPA3-Enterprise और आज प्रोडक्शन में लगभग हर कैप्टिव पोर्टल सिस्टम का आधार है। RFC 2865 में परिभाषित यह प्रोटोकॉल खुद एक ऐसे युग में डिज़ाइन किया गया था जब इंटरनेट एक बहुत ही अलग जगह थी। आपके NAS उपकरणों — आपके एक्सेस पॉइंट, स्विच और नियंत्रकों — और आपके RADIUS सर्वर के बीच ऑथेंटिकेशन ट्रैफ़िक UDP पर चलता था, ऑथेंटिकेशन के लिए पोर्ट 1812, अकाउंटिंग के लिए पोर्ट 1813। और वह ट्रैफ़िक? काफी हद तक अनएन्क्रिप्टेड। एकमात्र सुरक्षा एक साझा रहस्य (shared secret) था जिसका उपयोग उपयोगकर्ता पासवर्ड एट्रिब्यूट को अस्पष्ट करने के लिए किया जाता था, और यहाँ तक कि उसकी भी अच्छी तरह से प्रलेखित कमजोरियाँ हैं। वर्षों तक, यह स्वीकार्य था क्योंकि RADIUS ट्रैफ़िक निजी, नियंत्रित नेटवर्क पर रहता था। आपके NAS डिवाइस और आपका RADIUS सर्वर एक ही LAN पर थे, या एक समर्पित MPLS सर्किट के माध्यम से जुड़े हुए थे। अटैक सरफेस प्रबंधनीय था। लेकिन दुनिया बदल गई है। क्लाउड-नेटिव इंफ्रास्ट्रक्चर, वितरित स्थान डिप्लॉयमेंट, SD-WAN ओवरले और क्लाउड RADIUS सेवाओं में बदलाव ने थ्रेट मॉडल को मौलिक रूप से बदल दिया है। आपका ऑथेंटिकेशन ट्रैफ़िक अब सार्वजनिक इंटरनेट, या सबसे अच्छे रूप में, साझा इंफ्रास्ट्रक्चर से होकर गुजर रहा है जिसे आप पूरी तरह से नियंत्रित नहीं करते हैं। यहीं पर RadSec काम आता है। तकनीकी गहन विश्लेषण। औपचारिक रूप से RFC 6614 में परिभाषित RadSec, TLS पर RADIUS है। अवधारणा सीधी है: UDP पर RADIUS पैकेट भेजने के बजाय, आप उन्हें TCP पर TLS कनेक्शन के भीतर एनकैप्सुलेट करते हैं। इसका परिणाम यह है कि आपके NAS और आपके RADIUS सर्वर के बीच सभी ऑथेंटिकेशन और अकाउंटिंग ट्रैफ़िक पूरी तरह से एन्क्रिप्टेड, पारस्परिक रूप से ऑथेंटिकेटेड और अखंडता-संरक्षित (integrity-protected) होते हैं। RFC 7360 इसे DTLS — UDP पर डेटाग्राम TLS — तक विस्तारित करता है, जो एन्क्रिप्शन जोड़ते हुए मूल UDP ट्रांसपोर्ट की कुछ विलंबता (latency) विशेषताओं को सुरक्षित रखता है। अधिकांश एंटरप्राइज़ डिप्लॉयमेंट के लिए, TCP पर TLS सही विकल्प है। बड़े स्टेडियम डिप्लॉयमेंट जैसे उच्च-थ्रूपुट, विलंबता-संवेदनशील वातावरण में DTLS पर विचार करना उचित है। आइए यांत्रिकी (mechanics) के बारे में बात करते हैं। RadSec TCP पोर्ट 2083 पर काम करता है, जो इस प्रोटोकॉल के लिए IANA-असाइन किया गया पोर्ट है। जब कोई NAS डिवाइस RadSec कनेक्शन शुरू करता है, तो यह पोर्ट 2083 पर RADIUS सर्वर के लिए एक TCP कनेक्शन खोलता है और एक TLS हैंडशेक करता है। यह हैंडशेक पारस्परिक होता है — क्लाइंट, यानी आपका NAS, और सर्वर दोनों X.509 सर्टिफिकेट प्रस्तुत करते हैं। सर्वर के सर्टिफिकेट को एक विश्वसनीय CA के खिलाफ सत्यापित किया जाता है। क्लाइंट सर्टिफिकेट RADIUS सर्वर पर NAS की पहचान करता है। एक बार TLS सेशन स्थापित हो जाने के बाद, RADIUS पैकेट उस एन्क्रिप्टेड टनल के भीतर बिल्कुल वैसे ही प्रवाहित होते हैं जैसे वे UDP पर होते, लेकिन अब पूर्ण गोपनीयता, अखंडता और रीप्ले सुरक्षा के साथ। यह तीन महत्वपूर्ण तरीकों से पारंपरिक RADIUS से एक महत्वपूर्ण बदलाव है। पहला, ट्रांसपोर्ट TCP है, UDP नहीं। इसका मतलब है कि आपको विश्वसनीय, क्रमित डिलीवरी मिलती है। खोए हुए पैकेट स्वचालित रूप से पुन: प्रेषित (retransmit) हो जाते हैं। दूसरा, दोनों एंडपॉइंट्स का ऑथेंटिकेशन सर्टिफिकेट-आधारित है, साझा-रहस्य-आधारित नहीं। यह कमजोर या समझौता किए गए साझा रहस्यों पर आधारित हमलों के एक पूरे वर्ग को समाप्त करता है। तीसरा, पूरा RADIUS पैकेट एन्क्रिप्टेड होता है, न कि केवल पासवर्ड एट्रिब्यूट। इसका मतलब है कि उपयोगकर्ता नाम, सेशन आइडेंटिफ़ायर और सभी RADIUS एट्रिब्यूट ट्रांज़िट में सुरक्षित हैं। सर्टिफिकेट प्रबंधन के दृष्टिकोण से, आपको अपने RADIUS सर्वर और अपने NAS उपकरणों दोनों के लिए सर्टिफिकेट जारी करने और प्रबंधित करने के लिए एक PKI — एक पब्लिक की इंफ्रास्ट्रक्चर — की आवश्यकता होती है। व्यवहार में, अधिकांश क्लाउड RADIUS प्रदाता, जिसमें Purple का क्लाउड-नेटिव ऑथेंटिकेशन इंफ्रास्ट्रक्चर शामिल है, आपके लिए सर्वर-साइड सर्टिफिकेट प्रबंधन को संभालते हैं। आपकी जिम्मेदारी आपके NAS उपकरणों के लिए क्लाइंट सर्टिफिकेट का प्रावधान (provisioning) करना है। बड़े पैमाने पर डिप्लॉयमेंट के लिए, इसे आमतौर पर आपके नेटवर्क प्रबंधन प्लेटफ़ॉर्म या एक समर्पित सर्टिफिकेट प्रबंधन प्रणाली के माध्यम से संभाला जाता है। सर्टिफिकेट में न्यूनतम के रूप में RSA 2048-बिट या ECDSA P-256 का उपयोग होना चाहिए, वैधता अवधि के साथ जो सुरक्षा स्वच्छता के खिलाफ परिचालन ओवरहेड को संतुलित करती है — बारह महीने एक उचित डिफ़ॉल्ट है। अब, आइए उस वैकल्पिक दृष्टिकोण के साथ तुलना करें जिसका उपयोग आज कई संगठन करते हैं: RADIUS ट्रैफ़िक की सुरक्षा के लिए IPsec टनल या VPN ओवरले। IPsec एक पूरी तरह से वैध दृष्टिकोण है, लेकिन यह एक अलग लेयर पर काम करता है। आप दो एंडपॉइंट्स के बीच सभी ट्रैफ़िक को एन्क्रिप्ट कर रहे हैं, जो जटिलता जोड़ता है — आपको टनल के लिए ही IKE, प्री-शेयर्ड कीज़ या सर्टिफिकेट प्रबंधित करने की आवश्यकता होती है, और संभावित रूप से सैकड़ों साइटों पर टनल स्थिति बनाए रखने का परिचालन ओवरहेड होता है। RadSec अधिक सटीक (surgical) है। यह विशेष रूप से 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 हैंडशेक विफलताओं के रूप में सामने आता है जो कनेक्टिविटी समस्याओं की तरह दिखती हैं। दूसरा नुकसान सर्टिफिकेट की समाप्ति है। साझा रहस्यों के विपरीत, जो समाप्त नहीं होते हैं, सर्टिफिकेट की एक निश्चित वैधता अवधि होती है। यदि आपके RADIUS सर्वर का सर्टिफिकेट समाप्त हो जाता है, तो आपके परिसर का प्रत्येक NAS डिवाइस एक साथ ऑथेंटिकेट करने में विफल हो जाएगा। आपको सर्टिफिकेट लाइफसाइकिल मैनेजमेंट की आवश्यकता है — जहां संभव हो स्वचालित रिन्यूअल, और समाप्ति से काफी पहले अलर्ट के साथ निगरानी। नब्बे दिन का नोटिस न्यूनतम है; तीस दिन बेहतर है। तीसरी समस्या NAS डिवाइस अनुकूलता (compatibility) है। सभी 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 सर्वर समूह कॉन्फ़िगरेशन में इस सर्वर को संदर्भित करते हैं। विशिष्टताएं प्लेटफ़ॉर्म संस्करण के अनुसार भिन्न होती हैं, लेकिन तार्किक संरचना सभी वेंडरों में सुसंगत है। AOS चलाने वाले Aruba नियंत्रकों के लिए, आप RadSec विकल्प सक्षम करके RADIUS सर्वर को कॉन्फ़िगर करते हैं, सर्वर सत्यापन के लिए CA सर्टिफिकेट निर्दिष्ट करते हैं, और वैकल्पिक रूप से पारस्परिक TLS के लिए एक क्लाइंट सर्टिफिकेट कॉन्फ़िगर करते हैं। Aruba का कार्यान्वयन परिपक्व और अच्छी तरह से प्रलेखित है। त्वरित प्रश्न और उत्तर। आइए मैं उन प्रश्नों पर नज़र डालूँ जो मुझसे RadSec के बारे में सबसे अधिक पूछे जाते हैं। क्या RadSec विलंबता (latency) जोड़ता है? 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 कनेक्शन पर एन्क्रिप्टेड होता है। सारांश और अगले कदम। इसे एक साथ लाने के लिए: RadSec किसी भी ऐसे डिप्लॉयमेंट में RADIUS के लिए सही ट्रांसपोर्ट लेयर है जहाँ ऑथेंटिकेशन ट्रैफ़िक उस इंफ्रास्ट्रक्चर को पार करता है जिसे आप पूरी तरह से नियंत्रित नहीं करते हैं। इसका मतलब है क्लाउड RADIUS, मल्टी-साइट डिप्लॉयमेंट, SD-WAN वातावरण, और कोई भी परिदृश्य जहाँ RADIUS ट्रैफ़िक सार्वजनिक इंटरनेट या साझा वाहक (carrier) इंफ्रास्ट्रक्चर से होकर गुजरता है। आपकी टीम के लिए मुख्य कार्य हैं: पहला, RadSec अनुकूलता के लिए अपने NAS परिसरों का ऑडिट करें और उन उपकरणों की पहचान करें जिन्हें प्रॉक्सी की आवश्यकता होगी। दूसरा, अपने क्लाउड RADIUS प्रदाता से जुड़ें — या उन प्रदाताओं का मूल्यांकन करें जो मूल रूप से RadSec का समर्थन करते हैं — और उनके सर्टिफिकेट प्रबंधन दृष्टिकोण को समझें। तीसरा, लाइव होने से पहले एक सर्टिफिकेट लाइफसाइकिल मैनेजमेंट प्रक्रिया स्थापित करें। चौथा, अपने NAS प्रबंधन नेटवर्क से आउटबाउंड TCP 2083 की अनुमति देने के लिए अपने फ़ायरवॉल नियमों को अपडेट करें। पांचवां, प्रोडक्शन में रोल आउट करने से पहले एक स्टेजिंग वातावरण में अपने RadSec कॉन्फ़िगरेशन का परीक्षण करें, लोड के तहत सर्टिफिकेट चेन सत्यापन और कनेक्शन की निरंतरता पर विशेष ध्यान दें। वितरित स्थानों पर अतिथि WiFi और ऑथेंटिकेशन के लिए Purple के प्लेटफ़ॉर्म को चलाने वाले संगठनों के लिए, क्लाउड RADIUS कनेक्टिविटी के लिए RadSec अनुशंसित ट्रांसपोर्ट है। यह Purple के क्लाउड-नेटिव आर्किटेक्चर के साथ संरेखित है और यह सुनिश्चित करता है कि आपके स्थानों और प्लेटफ़ॉर्म के बीच बहने वाला ऑथेंटिकेशन डेटा पूरी तरह से सुरक्षित है — जो आपकी सुरक्षा स्थिति और GDPR और PCI-DSS के तहत आपके अनुपालन दायित्वों दोनों के लिए महत्वपूर्ण है। यदि आप डिप्लॉयमेंट की योजना बना रहे हैं या अपने विशिष्ट आर्किटेक्चर पर चर्चा करना चाहते हैं, तो Purple टीम सही शुरुआती बिंदु है। यह RadSec पर एक Purple तकनीकी ब्रीफिंग रही है। सुनने के लिए धन्यवाद।