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 नियम हर किनारे वाले उपकरण से गया है, जिसमें वह आपदा-पुनर्प्राप्ति प्रति भी है जिसे कोई याद नहीं रखता।

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