Proč se skenování portů změní při spuštění se sudo

Nmap ne vždy odešle paket, o kterém si myslíte, že jste ho požadovali. Když nejsou surové sockety dostupné, nahradí výchozí skenování SYN skenováním TCP connect, takže běh pod běžným uživatelem a běh pod sudo mohou odpovídat na různé otázky o stejném portu. Výsledky vypadají jako problém s oprávněními, obvykle jsou ale změnou metody. Udělat metodu explicitní je jediný způsob, jak oba běhy vůbec porovnat.

Dvě sondy, jeden port, různé cesty kódu

Skenování SYN si TCP hlavičku sestaví samo, odešle ji ze surového socketu a přečte odpověď ze sítě dřív, než TCP zásobník jádra vůbec zaznamená dokončené spojení. Skenování connect požádá operační systém o otevření běžného socketu a hlásí, co vrátí connect(). Obě mohou označit port jako otevřený, ale jen jedno zanechá polootevřený pokus a jen jedno podléhá politice na úrovni socketu navázané na odesílající proces.

Surová cesta vyžaduje CAP_NET_RAW, a proto se výchozí skenování tiše zhorší, když tato schopnost chybí. Vlastní příručka k technikám skenování od Nmap tuto záměnu dokumentuje: skenování connect je náhradou, protože nevyžaduje žádná zvláštní oprávnění. Záměna probíhá ve většině běhů bez varování, a právě proto se tak snadno přehlédne. Jakmile víte, že náhrada existuje, “otevřeno jako root, zavřeno jako uživatel” přestane znít jako chyba oprávnění a začne znít jako dvě různá měření.

Co sudo ve skenování skutečně mění

Zvýšení oprávnění obnoví cestu surového socketu, a to mění víc než verdikt. Volba zdrojového portu, časování paketů, chování při opakovaném přenosu i způsob klasifikace filtrované odpovědi pocházejí z jiného kódu. Prostředník, který omezuje rychlost SYN, zachází s oběma běhy nestejně, i když je cílový hostitel totožný.

Protokolování na straně cíle se také rozchází. Dokončený handshake je viditelný pro službu i pro jakékoli účtování socketů, zatímco resetovaná polootevřená sonda často ne. Pokud porovnáváte běhy proti hostiteli, jehož protokoly také čtete, část rozdílu, který vidíte, je samo pozorování.

Udržte metodu konstantní v obou běhech

Vynuťte stejnou techniku v obou voláních a porovnání začne něco znamenat. Přepínač -sT vyžaduje skenování connect výslovně, -Pn odstraňuje zjišťování hostitelů, -n odstraňuje překlad jmen a jediný -p odstraňuje rozdíly v seznamu portů.

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

Nahraďte adresu a port hostitelem, který smíte testovat; rozsah z dokumentace výše je zástupný, ne cíl. Pokud se oba běhy nyní shodují, původní rozdíl pocházel z metody skenování. Pokud se stále neshodují, provoz klasifikuje něco jiného a další oddíl je místem, kde hledat.

Kontext účtu není jen přepínač oprávnění

Nasazení VPN může klasifikovat pakety podle UID, podle cgroup nebo podle pravidla navázaného na proces, který socket otevřel. Provoz rootu a provoz uživatele pak vycházejí jinými směrovacími tabulkami nebo narážejí na jiné sady pravidel a žádná disciplína metody skenování je nesmíří.

Zkoumejte politiku, ne oprávnění. V Linuxu to nftables vyjadřuje pomocí meta skuid a iptables shodou vlastníka, a kterékoli z nich může poslat jediné UID tunelem, zatímco druhé dál používá fyzickou výchozí trasu.

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

Potvrďte sondu, než porovnáte výsledky

Než vyvodíte závěry, dokažte, která sonda běžela. Nmap techniku pojmenuje ve svém vlastním výstupu a --reason přidá důkaz za každým stavem, což je část, která vám řekne, zda se handshake skutečně dokončil.

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

Dva běhy, které hlásí stejný stav z různých důvodů, si neodporují, a dva běhy, které hlásí různé stavy ze stejného důvodu, ukazují na směrování nebo politiku, ne na skenování. Udržte cíl, port, jmenný prostor a časování totožné, pak měňte jednu proměnnou po druhé. Spuštění služby jako root není opravou nesouladu politiky; opravou je vyjádřit zamýšlenou politiku prostřednictvím vlastníka služby.