Waarom ’n poortskandering verander wanneer jy dit met sudo uitvoer

Nmap stuur nie altyd die pakket wat jy dink jy gevra het nie. Wanneer rou sokkels onbeskikbaar is, vervang dit die standaard SYN-skandering met ’n TCP-connect-skandering, sodat ’n uitvoering as jou gewone gebruiker en een onder sudo verskillende vrae oor dieselfde poort kan beantwoord. Die resultate lyk soos ’n regteprobleem, en hulle is gewoonlik ’n metodeverandering. Om die metode eksplisiet te maak, is die enigste manier om die twee uitvoerings hoegenaamd te vergelyk.

Twee sondes, een poort, verskillende kodepaaie

’n SYN-skandering bou die TCP-kop self, stuur dit uit ’n rou sokkel en lees die antwoord van die draad af voordat die kern se TCP-stapel ooit ’n voltooide verbinding aanteken. ’n Connect-skandering vra die bedryfstelsel om ’n gewone sokkel oop te maak en rapporteer wat connect() teruggee. Albei kan ’n poort oop noem, maar net een laat ’n halfope poging agter en net een is onderhewig aan sokkelvlakbeleid wat aan die stuipproses gekoppel is.

Die rou pad benodig CAP_NET_RAW, en daarom verswak die standaard skandering stilweg wanneer daardie vermoë ontbreek. Nmap se eie verwysing oor skanderingstegnieke dokumenteer die vervanging: connect-skandering is die terugval omdat dit hoegenaamd geen spesiale voorregte nodig het nie. Die omruiling gebeur in die meeste uitvoerings sonder ’n waarskuwing, en dit is wat dit so maklik maak om verkeerd te lees. Sodra jy weet die terugval bestaan, hou “oop as root, toe as gebruiker” op om soos ’n toestemmingsfout te klink en begin dit soos twee verskillende metings klink.

Wat sudo werklik in die skandering verander

Om voorregte te verhoog herstel die rou-sokkelpad, en dit verander meer as die uitspraak. Bronpoortkeuse, pakkettydsberekening, herversendinggedrag en die manier waarop ’n gefiltreerde antwoord geklassifiseer word, kom almal uit verskillende kode. ’n Middelkas wat SYN’s beperk, behandel die twee uitvoerings ongelyk selfs wanneer die bestemmingsgasheer identies is.

Gasheerkant-logging wyk ook af. ’n Voltooide handdruk is sigbaar vir die diens en vir enige sokkelrekeningkunde, terwyl ’n herstelde halfope sonde dikwels nie is nie. As jy uitvoerings vergelyk teen ’n gasheer wie se logs jy ook lees, is deel van die verskil wat jy sien die waarneming self.

Hou die metode konstant in albei uitvoerings

Forseer dieselfde tegniek in albei aanroepe en die vergelyking begin iets beteken. Die vlag -sT versoek connect-skandering uitdruklik, -Pn verwyder gasheerontdekking, -n verwyder naamoplossing, en ’n enkele -p verwyder poortlysverskille.

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

Ruil die adres en poort om vir ’n gasheer wat jy mag toets; die dokumentasiebereik hierbo is ’n plekhouer, nie ’n teiken nie. As die twee uitvoerings nou ooreenstem, het die oorspronklike verskil van die skanderingsmetode gekom. As hulle steeds verskil, klassifiseer iets anders die verkeer, en die volgende afdeling is waar om te kyk.

Konteks van die rekening is nie net ’n voorregvlag nie

’n VPN-ontplooiing kan pakkette klassifiseer volgens UID, volgens cgroup, of volgens ’n reël wat aan die proses gekoppel is wat die sokkel oopgemaak het. Root-verkeer en gebruikersverkeer verlaat dan verskillende roetertabelle of tref verskillende reëlstelle, en geen hoeveelheid skanderingsmetode-dissipline versoen hulle nie.

Ondersoek die beleid eerder as die voorreg. Op Linux druk nftables dit uit met meta skuid en iptables met die eienaar-passing, en enigeen van hulle kan ’n enkele UID deur ’n tonnel stuur terwyl die ander die fisiese standaardroete bly gebruik.

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 die sonde voordat jy resultate vergelyk

Voordat jy gevolgtrekkings maak, bewys watter sonde geloop het. Nmap noem die tegniek in sy eie uitvoer, en --reason voeg die bewyse agter elke toestand by, wat die deel is wat jou vertel of ’n handdruk werklik voltooi is.

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 uitvoerings wat dieselfde toestand om verskillende redes rapporteer, is nie ’n teenstrydigheid nie, en twee uitvoerings wat verskillende toestande om dieselfde rede rapporteer, wys op roetering of beleid eerder as op die skandering. Hou bestemming, poort, naamruimte en tydsberekening identies, verander dan een veranderlike op ’n slag. Om die diens as root te laat loop is nie die herstel vir ’n beleidsbotsing nie; om die bedoelde beleid deur die diens se eienaar uit te druk, is.