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

मतभेद सुलझाना, फिर जोखिम बंद करना

जब इन्वेंटरी और मूल्यांकन असहमत हों, तो जाँचें कि क्या दोनों एक ही एंडपॉइंट और रनटाइम बताते हैं: दूसरा पता, एक फ्रंट-एंड प्रॉक्सी, दूसरी सेवा, पोर्ट से अभी भी बँधी पुरानी प्रक्रिया, या पैकेज प्रबंधक द्वारा कभी न देखी गई बंडल लाइब्रेरी। रिपोर्ट फिर से लिखने से पहले सीमा पर इसे सुलझाएँ।

समर्थित सुधार लागू करें, प्रभावित सेवा पुनः आरंभ करें और पुष्टि करें कि नया बिल्ड ही अब चल रहा है। डिस्क पर पैच की गई फ़ाइल हो और पुरानी प्रक्रिया अभी भी ट्रैफ़िक परोसे, तो वह उपचार नहीं है।

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