Zašto se skeniranje portova mijenja kada ga pokrenete sa sudo
Kada sirovi soketi nisu dostupni, Nmap tiho zamjenjuje SYN skeniranje TCP connect skeniranjem, pa root i obični korisnik mjere različite putanje.
Nmap ne šalje uvijek paket za koji mislite da ste ga tražili. Kada sirovi soketi nisu dostupni, zamjenjuje zadano SYN skeniranje TCP connect skeniranjem, pa pokretanje kao obični korisnik i pokretanje pod sudo mogu odgovoriti na različita pitanja o istom portu. Rezultati izgledaju kao problem s dozvolama, a obično su promjena metode. Izričito navođenje metode jedini je način da se dva pokretanja uopće uporede.
Dvije sonde, jedan port, različite putanje koda
SYN skeniranje samo gradi TCP zaglavlje, šalje ga sa sirovog soketa i čita odgovor s mreže prije nego što TCP stek kernela uopće zabilježi završenu vezu. Connect skeniranje traži od operativnog sistema da otvori običan soket i prijavljuje šta connect() vrati. Oba mogu nazvati port otvorenim, ali samo jedan ostavlja poluotvoreni pokušaj i samo jedan podliježe politici na nivou soketa vezanoj za proces koji šalje.
Sirova putanja zahtijeva CAP_NET_RAW, zato zadano skeniranje tiho degradira kada ta mogućnost nedostaje. Nmapova vlastita referenca za tehnike skeniranja dokumentuje zamjenu: connect skeniranje je rezerva jer ne zahtijeva nikakve posebne privilegije. Zamjena se u većini pokretanja događa bez upozorenja, i upravo to je čini tako lakom za pogrešno čitanje. Kada znate da rezerva postoji, “otvoreno kao root, zatvoreno kao korisnik” prestaje zvučati kao greška u dozvolama i počinje zvučati kao dva različita mjerenja.
Šta sudo zapravo mijenja u skeniranju
Podizanje privilegija vraća putanju sirovog soketa, a to mijenja više od presude. Odabir izvornog porta, tajming paketa, ponašanje pri ponovnom slanju i način na koji se filtrirani odgovor klasifikuje dolaze iz različitog koda. Posrednik koji ograničava brzinu SYN-ova tretira dva pokretanja nejednako čak i kada je odredišni host identičan.
Zapisivanje na strani odredišta takođe se razilazi. Završeni handshake vidljiv je servisu i svakom obračunu soketa, dok resetovana poluotvorena sonda često nije. Ako upoređujete pokretanja prema hostu čije zapise takođe čitate, dio razlike koji vidite je samo opažanje.
Držite metodu konstantnom u oba pokretanja
Nametnite istu tehniku u oba poziva i poređenje počinje nešto značiti. Zastavica -sT izričito traži connect skeniranje, -Pn uklanja otkrivanje hosta, -n uklanja razrješavanje imena, a jedan -p uklanja razlike u listi portova.
nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77
Zamijenite adresu i port hostom koji smijete testirati; dokumentacijski raspon iznad je primjer, a ne meta. Ako se dva pokretanja sada slažu, prvobitna razlika dolazila je od metode skeniranja. Ako se i dalje ne slažu, nešto drugo klasifikuje saobraćaj, a sljedeći odjeljak je mjesto za traženje.
Kontekst računa nije samo zastavica privilegija
VPN raspoređivanje može klasifikovati pakete po UID-u, po cgroup-u ili po pravilu vezanom za proces koji je otvorio soket. Tada root saobraćaj i korisnički saobraćaj izlaze kroz različite tablice rutiranja ili udaraju u različite skupove pravila, i nikakva disciplina metode skeniranja ih ne može pomiriti.
Ispitajte politiku, a ne privilegiju. Na Linuxu nftables to izražava pomoću meta skuid, a iptables poklapanjem vlasnika, i bilo koje od njih može poslati jedan UID kroz tunel dok drugo nastavlja koristiti fizičku zadanu rutu.
sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77
Potvrdite sondu prije nego što uporedite rezultate
Prije izvođenja zaključaka dokažite koja je sonda radila. Nmap imenuje tehniku u vlastitom izlazu, a --reason dodaje dokaz iza svakog stanja, što je dio koji vam kaže je li handshake zaista završen.
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 pokretanja koja prijavljuju isto stanje iz različitih razloga nisu proturječnost, a dva pokretanja koja prijavljuju različita stanja iz istog razloga upućuju na rutiranje ili politiku, a ne na skeniranje. Držite odredište, port, imenski prostor i tajming identičnim, pa mijenjajte jednu varijablu po jednu. Pokretanje servisa kao root nije popravka za neusklađenost politike; popravka je izraziti namjeravanu politiku kroz vlasnika servisa.