बेन्चमार्कले VPN पोर्ट चिन्ह लगायो? नियन्त्रणको दायरा जाँच्नुहोस्
बेन्चमार्कले 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 पोर्ट समीक्षा भयो» भन्ने नोटले अर्को त्रैमासमा बहस फर्केर आउने ग्यारेन्टी गर्छ। बरु मूल्याङ्कनकर्ता, संशोधन र प्रमाणको नाम लिनुहोस्।