बेंचमार्क ने VPN पोर्ट को चिह्नित किया? नियंत्रण का दायरा देखें

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

पोर्ट का बचाव करने से पहले नियंत्रण पढ़ें। फैसले जैसा पढ़ा जाने वाला निष्कर्ष आमतौर पर एक संसाधन पर लागू विधेय होता है।

निष्कर्ष की पंक्ति वास्तव में क्या उद्धृत करती है

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

Amazon का Security Hub दस्तावेज़ीकरण उस अलगाव को पेवॉल वाले PDF के बिना दिखाई देने योग्य रखता है:EC2 नियंत्रण पृष्ठ पोर्ट 22 और 3389 पर अप्रतिबंधित पहुंच के लिए सुरक्षा समूह जांच की सूची देता है, और नेटवर्क ACL को उसकी अपनी शर्तों वाला अलग संसाधन मानता है। वही प्रशासनिक पोर्ट, अलग ऑब्जेक्ट, अलग परीक्षण। यही वह बारीकी है जो निष्कर्ष को विरासत में मिलती है।

aws ec2 describe-security-groups --group-ids sg-0d1f8a2c4b6e9f3a1 --output json
aws ec2 describe-network-acls --filters Name=entry.port-range.from,Values=22 --output table

सार्वजनिक श्रोता को प्रशासनिक पहुंच से अलग करें

इंटरनेट से UDP 1194 स्वीकार करने वाला VPN श्रोता और प्रवेश की अनुमति के बाद ही पहुंचने योग्य SSH सेवा अलग-अलग एक्सपोज़र मार्ग हैं। पहले को कवर करने वाली जांच दूसरे के बारे में कुछ नहीं कह सकती, और दूसरे को कवर करने वाली जांच पहले को अनदेखा कर सकती है। एक पर सफल परिणाम दूसरे के बारे में वक्तव्य नहीं है, स्टेटस मीटिंग में दोनों कितने भी समान लगें।

समीक्षा में हर मार्ग को उसकी अपनी पंक्ति मानें।

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

संसाधन ही तय करता है कि पोर्ट दायरे में है भी या नहीं

सुरक्षा समूह नियम, सबनेट ACL प्रविष्टि और होस्ट फ़ायरवॉल नियम सभी ट्रैफ़िक की अनुमति दे सकते हैं, फिर भी उनमें से केवल एक ही ऑब्जेक्ट हो सकता है जिसका नियंत्रण मूल्यांकन करता है। प्रभावी अनुमति का अर्थ है समानांतर समूहों, दोनों पता परिवारों और उनके सामने बैठे किसी भी अस्वीकृति नियम को मिलाना। समूह-स्तरीय जांच में विफल पोर्ट अभी भी अगम्य हो सकता है, और उसे पास करने वाला पोर्ट और भीतर अवरुद्ध हो सकता है।

यहीं दूसरे वातावरण के नियमों का प्रत्यारोपण गलत हो जाता है। नेटवर्क ACL स्टेटलेस होते हैं और क्रम में मूल्यांकित होते हैं; सुरक्षा समूह स्टेटफुल होते हैं और केवल अनुमति देते हैं। एक से उधार लिया गया नियम मॉडल दूसरे का वर्णन नहीं करता, और उसका अनुवाद गलत ऑब्जेक्ट के बारे में आत्मविश्वासी उत्तर देता है।

निर्णय दर्ज करें ताकि अगला ऑडिट उसका पुनः उपयोग करे

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

«VPN पोर्ट की समीक्षा हुई» लिखा नोट गारंटी देता है कि अगली तिमाही में बहस लौटेगी। इसके बजाय मूल्यांकनकर्ता, संशोधन और साक्ष्य का नाम लें।