Varför en portskanning ändras när du kör den med sudo

När råa socketar inte är tillgängliga byter Nmap tyst ut en SYN-skanning mot en TCP connect-skanning, så root och en vanlig användare mäter olika vägar.

Nmap skickar inte alltid det paket du tror att du bad om. När råa socketar inte är tillgängliga ersätter den standardskanningen med en TCP connect-skanning, så en körning som vanlig användare och en körning under sudo kan svara på olika frågor om samma port. Resultaten ser ut som ett rättighetsproblem, och de är oftast en metodändring. Att göra metoden explicit är det enda sättet att alls jämföra de två körningarna.

Två prober, en port, olika kodvägar

En SYN-skanning bygger TCP-huvudet själv, skickar det från en rå socket och läser svaret från nätet innan kernens TCP-stack någonsin registrerar en slutförd anslutning. En connect-skanning ber operativsystemet öppna en vanlig socket och rapporterar vad connect() returnerar. Båda kan kalla en port öppen, men bara en lämnar ett halvöppet försök och bara en omfattas av socketnivåpolicy kopplad till den sändande processen.

Råvägen kräver CAP_NET_RAW, och därför försämras standardskanningen tyst när den förmågan saknas. Nmaps egen referens för skanningstekniker dokumenterar utbytet: connect-skanningen är reserven eftersom den inte kräver några särskilda rättigheter alls. Byten sker utan varning i de flesta körningar, och det är just det som gör den så lätt att felläsa. När du väl vet att reserven finns slutar ”öppen som root, stängd som användare” låta som en rättighetsbugg och börjar låta som två olika mätningar.

Vad sudo faktiskt ändrar i skanningen

Förhöjda rättigheter återställer råsocketvägen, och det ändrar mer än domen. Val av källport, pakettiming, beteende vid omsändning och sättet en filtrerad respons klassas på kommer alla från annan kod. En mellanbox som begränsar SYN-frekvensen behandlar de två körningarna olika även när målvärden är identisk.

Loggning på målsidan skiljer sig också. En slutförd handskakning syns för tjänsten och för all socketredovisning, medan en återställd halvöppen sond ofta inte gör det. Om du jämför körningar mot en värd vars loggar du också läser, är en del av skillnaden du ser själva observationen.

Håll metoden konstant i båda körningarna

Tvinga fram samma teknik i båda anropen och jämförelsen börjar betyda något. Flaggan -sT begär uttryckligen connect-skanning, -Pn tar bort värdidentifiering, -n tar bort namnmatchning, och en enda -p tar bort skillnader i portlistan.

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

Byt ut adressen och porten mot en värd du har tillstånd att testa; dokumentationsintervallet ovan är ett exempel, inte ett mål. Om de två körningarna nu stämmer överens kom den ursprungliga skillnaden från skanningsmetoden. Om de fortfarande inte stämmer överens klassar något annat trafiken, och nästa avsnitt är där du ska titta.

Kontokontext är inte bara en rättighetsflagga

En VPN-distribution kan klassificera paket efter UID, efter cgroup eller efter en regel kopplad till processen som öppnade socketen. Då lämnar roottrafik och användartrafik olika routingtabeller eller träffar olika regeluppsättningar, och ingen skanningsmetoddisciplin förenar dem.

Undersök policyn i stället för rättigheten. På Linux uttrycker nftables detta med meta skuid och iptables med ägarmatchning, och båda kan skicka en enda UID genom en tunnel medan den andra fortsätter använda den fysiska standardvägen.

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

Bekräfta sonden innan du jämför resultat

Innan du drar slutsatser, bevisa vilken sond som kördes. Nmap namnger tekniken i sin egen utdata, och --reason lägger till beviset bakom varje tillstånd, vilket är den del som säger om en handskakning faktiskt slutfördes.

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

Två körningar som rapporterar samma tillstånd av olika skäl är inte en motsägelse, och två körningar som rapporterar olika tillstånd av samma skäl pekar på routing eller policy snarare än på skanningen. Håll mål, port, namnrymd och timing identiska och ändra sedan en variabel i taget. Att köra tjänsten som root är inte reparationen för en policyavvikelse; att uttrycka den avsedda policyn genom tjänstens ägare är det.

Relaterade artiklar