त्यो कमजोरीको नतिजा कुन VPN प्रक्रियासँग सम्बन्धित छ?

स्क्यानरको नतिजाले एउटा ठेगाना, एउटा पोर्ट र त्यहाँ जे कुरा भयो त्यसको नाम दिन्छ। यसले त्यो सकेटपछाडिको प्रक्रियाको नाम दिँदैन, र VPN होस्टमा धेरै प्रक्रियाले मेसिन साझा गर्न सक्छन् जबकि तीमध्ये एउटा मात्र टनेल हो। छेउको उपकरणबाट संस्करण स्ट्रिङ पढ्नु वा डिस्कमा लाइब्रेरी फाइल भेट्नुले होस्टको बारेमा प्रमाण थप्छ, श्रोताको बारेमा होइन। नतिजा तब मात्र कार्ययोग्य हुन्छ जब यसलाई एउटा चलिरहेको घटकसँग जोडिन्छ र त्यसपछि सूचनाले वास्तवमा भनेको दायरासँग मिलाइन्छ।

क्रम महत्त्वपूर्ण छ: पहिले घटक, दोस्रो सूचना, तेस्रो उपचार।

प्रतिवेदनले पोर्टको नाम दिन्छ, कार्यक्रमको होइन

वास्तवमा मूल्याङ्कन गरिएको अन्त्यबिन्दुबाट सुरु गर्नुहोस्। HTTPS प्रशासन पोर्टविरुद्धको जाँचले वेब सेवा, त्यसको TLS स्ट्याक र त्यसअगाडि रहेको जुनसुकै प्रोक्सी मापन गर्यो; यसले अर्को पोर्टको OpenVPN वा WireGuard श्रोताको बारेमा केही सिकेन। रिभर्स प्रोक्सी र व्यवस्थापन एजेन्टले यसलाई अझ बिगार्छन्, किनभने प्रमाणपत्र र ब्यानर अगाडिको भागको हुन सक्छ जबकि कमजोर लाइब्रेरी त्यसपछाडि ब्याकएन्ड प्रक्रियामा हुन्छ।

नतिजासँगै गन्तव्य, ढुवानी, पोर्ट र सेवाको नाम रेकर्ड गर्नुहोस्, ताकि दायरा नतिजासँगै जाओस्।

चलिरहेको बिल्ड वास्तवमा के हो

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

बिल्डलाई सूचनाको दायरासँग मिलाउने

सूचनाले उत्पादन, संस्करण र कहिलेकाहीँ आवश्यक सर्तहरू वर्णन गर्छन्, र ती तीन क्षेत्र सधैं प्याकेज संस्करणसँग मिल्दैनन्। OpenVPNको अप्रिल 2014को Heartbleed सूचना उपयोगी ऐतिहासिक उदाहरण हो, किनभने यसले प्रभावित Access Server संस्करणहरूलाई फरक जोखिम भएका वेब सेवा र VPN डेमनबाट अलग गर्छ। पाठ यो हो कि OpenSSL शब्द ढाँचाले मिलाउनुभन्दा पाठले कुन घटक समेट्छ त्यो पढ्नुहोस्।

त्यो सूचना पनि पुरानो छ। यसका प्याच गरिएका रिलिज नम्बर अब स्थापना सल्लाह होइनन्, र 2014 मा सुधारिएको त्रुटिले आज तपाईंले चलाइरहेको शाखाका पछिल्ला समस्याबारे केही भन्दैन।

असहमति समाधान गर्ने, त्यसपछि जोखिम बन्द गर्ने

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

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

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