Защо сканирането на портове се променя при 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 не е поправката за несъответствие в политиката; поправката е да изразите желаната политика чрез собственика на услугата.