4.4 Listener, Ports und Bindungsadressen prüfen

Beispiel einer TCP-Verbindung:

Client:  192.0.2.50:53124
Server:  192.0.2.20:443

Dabei ist 53124 normalerweise ein temporärer Clientport und 443 der bekannte Serverport.

Vor der Listenerprüfung müssen folgende Sollwerte bekannt sein:

Unzureichende Prüffrage:

„Ist Port 443 offen?“

Bessere Prüffragen:

• Lauscht der erwartete Prozess auf TCP-Port 443?
• Lauscht er auf der richtigen IPv4- oder IPv6-Adresse?
• Ist der Port lokal erreichbar?
• Ist er von einem vorgesehenen Clientnetz erreichbar?
• Antwortet dort tatsächlich das erwartete Anwendungsprotokoll?
• Wird der Zugriff durch einen Proxy oder Loadbalancer vermittelt?

Beispiel:

Ein Server besitzt folgende Adressen:

127.0.0.1
192.0.2.20
198.51.100.20

Der Dienst bindet sich an:

127.0.0.1:8080

Dann ist der Dienst normalerweise nicht direkt über 192.0.2.20:8080 oder 198.51.100.20:8080 erreichbar.

Bindet er sich an:

0.0.0.0:8080

nimmt er grundsätzlich auf allen lokalen IPv4-Adressen Verbindungen an. Firewall- und Routingregeln gelten zusätzlich.

Eine Wildcard-Bindung bedeutet nicht, dass der Port aus jedem Netzwerk erreichbar ist. Paketfilter, Routing, NAT, Sicherheitsgruppen und vorgeschaltete Systeme können den Zugriff weiterhin verhindern.

Alle TCP-Listener anzeigen:

[RO] Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort, LocalAddress

Wichtige Felder auswählen:

[RO] Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort, State, OwningProcess |
    Sort-Object LocalPort, LocalAddress

Bestimmten TCP-Port prüfen:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Bestimmte lokale Adresse und Port prüfen:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalAddress "<IP-ADRESSE>" `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Klassische Alternative:

[RO] netstat -ano -p tcp

Nur TCP-Listener mit netstat:

[RO] netstat -ano -p tcp |
    Select-String "LISTENING"

Get-NetTCPConnection liefert strukturierte PowerShell-Objekte und ist deshalb für gezielte Filterungen besser geeignet als das Verarbeiten formatierter netstat-Ausgaben.

UDP besitzt keinen Verbindungszustand Listen. Stattdessen werden gebundene UDP-Endpunkte angezeigt.

Alle UDP-Endpunkte anzeigen:

[RO] Get-NetUDPEndpoint |
    Select-Object LocalAddress, LocalPort, OwningProcess |
    Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

[RO] Get-NetUDPEndpoint `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Klassische Alternative:

[RO] netstat -ano -p udp

Wichtig:

• Das Vorhandensein eines UDP-Endpunkts zeigt nur eine lokale Bindung.
• UDP verwendet keinen TCP-Handshake.
• Ein UDP-Porttest kann deshalb nicht so eindeutig wie ein TCP-Verbindungstest bewertet werden.
• Eine fehlende UDP-Antwort kann normal sein, wenn die Testanfrage nicht dem erwarteten Anwendungsprotokoll entspricht.

TCP-Port und Prozess-ID ermitteln:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess

Zugehörigen Prozess anzeigen:

[RO] $connection = Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

$connection |
    ForEach-Object {
        Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    } |
    Select-Object Id, ProcessName, StartTime

Prozess und Dienst über eine gefundene PID zuordnen:

[RO] Get-CimInstance Win32_Service -Filter "ProcessId=<PID>" |
    Select-Object Name, DisplayName, State, StartName

Alle TCP-Listener zusammen mit Prozessnamen anzeigen:

[RO] Get-NetTCPConnection -State Listen |
    ForEach-Object {
        $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue

        [PSCustomObject]@{
            LocalAddress = $_.LocalAddress
            LocalPort    = $_.LocalPort
            PID          = $_.OwningProcess
            ProcessName  = $process.ProcessName
        }
    } |
    Sort-Object LocalPort, LocalAddress

Mehrere Listener können dieselbe PID verwenden. Ebenso kann ein Prozess auf mehreren Adressen und Ports lauschen.

ss ist auf modernen Linux-Systemen das bevorzugte Werkzeug für Socketinformationen.

Alle lauschenden TCP-Sockets numerisch anzeigen:

[RO] ss -lnt

TCP-Listener einschließlich Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -lntp

Gebundene UDP-Sockets anzeigen:

[RO] ss -lnu

UDP-Sockets einschließlich Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -lnup

TCP- und UDP-Sockets gemeinsam anzeigen:

[RO][PRIV] sudo ss -lntup

Bedeutung wichtiger Optionen:

Nur IPv4-TCP-Listener:

[RO] ss -4 -lnt

Nur IPv6-TCP-Listener:

[RO] ss -6 -lnt

Ohne ausreichende Berechtigungen können Prozessname und PID in der Ausgabe fehlen.

Bestimmten TCP-Listener prüfen:

[RO][PRIV] sudo ss -lntp "sport = :<PORT>"

Bestimmten UDP-Port prüfen:

[RO][PRIV] sudo ss -lnup "sport = :<PORT>"

Offene Netzwerkressourcen einer PID anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

TCP-Listener einer PID anzeigen:

[RO][SENS][PRIV] sudo lsof \
    -nP \
    -a \
    -p <PID> \
    -iTCP \
    -sTCP:LISTEN

Bestimmten TCP-Port mit lsof prüfen:

[RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN

Bestimmten UDP-Port mit lsof prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

lsof ist nicht auf jeder minimalen Linux-Installation vorhanden. In diesem Fall kann zunächst ss verwendet werden.

Alle TCP-Listener anzeigen:

[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

[RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN

Gebundene UDP-Sockets anzeigen:

[RO][PRIV] sudo lsof -nP -iUDP

Bestimmten UDP-Port prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

Netzwerksockets einer bestimmten PID anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

TCP-Verbindungen und Listener mit netstat anzeigen:

[RO] netstat -anv -p tcp

UDP-Sockets mit netstat anzeigen:

[RO] netstat -anv -p udp

Unter macOS ist lsof für die Zuordnung von Netzwerkendpunkten zu Prozessen meist übersichtlicher als netstat.

Beispiel eines TCP-Listeners:

LISTEN  0  128  0.0.0.0:443  0.0.0.0:*

Interpretation:

Beispiel einer aufgebauten Verbindung:

192.0.2.20:443  192.0.2.50:53124  ESTABLISHED

Interpretation:

Lokaler Serverendpunkt:  192.0.2.20:443
Entfernter Client:       192.0.2.50:53124
Zustand:                 Verbindung aufgebaut

Bei der Auswertung muss zuerst bestimmt werden, welches System Client und welches System Server ist. Ein hoher temporärer Port gehört häufig zum Client.

Ein Dienst kann:

• nur auf IPv4 lauschen,
• nur auf IPv6 lauschen,
• getrennte IPv4- und IPv6-Sockets verwenden,
• einen IPv6-Wildcard-Socket verwenden,
• abhängig vom Betriebssystem IPv4-Verbindungen über einen IPv6-Socket annehmen.

Windows – IPv4-Listener eines Ports:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Where-Object LocalAddress -NotLike "*:*"

Windows – IPv6-Listener eines Ports:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Where-Object LocalAddress -Like "*:*"

Linux – IPv4 prüfen:

[RO][PRIV] sudo ss -4 -lntp "sport = :<PORT>"

Linux – IPv6 prüfen:

[RO][PRIV] sudo ss -6 -lntp "sport = :<PORT>"

macOS – IPv4 prüfen:

[RO][PRIV] sudo lsof -nP -i4TCP:<PORT> -sTCP:LISTEN

macOS – IPv6 prüfen:

[RO][PRIV] sudo lsof -nP -i6TCP:<PORT> -sTCP:LISTEN

Aus einer Bindung an [::]:<PORT> darf nicht ungeprüft geschlossen werden, dass IPv4 ebenfalls funktioniert. IPv4 und IPv6 müssen praktisch getrennt getestet werden.

Ein lokaler Test hilft zu unterscheiden, ob der Dienst grundsätzlich Verbindungen annimmt oder ob nur der externe Zugriff fehlschlägt.

Windows – IPv4-Loopback testen:

[TEST] Test-NetConnection 127.0.0.1 -Port <PORT>

Windows – konkrete Serveradresse testen:

[TEST] Test-NetConnection <SERVER-IP> -Port <PORT>

Linux – IPv4-Loopback testen:

[TEST] nc -vz -w 3 127.0.0.1 <PORT>

Linux – konkrete Serveradresse testen:

[TEST] nc -vz -w 3 <SERVER-IP> <PORT>

macOS – IPv4-Loopback testen:

[TEST] nc -vz -w 3 127.0.0.1 <PORT>

macOS – konkrete Serveradresse testen:

[TEST] nc -vz -w 3 <SERVER-IP> <PORT>

IPv6-Loopback unter Linux oder macOS testen:

[TEST] nc -6 -vz -w 3 ::1 <PORT>

Interpretation:

Ein erfolgreicher TCP-Porttest beweist nur, dass ein TCP-Verbindungsaufbau möglich war. Er beweist nicht, dass die Anwendung fachlich korrekt antwortet.

Der Test sollte aus dem tatsächlich betroffenen Netzwerk oder von einem vergleichbaren Client erfolgen.

Windows mit ausführlicher Ausgabe:

[TEST] Test-NetConnection <SERVER> -Port <PORT> -InformationLevel Detailed

Wichtige Ausgabe:

ComputerName
RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Prüffragen:

• Wurde der erwartete Servername verwendet?
• Wurde der Name zur erwarteten IP-Adresse aufgelöst?
• Verwendet der Test die erwartete Quelladresse?
• Erfolgt der Test über das vorgesehene Netzwerkinterface?
• Ist der Port nur aus bestimmten Netzen erreichbar?
• Wird IPv4 oder IPv6 verwendet?
• Besteht zwischen Client und Server ein Proxy, VPN oder Loadbalancer?

Linux oder macOS:

[TEST] nc -vzu -w 3 <SERVER> <PORT>

Ein solcher Test kann jedoch häufig nicht zuverlässig bestätigen, dass:

• ein UDP-Dienst tatsächlich antwortet,
• die Anwendung die Testdaten verstanden hat,
• eine Firewall die Pakete verworfen hat,
• die Rückantwort den Client erreicht,
• der Dienst fachlich funktioniert.

Bessere UDP-Prüfung:

Bei UDP ist ein protokollspezifischer Funktionstest wesentlich aussagekräftiger als ein allgemeiner Portscan.

Wenn ein lokaler Porttest erfolgreich ist, ein entfernter Test aber fehlschlägt, kommen unter anderem folgende Ursachen infrage:

• Dienst bindet nur an Loopback,
• Dienst bindet an die falsche Netzwerkschnittstelle,
• lokale Hostfirewall blockiert externe Quellen,
• Netzwerkfirewall blockiert den Zielport,
• Routing zum Server oder zurück zum Client fehlt,
• falsches VLAN wird verwendet,
• Zugriff erfolgt über falsche IP-Adresse,
• IPv4 und IPv6 werden verwechselt,
• NAT- oder Portweiterleitung ist fehlerhaft,
• Sicherheitsgruppe oder Cloud-Firewall blockiert,
• Reverse Proxy oder Loadbalancer leitet nicht weiter,
• VPN-Richtlinie erlaubt das Zielnetz nicht,
• Dienst akzeptiert nur bestimmte Quelladressen.

Diagnosereihenfolge:

1. Listener und Bindungsadresse prüfen
2. Lokalen Test über Loopback durchführen
3. Lokalen Test über die Server-IP durchführen
4. Test aus demselben Subnetz durchführen
5. Test aus dem betroffenen Clientnetz durchführen
6. Hostfirewall prüfen
7. Netzwerkpfad und Zwischenfirewalls prüfen
8. Paketmitschnitt auf Client und Server erwägen

Ein Portkonflikt entsteht, wenn ein Prozess eine Adresse-Port-Kombination verwenden möchte, die bereits unvereinbar belegt ist.

Typische Fehlermeldungen:

Address already in use
Only one usage of each socket address is normally permitted
Failed to bind
Bind failed
EADDRINUSE
Port is already allocated

Windows:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Select-Object LocalAddress, LocalPort, OwningProcess

[RO] Get-NetUDPEndpoint -LocalPort <PORT> |
    Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

[RO][PRIV] sudo ss -lntup "sport = :<PORT>"

macOS – TCP:

[RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN

macOS – UDP:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

Prüffragen bei einem Konflikt:

• Welcher Prozess besitzt den Port?
• Gehört der Prozess zum erwarteten Dienst?
• Verwendet er eine Wildcard- oder Einzeladressbindung?
• Wurde eine zweite Dienstinstanz gestartet?
• Wurde der Port nach einer Aktualisierung verändert?
• Läuft ein alter Prozess weiter?
• Wird der Port durch einen Container oder Proxy veröffentlicht?
• Unterstützt die Anwendung mehrere Prozesse mit gemeinsamem Listener?
• Ist die Mehrfachbindung durch Socketoptionen ausdrücklich vorgesehen?

Einen unbekannten Prozess nicht allein deshalb beenden, weil er den gewünschten Port verwendet. Zuerst müssen Prozess, Dienst und betriebliche Funktion eindeutig zugeordnet werden.

Einzelne Verbindungen in TIME_WAIT oder CLOSE_WAIT sind noch kein Fehler. Auffällig sind große oder kontinuierlich wachsende Bestände über einen längeren Zeitraum.

Windows – Verbindungen einer PID:

[RO] Get-NetTCPConnection -OwningProcess <PID> |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State

Linux – alle TCP-Verbindungen einer PID über lsof:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -iTCP

macOS – alle TCP-Verbindungen einer PID:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -iTCP

Damit können unter anderem folgende Fragen beantwortet werden:

• Nimmt der Dienst Clientverbindungen an?
• Baut der Dienst Verbindungen zu einer Datenbank auf?
• Verbindet er sich mit einem Verzeichnisdienst?
• Greift er auf einen Proxy oder eine externe API zu?
• Bleiben ungewöhnlich viele Verbindungen in CLOSE_WAIT?
• Verwendet der Prozess den erwarteten Zielport?
• Baut er Verbindungen zu einer unerwarteten Adresse auf?

Remoteadressen, interne Servernamen und Verbindungsziele können sensible Infrastrukturinformationen darstellen.

Bei containerisierten oder weitergeleiteten Anwendungen können mehrere Portebenen vorhanden sein.

Client
  → Hostadresse: veröffentlichter Port
  → Firewall oder Proxy
  → Containeradresse: interner Port
  → Anwendungsprozess

Beispiel:

Host:       192.0.2.20:8443
Container:  172.18.0.5:443
Anwendung:  0.0.0.0:443 im Container

Prüfungen müssen deshalb unterscheiden zwischen:

• Listener auf dem Host,
• veröffentlichtem Containerport,
• internem Containerport,
• Listener innerhalb des Containers,
• Reverse-Proxy-Listener,
• Backend-Verbindung des Proxys,
• Host- und Containerfirewall,
• Container-Netzwerk und DNS.

Typische Fehler:

• Port wurde nicht veröffentlicht,
• Hostport und Containerport wurden vertauscht,
• Anwendung lauscht im Container nur auf 127.0.0.1,
• Reverse Proxy verwendet falschen Backendport,
• zwei Container beanspruchen denselben Hostport,
• Container wurde neu erstellt und erhielt eine andere interne Adresse,
• Anwendung startet später als der vorgeschaltete Proxy,
• Dienst lauscht nur auf IPv6 oder nur auf IPv4.

Die allgemeine Socketprüfung bleibt gleich, muss aber in jedem relevanten Netzwerk-Namespace beziehungsweise auf jeder Weiterleitungsstufe wiederholt werden.

[ ] Erwartetes Protokoll bestimmt
[ ] Erwarteten Port bestimmt
[ ] Erwartete Bindungsadresse bestimmt
[ ] IPv4 und IPv6 berücksichtigt
[ ] Dienststatus geprüft
[ ] Prozess und aktuelle PID geprüft
[ ] TCP-Listener beziehungsweise UDP-Endpunkt gesucht
[ ] Port dem richtigen Prozess zugeordnet
[ ] Loopback-Bindung ausgeschlossen oder als vorgesehen bestätigt
[ ] Wildcard- oder Einzeladressbindung bewertet
[ ] Lokalen Test über Loopback durchgeführt
[ ] Lokalen Test über die Serveradresse durchgeführt
[ ] Test aus dem betroffenen Clientnetz durchgeführt
[ ] Aufgelöste Zieladresse kontrolliert
[ ] TCP-Verbindungszustände geprüft
[ ] Portkonflikt ausgeschlossen
[ ] Proxy-, Loadbalancer- oder Containerstufe berücksichtigt
[ ] UDP nur mit geeignetem Protokolltest bewertet
[ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt
[ ] Nächsten Diagnoseschritt dokumentiert