Lauschende Ports und den zugehörigen Prozess mit ss finden

Ziel

Auf einem Linux-Host ermitteln, welche Prozesse auf welchen Adressen und Ports lauschen, als erster Schritt bei der Beurteilung, ob ein Dienst korrekt exponiert ist.

Voraussetzungen

ss aus dem Paket iproute2 (unter RHEL, Debian und Ubuntu standardmässig vorhanden). -p (zugehörigen Prozess anzeigen) benötigt Root-Rechte, um jeden Socket zuzuordnen. Ohne Root wird nur bei Sockets von Prozessen, die unter dem eigenen Benutzer laufen, ein Prozess angezeigt; bei allen anderen bleibt die Prozessspalte leer.

Schritte

1. ss -tulpn ausführen: -t TCP, -u UDP, -l nur lauschende Sockets, -p zugehörigen Prozess anzeigen, -n numerische Adressen und Ports anzeigen, statt Namen aufzulösen (schneller und verhindert, dass eine hängende DNS-Abfrage den Befehl blockiert).
2. Die Spalte "Local Address:Port" lesen:
   • 0.0.0.0:PORT (oder eine bestimmte IPv4-Adresse): lauscht auf IPv4, entweder auf allen Schnittstellen (0.0.0.0) oder auf einer einzelnen.
   • 127.0.0.1:PORT: nur Loopback, von einem anderen Host aus nicht erreichbar.
   • [::]:PORT: IPv6-Wildcard (alle Schnittstellen). Aktuelle iproute2-Versionen geben diese Form für Sockets mit gesetztem IPV6_V6ONLY aus, also nur für IPv6.
   • *:PORT: ein IPv6-Wildcard-Socket ohne IPV6_V6ONLY, also Dual-Stack; er nimmt auch IPv4-Verbindungen an (Linux-Standard, solange net.ipv6.bindv6only=0 gilt). Ältere ss-Versionen geben auch hierfür unter Umständen [::] oder ::: aus. Eine einzelne IPv6-Wildcard-Zeile beweist daher nie, dass IPv4 geschlossen ist.
3. Mit Filtern eingrenzen: ss -tlpn state listening 'sport = :22' für einen einzelnen Port, oder ss -tn state established, um statt der Listener die aktiven Verbindungen zu sehen.
4. Den Prozess aus der Prozessspalte (users:(("nginx",pid=1234,fd=6))) mit ps -p 1234 -o cmd= gegenprüfen, wenn der Name allein nicht eindeutig ist.
5. Ein Listener ohne angezeigten Prozess, selbst als Root, gehört meist dem Kernel (zum Beispiel NFS-Server oder WireGuard). Listener von Containern liegen in einem anderen Netzwerk-Namespace und erscheinen in der Liste des Hosts gar nicht (veröffentlichte Ports tauchen als Proxy-Prozess oder nur als NAT-Regeln auf); nsenter --net=/proc/<pid>/ns/net ss -tulpn listet sie von innen auf.

Erwartetes Ergebnis

Eine Tabelle der lauschenden Sockets, jeweils mit einer Bind-Adresse (zeigt die Exposition) und einem Prozess (zeigt den Eigentümer), bereit zum Abgleich mit einem Firewall-Regelwerk oder einer Liste der beabsichtigten Dienste.

Grenzen und Prüfbasis

Dass 0.0.0.0 als Bind-Adresse "alle lokalen Schnittstellen" bedeutet, ist für INADDR_ANY in der Manpage ip(7) in der Beschreibung der Socket-API dokumentiert. ss(8) selbst dokumentiert die Option -p/--processes sowie die oben verwendete Syntax für Status- und Port-Filter.