Offene Ports unter Linux prüfen: ss, netstat, lsof, nmap

Offene Ports mit ss prüfen, dem modernen Standard

Jeder offene Port auf einem Linux-System existiert, weil ein Prozess den Kernel gebeten hat, darauf zu lauschen. Das Werkzeug, das Ihnen diese Sockets heute anzeigt, ist ss (socket statistics), Teil der iproute2-Suite, die auf jeder modernen Distribution installiert ist. Ein Befehl deckt die meisten Situationen ab:

sudo ss -tulpn

Jedes Flag hat genau eine Aufgabe:

• -t: TCP-Sockets einbeziehen
• -u: UDP-Sockets einbeziehen
• -l: nur lauschende Sockets anzeigen (weglassen, um auch bestehende Verbindungen zu sehen)
• -p: den Prozess anzeigen, dem der Socket gehört; deshalb brauchen Sie sudo, denn ohne sehen Sie nur Ihre eigenen Prozesse
• -n: numerische Ausgabe (:22 statt :ssh) und keine Reverse-DNS-Abfragen, was den Befehl zusätzlich beschleunigt

Eine typische Ausgabezeile sieht so aus:

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=712,fd=3))

Die Spalte Local Address ist die sicherheitsrelevante. 0.0.0.0:22 bedeutet, dass der Socket Verbindungen auf allen IPv4-Schnittstellen annimmt, [::]:22 ist das IPv6-Äquivalent, und 127.0.0.1:5432 bedeutet, dass der Dienst nur auf Loopback antwortet und aus dem Netzwerk überhaupt nicht erreichbar ist.

Ein paar Varianten, die man sich merken sollte:

ss -tlnp                      # TCP listeners only
ss -ulnp                      # UDP listeners only
sudo ss -tlnp 'sport = :22'   # who is listening on port 22
ss -tn state established      # active TCP connections right now

netstat funktioniert noch, ist aber Legacy

Millionen Tutorials nennen weiterhin netstat -tulpn, und die Flags entsprechen eins zu eins dem obigen ss-Befehl, das Muskelgedächtnis lässt sich also in beide Richtungen übertragen. Der Unterschied liegt unter der Haube: netstat gehört zum net-tools-Paket im Wartungsmodus und liest /proc-Dateien, während ss den Kernel direkt über netlink abfragt, deutlich schneller auf Maschinen mit tausenden Sockets.

Die meisten aktuellen Distributionen liefern net-tools nicht mehr standardmäßig mit. Falls Sie es dennoch brauchen:

sudo netstat -tulpn

# if the command is missing:
sudo apt install net-tools    # Debian / Ubuntu
sudo dnf install net-tools    # RHEL / Fedora

Es gibt keinen Grund, es auf einem neuen Server zu installieren. Betrachten Sie netstat als Kompatibilitäts-Notlösung für ältere Systeme, die Sie übernehmen, und nutzen Sie überall sonst ss.

lsof: Ports aus der Perspektive der Prozesse

Unter Linux ist alles eine Datei, auch Netzwerk-Sockets, deshalb funktioniert lsof (list open files) auch als Port-Inspektor. Es glänzt, wenn Sie ohnehin in Prozessen statt in Ports denken:

sudo lsof -i -P -n                  # every process with a network socket
sudo lsof -iTCP -sTCP:LISTEN -P -n  # TCP listeners only
sudo lsof -i :443                   # everything touching port 443

-P und -n deaktivieren die Auflösung von Portnamen und Hostnamen, dieselbe Idee wie das -n in ss -tulpn. Die dritte Form ist die alltägliche: Sie richten sie auf einen Port und erhalten Befehlsnamen, PID, Benutzer und Dateideskriptor in einer lesbaren Tabelle. Anders als ss listet lsof neben den Listenern auch die bestehenden Verbindungen jedes Prozesses auf, was hilft, wenn Sie wissen wollen, wer gerade mit einem Dienst spricht, und nicht nur, dass der Dienst existiert.

nmap: lauschen ist nicht dasselbe wie erreichbar

Alles bisher beantwortet eine Frage: Was lauscht auf dieser Maschine? Für die Sicherheit zählt eine andere Frage mehr: Was ist von außen tatsächlich erreichbar? Die beiden Listen sind selten identisch, denn Host-Firewalls, Filterung auf Provider-Ebene und Loopback-only-Bindungen erzeugen Lücken dazwischen. Genau deshalb beweist ein Selbstscan von sich selbst wenig: nmap localhost läuft über die Loopback-Schnittstelle, umgeht Ihre externen Firewall-Regeln vollständig und meldet bereitwillig Dienste, die kein Angreifer je erreichen könnte.

Führen Sie den Scan von einer anderen Maschine aus, gerichtet auf die öffentliche IP des Servers:

nmap 203.0.113.10                            # top 1000 TCP ports
nmap -p- 203.0.113.10                        # all 65535 TCP ports
sudo nmap -sU --top-ports 100 203.0.113.10   # common UDP ports (slow)

nmap meldet drei Zustände, die man kennen sollte: open bedeutet, ein Dienst hat geantwortet, closed bedeutet, das Paket kam an, aber dort lauscht nichts, und filtered bedeutet, das Paket wurde stillschweigend verworfen, fast immer von einer Firewall. Ein Port, den ss als LISTEN zeigt, den ein entferntes nmap aber als filtered meldet, ist genau das, wie eine funktionierende Firewall aussieht. Eine Regel gilt ohne Ausnahme: Scannen Sie nur Hosts, die Ihnen gehören oder deren Prüfung Ihnen ausdrücklich erlaubt ist.

Genau herausfinden, welcher Prozess einen Port hält

Angenommen, irgendetwas besetzt Port 8080 und Ihre Anwendung kann sich nicht binden. Drei Wege führen zur PID:

sudo ss -tlnp 'sport = :8080'
sudo lsof -i :8080
sudo fuser -v 8080/tcp

fuser ist das kompakteste: Es gibt die PID aus, und -v ergänzt Benutzer und Befehlsnamen. Es kann den Störenfried mit fuser -k 8080/tcp sogar direkt beenden, aber das sendet ein Signal ohne jede Aufräumarbeit auf Dienstebene, behandeln Sie es also als letztes Mittel. Sobald Sie eine PID haben, zeigt ps -fp PID die vollständige Befehlszeile, und systemctl status PID verrät, welche systemd-Unit sie gestartet hat.

Wenn Sie überhaupt keine Werkzeuge haben (etwa in einem abgespeckten Container-Image), ist die Tabelle des Kernels immer da: cat /proc/net/tcp. Ports erscheinen hexadezimal (0016 ist 22), und der Zustand 0A bedeutet LISTEN. Diese Rohtabelle ist genau die Datenquelle, die die anderen Werkzeuge für Sie parsen und aufbereiten.

Alles, was einen Socket bindet, erscheint in diesen Auflistungen auf dieselbe Weise, ob Datenbank oder Proxy-Stack. Ein V2Ray-Inbound ist zum Beispiel nur ein weiterer Listener auf dem Port, den Sie konfiguriert haben, wie in unserem Leitfaden zum V2Ray-Protokoll erklärt.

Einen offenen Port schließen: kill oder Firewall

Ein Port ist offen, weil ein Prozess darauf lauscht, was Ihnen zwei getrennte Hebel gibt: den Listener entfernen oder die Erreichbarkeit blockieren. Sie sind nicht austauschbar, und bei allem Wichtigen sollten Sie meist beide ziehen.

Die saubere Lösung ist, den Dienst zu stoppen und zu deaktivieren, dem der Socket gehört. Die PID zu killen sieht schneller aus, hält aber selten: systemd startet überwachte Dienste automatisch neu, und der Port ist zurück, bevor Sie ss erneut ausführen. Reservieren Sie kill für Prozesse, die Sie selbst von Hand gestartet haben. Um zu sehen, was läuft, und abzuschalten, was Sie nicht brauchen, deckt unser Leitfaden zum Auflisten von Diensten mit systemctl diesen Ablauf von Anfang bis Ende ab.

sudo systemctl stop cups
sudo systemctl disable cups

Die Firewall bedient den zweiten Hebel. Erlauben Sie unter Ubuntu SSH, bevor Sie ufw aktivieren, sonst sperren Sie sich selbst aus der Kiste aus:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Auf Systemen der RHEL-Familie verwirft die Standardzone von firewalld unaufgeforderten Verkehr bereits; entfernen Sie alles, was Sie vorher geöffnet haben, mit firewall-cmd --permanent --remove-port=8080/tcp und anschließend firewall-cmd --reload. Eines ist keine Lösung: einen Dienst auf einen ungewöhnlichen Port zu verlegen. Das versteckt Sie vor den faulsten Scans und beruhigt Ihre Logs, aber nmap -p- findet den neuen Port in Minuten. Verschleierung ist keine Sicherheit: Schließen Sie den Port oder sperren Sie ihn per Firewall.

Ein Fünf-Minuten-Port-Audit für einen neuen Server

Führen Sie beim ersten Login auf einer frisch bereitgestellten Kiste die Inventur mit sudo ss -tulpn aus. Eine saubere Minimalinstallation sollte sehr wenig zeigen: sshd auf 22 und, auf Distributionen mit systemd-resolved, einen DNS-Stub auf 127.0.0.53:53. Alles andere verdient eine Erklärung. Arbeiten Sie dann diese Checkliste ab:

1. Identifizieren Sie jeden Listener über Prozessname und PID; deaktivieren Sie jeden Dienst, den Sie nicht angefordert haben.
2. Hinterfragen Sie jede Bindung an 0.0.0.0 oder [::]. Datenbanken und Adminpanels gehören auf 127.0.0.1, sofern sie nicht wirklich das Netzwerk bedienen.
3. Erkennen Sie gängige Ports auf den ersten Blick: 22 SSH, 80/443 Web, 3306 MySQL, 5432 PostgreSQL, 6379 Redis. Port 3389 ist Remote Desktop: Unter Linux bedeutet das, dass xrdp läuft, und die Regeln zu Exposition und Härtung dieses Ports sind das Thema unseres Leitfadens zum RDP-Port 3389.
4. Scannen Sie die öffentliche IP von Ihrer eigenen Maschine mit nmap -p- und vergleichen Sie das Ergebnis mit der ss-Liste; jede Abweichung ist entweder eine Firewall, die ihre Arbeit tut, oder eine Loopback-Bindung.
5. Schließen Sie mit einer Default-Deny-Firewall ab, die nur die Ports erlaubt, die Sie bewusst exponieren wollen.

Hier der gesamte Werkzeugkasten, je eine Zeile:

Befehle werden erst auf einer Maschine zum Reflex, auf der Sie echten Root-Zugriff haben und nichts Wichtiges kaputtgehen kann. Ein Linux VPS von rdp.monster gibt Ihnen genau diese Sandbox: vollen Administratorzugriff, dedizierte CPU und RAM, unlimitierte Bandbreite (Fair Use), kein KYC, und der Server ist etwa 10 Sekunden nach Zahlungsbestätigung online, schnell genug, um Ihr erstes ss -tulpn darauf auszuführen, bevor Ihr Kaffee kalt wird.

Häufig gestellte Fragen

Brauche ich Root, um offene Ports unter Linux zu prüfen?

Nein, um Ports aufzulisten; ja, um zu sehen, welcher Prozess sie besitzt.

Jeder Benutzer kann ss -tuln ausführen oder /proc/net/tcp lesen, die Liste der lauschenden Ports ist also nie verborgen. Die Grenze liegt beim Flag -p: ohne Root zeigen ss, lsof und fuser nur Prozesse Ihres eigenen Benutzers, andere Sockets erscheinen mit leerer Prozessspalte. Bei nmap erfordert der Standard-SYN-Scan (-sS) Root; die unprivilegierte Alternative ist der Connect-Scan (-sT), der gut funktioniert, aber etwas mehr Spuren hinterlässt.

Wie prüfe ich, ob ein bestimmter Port auf einem entfernten Server offen ist?

Nutzen Sie netcat: nc -zv host port liefert sofort eine Antwort.

nc -zv example.com 443 versucht eine TCP-Verbindung und meldet Erfolg oder Fehlschlag, ohne Daten zu senden. Fehlt netcat, genügt reines Bash: timeout 3 bash -c '</dev/tcp/example.com/443' && echo open. Beides beweist nur, dass irgendetwas die Verbindung angenommen hat. Es sagt nichts darüber, welcher Dienst geantwortet hat oder ob er gesund ist. Für UDP gibt es keinen zuverlässigen Schnelltest, denn ein stiller Port kann offen oder gefiltert sein; nutzen Sie dort nmap -sU.

Warum zeigt ss einen Port als lauschend, obwohl ich von außen keine Verbindung bekomme?

Der Socket ist an Loopback gebunden, oder eine Firewall verwirft den Verkehr.

Prüfen Sie zuerst die Spalte Local Address: 127.0.0.1:PORT oder [::1]:PORT bedeutet, der Dienst nimmt nur lokale Verbindungen an, was bei Datenbanken gewollt und üblich ist. Ist er an 0.0.0.0 gebunden, werden Pakete irgendwo auf dem Weg gefiltert: von einer Host-Firewall wie ufw, firewalld oder reinem nftables oder von der Edge-Filterung Ihres Anbieters. Meldet ein externer nmap-Scan den Port als filtered, bestätigt das eine Firewall; closed bedeutet, der Verkehr kommt an, aber auf dieser Schnittstelle lauscht nichts.

Welche Ports sollten auf einem frischen Linux-Server offen sein?

Einer: SSH. Alles andere auf einer sauberen Installation verdient eine Erklärung.

Eine minimale Debian-, Ubuntu- oder Rocky-Installation sollte dem Netzwerk nur sshd auf Port 22 zeigen. Ein Stub-DNS-Resolver auf 127.0.0.53:53 (systemd-resolved) ist normal und von außen nicht erreichbar. Cloud-Images ergänzen manchmal einen Agenten oder Monitoring-Daemon. Identifizieren Sie jeden Listener mit ss -tulpn und deaktivieren Sie alles, was Sie nicht angefordert haben. Jeder Dienst, den Sie danach installieren, sollte standardmäßig auf Loopback lauschen, sofern er nicht wirklich das Netzwerk bedienen muss, während die Firewall nur Öffentliches erlaubt.