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 గా నడపడం విధాన-అసమన్వయానికి పరిష్కారం కాదు; ఉద్దేశించిన విధానాన్ని సేవ యజమాని ద్వారా వ్యక్తపరచడమే పరిష్కారం.