Perché una scansione delle porte cambia quando la esegui con sudo

Nmap non invia sempre il pacchetto che credi di aver richiesto. Quando i socket raw non sono disponibili, sostituisce la scansione SYN predefinita con una scansione TCP connect, così un’esecuzione come utente normale e una con sudo possono rispondere a domande diverse sulla stessa porta. I risultati sembrano un problema di permessi, e di solito sono un cambio di metodo. Rendere esplicito il metodo è l’unico modo per confrontare le due esecuzioni.

Due sonde, una porta, percorsi di codice diversi

Una scansione SYN costruisce da sé l’intestazione TCP, la invia da un socket raw e legge la risposta dalla rete prima che lo stack TCP del kernel registri mai una connessione completata. Una scansione connect chiede al sistema operativo di aprire un socket ordinario e riporta ciò che connect() restituisce. Entrambe possono etichettare una porta come aperta, ma solo una lascia un tentativo semiaperto e solo una è soggetta alla politica a livello di socket legata al processo che invia.

Il percorso raw richiede CAP_NET_RAW, ed è per questo che la scansione predefinita degrada in silenzio quando quella capacità manca. La guida alle tecniche di scansione di Nmap documenta la sostituzione: la scansione connect è il ripiego perché non richiede alcun privilegio speciale. Lo scambio avviene senza avviso nella maggior parte delle esecuzioni, ed è proprio questo a renderlo così facile da fraintendere. Una volta che sai che il ripiego esiste, «aperta come root, chiusa come utente» smette di suonare come un bug dei permessi e comincia a suonare come due misurazioni diverse.

Che cosa cambia davvero sudo nella scansione

Elevare i privilegi ripristina il percorso del socket raw, e questo cambia più del verdetto. La scelta della porta sorgente, il timing dei pacchetti, il comportamento di ritrasmissione e il modo in cui una risposta filtrata viene classificata provengono tutti da codice diverso. Un apparato intermedio che limita la frequenza dei SYN tratta le due esecuzioni in modo diseguale anche quando l’host di destinazione è identico.

Anche la registrazione lato destinazione diverge. Un handshake completato è visibile al servizio e a qualsiasi contabilità dei socket, mentre una sonda semiaperta azzerata spesso non lo è. Se confronti esecuzioni verso un host di cui leggi anche i log, parte della differenza che osservi è l’osservazione stessa.

Mantieni costante il metodo in entrambe le esecuzioni

Forza la stessa tecnica in entrambe le invocazioni e il confronto inizia a significare qualcosa. L’opzione -sT richiede esplicitamente la scansione connect, -Pn elimina l’individuazione degli host, -n elimina la risoluzione dei nomi e un solo -p elimina le differenze nell’elenco delle porte.

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

Sostituisci l’indirizzo e la porta con un host che sei autorizzato a testare; l’intervallo di documentazione sopra è un segnaposto, non un obiettivo. Se le due esecuzioni ora concordano, la differenza originale veniva dal metodo di scansione. Se continuano a discordare, qualcos’altro sta classificando il traffico, e la sezione successiva è dove guardare.

Il contesto dell’account non è solo un flag di privilegi

Un deployment VPN può classificare i pacchetti per UID, per cgroup o per una regola associata al processo che ha aperto il socket. Allora il traffico di root e quello dell’utente escono da tabelle di routing diverse o incontrano insiemi di regole diversi, e nessuna disciplina di metodo di scansione li riconcilia.

Ispeziona la politica invece del privilegio. Su Linux, nftables lo esprime con meta skuid e iptables con la corrispondenza del proprietario, e ciascuno dei due può inviare un singolo UID dentro un tunnel mentre l’altro continua a usare la rotta fisica predefinita.

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

Conferma la sonda prima di confrontare i risultati

Prima di trarre conclusioni, dimostra quale sonda è stata eseguita. Nmap nomina la tecnica nel proprio output, e --reason aggiunge la prova dietro ogni stato, che è la parte che ti dice se un handshake si è davvero completato.

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

Due esecuzioni che riportano lo stesso stato per ragioni diverse non sono una contraddizione, e due esecuzioni che riportano stati diversi per la stessa ragione indicano il routing o la politica, non la scansione. Mantieni identici destinazione, porta, spazio dei nomi e timing, poi cambia una variabile alla volta. Eseguire il servizio come root non è la riparazione di una discrepanza di politica; la riparazione è esprimere la politica desiderata tramite il proprietario del servizio.