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 के रूप में चलाना नीति-असंगति का उपाय नहीं है; उपाय यह है कि इच्छित नीति सेवा के स्वामी के माध्यम से व्यक्त की जाए।