हरेक यन्त्र लक आउट नगरी VPN पासवर्ड परिवर्तन गर्नुहोस्

तीन फोन, एउटा राउटर र एउटा निगरानी जाँचले अझै पुरानो पासवर्ड समातिरहेका छन्, र तीमध्ये एउटा हरेक नब्बे सेकेन्डमा फेरि जोडिन्छ। खाताको पासवर्ड दस मिनेट अघि परिवर्तन भयो, त्यसैले ती क्लाइन्टमध्ये हरेकले अब सर्भरले अस्वीकार गर्ने मान पठाइरहेको छ। त्यही क्षणमा मिथक टुट्छ: पासवर्ड परिवर्तनले खातालाई छुन्छ, प्रत्येक यन्त्रमा बसेको पुरानो मानको प्रतिलिपिलाई होइन। अब आउने कुरा त्यो परिवर्तनले नगरेको काम हो।

मिथक: एउटा परिवर्तन, सबै ठाउँमा एकैचोटि

पासवर्ड परिवर्तनले सबै साइन आउट गरी सफा पुनः लगइन बाध्य पार्छ भन्ने विश्वास छ। त्यसो हुँदैन, किनकि सर्भरले अन्तिम पटक कुन प्रमाणीकरण स्वीकार गर्यो त्यति मात्र ट्र्याक गर्छ, जबकि क्लाइन्टहरूले सुरक्षित गरेको कुरा समातिरहन्छन्। सुरक्षित पासवर्ड भएको यन्त्रले आफ्नै तालिकाअनुसार त्यो फेरि प्रयास गर्छ र कसैले खाता लक भएको थाहा नपाउँदासम्म चुपचाप असफल हुन्छ। प्रतिलिपिहरू खाताबाहिर बाँच्छन् भन्ने स्वीकार गरेपछि, घुमाइ अब एउटै कार्यजस्तो देखिँदैन।

यीमध्ये केही पनि घुमाइविरुद्ध छैन। यसले सुरक्षित प्रतिलिपिलाई पछिको सोच होइन, परिवर्तनको भाग मान्ने पक्षमा वकालत गर्छ। लक आउट सामान्यतया समानान्तर पुनः प्रयासबाट आउँछ: गणक सक्रिय नहुँदासम्म हरेक यन्त्रले आफ्नै तालिकाअनुसार पुरानो मान पठाइरहन्छ। अनि खाता आक्रमणमा परेको जस्तो देखिन्छ, जबकि यसलाई कसैले नबदलेका प्रमाणीकरण मात्र दिइरहेको हुन्छ। यो भिन्नता महत्त्वपूर्ण छ, किनकि समाधान कडा लक आउट नीति होइन, यन्त्रहरूको सूची हो।

घुमाइअघि प्रतिलिपिहरूको सूची बनाउनुहोस्

पासवर्ड फारम खोल्नुअघि सूची लेख्नुहोस्। यो खाताको रूपमा प्रमाणित हुने हरेक क्लाइन्ट, स्क्रिप्ट, स्वचालन र व्यवस्थापित प्रोफाइल सूचीबद्ध गर्नुहोस्: आफै जोडिने फोन, दुई वर्षअघि कन्फिगर गरिएको राउटर, सोमबार मात्र जागा ल्यापटप, र हरेक मिनेट प्रयास गर्ने निगरानी जाँच। प्रत्येकका लागि प्रमाणीकरण कहाँ सुरक्षित छ, परिवर्तनका क्रममा यन्त्र पुग्न सकिन्छ कि सकिँदैन, र फेरि जोडिन नसके कुन पुनःप्राप्ति मार्ग छ लेख्नुहोस्। यही सूचीले जोखिमपूर्ण परिवर्तनलाई योजनाबद्ध परिवर्तनमा बदल्छ, र पुरानो पासवर्ड काम गर्न छोड्नुअघि यो हुनैपर्छ।

अफलाइन यन्त्रहरू चिरपरिचित छुट हुन्। दराजमा रहेको ल्यापटप तीन हप्तापछि फर्किन्छ र सबैभन्दा नराम्रो क्षणमा पुरानो मान प्रस्तुत गर्छ। यसको स्थान र तालिका पनि लेख्नुहोस्, किनकि पर्खनुको सट्टा यसको पछि दौडनु पर्नेछ।

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

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

प्रतिलिपिलाई तिनका मालिकसँग तुलना गर्नुहोस्। कसैले दाबी नगरेको यन्त्र त्यो यन्त्र हो जसलाई कसैले अद्यावधिक गर्दैन, र पुनः प्रयास जारी राख्ने सम्भावना सबैभन्दा बढी त्यसैको हुन्छ।

तपाईं वास्तवमा कुन रहस्य घुमाइरहनुभएको छ

खाता पासवर्ड VPN तैनाथीमा एउटा मात्र प्रमाणीकरण हो। कुञ्जी पासफ्रेज, प्रमाणपत्र पहिचान र वैकल्पिक सहकर्मी रहस्यको आ-आफ्नै प्रतिस्थापन मार्ग र आ-आफ्नै मालिक हुन्छ। खाता पासवर्ड बदल्नाले प्रमाणपत्रले प्रमाणित हुने यन्त्रका लागि केही गर्दैन, र प्रमाणपत्र फेरि जारी गर्नाले सुरक्षित पासवर्ड भएको क्लाइन्टका लागि केही गर्दैन। समाधानको नाम लिनुअघि रहस्यको नाम लिनुहोस्।

यदि घुमाइ नीतिले होइन, शंकाले चलाएको हो भने घटना प्रक्रिया सुविधा योजनाभन्दा माथि हुन्छ। प्रमाणले मागेको कुरा रद्द गर्नुहोस् र यन्त्र सूचीको थप काम स्वीकार गर्नुहोस्। त्यो निर्णय घटनाको मालिकको हो, पासवर्ड रिसेट फारम संयोगवश समात्नेको होइन।

सुरक्षित मान जहाँ बस्छ त्यहीँ बदल्नुहोस्

सेवाले अभिलेख गरेको संयन्त्रबाट प्रमाणीकरण बदल्नुहोस्, त्यसपछि सुरक्षित प्रतिलिपि अद्यावधिक गर्नुहोस् वा राख्न चाहेको हरेक यन्त्रमा साइन-इन प्रवाह चलाउनुहोस्। यसलाई फेरि लेख्ने प्रबन्धकको पछाडिको उत्पन्न कन्फिगरेसन सम्पादन नगर्नुहोस्, किनकि प्रबन्धकले अर्को चलाइमा पुरानो मान पुनःस्थापित गर्छ र सम्पादन ढिलो खराबी बन्छ। प्रबन्धकले पढ्ने स्रोत अद्यावधिक गर्नुहोस्, वा क्लाइन्टको आफ्नै प्रमाणीकरण भण्डार प्रयोग गर्नुहोस्। जसरी भए पनि, यन्त्रले क्लाइन्टले साँच्चै पढ्ने ठाउँमा नयाँ मान पाएर टुङ्गिनुपर्छ।

पासवर्ड फाइल सुरक्षित गर्ने क्लाइन्टलाई फाइल फेरि लेखिएको चाहिन्छ, जबकि सोध्ने क्लाइन्टलाई पूरा भएको साइन-इन चाहिन्छ। NetworkManager ले रहस्य जडान प्रोफाइलभित्र राख्छ, त्यसैले परिवर्तन पाठ सम्पादकबाट होइन, nmcli बाट जान्छ:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

प्रमाणीकरण फाइल पढ्ने प्रोफाइल तेस्रो अवस्था हो। त्यो फाइलको सामग्री बदल्नुहोस्, यसका अनुमतिहरू बन्द राख्नुहोस्, र यसलाई संकेत गर्ने प्रोफाइल सम्पादन गर्नुको सट्टा क्लाइन्ट फेरि लोड गर्नुहोस्। प्रोफाइल बदलिएन; यसले पढ्ने रहस्य मात्र बदलियो।

हरेक लक्षित यन्त्र एक पटक जानाजान फेरि जोड्नुहोस् र कुन असफल हुन्छन् हेर्नुहोस्। यन्त्र असफल हुँदै गए त्यसले संकेत गर्ने खाता र पढ्ने भण्डार हेर्नुहोस्, पासवर्ड फेरि बदल्नुअघि, किनकि दोस्रो परिवर्तनले अद्यावधिक गर्नुपर्ने प्रतिलिपि गुणन गर्छ। दुई पटक असफल हुने यन्त्र सामान्यतया गलत खातामा संकेत गर्छ वा तपाईंले अझै नभेटेको भण्डार पढ्छ। त्यो सुधार्नुहोस्, अनि फेरि जोड्नुहोस्।

सत्र र टोकनहरू पासवर्डभन्दा लामो बाँच्छन्

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

NIST SP 800-63B मा रहेको प्रमाणीकरण जीवनचक्र मार्गदर्शन ले प्रमाणक र सत्रहरूलाई छुट्टै श्रेणीमा राख्छ, त्यसैले पासवर्ड परिवर्तन र विश्वव्यापी लगआउट फरक कार्यहरू हुन्। तिनलाई दुई पूर्णता मापदण्ड भएका दुई काम मान्नुहोस्। पहिलो नयाँ मान चल्नेबित्तिकै सकिन्छ, र दोस्रो पुराना सत्रहरू गएपछि सकिन्छ।

नयाँ पासवर्ड अभिलेखमा नलेखी पूर्णता अभिलेख गर्नुहोस्। प्रमाणीकरण समावेश भएको घुमाइ लग साझा ड्राइभमा प्रतीक्षारत नयाँ घटना हो। मिति, अद्यावधिक गरिएका यन्त्र र अझै बाँकी यन्त्र लेख्नुहोस्।