Зошто скенирањето порти се менува кога се извршува со sudo

Nmap не секогаш го испраќа пакетот за кој мислите дека сте го побарале. Кога суровите сокети не се достапни, тој стандардното SYN скенирање го заменува со TCP connect скенирање, така што извршувањето како обичен корисник и извршувањето под sudo можат да одговорат на различни прашања за истиот порт. Резултатите изгледаат како проблем со дозволи, а обично се промена на методот. Експлицитното наведување на методот е единствениот начин двата извршувања воопшто да се споредат.

Две сонди, еден порт, различни кодни патеки

SYN скенирањето само го гради TCP заглавјето, го испраќа од суров сокет и го чита одговорот од мрежата пред TCP стекот на јадрото воопшто да забележи завршена врска. Connect скенирањето бара од оперативниот систем да отвори обичен сокет и известува што враќа connect(). Двете можат портот да го наречат отворен, но само едната остава полуотворен обид и само на едната ѝ се применува политика на ниво на сокет поврзана со процесот што испраќа.

Суровата патека бара CAP_NET_RAW, и затоа стандардното скенирање тивко се влошува кога ја нема таа можност. Сопствениот водич за техники на скенирање на Nmap ја документира замената: connect скенирањето е резервата бидејќи воопшто не бара посебни дозволи. Замената се случува без предупредување во повеќето извршувања, и токму тоа го прави толку лесно погрешно да се прочита. Откако ќе знаете дека резервата постои, „отворено како root, затворено како корисник“ престанува да звучи како грешка во дозволите и почнува да звучи како две различни мерења.

Што sudo навистина менува во скенирањето

Подигнувањето на дозволите ја враќа патеката на суровиот сокет, и тоа менува повеќе од пресудата. Изборот на изворен порт, таймингот на пакетите, однесувањето при препраќање и начинот на класификација на филтриран одговор доаѓаат од различен код. Средниот уред што го ограничува темпото на SYN ги третира двете извршувања нееднакво дури и кога целниот домаќин е идентичен.

Евидентирањето на страната на целта исто така се разликува. Завршеното ракување е видливо за услугата и за секое сокетно сметководство, додека ресетираната полуотворена сонда често не е. Ако ги споредувате извршувањата со домаќин чии логови исто така ги читате, дел од разликата што ја гледате е самото набљудување.

Држете го методот постојан во двете извршувања

Наметнете ја истата техника во двете повикувања и споредбата почнува да значи нешто. Знамето -sT бара connect скенирање експлицитно, -Pn го отстранува откривањето домаќини, -n го отстранува разрешувањето имиња, и едно -p ги отстранува разликите во списокот порти.

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

Заменете ја адресата и портот со домаќин што ви е дозволено да го тестирате; опсегот од документацијата погоре е пример, а не цел. Ако двете извршувања сега се совпаѓаат, првобитната разлика доаѓала од методот на скенирање. Ако сѐ уште не се совпаѓаат, нешто друго го класифицира сообраќајот, и следниот дел е местото каде да се погледне.

Контекстот на сметката не е само знаме за дозволи

Распоредувањето на VPN може да ги класифицира пакетите по UID, по cgroup или по правило поврзано со процесот што го отворил сокетот. Тогаш сообраќајот на root и сообраќајот на корисникот излегуваат низ различни табели за рутирање или удираат во различни множества правила, и никаква дисциплина на методот на скенирање не ги помирува.

Испитајте ја политиката, а не дозволата. На Linux, nftables тоа го изразува со meta skuid, а iptables со совпаѓање на сопственик, и кое било од двете може да испрати еден UID низ тунел додека другото продолжува да ја користи физичката стандардна рута.

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

Потврдете ја сондата пред да ги споредите резултатите

Пред да донесете заклучоци, докажете која сонда се извршила. Nmap ја именува техниката во сопствениот излез, а --reason го додава доказот зад секоја состојба, и токму тој дел ви кажува дали ракувањето навистина завршило.

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

Две извршувања што ја пријавуваат истата состојба од различни причини не се противречност, а две извршувања што пријавуваат различни состојби од иста причина укажуваат на рутирање или политика, а не на скенирањето. Држете ги целта, портот, именскиот простор и таймингот идентични, потоа менувајте една променлива одеднаш. Извршувањето на услугата како root не е поправка за несовпаѓање на политиката; поправката е да се изрази предвидената политика преку сопственикот на услугата.