Dlaczego skan portów zmienia się przy uruchomieniu z sudo
Gdy surowe gniazda są niedostępne, Nmap po cichu zastępuje skan SYN skanem TCP connect, więc root i zwykły użytkownik mierzą różne ścieżki.
Nmap nie zawsze wysyła pakiet, o który — jak sądzisz — prosiłeś. Gdy surowe gniazda są niedostępne, zastępuje domyślny skan SYN skanem TCP connect, więc uruchomienie jako zwykły użytkownik i uruchomienie pod sudo mogą odpowiedzieć na różne pytania o ten sam port. Wyniki wyglądają jak problem z uprawnieniami, a zwykle są zmianą metody. Ujawnienie metody to jedyny sposób, by w ogóle porównać oba uruchomienia.
Dwie sondy, jeden port, różne ścieżki kodu
Skan SYN sam buduje nagłówek TCP, wysyła go z surowego gniazda i odczytuje odpowiedź z sieci, zanim stos TCP jądra kiedykolwiek zarejestruje ukończone połączenie. Skan connect prosi system operacyjny o otwarcie zwykłego gniazda i raportuje to, co zwraca connect(). Oba mogą nazwać port otwartym, ale tylko jeden zostawia wpółotwartą próbę i tylko jeden podlega polityce na poziomie gniazda powiązanej z procesem wysyłającym.
Ścieżka surowa wymaga CAP_NET_RAW, dlatego domyślny skan po cichu się pogarsza, gdy tej możliwości brakuje. Własny przewodnik po technikach skanowania Nmapa dokumentuje tę zamianę: skan connect jest wariantem zapasowym, bo w ogóle nie wymaga specjalnych uprawnień. Zamiana następuje bez ostrzeżenia w większości uruchomień, i właśnie dlatego tak łatwo ją źle odczytać. Gdy wiesz, że wariant zapasowy istnieje, „otwarte jako root, zamknięte jako użytkownik” przestaje brzmieć jak błąd uprawnień i zaczyna brzmieć jak dwa różne pomiary.
Co sudo naprawdę zmienia w skanie
Podniesienie uprawnień przywraca ścieżkę surowego gniazda, a to zmienia więcej niż werdykt. Wybór portu źródłowego, taktowanie pakietów, zachowanie przy retransmisji i sposób klasyfikacji filtrowanej odpowiedzi pochodzą z innego kodu. Urządzenie pośredniczące ograniczające szybkość SYN traktuje oba uruchomienia nierówno, nawet gdy host docelowy jest identyczny.
Logowanie po stronie celu również się różni. Ukończony handshake jest widoczny dla usługi i dla dowolnej księgowości gniazd, a zresetowana wpółotwarta sonda często nie jest. Jeśli porównujesz uruchomienia wobec hosta, którego logi także czytasz, część widocznej różnicy to samo obserwowanie.
Utrzymaj metodę stałą w obu uruchomieniach
Wymuś tę samą technikę w obu wywołaniach, a porównanie zacznie coś znaczyć. Flaga -sT jawnie żąda skanu connect, -Pn usuwa wykrywanie hostów, -n usuwa rozwiązywanie nazw, a jeden -p usuwa różnice listy portów.
nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77
Zamień adres i port na host, który wolno ci testować; powyższy zakres dokumentacyjny jest przykładem, nie celem. Jeśli oba uruchomienia teraz się zgadzają, pierwotna różnica pochodziła z metody skanowania. Jeśli nadal się nie zgadzają, coś innego klasyfikuje ruch, a następna sekcja wskazuje, gdzie patrzeć.
Kontekst konta to nie tylko flaga uprawnień
Wdrożenie VPN może klasyfikować pakiety według UID, według cgroup lub według reguły powiązanej z procesem, który otworzył gniazdo. Wtedy ruch roota i ruch użytkownika wychodzą różnymi tabelami routingu lub trafiają na różne zestawy reguł, i żadna dyscyplina metody skanowania ich nie pogodzi.
Sprawdź politykę, a nie uprawnienie. W Linuksie nftables wyraża to przez meta skuid, a iptables przez dopasowanie właściciela, i każde z nich może wysłać jeden UID kanałem tunelu, podczas gdy drugie nadal korzysta z fizycznej trasy domyślnej.
sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77
Potwierdź sondę, zanim porównasz wyniki
Zanim wyciągniesz wnioski, udowodnij, która sonda działała. Nmap nazywa technikę we własnym wyjściu, a --reason dodaje dowód za każdym stanem, i to właśnie ta część mówi, czy handshake naprawdę się zakończył.
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
Dwa uruchomienia raportujące ten sam stan z różnych powodów nie są sprzecznością, a dwa uruchomienia raportujące różne stany z tego samego powodu wskazują na routing lub politykę, a nie na skan. Utrzymaj identyczne cel, port, przestrzeń nazw i taktowanie, a potem zmieniaj jedną zmienną naraz. Uruchamianie usługi jako root nie jest naprawą niezgodności polityki; naprawą jest wyrażenie zamierzonej polityki przez właściciela usługi.