Чому сканування портів змінюється під час запуску з 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 — не виправлення невідповідності політики; виправлення — виразити потрібну політику через власника служби.