De ce o scanare de porturi se schimbă când o rulezi cu sudo

Nmap nu trimite întotdeauna pachetul pe care crezi că l-ai cerut. Când socketurile brute nu sunt disponibile, înlocuiește scanarea SYN implicită cu o scanare TCP connect, așa că o rulare ca utilizator obișnuit și una sub sudo pot răspunde la întrebări diferite despre același port. Rezultatele arată ca o problemă de permisiuni, și de obicei sunt o schimbare de metodă. A face metoda explicită este singurul mod de a compara cele două rulări.

Două sonde, un port, căi de cod diferite

O scanare SYN construiește singură antetul TCP, îl trimite dintr-un socket brut și citește răspunsul din rețea înainte ca stiva TCP a nucleului să înregistreze vreodată o conexiune finalizată. O scanare connect cere sistemului de operare să deschidă un socket obișnuit și raportează ce returnează connect(). Ambele pot numi un port deschis, dar doar una lasă o încercare pe jumătate deschisă și doar una se supune politicii la nivel de socket legată de procesul care trimite.

Calea brută necesită CAP_NET_RAW, motiv pentru care scanarea implicită se degradează în tăcere când acea capacitate lipsește. Propria referință de tehnici de scanare a Nmap documentează înlocuirea: scanarea connect este varianta de rezervă pentru că nu necesită niciun privilegiu special. Schimbarea are loc fără avertisment în majoritatea rulărilor, și exact asta o face atât de ușor de citit greșit. Odată ce știi că varianta de rezervă există, „deschis ca root, închis ca utilizator” nu mai sună a eroare de permisiuni și începe să sune a două măsurători diferite.

Ce schimbă sudo de fapt în scanare

Ridicarea privilegiilor restaurează calea socketului brut, iar asta schimbă mai mult decât verdictul. Alegerea portului sursă, temporizarea pachetelor, comportamentul la retransmisie și modul de clasificare a unui răspuns filtrat provin toate din cod diferit. Un echipament intermediar care limitează rata SYN tratează cele două rulări inegal chiar și când gazda destinație este identică.

Și înregistrarea în jurnal pe partea destinației diferă. Un handshake finalizat este vizibil pentru serviciu și pentru orice contabilitate a socketurilor, în timp ce o sondă pe jumătate deschisă resetată adesea nu este. Dacă compari rulări față de o gazdă ale cărei jurnale le citești și tu, o parte din diferența pe care o vezi este observarea în sine.

Păstrează metoda constantă în ambele rulări

Impune aceeași tehnică în ambele apeluri și comparația începe să însemne ceva. Flagul -sT cere explicit scanarea connect, -Pn elimină descoperirea gazdelor, -n elimină rezolvarea numelor, iar un singur -p elimină diferențele din lista de porturi.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

Înlocuiește adresa și portul cu o gazdă pe care ai voie să o testezi; intervalul de documentație de mai sus este un exemplu, nu o țintă. Dacă cele două rulări coincid acum, diferența inițială venea din metoda de scanare. Dacă încă nu coincid, altceva clasifică traficul, iar secțiunea următoare este locul unde trebuie să te uiți.

Contextul contului nu este doar un flag de privilegii

Un deployment VPN poate clasifica pachetele după UID, după cgroup sau după o regulă legată de procesul care a deschis socketul. Atunci traficul de root și cel al utilizatorului ies prin tabele de rutare diferite sau lovesc seturi de reguli diferite, și nicio disciplină a metodei de scanare nu le împacă.

Inspectează politica, nu privilegiul. Pe Linux, nftables exprimă asta cu meta skuid, iar iptables cu potrivirea proprietarului, și oricare dintre ele poate trimite un singur UID printr-un tunel în timp ce celălalt continuă să folosească ruta fizică implicită.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

Confirmă sonda înainte de a compara rezultatele

Înainte de a trage concluzii, dovedește ce sondă a rulat. Nmap numește tehnica în propria ieșire, iar --reason adaugă dovada din spatele fiecărei stări, care este partea ce îți spune dacă un handshake s-a finalizat cu adevărat.

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

Două rulări care raportează aceeași stare din motive diferite nu sunt o contradicție, iar două rulări care raportează stări diferite din același motiv indică rutarea sau politica, nu scanarea. Păstrează identice destinația, portul, spațiul de nume și temporizarea, apoi schimbă o singură variabilă pe rând. Rularea serviciului ca root nu este reparația pentru o discrepanță de politică; reparația este să exprimi politica dorită prin proprietarul serviciului.