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 लागतो। क्लायंट जोडण्यासाठी व्यवस्थापन इंटरफेस उघडणे ही दुरुस्ती नाही, ती शोधली जाण्याची वाट पाहणारी दुसरी घटना आहे।

शेवटी, सर्व्हर काय आणि किती काळ नोंदवतो ते ठरवा। प्रमाणीकरण इतिहास नसलेला शेवटचा बिंदू घटनेनंतरच्या पहिल्या प्रश्नाचे उत्तर देऊ शकत नाही, म्हणजे प्रयत्न कधीही अधिकृत होता का।