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