PPTP/MS-CHAPv2 बंद करणे: जुन्या VPN साठी रनबुक

दर महिन्याला बदलले जाणारे आणि तिजोरीत ठेवले जाणारे वीस अक्षरी पासवर्ड MS-CHAPv2 चालवणाऱ्या PPTP सर्व्हरला आधुनिक VPN करत नाहीत। पासवर्ड हा अशा देवाणघेवाणीचा इनपुट आहे ज्याची कमजोरी देवाणघेवाणीतच असते। हे रनबुक त्या व्यक्तीसाठी आहे ज्याला तो सर्व्हर वारसा म्हणून मिळाला आहे आणि त्यावर अवलंबून असलेली साइट तोडल्याशिवाय वापरकर्ते तिथून हलवायचे आहेत। टप्पे क्रमाने पूर्ण करा, कारण प्रत्येकजण एक नोंद ठेवतो, जी कोणी विचारल्यावर लागेल की प्रवेश अचानक का बदलला।

काहीही स्पर्श करण्यापूर्वी स्टॅक लिहून ठेवा

PPTP शब्दात तीन थर एकत्र येतात आणि प्रत्येकजण आपापल्या पद्धतीने अपयशी होतो। बोगदा PPTP स्वतःच आहे, GRE अधिक TCP 1723। प्रमाणीकरण म्हणजे सर्व्हर देते ती PPP पद्धत, येथे MS-CHAPv2। दुवा संरक्षण MPPE आहे, ज्याच्या किल्ल्या त्या प्रमाणीकरण देवाणघेवाणीतून येतात। तीनही नामाभिधान केल्यास पुढील दुरुस्ती चुकीच्या थरावर पडत नाही।

विकी पानावर विश्वास ठेवण्यापेक्षा जिवंत संरचना वाचा आणि फाइल, श्रोता आणि शेवटची प्रमाणित झालेली सत्रे नोंदवा।

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

Windows च्या दूरस्थ प्रवेश भूमिकेत तीच मोजणी दोन आदेशांतून येते, आणि दुसरा महत्त्वाचा आहे कारण भूमिका एकाच वेळी अनेक पद्धतींची जाहिरात करू शकते, पण क्षेत्रातील क्लायंट नेहमी फक्त सर्वात कमकुवत पद्धतीवरच सहमत होतात।

Get-VpnAuthProtocol
netstat -ano | findstr :1723

आज बोगदा प्रत्यक्षात काय वाहतो हे ठरवा

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

मग विचारा की लॉगिन देवाणघेवाण पाहू शकणारा किंवा तिच्यावर परिणाम करू शकणारा हल्लेखोर काय मिळवेल। MS-CHAPv2 सह उत्तरात असे साहित्य असते जे वापरकर्त्याचा पासवर्ड ऑफलाइन पुनर्प्राप्त करू देते, आणि म्हणूनच लांबी व फिरती रचना दुरुस्त करत नाहीत: पुनर्प्राप्त गुपित वापरकर्त्याने ते पुन्हा वापरलेल्या प्रत्येक प्रणालीवर वैध असते।

MPPE तीच कमजोरी वारसा घेते, कारण तिच्या किल्ल्या त्या देवाणघेवाणीतून येतात, आणि ती आधुनिक AEAD सिफरची प्रति-पॅकेट अखंडता व पुनरावृत्ती वर्तन देत नाही। स्वच्छ प्रमाणित झालेल्या सत्राने फक्त संरचित तपासण्यांशी सुसंगतता सिद्ध केली आहे, त्याहून अधिक काही नाही।

एक छोटा दुपारचा विराम किंवा कमी वापरकर्तासंख्या क्रिप्टोग्राफिक गुणधर्माचे धोरणात्मक गुणधर्मात रूपांतर करत नाही।

स्थलांतर एकाच देखभाल खिडकीत करा

पर्याय उभा करा, एका पथकासह तो सिद्ध करा, आणि मग जुना श्रोता शांत बॅकअप म्हणून ठेवण्याऐवजी थांबवा। ज्यापर्यंत अजूनही सर्वजण पोहोचू शकतात तो बॅकअप स्थलांतर नाही, आणि तो कमजोर देवाणघेवाण अशाच वापरकर्त्यांसाठी उघडी ठेवतो ज्यांना बदलण्याचा कधीही त्रास होत नाही।

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

त्याच खिडकीत फायरवॉलचा मार्ग बंद करा। GRE ला लक्षात ठेवायचा पोर्ट नाही, म्हणून क्रमांकाने प्रोटोकॉल 47 ला परवानगी देणारा नियम सहज लक्षात न येता राहतो आणि डेमन गेल्यावरही सेवा पोहोचण्यायोग्य ठेवतो। काढलेला नियम, त्याचे पूर्वीचे स्थान आणि कारण नोंदवा, जेणेकरून नंतरची बदल-तपासणी तो अपघाताने पुन्हा आणणार नाही।

क्रेडेन्शियल संरचनेपासून वेगळे हाताळा। क्लायंट प्रोफाइल काढणे म्हणजे रद्द करणे नाही, आणि दुसरीकडे अजूनही प्रमाणित होणारे खाते मागे घेतलेले नाही।

पर्याय PPTP करत असलेली कामे करतो का ते पडताळा

तपासणी यादी “जोडतो का” ही नाही। ती ही आहे की प्रमाणीकरण, पत्ते वाटप, DNS निराकरण, मार्ग निवड, पुनर्जोडणी वर्तन आणि समवयस्क पडताळणी हे सर्व पर्यायाखाली टिकतात का। प्रत्येक एक पथक उपकरणावर, त्याच क्रमाने तपासा, आणि निरीक्षण केलेला निकाल अपेक्षेच्या शेजारी लिहा।

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

इंटरफेसवरचा पत्ता सिद्ध करतो की बोलणी पूर्ण झाली। तो सिद्ध करत नाही की दूरच्या बाजूने अपेक्षित मार्गास मान्यता दिली, आणि वरील चौकशी फक्त या होस्टसाठी उत्तर देते, पुढे पाठवलेल्या LAN साठी नाही। रिझॉल्व्हरचे उत्तर रिझॉल्व्हरपर्यंत पोहोच सिद्ध करते, विभाजित DNS धोरण तेथे योग्य नावे पाठवते हे नाही।

पुनर्जोडणी सर्वात शेवटी तपासा, कारण तिथेच बहुतेक पर्याय मागे पडतात: लॅपटॉप झोपेत घाला, नेटवर्क बदला, आणि जुने मार्ग सोडल्याशिवाय बोगदा पुन्हा उभा राहतो याची खात्री करा।

रोलबॅक, रद्द करणे आणि तुम्ही सोडलेली नोंद

रोलबॅक सेवा पुनर्संचयित करतो; तो सुरक्षा पुनर्संचयित करत नाही, आणि हा फरक खिडकी उघडण्यापूर्वी मोठ्याने सांगावा लागतो। नवीन मार्ग अपयशी झाल्यास वापरकर्त्यांना सर्वांसाठी PPTP पुन्हा सुरू करण्याऐवजी दुसऱ्या आधुनिक टोकाद्वारे किंवा तात्पुरत्या गेटवेद्वारे परत आणा। जुन्या प्रोटोकॉलवर एक आपत्कालीन मार्ग ठेवणे हे नुकतेच नोंदवलेले एक्सपोजर वाढवते।

संक्रमणानंतर PPTP वर प्रमाणित झालेली खाती रद्द करा, त्यांची साठवलेली प्रोफाइल कालबाह्य होऊ द्या, आणि GRE नियम प्रत्येक कडेच्या उपकरणातून गेला आहे याची खात्री करा, ज्यात कोणालाही आठवत नसलेली आपत्ती-पुनर्प्राप्ती प्रतही आहे।

थोडक्यात नोंद ठेवा: तुम्हाला सापडलेले प्रोटोकॉल, प्रत्येक श्रोता थांबल्याची तारीख, पर्यायाने समर्थित क्लायंट आवृत्त्या, आणि निर्णय पुन्हा उघडू शकणारा मालक। पासवर्ड स्वच्छता नंतरही महत्त्वाची आहे, पण तिच्या लायकीच्या प्रोटोकॉलवर स्वच्छता म्हणून, जुन्याला जिवंत ठेवण्याचा युक्तिवाद म्हणून नाही।