Porty w Linuksie: sprawdź nasłuch, proces i rzeczywistą dostępność

„Otwarty port” może oznaczać, że program czeka na połączenia, zapora dopuszcza ruch albo usługę rzeczywiście da się osiągnąć z innego urządzenia. To trzy różne sprawdzenia. Na własnym komputerze z Linuksem zacznij od lokalnego odczytu gniazd: dowiesz się, jaki proces korzysta z portu i na jakim adresie, bez skanowania innych maszyn.

TCP: pokaż usługi czekające na połączenie

ss -ltn

Opcja -l wybiera nasłuch, -t TCP, a -n pozostawia numery adresów i portów zamiast zastępowania ich nazwami. Wynik z nagłówkiem, ale bez pozycji, oznacza brak pasujących gniazd widocznych w bieżącej przestrzeni sieciowej. Nie jest to zapewnienie, że na całej maszynie i we wszystkich kontenerach nie działa żadna usługa.

Aby dodać informacje o procesie, użyj:

sudo ss -ltnp

Własne procesy mogą być widoczne także bez podwyższenia uprawnień, lecz dane pozostałych bywają ograniczone. Brak nazwy procesu przy wyniku odczytanym zwykłym kontem nie dowodzi, że gniazdo jest podejrzane. Zwróć uwagę na PID, nazwę programu i lokalny adres z portem. Numer portu sam nie potwierdza rodzaju aplikacji: różne programy mogą używać tego samego numeru.

Adres lokalny mówi, gdzie program przyjmuje ruch

Adresy w tabeli są przykładami interpretacji, nie wynikami z Twojego komputera. Nie traktuj 0.0.0.0 jako adresu do wpisania na drugim urządzeniu. Do połączenia potrzebny jest rzeczywisty adres komputera. Również zapis IPv6 nie pozwala automatycznie stwierdzić, że program przyjmuje ruch obu rodzin adresów; odpowiada za to między innymi ustawienie IPV6_V6ONLY.

UDP wygląda inaczej

sudo ss -lunp

Opcja -u wybiera UDP. Możesz zobaczyć stan UNCONN: UDP nie zestawia połączenia tak jak TCP, więc nie oczekuj identycznej etykiety LISTEN. Odczytaj lokalny adres, port i proces, a następnie porównaj je z przeznaczeniem aplikacji. Brak odpowiedzi na prostą próbę pakietem nie daje pewności, że port UDP jest zamknięty — program może odpowiadać tylko na prawidłowe zapytania swojego protokołu.

Połączenia wychodzące to osobny widok

Przeglądarka korzystająca z internetu nie musi nasłuchiwać na porcie serwera. Do odczytu nawiązanych połączeń TCP możesz użyć:

ss -tn state established

W tym widoku port lokalny klienta i port zdalnego serwera pełnią inne role niż port nasłuchującej usługi. Nie próbuj „zamykać wszystkich portów”, bo zwykłe korzystanie z sieci potrzebuje gniazd. Najpierw ustal, czy oglądasz serwer przyjmujący ruch, czy połączenie rozpoczęte przez aplikację.

Nasłuch nie potwierdza dostępu z internetu

Między usługą a innym urządzeniem mogą znajdować się zapora komputera, reguły routera, translacja adresów i sieć operatora. Nawet nasłuch na wszystkich adresach nie potwierdza, że port jest dostępny z internetu. Jeśli chcesz sprawdzić dostępność, wykonaj próbę z drugiego własnego urządzenia w odpowiedniej sieci, używając klienta właściwego dla usługi.

Próba przez localhost sprawdza lokalną drogę, a próba z domowego laptopa sprawdza drogę w LAN. Żadna nie opisuje automatycznie dostępu spoza domu. Przy VPN uwzględnij również adres i reguły tego interfejsu. Nie otwieraj przekierowania portów w routerze tylko po to, aby wynik lokalnej listy wydawał się kompletny.

Kontenery i procesy wymagają właściwego kontekstu

Kontener może korzystać z osobnej przestrzeni sieciowej, a publikowanie jego portu może odbywać się przez reguły przekazywania ruchu. Lista ss na hoście nie zastępuje sprawdzenia konfiguracji publikowanych portów Docker. Porównaj ustawienia kontenera, port wewnętrzny i adres publikacji. To także wyjaśnia, dlaczego numer portu widoczny dla klienta może różnić się od numeru używanego przez program wewnątrz.

Po rozpoznaniu procesu sprawdź jego konfigurację i, jeśli jest usługą systemd, stan odpowiedniej jednostki. Nie zabijaj procesu wyłącznie z powodu nieznanego numeru. Jeśli pracujesz przez SSH, przypadkowe zatrzymanie usługi może odebrać Ci dostęp. Zapisz obserwację, ustal potrzebną funkcję i dopiero potem ograniczaj jej adres nasłuchu lub reguły dostępu.