PEAP Authentication क्या है? PEAP आपके WiFi को कैसे सुरक्षित करता है

PEAP Authentication क्या है? PEAP आपके WiFi को कैसे सुरक्षित बनाता है। एक Purple Enterprise WiFi Intelligence ब्रीफिंग। आपका स्वागत है। यदि आप किसी होटल समूह, रिटेल एस्टेट, स्टेडियम, या सार्वजनिक क्षेत्र के संगठन में नेटवर्क सुरक्षा के लिए जिम्मेदार हैं, तो यह ब्रीफिंग आपके लिए है। अगले दस मिनटों में, हम PEAP authentication को कवर करने जा रहे हैं - यह वास्तव में क्या है, यह बैकएंड पर कैसे काम करता है, यह आपके सुरक्षा आर्किटेक्चर में कहाँ फिट बैठता है, और सबसे महत्वपूर्ण बात, यह कब सही निर्णय है और कब आपको कुछ अधिक मजबूत सुरक्षा विकल्प की ओर देखना चाहिए। आइए शुरुआत करते हैं। सत्र एक: संदर्भ और यह इस समय क्यों महत्वपूर्ण है। आज अधिकांश एंटरप्राइज़ WiFi डिप्लॉयमेंट अभी भी दो authentication मॉडलों में से किसी एक पर निर्भर हैं। आपके पास या तो एक प्री-शेयर्ड की है - जो पूरे संगठन में साझा किया जाने वाला एक सिंगल पासवर्ड है - या आपके पास 802.1X है, जो पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए IEEE मानक है। PEAP पूरी तरह से 802.1X के अंतर्गत आता है, और यह विश्व स्तर पर कॉर्पोरेट और संस्थागत वातावरण में अब तक का सबसे व्यापक रूप से उपयोग किया जाने वाला EAP तरीका है। PEAP के इतना हावी होने का कारण सीधा है: इसने एक वास्तविक परिचालन समस्या को हल किया। PEAP से पहले, सर्टिफिकेट-आधारित WiFi authentication को डिप्लॉय करने का मतलब था प्रत्येक डिवाइस - हर लैपटॉप, हर फोन, हर टैबलेट को क्लाइंट सर्टिफिकेट जारी करना। पांच सौ कर्मचारियों और एक BYOD नीति वाले संगठन के लिए, यह एक ऐसा PKI डिप्लॉयमेंट सिरदर्द था जिसके लिए अधिकांश IT टीमों के पास न तो बजट था और न ही समय। PEAP ने एक बीच का रास्ता पेश किया: TLS के माध्यम से मजबूत सर्वर-साइड authentication, और क्लाइंट साइड पर यूजरनेम और पासवर्ड क्रेडेंशियल। किसी क्लाइंट सर्टिफिकेट की आवश्यकता नहीं है। इस समझौते ने PEAP को 2000 और 2010 के दशकों में एंटरप्राइज़ WiFi authentication के लिए वास्तव में एक मानक बना दिया, और यह आज भी बेहद सामान्य है। 2024 और उसके बाद इन्फ्रास्ट्रक्चर के फैसले लेने वाले किसी भी व्यक्ति के लिए इसके आर्किटेक्चर और इसकी सीमाओं को समझना आवश्यक है। सत्र दो: तकनीकी रूप से गहराई से समझना। आइए विस्तार से देखें कि जब कोई डिवाइस PEAP के माध्यम से authenticate होता है तो वास्तव में क्या होता है। इस प्रक्रिया के दो अलग-अलग चरण होते हैं, और दोनों को समझना महत्वपूर्ण है। इस एक्सचेंज में तीन मुख्य भूमिकाएँ हैं: सप्लीकेंट - यह क्लाइंट डिवाइस है, चाहे वह लैपटॉप हो, स्मार्टफोन हो, या IoT टर्मिनल हो; ऑथेंटिकेटर - आमतौर पर वायरलेस एक्सेस पॉइंट या वायरलेस LAN कंट्रोलर; और ऑथेंटिकेशन सर्वर - लगभग हमेशा एक RADIUS सर्वर, जैसे Microsoft NPS, FreeRADIUS, या क्लाउड-होस्टेड RADIUS सेवा। चरण एक TLS टनल की स्थापना है। जब सप्लीकेंट कनेक्ट करने का प्रयास करता है, तो ऑथेंटिकेटर तुरंत एक्सेस नहीं देता है। इसके बजाय, यह स्थानीय नेटवर्क पर एक EAP एक्सचेंज शुरू करता है - यह EAPOL है, यानी LAN पर EAP। ऑथेंटिकेटर इसे RADIUS सर्वर पर भेजता है, जो क्लाइंट को अपना सर्वर-साइड TLS सर्टिफिकेट प्रस्तुत करता है। क्लाइंट अपने विश्वसनीय सर्टिफिकेट स्टोर के साथ उस सर्टिफिकेट को वैलिडेट करता है। यदि वैलिडेशन सफल हो जाता है, तो क्लाइंट और RADIUS सर्वर के बीच एक TLS टनल स्थापित हो जाती है। यह टनल एन्क्रिप्टेड होती है - आधुनिक डिप्लॉयमेंट में आमतौर पर TLS 1.2 या 1.3।दूसरा चरण आंतरिक प्रमाणीकरण (inner authentication) है। उस एन्क्रिप्टेड टनल के अंदर, वास्तविक क्रेडेंशियल्स का आदान-प्रदान किया जाता है। सबसे आम डिप्लॉयमेंट - PEAP-MSCHAPv2 - में क्लाइंट Microsoft Challenge Handshake Authentication Protocol version 2 का उपयोग करके एक यूजरनेम और पासवर्ड भेजता है। RADIUS सर्वर अपने पहचान स्टोर के विरुद्ध उन क्रेडेंशियल्स को सत्यापित करता है, जो Active Directory, LDAP, या क्लाइंट का क्लाउड पहचान प्रदाता हो सकता है। यदि क्रेडेंशियल्स सही पाए जाते हैं, तो RADIUS सर्वर ऑथेंटिकेटर के माध्यम से एक Access-Accept संदेश वापस भेजता है, और क्लाइंट को नेटवर्क एक्सेस प्रदान कर दी जाती है। यहाँ मुख्य सुरक्षा विशेषता यह है कि MSCHAPv2 एक्सचेंज TLS टनल के अंदर होता है। वायरलेस चैनल की पैसिव रूप से निगरानी करने वाला कोई हमलावर पारगमन में क्रेडेंशियल्स को नहीं देख सकता है। यही PEAP का मुख्य मूल्य प्रस्ताव है। अब, PEAP-MSCHAPv2 कहाँ कमजोर पड़ जाता है? यहाँ दो महत्वपूर्ण मुद्दे हैं जिन्हें किसी भी सुरक्षा-सचेत आर्किटेक्ट को समझने की आवश्यकता है। पहला: सर्वर प्रमाणपत्र सत्यापन। PEAP के लिए केवल सर्वर को एक प्रमाणपत्र प्रस्तुत करने की आवश्यकता होती है - इसके लिए क्लाइंट को प्रमाणपत्र प्रस्तुत करने की आवश्यकता नहीं होती है। यह एक अच्छी तरह से प्रलेखित हमले का जरिया (attack vector) बनाता है। यदि कोई क्लाइंट डिवाइस किसी भी प्रमाणपत्र को स्वीकार करने के लिए - या किसी भी CA से प्रमाणपत्र स्वीकार करने के लिए - गलत तरीके से कॉन्फ़िगर किया गया है - तो एक हमलावर एक नकली एक्सेस पॉइंट खड़ा कर सकता है, एक धोखाधड़ी वाला प्रमाणपत्र प्रस्तुत कर सकता है, और MSCHAPv2 हैंडशेक को बीच में रोक सकता है। hostapd-wpe जैसे टूल्स ने इस हमले को बेहद आसान बना दिया है। इसका समाधान सख्त सप्लीकेंट कॉन्फ़िगरेशन है: सर्वर प्रमाणपत्र सत्यापन को लागू करें, अपेक्षित CA को पिन करें, और सर्वर के कॉमन नाम को निर्दिष्ट करें। किसी भी गंभीर डिप्लॉयमेंट में यह गैर-परक्राम्य है। दूसरा: MSCHAPv2 ज्ञात कमजोरियों वाला एक पुराना प्रोटोकॉल है। Moxie Marlinspike द्वारा 2012 के शोध ने प्रदर्शित किया कि पर्याप्त कंप्यूट पावर के साथ MSCHAPv2 चैलेंज-रिस्पॉन्स पेयर्स को ऑफलाइन क्रैक किया जा सकता है। यदि कोई हमलावर आंतरिक प्रमाणीकरण एक्सचेंज को कैप्चर कर लेता है - उदाहरण के लिए ऊपर वर्णित नकली AP हमले के माध्यम से - तो वे ऑफलाइन ही प्लेनटेक्स्ट पासवर्ड को पुनर्प्राप्त करने का प्रयास कर सकते हैं। इसलिए आपकी पासवर्ड नीति की मजबूती सीधे आपके जोखिम को प्रभावित करती है। लंबे, जटिल, और रैंडम रूप से जनरेट किए गए पासवर्ड इस जोखिम को काफी कम कर देते हैं। इसकी तुलना EAP-TLS से करें, जहाँ सर्वर और क्लाइंट दोनों प्रमाणपत्र प्रस्तुत करते हैं। यहाँ चुराने के लिए कोई पासवर्ड नहीं होते हैं। हमले का दायरा नाटकीय रूप से कम हो जाता है। इसका समझौता परिचालन जटिलता है: आपको एक PKI की आवश्यकता होती है, आपको क्लाइंट प्रमाणपत्र जारी करने और प्रबंधित करने की आवश्यकता होती है, और आपको उन्हें हर डिवाइस पर वितरित करने के लिए एक तंत्र की आवश्यकता होती है। एक परिपक्व MDM डिप्लॉयमेंट और एक अच्छी तरह से प्रबंधित PKI वाले संगठनों के लिए, EAP-TLS गोल्ड स्टैंडर्ड है। बाकी सभी के लिए, सख्त कॉन्फ़िगरेशन के साथ PEAP-MSCHAPv2 एक व्यावहारिक और सुरक्षित विकल्प बना हुआ है। तीसरा भाग: कार्यान्वयन सिफारिशें और नुकसान। मैं आपको व्यावहारिक डिप्लॉयमेंट मार्गदर्शन देता हूँ। ये वे चीजें हैं जो एक सुरक्षित PEAP डिप्लॉयमेंट को एक कमजोर डिप्लॉयमेंट से अलग करती हैं। नंबर एक: प्रत्येक सप्लीकेंट पर सर्वर प्रमाणपत्र सत्यापन (validation) लागू करें। यह सबसे महत्वपूर्ण कॉन्फ़िगरेशन आइटम है। Windows में, यह वायरलेस नेटवर्क प्रोफ़ाइल में "Validate server certificate" चेकबॉक्स है। iOS और Android में, यह EAP कॉन्फ़िगरेशन में CA प्रमाणपत्र फ़ील्ड है। यदि यह कॉन्फ़िगर नहीं है, तो आपका PEAP डिप्लॉयमेंट रॉग AP हमलों के प्रति संवेदनशील है, भले ही बाकी सब कुछ कितनी भी अच्छी तरह से सेटअप किया गया हो। नंबर दो: MDM या GPO के माध्यम से डिप्लॉय करें, न कि मैन्युअल कॉन्फ़िगरेशन द्वारा। अंतिम उपयोगकर्ताओं द्वारा मैन्युअल कॉन्फ़िगरेशन अविश्वसनीय है। उपयोगकर्ता प्रमाणपत्र चेतावनियों पर क्लिक करके आगे बढ़ जाएंगे। वे CA फ़ील्ड को गलत तरीके से कॉन्फ़िगर कर देंगे। अपनी वायरलेस प्रोफ़ाइल को Microsoft Intune, Jamf, या Group Policy के माध्यम से पुश करें। यह आपके पूरे एस्टेट में सुसंगत, नीति-अनुपालन सप्लीकेंट कॉन्फ़िगरेशन सुनिश्चित करता है। नंबर तीन: अपने RADIUS सर्वर पर न्यूनतम के रूप में TLS 1.2 का उपयोग करें। TLS 1.0 और 1.1 को अक्षम करें। अधिकांश आधुनिक RADIUS कार्यान्वयन इसका समर्थन करते हैं, लेकिन इसे सत्यापित करना उचित है - विशेष रूप से पुराने ऑन-प्रिमाइसेस डिप्लॉयमेंट पर। नंबर चार: अपने पहचान प्रदाता (identity provider) के साथ एकीकृत करें। PEAP-MSCHAPv2 एक क्रेडेंशियल स्टोर के विरुद्ध प्रमाणित करता है। वह स्टोर आपका आधिकारिक पहचान प्रदाता होना चाहिए - Active Directory, NPS एक्सटेंशन के माध्यम से Azure AD, या LDAP एकीकरण के साथ क्लाउड RADIUS सेवा। इसका मतलब यह है कि जब कोई कर्मचारी नौकरी छोड़ता है, तो उसका खाता अक्षम करने से उसकी WiFi एक्सेस तुरंत रद्द हो जाती है। रोटेट करने के लिए कोई साझा रहस्य नहीं, कोई मैन्युअल डी-प्रोविज़निंग नहीं। नंबर पांच: अपने गेस्ट नेटवर्क पर अलग से विचार करें। PEAP एक एंटरप्राइज़ प्रमाणीकरण विधि है। गेस्ट WiFi के लिए - जहां आप आगंतुकों, ग्राहकों या कार्यक्रम में शामिल होने वाले लोगों को ऑनबोर्ड कर रहे हैं - आपको एक अलग दृष्टिकोण की आवश्यकता है। Purple जैसे प्लेटफ़ॉर्म एक उद्देश्य-निर्मित गेस्ट WiFi लेयर प्रदान करते हैं जो गेस्ट SSID पर RADIUS इन्फ्रास्ट्रक्चर की आवश्यकता के बिना कैप्टिव पोर्टल (captive portal) प्रमाणीकरण, डेटा कैप्चर और एनालिटिक्स को संभालता है। अपने एंटरप्राइज़ SSID को PEAP के साथ 802.1X पर रखें, और अपने गेस्ट SSID को उचित ऑनबोर्डिंग के साथ एक अलग, पृथक नेटवर्क पर रखें। नंबर छह: प्रमाणपत्र रोटेशन की योजना बनाएं। आपके RADIUS सर्वर प्रमाणपत्र की अवधि समाप्त हो जाएगी। जब ऐसा होगा, तो प्रत्येक क्लाइंट जिसने उस प्रमाणपत्र को पिन किया है, वह तब तक प्रमाणित करने में विफल रहेगा जब तक कि नया प्रमाणपत्र वितरित नहीं हो जाता। प्रमाणपत्र नवीनीकरण को अपने परिचालन कैलेंडर में शामिल करें - समाप्ति से कम से कम 90 दिन पहले - और इसे प्रोडक्शन में रोल आउट करने से पहले एक स्टेजिंग वातावरण में रोटेशन प्रक्रिया का परीक्षण करें। इस क्षेत्र में मुझे दिखने वाली सबसे आम विफलता मोड हैं: प्रमाणपत्र सत्यापन लागू नहीं किया जाना, जिससे रॉग AP भेद्यता उत्पन्न होती है; RADIUS सर्वर प्रमाणपत्र जो बिना किसी चेतावनी के समाप्त हो जाते हैं, जिससे व्यापक प्रमाणीकरण विफलताएं होती हैं; और MSCHAPv2 आंतरिक प्रमाणीकरण का उजागर होना क्योंकि RADIUS सर्वर गलत नेटवर्क सेगमेंट से सुलभ है। उचित योजना के साथ इन तीनों से बचा जा सकता है। धारा चार: त्वरित-फायर प्रश्न। क्या PEAP, Azure AD जैसे क्लाउड आइडेंटिटी प्रोवाइडर्स के साथ काम कर सकता है? हाँ। Azure AD MFA के लिए Microsoft का NPS एक्सटेंशन आपको Azure AD के माध्यम से PEAP ऑथेंटिकेशन को प्रॉक्सी करने की अनुमति देता है, जिससे आपके WiFi पर मल्टी-फैक्टर ऑथेंटिकेशन सक्षम होता है। वैकल्पिक रूप से, Cisco ISE, Aruba ClearPass, या JumpCloud RADIUS जैसी क्लाउड RADIUS सेवाएं सीधे Azure AD या Okta के साथ एकीकृत हो सकती हैं। क्या PEAP, PCI-DSS के अनुकूल है? PEAP-MSCHAPv2 का उपयोग PCI-DSS वातावरण में किया जा सकता है, लेकिन आपको यह सुनिश्चित करना होगा कि सर्वर प्रमाणपत्र सत्यापन लागू हो, TLS 1.2 या उच्चतर का उपयोग किया जा रहा हो, और RADIUS सर्वर ठीक से खंडित हो। PCI-DSS 4.0 नेटवर्क एक्सेस कंट्रोल के नियमों को और कड़ा करता है - अपने QSA के साथ प्रासंगिक आवश्यकताओं की समीक्षा करें। क्या मुझे PEAP से EAP-TLS पर माइग्रेट करना चाहिए? यदि आपके पास एक परिपक्व MDM परिनियोजन है और PKI को प्रबंधित करने की परिचालन क्षमता है, तो हाँ - EAP-TLS अधिक मजबूत विकल्प है। यदि आप व्यक्तिगत डिवाइस, लीगेसी हार्डवेयर, या सीमित MDM कवरेज वाले मिश्रित एस्टेट का प्रबंधन कर रहे हैं, तो कड़े कॉन्फ़िगरेशन के साथ PEAP-MSCHAPv2 उपयुक्त बना रहता है। यह जोखिम पर आधारित निर्णय है, न कि कोई बाइनरी निर्णय। WPA3-Enterprise के बारे में क्या? WPA3-Enterprise उच्च-सुरक्षा वातावरण के लिए 192-बिट सुरक्षा मोड को अनिवार्य बनाता है, लेकिन यह अभी भी PEAP सहित EAP विधियों का समर्थन करता है। WPA3 ओवर-द-एयर एन्क्रिप्शन में सुधार करता है लेकिन स्वयं EAP ऑथेंटिकेशन एक्सचेंज को नहीं बदलता है। खंड पांच: सारांश और अगले कदम। इसे संक्षेप में समझने के लिए: PEAP एक दो-चरण वाला ऑथेंटिकेशन प्रोटोकॉल है जो आंतरिक क्रेडेंशियल्स - आमतौर पर MSCHAPv2 - को एक TLS टनल के भीतर रैप करता है। यह सबसे व्यापक रूप से तैनात किया जाने वाला 802.1X EAP तरीका है क्योंकि यह क्लाइंट सर्टिफिकेट की आवश्यकता को समाप्त करता है और साथ ही मजबूत सर्वर ऑथेंटिकेशन प्रदान करता है। इसकी प्राथमिक भेद्यता दुष्ट AP हमले हैं जो गलत तरीके से कॉन्फ़िगर किए गए सप्लिकेंट्स के कारण सक्षम होते हैं जो सर्वर प्रमाणपत्र को सत्यापित नहीं करते हैं। MDM-लागू वायरलेस प्रोफाइल, CA पिनिंग और सर्वर नाम सत्यापन के माध्यम से इसे कम करें। अधिकांश एंटरप्राइज WiFi परिनियोजन - कॉर्पोरेट कार्यालय, होटल बैक-ऑफ-हाउस नेटवर्क, रिटेल स्टाफ नेटवर्क - के लिए उचित कॉन्फ़िगरेशन के साथ PEAP-MSCHAPv2 एक सुरक्षित और सही विकल्प है। उच्च-सुरक्षा वातावरण, विनियमित उद्योगों, या परिपक्व PKI इन्फ्रास्ट्रक्चर वाले संगठनों के लिए, EAP-TLS सार्थक रूप से अधिक मजबूत सुरक्षा प्रदान करता है और यही लक्षित आर्किटेक्चर होना चाहिए। यदि आप अपने एंटरप्राइज नेटवर्क के साथ-साथ गेस्ट WiFi भी चला रहे हैं - और आप में से अधिकांश ऐसा कर रहे हैं - तो याद रखें कि PEAP गेस्ट ऑनबोर्डिंग के लिए सही टूल नहीं है। Purple जैसे प्लेटफॉर्म देखें, जो एनालिटिक्स, डेटा कैप्चर और मार्केटिंग इंटीग्रेशन के साथ उद्देश्य-निर्मित गेस्ट WiFi ऑथेंटिकेशन प्रदान करते हैं, जिससे आपके गेस्ट और एंटरप्राइज ट्रैफिक को ठीक से अलग रखा जा सके और आपका अनुपालन बना रहे। आगे पढ़ने के लिए, RADIUS सर्वर आर्किटेक्चर और एंटरप्राइज WiFi ऑथेंटिकेशन पर Purple के गाइड देखें। लिंक शो नोट्स में दिए गए हैं। सुनने के लिए धन्यवाद। यह Purple Enterprise WiFi इंटेलिजेंस ब्रीफिंग थी।