sudo सँग चलाउँदा पोर्ट स्क्यान किन बदलिन्छ

Nmap ले सधैं तपाईंले मागेको भन्ने ठान्नुभएको प्याकेट पठाउँदैन। raw सकेट उपलब्ध नभएपछि यसले पूर्वनिर्धारित SYN स्क्यानको सट्टा TCP connect स्क्यान राख्छ, त्यसैले तपाईंको सामान्य प्रयोगकर्ताका रूपमा चलाउनु र sudo मुनि चलाउनु एउटै पोर्टबारे फरक प्रश्नको जवाफ दिन सक्छ। नतिजा अनुमति-समस्याजस्तो देखिन्छ, तर सामान्यतया ती विधिको परिवर्तन हुन्। विधि स्पष्ट बनाउनु नै दुवै रनको तुलना गर्ने एकमात्र उपाय हो।

दुई प्रोब, एउटा पोर्ट, फरक कोड-बाटो

SYN स्क्यानले आफैं TCP हेडर बनाउँछ, raw सकेटबाट पठाउँछ, र कर्नेलको TCP स्ट्याकले कहिल्यै पूरा भएको जडान दर्ता गर्नुअघि नै सञ्जालबाट जवाफ पढ्छ। connect स्क्यानले अपरेटिङ सिस्टमलाई सामान्य सकेट खोल्न भन्छ र connect() ले के फर्काउँछ त्यो जनाउँछ। दुवैले पोर्टलाई खुला भन्न सक्छन्, तर आधा-खुला प्रयास एउटाले मात्र छोड्छ र पठाउने प्रक्रियासँग जोडिएको सकेट-तह नीतिको अधीन एउटा मात्र हुन्छ।

raw बाटोलाई CAP_NET_RAW चाहिन्छ, त्यसैले त्यो क्षमता नभएपछि पूर्वनिर्धारित स्क्यान चुपचाप कमजोर हुन्छ। Nmap को आफ्नै स्क्यान प्रविधिको सन्दर्भ ले यो प्रतिस्थापन अभिलेख गर्छ: connect स्क्यान विकल्प हो किनभने यसलाई कुनै विशेष अनुमति चाहिँदैन। अधिकांश रनमा यो अदलबदल चेतावनीबिना हुन्छ, र त्यसैले यसलाई गलत पढ्न यति सजिलो हुन्छ। विकल्प छ भन्ने थाहा भएपछि, “root का रूपमा खुला, प्रयोगकर्ताका रूपमा बन्द” अनुमति-बगजस्तो सुनिन छोड्छ र दुई फरक मापनजस्तो सुनिन थाल्छ।

स्क्यानमा sudo ले वास्तवमा के बदल्छ

अनुमति बढाउँदा raw सकेटको बाटो फर्किन्छ, र त्यसले फैसलाभन्दा धेरै बदल्छ। स्रोत पोर्टको छनोट, प्याकेटको समय, पुनःपठाउने व्यवहार र फिल्टर गरिएको जवाफको वर्गीकरण सबै फरक कोडबाट आउँछन्। SYN को दर सीमित गर्ने बीचको उपकरणले गन्तव्य होस्ट एकै भए पनि दुवै रनलाई असमान व्यवहार गर्छ।

गन्तव्यतर्फको लगिङ पनि फरक हुन्छ। पूरा भएको ह्यान्डशेक सेवा र कुनै पनि सकेट हिसाबलाई देखिन्छ, तर रिसेट गरिएको आधा-खुला प्रोब प्रायः देखिँदैन। तपाईंले जसको लग पनि पढ्नुहुन्छ त्यस्तो होस्टविरुद्ध रनको तुलना गर्नुभयो भने, देखिने फरकको केही भाग अवलोकन आफैं हो।

दुवै रनमा विधि स्थिर राख्नुहोस्

दुवै कलमा एउटै प्रविधि जबरजस्ती लगाउनुहोस् र तुलना अर्थपूर्ण हुन थाल्छ। -sT फ्ल्यागले connect स्क्यान स्पष्ट माग्छ, -Pn ले होस्ट पत्ता लगाउने काम हटाउँछ, -n ले नाम समाधान हटाउँछ, र एउटा -p ले पोर्ट-सूचीका फरक हटाउँछ।

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

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

खाता-सन्दर्भ केवल अनुमति-फ्ल्याग होइन

VPN तैनाथीले प्याकेटलाई UID अनुसार, cgroup अनुसार, वा सकेट खोल्ने प्रक्रियासँग जोडिएको नियम अनुसार वर्गीकृत गर्न सक्छ। त्यसपछि root ट्राफिक र प्रयोगकर्ता ट्राफिक फरक राउटिङ तालिकाबाट बाहिरिन्छन् वा फरक नियम-समूहमा ठोकिन्छन्, र स्क्यान-विधिको कुनै अनुशासनले तिनलाई मिलाउन सक्दैन।

अनुमति होइन, नीति जाँच्नुहोस्। Linux मा nftables ले यसलाई meta skuid ले व्यक्त गर्छ र iptables ले मालिक-मिलानले, र यीमध्ये कुनैले पनि एउटा UID सुरुङमा पठाउन सक्छ जब अर्कोले भौतिक पूर्वनिर्धारित मार्ग प्रयोग गरिरहन्छ।

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

नतिजा तुलना गर्नुअघि प्रोब पुष्टि गर्नुहोस्

निष्कर्ष निकाल्नुअघि कुन प्रोब चल्यो भनी प्रमाणित गर्नुहोस्। Nmap ले आफ्नै आउटपुटमा प्रविधिको नाम दिन्छ, र --reason ले प्रत्येक अवस्थापछिको प्रमाण थप्छ, र त्यही भागले ह्यान्डशेक साँच्चै पूरा भयो कि भएन भनी बताउँछ।

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

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