Windows VPN को मज़बूत बनाना: सुरंग से पहले प्रमाणीकरण ठीक करें

आपका Windows VPN सर्वर उपयोगकर्ता नाम और पासवर्ड मांगता है, और वह एक ही संवाद तीन असंबंधित कर्तव्यों को छिपाता है। एक साबित करता है कि व्यक्ति कौन है, एक रोकता है कि तार पर नज़र रखने वाला कोई वह प्रमाण दोबारा इस्तेमाल करे, और एक तय करता है कि बाद में किन पतों तक पहुँच सकता है। ज़्यादातर छोटी तैनातियाँ पहले सुरंग को मज़बूत करती हैं और पहले दो कर्तव्यों को उनके डिफ़ॉल्ट मानों पर छोड़ देती हैं, जो गलत क्रम है।

उसी क्रम में काम करें जिस क्रम में हमलावर करता है। पहले वह जो तार से पकड़ा जा सकता है। फिर वह जो उस रिकॉर्डिंग के साथ बाद में दोबारा चलाया जा सकता है। अंत में, वह जहाँ प्रमाणित हमलावर अंदर पहुँचकर पहुँच सकता है।

तीन कर्तव्य, एक संवाद

पहचान वह हिस्सा है जिसके बारे में लोग सोचते हैं, और वह समस्या का केवल एक तिहाई है। पहचान का प्रमाण ऐसे प्रेक्षक का सामना करे जो आदान-प्रदान रिकॉर्ड करता है और बाद में फिर कोशिश करता है। अधिकृति एक अलग निर्णय है जो सर्वर पहचान तय होने के बाद लेता है, और Windows इसे उस सेवा से अलग सेवा में रखता है जो क्रेडेंशियल जाँचती है।

जब तीनों एक ही मानसिक बाल्टी में रहते हैं, तो सामान्य परिणाम वह सर्वर होता है जो मज़बूती से प्रमाणीकरण करता है और फिर उपयोगकर्ता को सब कुछ तक पहुँचने देता है। इसे बाद में ठीक करना अभी नीति तय करने से कठिन है, क्योंकि तब तक फ़ायरवॉल प्रोफ़ाइल, पता पूल और मार्ग सभी पुरानी धारणा को कूटबद्ध कर चुके होते हैं।

किसी भी सेटिंग को छूने से पहले तीनों को अपने नोट्स में अलग करें, फिर उन्हें सबसे कमज़ोर कड़ी से ऊपर की ओर ठीक करें।

MS-CHAPv2 पुनःप्ले परीक्षण क्यों नहीं झेल सकता

अगर सर्वर अब भी MS-CHAPv2 के साथ PPTP स्वीकार करता है, तो सुरंग पासवर्ड को किसी सार्थक अर्थ में नहीं बचाती। चुनौती और प्रतिक्रिया पकड़ी जा सकती हैं और ऑफ़लाइन हमला किया जा सकता है, और 2012 में एक सार्वजनिक क्रैकिंग सेवा ने ऐसे हाथ मिलाने से सामान्य पासवर्ड के लिए लगभग एक दिन में वापसी दिखाई। लंबा और जटिल पासवर्ड लागत बढ़ाता है; यह वह सामग्री नहीं हटाता जो हमलावर को नेटवर्क से चाहिए।

आप जो गुण चाहते हैं वह ऐसा क्रेडेंशियल है जिसे दोबारा न चलाया जा सके। क्लाइंट प्रमाणपत्रों के साथ EAP-TLS हर उपकरण को उसकी अपनी पहचान देता है और आपको ठीक एक उपकरण रद्द करने देता है।

प्रमाणपत्र तैनात करना वास्तविक काम है: एक निजी CA, ऐसा रद्दीकरण पथ जिसे क्लाइंट जाँचें, और ऐसी नवीनीकरण योजना जो कर्मचारी बदलाव झेल सके। उस काम को परियोजना मानें, अपने और काम करती सुरंग के बीच बाधा नहीं। उसके लिए वैसे बजट रखें जैसे फ़ायरवॉल बदलने के लिए रखते हैं। साझा पासवर्ड केवल पहले रद्दीकरण तक सस्ता है।

पूर्व-साझा कुंजी जोड़ी को प्रमाणित करती है, व्यक्ति को नहीं

L2TP/IPsec पूर्व-साझा कुंजी के साथ साबित करता है कि दो गेटवे एक ही रहस्य जानते हैं। यह नहीं बताता कि कौन सा मनुष्य जुड़ रहा है, और उस परत पर एक कर्मचारी को दूसरे से अलग नहीं कर सकता। लंबा यादृच्छिक मान इस्तेमाल करें, कुछ मार्गदर्शिकाओं के सुझाए दस अक्षरों से कहीं अधिक, क्योंकि जो भी हाथ मिलाना पकड़ ले वह कुंजी पर ऑफ़लाइन हमला कर सकता है।

उस प्रोफ़ाइल का हर क्लाइंट रहस्य साझा करता है, इसलिए एक व्यक्ति को हटाने का अर्थ है उसे बाकी सभी में फिर बाँटना। मशीन-स्तर के रहस्य के ऊपर उपयोगकर्ता प्रमाणीकरण का अलग चरण रखें, और क्लाइंट आबादी बढ़ने के साथ प्रमाणपत्रों पर जाएँ। पूर्व-साझा कुंजी MS-CHAPv2 के साथ मिलकर दो कमज़ोर परतें हैं, और दूसरी पहली को निष्फल कर देती है।

अधिकृति Network Policy Server में है

Windows पर NPS तय करता है कि कौन जुड़ सकता है, और यह प्रमाणीकरण पहले ही सफल होने के बाद करता है। वह अलगाव उत्पाद में सबसे उपयोगी मज़बूती नियंत्रण है, और कई तैनातियाँ उसे अछूता छोड़ देती हैं।

ऐसी नीति शर्तें इस्तेमाल करें जो वास्तविक सीमाएँ दर्शाएँ: समूह सदस्यता, वह समय-खिड़की जब सहायता कर्मचारियों के साथ हो, और स्वास्थ्य जाँच से उपकरण की स्थिति। जहाँ डेटा घर्षण को उचित ठहराए वहाँ दूसरा कारक जोड़ें, और याद रखें कि नीति हर कनेक्शन प्रयास पर मूल्यांकित होती है, जो उसे दस्तावेज़ नहीं बल्कि जीवंत नियंत्रण बनाता है।

RADIUS लेखांकन आपको एक रिकॉर्ड भी देता है कि कौन जुड़ा और कब। वह लॉग घटना समीक्षा और अनुमान के बीच का अंतर है, और वह मौजूद रहता है चाहे कोई उसे पढ़े या न पढ़े।

सीमित करें कि सफल लॉगिन कहाँ पहुँच सकता है

VPN अडैप्टर को ऐसी फ़ायरवॉल प्रोफ़ाइल में उतरना चाहिए जो उसकी भूमिका के लिए ज़रूरी सेवाओं की अनुमति दे, पूरे सबनेट की नहीं। मार्ग का प्रश्न फ़िल्टरिंग से अलग है। पूर्ण सुरंग क्लाइंट उपकरण की रक्षा करती है और हर बाइट को आपके अपलिंक से भेजती है, जबकि विभाजित सुरंग स्थानीय ट्रैफ़िक को स्थानीय रखती है और उपकरण को उस नेटवर्क के सामने उजागर करती है जिस पर वह हो।

दोनों में से कोई भी विकल्प सुरक्षा डिफ़ॉल्ट नहीं है। दोनों को उस फ़ायरवॉल प्रोफ़ाइल के पास लिखा जाना चाहिए जिसकी वे अपेक्षा करते हैं।

विफलता पथ सत्यापित करें

जाँचें कि क्या टूटना चाहिए: गलत पासवर्ड, समाप्त प्रमाणपत्र, रद्द उपकरण, समूह से बाहर का उपयोगकर्ता। हर एक अलग बिंदु पर विफल होना चाहिए, और लॉग को बताना चाहिए कि कौन सा था। सेट पहले परीक्षण खाते पर चलाएँ, फिर वास्तविक उपयोगकर्ता के लिए दोहराएँ। बिना कारण घटना लॉग में पहुँचने वाला अस्वीकार उस रिकॉर्ड की ज़रूरत से बहुत पहले ठीक करने लायक है।

फिर पुष्टि करें कि कौन से पोर्ट प्रकाशित हैं और क्यों। PPTP को TCP 1723 और पोर्ट के बजाय IP प्रोटोकॉल के रूप में GRE चाहिए, IKEv2 को UDP 500 और 4500 चाहिए, और L2TP को UDP 1701 के साथ IPsec चाहिए। क्लाइंट के जुड़ने के लिए प्रबंधन इंटरफ़ेस खोलना मरम्मत नहीं है, यह खोजे जाने की प्रतीक्षा करती दूसरी घटना है।

अंत में तय करें कि सर्वर क्या दर्ज करता है और कितने समय तक। प्रमाणीकरण इतिहास के बिना कोई अंतिम बिंदु घटना के बाद पहला प्रश्न उत्तर नहीं दे सकता, यानी क्या वह प्रयास कभी अधिकृत था।