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 ആയി പ്രവർത്തിപ്പിക്കുന്നത് നയ-പൊരുത്തക്കേടിന്റെ പരിഹാരമല്ല; ഉദ്ദേശിച്ച നയം സേവനത്തിന്റെ ഉടമ മുഖേന പ്രകടിപ്പിക്കുന്നതാണ് പരിഹാരം.