netstat und ss

Stell dir vor, du betrittst ein Bürogebäude und willst wissen: Wer telefoniert gerade mit wem? Welche Telefonleitungen sind aktiv? Welche stehen auf „bereit" und warten auf einen Anruf? Genau diese Auskunft geben dir netstat (Windows + älteres Linux) und ss (modernes Linux) für TCP-/UDP-Verbindungen auf deinem System: alle aktiven Sockets, alle lauschenden Ports, alle eingehenden und ausgehenden Verbindungen.

Die Analogie: Ein Socket ist wie ein Telefon-Apparat – er hat eine Nummer (Port), kann klingeln (Listen), gerade ein Gespräch führen (Established) oder seit Kurzem aufgelegt haben (Time-Wait, „Hörer noch warm"). netstat/ss zeigen den Zustand aller Telefone im Haus. Eine zweite Analogie: ein Hafenmeister-Verzeichnis – welche Schiffe liegen an welchem Pier (Port), welche fahren gerade an, welche verlassen den Hafen.

1) Was sind Sockets eigentlich?

Bevor wir Tools anschauen, kurz das Fundament: Ein Socket ist die Kombination aus IP-Adresse und Port-Nummer. Server-Anwendungen öffnen einen Socket im Zustand „Listen" – sie warten auf eingehende Verbindungen. Ein Client baut eine Verbindung zu einem solchen Listen-Socket auf, beide Seiten haben dann je einen Socket im Zustand „Established". Wenn jemand fragt „Welcher Port?", meint er fast immer: Auf welcher Port-Nummer lauscht ein bestimmter Dienst (Webserver typischerweise auf 80/443, SSH auf 22, DNS auf 53). Sockets und Ports sind das Vokabular der Transportschicht (OSI-Schicht 4).

2) TCP-States – jeder Socket hat einen Zustand

Ein TCP-Socket durchläuft mehrere Zustände, vom ersten Handshake bis zum geordneten Abbau. Im normalen Betrieb siehst du vor allem zwei Zustände: LISTEN (Server wartet) und ESTABLISHED (Verbindung läuft). Treten ungewöhnlich viele Sockets in anderen Zuständen auf, ist das oft ein Symptom – klick einen Zustand für die Bedeutung:

TCP-States – welcher Zustand bedeutet was?

LISTEN

Server

SYN_SENT

Client

SYN_RECV

Server

ESTABLISHED

beide

FIN_WAIT_1

aktiv schließt

CLOSE_WAIT

passiv

TIME_WAIT

Client (Ende)

CLOSED

leer

Wähle einen TCP-State.

Typische Alarmsignale: Viele CLOSE_WAIT = Anwendung schließt ihre Sockets nicht (Bug, Socket-Leak). Viele TIME_WAIT auf einem Server = sehr kurze Verbindungen in hoher Frequenz, evtl. Keep-Alive empfohlen. Viele SYN_RECV ohne nachfolgendes ESTABLISHED = möglicher SYN-Flood.

3) Use-Case-Selector – welcher Befehl für welche Frage?

Die Optionen von netstat und ss sind viele, im Alltag braucht man aber nur wenige Kombinationen. Wähle eine Frage – die passende Kommandozeile wird angezeigt:

Welcher Befehl beantwortet meine Frage?

Eselsbrücke für ss/netstat-Flags: -t = TCP, -u = UDP, -l = Listening, -n = numerisch (keine DNS-Auflösung – schneller!), -p = mit Prozess (Linux: root nötig). Bei netstat-Windows -a = alle, -n = numerisch, -o = PID, -b = Programmname (admin nötig).

4) Eine echte Ausgabe lesen

Wer einmal verstanden hat, was die Spalten bedeuten, kann eine ss-Ausgabe in zwei Sekunden überfliegen und sofort sehen, was läuft. Lokale Adresse, Remote-Adresse, State, und – wichtig – der Prozess dahinter:

ss -tnp – annotierte Ausgabe

State    Recv-Q Send-Q Local Address:Port    Peer Address:Port   Process
LISTEN  0      128   0.0.0.0:22          0.0.0.0:*      users:(("sshd",pid=820,fd=3))
LISTEN  0      511   0.0.0.0:80          0.0.0.0:*      users:(("nginx",pid=901,fd=6))
ESTAB   0      0     10.0.0.5:22          10.0.0.99:54322  users:(("sshd",pid=1102))
ESTAB   0      0     10.0.0.5:443         142.250.74.195:443 users:(("firefox",pid=2390))
TIME-WAIT 0     0     10.0.0.5:51244      93.184.216.34:443

Lesehinweis: 0.0.0.0:22 bedeutet „sshd lauscht auf allen Interfaces auf Port 22". Wenn da stattdessen 127.0.0.1:22 stehen würde, wäre sshd nur lokal erreichbar – ein Kandidat, wenn „SSH geht nicht von außen". Recv-Q/Send-Q ≠ 0 = Daten in der Queue – kann bei laufender Übertragung normal sein oder bei einer hängenden Verbindung auffällig.

5) Praxisszenarien – netstat/ss im Alltag

Drei klassische Aufgaben, die jede:r FISI in den ersten Wochen im Job mehrfach hat:

Szenario	Vorgehen
„Port 8080 ist angeblich belegt"	`ss -tlnp \| grep :8080` bzw. Win `netstat -ano \| findstr :8080` → PID notieren → Prozess identifizieren → Anwendung neu starten oder Port wechseln
Webserver erreichbar nur lokal, nicht von außen	Listening-Adresse prüfen: `127.0.0.1:80` = nur lokal → Config auf `0.0.0.0:80` ändern. Erst danach Firewall-Regel prüfen.
„Mein Server hat zu viele offene Verbindungen"	`ss -s` für Gesamtstatistik, `ss -tan \| awk '{print $1}' \| sort \| uniq -c` für State-Verteilung. Viele TIME_WAIT oft normal, viele CLOSE_WAIT immer verdächtig.
„Welche Anwendung sendet gerade Traffic ins Internet?"	`ss -tn state established '! ( dst = 10.0.0.0/8 \|\| dst = 192.168.0.0/16 )'` – zeigt nur öffentliche Verbindungen.

Zusammenfassung

netstat (legacy, überall) und ss (modern, Linux) zeigen alle Sockets eines Systems – lauschende Ports und aktive Verbindungen. Wichtigste Flags: -t/-u (TCP/UDP), -l (listening), -n (numerisch), -p (Prozess). TCP-States kennen: LISTEN und ESTABLISHED sind normal, viele CLOSE_WAIT = Socket-Leak, viele SYN_RECV = mögliche SYN-Flood. Klassische Fragen: Welcher Port? Welcher Prozess? Welche Adresse lauscht? netstat/ss arbeiten auf Schicht 4 – perfekte Ergänzung zu ping/traceroute (Schicht 3).