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 તરીકે ચલાવવી એ નીતિ-અસંગતિનો ઉપાય નથી; ઉપાય એ છે કે સેવાના માલિક દ્વારા ઇચ્છિત નીતિ વ્યક્ત કરવામાં આવે.