Skip to main content

9.1 Ports, Sockets, Listener und gebundene Adressen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose von Ports, Sockets, Listenern und gebundenen IP-Adressen unter Windows, Linux, macOS sowie in Container- und Kubernetes-Umgebungen.

Nach der Bearbeitung muss nachvollziehbar geprüft werden können:

  • welches Transportprotokoll verwendet wird;
  • auf welchem Port ein Dienst lauschen soll;
  • an welche lokale Adresse der Socket gebunden ist;
  • welcher Prozess den Socket besitzt;
  • ob der Socket im richtigen Netzwerk-Namespace existiert;
  • ob ein lokaler Listener tatsächlich erreichbar ist;
  • ob Firewall, NAT, Portweiterleitung oder Proxy beteiligt sind;
  • ob ein Portkonflikt vorliegt;
  • ob TCP- und UDP-Verhalten richtig unterschieden werden;
  • ob die Anwendung auf Protokollebene korrekt antwortet.

Ein sichtbarer Listener beweist nur, dass im untersuchten Netzwerk-Namespace ein Socket gebunden wurde. Er beweist nicht, dass der Dienst von einem entfernten Client erreichbar ist oder auf Anwendungsebene korrekt funktioniert.

Sicherheits- und Wirkungsklassen

Kennzeichnung Bedeutung
LESEND Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV Kann interne Adressen, Prozesse, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO Kann bestehende Verbindungen oder Dienste beeinträchtigen.

Socket- und Prozesslisten können interne Dienstnamen, Benutzerkonten, Zieladressen und aktive Kommunikationsbeziehungen enthalten. Ausgaben und Netzwerkaufzeichnungen müssen entsprechend geschützt werden.

Grundbegriffe

Begriff Bedeutung
Port Numerische Kennzeichnung eines Dienstendpunkts innerhalb eines Transportprotokolls.
Socket Vom Betriebssystem verwalteter Kommunikationsendpunkt.
Listener TCP-Socket, der auf neue eingehende Verbindungen wartet.
Bind Zuordnung eines Sockets zu einer lokalen IP-Adresse und einem lokalen Port.
Local Address Lokale IP-Adresse, an die der Socket gebunden ist.
Local Port Lokaler TCP- oder UDP-Port des Sockets.
Remote Address Adresse der Gegenstelle einer bestehenden Verbindung.
Remote Port Port der Gegenstelle einer bestehenden Verbindung.
Wildcard-Bindung Bindung an alle geeigneten lokalen Adressen, beispielsweise 0.0.0.0.
Loopback-Bindung Bindung ausschließlich an die lokale Rückschleifenschnittstelle.
Netzwerk-Namespace Isolierte Netzwerksicht eines Systems oder Containers mit eigenen Schnittstellen, Routen und Sockets.

Ein Port ist nicht unabhängig vom Transportprotokoll zu betrachten. TCP-Port 53 und UDP-Port 53 sind unterschiedliche Endpunkte und können von unterschiedlichen Sockets verwendet werden.

Portnummern und Portbereiche

TCP- und UDP-Portnummern besitzen einen Wertebereich von 0 bis 65535.

Bereich IANA-Bezeichnung Typische Verwendung
0–1023 System Ports Standardisierte oder systemnahe Dienste
1024–49151 User Ports Registrierte Anwendungsdienste
49152–65535 Dynamic and/or Private Ports Dynamische Clientports und private Verwendung

Port 0 besitzt eine besondere Bedeutung und wird nicht wie ein normaler Dienstport verwendet. Eine Anwendung kann beim Binden an Port 0 das Betriebssystem einen freien lokalen Port auswählen lassen.

Auf Unix-artigen Systemen erfordert das Binden niedriger Ports häufig erhöhte Berechtigungen oder eine Fähigkeit wie CAP_NET_BIND_SERVICE. Das genaue Verhalten ist jedoch vom Betriebssystem und dessen Konfiguration abhängig.

Eine Eintragung im IANA-Verzeichnis bedeutet nicht, dass ein Port ausschließlich von dem dort genannten Dienst verwendet werden darf. Für die Diagnose ist die tatsächlich wirksame Konfiguration entscheidend.

Socket- und Verbindungsmodell

Ein TCP-Listener wird im Wesentlichen durch folgende Angaben beschrieben:

Transportprotokoll + lokale IP-Adresse + lokaler Port

Beispiel:

TCP 192.0.2.25:443

Eine aufgebaute TCP-Verbindung wird durch beide Endpunkte unterschieden:

Transportprotokoll
lokale IP-Adresse
lokaler Port
entfernte IP-Adresse
entfernter Port

Beispiel:

TCP
lokal:   192.0.2.25:443
remote:  198.51.100.40:53124

Ein einzelner TCP-Listener auf Port 443 kann deshalb viele gleichzeitige Verbindungen bedienen. Die einzelnen Verbindungen unterscheiden sich mindestens durch die entfernte Adresse oder den entfernten Port.

UDP besitzt keinen TCP-Verbindungsaufbau und keinen TCP-Zustand LISTEN. Ein UDP-Endpunkt kann dennoch an eine lokale Adresse und einen lokalen Port gebunden sein und Datagramme empfangen.

Gebundene Adressen richtig interpretieren

Bindung Bedeutung
127.0.0.1:8080 Nur über IPv4-Loopback des eigenen Systems erreichbar
192.0.2.25:8080 Nur über diese konkrete IPv4-Adresse erreichbar
0.0.0.0:8080 IPv4-Wildcard; Bindung an alle geeigneten lokalen IPv4-Adressen
[::1]:8080 Nur über IPv6-Loopback erreichbar
[::]:8080 IPv6-Wildcard; Bindung an alle geeigneten lokalen IPv6-Adressen
<Container-IP>:8080 Innerhalb des betreffenden Container-Netzwerks gebunden
<Pod-IP>:8080 Innerhalb des Kubernetes-Pod-Netzwerks gebunden

Eine Bindung an 0.0.0.0 bedeutet nicht, dass ein Client die Zieladresse 0.0.0.0 verwenden soll. Der Client verwendet eine konkrete erreichbare Adresse des Servers.

Bei einer Bindung an [::] darf nicht ungeprüft angenommen werden, dass derselbe Socket auch IPv4-Verbindungen akzeptiert. Das Verhalten hängt unter anderem vom Betriebssystem, der Socketoption IPV6_V6ONLY und der Anwendung ab. IPv4 und IPv6 müssen getrennt geprüft werden.

Loopback-, Wildcard- und spezifische Bindung

Loopback-Bindung

127.0.0.1:8080
[::1]:8080

Der Dienst ist grundsätzlich nur vom eigenen Netzwerk-Namespace erreichbar. Das ist beispielsweise für lokale Backends hinter einem Reverse Proxy sinnvoll.

Ein entfernter Client kann diesen Listener nicht direkt erreichen.

Wildcard-Bindung

0.0.0.0:8080
[::]:8080

Der Dienst lauscht grundsätzlich auf allen dafür geeigneten Adressen der entsprechenden Protokollfamilie. Dazu können gehören:

  • LAN-Schnittstellen;
  • WLAN-Schnittstellen;
  • VPN-Schnittstellen;
  • öffentliche Schnittstellen;
  • virtuelle Switches;
  • Container-Bridges.

Ob der Dienst tatsächlich von jedem Netz erreichbar ist, wird zusätzlich durch Routing, Firewall, NAT, Sicherheitsgruppen und vorgelagerte Systeme bestimmt.

Bindung an eine konkrete Adresse

192.0.2.25:8080

Der Dienst nimmt Verbindungen nur über diese lokale Adresse an.

Die Bindung kann beim Dienststart fehlschlagen, wenn:

  • die Adresse nicht mehr am System vorhanden ist;
  • die Schnittstelle noch nicht verfügbar ist;
  • DHCP eine andere Adresse vergeben hat;
  • die Adresse erst durch einen später gestarteten VPN-Tunnel entsteht;
  • die Anwendung vor der Netzwerkkonfiguration gestartet wird;
  • sich der Dienst in einem anderen Netzwerk-Namespace befindet.

TCP-Zustände

Zustand Einordnung
LISTEN Lokaler Socket wartet auf neue TCP-Verbindungen.
SYN-SENT Verbindungsaufbau wurde begonnen; Antwort steht noch aus.
SYN-RECEIVED Ein SYN wurde empfangen und der Aufbau ist noch nicht abgeschlossen.
ESTABLISHED TCP-Verbindung ist aufgebaut.
FIN-WAIT-1 Lokale Seite hat das Schließen begonnen.
FIN-WAIT-2 Lokale Seite wartet nach eigenem FIN auf das FIN der Gegenstelle.
CLOSE-WAIT Gegenstelle hat geschlossen; lokale Anwendung muss noch schließen.
LAST-ACK Lokale Seite wartet auf die Bestätigung ihres abschließenden FIN.
TIME-WAIT Geschlossene Verbindung wird vorübergehend zur sicheren Protokollabwicklung vorgehalten.
CLOSED Keine aktive TCP-Verbindung.

Viele Einträge in TIME-WAIT sind nicht automatisch ein Fehler. Sie können bei kurzlebigen Verbindungen normal sein.

Dauerhaft viele CLOSE-WAIT-Sockets können darauf hindeuten, dass die lokale Anwendung geschlossene Verbindungen nicht ordnungsgemäß freigibt. Dieser Befund muss über Zeitverlauf, Prozesszustand und Anwendungstelemetrie bestätigt werden.

Was ein Listener beweist – und was nicht

Ein Listener beweist:

  • ein Socket wurde im untersuchten Netzwerk-Namespace angelegt;
  • der Socket ist an einen lokalen Port gebunden;
  • das Betriebssystem führt ihn als empfangsbereiten TCP-Socket;
  • ein Prozess oder Kernelbestandteil besitzt den Socket.

Ein Listener beweist nicht:

  • dass die Firewall eingehende Verbindungen erlaubt;
  • dass Routing zum Server funktioniert;
  • dass NAT oder Portweiterleitung korrekt sind;
  • dass ein Load Balancer das richtige Ziel verwendet;
  • dass die Anwendung nach dem Verbindungsaufbau korrekt antwortet;
  • dass TLS, HTTP, DNS oder ein anderes Anwendungsprotokoll funktioniert;
  • dass der Dienst unter dem erwarteten Namen erreichbar ist;
  • dass IPv4 und IPv6 gleichermaßen funktionieren;
  • dass der Listener im richtigen Container oder Netzwerk-Namespace existiert.

Erwarteten Endpunkt festlegen

Vor der Diagnose müssen mindestens folgende Sollangaben dokumentiert werden:

Dienst:
<Anwendung oder Dienstname>

Transportprotokoll:
<TCP oder UDP>

Erwartete lokale Adresse:
<Loopback, konkrete Adresse oder Wildcard>

Erwarteter lokaler Port:
<Portnummer>

Erwarteter Netzwerk-Namespace:
<Host, Container, Pod oder anderer Namespace>

Erwartete Erreichbarkeit:
<nur lokal, internes Netz, VPN oder öffentlich>

Vorgelagerte Komponenten:
<Firewall, NAT, Reverse Proxy, Load Balancer oder Service>

Ohne diese Sollangaben kann ein sichtbarer Socket nicht zuverlässig als richtig oder falsch bewertet werden.

Windows: TCP-Listener erfassen

LESEND

Alle TCP-Verbindungen und Listener:

Get-NetTCPConnection

Nur TCP-Listener:

Get-NetTCPConnection `
  -State Listen |
  Sort-Object LocalPort, LocalAddress

Bestimmten lokalen Port prüfen:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443

Ausgabe auf wesentliche Felder begrenzen:

Get-NetTCPConnection `
  -State Listen |
  Select-Object `
    LocalAddress,
    LocalPort,
    State,
    OwningProcess |
  Sort-Object LocalPort, LocalAddress

Zu prüfen sind:

  • LocalAddress;
  • LocalPort;
  • State;
  • OwningProcess;
  • mehrere Listener auf demselben Port;
  • getrennte IPv4- und IPv6-Einträge;
  • unerwartete Loopback-Bindung;
  • unerwartete Wildcard-Bindung.

Windows: Prozess eines TCP-Listeners bestimmen

LESEND

Beispiel für Port 443:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443 |
  ForEach-Object {
    $connection = $_
    $process = Get-Process `
      -Id $connection.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $connection.LocalAddress
      LocalPort    = $connection.LocalPort
      ProcessId    = $connection.OwningProcess
      ProcessName  = $process.ProcessName
      ProcessPath  = $process.Path
    }
  }

Einen bekannten Prozess prüfen:

Get-Process `
  -Id 1234

Die ausführbare Datei kann abhängig von Prozessschutz und Berechtigungen nicht immer angezeigt werden.

Windows: Prozess einem Dienst zuordnen

LESEND

$processId = 1234

Get-CimInstance `
  -ClassName Win32_Service `
  -Filter "ProcessId = $processId" |
  Select-Object `
    Name,
    DisplayName,
    State,
    StartMode,
    ProcessId,
    PathName

Wenn kein Dienst zurückgegeben wird, kann der Prozess beispielsweise:

  • interaktiv gestartet worden sein;
  • durch einen Task gestartet worden sein;
  • zu einer Desktopanwendung gehören;
  • Teil einer Container- oder Virtualisierungsumgebung sein;
  • durch einen anderen Dienstprozess verwaltet werden.

Windows: UDP-Endpunkte erfassen

LESEND

Alle UDP-Endpunkte:

Get-NetUDPEndpoint |
  Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

Get-NetUDPEndpoint `
  -LocalPort 53

UDP-Endpunkt mit Prozessinformationen anzeigen:

Get-NetUDPEndpoint `
  -LocalPort 53 |
  ForEach-Object {
    $endpoint = $_
    $process = Get-Process `
      -Id $endpoint.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $endpoint.LocalAddress
      LocalPort    = $endpoint.LocalPort
      ProcessId    = $endpoint.OwningProcess
      ProcessName  = $process.ProcessName
    }
  }

Das Vorhandensein eines UDP-Endpunkts beweist noch nicht, dass eine gesendete Anfrage verarbeitet oder beantwortet wird.

Windows: netstat als ergänzende Sicht

LESEND

netstat -ano

Nur TCP-Listener:

netstat -ano -p tcp

UDP-Endpunkte:

netstat -ano -p udp

Wiederholte Aktualisierung alle fünf Sekunden:

netstat -ano 5

Beenden mit Strg+C.

Wichtige Optionen:

Option Bedeutung
-a Zeigt aktive Verbindungen und Listener.
-n Zeigt numerische Adressen und Ports.
-o Zeigt die zugehörige Prozess-ID.
-p tcp Begrenzt die Anzeige auf TCP.
-p udp Begrenzt die Anzeige auf UDP.

Namensauflösung sollte für die erste Diagnose mit -n vermieden werden. Anderenfalls können DNS-Verzögerungen die Ausgabe verlangsamen oder Adressen durch Namen verdecken.

Windows: lokale IP-Adressen bestätigen

LESEND

Get-NetIPConfiguration

Alle verwendbaren IP-Adressen:

Get-NetIPAddress |
  Where-Object AddressState -eq "Preferred" |
  Sort-Object InterfaceIndex, AddressFamily

Eine Bindung an eine konkrete Adresse ist nur sinnvoll, wenn diese Adresse tatsächlich im richtigen Netzwerk-Compartment und auf der vorgesehenen Schnittstelle vorhanden ist.

Windows: Kernel- und HTTP.sys-Zuordnungen prüfen

Ein Port kann durch einen Kernelbestandteil oder eine gemeinsame HTTP-Infrastruktur verwaltet werden. Der sichtbare Besitzer muss daher nicht unmittelbar der erwartete Anwendungsprozess sein.

Bei HTTP- oder HTTPS-Diensten unter Windows:

LESEND

netsh http show servicestate

Registrierte URL-Zuordnungen:

netsh http show urlacl

Registrierte TLS-Zertifikatbindungen:

netsh http show sslcert

Portproxy-Konfiguration:

netsh interface portproxy show all

Zu prüfen sind:

  • welcher Dienst die URL registriert hat;
  • welcher Prozess eine HTTP.sys-Anforderungswarteschlange verwendet;
  • ob eine Portproxy-Regel besteht;
  • ob der sichtbare Hostport an ein anderes Ziel weiterleitet;
  • ob der Prozessbesitzer nur als System erscheint.

Eine URL-Reservierung allein beweist keinen aktiven Listener.

Linux: TCP- und UDP-Sockets mit ss prüfen

ss ist unter Linux das bevorzugte Werkzeug zur Anzeige von Socketinformationen.

LESEND

TCP-Listener:

ss -lnt

TCP-Listener einschließlich Prozessinformationen:

sudo ss -lntp

UDP-Endpunkte:

sudo ss -lnup

TCP- und UDP-Endpunkte gemeinsam:

sudo ss -lntup

Bestimmten TCP-Port prüfen:

sudo ss -lntp 'sport = :443'

Bestimmten UDP-Port prüfen:

sudo ss -lnup 'sport = :53'

Alle TCP-Verbindungen und Zustände:

ss -tan

Zusammenfassung:

ss -s

Wichtige Optionen:

Option Bedeutung
-l Nur lauschende beziehungsweise unverbundene Endpunkte
-n Numerische Adressen und Ports
-t TCP
-u UDP
-p Prozessinformationen
-a Alle Sockets
-x Unix-Domain-Sockets

Prozessinformationen können erhöhte Berechtigungen erfordern.

Linux: Prozess mit lsof bestimmen

LESEND

Alle lauschenden TCP-Sockets:

sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

Bestimmten UDP-Port prüfen:

sudo lsof -nP -iUDP:53

Wichtige Optionen:

Option Bedeutung
-n Keine Namensauflösung der IP-Adressen
-P Keine Umwandlung von Ports in Dienstnamen
-iTCP TCP-Sockets
-iUDP UDP-Sockets
-sTCP:LISTEN Nur TCP-Listener

Danach können Prozess und Dienst untersucht werden:

ps -fp <PID>

Bei einem systemd-Dienst:

systemctl status <Dienstname>

Prozessbaum:

pstree -p <PID>

Falls pstree nicht installiert ist:

ps -ef --forest

Linux: Netzwerkadressen und Namespace prüfen

LESEND

ip address show

Kompakte Ansicht:

ip -brief address

Netzwerk-Namespaces anzeigen:

ip netns list

Socketansicht eines bekannten Prozess-Namespace:

sudo nsenter \
  -t <PID> \
  -n \
  ss -lntup

Dieser Test ist besonders wichtig, wenn ein Prozess in einem Container oder separaten Netzwerk-Namespace läuft.

Ein Listener innerhalb eines Container-Namespace muss nicht als normaler Listener in der Sockettabelle des Hosts erscheinen.

macOS: TCP- und UDP-Sockets prüfen

Linux-ss ist unter macOS standardmäßig nicht verfügbar. Für die Prozesszuordnung ist lsof besonders geeignet.

LESEND

Alle TCP-Listener:

sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

UDP-Endpunkte:

sudo lsof -nP -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof -nP -iUDP:53

TCP-Socketzustände mit netstat:

netstat -anv -p tcp

UDP-Sockets:

netstat -anv -p udp

Lokale Netzwerkschnittstellen:

ifconfig

Routing- und Schnittstelleninformationen:

route -n get default

Für die Zuordnung eines Ports zu einem Prozess sollte unter macOS nicht allein auf netstat vertraut werden. lsof liefert dafür normalerweise die geeignetere Sicht.

Unix-Domain-Sockets und andere lokale IPC-Endpunkte

Nicht jede lokale Dienstkommunikation verwendet einen TCP- oder UDP-Port.

Typische Alternativen sind:

  • Unix-Domain-Sockets;
  • Windows Named Pipes;
  • Shared Memory;
  • lokale Message Queues;
  • anwendungsspezifische IPC-Mechanismen.

Linux:

sudo ss -lxnp

Linux und macOS:

sudo lsof -U

Ein Reverse Proxy kann beispielsweise über einen Unix-Domain-Socket mit seinem Backend kommunizieren. In diesem Fall ist für die Backendverbindung kein TCP-Listener sichtbar.

Die Diagnose muss dann zusätzlich prüfen:

  • Pfad des Sockets;
  • Dateiberechtigungen;
  • Besitzer und Gruppe;
  • Existenz nach dem Dienststart;
  • Namespace oder Container;
  • SELinux- beziehungsweise AppArmor-Richtlinien;
  • Konfiguration von Proxy und Backend.

Portkonflikte erkennen

Typische Meldungen eines Bindungsfehlers sind:

Address already in use
EADDRINUSE
WSAEADDRINUSE
Only one usage of each socket address is normally permitted

Mögliche Ursachen:

  • ein anderer Prozess besitzt bereits denselben Endpunkt;
  • eine alte Instanz der Anwendung läuft noch;
  • zwei Dienste verwenden dieselbe konfigurierte Adresse und denselben Port;
  • ein Wildcard-Listener kollidiert mit einer spezifischen Bindung;
  • IPv4- und IPv6-Verhalten wurde falsch eingeschätzt;
  • ein Dienst wird doppelt durch Service Manager und manuellen Start gestartet;
  • ein Container veröffentlicht bereits denselben Hostport;
  • eine Portproxy- oder Kernelkomponente ist beteiligt.

Windows:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 8080

Get-NetUDPEndpoint `
  -LocalPort 8080

Linux:

sudo ss -lntup 'sport = :8080'

macOS:

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN

Ein Port kann unter bestimmten Bedingungen absichtlich durch mehrere Prozesse oder Sockets gemeinsam verwendet werden. Beispiele sind Socketaktivierung, SO_REUSEPORT, gemeinsam verwaltete Kernel-Listener oder Clustermechanismen. Deshalb darf ein ungewöhnlicher Mehrfachbefund nicht ohne Prüfung als Fehler bewertet werden.

Weitere typische Bindungsfehler

Meldung oder Fehler Mögliche Einordnung
Address already in use Endpunkt wird bereits verwendet.
Permission denied Fehlende Berechtigung, Sicherheitsrichtlinie oder geschützter Port.
EACCES Zugriff auf Adresse oder Port verweigert.
Cannot assign requested address Konfigurierte lokale Adresse ist nicht vorhanden.
EADDRNOTAVAIL Lokale Bindungsadresse steht nicht zur Verfügung.
Connection refused Zielsystem lehnt aktiv ab; häufig kein passender Listener.
Timeout Keine verwertbare Antwort; Paketverlust, Filterung, Routing oder Überlastung möglich.
Verbindung erfolgreich, Protokollfehler Transport funktioniert; Anwendung oder Protokollkonfiguration fehlerhaft.

Die Zuordnung ist eine erste Einordnung und kein alleiniger Ursachennachweis.

Lokalen TCP-Endpunkt testen

Ein lokaler Test muss zur tatsächlichen Bindung passen.

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 8080 `
  -InformationLevel Detailed

Test gegen die konkrete Schnittstellenadresse:

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 8080 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 127.0.0.1 8080

nc -vz 192.0.2.25 8080

Ein erfolgreicher TCP-Test beweist nur, dass der TCP-Verbindungsaufbau funktioniert hat. Er beweist nicht, dass die Anwendung ein gültiges Ergebnis liefert.

Test-NetConnection -Port prüft TCP. Es ist kein allgemeiner UDP-Test.

Loopback und Schnittstellenadresse getrennt testen

Die folgenden Befunde müssen unterschieden werden:

Loopback-Test Test gegen Serveradresse Mögliche Einordnung
erfolgreich erfolgreich Listener ist lokal über beide Pfade erreichbar
erfolgreich fehlgeschlagen falsche Bindung, lokale Firewall oder Adressproblem
fehlgeschlagen erfolgreich Dienst lauscht nur auf konkreter Adresse
fehlgeschlagen fehlgeschlagen kein Listener, falscher Port, falsches Protokoll oder Dienstfehler

Ein Test gegen localhost kann je nach Namensauflösung zuerst ::1 oder 127.0.0.1 verwenden. Für eine eindeutige Diagnose müssen IPv4- und IPv6-Adressen ausdrücklich getestet werden.

Windows:

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 8080

Test-NetConnection `
  -ComputerName "::1" `
  -Port 8080

Linux und macOS:

nc -4 -vz 127.0.0.1 8080

nc -6 -vz ::1 8080

Test von einem entfernten Client

Der Test muss von einem System erfolgen, das den realen Zugriffspfad möglichst genau abbildet.

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz app.example.test 443

Getrennte Prüfung einer bekannten IP-Adresse:

nc -vz 192.0.2.25 443

Zu dokumentieren sind:

  • verwendeter Zielname;
  • aufgelöste Zieladresse;
  • Quelladresse;
  • Zielport;
  • TCP-Ergebnis;
  • Zeitpunkt;
  • Teststandort;
  • VPN-Zustand;
  • IPv4 oder IPv6;
  • direkter oder weitergeleiteter Pfad.

Nur autorisierte Ziele und Ports dürfen geprüft werden. Breite Portscans sind für die Diagnose eines bekannten Dienstendpunkts normalerweise nicht erforderlich.

Anwendungsprotokoll statt nur Port prüfen

Nach erfolgreichem TCP-Verbindungsaufbau muss das erwartete Anwendungsprotokoll getestet werden.

HTTP:

curl -v http://127.0.0.1:8080/

HTTPS mit korrektem Hostnamen und festgelegter Zieladresse:

curl -v \
  --resolve app.example.test:443:192.0.2.25 \
  https://app.example.test/

TLS mit Server Name Indication:

openssl s_client \
  -connect 192.0.2.25:443 \
  -servername app.example.test

DNS über UDP:

dig @192.0.2.53 example.test A

DNS über TCP:

dig @192.0.2.53 example.test A +tcp

Ein erfolgreicher TCP-Test auf Port 443 beweist beispielsweise nicht:

  • dass der TLS-Handshake funktioniert;
  • dass das richtige Zertifikat geliefert wird;
  • dass SNI korrekt verarbeitet wird;
  • dass HTTP eine gültige Antwort liefert;
  • dass der erwartete virtuelle Host ausgewählt wird.

UDP richtig prüfen

UDP besitzt keinen TCP-Handshake. Deshalb kann ein allgemeiner UDP-Porttest kein gleichwertiges Ergebnis wie ein erfolgreicher TCP-Verbindungsaufbau liefern.

Zu prüfen sind:

  • existiert ein lokaler UDP-Endpunkt?
  • verlässt die Anfrage den Client?
  • erreicht sie den Server?
  • antwortet die Anwendung?
  • erreicht die Antwort den Client?
  • wird ein ICMP-Fehler zurückgegeben?
  • wird ICMP unterwegs gefiltert?
  • wird das richtige Anwendungsprotokoll verwendet?

Ein Aufruf wie:

nc -vzu 192.0.2.53 53

kann Datagramme erzeugen, liefert aber ohne geeignete Anwendungsantwort keinen belastbaren Nachweis für einen funktionsfähigen UDP-Dienst.

Für UDP ist ein protokollspezifischer Test vorzuziehen, beispielsweise:

  • dig für DNS;
  • ntpq, chronyc oder ein geeigneter NTP-Test für NTP;
  • ein herstellerspezifischer Testclient;
  • eine begrenzte Netzwerkaufzeichnung.

Firewall und Listener getrennt betrachten

Die Diagnoseebenen sind voneinander zu trennen:

Anwendungsprozess
→ lokaler Socket
→ lokale Firewall
→ Routing und Netzwerk
→ externe Firewall oder NAT
→ Client

Mögliche Befunde:

  • Dienst läuft, aber kein Socket wurde gebunden;
  • Socket existiert, lokale Firewall blockiert;
  • lokale Prüfung funktioniert, entfernte Prüfung schlägt fehl;
  • entfernte Verbindung erreicht den Server, Antwortweg fehlt;
  • NAT leitet auf einen falschen Hostport weiter;
  • Load Balancer verwendet den falschen Backendport;
  • Reverse Proxy erreicht sein lokales Backend nicht.

Ein laufender Dienststatus beweist keinen Listener. Ein Listener beweist keine Firewallfreigabe.

Windows-Firewallbezug lesend prüfen

Aktive eingehende Regeln anzeigen:

LESEND

Get-NetFirewallRule `
  -Enabled True `
  -Direction Inbound |
  Select-Object `
    DisplayName,
    Action,
    Profile,
    Direction

Portfilter zu einer bekannten Regel:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallPortFilter

Adressfilter:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallAddressFilter

Anwendungsfilter:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallApplicationFilter

Zu prüfen sind:

  • TCP oder UDP;
  • lokaler Port;
  • lokales Programm;
  • lokales und entferntes Adressnetz;
  • aktives Firewallprofil;
  • eingehende oder ausgehende Richtung;
  • Block- und Zulassungsregeln;
  • durch Gruppenrichtlinie gelieferte Regeln.

Die Firewall darf nicht vorsorglich vollständig deaktiviert werden. Eine Änderung muss auf den nachgewiesenen Dienst, Port, Pfad und Zeitraum begrenzt werden.

Reverse Proxy und Backendlistener

Ein typischer Aufbau ist:

Client
→ Reverse Proxy auf 0.0.0.0:443
→ Backend auf 127.0.0.1:8080

In diesem Fall müssen zwei getrennte Endpunkte geprüft werden:

  • externer Listener des Reverse Proxys;
  • interner Listener des Backends.

Mögliche Fehler:

  • Proxy lauscht nicht auf Port 443;
  • Backend lauscht nicht auf Port 8080;
  • Backend ist nur über IPv6 erreichbar, Proxy verwendet IPv4;
  • Proxy verwendet den falschen Backendport;
  • Backend befindet sich in einem Container und 127.0.0.1 bezeichnet dort einen anderen Namespace;
  • Proxy erwartet einen Unix-Domain-Socket;
  • TLS endet am Proxy, während das Backend fälschlich ebenfalls TLS erwartet;
  • Health Check und produktiver Zielport unterscheiden sich.

Ein erfolgreicher externer TCP-Verbindungsaufbau beweist nicht, dass das Backend erreichbar ist.

Container und Netzwerk-Namespaces

Container besitzen häufig eine eigene Netzwerksicht. Dabei sind mindestens drei Endpunkte zu unterscheiden:

Anwendungsport im Container
veröffentlichter Port auf dem Host
Port des zugreifenden Clients

Beispiel:

Container: 172.18.0.5:80
Host:      192.0.2.25:8080
Client:    verbindet zu 192.0.2.25:8080

Ein Dienst, der innerhalb des Containers nur an 127.0.0.1:80 gebunden ist, ist über eine normale Portveröffentlichung häufig nicht erreichbar. Für den Zugriff über das Container-Netz muss er üblicherweise an der Containeradresse oder an einer geeigneten Wildcard-Adresse lauschen.

Docker: Portzuordnung prüfen

LESEND

Laufende Container und veröffentlichte Ports:

docker ps \
  --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Portzuordnungen eines Containers:

docker port <Containername>

Ausführliche Portkonfiguration:

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

Netzwerkmodus:

docker inspect \
  <Containername> \
  --format '{{.HostConfig.NetworkMode}}'

Containeradresse:

docker inspect \
  <Containername> \
  --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

Listener innerhalb des Containers, falls ss vorhanden ist:

docker exec \
  <Containername> \
  ss -lntup

Alternativ, falls lsof vorhanden ist:

docker exec \
  <Containername> \
  lsof -nP -i

Fehlende Diagnosewerkzeuge im Container sind kein Nachweis für einen fehlenden Listener. Minimal gehaltene Images enthalten häufig weder ss noch lsof.

Docker-Portveröffentlichung interpretieren

Beispiele für Veröffentlichungen:

127.0.0.1:8080:80

Bedeutung:

Host 127.0.0.1:8080
→ Containerport 80

Dieser Hostport soll nur lokal erreichbar sein.

8080:80

Bedeutung:

Hostport 8080
→ Containerport 80

Ohne ausdrücklich angegebene Hostadresse veröffentlicht Docker den Port standardmäßig auf den Hostadressen. Die genaue Erreichbarkeit hängt zusätzlich von Docker-, Firewall- und IPv4-/IPv6-Konfiguration ab.

Wichtige Unterscheidungen:

  • EXPOSE im Image veröffentlicht keinen Hostport;
  • -p beziehungsweise --publish erstellt eine Portveröffentlichung;
  • -P veröffentlicht dafür vorgesehene Ports automatisch auf Hostports;
  • Hostport und Containerport können unterschiedlich sein;
  • Container-IP und Host-IP sind unterschiedliche Adressen;
  • der Listener im Container muss zum Containerport passen;
  • im Host-Netzwerkmodus teilt der Container den Netzwerk-Namespace des Hosts;
  • im Host-Netzwerkmodus werden normale Publish-Optionen nicht wie bei einem Bridge-Netzwerk verwendet.

Ein veröffentlichter Docker-Port muss nicht immer als gewöhnlicher Benutzerprozess-Listener in der erwarteten Host-Socketliste erscheinen. Weiterleitung kann abhängig von Plattform und Konfiguration über Firewall-, NAT- oder Proxymechanismen erfolgen.

Kubernetes: Portebenen unterscheiden

Bei Kubernetes sind mehrere Portangaben auseinanderzuhalten:

Feld Bedeutung
containerPort Deklarative Portangabe am Container; erzwingt keinen Listener.
targetPort Port, zu dem ein Service im ausgewählten Pod weiterleitet.
port Port des Kubernetes-Service.
nodePort Optionaler Port auf den Clusterknoten.
Pod-Port Tatsächlicher Socket des Prozesses im Pod.
Ingress-/Gateway-Port Extern bereitgestellter Listener eines Proxys oder Gateways.

Beispiel:

ports:
  - name: https
    port: 443
    targetPort: 8443

Der Service nimmt Verkehr auf Port 443 an und leitet ihn zum Zielport 8443 weiter.

Wenn targetPort nicht angegeben wird, entspricht er standardmäßig dem Wert von port.

Ein eingetragener containerPort erzeugt keinen Socket und startet keinen Dienst.

Kubernetes-Service und Endpunkte prüfen

LESEND

Services:

kubectl get service \
  --all-namespaces

Bestimmten Service beschreiben:

kubectl describe service \
  <Servicename> \
  -n <Namespace>

Service als YAML anzeigen:

kubectl get service \
  <Servicename> \
  -n <Namespace> \
  -o yaml

EndpointSlices anzeigen:

kubectl get endpointslice \
  -n <Namespace> \
  -l kubernetes.io/service-name=<Servicename> \
  -o wide

Pods und Pod-Adressen:

kubectl get pods \
  -n <Namespace> \
  -o wide

Pod beschreiben:

kubectl describe pod \
  <Podname> \
  -n <Namespace>

Listener im Pod, falls das Werkzeug vorhanden ist:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -- ss -lntup

Bei mehreren Containern im Pod:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -c <Containername> \
  -- ss -lntup

Zu prüfen sind:

  • Service-Port;
  • targetPort;
  • benannter oder numerischer Zielport;
  • Selektor des Service;
  • passende Pods;
  • Ready-Zustand der Pods;
  • vorhandene EndpointSlices;
  • tatsächlicher Listener im Pod;
  • Bindung an Pod-IP oder Wildcard;
  • NetworkPolicy;
  • Sidecar- oder Service-Mesh-Proxy;
  • Ingress- oder Gateway-Konfiguration.

Ein Service ohne passende Endpunkte kann existieren, obwohl kein Backend erreichbar ist.

Besonderheiten von NodePort, Service und Ingress

Ein Kubernetes-NodePort oder ein durch Regeln weitergeleiteter Service-Port muss nicht als klassischer Anwendungsprozess im Zustand LISTEN erscheinen. Je nach Plattform wird der Verkehr beispielsweise durch:

  • kube-proxy;
  • nftables;
  • iptables;
  • IPVS;
  • eBPF;
  • einen Cloud Load Balancer;
  • ein Ingress-Gateway

weitergeleitet.

Deshalb sind für Kubernetes mehrere Ebenen zu prüfen:

externer Listener oder Load Balancer
→ NodePort beziehungsweise Service
→ EndpointSlice
→ Pod-IP und targetPort
→ Prozess im Pod

Die alleinige Suche nach einem Hostprozess mit dem externen Port kann zu einer falschen Schlussfolgerung führen.

IPv4 und IPv6 getrennt prüfen

Zu prüfen sind:

  • existiert ein IPv4-Listener?
  • existiert ein IPv6-Listener?
  • welche Adresse liefert DNS?
  • welche Adresse wählt der Client zuerst?
  • ist die Firewall für beide Protokollfamilien passend konfiguriert?
  • existiert für beide Adressfamilien eine Route?
  • liefert die Anwendung auf beiden Pfaden dieselbe Antwort?

Windows:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

sudo ss -lntp 'sport = :443'

Gezielter IPv4-Test:

curl -4 -v https://app.example.test/

Gezielter IPv6-Test:

curl -6 -v https://app.example.test/

Wenn IPv6 fehlschlägt und IPv4 funktioniert, darf der Fehler nicht durch dauerhaftes Abschalten von IPv6 verdeckt werden. Bindung, Routing, DNS und Firewall müssen getrennt untersucht werden.

Temporäre und dynamische Clientports

Beim Aufbau einer ausgehenden Verbindung verwendet der Client normalerweise einen lokalen Quellport aus einem dynamischen Bereich.

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.25:443

Der Serverdienst lauscht auf Port 443. Der Clientport 53124 wurde für diese Verbindung lokal ausgewählt.

Typische Diagnosefehler:

  • den dynamischen Clientport mit dem Serverport verwechseln;
  • eine eingehende Firewallregel für den Clientquellport erwarten;
  • einen TIME-WAIT-Eintrag als Serverlistener interpretieren;
  • nur nach dem Zielport suchen und die Verbindungsrichtung ignorieren.

Die ausführliche Diagnose dynamischer Ports und Porterschöpfung erfolgt in der dafür vorgesehenen Folgeseite.

Dienststatus und Socketstatus vergleichen

Dienststatus Socketstatus Einordnung
läuft Listener vorhanden Dienst hat mindestens einen erwarteten Socket angelegt
läuft Listener fehlt Start teilweise fehlgeschlagen, falsche Konfiguration oder falscher Namespace
beendet Listener vorhanden anderer Prozess, Kernelkomponente oder alte Instanz besitzt den Port
startet wiederholt Listener erscheint kurz Absturz, Health-Check-Fehler oder Portkonflikt möglich
läuft falsche Adresse Bindung oder Schnittstellenkonfiguration fehlerhaft
läuft falscher Port Konfigurationsquelle oder Startparameter prüfen

Ein grüner Dienststatus ist kein ausreichender Funktionsnachweis.

Konfigurationsquelle des Listeners bestimmen

Mögliche Quellen der Bindung:

  • Anwendungskonfigurationsdatei;
  • Kommandozeilenparameter;
  • Umgebungsvariable;
  • Windows-Registry;
  • systemd-Unit;
  • Socketaktivierung;
  • Docker-Compose-Datei;
  • Kubernetes-Manifest;
  • Helm-Werte;
  • Reverse-Proxy-Konfiguration;
  • Orchestrator oder Service Discovery;
  • durch Gruppenrichtlinie oder zentrale Verwaltung gelieferte Einstellung.

Zu dokumentieren sind:

wirksamer Port:
<Port>

wirksame Bindungsadresse:
<Adresse>

Quelle:
<Datei, Parameter, Variable oder zentrale Richtlinie>

geladene Version:
<Version oder Prüfsumme>

Zeitpunkt der letzten Änderung:
<Zeitpunkt>

Neustart erforderlich:
<ja oder nein>

Die Änderung einer nicht wirksamen Konfigurationsdatei führt zu keinem belastbaren Ergebnis. Zuerst muss bestimmt werden, welche Konfiguration der laufende Prozess tatsächlich verwendet.

Netzwerkaufzeichnung gezielt einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

  • ob der Client ein SYN sendet;
  • ob das SYN den Server erreicht;
  • ob der Server mit SYN/ACK oder RST antwortet;
  • ob die Antwort den Client erreicht;
  • ob UDP-Anfragen und Antworten übertragen werden;
  • ob ein Proxy oder Load Balancer beteiligt ist;
  • ob IPv4 oder IPv6 verwendet wird;
  • ob Verbindungen wiederholt aufgebaut werden;
  • ob der Server die Verbindung nach dem Aufbau beendet.

Linux:

SENSITIV · LESEND

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 100

Auf eine Gegenstelle begrenzen:

sudo tcpdump \
  -ni any \
  'host 198.51.100.40 and tcp port 443' \
  -c 100

UDP-Beispiel:

sudo tcpdump \
  -ni any \
  'udp port 53' \
  -c 100

macOS mit konkreter Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'tcp port 443' \
  -c 100

Lokalen macOS-Verkehr auf Loopback:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 100

Aufzeichnungen müssen auf den benötigten Port, Host und Zeitraum begrenzt werden. Sie können sensible Adressen und Nutzdaten enthalten.

TCP-Paketbefunde einordnen

Beobachtung Mögliche Einordnung
SYN verlässt Client, erreicht Server nicht Routing, Firewall, NAT oder falsche Zieladresse
SYN erreicht Server, keine Antwort Filterung, Überlastung oder falscher Netzwerk-Namespace
SYN erreicht Server, RST folgt häufig kein passender Listener oder aktive Ablehnung
SYN, SYN/ACK, ACK sichtbar TCP-Verbindungsaufbau erfolgreich
Aufbau erfolgreich, sofortiges FIN Anwendung beendet Verbindung kontrolliert
Aufbau erfolgreich, sofortiges RST Anwendung, Proxy oder Protokollfehler möglich
Server antwortet, Antwort erreicht Client nicht Rückweg, Firewall, asymmetrisches Routing
wiederholte SYN-Pakete Client erhält keine verwertbare Antwort

Die Paketaufzeichnung muss möglichst auf beiden Seiten oder an einem geeigneten Zwischenpunkt korreliert werden. Eine Aufzeichnung nur am Client zeigt nicht sicher, ob das Paket den Server erreicht hat.

Systematischer Diagnoseablauf

  1. Exakte Fehlermeldung, Zeitpunkt und betroffene Anwendung dokumentieren.
  2. Erwartetes Transportprotokoll bestimmen.
  3. Erwarteten lokalen und entfernten Port bestimmen.
  4. Erwartete Bindungsadresse festlegen.
  5. Erforderliche Erreichbarkeit bestimmen: lokal, LAN, VPN oder öffentlich.
  6. Host, Container, Pod und Netzwerk-Namespace unterscheiden.
  7. Tatsächliche IP-Adressen des Systems erfassen.
  8. DNS-Auflösung des Zielnamens dokumentieren.
  9. TCP-Listener oder UDP-Endpunkt erfassen.
  10. IPv4- und IPv6-Bindung getrennt auswerten.
  11. Besitzenden Prozess bestimmen.
  12. Prozess einem Dienst, Container oder Pod zuordnen.
  13. Wirksame Konfigurationsquelle bestimmen.
  14. Dienstprotokolle zum Startzeitpunkt prüfen.
  15. Auf Portkonflikte oder Bindungsfehler prüfen.
  16. Loopback-Endpunkt testen.
  17. Konkrete lokale Schnittstellenadresse testen.
  18. Test von einem repräsentativen entfernten Client durchführen.
  19. Firewall, NAT und Portweiterleitung prüfen.
  20. Reverse Proxy, Load Balancer oder Kubernetes-Service berücksichtigen.
  21. Nach erfolgreichem Transport das Anwendungsprotokoll testen.
  22. Bei Bedarf eine begrenzte Netzwerkaufzeichnung durchführen.
  23. Hypothese, erwarteten Befund und Gegenbeweis formulieren.
  24. Genau eine kontrollierte Maßnahme durchführen.
  25. Identische Tests wiederholen.
  26. Anwendung und weitere repräsentative Clients verifizieren.
  27. Temporäre Diagnoseänderungen zurücknehmen.
  28. Ursache und Prävention dokumentieren.

Hypothese und Gegenbeweis

Beispiel:

Hypothese:
Der Webdienst ist ausschließlich an 127.0.0.1:8080 gebunden und deshalb
von entfernten Clients nicht direkt erreichbar.

Erwarteter Befund:
Der lokale Test gegen 127.0.0.1:8080 funktioniert.
Die Socketliste zeigt keinen Listener auf 192.0.2.25:8080 oder
0.0.0.0:8080.
Der Test eines entfernten Clients schlägt fehl.

Gegenbeweis:
Die Socketliste zeigt einen Listener auf 0.0.0.0:8080 und eine
Netzwerkaufzeichnung bestätigt, dass der Server eingehende SYN-Pakete
mit SYN/ACK beantwortet.

Testmethode:
Socketliste, lokaler Test, entfernter Test und begrenzte Aufzeichnung.

Risiko:
Die lesenden Socketprüfungen sind risikoarm. Aktive Tests erzeugen
Netzwerkverkehr, verändern aber nicht die Dienstkonfiguration.

Eine Änderung darf erst erfolgen, wenn die vermutete Ursache einen messbaren Befund besitzt.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Bindungsadresse korrigieren falsche Adresse nachgewiesen Dienst kann auf weiteren Netzen erreichbar werden
Port korrigieren Soll- und Ist-Port unterscheiden sich nachweislich Clients oder Überwachung verwenden eventuell alten Port
kollidierenden Prozess beenden falscher Prozessbesitz eindeutig bestätigt Prozess oder abhängiger Dienst fällt aus
Dienst geordnet neu starten Konfigurationsänderung erfordert Neustart bestehende Verbindungen werden unterbrochen
Firewallregel anpassen Listener funktioniert lokal und Filterung ist bestätigt unbeabsichtigte Freigabe
Docker-Portzuordnung korrigieren falscher Host- oder Containerport bestätigt Container muss eventuell neu erstellt werden
Kubernetes-targetPort korrigieren Service und Pod-Listener stimmen nicht überein laufender Dienstverkehr wird umgeleitet
Reverse-Proxy-Ziel korrigieren falscher Backendendpunkt nachgewiesen alle über den Proxy laufenden Anfragen betroffen
IPv4-/IPv6-Bindung korrigieren Protokollfamilienfehler bestätigt zusätzliche Angriffsfläche oder geänderte Erreichbarkeit
Socketdateiberechtigung korrigieren Unix-Socket und Zugriffsfehler bestätigt weitere lokale Prozesse können Zugriff erhalten

Vor der Maßnahme sind zu dokumentieren:

  • Ausgangszustand;
  • betroffener Endpunkt;
  • Prozess und Dienst;
  • Konfigurationsquelle;
  • erwartete Wirkung;
  • Sicherheitsauswirkung;
  • Wartungsfenster;
  • Rückweg;
  • Erfolgskriterium.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
Dienst läuft, Port fehlt Bindung fehlgeschlagen oder falsche Konfiguration Startprotokoll und wirksame Konfiguration
Port vorhanden, falscher Prozess Portkonflikt oder unerwarteter Dienst Prozesspfad und Dienstzuordnung
Listener nur auf 127.0.0.1 nur lokale Erreichbarkeit vorgesehen oder Fehlkonfiguration Sollbindung und Proxyaufbau prüfen
Listener auf 0.0.0.0 alle geeigneten IPv4-Adressen Firewall und tatsächliche Erreichbarkeit prüfen
Listener nur auf [::] IPv6-Wildcard IPv4 und IPv6 ausdrücklich getrennt testen
lokaler Test funktioniert, remote nicht Firewall, Routing, NAT oder Bindungsumfang entfernte Aufzeichnung und Firewallzustand
TCP-Verbindung funktioniert, Anwendung nicht Anwendungs- oder Protokollfehler HTTP-, TLS- oder Diensttest
Connection refused häufig kein passender Listener Server-Socketliste und Paketaufzeichnung
Timeout keine verwertbare Antwort Routing, Filterung und Aufzeichnung
UDP-Endpunkt sichtbar, keine Antwort Anwendung, Firewall oder Rückweg protokollspezifischer Test und Aufzeichnung
Port erscheint kurz und verschwindet Prozess beendet sich oder startet neu Prozess- und Dienstprotokolle
Bindung meldet Address already in use Endpunkt bereits belegt Besitzer des vorhandenen Sockets bestimmen
Bindung meldet Address not available konfigurierte lokale IP fehlt Schnittstellen und Startreihenfolge
Docker-Port veröffentlicht, Anwendung nicht erreichbar falscher Containerport oder Loopback-Bindung im Container Listener innerhalb des Containers
Kubernetes-Service ohne Endpunkte Selektor oder Readiness fehlerhaft Pods und EndpointSlices
Service-Port stimmt, targetPort falsch Weiterleitung auf falschen Pod-Port Service-YAML und Pod-Listener
Host zeigt keinen Listener, NodePort funktioniert regelbasierte Weiterleitung Kubernetes- und Host-Netzwerkregeln
nur localhost schlägt fehl IPv4-/IPv6-Auswahl oder Hosts-Auflösung 127.0.0.1 und ::1 einzeln testen
nur einige Clients scheitern Netzpfad, Adressfamilie oder Richtlinie erfolgreiche und fehlerhafte Pfade vergleichen

Typische Diagnosefehler

  • TCP und UDP nicht unterscheiden.
  • Einen UDP-Endpunkt als TCP-Listener interpretieren.
  • Nur nach der Portnummer suchen und das Protokoll ignorieren.
  • 0.0.0.0 als verwendbare Zieladresse eines Clients behandeln.
  • Loopback-Bindung und Wildcard-Bindung gleichsetzen.
  • Einen Listener als vollständigen Funktionsnachweis bewerten.
  • Nur den Dienststatus prüfen.
  • Den besitzenden Prozess nicht bestimmen.
  • Prozess-ID aus einer alten Aufnahme verwenden.
  • IPv4 und IPv6 nicht getrennt prüfen.
  • localhost als eindeutigen IPv4-Test behandeln.
  • Wildcard-Bindung automatisch als öffentliche Erreichbarkeit interpretieren.
  • Öffentliche Erreichbarkeit allein durch lokale Socketlisten bewerten.
  • Test-NetConnection -Port als UDP-Test verwenden.
  • Einen offenen TCP-Port mit funktionierendem TLS oder HTTP gleichsetzen.
  • Host- und Containerport verwechseln.
  • Container-IP und Host-IP verwechseln.
  • Den falschen Netzwerk-Namespace untersuchen.
  • EXPOSE mit einer Docker-Portveröffentlichung gleichsetzen.
  • Kubernetes-containerPort als echten Listener interpretieren.
  • port, targetPort und nodePort verwechseln.
  • Bei NodePort nur nach einem Benutzerprozess-Listener suchen.
  • Einen Reverse Proxy und sein Backend als einen einzigen Endpunkt behandeln.
  • Einen Portkonflikt durch wiederholte Neustarts verdecken.
  • Einen Prozess beenden, bevor seine Funktion und Abhängigkeiten geklärt sind.
  • Die Firewall vollständig deaktivieren.
  • Breite Portscans ohne technische Notwendigkeit durchführen.
  • Netzwerkaufzeichnungen unbegrenzt laufen lassen.
  • Sensible Socket- oder Paketdaten ungeschützt speichern.
  • Mehrere Konfigurationsvariablen gleichzeitig verändern.
  • Nach der Maßnahme nur lokal testen.
  • Temporäre Regeln und Diagnosewerkzeuge aktiv lassen.

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

  • der erwartete Prozess läuft;
  • der Prozess besitzt den vorgesehenen Socket;
  • das richtige Transportprotokoll wird verwendet;
  • der richtige lokale Port ist gebunden;
  • die richtige lokale Adresse ist gebunden;
  • die Bindung existiert im richtigen Netzwerk-Namespace;
  • keine unerwartete zusätzliche Bindung besteht;
  • IPv4 funktioniert, sofern vorgesehen;
  • IPv6 funktioniert, sofern vorgesehen;
  • Loopback-Verhalten entspricht der Planung;
  • konkrete Schnittstellenadressen funktionieren;
  • lokale Firewallregeln entsprechen dem Sollzustand;
  • NAT oder Portweiterleitung verwendet den richtigen Zielport;
  • Docker-Host- und Containerport stimmen überein;
  • Kubernetes-port und targetPort stimmen mit dem Pod-Listener überein;
  • EndpointSlices enthalten die vorgesehenen Backends;
  • Reverse Proxy oder Load Balancer erreicht das Backend;
  • ein repräsentativer entfernter Client kann den Endpunkt erreichen;
  • das Anwendungsprotokoll liefert die erwartete Antwort;
  • keine neuen Bindungs-, Prozess- oder Dienstfehler entstehen;
  • temporäre Diagnoseänderungen wurden zurückgenommen;
  • Sicherheitsauswirkungen der Bindung wurden geprüft;
  • Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine einzelne erfolgreiche lokale TCP-Verbindung ist keine ausreichende Gesamtverifikation.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Dienst:
<Dienst oder Anwendung>

Betroffener Host:
<Hostname und IP-Adresse>

Netzwerk-Namespace:
<Host, Container, Pod oder anderer Namespace>

Transportprotokoll:
<TCP oder UDP>

Erwartete Bindung:
<Adresse und Port>

Tatsächliche Bindung:
<Adresse und Port>

Prozess:
<Name, PID und Pfad>

Dienstzuordnung:
<Service, Container oder Pod>

Konfigurationsquelle:
<Datei, Startparameter, Variable oder Manifest>

Lokaler Test:
<Zieladresse, Port und Ergebnis>

Entfernter Test:
<Client, Zieladresse, Port und Ergebnis>

Anwendungsprotokolltest:
<Test und Ergebnis>

Firewall-, NAT- oder Proxyweg:
<Befund>

IPv4-Befund:
<Ergebnis>

IPv6-Befund:
<Ergebnis>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identische Tests und Anwendungstest>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

  • exakte Fehlermeldung dokumentiert
  • Zeitpunkt dokumentiert
  • Anwendung oder Dienst bestimmt
  • TCP und UDP unterschieden
  • erwarteten Port bestimmt
  • erwartete Bindungsadresse bestimmt
  • erforderliche Erreichbarkeit bestimmt
  • Host, Container und Pod unterschieden
  • Netzwerk-Namespace bestimmt
  • lokale IP-Adressen erfasst
  • DNS-Zieladressen dokumentiert
  • TCP-Listener geprüft
  • UDP-Endpunkte bei Bedarf geprüft
  • IPv4-Bindung geprüft
  • IPv6-Bindung geprüft
  • Loopback-Bindung geprüft
  • Wildcard-Bindung geprüft
  • Bindung an konkrete Adresse geprüft
  • Prozess-ID bestimmt
  • Prozessname und Pfad geprüft
  • Dienstzuordnung geprüft
  • Konfigurationsquelle bestimmt
  • Startparameter und Umgebungsvariablen berücksichtigt
  • Dienstprotokolle ausgewertet
  • Portkonflikt ausgeschlossen
  • Kernel- oder HTTP.sys-Zuordnung bei Bedarf geprüft
  • Portproxy bei Bedarf geprüft
  • lokalen Loopback-Test durchgeführt
  • konkrete lokale Serveradresse getestet
  • entfernten Clienttest durchgeführt
  • Quell- und Zieladresse dokumentiert
  • Firewallzustand berücksichtigt
  • NAT und Portweiterleitung berücksichtigt
  • Reverse Proxy berücksichtigt
  • Load Balancer berücksichtigt
  • Docker-Portzuordnung bei Bedarf geprüft
  • Listener innerhalb des Containers geprüft
  • Kubernetes-Service bei Bedarf geprüft
  • port und targetPort verglichen
  • EndpointSlices geprüft
  • tatsächlichen Pod-Listener geprüft
  • Anwendungsprotokoll getestet
  • UDP mit protokollspezifischem Werkzeug geprüft
  • bei Bedarf Netzwerkaufzeichnung durchgeführt
  • Aufzeichnung technisch und zeitlich begrenzt
  • Hypothese formuliert
  • Gegenbeweis festgelegt
  • Risiko und Rückweg dokumentiert
  • nur eine kontrollierte Änderung durchgeführt
  • identische Tests wiederholt
  • ursprüngliche Anwendung getestet
  • repräsentative entfernte Clients geprüft
  • temporäre Änderungen zurückgenommen
  • Ursache und Prävention dokumentiert

Schnellreferenz

Aufgabe Befehl
Windows-TCP-Verbindungen Get-NetTCPConnection
Windows-TCP-Listener Get-NetTCPConnection -State Listen
Windows-Port prüfen Get-NetTCPConnection -State Listen -LocalPort <Port>
Windows-UDP-Endpunkte Get-NetUDPEndpoint
Windows-UDP-Port prüfen Get-NetUDPEndpoint -LocalPort <Port>
Windows-Prozess prüfen Get-Process -Id <PID>
Windows-Dienst zu PID Get-CimInstance Win32_Service -Filter "ProcessId = <PID>"
Windows-netstat netstat -ano
Windows-IP-Adressen Get-NetIPAddress
Windows-TCP-Test Test-NetConnection -ComputerName <Ziel> -Port <Port>
Windows-HTTP.sys-Zustand netsh http show servicestate
Windows-URL-Reservierungen netsh http show urlacl
Windows-Portproxy netsh interface portproxy show all
Linux-TCP-Listener sudo ss -lntp
Linux-UDP-Endpunkte sudo ss -lnup
Linux-TCP-Port prüfen sudo ss -lntp 'sport = :<Port>'
Linux-Socketübersicht ss -s
Linux-Prozess zu TCP-Port sudo lsof -nP -iTCP:<Port> -sTCP:LISTEN
Linux-Prozess zu UDP-Port sudo lsof -nP -iUDP:<Port>
Linux-IP-Adressen ip -brief address
Linux-Netzwerk-Namespaces ip netns list
macOS-TCP-Listener sudo lsof -nP -iTCP -sTCP:LISTEN
macOS-UDP-Endpunkte sudo lsof -nP -iUDP
macOS-TCP-Sockets netstat -anv -p tcp
Unix-Domain-Sockets Linux sudo ss -lxnp
Unix-Domain-Sockets mit lsof sudo lsof -U
TCP-Test Linux/macOS nc -vz <Ziel> <Port>
HTTP-Test curl -v http://<Ziel>:<Port>/
HTTPS-Test mit Zieladresse curl -v --resolve <Name>:<Port>:<IP> https://<Name>/
TLS-Test mit SNI openssl s_client -connect <IP>:<Port> -servername <Name>
Docker-Portübersicht docker ps --format 'table {{.Names}}\t{{.Ports}}'
Docker-Portzuordnung docker port <Container>
Docker-Netzwerkmodus docker inspect <Container> --format '{{.HostConfig.NetworkMode}}'
Listener im Container docker exec <Container> ss -lntup
Kubernetes-Services kubectl get service --all-namespaces
Kubernetes-Service prüfen kubectl describe service <Service> -n <Namespace>
Kubernetes-EndpointSlices kubectl get endpointslice -n <Namespace> -l kubernetes.io/service-name=<Service>
Listener im Pod kubectl exec -n <Namespace> <Pod> -- ss -lntup
begrenzte Linux-Aufzeichnung sudo tcpdump -ni any 'tcp port <Port>' -c 100

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
Set-NetFirewallRule
New-NetFirewallRule
Remove-NetFirewallRule
netsh advfirewall set allprofiles state off
kill
kill -9
systemctl stop
systemctl restart
iptables
nft
ufw disable
firewall-cmd --permanent
docker stop
docker restart
docker rm
kubectl delete
kubectl rollout restart
Änderung einer Wildcard- oder öffentlichen Bindung
Entfernen einer Portweiterleitung
vollständiges Deaktivieren einer Hostfirewall

Das Beenden eines Prozesses oder Neustarten eines Dienstes kann den aktuellen Portbesitz zwar verändern, vernichtet aber möglicherweise den für die Ursachenanalyse wichtigen Ausgangszustand.

Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Unix-Dokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Standards und Register

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

Back to top