Kāpēc portu skenēšana mainās, palaižot to ar sudo

Nmap ne vienmēr nosūta to pakešu, kuru, jūsuprāt, esat pieprasījis. Kad neapstrādātās ligzdas nav pieejamas, tas aizstāj noklusējuma SYN skenēšanu ar TCP connect skenēšanu, tāpēc palaišana kā parasts lietotājs un palaišana zem sudo var atbildēt uz dažādiem jautājumiem par vienu un to pašu portu. Rezultāti izskatās kā tiesību problēma, un parasti tie ir metodes maiņa. Metodes skaidra norādīšana ir vienīgais veids, kā abus palaišanas gadījumus vispār salīdzināt.

Divas zondes, viens ports, dažādi koda ceļi

SYN skenēšana pati veido TCP galveni, nosūta to no neapstrādātas ligzdas un nolasa atbildi no tīkla, pirms kodola TCP steks jebkad reģistrē pabeigtu savienojumu. Connect skenēšana lūdz operētājsistēmu atvērt parastu ligzdu un ziņo, ko atgriež connect(). Abas var nosaukt portu par atvērtu, taču tikai viena atstāj pusatvērtu mēģinājumu un tikai vienai attiecas uz ligzdas līmeņa politika, kas saistīta ar sūtošo procesu.

Neapstrādātajam ceļam nepieciešams CAP_NET_RAW, tāpēc noklusējuma skenēšana klusi pasliktinās, kad šīs iespējas trūkst. Nmap skenēšanas tehniku uzziņa dokumentē šo aizstāšanu: connect skenēšana ir rezerves variants, jo tai vispār nav vajadzīgas īpašas tiesības. Aizstāšana notiek bez brīdinājuma lielākajā daļā palaišanas gadījumu, un tieši tāpēc to ir tik viegli nepareizi nolasīt. Kad zināt, ka rezerves variants pastāv, „atvērts kā root, aizvērts kā lietotājs“ pārstāj skanēt kā tiesību kļūda un sāk skanēt kā divi dažādi mērījumi.

Ko sudo patiešām maina skenēšanā

Tiesību paaugstināšana atjauno neapstrādātās ligzdas ceļu, un tas maina vairāk nekā spriedumu. Avota porta izvēle, pakešu laiks, atkārtotas sūtīšanas uzvedība un filtrētās atbildes klasificēšanas veids visi nāk no cita koda. Starpmezgls, kas ierobežo SYN biežumu, abus palaišanas gadījumus izturas nevienlīdzīgi arī tad, kad mērķa resursdators ir identisks.

Žurnalēšana mērķa pusē arī atšķiras. Pabeigta rokasspiediena ir redzama pakalpojumam un jebkurai ligzdu uzskaitei, savukārt atiestatīta pusatvērta zonde bieži nav. Ja salīdzināt palaišanas ar resursdatoru, kura žurnālus arī lasāt, daļa redzamās atšķirības ir pats novērojums.

Saglabājiet metodi nemainīgu abos palaišanas gadījumos

Uzspiediet to pašu tehniku abos izsaukumos, un salīdzinājums sāks kaut ko nozīmēt. Karodziņš -sT skaidri pieprasa connect skenēšanu, -Pn noņem resursdatoru atklāšanu, -n noņem vārdu atrisināšanu, un viens -p noņem portu saraksta atšķirības.

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

Aizstājiet adresi un portu ar resursdatoru, kuru jums ir atļauts testēt; iepriekš minētais dokumentācijas diapazons ir paraugs, nevis mērķis. Ja abi palaišanas gadījumi tagad sakrīt, sākotnējā atšķirība nāca no skenēšanas metodes. Ja tie joprojām nesakrīt, kaut kas cits klasificē trafiku, un nākamā sadaļa ir vieta, kur skatīties.

Konta konteksts nav tikai tiesību karodziņš

VPN izvietojums var klasificēt paketes pēc UID, pēc cgroup vai pēc noteikuma, kas saistīts ar procesu, kurš atvēra ligzdu. Tad root un lietotāja trafiks iziet pa dažādām maršrutēšanas tabulām vai nonāk dažādos noteikumu kopumos, un neviena skenēšanas metodes disciplīna tos nesaskaņo.

Pārbaudiet politiku, nevis tiesības. Linux sistēmā nftables to izsaka ar meta skuid, bet iptables ar īpašnieka atbilstību, un jebkurš no tiem var nosūtīt vienu UID caur tuneli, kamēr otrs turpina izmantot fizisko noklusējuma marš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

Apstipriniet zondi, pirms salīdzināt rezultātus

Pirms izdarāt secinājumus, pierādiet, kura zonde darbojās. Nmap nosauc tehniku savā izvadē, un --reason pievieno pierādījumu aiz katra stāvokļa, un tieši šī daļa pasaka, vai rokasspiediens patiešām tika pabeigts.

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

Divi palaišanas gadījumi, kas ziņo vienu un to pašu stāvokli dažādu iemeslu dēļ, nav pretruna, un divi palaišanas gadījumi, kas ziņo dažādus stāvokļus viena iemesla dēļ, norāda uz maršrutēšanu vai politiku, nevis uz skenēšanu. Saglabājiet mērķi, portu, nosaukumvietu un laiku identiskus, pēc tam mainiet vienu mainīgo vienlaikus. Pakalpojuma palaišana kā root nav politikas neatbilstības labojums; labojums ir izteikt paredzēto politiku pakalpojuma īpašnieka ceļā.