Waarom een poortscan verandert wanneer je die met sudo uitvoert

Nmap verstuurt niet altijd het pakket dat je denkt te hebben aangevraagd. Wanneer raw sockets niet beschikbaar zijn, vervangt het de standaard SYN-scan door een TCP connect-scan, zodat een run als gewone gebruiker en een run onder sudo verschillende vragen over dezelfde poort kunnen beantwoorden. De resultaten lijken op een rechtenprobleem, en meestal zijn het een methodeverandering. De methode expliciet maken is de enige manier om de twee runs überhaupt te vergelijken.

Twee probes, één poort, verschillende codepaden

Een SYN-scan bouwt de TCP-header zelf, verstuurt die vanuit een raw socket en leest het antwoord van de draad voordat de TCP-stack van de kernel ooit een voltooide verbinding registreert. Een connect-scan vraagt het besturingssysteem een gewone socket te openen en rapporteert wat connect() teruggeeft. Beide kunnen een poort open noemen, maar slechts één laat een halfopen poging achter en slechts één is onderworpen aan socketbeleid dat aan het verzendende proces is gekoppeld.

Het raw-pad vereist CAP_NET_RAW, en daarom verslechtert de standaardscan stilletjes wanneer die mogelijkheid ontbreekt. Nmaps eigen naslagwerk over scantechnieken documenteert de vervanging: de connect-scan is de terugvaloptie omdat die helemaal geen speciale rechten nodig heeft. De wissel gebeurt in de meeste runs zonder waarschuwing, en dat maakt het zo makkelijk om verkeerd te lezen. Zodra je weet dat de terugval bestaat, klinkt “open als root, dicht als gebruiker” niet meer als een rechtenfout en begint het als twee verschillende metingen te klinken.

Wat sudo feitelijk verandert in de scan

Rechten verhogen herstelt het raw-socketpad, en dat verandert meer dan het oordeel. Keuze van bronpoort, pakket-timing, gedrag bij herverzending en de manier waarop een gefilterd antwoord wordt geclassificeerd komen allemaal uit andere code. Een middlebox die SYN's beperkt, behandelt de twee runs ongelijk, zelfs wanneer de doelserver identiek is.

Logging aan de doelzijde wijkt ook af. Een voltooide handshake is zichtbaar voor de dienst en voor elke socketadministratie, terwijl een gereset halfopen probe dat vaak niet is. Als je runs vergelijkt tegen een host waarvan je ook de logs leest, is een deel van het verschil dat je ziet de waarneming zelf.

Houd de methode constant in beide runs

Forceer dezelfde techniek in beide aanroepen en de vergelijking begint iets te betekenen. De vlag -sT vraagt expliciet om een connect-scan, -Pn verwijdert hostontdekking, -n verwijdert naamresolutie, en één enkele -p verwijdert verschillen in de poortenlijst.

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

Vervang het adres en de poort door een host die je mag testen; het documentatiebereik hierboven is een voorbeeld, geen doelwit. Als de twee runs nu overeenkomen, kwam het oorspronkelijke verschil van de scanmethode. Als ze het nog steeds oneens zijn, classificeert iets anders het verkeer, en de volgende sectie is waar je moet kijken.

Accountcontext is niet alleen een rechtenvlag

Een VPN-implementatie kan pakketten classificeren op UID, op cgroup of op een regel die aan het proces is gekoppeld dat de socket heeft geopend. Dan verlaten rootverkeer en gebruikersverkeer verschillende routingtabellen of treffen ze verschillende regelsets, en geen enkele scannethode-discipline verzoent ze.

Onderzoek het beleid in plaats van het recht. Op Linux drukt nftables dat uit met meta skuid en iptables met de eigenaar-match, en elk van beide kan één UID door een tunnel sturen terwijl de andere het fysieke standaardpad blijft gebruiken.

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

Bevestig de probe voordat je resultaten vergelijkt

Voordat je conclusies trekt, bewijs welke probe liep. Nmap noemt de techniek in zijn eigen uitvoer, en --reason voegt het bewijs achter elke toestand toe, en dat is het deel dat je vertelt of een handshake echt is voltooid.

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

Twee runs die dezelfde toestand om verschillende redenen melden, zijn geen tegenspraak, en twee runs die verschillende toestanden om dezelfde reden melden, wijzen op routing of beleid in plaats van op de scan. Houd bestemming, poort, naamruimte en timing identiek en verander dan één variabele per keer. De dienst als root draaien is niet de reparatie voor een beleidsafwijking; het beoogde beleid via de eigenaar van de dienst uitdrukken is dat.