802.1X Supplicant म्हणजे काय? क्लायंटचे प्रकार आणि डिव्हाइस कॉन्फिगरेशन

आत्मविश्वासपूर्ण, अधिकृत आणि संवादात्मक टोनमध्ये ब्रिटिश इंग्रजीत बोला - जसे की एखादे वरिष्ठ नेटवर्क सुरक्षा सल्लागार क्लायंटला माहिती देत आहेत. मोजलेला वेग, स्पष्ट शब्दरचना, व्यावसायिक परंतु कोरडे नसलेले. आवश्यकतेनुसार नैसर्गिक विराम घ्या: Purple च्या तांत्रिक माहिती मालिकेमध्ये आपले स्वागत आहे. आज आपण अशा एका विषयावर बोलणार आहोत जो थेट एंटरप्राइझ WiFi सुरक्षेच्या केंद्रस्थानी आहे - 802.1X सप्लिकंट (supplicant). जर तुम्हाला कधीही प्रश्न पडला असेल की काही उपकरणे कोणत्याही पासवर्डच्या प्रॉम्प्टशिवाय तुमच्या कॉर्पोरेट नेटवर्कशी कशी जोडली जातात, तर इतर उपकरणांवर सर्टिफिकेट एरर आणि हेल्पडेस्क तिकीट का तयार होतात, तर हा भाग तुमच्यासाठीच आहे. [medium pause] चला मूलभूत गोष्टींपासून सुरुवात करूया. 802.1X सप्लिकंट हा क्लायंट डिव्हाइसवरील - लॅपटॉप, स्मार्टफोन, टॅबलेट - एक सॉफ्टवेअर घटक आहे, जो IEEE 802.1X द्वारे सुरक्षित असलेल्या नेटवर्कमध्ये सामील होण्याचा प्रयत्न करताना ऑथेंटिकेशन हँडशेक हाताळतो. याला डिव्हाइसचे आयडी कार्ड सादरकर्ता समजा. नेटवर्क कोणालाही थेट प्रवेश देत नाही. ते क्रेडेंशियल्सची मागणी करते. सप्लिकंट हाच तो घटक आहे जो पुढे येतो आणि सांगतो: मी कोण आहे ते हे आहे, हे माझे सर्टिफिकेट आहे, मला प्रवेश द्या. हा मानक स्वतः - IEEE 802.1X - पोर्ट-आधारित नेटवर्क प्रवेश नियंत्रण परिभाषित करतो. ऑथेंटिकेशन यशस्वी होण्यापूर्वी, ॲक्सेस पॉइंट किंवा स्विच केवळ अतिशय मर्यादित प्रकारच्या ट्रॅफिकला अनुमती देतो: EAPOL फ्रेम्स, ज्याचा अर्थ Extensible Authentication Protocol over LAN असा आहे. इतर सर्व काही ब्लॉक केले जाते. एकदा सप्लिकंटने ऑथेंटिकेटरद्वारे RADIUS सर्व्हरकडे आपली ओळख सिद्ध केली की, पोर्ट उघडतो आणि सामान्य ट्रॅफिक सुरू होतो. [medium pause] आता, या प्रक्रियेत तीन मुख्य घटक आहेत. पहिला, सप्लिकंट - म्हणजेच क्लायंट डिव्हाइस. दुसरा, ऑथेंटिकेटर - तुमचा ॲक्सेस पॉइंट किंवा स्विच, जसे की Cisco Meraki, HPE Aruba, Ruckus, किंवा Juniper Mist सारखे हार्डवेअर. तिसरा, ऑथेंटिकेशन सर्व्हर - जो बहुधा एक RADIUS सर्व्हर असतो, जो Microsoft Entra ID किंवा Okta सारख्या डिरेक्टरीच्या विरूद्ध क्रेडेंशियल्सची पडताळणी करतो. सप्लिकंट EAPOL-Start मेसेज पाठवून प्रक्रिया सुरू करतो. ऑथेंटिकेटर ओळखीसाठी EAP-Request ने प्रतिसाद देतो. सप्लिकंट त्याच्या ओळखीसह उत्तर देतो. ती ओळख RADIUS सर्व्हरकडे पाठवली जाते, जो नंतर मान्य केलेल्या EAP पद्धतीने सप्लिकंटला चॅलेंज करतो. जर सर्व काही व्यवस्थित असेल, तर RADIUS सर्व्हर Access-Accept पाठवतो, पोर्ट उघडतो आणि डिव्हाइस योग्य VLAN वर ठेवले जाते. [medium pause] चला EAP पद्धतींबद्दल बोलूया, कारण याच ठिकाणी बहुतेक डिप्लॉयमेंटचे निर्णय घेतले जातात. EAP-TLS - म्हणजेच Extensible Authentication Protocol with Transport Layer Security - हे एक सुवर्ण मानक आहे. यासाठी क्लायंट आणि सर्व्हर दोन्हीकडे प्रमाणपत्रे सादर करणे आवश्यक असते. परस्पर प्रमाणीकरण. कोणतेही पासवर्ड नाही. क्लायंट प्रमाणपत्र डिव्हाइसची ओळख सिद्ध करते; सर्व्हर प्रमाणपत्र नेटवर्क वैध असल्याचे सिद्ध करते, ज्यामुळे इव्हिल ट्विन हल्ल्यांपासून (evil twin attacks) संरक्षण होते जेथे बनावट ॲक्सेस पॉइंट क्रेडेंशियल्स चोरण्याचा प्रयत्न करतो. EAP-TLS बारा स्टेप्समध्ये पूर्ण होते आणि संपूर्ण प्रक्रियेत पब्लिक-प्रायव्हेट की क्रिप्टोग्राफीचा वापर करते. WPA3-Enterprise च्या सर्वोच्च सुरक्षा मोडमध्ये हीच पद्धत आवश्यक आहे, आणि ती डिव्हाइस ओळख पडताळणीसाठी NIST SP 800-171 च्या आवश्यकतांशी सुसंगत आहे. PEAP - Protected EAP - हा अशा संस्थांसाठी अधिक सामान्य सुरुवातीचा बिंदू आहे ज्यांच्याकडे अद्याप पूर्ण PKI उपलब्ध नाही. PEAP हे पासवर्ड-आधारित आतील पद्धत, विशेषतः MSCHAPv2 ला TLS टनेलमध्ये गुंडाळते. सर्व्हर प्रमाणपत्र सादर करतो; क्लायंट करत नाही. याचा अर्थ डिप्लॉयमेंट सोपे आहे - तुम्हाला क्लायंट प्रमाणपत्रे प्रदान करण्याची आवश्यकता नाही - परंतु ते कमी सुरक्षित आहे. MSCHAPv2 हे MD4 हॅशिंग वापरते, जे 1995 पासून असुरक्षित मानले गेले आहे. जर एखादा युझर विश्वासार्ह वाटणारे प्रमाणपत्र सादर करणाऱ्या बनावट ॲक्सेस पॉइंटशी कनेक्ट झाला, तर त्यांचे क्रेडेंशियल्स चोरले जाऊ शकतात. म्हणूनच PEAP चालवताना क्लायंटच्या बाजूने सर्व्हर प्रमाणपत्र प्रमाणीकरण करणे अत्यंत अनिवार्य आहे. [medium pause] आता आपण सप्लिकंट (supplicant) कडे वळूयात - विशेषतः मूळ OS सप्लिकंट्स आणि थर्ड-पार्टी क्लायंट सॉफ्टवेअर यामधील निवड. प्रत्येक प्रमुख ऑपरेटिंग सिस्टम अंगभूत 802.1X सप्लिकंटसह येते. Windows ने XP पासून, Wireless AutoConfig आणि Wired AutoConfig सर्व्हिसेसद्वारे याला मूळतः सपोर्ट केला आहे. macOS आणि iOS त्यांच्या नेटवर्क कॉन्फिगरेशन प्रोफाइल्सद्वारे 802.1X हाताळतात. Android त्याच्या WiFi सेटिंग्ज पॅनेलद्वारे याला सपोर्ट करते. हे मूळ सप्लिकंट्स सध्याच्या सर्व प्लॅटफॉर्मवर EAP-TLS आणि PEAP-MSCHAPv2 कव्हर करतात. मूळ सप्लिकंट्सचा फायदा उघड आहे: डिप्लॉय करण्यासाठी कोणतेही अतिरिक्त सॉफ्टवेअर नाही, कोणताही परवाना खर्च नाही, स्वयंचलित OS सुरक्षा अपडेट्स आणि ऑपरेटिंग सिस्टमच्या प्रमाणपत्र स्टोअरसह घट्ट एकत्रीकरण. व्यवस्थापित (managed) डिव्हाइस ताफ्यांसाठी - Microsoft Intune मध्ये नोंदणीकृत Windows मशिन्स, Jamf द्वारे व्यवस्थापित केलेले Macs - तुम्ही MDM द्वारे 802.1X कॉन्फिगरेशन प्रोफाइल्स गुप्तपणे पुश करू शकता आणि युझर्सना कोणतीही सूचना दिसत नाही. प्रत्येक वेळी डिव्हाइस रेंजमध्ये आल्यावर आपोआप प्रमाणीकृत होते. विशिष्ट परिस्थितींमध्ये थर्ड-पार्टी सप्लिकंट्स (supplicants) उपयोगी पडतात. जर तुम्ही Cisco इन्फ्रास्ट्रक्चर वापरत असाल आणि तुम्हाला EAP-FAST - Cisco ची प्रोप्रायटरी EAP पद्धत - वापरायची असेल, तर तुम्हाला Cisco च्या क्लायंट सॉफ्टवेअरची आवश्यकता असेल, जे ऐतिहासिकदृष्ट्या Secure Services Client किंवा AnyConnect Network Access Manager आहे. जर तुम्हाला मिश्र-OS असलेल्या मालमत्तेमध्ये सुसंगत कॉन्फिगरेशन व्यवस्थापनाची गरज असेल आणि सप्लिकंट सेटिंग्ज लॉक डाऊन करायच्या असतील जेणेकरून वापरकर्ते चुकून त्या चुकीच्या पद्धतीने कॉन्फिगर करणार नाहीत, तर थर्ड-पार्टी क्लायंट तुम्हाला ते नियंत्रण देतो. SecureW2 च्या JoinNow सूट सारखी टूल्स ऑनबोर्डिंग एजंट्स म्हणून देखील काम करतात - ते नेटिव्ह सप्लिकंट बदलण्याऐवजी कॉन्फिगर करतात आणि वापरकर्त्यांना प्रमाणपत्र नोंदणी आणि प्रोफाइल इन्स्टॉलेशनच्या प्रक्रियेत मदत करतात. [medium pause] हे प्रत्यक्ष स्वरूपात समजून घेण्यासाठी मी तुम्हाला दोन वास्तविक परिस्थितींमधून घेऊन जातो. पहिली, एक ४०० खोल्यांचे हॉटेल. ही मालमत्ता आज PEAP-MSCHAPv2 सह WPA2-Enterprise वर स्टाफ नेटवर्क चालवते. आयटी टीमला पासवर्ड-आधारित ऑथेंटिकेशन पूर्णपणे बंद करण्यासाठी आणि क्रेडेंशियल चोरीचा धोका कमी करण्यासाठी EAP-TLS वर स्थलांतरित करायचे आहे. आव्हान असे आहे: कर्मचाऱ्यांची डिव्हाइसेस ही Intune द्वारे व्यवस्थापित केलेल्या Windows लॅपटॉप्स, प्रॉपर्टी मॅनेजमेंट सॉफ्टवेअरसाठी वापरल्या जाणाऱ्या वैयक्तिक Android फोन्स आणि बॅक-ऑफिसमधील काही जुन्या Windows 7 मशिन्स यांचे मिश्रण आहे. येथे टप्प्याटप्प्याने मार्ग अवलंबला जातो. व्यवस्थापित केलेल्या Windows फ्लिटपासून सुरुवात करा. एक Intune कॉन्फिगरेशन प्रोफाइल पुश करा जे RADIUS सर्व्हरचे रूट CA प्रमाणपत्र इन्स्टॉल करते, WiFi प्रोफाइल EAP-TLS साठी कॉन्फिगर करते आणि अंतर्गत PKI कडून SCEP-आधारित प्रमाणपत्र नोंदणी सुरू करते. ती डिव्हाइसेस पहिल्या दिवसापासून आपोआप ऑथेंटिकेट होतात. Android BYOD डिव्हाइसेससाठी, एक सेल्फ-सर्व्हिस ऑनबोर्डिंग पोर्टल तैनात करा - वापरकर्ते एका URL ला भेट देतात, कॉन्फिगरेशन प्रोफाइल डाउनलोड करतात आणि सप्लिकंट त्यांच्यासाठी कॉन्फिगर केला जातो. जुन्या Windows 7 मशिन्स कडक सर्व्हर प्रमाणपत्र व्हॅलिडेशन लागू करून PEAP वरच राहतात आणि जोपर्यंत त्या वापरातून बाहेर काढल्या जात नाहीत, तोपर्यंत मर्यादित प्रवेशासह एका स्वतंत्र VLAN मध्ये विलग केल्या जातात. [medium pause] दुसरी परिस्थिती: २०० स्टोअर्स असलेली एक मोठी रिटेल साखळी. प्रत्येक स्टोअरमध्ये पॉईंट-ऑफ-सेल (POS) टर्मिनल्स, कर्मचाऱ्यांचे टॅबलेट्स आणि एक गेस्ट WiFi नेटवर्क यांचे मिश्रण आहे. PCI-DSS नुसार कार्डधारक डेटा वातावरण इतर नेटवर्क सेगमेंट्सपासून वेगळे असणे आवश्यक आहे. रिटेलर स्टाफ आणि POS नेटवर्कवर 802.1X वापरतो, ज्यामध्ये VLAN असाइनमेंट प्रमाणपत्र वैशिष्ट्यांद्वारे (certificate attributes) चालवले जाते. एक POS टर्मिनल "POS" च्या संस्थात्मक युनिटसह डिव्हाइस प्रमाणपत्र सादर करते - RADIUS पॉलिसी त्याला PCI VLAN मध्ये नियुक्त करते. कर्मचाऱ्याचे टॅबलेट "Staff" असलेले प्रमाणपत्र सादर करते - ते स्टाफ VLAN वर जाते. गेस्ट डिव्हाइसेस पूर्णपणे वेगळ्या SSID ला जोडतात, जे Captive Portal सोल्यूशनद्वारे हाताळले जाते. POS टर्मिनल्सवरील सप्लिकंट कॉन्फिगरेशन MDM द्वारे लॉक डाऊन केले जाते. यामध्ये कोणत्याही वापरकर्त्याच्या हस्तक्षेपाची आवश्यकता नसते. टर्मिनल्स बूट झाल्यावर शांतपणे ऑथेंटिकेट होतात. SCEP द्वारे प्रमाणपत्र नूतनीकरण स्वयंचलित केले जाते, त्यामुळे प्रमाणपत्रांची मुदत संपल्यावर कोणताही मॅन्युअल हस्तक्षेप करावा लागत नाही. [medium pause] आता, अंमलबजावणीतील त्रुटी. मी तुम्हाला चार सर्वात सामान्य त्रुटी सांगतो. क्रमांक एक: PEAP डिप्लॉयमेंटवर सर्व्हर सर्टिफिकेट व्हॅलिडेशन नसणे. जर तुम्ही RADIUS सर्व्हरचे सर्टिफिकेट व्हॅलिडेशन करण्यासाठी आणि सर्व्हरचे नाव तपासण्यासाठी सप्लीकंट कॉन्फिगर केले नाही, तर युजर्स फसव्या ऍक्सेस पॉईंटशी कनेक्ट होण्यासाठी असुरक्षित ठरतात. सप्लीकंट प्रोफाइलमध्ये नेहमी ट्रस्टेड रूट CA आणि सर्व्हरचे नाव नक्की नमूद करा. क्रमांक दोन: सर्टिफिकेटची मुदत संपल्यामुळे मोठ्या प्रमाणावर ऑथेंटिकेशन अयशस्वी होणे. क्लायंट सर्टिफिकेट्सना वैधतेचा कालावधी असतो. जर तुमच्याकडे SCEP किंवा NDES द्वारे ऑटोमेटेड रिन्यूअलची व्यवस्था नसेल, तर तुम्हाला अशा कठीण परिस्थितीचा सामना करावा लागेल जिथे शेकडो डिव्हाइसेसचे ऑथेंटिकेशन एकाच वेळी थांबेल. सेवा लाईव्ह करण्यापूर्वी रिन्यूअल ऑटोमेशन तयार करा. क्रमांक तीन: विसंगत सप्लीकंट वर्तन असलेले BYOD डिव्हाइसेस. विशेषतः Android मधील विविध उत्पादकांमध्ये 802.1X चे सपोर्ट विखुरलेले आहे. काही व्हर्जनमध्ये WiFi प्रोफाइल स्वीकारण्यापूर्वी युजरला मॅन्युअली CA सर्टिफिकेट इन्स्टॉल करावे लागते. ही पायरी हाताळणारे ऑनबोर्डिंग पोर्टल हेल्पडेस्कवरील कामाचा ताण लक्षणीयरीत्या कमी करते. क्रमांक चार: Windows 11 चे नवीन अपडेट्स सप्लीकंट कॉन्फिगरेशन बिघडवतात. Microsoft ने अनेक Windows 11 अपडेट्समध्ये 802.1X चे वर्तन बदलले आहे. विशेषतः, 24H2 अपडेटने मूळ सप्लीकंटद्वारे EAP-TLS फॉलबॅक हाताळण्याच्या पद्धतीमध्ये बदल केले आहेत. उत्पादन क्षेत्रात लागू करण्यापूर्वी नवीन OS व्हर्जनवर तुमच्या सप्लीकंट प्रोफाइलची चाचणी घ्या. [medium pause] आता काही जलद प्रश्न. काय IoT डिव्हाइसेस 802.1X ला सपोर्ट करू शकतात? बहुतेक करू शकत नाहीत. IoT डिव्हाइसेसमध्ये सहसा सप्लीकंट नसतोच. यासाठीचा पर्याय म्हणजे MAC Authentication Bypass - MAB - जिथे RADIUS सर्व्हर डिव्हाइसच्या MAC ऍड्रेसच्या आधारे त्याचे ऑथेंटिकेशन करतो. MAC ऍड्रेस स्पूफ केले जाऊ शकतात, त्यामुळे MAB डिव्हाइसेस नेहमी कडक फायरवॉल नियम असलेल्या एका वेगळ्या IoT VLAN वरच असायला हवेत. मला 802.1X चालवण्यासाठी PKI ची गरज आहे का? PEAP साठी, नाही - तुम्हाला फक्त RADIUS सर्व्हरवर सर्व्हर सर्टिफिकेटची आवश्यकता असते. EAP-TLS साठी, होय - क्लायंट सर्टिफिकेट जारी करण्यासाठी तुम्हाला PKI ची आवश्यकता असते. क्लाउड-आधारित PKI सेवा इन्फ्रास्ट्रक्चरचा खर्च लक्षणीयरीत्या कमी करतात. 802.1X Purple च्या नेटवर्क ऍक्सेस प्लॅटफॉर्मशी कसे जोडले जाते? Purple तुमच्या सद्य हार्डवेअरवर - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist आणि इतर - वर क्लाउड ओव्हरले म्हणून काम करते. Staff WiFi नेटवर्कवर, Purple चे SecurePass ॲड-ऑन तुमच्या आयडेंटिटी प्रोव्हाइडरशी - Microsoft Entra ID, Okta किंवा Google Workspace - जोडले जाते जेणेकरून ऑन-प्रिमायसेस RADIUS इन्फ्रास्ट्रक्चरची आवश्यकता न पडता 802.1X ऑथेंटिकेशन लागू करता येईल आणि प्रति-युजर VLAN पॉलिसी सेट करता येतील. [medium pause] थोडक्यात सांगायचे तर: 802.1X सप्लीकंट हा डिव्हाइस-साइड एजंट आहे जो पोर्ट-आधारित नेटवर्क ऍक्सेस कंट्रोल कार्यरत करतो. तुमची EAP पद्धतीची निवड - कमाल सुरक्षेसाठी EAP-TLS, ट्रान्झिशनल पर्याय म्हणून PEAP - तुमच्या PKI च्या गरजा आणि सप्लीकंट कॉन्फिगरेशनचा दृष्टिकोन ठरवते. MDM द्वारे डिप्लॉय केल्यावर मूळ OS सप्लीकंट्स बहुतांश मॅनेज्ड डिव्हाइसच्या गरजा पूर्ण करतात. थर्ड-पार्टी क्लायंट्स विशिष्ट प्रकरणांमध्ये अधिक उपयुक्त ठरतात: प्रोप्रायटरी EAP पद्धती, सुसंगत कॉन्फिगरेशनची आवश्यकता असलेले मिक्स-OS डिव्हाइसेस किंवा सेल्फ-सर्व्हिस BYOD ऑनबोर्डिंग.लक्षात ठेवण्यासारख्या तीन महत्त्वाच्या गोष्टी: प्रत्येक supplicant profile वर तुमच्या RADIUS सर्व्हर प्रमाणपत्राची पडताळणी करा, EAP-TLS मोठ्या प्रमाणावर तैनात करण्यापूर्वी प्रमाणपत्र नूतनीकरण स्वयंचलित करा, आणि 802.1X ला सपोर्ट न करू शकणारे डिव्हाइसेस - IoT, जुने हार्डवेअर - यांना MAC Authentication Bypass चा पर्याय वापरून समर्पित VLANs वर वेगळे करा. तुमच्या नेटवर्क ऍक्सेस आर्किटेक्चरसोबत Purple कसे समाकलित होते याबद्दल अधिक माहितीसाठी, purple dot ai ला भेट द्या. ऐकल्याबद्दल धन्यवाद.