Hvorfor en portskanning endrer seg når du kjører den med sudo

Nmap sender ikke alltid pakken du tror du ba om. Når råsokler ikke er tilgjengelige, erstatter den standardskanningen med en TCP connect-skanning, så en kjøring som vanlig bruker og en kjøring under sudo kan svare på forskjellige spørsmål om samme port. Resultatene ser ut som et rettighetsproblem, og de er vanligvis en metodeendring. Å gjøre metoden eksplisitt er den eneste måten å sammenligne de to kjøringene i det hele tatt.

To prober, én port, forskjellige kodestier

En SYN-skanning bygger TCP-headeren selv, sender den fra en råsokkel og leser svaret fra nettet før kjernens TCP-stack noen gang registrerer en fullført forbindelse. En connect-skanning ber operativsystemet åpne en vanlig sokkel og rapporterer hva connect() returnerer. Begge kan kalle en port åpen, men bare én etterlater et halvåpent forsøk, og bare én er underlagt sokkel-nivå-policy knyttet til prosessen som sender.

Råstien krever CAP_NET_RAW, og derfor forringes standardskanningen stille når den egenskapen mangler. Nmaps egen referanse for skanningsteknikker dokumenterer erstatningen: connect-skanning er reservevalget fordi det ikke krever noen spesielle rettigheter i det hele tatt. Byttet skjer uten varsel i de fleste kjøringer, og det er nettopp det som gjør det så lett å feiltolke. Når du først vet at reservevalget finnes, slutter «åpen som root, lukket som bruker» å høres ut som en rettighetsfeil og begynner å høres ut som to forskjellige målinger.

Hva sudo egentlig endrer i skanningen

Forhøyede rettigheter gjenoppretter råsokkelstien, og det endrer mer enn dommen. Valg av kildeport, pakketiming, videresendingsatferd og måten en filtrert respons klassifiseres på kommer alle fra forskjellig kode. En mellomvare som begrenser SYN-frekvensen behandler de to kjøringene ulikt selv når destinasjonsverten er identisk.

Logging på destinasjonssiden avviker også. Et fullført håndtrykk er synlig for tjenesten og for all sokkelregnskap, mens en tilbakestilt halvåpen probe ofte ikke er det. Hvis du sammenligner kjøringer mot en vert du også leser loggene til, er en del av forskjellen du ser selve observasjonen.

Hold metoden konstant i begge kjøringene

Tving gjennom samme teknikk i begge kall, og sammenligningen begynner å bety noe. Flagget -sT ber uttrykkelig om connect-skanning, -Pn fjerner vertsoppdagelse, -n fjerner navneoppslag, og et enkelt -p fjerner forskjeller i portlisten.

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

Bytt ut adressen og porten med en vert du har tillatelse til å teste; dokumentasjonsområdet over er et eksempel, ikke et mål. Hvis de to kjøringene nå er enige, kom den opprinnelige forskjellen fra skannemetoden. Hvis de fortsatt er uenige, er det noe annet som klassifiserer trafikken, og neste avsnitt er stedet å se.

Kontokontekst er ikke bare et rettighetsflagg

En VPN-utrulling kan klassifisere pakker etter UID, etter cgroup eller etter en regel knyttet til prosessen som åpnet sokkelen. Da forlater root-trafikk og brukertrafikk forskjellige rutetabeller eller treffer forskjellige regelsett, og ingen skannemetodedisiplin forener dem.

Undersøk policyen i stedet for rettigheten. På Linux uttrykker nftables dette med meta skuid og iptables med eiersamsvar, og begge kan sende én enkelt UID ned gjennom en tunnel mens den andre fortsetter å bruke den fysiske standardruten.

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

Bekreft proben før du sammenligner resultater

Før du trekker konklusjoner, bevis hvilken probe som kjørte. Nmap navngir teknikken i sin egen utdata, og --reason legger til beviset bak hver tilstand, som er den delen som forteller deg om et håndtrykk faktisk ble fullført.

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

To kjøringer som rapporterer samme tilstand av forskjellige grunner, er ikke en motsetning, og to kjøringer som rapporterer forskjellige tilstander av samme grunn, peker på ruting eller policy snarere enn på skanningen. Hold destinasjon, port, navnerom og timing identiske, og endre så én variabel om gangen. Å kjøre tjenesten som root er ikke reparasjonen for et policy-avvik; å uttrykke den tiltenkte policyen gjennom tjenestens eier er det.