ती असुरक्षता शोध कोणत्या 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 मध्ये दुरुस्त केलेली त्रुटी आज तुम्ही चालवत असलेल्या शाखेतील नंतरच्या समस्यांबद्दल काहीही सांगत नाही।

मतभेद सोडवणे, नंतर प्रदर्शन बंद करणे

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

समर्थित दुरुस्ती लागू करा, प्रभावित सेवा पुन्हा सुरू करा आणि नवीन बिल्डच आता चालू आहे याची खात्री करा। डिस्कवर पॅच केलेली फाइल असूनही जुनी प्रक्रिया अजूनही रहदारी सेवा देत असेल, तर तो उपाय नाही।

नंतर प्रदर्शन कालावधीत घटकाकडे काय असू शकते यावर काम करा। पॅचिंग आणि ओळखपत्रे बदलणे वेगवेगळ्या प्रश्नांची उत्तरे देतात, आणि प्रभावित होस्टजवळ साठवलेले प्रमाणपत्र स्वतःच गळलेल्याची यादी नाही। रद्द करणे, सत्रे काढणे आणि क्लायंट अद्ययावत करण्यासाठी घटनेच्या मालकाची प्रक्रिया पाळा, आणि कोणता घटक प्रभावित झाला, पुरावे का लागू होते आणि कशाने ते बंद झाले हे नोंदवा। तीच नोंद नंतरचा आढावा वाचेल।