# 9. TCP, UDP, Ports, Firewall, NAT und Proxy # 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: ```text Transportprotokoll + lokale IP-Adresse + lokaler Port ``` Beispiel: ```text TCP 192.0.2.25:443 ``` Eine aufgebaute TCP-Verbindung wird durch beide Endpunkte unterschieden: ```text Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port ``` Beispiel: ```text 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 | | `:8080` | Innerhalb des betreffenden Container-Netzwerks gebunden | | `: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** ```text 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** ```text 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** ```text 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: ```text Dienst: Transportprotokoll: Erwartete lokale Adresse: Erwarteter lokaler Port: Erwarteter Netzwerk-Namespace: Erwartete Erreichbarkeit: Vorgelagerte Komponenten: ``` 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: ```powershell Get-NetTCPConnection ``` Nur TCP-Listener: ```powershell Get-NetTCPConnection ` -State Listen | Sort-Object LocalPort, LocalAddress ``` Bestimmten lokalen Port prüfen: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 443 ``` Ausgabe auf wesentliche Felder begrenzen: ```powershell 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`: ```powershell 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: ```powershell 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** ```powershell $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: ```powershell Get-NetUDPEndpoint | Sort-Object LocalPort, LocalAddress ``` Bestimmten UDP-Port prüfen: ```powershell Get-NetUDPEndpoint ` -LocalPort 53 ``` UDP-Endpunkt mit Prozessinformationen anzeigen: ```powershell 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** ```cmd netstat -ano ``` Nur TCP-Listener: ```cmd netstat -ano -p tcp ``` UDP-Endpunkte: ```cmd netstat -ano -p udp ``` Wiederholte Aktualisierung alle fünf Sekunden: ```cmd 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** ```powershell Get-NetIPConfiguration ``` Alle verwendbaren IP-Adressen: ```powershell 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** ```cmd netsh http show servicestate ``` Registrierte URL-Zuordnungen: ```cmd netsh http show urlacl ``` Registrierte TLS-Zertifikatbindungen: ```cmd netsh http show sslcert ``` Portproxy-Konfiguration: ```cmd 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: ```bash ss -lnt ``` TCP-Listener einschließlich Prozessinformationen: ```bash sudo ss -lntp ``` UDP-Endpunkte: ```bash sudo ss -lnup ``` TCP- und UDP-Endpunkte gemeinsam: ```bash sudo ss -lntup ``` Bestimmten TCP-Port prüfen: ```bash sudo ss -lntp 'sport = :443' ``` Bestimmten UDP-Port prüfen: ```bash sudo ss -lnup 'sport = :53' ``` Alle TCP-Verbindungen und Zustände: ```bash ss -tan ``` Zusammenfassung: ```bash 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: ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` Bestimmten TCP-Port prüfen: ```bash sudo lsof -nP -iTCP:443 -sTCP:LISTEN ``` Bestimmten UDP-Port prüfen: ```bash 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: ```bash ps -fp ``` Bei einem systemd-Dienst: ```bash systemctl status ``` Prozessbaum: ```bash pstree -p ``` Falls `pstree` nicht installiert ist: ```bash ps -ef --forest ``` --- **Linux: Netzwerkadressen und Namespace prüfen** **LESEND** ```bash ip address show ``` Kompakte Ansicht: ```bash ip -brief address ``` Netzwerk-Namespaces anzeigen: ```bash ip netns list ``` Socketansicht eines bekannten Prozess-Namespace: ```bash sudo nsenter \ -t \ -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: ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` Bestimmten TCP-Port prüfen: ```bash sudo lsof -nP -iTCP:443 -sTCP:LISTEN ``` UDP-Endpunkte: ```bash sudo lsof -nP -iUDP ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof -nP -iUDP:53 ``` TCP-Socketzustände mit `netstat`: ```bash netstat -anv -p tcp ``` UDP-Sockets: ```bash netstat -anv -p udp ``` Lokale Netzwerkschnittstellen: ```bash ifconfig ``` Routing- und Schnittstelleninformationen: ```bash 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: ```bash sudo ss -lxnp ``` Linux und macOS: ```bash 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: ```text 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: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 8080 ``` ```powershell Get-NetUDPEndpoint ` -LocalPort 8080 ``` Linux: ```bash sudo ss -lntup 'sport = :8080' ``` macOS: ```bash 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** ```powershell Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 8080 ` -InformationLevel Detailed ``` Test gegen die konkrete Schnittstellenadresse: ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 8080 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz 127.0.0.1 8080 ``` ```bash 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: ```powershell Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 8080 ``` ```powershell Test-NetConnection ` -ComputerName "::1" ` -Port 8080 ``` Linux und macOS: ```bash nc -4 -vz 127.0.0.1 8080 ``` ```bash 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** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz app.example.test 443 ``` Getrennte Prüfung einer bekannten IP-Adresse: ```bash 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: ```bash curl -v http://127.0.0.1:8080/ ``` HTTPS mit korrektem Hostnamen und festgelegter Zieladresse: ```bash curl -v \ --resolve app.example.test:443:192.0.2.25 \ https://app.example.test/ ``` TLS mit Server Name Indication: ```bash openssl s_client \ -connect 192.0.2.25:443 \ -servername app.example.test ``` DNS über UDP: ```bash dig @192.0.2.53 example.test A ``` DNS über TCP: ```bash 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: ```bash 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: ```text 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** ```powershell Get-NetFirewallRule ` -Enabled True ` -Direction Inbound | Select-Object ` DisplayName, Action, Profile, Direction ``` Portfilter zu einer bekannten Regel: ```powershell Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallPortFilter ``` Adressfilter: ```powershell Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallAddressFilter ``` Anwendungsfilter: ```powershell Get-NetFirewallRule ` -DisplayName "" | 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: ```text 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: ```text Anwendungsport im Container veröffentlichter Port auf dem Host Port des zugreifenden Clients ``` Beispiel: ```text 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: ```bash docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' ``` Portzuordnungen eines Containers: ```bash docker port ``` Ausführliche Portkonfiguration: ```bash docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' ``` Netzwerkmodus: ```bash docker inspect \ \ --format '{{.HostConfig.NetworkMode}}' ``` Containeradresse: ```bash docker inspect \ \ --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ``` Listener innerhalb des Containers, falls `ss` vorhanden ist: ```bash docker exec \ \ ss -lntup ``` Alternativ, falls `lsof` vorhanden ist: ```bash docker exec \ \ 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: ```text 127.0.0.1:8080:80 ``` Bedeutung: ```text Host 127.0.0.1:8080 → Containerport 80 ``` Dieser Hostport soll nur lokal erreichbar sein. ```text 8080:80 ``` Bedeutung: ```text 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: ```yaml 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: ```bash kubectl get service \ --all-namespaces ``` Bestimmten Service beschreiben: ```bash kubectl describe service \ \ -n ``` Service als YAML anzeigen: ```bash kubectl get service \ \ -n \ -o yaml ``` EndpointSlices anzeigen: ```bash kubectl get endpointslice \ -n \ -l kubernetes.io/service-name= \ -o wide ``` Pods und Pod-Adressen: ```bash kubectl get pods \ -n \ -o wide ``` Pod beschreiben: ```bash kubectl describe pod \ \ -n ``` Listener im Pod, falls das Werkzeug vorhanden ist: ```bash kubectl exec \ -n \ \ -- ss -lntup ``` Bei mehreren Containern im Pod: ```bash kubectl exec \ -n \ \ -c \ -- 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: ```text 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: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 443 | Select-Object LocalAddress, LocalPort, OwningProcess ``` Linux: ```bash sudo ss -lntp 'sport = :443' ``` Gezielter IPv4-Test: ```bash curl -4 -v https://app.example.test/ ``` Gezielter IPv6-Test: ```bash 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: ```text 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: ```text wirksamer Port: wirksame Bindungsadresse: Quelle: geladene Version: Zeitpunkt der letzten Änderung: Neustart erforderlich: ``` 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** ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 100 ``` Auf eine Gegenstelle begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 198.51.100.40 and tcp port 443' \ -c 100 ``` UDP-Beispiel: ```bash sudo tcpdump \ -ni any \ 'udp port 53' \ -c 100 ``` macOS mit konkreter Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'tcp port 443' \ -c 100 ``` Lokalen macOS-Verkehr auf Loopback: ```bash 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: ```text 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** ```text Störung: Zeitpunkt: Betroffener Dienst: Betroffener Host: Netzwerk-Namespace: Transportprotokoll: Erwartete Bindung: Tatsächliche Bindung: Prozess: Dienstzuordnung: Konfigurationsquelle: Lokaler Test: Entfernter Test: Anwendungsprotokolltest: Firewall-, NAT- oder Proxyweg: IPv4-Befund: IPv6-Befund: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **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 ` | | Windows-UDP-Endpunkte | `Get-NetUDPEndpoint` | | Windows-UDP-Port prüfen | `Get-NetUDPEndpoint -LocalPort ` | | Windows-Prozess prüfen | `Get-Process -Id ` | | Windows-Dienst zu PID | `Get-CimInstance Win32_Service -Filter "ProcessId = "` | | Windows-netstat | `netstat -ano` | | Windows-IP-Adressen | `Get-NetIPAddress` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -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 = :'` | | Linux-Socketübersicht | `ss -s` | | Linux-Prozess zu TCP-Port | `sudo lsof -nP -iTCP: -sTCP:LISTEN` | | Linux-Prozess zu UDP-Port | `sudo lsof -nP -iUDP:` | | 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 ` | | HTTP-Test | `curl -v http://:/` | | HTTPS-Test mit Zieladresse | `curl -v --resolve :: https:///` | | TLS-Test mit SNI | `openssl s_client -connect : -servername ` | | Docker-Portübersicht | `docker ps --format 'table {{.Names}}\t{{.Ports}}'` | | Docker-Portzuordnung | `docker port ` | | Docker-Netzwerkmodus | `docker inspect --format '{{.HostConfig.NetworkMode}}'` | | Listener im Container | `docker exec ss -lntup` | | Kubernetes-Services | `kubectl get service --all-namespaces` | | Kubernetes-Service prüfen | `kubectl describe service -n ` | | Kubernetes-EndpointSlices | `kubectl get endpointslice -n -l kubernetes.io/service-name=` | | Listener im Pod | `kubectl exec -n -- ss -lntup` | | begrenzte Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 100` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text 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** - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – Get-NetIPAddress](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress) - [Microsoft Learn – Get-NetFirewallRule](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallrule) - [Microsoft Learn – netsh http](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-http) - [Microsoft Learn – netsh interface portproxy](https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-interface-portproxy) **Offizielle Linux- und Unix-Dokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – lsof(8)](https://man7.org/linux/man-pages/man8/lsof.8.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux man-pages – ip-netns(8)](https://man7.org/linux/man-pages/man8/ip-netns.8.html) - [Linux man-pages – socket(7)](https://man7.org/linux/man-pages/man7/socket.7.html) - [Linux man-pages – tcp(7)](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – udp(7)](https://man7.org/linux/man-pages/man7/udp.7.html) **Offizielle Docker-Dokumentation** - [Docker Docs – Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) - [Docker Docs – Networking overview](https://docs.docker.com/engine/network/) - [Docker Docs – docker container port](https://docs.docker.com/reference/cli/docker/container/port/) - [Docker Docs – Bridge network driver](https://docs.docker.com/engine/network/drivers/bridge/) - [Docker Docs – Host network driver](https://docs.docker.com/engine/network/drivers/host/) **Offizielle Kubernetes-Dokumentation** - [Kubernetes – Services, Load Balancing, and Networking](https://kubernetes.io/docs/concepts/services-networking/service/) - [Kubernetes – EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) - [Kubernetes API – Service](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/) - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) **Standards und Register** - [IANA – Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) - [RFC 6335 – Service Name and Transport Protocol Port Number Registry](https://datatracker.ietf.org/doc/html/rfc6335) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 3493 – Basic Socket Interface Extensions for IPv6](https://datatracker.ietf.org/doc/html/rfc3493) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.2 TCP-Handshake, Timeouts und TCP Reset **Ziel dieser Seite** Diese Seite beschreibt den vollständigen Lebenszyklus einer TCP-Verbindung: - Verbindungsaufbau zwischen Client und Server; - Aushandlung wichtiger TCP-Optionen; - zuverlässige und geordnete Datenübertragung; - Bestätigungen, Sequenznummern und Wiederholungen; - kontrollierter Verbindungsabbau; - Timeouts auf unterschiedlichen Ebenen; - abrupter Verbindungsabbruch durch TCP Reset; - systematische Diagnose mit Windows, Linux, macOS und Paketaufzeichnungen. Nach der Bearbeitung muss unterschieden werden können: - ob bereits der TCP-Verbindungsaufbau scheitert; - welche Seite den Verbindungsaufbau nicht fortsetzt; - ob ein Port aktiv abgelehnt wird; - ob Pakete verworfen oder verzögert werden; - ob TCP erfolgreich aufgebaut wurde und erst das Anwendungsprotokoll scheitert; - ob eine Verbindung kontrolliert mit `FIN` oder abrupt mit `RST` beendet wurde; - ob ein Timeout aus TCP, der Anwendung, einem Proxy oder einer Firewall stammt; - welche Gegenstelle oder Zwischenkomponente wahrscheinlich einen Reset erzeugt hat; - ob Wiederholungen auf Paketverlust oder lediglich auf eine unvollständige Aufzeichnung zurückzuführen sind. Ein TCP-Fehler darf nicht allein anhand einer Anwendungsmeldung wie „Timeout“ oder „Connection reset“ eingeordnet werden. Er muss mit Socketzuständen, Zeitpunkten, Protokollen und bei Bedarf einer begrenzten Paketaufzeichnung korreliert werden. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen. | | **ÄNDERND** | Verändert Konfiguration oder Laufzeitzustand. | | **AUSFALLRISIKO** | Kann Verbindungen, Prozesse oder Dienste beeinträchtigen. | Paketaufzeichnungen können enthalten: - interne und externe IP-Adressen; - Portnummern; - Hostnamen; - Anwendungsdaten; - Authentifizierungsinformationen; - Cookies oder Tokens; - unverschlüsselte Nutzdaten; - Zertifikatsinformationen; - Kommunikationsbeziehungen. Aufzeichnungen müssen technisch und zeitlich begrenzt, geschützt gespeichert und nach Abschluss der Diagnose kontrolliert entfernt werden. --- **Grundlegende Eigenschaften von TCP** TCP stellt Anwendungen einen zuverlässigen, geordneten und bidirektionalen Bytestrom zur Verfügung. TCP bietet unter anderem: - verbindungsorientierte Kommunikation; - Sequenznummern; - Bestätigungen; - Prüfsummen; - Wiederholungen verlorener Segmente; - Flusskontrolle; - Überlastkontrolle; - geordnete Übergabe der Daten; - kontrollierten Verbindungsabbau; - Erkennung bestimmter ungültiger oder nicht mehr existierender Verbindungen. TCP stellt keine Anwendungsnachrichten bereit. Eine Anwendung übergibt einen Bytestrom. Die Aufteilung in einzelne TCP-Segmente kann sich während der Übertragung ändern. Folgende Annahmen sind deshalb falsch: ```text Eine TCP-Verbindung entspricht einer Anfrage. Ein TCP-Segment entspricht einer Anwendungsnachricht. Ein ACK bedeutet, dass die Anwendung die Daten verarbeitet hat. Ein erfolgreicher Handshake bedeutet, dass HTTP, TLS oder die Anwendung funktioniert. ``` Ein TCP-ACK bestätigt grundsätzlich, dass die TCP-Implementierung der Gegenstelle die entsprechenden Bytes angenommen hat. Es beweist nicht, dass: - die Anwendung die Bytes gelesen hat; - die Anwendung die Anfrage verstanden hat; - Daten auf einen Datenträger geschrieben wurden; - eine Transaktion erfolgreich abgeschlossen wurde; - eine Anwendungsantwort erzeugt wurde. --- **TCP-Verbindung eindeutig bestimmen** Eine TCP-Verbindung wird durch ihre Endpunkte unterschieden: ```text Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port ``` Beispiel: ```text Client: 192.0.2.100:53124 Server: 192.0.2.25:443 ``` Die Verbindung kann kompakt dargestellt werden als: ```text 192.0.2.100:53124 → 192.0.2.25:443 ``` Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar: ```text lokal: 192.0.2.25:443 remote: 192.0.2.100:53124 ``` Bei NAT, Load Balancern oder Proxys können sich Adressen und Ports entlang des Pfads verändern. Paketaufzeichnungen auf verschiedenen Seiten müssen deshalb anhand von: - Zeitpunkt; - Richtung; - TCP-Flags; - Sequenznummern; - Nutzdaten; - übersetzten Adressen und Ports korreliert werden. --- **Wichtige TCP-Flags** | Flag | Bedeutung | |---|---| | `SYN` | Synchronisiert Sequenznummern und beginnt normalerweise den Verbindungsaufbau. | | `ACK` | Das Bestätigungsfeld ist gültig. | | `FIN` | Der Sender hat keine weiteren Daten mehr zu senden. | | `RST` | Verbindung zurücksetzen oder ungültige Verbindung ablehnen. | | `PSH` | Kennzeichnet Daten für eine zeitnahe Weitergabe innerhalb des TCP-Datenstroms. | | `URG` | Das Urgent-Pointer-Feld ist relevant. | | `ECE` | Wird im Zusammenhang mit Explicit Congestion Notification verwendet. | | `CWR` | Signalisiert eine reduzierte Congestion Window nach ECN. | `PSH` definiert keine Anwendungsnachricht und garantiert keine bestimmte Paketgröße oder sofortige Verarbeitung durch die Anwendung. --- **Verbindungsaufbau zwischen Client und Server** Der reguläre TCP-Verbindungsaufbau wird als Three-Way Handshake bezeichnet. ```text Client Server CLOSED LISTEN | | | SYN, Seq=x | |------------------------------------------>| | | | SYN, ACK, Seq=y, Ack=x+1 | |<------------------------------------------| | | | ACK, Ack=y+1 | |------------------------------------------>| | | ESTABLISHED ESTABLISHED ``` Die drei logischen Schritte sind: 1. Der Client sendet ein Segment mit `SYN`. 2. Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit `SYN, ACK`. 3. Der Client bestätigt das Server-SYN mit `ACK`. Das dritte Segment kann abhängig von Anwendung und TCP-Erweiterungen bereits Daten enthalten. Für die grundlegende Diagnose wird es dennoch als dritter Handshake-Schritt betrachtet. --- **Sequenznummern beim Handshake** Beispiel: ```text Client → Server: SYN Seq = 1000 Server → Client: SYN, ACK Seq = 7000 Ack = 1001 Client → Server: ACK Seq = 1001 Ack = 7001 ``` Ein SYN verbraucht eine Sequenznummer. Deshalb bestätigt der Server: ```text 1000 + 1 = 1001 ``` Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt: ```text 7000 + 1 = 7001 ``` Die tatsächlich verwendeten Initial Sequence Numbers werden von den TCP-Implementierungen bestimmt und sind nicht als einfache fortlaufende Werte vorhersehbar. --- **TCP-Zustände während des Verbindungsaufbaus** | Zustand | Bedeutung | |---|---| | `CLOSED` | Es besteht keine TCP-Verbindung. | | `LISTEN` | Der Server wartet auf neue Verbindungsanfragen. | | `SYN-SENT` | Ein SYN wurde gesendet; eine passende Antwort steht aus. | | `SYN-RECEIVED` | SYN wurde empfangen und mit SYN/ACK beantwortet; abschließendes ACK steht aus. | | `ESTABLISHED` | Der Handshake ist abgeschlossen. | Eine große Zahl von Verbindungen in `SYN-SENT` kann bedeuten: - Zieladresse nicht erreichbar; - Zielport wird gefiltert; - Rückweg ist fehlerhaft; - Server antwortet nicht; - SYN/ACK wird verworfen; - falsche IPv4- oder IPv6-Adresse; - Überlastung oder Ressourcenproblem; - ausgehende Verbindung wird lokal blockiert. Viele Einträge in `SYN-RECEIVED` können bedeuten: - abschließende ACKs erreichen den Server nicht; - Rückweg vom Server zum Client funktioniert, Hinweg des ACKs jedoch nicht; - Clients brechen den Aufbau ab; - SYN-Flood oder ungewöhnlich viele unvollständige Verbindungsversuche; - vorgeschaltete Systeme oder Health Checks öffnen Verbindungen nicht vollständig; - Serverwarteschlangen oder Ressourcen sind erschöpft. Ein einzelner kurz sichtbarer Zustand `SYN-SENT` oder `SYN-RECEIVED` ist normal. Entscheidend sind Häufigkeit, Dauer und Vergleich mit einer Baseline. --- **TCP-Optionen während des Handshakes** Wichtige Optionen werden typischerweise in SYN-Segmenten angeboten oder ausgehandelt. | Option | Zweck | |---|---| | `MSS` | Maximale TCP-Nutzdatenmenge, die die jeweilige Seite in einem Segment empfangen möchte. | | `Window Scale` | Erweitert die darstellbare TCP-Empfangsfenstergröße. | | `SACK Permitted` | Erlaubt Selective Acknowledgment. | | `Timestamps` | Unterstützt unter anderem RTT-Messungen und Schutzmechanismen gegen alte Segmente. | | `ECN` | Ermöglicht Überlastsignalisierung ohne zwingenden Paketverlust, sofern der Pfad sie unterstützt. | Bei der Diagnose müssen die SYN- und SYN/ACK-Optionen verglichen werden. Zu prüfen sind: - bietet der Client eine MSS an? - bietet der Server eine abweichende MSS an? - wird Window Scaling angeboten? - wird SACK unterstützt? - werden TCP-Timestamps verwendet? - verschwinden Optionen zwischen Client und Server? - verändert eine Firewall oder Optimierungskomponente SYN-Pakete? - unterscheiden sich erfolgreiche und fehlerhafte Verbindungen? Ein Handshake kann trotz unterschiedlicher angebotener Optionen erfolgreich sein. Die Optionen können jedoch das spätere Übertragungsverhalten beeinflussen. --- **Erfolgreicher TCP-Handshake** Eine normale Paketfolge ist: ```text Client → Server SYN Server → Client SYN, ACK Client → Server ACK ``` Dieser Befund beweist: - der Client konnte ein SYN senden; - das SYN erreichte einen antwortenden TCP-Endpunkt; - eine SYN/ACK-Antwort erreichte den Client; - das abschließende ACK konnte gesendet werden; - die TCP-Verbindung wurde mindestens kurzfristig aufgebaut. Dieser Befund beweist nicht: - dass TLS funktioniert; - dass das richtige Zertifikat geliefert wird; - dass HTTP antwortet; - dass der virtuelle Host stimmt; - dass die Anwendung gesund ist; - dass Authentifizierung funktioniert; - dass eine Datenbankanfrage verarbeitet wird; - dass die Verbindung dauerhaft stabil bleibt. --- **SYN ohne Antwort** Typischer Paketbefund: ```text Client → Server SYN Client → Server SYN erneut Client → Server SYN erneut ... Timeout ``` Mögliche Ursachen: - Zielhost ist nicht erreichbar; - Routing ist fehlerhaft; - lokale Firewall verwirft das SYN; - Netzwerkfirewall verwirft das SYN; - Zielport wird still verworfen; - SYN erreicht den Server nicht; - Server-SYN/ACK wird auf dem Rückweg verworfen; - falsche Zieladresse; - falsche Adressfamilie; - NAT-Zuordnung fehlt; - Load Balancer besitzt kein erreichbares Frontend; - Server oder Zwischenkomponente ist überlastet; - Paketaufzeichnung wurde am falschen Punkt durchgeführt. Aus einer alleinigen Clientaufzeichnung kann nicht sicher geschlossen werden, ob das SYN den Server erreicht hat. Dafür wird eine korrelierte Aufzeichnung am Server oder an einem geeigneten Zwischenpunkt benötigt. --- **SYN wird mit Reset beantwortet** Typischer Paketbefund: ```text Client → Server SYN Server → Client RST, ACK ``` Typische Einordnung: - Zielhost ist erreichbar; - auf dem angesprochenen Endpunkt existiert häufig kein passender Listener; - das Betriebssystem oder eine Zwischenkomponente lehnt die Verbindung aktiv ab; - eine Firewall kann mit einem Reset ablehnen; - ein Load Balancer besitzt möglicherweise kein verwendbares Backend; - Portweiterleitung zeigt auf einen geschlossenen Zielport. Eine Anwendung meldet in diesem Fall häufig: ```text Connection refused Verbindung abgelehnt No connection could be made because the target machine actively refused it ``` Die Meldung beweist nicht, dass der eigentliche Zielserver selbst den Reset erzeugt hat. Firewalls, Proxys und Load Balancer können ebenfalls TCP-Reset-Segmente erzeugen. --- **Server sendet SYN/ACK, erhält aber kein ACK** Typischer Befund am Server: ```text Client → Server SYN Server → Client SYN, ACK Server → Client SYN, ACK erneut Server → Client SYN, ACK erneut ... ``` Mögliche Ursachen: - SYN/ACK erreicht den Client nicht; - Clientfirewall verwirft die Antwort; - asymmetrischer Rückweg; - NAT-Zustand ist fehlerhaft; - Client sendet das ACK über einen anderen Pfad; - Quelladressprüfung verwirft das Paket; - Clientprozess wurde beendet; - fehlerhafte oder unvollständige Paketaufzeichnung; - Zwischenkomponente verwirft das abschließende ACK. Zur Eingrenzung werden Aufzeichnungen auf Client- und Serverseite benötigt. --- **Handshake funktioniert nur teilweise** | Paketbefund | Einordnung | |---|---| | kein SYN sichtbar | Anwendung startet keinen TCP-Aufbau oder Aufzeichnungspunkt ist falsch | | SYN sichtbar, keine Antwort | Filterung, Routing, Verlust oder fehlender Rückweg | | SYN gefolgt von RST | aktive Ablehnung | | SYN/ACK wird wiederholt | abschließendes ACK fehlt | | Handshake vollständig, danach keine Daten | Anwendung wartet, Protokollmissverständnis oder falsche Rolle | | Handshake vollständig, danach RST | Anwendung, Betriebssystem oder Zwischenkomponente bricht ab | | Handshake vollständig, danach FIN | kontrollierte Beendigung | | Handshake vollständig, TLS beginnt und stoppt | TLS- oder Anwendungsproblem, nicht TCP-Verbindungsaufbau | --- **Die kontrollierte Datenübertragung bei TCP** Nach dem Handshake können beide Seiten Daten senden. TCP arbeitet als bidirektionaler Bytestrom: ```text Client ⇄ Server ``` Jede Richtung besitzt eigene: - Sequenznummern; - Bestätigungen; - Empfangsfenster; - Sendepuffer; - Empfangspuffer; - Wiederholungszustände. Ein Client kann gleichzeitig Daten senden und Daten des Servers empfangen. --- **Sequenznummern bei der Datenübertragung** Beispiel: ```text Client sendet: Seq = 1001 TCP-Nutzdatenlänge = 500 Bytes ``` Der Server bestätigt als nächste erwartete Sequenznummer: ```text Ack = 1501 ``` Berechnung: ```text 1001 + 500 = 1501 ``` Die Bestätigungsnummer bezeichnet das nächste Byte, das die empfangende Seite erwartet. Wenn der Server `Ack = 1501` sendet, bestätigt er kumulativ alle Bytes bis einschließlich Sequenznummer `1500`. --- **Kumulative Bestätigungen** TCP-ACKs sind grundsätzlich kumulativ. Beispiel: ```text Segment 1: Seq 1001, Länge 500 Segment 2: Seq 1501, Länge 500 Segment 3: Seq 2001, Länge 500 ``` Wenn der Empfänger anschließend sendet: ```text Ack = 2501 ``` sind damit alle zusammenhängend empfangenen Bytes bis `2500` bestätigt. Ein fehlendes Segment kann dazu führen, dass der Empfänger weiterhin dieselbe nächste erwartete Sequenznummer bestätigt. --- **Selective Acknowledgment** Wenn SACK während des Handshakes erlaubt wurde, kann der Empfänger zusätzlich mitteilen, welche späteren Datenblöcke bereits angekommen sind. Beispiel: ```text Segment 1 angekommen Segment 2 fehlt Segment 3 angekommen Segment 4 angekommen ``` Der kumulative ACK verweist weiterhin auf Segment 2. SACK-Informationen können jedoch anzeigen, dass Segment 3 und Segment 4 bereits vorhanden sind. Dadurch muss der Sender nicht zwingend alle späteren Daten erneut übertragen. --- **Verzögerte ACKs** TCP-Implementierungen können Bestätigungen kurz verzögern, um: - mehrere empfangene Segmente gemeinsam zu bestätigen; - ACKs mit eigenen ausgehenden Daten zu kombinieren; - unnötige kleine Pakete zu reduzieren. Ein nicht sofort sichtbares ACK ist deshalb nicht automatisch ein Fehler. Entscheidend sind: - tatsächliche Verzögerungsdauer; - Wiederholungen; - Anwendungsreaktion; - Vergleich mit erfolgreichen Verbindungen; - Betriebssystem- und Protokollverhalten. --- **Flusskontrolle** Der Empfänger teilt über das TCP-Empfangsfenster mit, wie viele weitere Bytes er aufnehmen kann. Vereinfacht: ```text Sender darf nur so viele unbestätigte Daten senden, wie das angekündigte Empfangsfenster zulässt. ``` Ein kleiner werdendes Empfangsfenster kann darauf hindeuten, dass die empfangende Anwendung Daten nicht schnell genug aus dem Socket liest. Ein Empfangsfenster von null bedeutet, dass momentan kein weiterer Empfangspuffer verfügbar ist. Die ausführliche Diagnose von Zero Window und Übertragungsstillständen erfolgt auf der dafür vorgesehenen Seite zu Retransmissions, Zero Window und MTU-Problemen. --- **Überlastkontrolle** Zusätzlich zur Flusskontrolle begrenzt TCP die Sendemenge anhand des vermuteten Netzzustands. Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | `cwnd` | Congestion Window des Senders | | `rwnd` | vom Empfänger angekündigtes Receive Window | | `RTT` | gemessene Round Trip Time | | `RTO` | berechneter Retransmission Timeout | | Slow Start | vorsichtige Erhöhung der Sendemenge zu Beginn oder nach bestimmten Verlusten | | Congestion Avoidance | kontrollierte Anpassung der Sendemenge | | Fast Retransmit | schnelle Wiederholung bei Verlusthinweisen | | Fast Recovery | Wiederherstellung nach bestimmten Verlustereignissen | Die tatsächlich sendbare unbestätigte Datenmenge wird unter anderem durch Empfangsfenster und Congestion Window begrenzt. --- **Retransmission Timeout** Ein Sender startet für noch nicht bestätigte Daten einen Wiederholungstimer. Der RTO wird aus gemessenen Laufzeiten und deren Schwankungen berechnet. Er ist kein fester universeller Wert. Wenn eine Bestätigung nicht rechtzeitig eintrifft: - läuft der Wiederholungstimer ab; - das betreffende Segment kann erneut gesendet werden; - der Wiederholungstimer wird typischerweise vergrößert; - die Sendegeschwindigkeit kann reduziert werden; - nach weiteren erfolglosen Versuchen kann die Verbindung aufgegeben werden. Die genaue Anzahl der Versuche und die Gesamtdauer sind abhängig von: - Betriebssystem; - TCP-Implementierung; - Verbindungsphase; - Anwendung; - Socketoptionen; - Systemkonfiguration; - Zwischenkomponenten. Es darf kein universeller TCP-Timeoutwert angenommen werden. --- **Fast Retransmit** Beim klassischen Fast-Retransmit-Verfahren können mehrere Duplicate ACKs den Sender darauf hinweisen, dass ein früheres Segment fehlt, während spätere Segmente angekommen sind. Der Sender kann das fehlende Segment wiederholen, bevor der normale RTO abläuft. Moderne TCP-Implementierungen können zusätzlich oder alternativ weitere Verlustalgorithmen und SACK-Informationen verwenden. Deshalb darf nicht jeder Fast-Retransmit ausschließlich anhand einer festen Zahl von Duplicate ACKs erklärt werden. --- **Duplicate ACKs richtig einordnen** Duplicate ACKs können entstehen durch: - tatsächlich verlorenes Segment; - Paketumordnung; - duplizierte Pakete; - verzögerte Übertragung; - unvollständige Paketaufzeichnung; - asymmetrische Aufzeichnung; - unterschiedliche Netzwerkpfade; - Captureverlust am Analysesystem. Ein Duplicate ACK ist ein Hinweis und kein alleiniger Beweis für Paketverlust. --- **TCP-Retransmissions richtig einordnen** Eine als Retransmission markierte Übertragung kann bedeuten: - ursprüngliches Segment ging im Netzwerk verloren; - Bestätigung ging verloren; - ursprüngliches Segment wurde am Aufzeichnungspunkt nicht erfasst; - Pakete trafen in anderer Reihenfolge ein; - Aufzeichnungssoftware verlor Pakete; - Daten wurden durch Offloading anders dargestellt; - Wireshark ordnete den Datenstrom heuristisch ein. Wireshark-Analysefelder wie `tcp.analysis.retransmission` sind Analyseergebnisse und keine im TCP-Paket übertragenen Flags. --- **TCP Checksum Offloading berücksichtigen** Bei einer Aufzeichnung auf dem sendenden Host kann eine TCP-Prüfsumme als fehlerhaft erscheinen, obwohl das Netzwerkpaket später korrekt übertragen wird. Mögliche Ursache: - die Netzwerkkarte berechnet die Prüfsumme erst nach dem Aufzeichnungspunkt; - TCP Segmentation Offload zerlegt große Datenblöcke erst in der Netzwerkkarte; - Generic Receive Offload oder Large Receive Offload fasst Daten zusammen. Deshalb gilt: ```text Eine lokal als fehlerhaft angezeigte TCP-Prüfsumme beweist ohne weitere Prüfung keinen Netzwerkfehler. ``` Zu vergleichen sind: - Aufzeichnung am sendenden Host; - Aufzeichnung auf einem externen Messpunkt; - Offloading-Anzeige des Analysewerkzeugs; - erfolgreiche und fehlerhafte Verbindungen. --- **TCP besitzt keine Anwendungs-Lebendigkeitsprüfung** Eine bestehende TCP-Verbindung kann im Zustand `ESTABLISHED` verbleiben, obwohl: - die Gegenstelle ausgefallen ist; - ein Kabel getrennt wurde; - eine Firewall den Sitzungszustand gelöscht hat; - der Netzwerkpfad nicht mehr funktioniert; - die Anwendung der Gegenstelle nicht mehr reagiert. Solange keine Daten übertragen oder Prüfmechanismen ausgelöst werden, erkennt TCP einen solchen Zustand nicht zwingend sofort. Mögliche zusätzliche Mechanismen sind: - TCP Keepalive; - anwendungsspezifische Heartbeats; - Request-Timeouts; - Health Checks; - Sitzungszeitüberschreitungen; - erneuter Verbindungsaufbau. Ein TCP-Keepalive beweist nur eine Reaktion des TCP-Endpunkts. Es beweist nicht automatisch, dass die Anwendung fachlich gesund ist. --- **Timeout ist nicht gleich Timeout** Die Meldung „Timeout“ kann aus verschiedenen Ebenen stammen. | Timeoutart | Phase | Typischer Befund | |---|---|---| | DNS-Timeout | vor TCP | kein SYN zum eigentlichen Server | | TCP-Connect-Timeout | Handshake | SYN bleibt unbeantwortet | | TCP-Retransmission-Timeout | Datenübertragung | unbestätigte Segmente werden wiederholt | | TLS-Handshake-Timeout | nach TCP-Aufbau | TCP steht, TLS wird nicht abgeschlossen | | Application-Read-Timeout | nach Anfrage | TCP steht, erwartete Antwort fehlt | | Application-Write-Timeout | Datenversand | Anwendung kann nicht rechtzeitig schreiben | | Proxy-Connect-Timeout | Proxy zum Backend | Client erreicht Proxy, Proxy nicht das Backend | | Proxy-Read-Timeout | Proxy wartet auf Backend | Backendverbindung besteht, Antwort dauert zu lange | | Firewall-Idle-Timeout | längere Inaktivität | Sitzungszustand der Firewall wird entfernt | | NAT-Idle-Timeout | längere Inaktivität | NAT-Zuordnung läuft ab | | Load-Balancer-Idle-Timeout | längere Inaktivität | Load Balancer verwirft inaktive Sitzung | | TCP-Keepalive-Timeout | Prüfmechanismus | Gegenstelle reagiert nicht auf Keepalive-Probes | | Anwendungsdeadline | beliebige Phase | Anwendung bricht nach eigener Gesamtfrist ab | Vor einer Änderung muss festgestellt werden, welcher Zeitgeber tatsächlich abgelaufen ist. --- **Connect-Timeout erkennen** Typischer Ablauf: ```text Anwendung startet Verbindung Client sendet SYN keine verwertbare Antwort SYN wird wiederholt Anwendung meldet Timeout ``` Zu prüfen sind: - Zeitpunkt des ersten SYN; - Anzahl und Abstand der SYN-Wiederholungen; - Zeitpunkt der Anwendungsmeldung; - kommt ein SYN/ACK oder RST an? - erreicht das SYN den Server? - erreicht die Antwort den Client? - beendet die Anwendung den Versuch vor dem TCP-Stack? - versucht die Anwendung danach eine weitere Zieladresse? Bei mehreren DNS-Adressen kann die Anwendung nacheinander oder parallel unterschiedliche Ziele versuchen. Die sichtbare Gesamtdauer muss daher nicht dem Timeout eines einzelnen TCP-Versuchs entsprechen. --- **Anwendungs-Timeout nach erfolgreichem Handshake** Typischer Ablauf: ```text SYN SYN, ACK ACK Anwendungsanfrage keine oder verspätete Anwendungsantwort Anwendung meldet Timeout ``` TCP ist in diesem Fall grundsätzlich aufgebaut. Mögliche Ursachen: - Serveranwendung verarbeitet die Anfrage zu langsam; - Backenddienst reagiert nicht; - Datenbankabfrage blockiert; - Thread- oder Workerpool ist erschöpft; - Empfangsfenster wird klein oder null; - Proxy wartet auf ein Backend; - falsches Anwendungsprotokoll; - Deadlock oder Ressourcensperre; - Antwortpakete gehen verloren; - Anwendung verwendet eine zu kurze Frist. Die Diagnose darf nicht bei einem erfolgreichen Porttest enden. --- **Idle-Timeout erkennen** Typischer Ablauf: ```text TCP-Verbindung wird erfolgreich aufgebaut Datenübertragung funktioniert Verbindung bleibt längere Zeit inaktiv erste neue Übertragung schlägt fehl eine neue TCP-Verbindung funktioniert wieder ``` Mögliche Ursachen: - Firewall hat Sessiontabelleneintrag entfernt; - NAT-Zuordnung ist abgelaufen; - Load Balancer hat die Verbindung geschlossen; - Proxy hat seine Idle-Frist erreicht; - Serveranwendung hat die Sitzung beendet; - Client verwendet eine veraltete Verbindung aus einem Connection Pool; - TCP Keepalive ist nicht aktiv oder zu spät eingestellt. Benötigter Nachweis: - genaue Dauer der Inaktivität; - Zeitpunkt der letzten erfolgreichen Datenübertragung; - Paketfolge beim ersten erneuten Sendeversuch; - Verhalten bei einer frisch aufgebauten Verbindung; - konfigurierte Idle-Timeouts aller Zwischenkomponenten; - Anwendungspool- und Keepalive-Konfiguration. --- **TCP Reset** Ein TCP-Reset wird durch das Flag `RST` signalisiert. Ein Reset bedeutet grundsätzlich: ```text Diese TCP-Verbindung soll sofort zurückgesetzt werden oder der angesprochene TCP-Zustand ist nicht gültig. ``` Im Unterschied zu einem geordneten Abbau mit `FIN` ist ein Reset ein abrupter Abbruch. Mögliche Anwendungsmeldungen: ```text Connection reset by peer ECONNRESET An existing connection was forcibly closed by the remote host Die Verbindung wurde vom Kommunikationspartner zurückgesetzt SocketException: Connection reset ``` Die Formulierung „by peer“ bedeutet nicht zwingend, dass der eigentliche Anwendungsprozess der Gegenstelle den Reset absichtlich erzeugt hat. Der Reset kann stammen von: - Betriebssystem der Gegenstelle; - Anwendung; - lokalem Betriebssystem; - Firewall; - Load Balancer; - Reverse Proxy; - NAT-Gateway; - Intrusion-Prevention-System; - Service Mesh; - Container- oder Cloudnetzkomponente. --- **Typische Ursachen eines TCP Reset** - Verbindung zu einem geschlossenen TCP-Port; - Anwendung bricht einen Socket ausdrücklich ab; - Prozess wird beendet oder stürzt ab; - Anwendung schließt mit ungelesenen Eingangsdaten; - ungültiges Segment für eine nicht mehr existierende Verbindung; - Gegenstelle hat den Verbindungszustand verloren; - Host wurde neu gestartet; - alte Verbindung wird nach längerer Inaktivität erneut verwendet; - Firewall oder Load Balancer hat den Sitzungszustand entfernt; - Proxy lehnt eine Verbindung oder Anfrage ab; - Backend ist nicht verfügbar; - Protokoll wird auf dem falschen Port verwendet; - Sicherheitskomponente beendet die Sitzung; - Verbindungslimit oder Ressourcenlimit wurde erreicht; - Zeitüberschreitung führt zu einem erzwungenen Abbruch; - fehlerhafte NAT- oder Sessionzuordnung; - Paket gehört zu einer früheren Verbindung mit wiederverwendetem Port; - Anwendung verwendet eine abortive Socket-Schließung. Nicht jede Prozessbeendigung erzeugt zwingend einen Reset. Abhängig vom Socketzustand und Betriebssystem kann auch ein kontrollierter FIN-Abbau erfolgen. --- **Reset während des Handshakes** Paketfolge: ```text Client → Server SYN Server → Client RST, ACK ``` Mögliche Einordnung: - kein Listener auf dem Zielport; - Firewall lehnt aktiv ab; - Portweiterleitung zeigt auf geschlossenen Port; - Load Balancer lehnt ab; - falsche Zieladresse; - Dienst wurde beendet; - Listener existiert nur auf einer anderen lokalen Adresse; - IPv4-/IPv6-Bindung passt nicht. Nächster Nachweis: - Listener direkt auf dem Zielsystem prüfen; - Prozessbesitzer bestimmen; - Zieladresse und Adressfamilie bestätigen; - Paketaufzeichnung auf Serverseite durchführen; - Firewall- und NAT-Pfad prüfen. --- **Reset unmittelbar nach erfolgreichem Handshake** Paketfolge: ```text SYN SYN, ACK ACK RST ``` Mögliche Ursachen: - Anwendung akzeptiert und verwirft die Verbindung sofort; - Prozess- oder Workerlimit erreicht; - Zugriffskontrolle lehnt ab; - Proxy besitzt kein Backend; - Client beendet den Socket abrupt; - Server erwartet sofortige Protokolldaten; - Health Check verwendet ein unpassendes Protokoll; - Verbindungszustand ist zwischen Komponenten inkonsistent. Zu prüfen sind: - wer sendet den Reset? - wird vor dem Reset Anwendungsnutzlast übertragen? - existiert im Serverlog eine passende Verbindung? - tritt der Fehler bei jedem Client auf? - funktioniert ein protokollspezifischer Test? --- **Reset nach Übertragung einer Anfrage** Paketfolge: ```text Handshake erfolgreich Client sendet Anfrage Server oder Zwischenkomponente sendet RST ``` Mögliche Ursachen: - ungültiges Anwendungsprotokoll; - TLS-Daten an einem Klartextport; - Klartextdaten an einem TLS-Port; - fehlerhafte oder verbotene Anfrage; - Anwendung stürzt bei der Verarbeitung ab; - Proxy oder WAF beendet die Verbindung; - maximale Anfragegröße überschritten; - Sicherheitsrichtlinie löst aus; - Backend schließt abrupt; - Server liest die Anfrage nicht vollständig; - Client sendet weiter, nachdem der Server bereits geschlossen hat. Der Inhalt unmittelbar vor dem Reset ist für die Ursachenbestimmung besonders wichtig. --- **Reset nach längerer Inaktivität** Typischer Ablauf: ```text Verbindung ist ESTABLISHED keine Übertragung über längere Zeit Client sendet neue Daten RST wird empfangen ``` Mögliche Ursache: - Zwischenkomponente hat den Sitzungszustand gelöscht; - Server hat die Verbindung lokal bereits beendet; - Anwendung verwendet einen veralteten Socket; - Connection Pool prüft die Verbindung vor Wiederverwendung nicht; - Idle-Timeouts verschiedener Komponenten sind nicht abgestimmt. Zu vergleichen sind: - TCP-Keepalive; - Anwendungsheartbeat; - Firewall-Idle-Timeout; - NAT-Timeout; - Proxy-Timeout; - Load-Balancer-Timeout; - Connection-Pool-Lebensdauer. --- **Reset nach Wiederholungen** Möglicher Ablauf: ```text Daten werden gesendet Bestätigung fehlt Daten werden wiederholt weitere Wiederholungen RST oder lokaler Verbindungsabbruch ``` Ein Reset nach Wiederholungen kann bedeuten: - Netzwerkpfad war unterbrochen; - Gegenstelle hat den Zustand verloren; - Anwendung oder Betriebssystem gibt die Verbindung auf; - eine Zwischenkomponente reagiert auf eine nicht mehr bekannte Sitzung; - Prozess wurde während des Fehlers beendet. Die zeitliche Reihenfolge muss genau ausgewertet werden. Der Reset kann Folge und nicht Ursache des ursprünglichen Problems sein. --- **Reset-Absender bestimmen** In der Clientaufzeichnung ist zunächst die Quelladresse des Reset-Segments sichtbar. Sie ist jedoch nicht immer ein eindeutiger Beweis für den tatsächlichen Erzeuger. Zwischenkomponenten können: - mit der Adresse des Servers antworten; - Verbindungen stellvertretend terminieren; - NAT-Adressen verwenden; - einen eigenen TCP-Endpunkt darstellen; - Reset-Segmente erzeugen. Belastbarer Nachweis: 1. Aufzeichnung am Client. 2. Aufzeichnung am Server. 3. Zeitliche Synchronisation beider Systeme. 4. Vergleich derselben TCP-Verbindung. 5. Prüfung, ob der Reset den Server verlässt. 6. Prüfung, ob der Server den Reset überhaupt empfängt. 7. Protokolle von Firewall, Proxy und Load Balancer korrelieren. Beispiel: ```text Client sieht einen RST. Serveraufzeichnung zeigt keinen ausgehenden RST. Firewallprotokoll zeigt eine aktive Sitzungsbeendigung. Einordnung: Der Reset wurde wahrscheinlich von der Firewall erzeugt. ``` Dies ist eine Schlussfolgerung aus mehreren Befunden und nicht allein aus der IP-Quelladresse. --- **FIN, RST und Timeout unterscheiden** | Befund | Bedeutung | |---|---| | `FIN` | Sender beendet seine Senderichtung geordnet. | | `RST` | Verbindung wird abrupt zurückgesetzt. | | Timeout | Innerhalb der erwarteten Frist kam keine verwertbare Reaktion. | | ICMP-Fehler | IP- oder Netzwerkebene meldet ein Problem. | | Anwendungsfehler | TCP kann funktionieren, während das höhere Protokoll fehlschlägt. | Ein FIN bedeutet nicht zwingend, dass die gesamte Verbindung sofort beendet ist. TCP unterstützt einen geordneten Abbau je Richtung. --- **Verbindungsabbau zwischen Client und Server** Ein regulärer TCP-Abbau besteht logisch aus: ```text Teilnehmer A Teilnehmer B ESTABLISHED ESTABLISHED | | | FIN, ACK | |------------------------------------------>| | | FIN-WAIT-1 CLOSE-WAIT | | | ACK | |<------------------------------------------| | | FIN-WAIT-2 CLOSE-WAIT | | | FIN, ACK | |<------------------------------------------| | | TIME-WAIT LAST-ACK | | | ACK | |------------------------------------------>| | | TIME-WAIT CLOSED | | nach Ablauf der Wartezeit | CLOSED ``` Dies wird häufig als Four-Way Termination bezeichnet. In einer echten Aufzeichnung müssen nicht immer vier getrennte Pakete sichtbar sein. ACK und FIN können kombiniert werden. --- **FIN verbraucht eine Sequenznummer** Wie SYN verbraucht auch FIN eine Sequenznummer. Beispiel: ```text Teilnehmer A sendet: FIN, Seq = 5000 Teilnehmer B bestätigt: ACK = 5001 ``` Das FIN signalisiert: ```text Ich werde in dieser Richtung keine weiteren Daten mehr senden. ``` Die Gegenrichtung kann abhängig vom Anwendungs- und Socketzustand noch Daten übertragen. --- **Half-Close** Bei einem Half-Close wurde nur eine Senderichtung geordnet geschlossen. Beispiel: ```text Client sendet FIN. Server bestätigt FIN. Server sendet weiterhin verbleibende Antwortdaten. Server sendet später sein eigenes FIN. ``` Half-Close ist nicht dasselbe wie eine Half-Open Connection. | Begriff | Bedeutung | |---|---| | Half-Close | Eine Richtung wurde geordnet mit FIN beendet. | | Half-Open | Beide Endpunkte besitzen unterschiedliche Vorstellungen darüber, ob die Verbindung noch existiert. | Eine Half-Open Connection kann beispielsweise entstehen, wenn ein System neu startet und den früheren TCP-Zustand verliert, während die Gegenstelle die Verbindung weiterhin als vorhanden betrachtet. --- **TCP-Zustände beim Verbindungsabbau** | Zustand | Bedeutung | |---|---| | `FIN-WAIT-1` | Lokales FIN wurde gesendet; Bestätigung oder FIN der Gegenstelle steht aus. | | `FIN-WAIT-2` | Lokales FIN wurde bestätigt; FIN der Gegenstelle steht aus. | | `CLOSE-WAIT` | FIN der Gegenstelle wurde empfangen; lokale Anwendung hat noch nicht geschlossen. | | `CLOSING` | Beide Seiten haben nahezu gleichzeitig FIN gesendet. | | `LAST-ACK` | Lokales FIN wurde nach empfangenem FIN gesendet; abschließendes ACK steht aus. | | `TIME-WAIT` | Endpunkt wartet, damit verspätete Segmente einer alten Verbindung nicht falsch zugeordnet werden. | | `CLOSED` | Verbindung ist vollständig beendet. | --- **CLOSE-WAIT richtig interpretieren** `CLOSE-WAIT` bedeutet: ```text Die Gegenstelle hat ihre Senderichtung geschlossen. Das lokale Betriebssystem wartet darauf, dass die lokale Anwendung ihren Socket schließt. ``` Viele dauerhaft vorhandene `CLOSE-WAIT`-Sockets können hinweisen auf: - Anwendung liest EOF, schließt aber nicht; - Fehler im Connection-Handling; - blockierte Threads; - fehlende Fehlerbehandlung; - Ressourcenleck; - Anwendung wartet auf einen internen Vorgang; - Prozess reagiert nicht. `CLOSE-WAIT` wird nicht durch das bloße Ändern eines TCP-Timers behoben. Zuerst müssen Prozess und Anwendungscode beziehungsweise Herstellerprotokolle geprüft werden. --- **FIN-WAIT-2 richtig interpretieren** `FIN-WAIT-2` bedeutet: ```text Die lokale Seite hat ihre Senderichtung geschlossen. Die Gegenstelle hat dies bestätigt, aber noch kein eigenes FIN gesendet. ``` Mögliche Ursachen bei ungewöhnlich langen Beständen: - Gegenanwendung hält ihre Senderichtung offen; - Anwendung wartet auf weitere Verarbeitung; - Gegenprozess reagiert nicht; - Half-Close wird absichtlich verwendet; - Netzwerk- oder Zustandsproblem. Ein kurzfristiger `FIN-WAIT-2`-Zustand ist nicht automatisch fehlerhaft. --- **TIME-WAIT richtig interpretieren** `TIME-WAIT` schützt unter anderem davor, dass verspätete Segmente einer alten Verbindung einer späteren Verbindung mit denselben Endpunkten zugeordnet werden. Viele `TIME-WAIT`-Einträge können bei folgenden Arbeitslasten normal sein: - viele kurze HTTP-Verbindungen; - häufige Health Checks; - Proxy- oder API-Aufrufe; - fehlendes oder nicht genutztes Connection Pooling; - Lasttests; - Microservice-Kommunikation. Zu prüfen sind: - Rate neuer Verbindungen; - Wiederverwendung bestehender Verbindungen; - Quellportbestand; - Verbindungslaufzeit; - Baseline; - Anwendungskonfiguration. `TIME-WAIT` darf nicht vorsorglich durch aggressive Timeränderungen beseitigt werden. --- **Windows: TCP-Zustände prüfen** **LESEND** Alle TCP-Verbindungen: ```powershell Get-NetTCPConnection | Sort-Object State, LocalPort ``` Verbindungen im Zustand `SYN-SENT`: ```powershell Get-NetTCPConnection ` -State SynSent ``` Verbindungen im Zustand `SYN-RECEIVED`: ```powershell Get-NetTCPConnection ` -State SynReceived ``` Aufgebaute Verbindungen: ```powershell Get-NetTCPConnection ` -State Established ``` `CLOSE-WAIT`: ```powershell Get-NetTCPConnection ` -State CloseWait ``` `TIME-WAIT`: ```powershell Get-NetTCPConnection ` -State TimeWait ``` Bestimmten entfernten Port prüfen: ```powershell Get-NetTCPConnection ` -RemotePort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Serververbindungen eines lokalen Ports: ```powershell Get-NetTCPConnection ` -LocalPort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Kurzlebige Zustände können zwischen zwei Abfragen verschwinden. Eine Paketaufzeichnung ist für die vollständige zeitliche Reihenfolge zuverlässiger. --- **Windows: Prozess zuordnen** **LESEND** ```powershell Get-NetTCPConnection ` -RemotePort 443 | ForEach-Object { $connection = $_ $process = Get-Process ` -Id $connection.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $connection.LocalAddress LocalPort = $connection.LocalPort RemoteAddress = $connection.RemoteAddress RemotePort = $connection.RemotePort State = $connection.State ProcessId = $connection.OwningProcess ProcessName = $process.ProcessName } } ``` Ein Prozess kann zwischen Socketabfrage und Prozessabfrage bereits beendet sein. Fehlende Prozessinformationen müssen deshalb mit Zeitpunkt und Ereignisprotokollen korreliert werden. --- **Windows: TCP-Verbindung aktiv testen** **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Wichtige Felder: - `ComputerName`; - `RemoteAddress`; - `RemotePort`; - `InterfaceAlias`; - `SourceAddress`; - `TcpTestSucceeded`. `TcpTestSucceeded = True` bestätigt einen erfolgreichen TCP-Verbindungsaufbau für diesen Versuch. Es bestätigt nicht die Funktion von TLS, HTTP oder der eigentlichen Anwendung. Getrennte Prüfung einer konkreten Adresse: ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 ` -InformationLevel Detailed ``` --- **Windows: TCP-Statistiken prüfen** **LESEND** ```cmd netstat -s -p tcp ``` IPv6-TCP-Statistiken: ```cmd netstat -s -p tcpv6 ``` Verfügbare Leistungsindikatoren suchen: ```powershell Get-Counter ` -ListSet "*TCP*" ``` Die Namen der Leistungsindikatoren können von Sprache und Windows-Version abhängen. Zähler müssen über einen definierten Zeitraum als Differenz oder Rate ausgewertet werden. Ein hoher kumulierter Wert seit dem Systemstart beweist keine aktuelle Störung. --- **Windows: Paketaufzeichnung mit pktmon** `pktmon` verändert den Aufzeichnungszustand und erstellt Dateien. **SENSITIV · ÄNDERND** Vorhandene Aufzeichnung stoppen: ```cmd pktmon stop ``` Vorhandene Filter entfernen: ```cmd pktmon filter remove ``` Filter für TCP-Port `443` anlegen: ```cmd pktmon filter add TCP443 -t TCP -p 443 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` In PCAPNG konvertieren: ```cmd pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng ``` Temporären Filter entfernen: ```cmd pktmon filter remove ``` Voraussetzungen: - Zielverzeichnis existiert; - ausreichend freier Speicher ist vorhanden; - Aufzeichnungszeitraum ist begrenzt; - Datei wird geschützt gespeichert; - Filter und Aufzeichnungszustand werden anschließend zurückgesetzt. --- **Linux: TCP-Zustände mit ss prüfen** **LESEND** Alle TCP-Sockets: ```bash ss -tan ``` TCP-Sockets mit Prozessinformationen: ```bash sudo ss -tanp ``` `SYN-SENT`: ```bash ss -tan state syn-sent ``` `SYN-RECEIVED`: ```bash ss -tan state syn-recv ``` Aufgebaute Verbindungen: ```bash ss -tan state established ``` `CLOSE-WAIT`: ```bash ss -tan state close-wait ``` `TIME-WAIT`: ```bash ss -tan state time-wait ``` Erweiterte TCP-Informationen für Zielport `443`: ```bash sudo ss -tin \ 'dport = :443' ``` Erweiterte Informationen für einen lokalen Serverport: ```bash sudo ss -tin \ 'sport = :443' ``` Je nach Zustand und Kernel können erweiterte Angaben enthalten sein: - RTT; - RTO; - Congestion Window; - Retransmissions; - Sendemenge; - Empfangsmenge; - Window Scaling; - MSS; - Timer. Die konkrete Ausgabe hängt von Kernel und TCP-Zustand ab. --- **Linux: TCP-Zähler prüfen** **LESEND** ```bash nstat -az ``` Bestimmte Zähler: ```bash nstat -az TcpRetransSegs ``` ```bash nstat -az TcpAttemptFails ``` ```bash nstat -az TcpEstabResets ``` Zusätzliche klassische Statistik: ```bash netstat -s ``` Zu beachten: - Zähler sind häufig kumulativ; - ein Reset-Zähler nennt nicht automatisch die betroffene Anwendung; - Container oder Netzwerk-Namespaces können eigene Sichten besitzen; - für eine aktuelle Störung sind Vorher-Nachher-Differenzen notwendig. --- **macOS: TCP-Zustände prüfen** **LESEND** ```bash netstat -anv -p tcp ``` TCP-Verbindungen mit Prozesszuordnung: ```bash sudo lsof -nP -iTCP ``` Aufgebaute TCP-Verbindungen: ```bash sudo lsof \ -nP \ -iTCP \ -sTCP:ESTABLISHED ``` Interaktive TCP-Ansicht: ```bash nettop -m tcp ``` TCP-Statistiken: ```bash netstat -s -p tcp ``` Kurzlebige Handshakezustände können auch unter macOS leichter mit einer Paketaufzeichnung als mit wiederholten Socketabfragen erfasst werden. --- **Aktive Tests unter Linux und macOS** TCP-Porttest: **NETZAKTIV** ```bash nc -vz app.example.test 443 ``` Linux mit begrenzter Wartezeit, abhängig von der installierten `nc`-Variante: ```bash nc -vz -w 5 app.example.test 443 ``` macOS mit TCP-Verbindungsfrist: ```bash nc -vz -G 5 app.example.test 443 ``` HTTP- oder HTTPS-Test mit getrennten Fristen: ```bash curl \ --connect-timeout 5 \ --max-time 15 \ -v \ https://app.example.test/ ``` Bedeutung: - `--connect-timeout` begrenzt die Verbindungsphase; - `--max-time` begrenzt den gesamten Aufruf. Ein Fehler nach erfolgreicher `Connected`-Meldung ist kein reiner TCP-Connect-Fehler mehr. --- **Paketaufzeichnung unter Linux** **SENSITIV · LESEND** Auf Port `443` begrenzen: ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 ``` Auf einen Host und Port begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.25 and tcp port 443' \ -c 200 ``` Mit ausführlicheren TCP-Informationen in Datei schreiben: ```bash sudo tcpdump \ -ni any \ -s 0 \ -w /tmp/tcp443.pcap \ 'host 192.0.2.25 and tcp port 443' ``` Nach reproduziertem Fehler mit `Strg+C` beenden. Die Datei enthält möglicherweise sensible Daten und muss anschließend geschützt ausgewertet und kontrolliert entfernt werden. --- **Paketaufzeichnung unter macOS** Verwendbare Schnittstellen anzeigen: ```bash tcpdump -D ``` Auf einer konkreten Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.25 and tcp port 443' \ -c 200 ``` Lokale Loopback-Verbindung: ```bash sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni en0 \ -s 0 \ -w /tmp/tcp443.pcap \ 'host 192.0.2.25 and tcp port 443' ``` --- **Wireshark-Filter für TCP** Bestimmter Port: ```text tcp.port == 443 ``` Bestimmte IP-Adresse und Port: ```text ip.addr == 192.0.2.25 && tcp.port == 443 ``` Nur initiale SYN-Segmente: ```text tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` SYN/ACK: ```text tcp.flags.syn == 1 && tcp.flags.ack == 1 ``` Reset: ```text tcp.flags.reset == 1 ``` FIN: ```text tcp.flags.fin == 1 ``` Vermutete Wiederholungen: ```text tcp.analysis.retransmission ``` Vermuteter Fast Retransmit: ```text tcp.analysis.fast_retransmission ``` Duplicate ACKs: ```text tcp.analysis.duplicate_ack ``` Zero Window: ```text tcp.analysis.zero_window ``` Ein bestimmter TCP-Datenstrom: ```text tcp.stream == 7 ``` Die Nummer des TCP-Streams wird von Wireshark innerhalb der geöffneten Aufzeichnung vergeben und ist keine übertragene Protokollnummer. --- **Aufzeichnung richtig planen** Vor Beginn sind festzulegen: ```text Client: Server: Port: Zeitfenster: Testhandlung: Aufzeichnungspunkte: Erwartete Paketfolge: Fehlerkriterium: ``` Die Systemzeiten der beteiligten Geräte müssen ausreichend synchron sein. Anderenfalls können Client-, Server-, Firewall- und Proxyprotokolle nicht zuverlässig korreliert werden. --- **Aufzeichnung am Client und Server vergleichen** | Clientaufzeichnung | Serveraufzeichnung | Mögliche Einordnung | |---|---|---| | SYN sichtbar | SYN nicht sichtbar | Fehler vor dem Server | | SYN sichtbar | SYN sichtbar | Hinweg funktioniert | | kein SYN/ACK am Client | SYN/ACK verlässt Server | Rückweg oder Filterung | | RST am Client | RST verlässt Server | Server oder Serveranwendung wahrscheinlich beteiligt | | RST am Client | kein RST am Server | Zwischenkomponente wahrscheinlich beteiligt | | Daten am Client gesendet | Daten erreichen Server | Hinweg der Daten funktioniert | | ACK fehlt am Client | ACK verlässt Server | Rückwegproblem | | Server erhält ACK nicht | Client sendet ACK | Filterung oder asymmetrischer Pfad | | FIN auf beiden Seiten | FIN verlässt ursprünglichen Sender | kontrollierter Abbau | | unterschiedliche Paketfolgen | Übersetzung oder Verlust | NAT, Proxy, Capturepunkt oder Netzwerkpfad prüfen | --- **NAT, Firewall, Proxy und Load Balancer berücksichtigen** Eine Ende-zu-Ende-Verbindung kann tatsächlich aus mehreren getrennten TCP-Verbindungen bestehen. Beispiel mit Reverse Proxy: ```text Client → TCP-Verbindung 1 → Reverse Proxy → TCP-Verbindung 2 → Backend ``` Ein Reset zwischen Proxy und Backend muss nicht als Reset zwischen Proxy und Client weitergegeben werden. Der Proxy kann stattdessen eine HTTP-Fehlerantwort erzeugen. Beispiel mit NAT: ```text Client intern: 192.0.2.100:53124 NAT extern: 203.0.113.10:62000 Server: 198.51.100.25:443 ``` Zu prüfen sind: - übersetzte Quelladresse; - übersetzter Quellport; - Sessiontabelleneintrag; - Ablaufzeit; - Rückweg; - Verbindung zum Backend; - getrennte Timeouts je TCP-Abschnitt; - welcher Abschnitt den Reset enthält. --- **Container und Kubernetes berücksichtigen** Eine TCP-Verbindung kann durch mehrere Netzwerk-Namespaces laufen: ```text Client → Hostport → Container-Netzwerk → Containersocket ``` oder: ```text Client → Load Balancer → Kubernetes-Service → Pod-IP → Anwendungscontainer ``` Zu prüfen sind: - Handshake am externen Endpunkt; - Handshake zum Backend; - Listener im Container oder Pod; - Host- und Containerport; - Service-`port` und `targetPort`; - Sidecar- oder Service-Mesh-Verbindung; - NetworkPolicy; - Readiness und EndpointSlices; - Reset innerhalb des Pods; - Reset am Ingress oder Gateway. Ein erfolgreicher Handshake zum Load Balancer beweist keinen erfolgreichen Handshake zum Backend. --- **Typische Fehlermeldungen einordnen** | Meldung | Mögliche TCP-Einordnung | |---|---| | `Connection refused` | häufig Reset als Antwort auf SYN | | `Connection timed out` | Handshake oder Datenübertragung ohne rechtzeitige Antwort | | `Connection reset by peer` | gültiger Reset wurde empfangen | | `Broken pipe` | Schreiben auf bereits geschlossene Verbindung | | `EOF` | Gegenstelle hat den Datenstrom beendet | | `Operation timed out` | Frist der Anwendung oder Bibliothek abgelaufen | | `No route to host` | Routing- oder lokal gemeldeter Erreichbarkeitsfehler | | `Network is unreachable` | keine verwendbare Route | | `TLS handshake timeout` | TCP möglicherweise erfolgreich, TLS nicht abgeschlossen | | `Read timed out` | Verbindung steht, erwartete Daten fehlen | | `Write timed out` | Daten konnten nicht innerhalb der Frist geschrieben werden | Der genaue Wortlaut hängt von Betriebssystem, Programmiersprache, Bibliothek und Anwendung ab. --- **Hypothese und Gegenbeweis** Beispiel für einen Connect-Timeout: ```text Hypothese: Eine Netzwerkfirewall verwirft die SYN-Pakete zum TCP-Port 443. Erwarteter Befund: Der Client sendet wiederholt SYN-Pakete. Der Server empfängt diese SYN-Pakete nicht. Es wird weder SYN/ACK noch RST empfangen. Gegenbeweis: Die Serveraufzeichnung zeigt das eingehende SYN und ein ausgehendes SYN/ACK. Testmethode: Zeitgleich begrenzte Paketaufzeichnung auf Client und Server. Erfolgskriterium: Der genaue Punkt des Paketverlusts ist eingegrenzt. Risiko: Die Aufzeichnung enthält interne Verbindungsdaten und muss geschützt werden. ``` Beispiel für einen Reset: ```text Hypothese: Der Reverse Proxy erzeugt den Reset, weil kein Backend verfügbar ist. Erwarteter Befund: Der Client-Handschlag mit dem Proxy ist erfolgreich. Der Proxy kann keine Verbindung zum Backend aufbauen. Der Client empfängt anschließend einen Reset. Das Backend empfängt keinen Verbindungsversuch oder lehnt ihn ab. Gegenbeweis: Der Backend-Handschlag ist erfolgreich und der Reset verlässt nachweislich das Backend. Testmethode: Aufzeichnungen und Protokolle an Client, Proxy und Backend korrelieren. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | Listener starten oder Bindung korrigieren | Reset wegen fehlendem Listener bestätigt | geänderte Erreichbarkeit | | Firewallregel korrigieren | Paketverlust an der Firewall nachgewiesen | unbeabsichtigte Freigabe | | Rückweg korrigieren | asymmetrischer oder fehlender Rückweg bestätigt | weitere Netze können betroffen sein | | NAT-Zuordnung korrigieren | falsche Übersetzung bestätigt | bestehende Sitzungen werden beeinflusst | | Proxy-Backend korrigieren | fehlerhafter Backendpfad nachgewiesen | produktiver Datenverkehr wird umgeleitet | | Idle-Timeout abstimmen | Sitzungsablauf nach Inaktivität bestätigt | mehr Sitzungszustand und Ressourcenverbrauch | | Connection-Pool-Lebensdauer anpassen | Wiederverwendung veralteter Verbindungen bestätigt | mehr neue Verbindungen | | Anwendungs-Timeout anpassen | Verarbeitung dauert legitim länger und Ursache ist bekannt | Fehler werden eventuell später erkannt | | TCP-Keepalive gezielt konfigurieren | verwaiste Idle-Verbindungen bestätigt | zusätzlicher Netzwerkverkehr | | Anwendung korrigieren | `CLOSE-WAIT`, abortives Schließen oder Absturz bestätigt | Dienstneustart oder Deployment erforderlich | | Backendkapazität erhöhen | Ressourcenengpass nachgewiesen | Kosten und Betriebsänderung | | Protokoll oder Zielport korrigieren | falsches Protokoll beziehungsweise falscher Port bestätigt | Clientkonfiguration ändert sich | Timeouts dürfen nicht pauschal verlängert werden, um Paketverlust, Deadlocks oder überlastete Backends zu verdecken. --- **Systematischer Diagnoseablauf** 1. Exakte Anwendungsmeldung aufnehmen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Client, Server, Zielname und Zielport bestimmen. 4. Verwendete IP-Adresse und Adressfamilie erfassen. 5. Transportprotokoll bestätigen. 6. Erwarteten Listener auf dem Server prüfen. 7. Besitzenden Prozess bestimmen. 8. Lokalen TCP-Test am Server durchführen. 9. TCP-Test vom betroffenen Client durchführen. 10. Socketzustand während des Versuchs beobachten. 11. Prüfen, ob ein SYN erzeugt wird. 12. Prüfen, ob der Server das SYN empfängt. 13. Prüfen, ob SYN/ACK oder RST zurückgesendet wird. 14. Prüfen, ob das abschließende ACK ankommt. 15. Bei erfolgreichem Handshake Anwendungsdaten prüfen. 16. Connect- und Anwendungs-Timeout unterscheiden. 17. FIN und RST unterscheiden. 18. Reset-Richtung und Reset-Zeitpunkt bestimmen. 19. Client-, Server- und Zwischenprotokolle korrelieren. 20. Retransmissions und Duplicate ACKs auswerten. 21. Captureverlust und Offloading berücksichtigen. 22. NAT-, Firewall- und Proxyzustand prüfen. 23. Load Balancer und Backendverbindung getrennt prüfen. 24. Container- und Netzwerk-Namespace berücksichtigen. 25. Idle-Phase und Timeoutwerte dokumentieren. 26. Frische und wiederverwendete Verbindung vergleichen. 27. Hypothese und Gegenbeweis formulieren. 28. Genau eine kontrollierte Maßnahme durchführen. 29. Identischen Verbindungsversuch wiederholen. 30. Anwendungsprotokoll vollständig verifizieren. 31. Weitere repräsentative Clients prüfen. 32. Temporäre Filter und Aufzeichnungen entfernen. 33. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein SYN sichtbar | Anwendung, DNS oder lokaler Socketaufruf | Anwendungstrace und Zieladresse | | SYN wiederholt, keine Antwort | Drop, Routing oder Rückweg | serverseitige Aufzeichnung | | SYN erreicht Server nicht | Netzpfad vor dem Server | Zwischenpunkte und Firewalllogs | | SYN erreicht Server, kein SYN/ACK | lokaler Filter, kein Listener oder Überlastung | Socketliste und Servertrace | | SYN wird mit RST beantwortet | aktive Ablehnung | Reset-Erzeuger und Listener prüfen | | SYN/ACK verlässt Server, erreicht Client nicht | Rückweg oder Filterung | Client- und Firewallaufzeichnung | | SYN/ACK wird wiederholt | abschließendes ACK fehlt | Clientaufzeichnung | | Handshake vollständig | TCP-Connect funktioniert | Anwendungsprotokoll prüfen | | Handshake vollständig, keine Nutzdaten | Anwendung wartet oder startet Anfrage nicht | Anwendungstrace | | Anfrage gesendet, keine Antwort | Backend oder Anwendung langsam | Server- und Backendprotokolle | | RST direkt nach Handshake | Anwendung oder Zwischenkomponente lehnt ab | Reset-Sender und Logs | | RST nach Anfrage | Protokoll-, Anwendungs- oder Sicherheitsfehler | Daten vor dem Reset auswerten | | RST nach langer Inaktivität | Idle-Timeout oder veralteter Socket | Timeoutwerte und frische Verbindung | | FIN nach Anfrage | kontrollierte Schließung | Anwendungsergebnis prüfen | | viele `CLOSE-WAIT` | lokale Anwendung schließt nicht | Prozess- und Threadanalyse | | viele `TIME-WAIT` | viele kurzlebige Verbindungen | Verbindungsrate und Pooling | | viele `SYN-SENT` | Ziele antworten nicht | Ziel- und Pfadvergleich | | viele `SYN-RECEIVED` | Handshake bleibt unvollständig | Serverwarteschlange und Clientpfad | | Retransmissions nur in einer Capturedatei | Captureverlust oder Offloading möglich | zweiter Aufzeichnungspunkt | | frische Verbindung funktioniert | alte Verbindung fehlerhaft | Idle- und Poolingverhalten | | Porttest funktioniert, TLS scheitert | TCP funktioniert, TLS fehlerhaft | TLS-Handshake analysieren | | nur große Übertragung stockt | Verlust, Window oder MTU möglich | Folgeseite zu Retransmissions und MTU | | nur ein Backend erzeugt Resets | Backend- oder Pfadproblem | direkte Backendtests | | Reset am Client, nicht am Server | Zwischenkomponente wahrscheinlich | Firewall-, Proxy- und LB-Protokolle | --- **Typische Diagnosefehler** - Anwendungstimeout und TCP-Timeout gleichsetzen. - Einen erfolgreichen Ping als TCP-Nachweis verwenden. - Einen offenen TCP-Port als vollständigen Anwendungsnachweis bewerten. - Nur `Test-NetConnection` oder `nc` verwenden. - DNS-Zeit und TCP-Verbindungszeit vermischen. - Nur auf dem Client aufzeichnen. - Aus einer fehlenden Clientantwort schließen, dass der Server nichts gesendet hat. - Aus der RST-Quelladresse sicher auf den Erzeuger schließen. - Firewall, Proxy oder Load Balancer als Reset-Erzeuger ignorieren. - FIN und RST gleich behandeln. - `CLOSE-WAIT` durch Änderung von TCP-Timern beheben wollen. - `TIME-WAIT` pauschal als Fehler bewerten. - Wiederholungen ohne Sequenznummern und ACKs auswerten. - Duplicate ACKs automatisch als Paketverlust bewerten. - Wireshark-Analysemarkierungen als echte TCP-Flags interpretieren. - Checksum-Offloading ignorieren. - Captureverlust am Analysesystem ignorieren. - IPv4 und IPv6 nicht getrennt prüfen. - Client- und Serverzeit nicht synchronisieren. - NAT-Adressen und ursprüngliche Adressen verwechseln. - Proxyverbindung und Backendverbindung als eine einzige TCP-Verbindung behandeln. - Host-, Container- und Pod-Namespace verwechseln. - Veraltete Verbindung aus einem Pool nicht berücksichtigen. - Idle-Timeout ohne Messung vermuten. - Timeout pauschal erhöhen. - TCP Keepalive als Nachweis der Anwendungsgesundheit betrachten. - Firewall vollständig deaktivieren. - Prozess vorsorglich beenden. - Server vorsorglich neu starten. - mehrere Einstellungen gleichzeitig verändern. - Paketaufzeichnung ohne Filter laufen lassen. - sensible Capturedateien ungeschützt speichern. - nach der Maßnahme nur einen einzelnen erfolgreichen Versuch prüfen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Zielname wird zur richtigen Adresse aufgelöst; - richtige IPv4- oder IPv6-Adresse wird verwendet; - erwarteter TCP-Listener ist vorhanden; - richtiger Prozess besitzt den Listener; - SYN erreicht den Server; - SYN/ACK erreicht den Client; - abschließendes ACK erreicht den Server; - TCP-Verbindung erreicht `ESTABLISHED`; - keine unerwarteten Reset-Segmente entstehen; - Daten werden in beiden Richtungen übertragen; - ACKs bestätigen die erwarteten Sequenzbereiche; - Retransmissionsrate entspricht der Baseline; - Anwendung antwortet innerhalb der vorgesehenen Frist; - TLS funktioniert, sofern vorgesehen; - Proxy erreicht sein Backend; - Load Balancer verwendet gesunde Backends; - NAT- und Firewallzustand bleiben während der Sitzung bestehen; - wiederverwendete Verbindungen funktionieren; - Verhalten nach repräsentativer Inaktivität ist korrekt; - Verbindung wird kontrolliert beendet; - keine dauerhaft wachsenden `CLOSE-WAIT`-Bestände entstehen; - `TIME-WAIT`-Bestand ist zur Arbeitslast plausibel; - mehrere aufeinanderfolgende Versuche funktionieren; - weitere repräsentative Clients funktionieren; - temporäre Capturefilter wurden entfernt; - Aufzeichnungen wurden geschützt oder kontrolliert gelöscht; - Ursache, Maßnahme und Prävention wurden dokumentiert. Ein einzelner erfolgreicher Three-Way Handshake ist keine vollständige Verifikation der Anwendung. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Client: Server: Zielname: Zielport: Adressfamilie: Anwendung: Exakte Fehlermeldung: Verwendete Quelladresse: Verwendete Zieladresse: Listener: Handshake-Befund: Socketzustände: Anwendungsdaten: Timeoutart: Timeoutdauer: Reset-Absender: Nachweis des Reset-Absenders: Retransmissions: FIN-Befund: Zwischenkomponenten: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] Client und Server bestimmt - [ ] Zielname dokumentiert - [ ] Zieladresse dokumentiert - [ ] Quelladresse dokumentiert - [ ] Quell- und Zielport erfasst - [ ] IPv4 und IPv6 unterschieden - [ ] TCP-Listener geprüft - [ ] Prozessbesitzer bestimmt - [ ] lokalen TCP-Test durchgeführt - [ ] entfernten TCP-Test durchgeführt - [ ] SYN sichtbar - [ ] SYN/ACK oder RST ausgewertet - [ ] abschließendes ACK geprüft - [ ] Zustand `SYN-SENT` berücksichtigt - [ ] Zustand `SYN-RECEIVED` berücksichtigt - [ ] Zustand `ESTABLISHED` bestätigt - [ ] TCP-Optionen bei Bedarf verglichen - [ ] MSS geprüft - [ ] Window Scaling berücksichtigt - [ ] SACK-Unterstützung berücksichtigt - [ ] Anwendungsdaten nach dem Handshake geprüft - [ ] Sequenz- und Bestätigungsnummern ausgewertet - [ ] Retransmissions geprüft - [ ] Duplicate ACKs berücksichtigt - [ ] Captureverlust ausgeschlossen - [ ] Checksum-Offloading berücksichtigt - [ ] Connect-Timeout bestimmt - [ ] Anwendungs-Timeout bestimmt - [ ] TLS-Timeout bei Bedarf berücksichtigt - [ ] Proxy-Timeout bei Bedarf berücksichtigt - [ ] Idle-Timeout berücksichtigt - [ ] frische Verbindung getestet - [ ] wiederverwendete Verbindung getestet - [ ] TCP Keepalive bei Bedarf geprüft - [ ] RST-Richtung bestimmt - [ ] Reset-Absender eingegrenzt - [ ] FIN und RST unterschieden - [ ] Verbindungsabbau geprüft - [ ] `CLOSE-WAIT` berücksichtigt - [ ] `FIN-WAIT-2` berücksichtigt - [ ] `TIME-WAIT` berücksichtigt - [ ] Clientaufzeichnung durchgeführt - [ ] Serveraufzeichnung durchgeführt - [ ] Firewallprotokolle korreliert - [ ] NAT-Zustand berücksichtigt - [ ] Proxy und Backend getrennt geprüft - [ ] Load Balancer berücksichtigt - [ ] Container- oder Pod-Namespace berücksichtigt - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] Anwendungsprotokoll verifiziert - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Filter entfernt - [ ] Capturedateien geschützt oder entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl oder Filter | |---|---| | Windows-TCP-Verbindungen | `Get-NetTCPConnection` | | Windows `SYN-SENT` | `Get-NetTCPConnection -State SynSent` | | Windows `SYN-RECEIVED` | `Get-NetTCPConnection -State SynReceived` | | Windows `ESTABLISHED` | `Get-NetTCPConnection -State Established` | | Windows `CLOSE-WAIT` | `Get-NetTCPConnection -State CloseWait` | | Windows `TIME-WAIT` | `Get-NetTCPConnection -State TimeWait` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -Port -InformationLevel Detailed` | | Windows-TCP-Statistik | `netstat -s -p tcp` | | Windows-Paketmonitor | `pktmon` | | Linux-TCP-Sockets | `ss -tan` | | Linux-TCP-Details | `sudo ss -tin` | | Linux `SYN-SENT` | `ss -tan state syn-sent` | | Linux `SYN-RECEIVED` | `ss -tan state syn-recv` | | Linux `ESTABLISHED` | `ss -tan state established` | | Linux `CLOSE-WAIT` | `ss -tan state close-wait` | | Linux `TIME-WAIT` | `ss -tan state time-wait` | | Linux-TCP-Zähler | `nstat -az` | | macOS-TCP-Sockets | `netstat -anv -p tcp` | | macOS-Prozesszuordnung | `sudo lsof -nP -iTCP` | | macOS-Liveansicht | `nettop -m tcp` | | TCP-Porttest | `nc -vz ` | | HTTP-/HTTPS-Test | `curl --connect-timeout 5 --max-time 15 -v ` | | Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 200` | | macOS-Aufzeichnung | `sudo tcpdump -ni 'tcp port ' -c 200` | | Wireshark: Port | `tcp.port == ` | | Wireshark: initiales SYN | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | Wireshark: SYN/ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 1` | | Wireshark: Reset | `tcp.flags.reset == 1` | | Wireshark: FIN | `tcp.flags.fin == 1` | | Wireshark: Retransmission | `tcp.analysis.retransmission` | | Wireshark: Fast Retransmit | `tcp.analysis.fast_retransmission` | | Wireshark: Duplicate ACK | `tcp.analysis.duplicate_ack` | | Wireshark: TCP-Stream | `tcp.stream == ` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Stop-Process taskkill Stop-Service Restart-Service netsh int ip reset netsh winsock reset Set-NetFirewallRule New-NetFirewallRule Deaktivieren der Windows-Firewall kill kill -9 systemctl stop systemctl restart sysctl -w iptables nft ufw disable firewall-cmd --permanent docker restart docker stop kubectl delete kubectl rollout restart pauschales Erhöhen aller Timeouts aggressives Verkürzen von TIME-WAIT unkontrolliertes Aktivieren oder Ändern von TCP Keepalive Deaktivieren von TCP-Offloading ohne Vergleichstest Neustart von Firewall, Proxy oder Load Balancer ``` Ein Neustart kann TCP-Zustände, Sessiontabellen und den für die Diagnose wichtigen Ausgangszustand zerstören. --- **Quellen** **Standards** - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 1122 – Requirements for Internet Hosts – Communication Layers](https://datatracker.ietf.org/doc/html/rfc1122) - [RFC 5681 – TCP Congestion Control](https://datatracker.ietf.org/doc/html/rfc5681) - [RFC 6298 – Computing TCP's Retransmission Timer](https://datatracker.ietf.org/doc/html/rfc6298) - [RFC 7323 – TCP Extensions for High Performance](https://datatracker.ietf.org/doc/html/rfc7323) - [RFC 2018 – TCP Selective Acknowledgment Options](https://datatracker.ietf.org/doc/html/rfc2018) - [RFC 2883 – An Extension to the Selective Acknowledgement Option](https://datatracker.ietf.org/doc/html/rfc2883) - [RFC 5961 – Improving TCP's Robustness to Blind In-Window Attacks](https://datatracker.ietf.org/doc/html/rfc5961) **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – pktmon filter add](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-filter-add) - [Microsoft Learn – Troubleshoot TCP/IP connectivity](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) - [Microsoft Learn – Guidance for troubleshooting TCP/IP communication](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-communication-guidance) **Offizielle Linux-Dokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – tcp(7)](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux Kernel Documentation – SNMP counters](https://docs.kernel.org/networking/snmp_counter.html) **Offizielle Wireshark-Dokumentation** - [Wireshark User’s Guide – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark Display Filter Reference – TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.3 UDP-Diagnose und ICMP-Fehlermeldungen **Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose von UDP-Kommunikation und zugehörigen ICMP- beziehungsweise ICMPv6-Fehlermeldungen. Nach der Bearbeitung muss unterschieden werden können: - ob ein lokaler UDP-Endpunkt vorhanden ist; - welcher Prozess den UDP-Port besitzt; - ob ein Datagramm den Client tatsächlich verlässt; - ob es den vorgesehenen Server erreicht; - ob die Serveranwendung das Datagramm verarbeitet; - ob eine Antwort erzeugt und zurückgesendet wird; - ob eine Firewall, NAT-Instanz oder andere Zwischenkomponente eingreift; - ob eine ICMP-Fehlermeldung zurückkommt; - ob ein Port geschlossen oder lediglich nicht eindeutig prüfbar ist; - ob Paketgröße, Fragmentierung oder Path MTU beteiligt sind; - ob Unicast, Broadcast oder Multicast verwendet wird; - ob der richtige Host-, Container- oder Pod-Namespace untersucht wird. UDP besitzt keinen Handshake und keine integrierte Empfangsbestätigung. Ein erfolgreich abgesendetes Datagramm beweist deshalb nicht, dass es den Zielhost oder die Zielanwendung erreicht hat. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen. | | **ÄNDERND** | Verändert Konfiguration oder Laufzeitzustand. | | **AUSFALLRISIKO** | Kann Verbindungen, Dienste oder Netzwerkkomponenten beeinträchtigen. | UDP-Dienste dürfen nur mit gültigen, erwarteten und autorisierten Anfragen getestet werden. Unkontrollierte oder sehr schnelle UDP-Anfragen können: - Dienste überlasten; - Rate Limits auslösen; - Intrusion-Detection-Systeme alarmieren; - Verstärkungsangriffe begünstigen; - große Antwortmengen erzeugen; - produktive Protokollzustände beeinflussen. --- **Grundlegende Eigenschaften von UDP** UDP ist ein minimales, nachrichtenorientiertes Transportprotokoll. UDP bietet: - Quell- und Zielport; - Datagrammgrenzen; - Längenfeld; - Prüfsumme; - geringen Protokolloverhead; - Unicast-, Broadcast- und Multicast-Kommunikation. UDP bietet selbst nicht: - Verbindungsaufbau; - Verbindungsabbau; - Empfangsbestätigung; - Sequenznummern; - automatische Wiederholung; - Reihenfolgegarantie; - Duplikatschutz; - Flusskontrolle; - Überlastkontrolle; - Sitzungserkennung; - zuverlässige Erkennung einer ausgefallenen Gegenstelle. Eine Anwendung oder ein über UDP betriebenes Protokoll kann solche Funktionen selbst implementieren. Beispiele sind: - DNS mit eigenen Wiederholungen und TCP-Fallback; - QUIC mit eigener Zuverlässigkeit und Überlastkontrolle; - anwendungsspezifische Sequenznummern; - Zeitstempel; - Request-IDs; - Heartbeats; - Bestätigungsdatagramme. --- **TCP und UDP vergleichen** | Merkmal | TCP | UDP | |---|---|---| | Verbindungsaufbau | Three-Way Handshake | kein Handshake | | Datenmodell | Bytestrom | einzelne Datagramme | | Bestätigung | TCP-ACK | nicht in UDP enthalten | | Reihenfolge | durch TCP sichergestellt | nicht sichergestellt | | Wiederholung | durch TCP | nur durch Anwendung | | Flusskontrolle | vorhanden | nicht vorhanden | | Überlastkontrolle | vorhanden | nicht in UDP selbst | | Verbindungszustände | unter anderem `LISTEN`, `ESTABLISHED` | keine entsprechenden TCP-Zustände | | Reaktion bei geschlossenem Port | normalerweise TCP Reset | möglicherweise ICMP Port Unreachable | | Porttest | TCP-Handshake liefert klares Ergebnis | ohne Protokollantwort häufig mehrdeutig | Ein Test von TCP-Port `53` beweist nicht, dass UDP-Port `53` funktioniert. Umgekehrt beweist eine erfolgreiche UDP-DNS-Abfrage nicht automatisch, dass DNS über TCP funktioniert. --- **UDP-Header** Der UDP-Header besitzt vier Felder: ```text Quellport Zielport Länge Prüfsumme ``` Die Mindestlänge eines UDP-Datagramms beträgt acht Byte, weil der UDP-Header selbst acht Byte groß ist. | Feld | Größe | Bedeutung | |---|---:|---| | Source Port | 16 Bit | Port des Senders | | Destination Port | 16 Bit | Port des Empfängers | | Length | 16 Bit | Gesamtlänge von UDP-Header und UDP-Nutzdaten | | Checksum | 16 Bit | Prüfsumme über relevante IP-, UDP- und Nutzdatenfelder | UDP enthält keine Felder für: - Sequenznummer; - Bestätigungsnummer; - Empfangsfenster; - SYN; - FIN; - RST. Bei IPv4 kann eine UDP-Prüfsumme gemäß der ursprünglichen UDP-Spezifikation als nicht verwendet gekennzeichnet sein. Bei IPv6 ist eine gültige UDP-Prüfsumme grundsätzlich erforderlich; nur eng definierte Sonderfälle besitzen Ausnahmen. --- **UDP-Kommunikation eindeutig bestimmen** Ein UDP-Datagramm wird durch folgende Angaben eingeordnet: ```text Quell-IP-Adresse Quellport Ziel-IP-Adresse Zielport Transportprotokoll UDP ``` Beispiel: ```text Client: 192.0.2.100:53124 Server: 192.0.2.53:53 ``` Anfrage: ```text 192.0.2.100:53124 → 192.0.2.53:53 UDP ``` Antwort: ```text 192.0.2.53:53 → 192.0.2.100:53124 UDP ``` Eine Stateful Firewall oder NAT-Instanz kann diese Angaben verwenden, um einen zeitlich begrenzten Pseudo-Sitzungszustand zu verwalten. UDP selbst erzeugt diesen Zustand nicht. --- **UDP besitzt keinen Listenerzustand wie TCP** Werkzeuge sprechen bei UDP teilweise trotzdem von „Listening“, weil ein Prozess einen UDP-Endpunkt gebunden hat. Technisch bedeutet der Befund: ```text Ein UDP-Socket ist an eine lokale Adresse und einen lokalen Port gebunden. ``` Der Befund beweist nicht: - dass eine bestimmte Anfrage korrekt formatiert ist; - dass die Anwendung das Datagramm liest; - dass die Anwendung antwortet; - dass der Rückweg funktioniert; - dass die Firewall den Datenverkehr erlaubt; - dass NAT die Antwort richtig zuordnet; - dass der Dienst auf Anwendungsebene gesund ist. --- **Verbundener UDP-Socket** Eine Anwendung kann einen UDP-Socket mit einer Gegenstelle „verbinden“. Dieser Vorgang führt nicht zu einem Netzwerk-Handshake. Das Betriebssystem kann dadurch lediglich: - eine Standardzieladresse hinterlegen; - eingehende Datagramme auf eine Gegenstelle begrenzen; - bestimmte ICMP-Fehler dem Socket zuordnen; - normale `send`- und `receive`-Aufrufe ermöglichen. Ein als verbunden dargestellter UDP-Socket beweist deshalb keine erreichbare Gegenstelle. --- **Was ein erfolgreicher send-Aufruf beweist** Wenn eine Anwendung ein UDP-Datagramm erfolgreich an das Betriebssystem übergibt, bedeutet das zunächst: ```text Der lokale Netzwerkstack hat das Datagramm zur Übertragung angenommen. ``` Es beweist nicht: - dass die Netzwerkkarte es gesendet hat; - dass es die lokale Firewall passiert hat; - dass es den Zielhost erreicht hat; - dass ein Prozess am Zielport lauscht; - dass die Zielanwendung es verarbeitet hat; - dass eine Antwort erzeugt wurde; - dass die Antwort den Client erreicht. Für einen belastbaren Nachweis sind Protokollantwort, Serverprotokoll oder korrelierte Paketaufzeichnung notwendig. --- **Erwarteten UDP-Ablauf festlegen** Vor der Diagnose müssen mindestens folgende Angaben dokumentiert werden: ```text Anwendung: Quellhost: Zielhost: Quellport: Zielport: Adressfamilie: Anfrage: Erwartete Antwort: Timeout: Kommunikationsart: Zwischenkomponenten: ``` Bei einem Protokoll ohne Antwort muss der Nachweis auf der Empfängerseite erfolgen. --- **UDP-Diagnose benötigt ein protokollspezifisches Werkzeug** Ein allgemeiner UDP-Test kann häufig nur ein Datagramm senden. Er kann nicht sicher bestimmen, ob ein beliebiger UDP-Dienst korrekt arbeitet. Geeignete Tests sind beispielsweise: | Protokoll | Geeigneter Nachweis | |---|---| | DNS | gültige DNS-Abfrage mit `Resolve-DnsName` oder `dig` | | NTP | gültige Zeitabfrage mit vorgesehenem NTP-Werkzeug | | SNMP | gültige, autorisierte SNMP-Abfrage | | TFTP | kontrollierter TFTP-Protokolltest | | Syslog | Empfang im vorgesehenen Logziel bestätigen | | RADIUS | autorisierter Test mit passendem RADIUS-Werkzeug | | QUIC/HTTP/3 | HTTP/3-fähiger Client und Serverprotokolle | | anwendungsspezifisches UDP | Herstellerclient, Testfunktion oder definierte Testnachricht | Ein zufälliges oder leeres Datagramm kann von einem korrekt funktionierenden Dienst absichtlich ignoriert werden. --- **DNS als UDP-Diagnosebeispiel** Windows: **NETZAKTIV** ```powershell Resolve-DnsName ` -Name "example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Linux und macOS: ```bash dig \ @192.0.2.53 \ example.test \ A ``` Vergleich über TCP: ```bash dig \ @192.0.2.53 \ example.test \ A \ +tcp ``` Auswertung: | UDP | TCP | Mögliche Einordnung | |---|---|---| | funktioniert | funktioniert | beide Transportwege grundsätzlich nutzbar | | fehlerhaft | funktioniert | UDP-Filterung, Fragmentierung, EDNS oder MTU möglich | | funktioniert | fehlerhaft | TCP-Port, Firewall oder TCP-Listener prüfen | | beide fehlerhaft | beide Pfade oder DNS-Dienst betroffen | Server, Zone, Routing und Firewall prüfen | Der Vergleich ist protokollspezifisch. Er darf nicht auf beliebige UDP-Dienste übertragen werden. --- **Allgemeine UDP-Porttests richtig bewerten** Ein Aufruf wie: ```bash nc -vzu 192.0.2.53 53 ``` liefert bei UDP keinen gleichwertigen Nachweis wie ein erfolgreicher TCP-Handshake. Mögliche Ergebnisse ohne Antwort: - Port ist geöffnet, aber die Anwendung ignoriert die ungültige Anfrage; - Port wird gefiltert; - Datagramm erreicht den Server nicht; - Antwort erreicht den Client nicht; - ICMP-Fehler wird gefiltert; - Zielhost ist ausgefallen; - Anwendung antwortet grundsätzlich nicht; - Werkzeug interpretiert fehlende Antwort als möglichen Erfolg. `nc -u` darf deshalb nur zum gezielten Erzeugen eines autorisierten Datagramms verwendet werden. Für die Funktionsprüfung ist ein protokollspezifischer Test erforderlich. --- **Windows: UDP-Endpunkte erfassen** **LESEND** Alle UDP-Endpunkte: ```powershell Get-NetUDPEndpoint | Sort-Object LocalPort, LocalAddress ``` Bestimmten UDP-Port prüfen: ```powershell Get-NetUDPEndpoint ` -LocalPort 53 ``` Wesentliche Felder anzeigen: ```powershell Get-NetUDPEndpoint | Select-Object ` LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort, LocalAddress ``` Zu prüfen sind: - lokale Adresse; - lokaler Port; - Prozess-ID; - IPv4 oder IPv6; - Loopback-, spezifische oder Wildcard-Bindung; - mehrere Prozesse oder Endpunkte; - unerwarteter Netzwerk-Namespace. --- **Windows: Prozess eines UDP-Endpunkts bestimmen** **LESEND** ```powershell 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 ProcessPath = $process.Path } } ``` Einen bekannten Prozess prüfen: ```powershell Get-Process ` -Id 1234 ``` Einem Windows-Dienst zuordnen: ```powershell $processId = 1234 Get-CimInstance ` -ClassName Win32_Service ` -Filter "ProcessId = $processId" | Select-Object ` Name, DisplayName, State, StartMode, ProcessId, PathName ``` --- **Windows: UDP mit netstat prüfen** **LESEND** ```cmd netstat -ano -p udp ``` Die Ausgabe zeigt unter anderem: - lokale Adresse; - lokalen Port; - Prozess-ID. UDP besitzt dabei keinen TCP-Zustand wie `LISTENING` oder `ESTABLISHED`. Numerische Darstellung ist für die erste Diagnose vorzuziehen, damit keine Namensauflösung die Ausgabe verändert oder verzögert. --- **Windows: UDP-Statistiken prüfen** **LESEND** IPv4: ```cmd netstat -s -p udp ``` IPv6: ```cmd netstat -s -p udpv6 ``` Verfügbare Leistungsindikatoren: ```powershell Get-Counter ` -ListSet "*UDP*" ``` Die Namen der Leistungsindikatoren können abhängig von Systemsprache und Windows-Version abweichen. Kumulative Zähler müssen über ein definiertes Zeitfenster verglichen werden. Ein hoher Gesamtwert seit dem Systemstart beweist keine aktuelle Störung. --- **Windows: Test-NetConnection ist kein UDP-Porttest** Dieser Befehl: ```powershell Test-NetConnection ` -ComputerName "192.0.2.53" ` -Port 53 ``` prüft TCP-Port `53`. Er prüft nicht UDP-Port `53`. Folgende Schlussfolgerung ist daher unzulässig: ```text TcpTestSucceeded = True also funktioniert UDP-Port 53. ``` Für UDP muss ein passendes Anwendungsprotokoll verwendet oder der Datenweg mit einer Paketaufzeichnung nachgewiesen werden. --- **Windows: UDP-Test mit PortQry** PortQry ist ein separat bereitzustellendes Microsoft-Diagnosewerkzeug und nicht auf jedem Windows-System vorinstalliert. **NETZAKTIV** ```cmd portqry.exe -n 192.0.2.53 -p UDP -e 53 ``` Mögliche Einordnung: | PortQry-Ergebnis | Bedeutung | |---|---| | `LISTENING` | PortQry hat eine verwertbare Protokollantwort erhalten. | | `NOT LISTENING` | PortQry hat typischerweise ICMP Port Unreachable erhalten. | | `LISTENING OR FILTERED` | Es kam keine eindeutige Antwort; geöffnet und still oder gefiltert sind nicht unterscheidbar. | Für einige bekannte Protokolle sendet PortQry speziell formatierte Anfragen. Bei beliebigen UDP-Diensten bleibt ein fehlendes Ergebnis mehrdeutig. PortQry darf nur gegen autorisierte Zielsysteme eingesetzt werden. --- **Linux: UDP-Endpunkte mit ss prüfen** **LESEND** Gebundene UDP-Endpunkte: ```bash sudo ss -lunp ``` Alle UDP-Sockets: ```bash sudo ss -uanp ``` Bestimmten lokalen Port prüfen: ```bash sudo ss -lunp \ 'sport = :53' ``` Ausgabe ohne Prozessinformationen: ```bash ss -lun ``` Wichtige Felder: - lokale Adresse; - lokaler Port; - Prozess; - Empfangswarteschlange; - Sendewarteschlange; - IPv4 oder IPv6. Prozessinformationen können erhöhte Berechtigungen erfordern. --- **Linux: Prozess mit lsof bestimmen** **LESEND** Alle UDP-Sockets: ```bash sudo lsof \ -nP \ -iUDP ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof \ -nP \ -iUDP:53 ``` Prozess prüfen: ```bash ps -fp ``` Bei systemd: ```bash systemctl status ``` Ein laufender Dienst beweist nicht, dass er den erwarteten UDP-Port im richtigen Netzwerk-Namespace gebunden hat. --- **Linux: UDP-Zähler prüfen** **LESEND** Alle Netzwerkstatistiken: ```bash nstat -az ``` Ausgewählte UDP-Zähler: ```bash nstat -az UdpInDatagrams ``` ```bash nstat -az UdpNoPorts ``` ```bash nstat -az UdpInErrors ``` ```bash nstat -az UdpRcvbufErrors ``` ```bash nstat -az UdpSndbufErrors ``` Klassische Übersicht: ```bash netstat -su ``` Schnittstellenzähler: ```bash ip -s link ``` Mögliche Hinweise: | Zähler | Mögliche Einordnung | |---|---| | `UdpInDatagrams` | empfangene und zugestellte UDP-Datagramme | | `UdpNoPorts` | Datagramme für nicht belegte UDP-Ports | | `UdpInErrors` | allgemeine UDP-Empfangsfehler | | `UdpRcvbufErrors` | Empfangspuffer konnte Datagramme nicht aufnehmen | | `UdpSndbufErrors` | Sendepufferfehler | | Schnittstellen-Drops | Verlust an oder nahe der Netzwerkschnittstelle | Die genaue Zählerverfügbarkeit hängt von Kernel und Werkzeugversion ab. --- **macOS: UDP-Endpunkte prüfen** **LESEND** ```bash sudo lsof \ -nP \ -iUDP ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof \ -nP \ -iUDP:53 ``` Socketübersicht: ```bash netstat -anv -p udp ``` UDP-Statistiken: ```bash netstat -s -p udp ``` Netzwerkschnittstellen: ```bash ifconfig ``` Interaktive Netzwerkansicht: ```bash nettop ``` `lsof` ist unter macOS für die Zuordnung eines UDP-Ports zu einem Prozess normalerweise geeigneter als `netstat`. --- **Empfangswarteschlange und Anwendungsgeschwindigkeit** Ein Datagramm kann den Host erreichen, aber verloren gehen, bevor die Anwendung es verarbeitet. Mögliche Ursachen: - Anwendung liest nicht schnell genug; - Empfangspuffer ist voll; - CPU-Überlastung; - Prozess hängt; - Workerpool ist erschöpft; - zu hohe Datagrammrate; - Datagramme sind größer als erwartet; - Kernel- oder Schnittstellenpuffer laufen über; - Container besitzt zu geringe Ressourcen; - Anwendung verwirft ungültige oder unerwartete Nachrichten. Benötigte Nachweise: - Paketaufzeichnung am Empfänger; - UDP- und Schnittstellenzähler; - Socketwarteschlange; - Prozess-CPU und Speicher; - Anwendungsprotokoll; - Rate und Größe der Datagramme; - Vergleich mit einer Baseline. Wenn ein Datagramm in der Paketaufzeichnung des Servers sichtbar ist, beweist das noch nicht, dass die Anwendung es aus dem Socket gelesen hat. --- **ICMP ist nicht nur Ping** ICMP dient zur Übertragung von Kontroll- und Fehlermeldungen für IP. Ping verwendet: - ICMP Echo Request; - ICMP Echo Reply. ICMP umfasst jedoch zusätzlich Meldungen wie: - Destination Unreachable; - Port Unreachable; - Time Exceeded; - Fragmentation Needed; - Packet Too Big; - Parameter Problem; - Redirect. ICMPv4 und ICMPv6 sind nicht identisch. Sie verwenden unterschiedliche Typen, Codes und Protokollmechanismen. Das vollständige Blockieren von ICMP kann Fehlerdiagnose und Path MTU Discovery beeinträchtigen. Bei IPv6 besitzt ICMPv6 darüber hinaus grundlegende Bedeutung für mehrere IPv6-Funktionen. --- **ICMP-Fehler einer UDP-Anfrage zuordnen** Eine ICMP-Fehlermeldung enthält Teile des Pakets, das den Fehler ausgelöst hat. Dadurch können Betriebssystem, Firewall oder Analysewerkzeug die Meldung beispielsweise folgender Kommunikation zuordnen: ```text 192.0.2.100:53124 → 192.0.2.53:53 UDP ``` Zu prüfen sind im eingebetteten ursprünglichen Paket: - ursprüngliche Quelladresse; - ursprüngliche Zieladresse; - UDP-Quellport; - UDP-Zielport; - Protokollnummer; - gegebenenfalls weitere Anwendungsdaten. Bei NAT muss auch die ICMP-Fehlermeldung korrekt zur ursprünglichen internen Kommunikation zurückübersetzt werden. --- **Häufige ICMPv4-Typen** | Typ | Bezeichnung | Typische Bedeutung | |---:|---|---| | `0` | Echo Reply | Antwort auf Echo Request | | `3` | Destination Unreachable | Ziel, Protokoll oder Port nicht erreichbar | | `5` | Redirect | Hinweis auf einen anderen nächsten Router | | `8` | Echo Request | Ping-Anfrage | | `11` | Time Exceeded | TTL abgelaufen oder Fragmentwiederherstellung zu langsam | | `12` | Parameter Problem | Fehler in einem IP-Headerfeld | ICMP Source Quench ist veraltet und darf nicht als moderner Überlastkontrollmechanismus verwendet werden. --- **ICMPv4 Destination Unreachable** ICMPv4 verwendet für Destination Unreachable den Typ `3`. | Code | Bedeutung | |---:|---| | `0` | Network Unreachable | | `1` | Host Unreachable | | `2` | Protocol Unreachable | | `3` | Port Unreachable | | `4` | Fragmentation Needed and DF Set | | `5` | Source Route Failed | | `9` | Network Administratively Prohibited | | `10` | Host Administratively Prohibited | | `13` | Communication Administratively Prohibited | Nicht jedes Gerät verwendet alle Codes. Firewalls können Fehler außerdem still verwerfen oder andere Meldungen erzeugen. --- **ICMPv4 Port Unreachable** Typischer Ablauf: ```text Client → Server: UDP-Datagramm an Port 9999 Server → Client: ICMP Destination Unreachable Type 3, Code 3 Port Unreachable ``` Mögliche Einordnung: - Zielhost wurde erreicht; - auf dem angesprochenen UDP-Port ist häufig kein passender Endpunkt vorhanden; - eine Firewall oder Zwischenkomponente kann die Meldung erzeugt haben; - NAT- oder Portweiterleitungsziel besitzt keinen passenden UDP-Dienst. Der genaue Erzeuger muss anhand von Aufzeichnungen und Protokollen bestimmt werden. --- **ICMPv4 Fragmentation Needed** Typischer Befund: ```text ICMP Type 3, Code 4 Fragmentation Needed and DF Set ``` Bedeutung: - ein IPv4-Paket ist für den nächsten Link zu groß; - das Paket darf aufgrund gesetztem DF-Bit nicht fragmentiert werden; - die Meldung kann eine verwendbare MTU enthalten; - der Sender muss die Paketgröße anpassen. Wenn diese ICMP-Meldung gefiltert wird, kann ein Path-MTU-Black-Hole entstehen: ```text kleine Datagramme funktionieren große Datagramme schlagen fehl keine verwertbare Fehlermeldung erreicht den Sender ``` --- **ICMPv4 Time Exceeded** ICMPv4 verwendet Typ `11`. | Code | Bedeutung | |---:|---| | `0` | TTL während der Weiterleitung abgelaufen | | `1` | Zeit für Fragmentwiederherstellung abgelaufen | TTL-Ablauf wird unter anderem von Traceroute verwendet, um Zwischenrouter sichtbar zu machen. Ein Stern in einer Traceroute-Ausgabe beweist nicht, dass der betreffende Router ausgefallen ist. Er kann ICMP-Antworten filtern oder begrenzen und trotzdem normalen Datenverkehr weiterleiten. --- **Häufige ICMPv6-Typen** | Typ | Bezeichnung | |---:|---| | `1` | Destination Unreachable | | `2` | Packet Too Big | | `3` | Time Exceeded | | `4` | Parameter Problem | | `128` | Echo Request | | `129` | Echo Reply | ICMPv6 enthält außerdem wichtige Mechanismen für IPv6. Es darf nicht pauschal wie optionaler Ping-Verkehr behandelt werden. --- **ICMPv6 Destination Unreachable** ICMPv6 verwendet Typ `1`. | Code | Bedeutung | |---:|---| | `0` | No Route to Destination | | `1` | Communication Administratively Prohibited | | `2` | Beyond Scope of Source Address | | `3` | Address Unreachable | | `4` | Port Unreachable | | `5` | Source Address Failed Ingress/Egress Policy | | `6` | Reject Route to Destination | Port Unreachable bei IPv6: ```text ICMPv6 Type 1, Code 4 ``` --- **ICMPv6 Packet Too Big** ICMPv6 verwendet: ```text Type 2, Code 0 ``` Die Meldung enthält die MTU des nächsten Links. IPv6-Router fragmentieren weitergeleitete Pakete nicht. Wenn ein Paket zu groß ist, muss der sendende Endpunkt seine Paketgröße anpassen oder selbst geeignete Fragmentierung verwenden. Das Blockieren von ICMPv6 Packet Too Big kann dazu führen, dass: - kleine UDP-Datagramme funktionieren; - größere Datagramme verschwinden; - Tunnel oder VPN-Pfade betroffen sind; - Anwendungen in Timeouts laufen; - die Ursache fälschlich beim UDP-Dienst gesucht wird. --- **ICMPv6 Time Exceeded** ICMPv6 verwendet Typ `3`. | Code | Bedeutung | |---:|---| | `0` | Hop Limit während der Weiterleitung abgelaufen | | `1` | Fragment Reassembly Time Exceeded | Das IPv6 Hop Limit entspricht funktional dem IPv4-TTL-Konzept. --- **ICMPv6 Parameter Problem** ICMPv6 verwendet Typ `4`. | Code | Bedeutung | |---:|---| | `0` | fehlerhaftes Headerfeld | | `1` | unbekannter Next-Header-Typ | | `2` | unbekannte IPv6-Option | Die Meldung kann auf das fehlerhafte Feld innerhalb des ursprünglichen Pakets verweisen. --- **Keine ICMP-Antwort ist mehrdeutig** Wenn auf ein UDP-Datagramm weder eine Anwendungsantwort noch eine ICMP-Fehlermeldung folgt, sind unter anderem möglich: - UDP-Port ist geöffnet, Anwendung antwortet aber nicht auf diese Anfrage; - Anfrage ist ungültig; - Anwendung antwortet grundsätzlich nicht; - Datagramm wurde unterwegs verworfen; - lokale Firewall verwirft es; - Netzwerkfirewall verwirft es; - Zielhost ist nicht erreichbar; - Antwortweg ist fehlerhaft; - ICMP wird gefiltert; - ICMP wird durch Rate Limiting unterdrückt; - NAT-Zustand fehlt; - Server ist überlastet; - Empfangspuffer ist voll; - Anwendung verwirft das Datagramm; - Paketaufzeichnung wurde am falschen Punkt durchgeführt. Das Ergebnis darf nicht ohne weiteren Nachweis als „Port offen“ oder „Port geschlossen“ dokumentiert werden. --- **ICMP Rate Limiting berücksichtigen** Hosts und Router können ICMP-Fehlermeldungen begrenzen. Folgen: - der erste Test liefert ICMP Port Unreachable; - spätere Tests liefern keine Meldung; - nur ein Teil der verlorenen Datagramme erzeugt ICMP; - ein UDP-Scan zeigt uneinheitliche Ergebnisse; - die Abwesenheit von ICMP wird fälschlich als Filterung interpretiert. Diagnosetests müssen mit geringer, kontrollierter Rate durchgeführt werden. --- **ICMP-Fehler müssen nicht die Anwendung erreichen** Ob eine Anwendung einen ICMP-Fehler wahrnimmt, hängt ab von: - Betriebssystem; - Socket-API; - verbundenem oder unverbundenem UDP-Socket; - Fehlerwarteschlange; - Anwendungscode; - NAT; - Firewall; - Zuordenbarkeit zum ursprünglichen Datagramm. Eine Anwendung kann deshalb einen Timeout melden, obwohl in einer Paketaufzeichnung eine ICMP-Fehlermeldung sichtbar ist. Umgekehrt kann das Betriebssystem einen Socketfehler melden, obwohl die Anwendung selbst keine ICMP-Pakete auswertet. --- **UDP, MTU und Fragmentierung** Ein UDP-Datagramm bleibt für die Anwendung eine einzelne Nachricht. Auf IP-Ebene kann das zugehörige Paket jedoch fragmentiert werden. Probleme großer UDP-Datagramme: - Verlust eines Fragments verwirft das gesamte Datagramm; - Firewalls verwerfen Fragmente; - NAT kann Fragmente nicht korrekt zuordnen; - Tunnel reduzieren die nutzbare Path MTU; - Fragmentwiederherstellung läuft in einen Timeout; - ICMP Fragmentation Needed oder Packet Too Big wird blockiert; - Anwendung besitzt keine geeignete Größenanpassung; - unterschiedliche Pfade besitzen unterschiedliche MTUs. Typischer Befund: ```text kleine Anfrage funktioniert kleine Antwort funktioniert große Antwort schlägt fehl über VPN tritt der Fehler häufiger auf Paketaufzeichnung zeigt Fragmente oder ICMP Packet Too Big ``` IP-Fragmentierung sollte nicht vorsorglich erzwungen werden. Die Anwendung muss geeignete Nachrichtengrößen und Path-MTU-Verfahren verwenden. --- **UDP und Checksummen diagnostizieren** Eine ungültige UDP-Prüfsumme kann dazu führen, dass ein Datagramm ohne Anwendungsantwort verworfen wird. Zu prüfen sind: - wird die Prüfsumme in der Aufzeichnung als gültig angezeigt? - stammt die Aufzeichnung vom sendenden Host? - ist Checksum Offloading aktiv? - zeigt eine externe Aufzeichnung denselben Befund? - steigen UDP-Checksum- oder Eingangsfehlerzähler? - tritt der Fehler nur auf einer Schnittstelle auf? Wie bei TCP kann eine lokal vor der Netzwerkkarte aufgenommene Prüfsumme scheinbar fehlerhaft sein, obwohl sie später durch die Hardware korrekt berechnet wird. Eine einzelne lokale Anzeige `Bad Checksum` ist deshalb kein ausreichender Fehlernachweis. --- **Unicast, Broadcast und Multicast unterscheiden** | Kommunikationsart | Ziel | |---|---| | Unicast | genau ein IP-Endpunkt | | Broadcast | alle geeigneten IPv4-Teilnehmer eines Broadcastbereichs | | Multicast | Mitglieder einer Multicastgruppe | Bei Broadcast und Multicast sind zusätzlich zu prüfen: - richtige Zieladresse; - richtige lokale Schnittstelle; - Broadcastberechtigung des Sockets; - Multicastgruppenmitgliedschaft; - IGMP bei IPv4; - MLD bei IPv6; - Switch-Snooping; - VLAN; - TTL beziehungsweise Hop Limit; - Routerunterstützung; - Firewallregeln; - Anwendung mit mehreren Schnittstellen; - erwartetes Antwortverhalten. Ein Dienst kann auf Unicast funktionieren und auf Broadcast oder Multicast dennoch fehlschlagen. IPv6 verwendet keinen Broadcast. Vergleichbare Aufgaben werden dort durch Multicastmechanismen umgesetzt. --- **Stateful Firewall und UDP** Eine Stateful Firewall kann für UDP einen temporären Zustand anhand des Datenflusses anlegen. Beispiel: ```text Client 192.0.2.100:53124 → Server 192.0.2.53:53 erwartete Antwort: Server 192.0.2.53:53 → Client 192.0.2.100:53124 ``` Zu prüfen sind: - Quell- und Zieladresse; - Quell- und Zielport; - UDP-Protokoll; - Richtung des ersten Datagramms; - Zustandstimer; - erwartete Antwortadresse; - erwarteter Antwortport; - NAT-Übersetzung; - asymmetrischer Rückweg; - Rate Limits. Wenn die Antwort erst nach Ablauf des Firewallzustands eintrifft, kann sie verworfen werden. --- **NAT und UDP** NAT kann eine interne Kommunikation wie folgt übersetzen: ```text intern: 192.0.2.100:53124 extern: 203.0.113.10:62000 Ziel: 198.51.100.53:53 ``` Die Antwort muss an die übersetzte Adresse und den übersetzten Port zurückkehren: ```text 198.51.100.53:53 → 203.0.113.10:62000 ``` Mögliche Fehler: - NAT-Zustand läuft zu früh ab; - Antwort verwendet unerwartete Quelladresse; - Antwort kommt von anderem Serverport; - asymmetrischer Rückweg umgeht die NAT-Instanz; - ICMP-Fehler wird nicht korrekt zurückübersetzt; - mehrere Clients kollidieren durch fehlerhafte Portzuordnung; - Portweiterleitung wurde nur für TCP eingerichtet; - interne und externe UDP-Ports stimmen nicht überein. TCP- und UDP-Portweiterleitungen müssen getrennt konfiguriert werden. --- **Load Balancer und UDP** Ein UDP-Load-Balancer kann Datagramme anhand des Flows einem Backend zuordnen. Zu prüfen sind: - Frontendadresse; - Frontendport; - Protokoll UDP; - Backendport; - Health-Check-Protokoll; - Flow-Hash; - Quellportverhalten; - UDP-Idle-Timeout; - Rückweg über denselben Load Balancer; - Direct Server Return; - Backendzustand; - Antwortquelladresse. Wenn ein Client bei jedem Datagramm einen anderen Quellport verwendet, kann ein Load Balancer unterschiedliche Backends auswählen. Ein erfolgreicher Health Check beweist nicht automatisch, dass der produktive UDP-Pfad funktioniert. --- **Docker: UDP-Veröffentlichung prüfen** Docker-Portveröffentlichungen müssen das Transportprotokoll berücksichtigen. Beispiel: ```text 53:53/udp ``` Ohne `/udp` wird eine Veröffentlichung typischerweise als TCP-Veröffentlichung behandelt. Laufende Container und Ports: **LESEND** ```bash docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' ``` Portzuordnung: ```bash docker port ``` Ausführliche Konfiguration: ```bash docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' ``` UDP-Endpunkt im Container: ```bash docker exec \ \ ss -lunp ``` Compose-Beispiel: ```yaml ports: - "53:53/udp" ``` Zu prüfen sind: - wurde UDP ausdrücklich veröffentlicht? - stimmt der Hostport? - stimmt der Containerport? - lauscht die Anwendung im Container? - ist sie an Loopback oder an die Containeradresse gebunden? - verwendet der Client Hostadresse oder Containeradresse? - blockiert die Hostfirewall? - existiert eine passende NAT-Regel? `EXPOSE 53/udp` im Image veröffentlicht den Port nicht automatisch auf dem Host. --- **Kubernetes: UDP-Service prüfen** Wenn `protocol` nicht angegeben wird, verwendet ein Kubernetes-Service standardmäßig TCP. Für UDP muss das Protokoll ausdrücklich passen. Beispiel: ```yaml ports: - name: dns-udp protocol: UDP port: 53 targetPort: 53 ``` Service anzeigen: ```bash kubectl get service \ \ -n \ -o yaml ``` Service beschreiben: ```bash kubectl describe service \ \ -n ``` EndpointSlices: ```bash kubectl get endpointslice \ -n \ -l kubernetes.io/service-name= \ -o wide ``` UDP-Endpunkt im Pod: ```bash kubectl exec \ -n \ \ -- ss -lunp ``` Bei mehreren Containern: ```bash kubectl exec \ -n \ \ -c \ -- ss -lunp ``` Zu prüfen sind: - `protocol: UDP`; - Service-`port`; - `targetPort`; - Pod-Endpunkt; - Service-Selektor; - EndpointSlices; - Readiness; - NetworkPolicy; - CNI-Implementierung; - NodePort oder Load Balancer; - Rückweg; - UDP-Idle-Timeout. Ein eingetragener `containerPort` erzeugt keinen UDP-Endpunkt. --- **Windows-Paketaufzeichnung mit pktmon** `pktmon` verändert den Aufzeichnungszustand und erstellt Dateien. **SENSITIV · ÄNDERND** Vorhandene Aufzeichnung stoppen: ```cmd pktmon stop ``` Vorhandene Filter entfernen: ```cmd pktmon filter remove ``` UDP-Port `53` erfassen: ```cmd pktmon filter add UDP53 -t UDP -p 53 ``` ICMPv4 ergänzen: ```cmd pktmon filter add ICMPv4 -t ICMP ``` ICMPv6 ergänzen: ```cmd pktmon filter add ICMPv6 -t ICMPV6 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\udp53.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` In PCAPNG konvertieren: ```cmd pktmon etl2pcap C:\Temp\udp53.etl --out C:\Temp\udp53.pcapng ``` Filter zurücknehmen: ```cmd pktmon filter remove ``` Das Zielverzeichnis muss vorhanden sein. Aufzeichnung, Filter und erzeugte Dateien müssen nach der Diagnose kontrolliert behandelt werden. --- **Paketaufzeichnung unter Linux** UDP und ICMP gemeinsam: **SENSITIV · LESEND** ```bash sudo tcpdump \ -ni any \ '(udp port 53) or icmp or icmp6' \ -c 200 ``` Auf bestimmte Gegenstelle begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni any \ -s 0 \ -w /tmp/udp53.pcap \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' ``` Nach reproduziertem Fehler mit `Strg+C` beenden. --- **Paketaufzeichnung unter macOS** Verfügbare Schnittstellen: ```bash tcpdump -D ``` Auf konkreter Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni en0 \ -s 0 \ -w /tmp/udp53.pcap \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' ``` Bei lokalem Verkehr muss gegebenenfalls `lo0` statt der physischen Schnittstelle verwendet werden. --- **Wireshark-Filter für UDP und ICMP** Alle UDP-Pakete: ```text udp ``` Bestimmter UDP-Port: ```text udp.port == 53 ``` Bestimmte Adresse und Port: ```text ip.addr == 192.0.2.53 && udp.port == 53 ``` ICMPv4: ```text icmp ``` ICMPv6: ```text icmpv6 ``` ICMPv4 Destination Unreachable: ```text icmp.type == 3 ``` ICMPv4 Port Unreachable: ```text icmp.type == 3 && icmp.code == 3 ``` ICMPv4 Fragmentation Needed: ```text icmp.type == 3 && icmp.code == 4 ``` ICMPv4 Time Exceeded: ```text icmp.type == 11 ``` ICMPv6 Port Unreachable: ```text icmpv6.type == 1 && icmpv6.code == 4 ``` ICMPv6 Packet Too Big: ```text icmpv6.type == 2 ``` ICMPv6 Time Exceeded: ```text icmpv6.type == 3 ``` UDP und beide ICMP-Versionen: ```text udp || icmp || icmpv6 ``` Eine ICMP-Meldung muss zusammen mit dem darin eingebetteten ursprünglichen Paket ausgewertet werden. --- **Client- und Serveraufzeichnung vergleichen** | Clientaufzeichnung | Serveraufzeichnung | Mögliche Einordnung | |---|---|---| | UDP-Anfrage sichtbar | Anfrage nicht sichtbar | Verlust oder Filterung vor dem Server | | Anfrage sichtbar | Anfrage sichtbar | Hinweg bis zum Aufzeichnungspunkt funktioniert | | keine Antwort | Anwendung protokolliert Anfrage nicht | Socket, lokaler Filter oder Anwendungsverarbeitung | | keine Antwort | Anwendung protokolliert Anfrage | Anwendung erzeugt keine oder verspätete Antwort | | Antwort verlässt Server | Antwort erreicht Client nicht | Rückweg, NAT oder Firewall | | ICMP Port Unreachable am Client | Server erzeugt ICMP | Zielport wahrscheinlich nicht gebunden | | ICMP nur am Client sichtbar | Server zeigt keine Meldung | Zwischenkomponente als Erzeuger möglich | | ICMP verlässt Server | Client erhält es nicht | Rückweg oder ICMP-Filterung | | kleine Datagramme funktionieren | große erreichen Server nicht | MTU, Fragmentierung oder Filterung | | Anfrage und Antwort sichtbar | Anwendung meldet Timeout | Socketzuordnung, Frist oder Anwendungslogik | --- **Typische UDP-Paketfolgen** **Erfolgreiche Anfrage mit Antwort** ```text Client → Server UDP-Anfrage Server → Client UDP-Antwort ``` **Geschlossener UDP-Port** ```text Client → Server UDP-Anfrage Server → Client ICMP Port Unreachable ``` **Stilles Verwerfen** ```text Client → Server UDP-Anfrage keine Antwort keine ICMP-Meldung ``` **Server verarbeitet Anfrage nicht** ```text Client → Server UDP-Anfrage Anfrage erreicht Serverschnittstelle keine Anwendungsantwort ``` **Rückwegfehler** ```text Client → Server UDP-Anfrage Server → Client UDP-Antwort Antwort erreicht Client nicht ``` **Path-MTU-Problem** ```text kleine UDP-Datagramme funktionieren großes UDP-Datagramm wird verworfen ICMP Fragmentation Needed oder Packet Too Big ``` --- **Traceroute und ICMP Time Exceeded** Traceroute nutzt schrittweise erhöhte TTL- beziehungsweise Hop-Limit-Werte. Zwischenrouter können darauf mit ICMP Time Exceeded antworten. Linux mit UDP-Probes: **NETZAKTIV** ```bash traceroute \ -U \ -p 33434 \ 192.0.2.53 ``` IPv6: ```bash traceroute \ -6 \ 2001:db8::53 ``` Die genaue Standardmethode von Traceroute hängt von Betriebssystem und Implementierung ab. Ein unvollständiger Traceroute beweist keinen vollständigen Pfadausfall. Router können: - ICMP-Antworten filtern; - Antworten begrenzen; - nur Datenverkehr weiterleiten; - für Antwort und Weiterleitung unterschiedliche Richtlinien verwenden; - auf einem asymmetrischen Rückweg antworten. --- **Hypothese und Gegenbeweis** Beispiel für einen geschlossenen UDP-Port: ```text Hypothese: Auf dem Server ist kein UDP-Endpunkt an Port 9999 gebunden. Erwarteter Befund: Die lokale Socketliste zeigt keinen UDP-Endpunkt auf Port 9999. Die Serveraufzeichnung zeigt die eingehende UDP-Anfrage. Der Server sendet ICMP Port Unreachable zurück. Gegenbeweis: Ein Prozess besitzt UDP-Port 9999 und protokolliert die eingehende Anfrage. Testmethode: Socketliste, Prozesszuordnung und korrelierte Paketaufzeichnung. Risiko: Die Anfrage erzeugt Netzwerkverkehr und muss dem erwarteten Protokoll entsprechen. ``` Beispiel für einen Rückwegfehler: ```text Hypothese: Die UDP-Antwort verlässt den Server, wird aber durch eine Firewall auf dem Rückweg verworfen. Erwarteter Befund: Die Serveraufzeichnung zeigt die ausgehende Antwort. Die Clientaufzeichnung zeigt diese Antwort nicht. Die Firewall protokolliert einen Drop für den Antwortflow. Gegenbeweis: Die Clientaufzeichnung zeigt die Antwort vollständig. Testmethode: Zeitgleiche Aufzeichnung auf Client und Server sowie Firewallprotokoll. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | UDP-Endpunkt starten oder Bindung korrigieren | fehlender Endpunkt bestätigt | geänderte Erreichbarkeit | | Firewallregel für UDP korrigieren | UDP-Drop nachgewiesen | unbeabsichtigte Freigabe | | ICMP-Regel korrigieren | benötigte Fehlermeldung wird nachweislich blockiert | zusätzliche Kontrollmeldungen werden zugelassen | | NAT-Regel um UDP ergänzen | nur TCP oder falsches Protokoll bestätigt | öffentliche Erreichbarkeit ändert sich | | UDP-Idle-Timeout abstimmen | ablaufender Sitzungszustand bestätigt | mehr Zustands- und Speicherverbrauch | | Antwortquelladresse korrigieren | falsche Quelladresse bestätigt | Routing und Dienstbindung ändern sich | | Datagrammgröße reduzieren | MTU- oder Fragmentierungsproblem bestätigt | Protokollverhalten oder Leistung ändert sich | | Receive Buffer anpassen | Pufferüberlauf nachgewiesen | höherer Speicherverbrauch | | Anwendungsgeschwindigkeit verbessern | Empfangsverlust durch Verarbeitung bestätigt | Anwendungsänderung erforderlich | | Docker-Publish auf `/udp` korrigieren | fehlende UDP-Veröffentlichung bestätigt | Container muss eventuell neu erstellt werden | | Kubernetes-Service auf UDP korrigieren | falsches Serviceprotokoll bestätigt | produktiver Servicepfad ändert sich | | Multicastmitgliedschaft korrigieren | fehlende Gruppenmitgliedschaft bestätigt | zusätzlicher Multicastempfang | | Rate Limit anpassen | legitimer Verkehr wird nachweislich begrenzt | Überlastungs- und Missbrauchsrisiko | Vor jeder Änderung sind Ausgangszustand, Risiko, Rückweg und Erfolgskriterium zu dokumentieren. --- **Systematischer Diagnoseablauf** 1. Exakte Fehlermeldung und Zeitpunkt aufnehmen. 2. Anwendung und Protokoll bestimmen. 3. Bestätigen, dass tatsächlich UDP verwendet wird. 4. Quell- und Zieladresse dokumentieren. 5. Quell- und Zielport dokumentieren. 6. IPv4 und IPv6 unterscheiden. 7. Unicast, Broadcast oder Multicast bestimmen. 8. Erwartete Anfrage und Antwort beschreiben. 9. Lokalen UDP-Endpunkt auf dem Server prüfen. 10. Besitzenden Prozess bestimmen. 11. Richtige Bindungsadresse prüfen. 12. Host-, Container- und Pod-Namespace unterscheiden. 13. Anwendungsprotokolle auf dem Server prüfen. 14. Protokollspezifischen Test vom Client durchführen. 15. UDP-Anfrage auf dem Client erfassen. 16. Prüfen, ob die Anfrage den Server erreicht. 17. Prüfen, ob die Anwendung die Anfrage verarbeitet. 18. Prüfen, ob eine Antwort erzeugt wird. 19. Prüfen, ob die Antwort den Client erreicht. 20. Quelladresse und Quellport der Antwort prüfen. 21. ICMPv4- und ICMPv6-Meldungen auswerten. 22. ICMP-Erzeuger und eingebettetes Originalpaket prüfen. 23. Stateful Firewall und UDP-Zustand prüfen. 24. NAT-Übersetzung und Rückweg prüfen. 25. Idle-Timeouts berücksichtigen. 26. UDP- und Schnittstellenzähler vergleichen. 27. Empfangspuffer und Anwendungsleistung prüfen. 28. Kleine und große gültige Datagramme vergleichen. 29. MTU, Fragmentierung und Tunnel berücksichtigen. 30. Bei Multicast Gruppenmitgliedschaft und Switch prüfen. 31. Hypothese und Gegenbeweis formulieren. 32. Genau eine kontrollierte Maßnahme durchführen. 33. Identischen Test wiederholen. 34. Anwendung und mehrere Versuche verifizieren. 35. Temporäre Aufzeichnung und Filter zurücknehmen. 36. Ursache und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein lokaler UDP-Endpunkt | Dienst fehlt oder falscher Namespace | Prozess und Dienststart prüfen | | Endpunkt nur auf Loopback | nur lokale Erreichbarkeit | Sollbindung prüfen | | Endpunkt vorhanden, Anfrage erreicht Server nicht | Netzwerk oder Firewall | Client- und Zwischenaufzeichnung | | Anfrage erreicht Server, Anwendung sieht sie nicht | Socket, Firewall oder Puffer | Prozesslog und UDP-Zähler | | Anwendung sieht Anfrage, antwortet nicht | Protokoll oder Anwendung | Anwendungslogik prüfen | | Antwort verlässt Server, erreicht Client nicht | Rückweg, NAT oder Firewall | Client- und Firewallaufzeichnung | | ICMP Port Unreachable | Zielport nicht gebunden oder aktive Ablehnung | lokale Socketliste | | ICMP Administratively Prohibited | Richtlinie blockiert | Firewall- oder Routerkonfiguration | | keine Antwort und kein ICMP | geöffnet/still oder gefiltert | serverseitige Aufzeichnung | | kleine Datagramme funktionieren | Basispfad funktioniert | größere gültige Nachricht testen | | große Datagramme scheitern | MTU, Fragmentierung oder Puffer | ICMP und Fragmente erfassen | | ICMP Fragmentation Needed | IPv4-Paket zu groß und DF gesetzt | Path MTU prüfen | | ICMPv6 Packet Too Big | IPv6-Paket überschreitet Path MTU | gemeldete MTU auswerten | | `UdpNoPorts` steigt | Datagramme erreichen ungebundene Ports | Zielport und Dienst prüfen | | `UdpRcvbufErrors` steigt | Empfangspuffer überlastet | Datenrate und Anwendung prüfen | | nur nach Inaktivität fehlerhaft | UDP-Zustand abgelaufen | Firewall-/NAT-Timeout | | neue Anfrage funktioniert sofort | alter Pseudo-Sitzungszustand fehlerhaft | Flow und Quellport vergleichen | | Docker zeigt nur TCP-Publish | UDP nicht veröffentlicht | Portkonfiguration prüfen | | Kubernetes-Service nutzt TCP | falsches Serviceprotokoll | Manifest korrigieren | | Service hat keine Endpunkte | Selektor oder Readiness | Pods und EndpointSlices | | Multicast nur auf einem Host fehlerhaft | Gruppenmitgliedschaft oder Schnittstelle | IGMP/MLD und Socket prüfen | | Wireshark zeigt Bad Checksum nur lokal | Checksum Offloading möglich | externe Aufzeichnung | | PortQry meldet `LISTENING OR FILTERED` | Ergebnis nicht eindeutig | gültiger Protokolltest und Servertrace | --- **Typische Diagnosefehler** - TCP- und UDP-Port mit derselben Nummer gleichsetzen. - `Test-NetConnection -Port` als UDP-Test verwenden. - Einen erfolgreichen Ping als UDP-Nachweis bewerten. - Einen UDP-Endpunkt als vollständigen Funktionsnachweis behandeln. - Von einem erfolgreichen send-Aufruf auf die Zustellung schließen. - `nc -u` als eindeutigen Porttest verwenden. - Eine ungültige Testnachricht an einen Dienst senden. - Aus fehlender Antwort auf einen geschlossenen oder gefilterten Port schließen. - `LISTENING OR FILTERED` als sicher geöffnet interpretieren. - ICMP ausschließlich mit Ping gleichsetzen. - Alle ICMP-Meldungen blockieren. - ICMPv4 und ICMPv6 verwechseln. - ICMP Port Unreachable nicht dem eingebetteten Paket zuordnen. - ICMP-Quelladresse ohne weiteren Nachweis als Erzeuger behandeln. - ICMP Rate Limiting ignorieren. - Nur auf dem Client aufzeichnen. - Antwortquelladresse und Antwortport nicht prüfen. - Stateful Firewallzustand bei UDP ignorieren. - UDP-Idle-Timeout nicht berücksichtigen. - TCP-Portweiterleitung als UDP-Portweiterleitung betrachten. - `/udp` bei Docker-Portveröffentlichung vergessen. - Kubernetes-`protocol` nicht prüfen. - `containerPort` als echten Endpunkt bewerten. - Container- und Host-Namespace verwechseln. - kleine und große Datagramme nicht vergleichen. - Fragmentierung und Tunnel-MTU ignorieren. - eine lokale Bad-Checksum-Anzeige ungeprüft als Fehler bewerten. - Empfangspuffer und Anwendungsleistung ignorieren. - Unicast, Broadcast und Multicast nicht unterscheiden. - Multicastgruppenmitgliedschaft nicht prüfen. - Netzwerkaufzeichnungen unbegrenzt laufen lassen. - UDP-Tests mit hoher Rate durchführen. - Firewall vorsorglich vollständig deaktivieren. - mehrere Variablen gleichzeitig verändern. - nur einen einzelnen erfolgreichen Antwortversuch verifizieren. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - der richtige UDP-Endpunkt ist vorhanden; - der richtige Prozess besitzt den Port; - richtige Bindungsadresse wird verwendet; - IPv4 funktioniert, sofern vorgesehen; - IPv6 funktioniert, sofern vorgesehen; - der Client verwendet den richtigen Zielport; - die Anfrage verlässt den Client; - die Anfrage erreicht den Server; - die Anwendung verarbeitet die Anfrage; - die Anwendung erzeugt die erwartete Antwort; - die Antwort verwendet die richtige Quelladresse; - die Antwort verwendet den richtigen Quellport; - die Antwort erreicht den Client; - keine unerwarteten ICMP-Fehler entstehen; - ICMP Fragmentation Needed oder Packet Too Big funktioniert; - kleine und repräsentativ große Datagramme funktionieren; - keine UDP-Empfangspufferfehler entstehen; - Firewallzustand bleibt ausreichend lange bestehen; - NAT übersetzt Anfrage, Antwort und ICMP korrekt; - Docker veröffentlicht ausdrücklich UDP; - Kubernetes-Service verwendet `protocol: UDP`; - `port` und `targetPort` stimmen; - EndpointSlices enthalten die vorgesehenen Pods; - Broadcast oder Multicast funktioniert, sofern erforderlich; - mehrere aufeinanderfolgende Versuche funktionieren; - ursprüngliche Anwendung funktioniert; - weitere repräsentative Clients funktionieren; - temporäre Filter wurden entfernt; - Aufzeichnungen wurden geschützt oder kontrolliert gelöscht; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne sichtbare UDP-Antwort ist keine ausreichende Verifikation für alle Clients, Paketgrößen und Netzwerkpfade. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Anwendung: Client: Server: Adressfamilie: Kommunikationsart: Quellport: Zielport: Erwartete Anfrage: Erwartete Antwort: UDP-Endpunkt: Clientaufzeichnung: Serveraufzeichnung: ICMP-Befund: Paketgröße: Fragmentierung: Firewallzustand: NAT-Zuordnung: Timeout: UDP-Zähler: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Zeitpunkt und Zeitzone erfasst - [ ] Anwendung bestimmt - [ ] UDP als Transport bestätigt - [ ] TCP und UDP unterschieden - [ ] Client und Server bestimmt - [ ] Quelladresse dokumentiert - [ ] Zieladresse dokumentiert - [ ] Quellport dokumentiert - [ ] Zielport dokumentiert - [ ] IPv4 und IPv6 unterschieden - [ ] Unicast, Broadcast oder Multicast bestimmt - [ ] erwartete Anfrage beschrieben - [ ] erwartete Antwort beschrieben - [ ] lokalen UDP-Endpunkt geprüft - [ ] Bindungsadresse geprüft - [ ] Prozessbesitzer bestimmt - [ ] Dienstzuordnung geprüft - [ ] Host-, Container- und Pod-Namespace unterschieden - [ ] protokollspezifischen Test verwendet - [ ] `Test-NetConnection` nicht als UDP-Nachweis verwendet - [ ] Clientaufzeichnung durchgeführt - [ ] Serveraufzeichnung durchgeführt - [ ] ausgehende Anfrage bestätigt - [ ] Eingang am Server bestätigt - [ ] Verarbeitung durch Anwendung bestätigt - [ ] ausgehende Antwort bestätigt - [ ] Eingang der Antwort am Client bestätigt - [ ] Antwortquelladresse geprüft - [ ] Antwortquellport geprüft - [ ] ICMPv4 geprüft - [ ] ICMPv6 geprüft - [ ] ICMP-Typ und Code dokumentiert - [ ] eingebettetes ursprüngliches Paket geprüft - [ ] ICMP-Erzeuger eingegrenzt - [ ] ICMP Rate Limiting berücksichtigt - [ ] Stateful Firewallzustand geprüft - [ ] NAT-Zuordnung geprüft - [ ] UDP-Idle-Timeout berücksichtigt - [ ] asymmetrischen Rückweg berücksichtigt - [ ] UDP-Zähler ausgewertet - [ ] Schnittstellen-Drops geprüft - [ ] Empfangspuffer geprüft - [ ] Anwendungslast geprüft - [ ] Checksum Offloading berücksichtigt - [ ] kleine Datagramme getestet - [ ] repräsentativ große Datagramme getestet - [ ] MTU berücksichtigt - [ ] Fragmentierung geprüft - [ ] ICMP Packet Too Big berücksichtigt - [ ] Docker-Protokoll bei Bedarf geprüft - [ ] Kubernetes-Serviceprotokoll bei Bedarf geprüft - [ ] EndpointSlices bei Bedarf geprüft - [ ] Multicastgruppenmitgliedschaft bei Bedarf geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Filter entfernt - [ ] Aufzeichnungen geschützt oder entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl oder Filter | |---|---| | Windows-UDP-Endpunkte | `Get-NetUDPEndpoint` | | Windows-UDP-Port | `Get-NetUDPEndpoint -LocalPort ` | | Windows-UDP-netstat | `netstat -ano -p udp` | | Windows-UDP-Statistik | `netstat -s -p udp` | | Windows-UDP-PortQry | `portqry.exe -n -p UDP -e ` | | Windows-Paketmonitor | `pktmon` | | Windows-DNS-UDP-Test | `Resolve-DnsName -Name -Server -DnsOnly` | | Linux-UDP-Endpunkte | `sudo ss -lunp` | | Linux-alle UDP-Sockets | `sudo ss -uanp` | | Linux-UDP-Port | `sudo ss -lunp 'sport = :'` | | Linux-Prozess zu UDP-Port | `sudo lsof -nP -iUDP:` | | Linux-UDP-Zähler | `nstat -az` | | Linux-Schnittstellenzähler | `ip -s link` | | macOS-UDP-Sockets | `sudo lsof -nP -iUDP` | | macOS-UDP-netstat | `netstat -anv -p udp` | | macOS-UDP-Statistik | `netstat -s -p udp` | | DNS-UDP-Test | `dig @ ` | | DNS-TCP-Vergleich | `dig @ +tcp` | | Linux-Aufzeichnung | `sudo tcpdump -ni any '(udp port ) or icmp or icmp6' -c 200` | | macOS-Aufzeichnung | `sudo tcpdump -ni '(udp port ) or icmp or icmp6' -c 200` | | Wireshark UDP-Port | `udp.port == ` | | Wireshark ICMPv4 | `icmp` | | Wireshark ICMPv6 | `icmpv6` | | ICMPv4 Port Unreachable | `icmp.type == 3 && icmp.code == 3` | | ICMPv4 Fragmentation Needed | `icmp.type == 3 && icmp.code == 4` | | ICMPv4 Time Exceeded | `icmp.type == 11` | | ICMPv6 Port Unreachable | `icmpv6.type == 1 && icmpv6.code == 4` | | ICMPv6 Packet Too Big | `icmpv6.type == 2` | | ICMPv6 Time Exceeded | `icmpv6.type == 3` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Stop-Process taskkill Stop-Service Restart-Service Set-NetFirewallRule New-NetFirewallRule Deaktivieren der Windows-Firewall netsh int ip reset netsh winsock reset kill kill -9 systemctl stop systemctl restart sysctl -w iptables nft ufw disable firewall-cmd --permanent docker restart docker stop kubectl delete kubectl rollout restart unkontrollierte UDP-Portscans UDP-Lasttests ohne Freigabe ungefilterte Broadcasts ungefilterte Multicasttests pauschales Zulassen aller ICMP-Typen vollständiges Blockieren von ICMP oder ICMPv6 willkürliche Erhöhung von Socketpuffern unkontrollierte Änderung von UDP-Idle-Timeouts ``` Ein Neustart kann Socketzustände, Zähler, NAT-Zuordnungen und den für die Diagnose wichtigen Ausgangszustand zerstören. --- **Quellen** **Standards** - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 8085 – UDP Usage Guidelines](https://datatracker.ietf.org/doc/html/rfc8085) - [RFC 1122 – Requirements for Internet Hosts – Communication Layers](https://datatracker.ietf.org/doc/html/rfc1122) - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 1812 – Requirements for IP Version 4 Routers](https://datatracker.ietf.org/doc/html/rfc1812) - [RFC 4443 – ICMPv6 for IPv6](https://datatracker.ietf.org/doc/html/rfc4443) - [RFC 8200 – Internet Protocol, Version 6 Specification](https://datatracker.ietf.org/doc/html/rfc8200) - [RFC 1191 – Path MTU Discovery](https://datatracker.ietf.org/doc/html/rfc1191) - [RFC 8201 – Path MTU Discovery for IPv6](https://datatracker.ietf.org/doc/html/rfc8201) - [RFC 4821 – Packetization Layer Path MTU Discovery](https://datatracker.ietf.org/doc/html/rfc4821) - [RFC 8899 – Datagram PLPMTUD](https://datatracker.ietf.org/doc/html/rfc8899) - [RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls](https://datatracker.ietf.org/doc/html/rfc4890) - [RFC 6633 – Deprecation of ICMP Source Quench Messages](https://datatracker.ietf.org/doc/html/rfc6633) **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – PortQry command-line tool](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – Pktmon command formatting](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) **Offizielle Linux- und Projektdokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – udp(7)](https://man7.org/linux/man-pages/man7/udp.7.html) - [Linux man-pages – icmp(7)](https://man7.org/linux/man-pages/man7/icmp.7.html) - [Linux man-pages – ipv6(7)](https://man7.org/linux/man-pages/man7/ipv6.7.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux man-pages – traceroute(8)](https://man7.org/linux/man-pages/man8/traceroute.8.html) - [ISC BIND 9 – Manual Pages und dig](https://bind9.readthedocs.io/en/stable/manpages.html) **Offizielle Wireshark-Dokumentation** - [Wireshark Display Filter Reference – UDP](https://www.wireshark.org/docs/dfref/u/udp.html) - [Wireshark Display Filter Reference – ICMP](https://www.wireshark.org/docs/dfref/i/icmp.html) - [Wireshark Display Filter Reference – ICMPv6](https://www.wireshark.org/docs/dfref/i/icmpv6.html) - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) **Offizielle Containerdokumentation** - [Docker Docs – Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) - [Docker Docs – Networking overview](https://docs.docker.com/engine/network/) - [Kubernetes – Service](https://kubernetes.io/docs/concepts/services-networking/service/) - [Kubernetes – EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.4 Lokale Host-Firewall prüfen **Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose einer lokalen Host-Firewall unter Windows, Linux und macOS sowie ihre Abgrenzung von: - fehlenden Listenern; - falschen Bindungsadressen; - Netzwerkfirewalls; - Access Control Lists; - NAT und Portweiterleitungen; - Proxys und Load Balancern; - Container- und Kubernetes-Regeln; - VPN- und Endpoint-Security-Filtern; - Anwendungsfehlern. Nach der Bearbeitung muss nachvollziehbar geprüft werden können: - welche lokale Firewalltechnik tatsächlich aktiv ist; - welches Netzwerkprofil, welche Zone oder welche Schnittstelle gilt; - welche eingehende und ausgehende Standardaktion verwendet wird; - welche Regel den betroffenen Datenverkehr erlaubt oder blockiert; - aus welcher Richtlinienquelle die wirksame Regel stammt; - ob TCP, UDP, ICMPv4 und ICMPv6 getrennt berücksichtigt wurden; - ob ein Paket den Host erreicht; - ob es durch die Host-Firewall verworfen wird; - ob ein Prozess oder Dienst trotz passender Regel nicht lauscht; - ob Container-, Hypervisor- oder Endpoint-Security-Filter beteiligt sind; - wie eine Änderung sicher vorbereitet und verifiziert wird. Eine Host-Firewall darf nicht vorsorglich vollständig deaktiviert werden. Zuerst müssen der betroffene Datenfluss und die tatsächlich wirksame Regel nachgewiesen werden. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Regeln, Adressen, Programme oder Kommunikationsbeziehungen sichtbar machen. | | **ÄNDERND** | Verändert Firewallkonfiguration oder Protokollierung. | | **AUSFALLRISIKO** | Kann bestehende Verbindungen, Verwaltung oder Dienste beeinträchtigen. | Firewallregeln und Protokolle können sicherheitsrelevante Informationen enthalten: - interne Netze; - Verwaltungsports; - erlaubte Quelladressen; - Anwendungspfade; - Dienstnamen; - Benutzer- und Gruppenbezüge; - VPN-Schnittstellen; - Sicherheitsprodukte; - Cloud- und Containerbereiche. Diese Informationen müssen geschützt gespeichert und weitergegeben werden. --- **Aufgabe einer lokalen Host-Firewall** Eine lokale Host-Firewall filtert Netzwerkverkehr direkt auf einem Endgerät oder Server. Abhängig vom Betriebssystem kann sie prüfen: - eingehenden Verkehr zum lokalen Host; - ausgehenden Verkehr des lokalen Hosts; - weitergeleiteten Verkehr; - Transportprotokoll; - lokale und entfernte Adressen; - lokale und entfernte Ports; - Netzwerkprofil oder Zone; - Schnittstelle; - Programm; - Dienst; - Benutzer; - Paket- oder Verbindungszustand; - IPsec-Authentifizierung; - Container- oder VM-Netzwerkpfade. Eine Host-Firewall ersetzt keine Netzwerkfirewall. Beide Ebenen können gleichzeitig filtern. --- **Datenpfad vereinfachen** Eingehender Datenverkehr: ```text Client → Netzwerkfirewall → Servernetzwerkschnittstelle → lokale Host-Firewall → lokaler Socket → Anwendung ``` Ausgehender Datenverkehr: ```text Anwendung → lokaler Socket → lokale Host-Firewall → Servernetzwerkschnittstelle → Netzwerkfirewall → Ziel ``` Container- oder VM-Verkehr kann zusätzlich einen Weiterleitungspfad verwenden: ```text Client → Hostnetzwerkschnittstelle → Host-Firewall oder NAT → virtuelle Bridge → Container- oder VM-Firewall → Anwendung ``` Jede Ebene muss getrennt nachgewiesen werden. --- **Host-Firewall, Listener und Anwendung unterscheiden** | Befund | Aussage | |---|---| | Dienst läuft | Prozessstatus ist vorhanden | | Listener vorhanden | Socket wurde gebunden | | lokale Verbindung funktioniert | lokaler Netzwerkpfad funktioniert | | entfernte Verbindung funktioniert | der getestete Ende-zu-Ende-Pfad funktioniert | | Firewallregel vorhanden | eine konfigurierte Regel existiert | | Firewallregel wirksam | Regel gilt für den konkreten Datenfluss | | Paket wird geloggt | Paket wurde an einem bestimmten Filterpunkt erfasst | | Anwendung antwortet | Transport und Anwendung funktionieren für den Test | Eine vorhandene Allow-Regel beweist nicht, dass: - das richtige Profil aktiv ist; - die Regel aktiviert ist; - Protokoll und Port stimmen; - die Quelladresse zum Regelbereich gehört; - das richtige Programm verwendet wird; - keine Blockregel Vorrang hat; - eine zentral verwaltete Richtlinie die Regel überschreibt; - der Dienst tatsächlich lauscht. --- **Prüfdaten des betroffenen Flows** Vor der Regelsuche muss der Datenfluss exakt dokumentiert werden. ```text Richtung: Transportprotokoll: Quelladresse: Quellport: Zieladresse: Zielport: Lokales Programm: Lokaler Dienst: Schnittstelle: Netzwerkprofil oder Zone: Zeitpunkt: ``` Ohne diese Angaben kann nicht sicher entschieden werden, ob eine Firewallregel zum Fehler passt. --- **Eingehend, ausgehend und weitergeleitet** | Richtung | Bedeutung | |---|---| | eingehend | Verkehr ist an den lokalen Host adressiert | | ausgehend | Verkehr wird durch einen lokalen Prozess erzeugt | | weitergeleitet | Verkehr durchquert den Host zu einem anderen Endpunkt | Unter Linux entsprechen diese Pfade häufig den Netfilter-Hooks beziehungsweise Basischains: ```text input output forward ``` Ein Paket für einen Container oder eine virtuelle Maschine kann den Hostpfad `forward` verwenden, obwohl der Client den Hostport anspricht. Eine Regel im lokalen `input`-Pfad muss deshalb nicht für weitergeleiteten Containerverkehr gelten. --- **Loopback ist kein vollständiger Firewalltest** Ein Test gegen: ```text 127.0.0.1 ::1 localhost ``` prüft den Loopbackpfad. Dieser Test bildet nicht zwingend ab: - die physische Netzwerkschnittstelle; - das aktive Firewallprofil; - die externe Quelladresse; - eine VPN-Schnittstelle; - NAT oder Portweiterleitung; - eine Netzwerkfirewall; - den Container-Weiterleitungspfad. Auch ein Test gegen die eigene LAN-Adresse vom selben Host kann lokal geroutet werden und muss nicht denselben Pfad wie ein entfernter Client verwenden. Für eine vollständige Prüfung ist ein repräsentativer externer Client erforderlich. --- **Firewallzustände richtig interpretieren** | Aktion | Typisches Verhalten | |---|---| | Allow oder Accept | passender Verkehr darf den Filterpunkt passieren | | Drop | Paket wird ohne aktive Fehlermeldung verworfen | | Reject | Paket wird verworfen und es kann eine Ablehnung zurückgesendet werden | | Log | Ereignis wird protokolliert; allein keine Allow- oder Blockaktion | | Default Deny | nicht ausdrücklich erlaubter Verkehr wird blockiert | | Default Allow | nicht ausdrücklich blockierter Verkehr wird erlaubt | Ein TCP-Reset kann entstehen durch: - geschlossenen TCP-Port; - Anwendung; - lokale Firewall mit Reject-Verhalten; - Netzwerkfirewall; - Proxy; - Load Balancer. Ein Timeout kann durch stilles Drop-Verhalten entstehen, beweist aber nicht automatisch eine Firewallblockierung. --- **Wirksame Richtlinie statt nur Konfigurationsdatei prüfen** Firewallregeln können stammen aus: - lokaler Konfiguration; - Gruppenrichtlinie; - MDM; - Sicherheitsbaseline; - Endpoint-Security-Software; - Cloudmanagement; - Containerplattform; - Hypervisor; - VPN-Client; - Service Manager; - temporärer Laufzeitkonfiguration. Entscheidend ist die tatsächlich aktive Richtlinie. Eine Konfigurationsdatei oder GUI kann vom wirksamen Kernelzustand abweichen, wenn: - Änderungen noch nicht geladen wurden; - Laufzeit- und permanente Konfiguration unterschiedlich sind; - eine zentrale Richtlinie Vorrang besitzt; - ein anderer Firewallmanager verwendet wird; - Containerwerkzeuge eigene Regeln erzeugt haben; - ein Sicherheitsprodukt zusätzliche Filter installiert hat. --- **Windows-Firewallprofile** Windows verwendet drei Firewallprofile: | Profil | Typische Verwendung | |---|---| | `Domain` | Netzwerk mit erkannter und authentifizierter Active-Directory-Domäne | | `Private` | als vertrauenswürdig eingestuftes privates Netzwerk | | `Public` | nicht vertrauenswürdiges oder öffentliches Netzwerk | Regeln können für ein oder mehrere Profile gelten. Ein häufiger Fehler ist: ```text Allow-Regel gilt nur für Domain oder Private. Die aktive Schnittstelle verwendet jedoch Public. ``` Windows kann unterschiedliche Profile gleichzeitig für unterschiedliche Schnittstellen verwenden. --- **Windows: aktive Netzwerkprofile prüfen** **LESEND** ```powershell Get-NetConnectionProfile | Select-Object ` InterfaceAlias, InterfaceIndex, Name, NetworkCategory, IPv4Connectivity, IPv6Connectivity ``` Zu prüfen sind: - richtige Schnittstelle; - aktive Netzwerkkategorie; - VPN-Adapter; - virtuelle Adapter; - unerwartetes `Public`-Profil; - mehrere gleichzeitig aktive Profile; - IPv4- und IPv6-Konnektivität. Das Domainprofil darf nicht manuell als Ersatz für eine fehlerhafte Domänenerkennung erzwungen werden. Zuerst müssen DNS, Erreichbarkeit, Authentifizierung und Netzwerkidentifikation geprüft werden. --- **Windows: Firewallprofile prüfen** **LESEND** ```powershell Get-NetFirewallProfile | Select-Object ` Name, Enabled, DefaultInboundAction, DefaultOutboundAction, AllowInboundRules, AllowLocalFirewallRules, AllowLocalIPsecRules, NotifyOnListen, LogFileName, LogMaxSizeKilobytes, LogAllowed, LogBlocked ``` Wirksame Profile aus dem aktiven Richtlinienspeicher: ```powershell Get-NetFirewallProfile ` -PolicyStore ActiveStore | Format-List * ``` Zu dokumentieren sind: - ist das Profil aktiviert? - welche Standardaktion gilt eingehend? - welche Standardaktion gilt ausgehend? - sind lokale Regeln zulässig? - sind lokal konfigurierte IPsec-Regeln zulässig? - werden blockierte Pakete protokolliert? - wo liegt die Protokolldatei? - welche maximale Größe besitzt sie? Die Standardaktionen dürfen nicht ungeprüft als `Block` beziehungsweise `Allow` angenommen werden. --- **Windows: aktive Regeln erfassen** **LESEND** Alle wirksamen Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ``` Aktivierte Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ``` Aktivierte eingehende Allow-Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Inbound ` -Action Allow ``` Aktivierte eingehende Blockregeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Inbound ` -Action Block ``` Aktivierte ausgehende Blockregeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Outbound ` -Action Block ``` Herkunft der Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True | Select-Object ` Name, DisplayName, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource ``` `ActiveStore` stellt die zusammengeführte aktive Richtlinie der auf das System wirkenden Policy Stores dar. Eine Abfrage ohne `-PolicyStore ActiveStore` kann eine andere Sicht liefern. --- **Windows: vollständige Regeldarstellung** **LESEND** ```powershell Show-NetFirewallRule ` -PolicyStore ActiveStore ``` Für eine bekannte Regel: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Format-List * ``` Die eigentlichen Port-, Adress-, Programm- und Dienstbedingungen werden in zugeordneten Filterobjekten verwaltet. --- **Windows: Portfilter prüfen** **LESEND** Alle Portfilter: ```powershell Get-NetFirewallPortFilter ` -PolicyStore ActiveStore ``` Regeln für lokalen Port `443` suchen: ```powershell Get-NetFirewallPortFilter ` -PolicyStore ActiveStore | Where-Object LocalPort -eq "443" | Get-NetFirewallRule | Select-Object ` Name, DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource ``` Regeln für entfernten Port `443`: ```powershell Get-NetFirewallPortFilter ` -PolicyStore ActiveStore | Where-Object RemotePort -eq "443" | Get-NetFirewallRule | Select-Object ` Name, DisplayName, Enabled, Direction, Action, Profile ``` Danach muss der vollständige Portfilter der gefundenen Regel geprüft werden: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallPortFilter | Format-List * ``` Zu prüfen sind: - TCP oder UDP; - lokaler Port; - entfernter Port; - ICMP-Typ; - dynamische Schlüsselwörter; - `Any` oder konkreter Wert. --- **Windows: Adressfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallAddressFilter | Format-List * ``` Zu prüfen sind: - `LocalAddress`; - `RemoteAddress`; - einzelne Hosts; - Subnetze; - `Any`; - lokale Subnetze; - IPv4 oder IPv6; - dynamische oder richtlinienbasierte Bereiche. Eine Allow-Regel für: ```text RemoteAddress = 192.0.2.0/24 ``` gilt nicht für einen Client aus: ```text 198.51.100.0/24 ``` --- **Windows: Programmfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallApplicationFilter | Format-List * ``` Zu prüfen sind: - vollständiger Programmpfad; - aktuell gestartete ausführbare Datei; - geänderter Installationspfad; - neue Programmversion; - 32-Bit- oder 64-Bit-Pfad; - symbolische Verknüpfungen; - Launcher und eigentlicher Serverprozess; - `Any` oder konkretes Programm. Eine Regel für einen alten Anwendungspfad gilt nicht automatisch für eine neue Programmdatei. --- **Windows: Dienstfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallServiceFilter | Format-List * ``` Zu prüfen sind: - konkreter Windows-Dienst; - Dienstname statt Anzeigename; - gemeinsam verwendeter Prozess; - Service Hardening; - `Any` oder konkreter Dienst. Eine Regel kann für einen Dienst gelten, obwohl mehrere Dienste denselben Prozess wie `svchost.exe` verwenden. --- **Windows: Schnittstellenfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallInterfaceFilter | Format-List * ``` Zu prüfen sind: - konkrete Schnittstelle; - Schnittstellentyp; - LAN; - WLAN; - Remote Access; - VPN; - virtuelle Schnittstelle. Eine Regel für LAN muss nicht für einen VPN- oder WLAN-Pfad gelten. --- **Windows: Regelbedingungen vollständig dokumentieren** Für eine gefundene Regel müssen mindestens folgende Informationen zusammengeführt werden: ```text Name: Status: Richtung: Aktion: Profile: Protokoll: Lokaler Port: Entfernter Port: Lokale Adresse: Entfernte Adresse: Programm: Dienst: Schnittstelle: Richtlinienquelle: ``` Erst der Vergleich aller Bedingungen mit dem konkreten Datenfluss zeigt, ob die Regel tatsächlich passt. --- **Windows-Regelvorrang** Für Windows-Firewallregeln gilt unter anderem: - eine ausdrücklich definierte Allow-Regel kann die eingehende Standardblockierung übersteuern; - eine ausdrücklich definierte Blockregel besitzt Vorrang vor einer widersprechenden Allow-Regel; - spezifischere Regeln können gegenüber weniger spezifischen Regeln maßgeblich sein; - zentrale Richtlinien können lokale Konfigurationsmöglichkeiten begrenzen; - Service-Hardening- und IPsec-Anforderungen können zusätzlich wirken. Windows-Firewallregeln dürfen nicht wie eine einfache von oben nach unten abgearbeitete ACL-Liste interpretiert werden. --- **Windows: Gruppenrichtlinienbezug prüfen** **LESEND** Zusammenfassung der angewendeten Computerrichtlinien: ```cmd gpresult /scope computer /r ``` Wirksame Firewallregeln enthalten zusätzlich: ```powershell PolicyStoreSourceType PolicyStoreSource ``` Zu prüfen sind: - stammt die Regel aus lokaler Konfiguration? - stammt sie aus einer Domänenrichtlinie? - dürfen lokale Firewallregeln zusammengeführt werden? - wurde die erwartete GPO angewendet? - existiert eine Blockregel aus einer anderen Richtlinie? - wird die Einstellung durch MDM verwaltet? - erscheint eine lokale Änderung nach Richtlinienaktualisierung erneut oder verschwindet sie? Eine zentral verwaltete Regel darf nicht durch eine lokale Parallelregel umgangen werden. --- **Windows: Firewallprotokoll prüfen** Der Protokollpfad kann je Profil abweichen und muss über `Get-NetFirewallProfile` bestimmt werden. Typischer Standardpfad: ```text %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log ``` Letzte Einträge: **LESEND · SENSITIV** ```powershell Get-Content ` "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" ` -Tail 100 ``` Nach Adresse oder Port suchen: ```powershell Get-Content ` "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" ` -Tail 1000 | Select-String "192.0.2.100|443" ``` Zu korrelieren sind: - Aktion; - Datum und Uhrzeit; - Protokoll; - Quell- und Zieladresse; - Quell- und Zielport; - Richtung beziehungsweise Pfad; - betroffene Schnittstelle; - identischer Testzeitpunkt. Fehlende Einträge beweisen nicht, dass die Firewall nicht beteiligt ist. Protokollierung kann deaktiviert, begrenzt oder an einem anderen Pfad konfiguriert sein. --- **Windows: temporäre Protokollierung** Vor einer Änderung müssen die vorhandenen Profilwerte dokumentiert werden. Aktuellen Zustand sichern: ```powershell Get-NetFirewallProfile | Select-Object ` Name, LogFileName, LogMaxSizeKilobytes, LogAllowed, LogBlocked ``` Blockprotokollierung für ein bestimmtes Profil aktivieren: **ÄNDERND · SENSITIV** ```powershell Set-NetFirewallProfile ` -Profile Domain ` -LogBlocked True ``` Die Änderung muss: - autorisiert sein; - auf das betroffene Profil begrenzt werden; - hinsichtlich Speicherbedarf überwacht werden; - nach dem Test auf den dokumentierten Ausgangswert zurückgesetzt werden. Das Aktivieren der Protokollierung für erlaubte Verbindungen kann sehr große Datenmengen erzeugen. --- **Windows Filtering Platform prüfen** Windows Filtering Platform, kurz WFP, bildet die Filterplattform für Windows-Firewall, IPsec und weitere Filterkomponenten. Relevante Security-Ereignisse können sein: | Ereignis-ID | Bedeutung | |---:|---| | `5152` | WFP hat ein Paket blockiert. | | `5154` | Anwendung oder Dienst durfte auf eingehende Verbindungen lauschen. | | `5155` | Anwendung oder Dienst wurde am Lauschen gehindert. | | `5156` | WFP hat eine Verbindung erlaubt. | | `5157` | WFP hat eine Verbindung blockiert. | | `5158` | Bindung an einen lokalen Port wurde erlaubt. | | `5159` | Bindung an einen lokalen Port wurde blockiert. | Blockereignisse lesen: **LESEND · SENSITIV** ```powershell Get-WinEvent ` -FilterHashtable @{ LogName = "Security" Id = 5152, 5155, 5157, 5159 } ` -MaxEvents 100 ``` Diese Ereignisse stehen nur zur Verfügung, wenn die entsprechenden Überwachungsrichtlinien aktiv waren. Zu prüfen sind: - Application Name; - Process ID; - Direction; - Source Address; - Source Port; - Destination Address; - Destination Port; - Protocol; - Filter Run-Time ID; - Layer Name; - Zeitpunkt. Sehr umfangreiche WFP-Überwachung kann viele Ereignisse erzeugen und muss gezielt eingesetzt werden. --- **Windows: netsh als ergänzende Sicht** **LESEND** Profile: ```cmd netsh advfirewall show allprofiles ``` Regeln: ```cmd netsh advfirewall firewall show rule name=all verbose ``` Überwachungszustand: ```cmd netsh advfirewall monitor show firewall ``` Der ältere Kontext: ```text netsh firewall ``` sollte nicht mehr für die aktuelle Verwaltung verwendet werden. Für moderne Systeme sind PowerShell-NetSecurity-Cmdlets und `netsh advfirewall` vorgesehen. --- **Windows: Drittanbieterfilter berücksichtigen** Verkehr kann blockiert werden, obwohl keine passende Windows-Firewall-Blockregel sichtbar ist. Mögliche zusätzliche Filter: - Endpoint Detection and Response; - Antiviren-Netzwerkfilter; - Data Loss Prevention; - VPN-Client; - Webfilter; - Network-Extension- oder WFP-Callout-Treiber; - Zero-Trust-Agent; - Hypervisorfilter; - Cloud-Sicherheitsagent. Hinweise: - Fehler beginnt nach Installation oder Update eines Sicherheitsprodukts; - WFP-Ereignis verweist auf einen fremden Filter; - Windows-Firewallprotokoll zeigt keinen Drop; - Paket erreicht die Schnittstelle, aber nicht die Anwendung; - nur ein bestimmter Prozess ist betroffen; - eine andere Anwendung auf demselben Portpfad funktioniert. Sicherheitssoftware darf nicht ohne Freigabe beendet oder deinstalliert werden. --- **Windows: Hyper-V, WSL und Container** Verkehr zu einer VM, WSL-Instanz oder einem Container kann zusätzliche Filterebenen durchlaufen. Zu unterscheiden sind: - Windows-Host-Firewall; - Hyper-V-Firewall; - virtueller Switch; - Host Network Service; - Container-NAT; - Gastbetriebssystem-Firewall; - Kubernetes- oder CNI-Regeln. Verfügbare Hyper-V-Firewall-Cmdlets prüfen: ```powershell Get-Command ` -Name "*NetFirewallHyperV*" ` -ErrorAction SilentlyContinue ``` Wenn entsprechende Cmdlets vorhanden sind, müssen Hyper-V-Profile und Regeln zusätzlich geprüft werden. Eine Allow-Regel im normalen Hostprofil beweist nicht automatisch, dass Verkehr zu einer VM oder WSL-Instanz erlaubt wird. --- **Linux: verwendetes Firewall-Backend bestimmen** Auf Linux-Systemen können mehrere Werkzeuge vorhanden sein: - nftables; - iptables-legacy; - iptables-nft; - firewalld; - UFW; - Container- oder Kuberneteskomponenten; - eBPF-, XDP- oder `tc`-Filter. Zuerst muss bestimmt werden, welches System die aktive Richtlinie verwaltet. Versionen prüfen: **LESEND** ```bash nft --version ``` ```bash iptables --version ``` Eine iptables-Ausgabe kann auf ein Backend hinweisen: ```text iptables vX.Y.Z (nf_tables) ``` oder: ```text iptables vX.Y.Z (legacy) ``` Aktive Manager: ```bash systemctl is-active firewalld ``` ```bash systemctl is-active ufw ``` Die Installation oder Aktivität eines Managers beweist nicht, dass keine weiteren Regeln existieren. --- **Linux: nftables-Regelsatz prüfen** **LESEND · SENSITIV** ```bash sudo nft list ruleset ``` Mit Regel-Handles: ```bash sudo nft -a list ruleset ``` Zu prüfen sind: - Tabellenfamilie; - Tabellenname; - Basischains; - Hook; - Priorität; - Chain Policy; - Sprünge in weitere Chains; - Regeln; - Sets; - Maps; - Protokoll; - Adressen; - Ports; - Schnittstellen; - Verbindungszustände; - Counter; - Log-Aktionen; - `accept`, `drop` oder `reject`. Wichtige Tabellenfamilien: | Familie | Bedeutung | |---|---| | `inet` | gemeinsame Verarbeitung von IPv4 und IPv6 | | `ip` | IPv4 | | `ip6` | IPv6 | | `bridge` | Bridgeverkehr | | `arp` | ARP | | `netdev` | früher Paketpfad an Netzgeräten | Eine Regel in `inet` kann sowohl IPv4 als auch IPv6 betreffen. Separate `ip`- und `ip6`-Regeln müssen getrennt geprüft werden. --- **Linux: nftables-Hooks prüfen** Typische Hooks: | Hook | Datenpfad | |---|---| | `input` | Verkehr zum lokalen Host | | `output` | lokal erzeugter Verkehr | | `forward` | weitergeleiteter Verkehr | | `prerouting` | vor der Routingentscheidung | | `postrouting` | nach der Routingentscheidung | | `ingress` | früher Eingangspfad | Der Name einer Chain muss nicht ihrem Hook entsprechen. Entscheidend ist die tatsächliche Chain-Definition. Beispiel: ```text chain host_in { type filter hook input priority filter; policy drop; } ``` Eine frei benannte Chain ohne Hook wirkt nur, wenn eine andere Regel in sie springt. --- **Linux: nftables-Counter auswerten** Regeln können Zähler für Pakete und Bytes enthalten. Beispielausgabe: ```text counter packets 42 bytes 3360 drop ``` Für einen kontrollierten Test: 1. aktuellen Zählerstand dokumentieren; 2. genau einen Test ausführen; 3. Regelsatz erneut lesen; 4. Zählerdifferenz prüfen; 5. Quelladresse, Zielport und Protokoll abgleichen. Ein unveränderter Zähler beweist nicht automatisch, dass die Regel nicht betroffen ist: - die Regel besitzt eventuell keinen Counter; - eine frühere Regel beendet die Verarbeitung; - der Datenfluss verwendet eine andere Chain; - die Aufzeichnung erfolgt in einem anderen Namespace; - ein XDP- oder `tc`-Filter verwirft früher. Zähler dürfen nicht vorsorglich zurückgesetzt werden, weil dadurch Beweisdaten verloren gehen. --- **Linux: iptables-Regeln prüfen** **LESEND · SENSITIV** IPv4: ```bash sudo iptables \ -L \ -n \ -v \ --line-numbers ``` IPv6: ```bash sudo ip6tables \ -L \ -n \ -v \ --line-numbers ``` Vollständiger IPv4-Regelsatz mit Countern: ```bash sudo iptables-save \ -c ``` Vollständiger IPv6-Regelsatz: ```bash sudo ip6tables-save \ -c ``` Wichtige Optionen: | Option | Bedeutung | |---|---| | `-L` | Chains und Regeln anzeigen | | `-n` | numerische Adressen und Ports | | `-v` | ausführliche Anzeige und Counter | | `--line-numbers` | Regelpositionen anzeigen | | `-c` bei `iptables-save` | Counter mit ausgeben | `iptables -L` allein bildet nicht immer alle Tabellen und benutzerdefinierten Zusammenhänge ausreichend ab. `iptables-save` liefert eine vollständigere Regelsatzdarstellung. --- **Linux: INPUT, OUTPUT und FORWARD unterscheiden** Typische Bedeutung: ```text INPUT: Paket ist an den Linux-Host selbst adressiert. OUTPUT: Paket wurde auf dem Linux-Host erzeugt. FORWARD: Paket wird durch den Linux-Host weitergeleitet. ``` Containerverkehr kann beispielsweise durchlaufen: ```text PREROUTING → FORWARD → POSTROUTING ``` Eine Allow-Regel in `INPUT` hilft in diesem Fall nicht zwingend. --- **Linux: firewalld-Zustand prüfen** **LESEND** Dienstzustand: ```bash firewall-cmd --state ``` Aktive Zonen und Zuordnungen: ```bash firewall-cmd --get-active-zones ``` Standardzone: ```bash firewall-cmd --get-default-zone ``` Alle Zonen: ```bash firewall-cmd --list-all-zones ``` Bestimmte aktive Zone: ```bash firewall-cmd \ --zone= \ --list-all ``` Rich Rules: ```bash firewall-cmd \ --zone= \ --list-rich-rules ``` Richtlinienobjekte: ```bash firewall-cmd --get-policies ``` ```bash firewall-cmd --list-all-policies ``` Zu prüfen sind: - welche Schnittstelle gehört zu welcher Zone? - existiert eine Quelladresszuordnung? - welche Services sind erlaubt? - welche Ports sind erlaubt? - welche Protokolle sind erlaubt? - existieren Rich Rules? - existieren ICMP-Blocks? - existieren aktive Policy Objects? - welches Zielverhalten besitzt die Zone? Die Standardzone ist nicht automatisch die tatsächlich für jede Schnittstelle wirksame Zone. --- **Linux: firewalld-Laufzeit und permanente Konfiguration** firewalld unterscheidet: | Konfiguration | Wirkung | |---|---| | Runtime | aktuell aktiv, geht ohne Übernahme bei Reload oder Neustart verloren | | Permanent | gespeichert, wird bei Reload oder Start zur Runtime-Konfiguration | Runtime-Konfiguration einer Zone: ```bash firewall-cmd \ --zone= \ --list-all ``` Permanente Konfiguration: ```bash firewall-cmd \ --permanent \ --zone= \ --list-all ``` Beide Ausgaben müssen verglichen werden. Mögliche Fehler: - Regel ist permanent gespeichert, aber noch nicht geladen; - Regel existiert nur zur Laufzeit und verschwindet nach Neustart; - Reload hat eine Diagnosefreigabe entfernt; - falsche Zone wurde geändert; - Schnittstelle wechselte die Zone; - Quelladressbindung besitzt eine andere Wirkung als erwartet. Ein `firewall-cmd --reload` ist eine Änderung und darf nicht als erster Diagnoseschritt verwendet werden. --- **Linux: bestimmten firewalld-Port prüfen** Runtime: ```bash firewall-cmd \ --zone= \ --query-port=443/tcp ``` Service: ```bash firewall-cmd \ --zone= \ --query-service=https ``` Permanent: ```bash firewall-cmd \ --permanent \ --zone= \ --query-port=443/tcp ``` Ein positives Ergebnis beweist nur, dass Port oder Service in dieser Zone konfiguriert ist. Es beweist nicht: - dass die Schnittstelle zu dieser Zone gehört; - dass keine Rich Rule blockiert; - dass der Dienst lauscht; - dass eine vorgelagerte Firewall erlaubt; - dass der Client aus dem passenden Quellbereich kommt. --- **Linux: UFW prüfen** **LESEND** Status und Standardrichtlinien: ```bash sudo ufw status verbose ``` Nummerierte Regeln: ```bash sudo ufw status numbered ``` Von UFW verwaltete hinzugefügte Regeln: ```bash sudo ufw show added ``` Vollständigere Netfilter-Sicht: ```bash sudo ufw show raw ``` Zu prüfen sind: - aktiv oder inaktiv; - eingehende Standardaktion; - ausgehende Standardaktion; - IPv4- und IPv6-Regeln; - Quelladressen; - Ports; - Protokolle; - Schnittstellen; - Reihenfolge; - gerouteter Verkehr. `ufw status` zeigt nicht zwingend alle Regeln, die außerhalb von UFW erzeugt wurden. Ein Status `inactive` beweist deshalb nicht, dass im Kernel keine anderen Netfilterregeln aktiv sind. --- **Linux: vorhandene Firewallprotokolle prüfen** Kernelmeldungen im betroffenen Zeitraum: **LESEND · SENSITIV** ```bash journalctl \ -k \ --since "15 minutes ago" ``` firewalld-Dienstmeldungen: ```bash journalctl \ -u firewalld \ --since "15 minutes ago" ``` UFW-Dienstmeldungen: ```bash journalctl \ -u ufw \ --since "15 minutes ago" ``` Zu beachten: - Dienstmeldungen sind nicht automatisch Paketlogs; - eine Regel muss eine Log-Aktion besitzen, damit sie Paketdetails erzeugt; - Logziele können Journal, Kernelringpuffer, Syslog oder NFLOG sein; - Logpräfixe müssen zum Datenfluss passen; - umfangreiche Paketprotokollierung kann Systeme und Datenträger belasten. Neue Logregeln dürfen nur gezielt, rate-limitiert und zeitlich begrenzt erstellt werden. --- **Linux: eBPF-, XDP- und tc-Filter berücksichtigen** Pakete können vor oder außerhalb der erwarteten nftables- oder iptables-Regel verworfen werden. Schnittstellendetails: ```bash ip \ -details \ link show \ dev ``` `tc`-Ingressfilter: ```bash sudo tc \ filter show \ dev \ ingress ``` `tc`-Egressfilter: ```bash sudo tc \ filter show \ dev \ egress ``` Falls `bpftool` vorhanden ist: ```bash sudo bpftool net ``` Mögliche Verursacher: - CNI-Plugin; - Kubernetes NetworkPolicy; - Sicherheitsagent; - DDoS-Schutz; - Service Mesh; - XDP-Programm; - Traffic Control; - Cloud- oder Hostingagent. Diese Filter dürfen nicht ohne Kenntnis ihres Besitzers entfernt werden. --- **macOS: zwei Firewallbereiche unterscheiden** Unter macOS müssen mindestens zwei unterschiedliche Mechanismen getrennt betrachtet werden: | Mechanismus | Aufgabe | |---|---| | Application Layer Firewall | steuert eingehende Verbindungen anhand von Apps und Diensten | | Packet Filter `pf` | paket- und regelbasierte Filterung auf Netzwerkebene | Zusätzlich können vorhanden sein: - Network Extensions; - Endpoint-Security-Produkte; - VPN-Filter; - Content Filter; - DNS-Proxy; - Drittanbieter-Firewall; - MDM-Konfigurationsprofile. Die macOS Application Firewall wird nicht primär als frei konfigurierbare Portfirewall verwaltet. Apple beschreibt sie als anwendungsbezogene Firewall. --- **macOS: Application Firewall in der Oberfläche prüfen** Aktueller Pfad: ```text Apple-Menü → Systemeinstellungen → Netzwerk → Firewall ``` Zu prüfen sind: - Firewall aktiviert oder deaktiviert; - „Alle eingehenden Verbindungen blockieren“; - Liste zugelassener und blockierter Apps; - automatisch zugelassene integrierte Software; - automatisch zugelassene signierte Software; - Tarnmodus; - MDM-Verwaltung. Die genaue Darstellung kann je nach macOS-Version und Geräteverwaltung abweichen. --- **macOS: Application Firewall im Terminal prüfen** **LESEND** Gesamtstatus: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getglobalstate ``` Block-All-Zustand: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getblockall ``` Tarnmodus: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getstealthmode ``` Anwendungsliste: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --listapps ``` Lokale Hilfe und verfügbare Optionen: ```bash /usr/libexec/ApplicationFirewall/socketfilterfw \ --help ``` Zusammenfassung über System Profiler: ```bash system_profiler SPFirewallDataType ``` Zu prüfen sind: - richtiger Anwendungspfad; - signierte oder integrierte Anwendung; - Allow- oder Blockstatus; - globales Blockieren; - MDM-Vorgabe; - geänderte App nach Update; - Launcher und tatsächlicher Listenerprozess. --- **macOS: pf-Zustand prüfen** **LESEND · SENSITIV** Status: ```bash sudo pfctl -s info ``` Filterregeln: ```bash sudo pfctl -sr ``` NAT-Regeln: ```bash sudo pfctl -sn ``` Zustandstabelle: ```bash sudo pfctl -ss ``` Gesamtübersicht: ```bash sudo pfctl -sa ``` Zu prüfen sind: - ist `pf` aktiviert? - welche Regeln und Anchors sind geladen? - existieren Block- oder Pass-Regeln? - welche Schnittstellen werden verwendet? - existieren NAT- oder Redirect-Regeln? - passt ein State zum betroffenen Datenfluss? - verwaltet ein Systemdienst oder Sicherheitsprodukt den Anchor? Apple weist darauf hin, dass Packet Filter keine unterstützte API für die Integration eigener Softwareprodukte ist. Systembestandteile können die Regeln verwalten und verändern. Die Diagnose vorhandener Zustände ist deshalb von einer dauerhaften eigenen Produktintegration zu unterscheiden. --- **macOS: Network Extensions und Sicherheitsfilter** Installierte System Extensions: **LESEND** ```bash systemextensionsctl list ``` Mögliche Filterkomponenten: - Content Filter; - Packet Tunnel; - App Proxy; - DNS Proxy; - Endpoint Security; - Hersteller-VPN; - Zero-Trust-Agent. Eine deaktivierte Application Firewall beweist nicht, dass keine Network Extension den Verkehr filtert. Sicherheits- oder VPN-Erweiterungen dürfen nicht ohne Freigabe entfernt oder deaktiviert werden. --- **Docker und Host-Firewall** Docker kann auf dem Host eigene iptables- oder nftables-Regeln erzeugen, um: - Bridge-Netzwerke zu isolieren; - veröffentlichte Ports weiterzuleiten; - NAT und Masquerading umzusetzen; - DNS-Verkehr in Netzwerk-Namespaces zu behandeln. Zu prüfen sind: ```bash docker info ``` ```bash docker network ls ``` ```bash docker ps \ --format 'table {{.Names}}\t{{.Ports}}' ``` ```bash docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' ``` Wichtige Punkte: - veröffentlichter Containerverkehr kann den Forward-Pfad verwenden; - Docker kann eigene Chains oder nftables-Tabellen erzeugen; - Docker-Regeln dürfen nicht vorsorglich gelöscht werden; - das Abschalten der Docker-Firewallverwaltung kann Containerkommunikation beschädigen; - UFW-, firewalld-, iptables- und Docker-Sichten müssen zusammen betrachtet werden; - Backend und Docker-Version müssen berücksichtigt werden. Ein freigegebener Hostport beweist nicht, dass die Anwendung im Container lauscht. --- **Kubernetes und lokale Host-Firewall** Auf einem Kubernetes-Knoten können zusätzlich wirken: - kube-proxy; - CNI-Plugin; - NetworkPolicy; - eBPF-Regeln; - NodePort; - Service; - Ingress; - Host-Firewall des Knotens; - Cloud-Sicherheitsgruppe. NetworkPolicy ist nicht dasselbe wie die allgemeine Host-Firewall. Zu prüfen sind: ```bash kubectl get networkpolicy \ --all-namespaces ``` ```bash kubectl get service \ --all-namespaces ``` ```bash kubectl get pods \ --all-namespaces \ -o wide ``` ```bash kubectl get endpointslice \ --all-namespaces ``` Bei hostnahen Problemen müssen zusätzlich CNI- und Knotenkonfiguration berücksichtigt werden. --- **TCP-Fehlerbilder einer lokalen Firewall** | Paketbefund | Mögliche Einordnung | |---|---| | SYN erreicht Host nicht | vorgelagerter Pfad oder falsche Zieladresse | | SYN erreicht Host, Firewall loggt Drop | lokale Host-Firewall bestätigt | | SYN erreicht Host, kein Listener | Betriebssystem kann RST senden | | SYN erreicht Host, Listener vorhanden, keine Antwort | lokale Filterung, Prozess oder Überlastung | | Host sendet SYN/ACK, Client erhält es nicht | ausgehender Filter oder Rückweg | | Verbindung wird sofort zurückgesetzt | Reject, fehlender Listener oder Anwendung | | lokaler Test funktioniert, externer nicht | Bindung, Profil, Host-Firewall oder Netzwerkpfad | | nur ein Quellnetz fehlerhaft | RemoteAddress- oder Zonenregel | | nur IPv6 fehlerhaft | fehlende IPv6-Regel oder ICMPv6-Problem | | nur nach VPN-Verbindung fehlerhaft | Profil-, Schnittstellen- oder VPN-Filter | --- **UDP-Fehlerbilder einer lokalen Firewall** | Paketbefund | Mögliche Einordnung | |---|---| | UDP-Anfrage erreicht Host nicht | vorgelagerter Pfad | | Anfrage erreicht Host, Drop wird geloggt | lokale Host-Firewall | | Anfrage erreicht Host und Prozess nicht | Hostfilter, Namespace oder Puffer | | Anwendung antwortet, Antwort verlässt Host nicht | ausgehende Hostfilterung | | keine Antwort und kein ICMP | geöffnet/still oder Drop | | ICMP Port Unreachable | kein passender UDP-Endpunkt oder aktive Ablehnung | | nur große Datagramme scheitern | Fragment-, MTU- oder ICMP-Filterung | | Broadcast oder Multicast scheitert | Schnittstellen-, Zonen- oder Gruppenregel | Ein allgemeiner TCP-Porttest ist kein Nachweis für UDP. --- **ICMP und ICMPv6 prüfen** Firewallregeln müssen ICMPv4 und ICMPv6 getrennt betrachten. Zu prüfen sind: - Echo Request und Echo Reply; - Destination Unreachable; - Port Unreachable; - Time Exceeded; - Fragmentation Needed; - Packet Too Big; - Parameter Problem; - notwendige IPv6-Kontrollmeldungen. Das Blockieren von Ping beweist nicht, dass TCP oder UDP blockiert wird. Umgekehrt kann Ping funktionieren, während ein TCP- oder UDP-Port blockiert ist. Das vollständige Blockieren von ICMP oder ICMPv6 kann Path MTU Discovery und Diagnose beeinträchtigen. --- **Paketaufzeichnung und Firewallprotokoll kombinieren** Eine Paketaufzeichnung allein zeigt nicht immer, ob ein Paket alle lokalen Filterstufen passiert hat. Der Aufzeichnungspunkt kann vor oder nach bestimmten Filtern liegen. Belastbarer Nachweis: 1. Testzeitpunkt genau dokumentieren. 2. Paketaufzeichnung auf dem Host starten. 3. Firewallcounter oder Protokoll erfassen. 4. Genau einen Test ausführen. 5. Listener und Prozesszustand erfassen. 6. Firewallprotokoll mit dem Flow abgleichen. 7. Paketaufzeichnung und Regelcounter vergleichen. 8. Test vom repräsentativen Client wiederholen. --- **Windows-Paketaufzeichnung mit pktmon** `pktmon` kann Paketerfassung und Drop-Erkennung innerhalb des Windows-Netzwerkstacks unterstützen. Filter zurücksetzen: **SENSITIV · ÄNDERND** ```cmd pktmon stop ``` ```cmd pktmon filter remove ``` Filter für TCP-Port `443`: ```cmd pktmon filter add TCP443 -t TCP -p 443 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\firewall443.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` Konvertieren: ```cmd pktmon etl2pcap C:\Temp\firewall443.etl --out C:\Temp\firewall443.pcapng ``` Filter entfernen: ```cmd pktmon filter remove ``` Das Zielverzeichnis muss vorhanden sein. Aufzeichnung und Filter müssen anschließend zurückgenommen werden. --- **Linux-Paketaufzeichnung** **LESEND · SENSITIV** TCP-Port `443`: ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 ``` UDP-Port `53` und ICMP: ```bash sudo tcpdump \ -ni any \ '(udp port 53) or icmp or icmp6' \ -c 200 ``` Bestimmte Schnittstelle und Gegenstelle: ```bash sudo tcpdump \ -ni \ 'host 192.0.2.100 and tcp port 443' \ -c 200 ``` Eine sichtbare eingehende Anfrage beweist, dass sie den Capturepunkt erreicht hat. Ob sie die Anwendung erreicht, muss zusätzlich mit Firewallcounter, Socket- und Anwendungsbefund geprüft werden. --- **macOS-Paketaufzeichnung** Verfügbare Schnittstellen: ```bash tcpdump -D ``` Bestimmte Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.100 and tcp port 443' \ -c 200 ``` Loopback: ```bash sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 200 ``` Application Firewall, `pf`, Network Extension und Anwendung müssen getrennt ausgewertet werden. --- **Lokalen und entfernten Test vergleichen** Windows: **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 443 ``` ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 ``` Von einem entfernten Client: ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz 127.0.0.1 443 ``` ```bash nc -vz 192.0.2.25 443 ``` Von einem entfernten Client: ```bash nc -vz app.example.test 443 ``` Auswertung: | lokaler Test | entfernter Test | Mögliche Einordnung | |---|---|---| | erfolgreich | erfolgreich | getesteter TCP-Pfad funktioniert | | erfolgreich | fehlerhaft | Bindung, Host-Firewall oder Netzwerkpfad | | fehlerhaft | fehlerhaft | Listener, Dienst, Port oder lokale Filterung | | Loopback erfolgreich, LAN-IP fehlerhaft | Bindung oder schnittstellenbezogene Regel | | IPv4 erfolgreich, IPv6 fehlerhaft | IPv6-Bindung oder IPv6-Firewall | | ohne VPN erfolgreich, mit VPN fehlerhaft | Profil-, Schnittstellen- oder VPN-Regel | --- **Host-Firewall von Netzwerkfirewall abgrenzen** | Nachweis | Einordnung | |---|---| | Paket erreicht Serverschnittstelle nicht | Problem vor dem Server | | Paket erreicht Host und Host-Firewall loggt Drop | lokale Host-Firewall bestätigt | | Paket erreicht Host, kein Drop, kein Listener | Dienst- oder Bindungsproblem | | Paket erreicht Host, Listener vorhanden, Anwendung loggt nichts | lokaler Filter, Endpoint Security oder Anwendung | | Antwort verlässt Serverschnittstelle | lokaler ausgehender Pfad wahrscheinlich passiert | | Antwort verlässt Host nicht und Outbound-Drop wird geloggt | lokale ausgehende Firewall | | Client- und Serveraufzeichnung unterscheiden sich | Verlust oder Filterung im Zwischenpfad | | anderer Server im selben Netz funktioniert | hostspezifische Konfiguration wahrscheinlich | Eine Paketaufzeichnung an nur einem Punkt reicht häufig nicht zur eindeutigen Abgrenzung. --- **Hypothese und Gegenbeweis** Beispiel: ```text Hypothese: Die aktive Windows-Firewall blockiert eingehende TCP-Verbindungen auf Port 443, weil die Allow-Regel nur für das Domainprofil gilt, die aktive Schnittstelle aber dem Public-Profil zugeordnet ist. Erwarteter Befund: Get-NetConnectionProfile zeigt Public. Die Regel gilt nur für Domain. Der lokale Listener auf Port 443 ist vorhanden. Der lokale Test funktioniert. Der entfernte Test schlägt fehl. Das Firewallprotokoll zeigt einen Drop für den Testflow. Gegenbeweis: Die Schnittstelle verwendet Domain und eine wirksame Allow-Regel passt vollständig zu Protokoll, Port, Quelladresse und Programm. Testmethode: Profil-, Regel-, Listener-, Protokoll- und Paketprüfung. Risiko: Die lesenden Prüfungen verändern den Firewallzustand nicht. ``` Linux-Beispiel: ```text Hypothese: Die Netzwerkschnittstelle befindet sich in der firewalld-Zone public, aber die Freigabe wurde in der Zone internal angelegt. Erwarteter Befund: firewall-cmd --get-active-zones ordnet die Schnittstelle public zu. Port 443 ist in public nicht erlaubt, in internal jedoch vorhanden. Der Listener existiert und ein externer Test schlägt fehl. Gegenbeweis: Die Schnittstelle ist internal zugeordnet oder eine andere wirksame Regel erlaubt den konkreten Flow. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | vorhandene passende Regel aktivieren | Regel ist geprüft und nur deaktiviert | Dienst wird erreichbar | | Profilzuordnung korrigieren | falsche Netzwerkkategorie nachgewiesen | Vertrauensniveau des Netzwerks ändert sich | | gezielte Allow-Regel erstellen | konkreter legitimer Flow bestätigt | zusätzliche Angriffsfläche | | zu breite Regel einschränken | unnötiger Geltungsbereich bestätigt | legitime Clients können ausfallen | | falsche Blockregel korrigieren | Blockregel als Ursache nachgewiesen | Schutzwirkung kann reduziert werden | | Programmpfad aktualisieren | Anwendungspfad hat sich nachweislich geändert | falsches Programm könnte freigegeben werden | | RemoteAddress-Bereich korrigieren | Quellnetz stimmt nachweislich nicht | weitere Quellen können Zugriff erhalten | | TCP-/UDP-Protokoll korrigieren | Protokollverwechslung bestätigt | zusätzlicher Transportweg wird geöffnet | | IPv6-Regel ergänzen | Dienst soll IPv6 nutzen und Block ist bestätigt | zusätzliche IPv6-Erreichbarkeit | | firewalld-Runtime und Permanent angleichen | Abweichung bestätigt | Wirkung über Neustart hinaus | | Container-Weiterleitungsregel korrigieren | Forward-Pfad bestätigt | mehrere Container können betroffen sein | | Endpoint-Security-Ausnahme beantragen | Produktfilter als Ursache bestätigt | zentrale Sicherheitswirkung | | Logging zeitlich begrenzt aktivieren | vorhandene Daten reichen nicht | Speicher- und Datenschutzrisiko | Vor jeder Änderung müssen dokumentiert werden: - genaue Regel; - Richtlinienquelle; - betroffener Flow; - Sicherheitsauswirkung; - verantwortlicher Besitzer; - Freigabe; - Ausgangszustand; - Rückweg; - Erfolgskriterium; - vorgesehenes Testverfahren. --- **Systematischer Diagnoseablauf** 1. Exakte Fehlermeldung aufnehmen. 2. Zeitpunkt und Zeitzone dokumentieren. 3. Client, Server und Anwendung bestimmen. 4. TCP, UDP, ICMPv4 oder ICMPv6 bestimmen. 5. Quell- und Zieladressen dokumentieren. 6. Quell- und Zielports dokumentieren. 7. Listener und Bindungsadresse prüfen. 8. Besitzenden Prozess bestimmen. 9. lokalen Loopbacktest durchführen. 10. konkrete lokale Schnittstellenadresse testen. 11. Test von einem repräsentativen entfernten Client durchführen. 12. Paketfluss eingehend, ausgehend oder weitergeleitet bestimmen. 13. aktive Firewalltechnik bestimmen. 14. aktives Profil, aktive Zone oder Schnittstelle bestimmen. 15. Standardaktionen prüfen. 16. wirksame Regeln erfassen. 17. Allow- und Blockregeln prüfen. 18. Protokoll- und Portfilter vergleichen. 19. Adressbereiche vergleichen. 20. Programm- und Dienstfilter vergleichen. 21. Schnittstellenfilter vergleichen. 22. Richtlinienquelle bestimmen. 23. zentrale Richtlinien und lokale Zusammenführung prüfen. 24. Firewallcounter und vorhandene Protokolle auswerten. 25. bei Bedarf zeitlich begrenzte Protokollierung aktivieren. 26. Paketaufzeichnung am Host durchführen. 27. Paketaufzeichnung mit einem zweiten Punkt vergleichen. 28. Container-, VM- und Namespacepfade berücksichtigen. 29. Endpoint Security, VPN und zusätzliche Filter berücksichtigen. 30. Hypothese und Gegenbeweis formulieren. 31. Genau eine kontrollierte Änderung durchführen. 32. identischen Test wiederholen. 33. Anwendung statt nur Porttest verifizieren. 34. weitere repräsentative Clients prüfen. 35. temporäre Protokollierung und Filter zurücknehmen. 36. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein Listener | kein Firewallproblem nachgewiesen | Dienst und Bindung prüfen | | lokaler Test funktioniert, remote nicht | Firewall, Bindung oder Netzwerkpfad | Serveraufzeichnung | | Paket erreicht Server nicht | vorgelagerter Pfad | Netzwerkfirewall und Routing | | Paket erreicht Server, Drop wird geloggt | lokale Host-Firewall | passende Regel bestimmen | | Paket erreicht Server, kein Drop, kein App-Log | Endpoint Filter oder Anwendung | Prozess- und WFP/eBPF-Befund | | Allow-Regel vorhanden, falsches Profil | Regel nicht wirksam | aktive Profilzuordnung | | Allow-Regel vorhanden, falsche Zone | Regel nicht wirksam | firewalld-Zuordnung | | Allow-Regel vorhanden, falsches Protokoll | TCP-/UDP-Verwechslung | Portfilter | | Allow-Regel vorhanden, falsche Quelladresse | Scope passt nicht | Adressfilter | | Allow-Regel vorhanden, alter Programmpfad | App-Filter passt nicht | Prozesspfad | | Blockregel und Allow-Regel treffen zu | Blockregel kann Vorrang besitzen | vollständige Regelbedingungen | | lokale Regel verschwindet | zentrale Verwaltung | PolicyStoreSource oder MDM | | UFW inaktiv, Verkehr blockiert | andere Netfilterregeln | `nft list ruleset` | | firewalld-Port permanent, nicht runtime | noch nicht wirksam | Runtime vergleichen | | firewalld-Port runtime, nicht permanent | verschwindet bei Reload | Permanent vergleichen | | nft-Counter steigt an Drop-Regel | Regel trifft den Flow | Zeit und 5-Tupel prüfen | | iptables-Counter bleibt unverändert | anderer Pfad oder Backend | nftables und Namespace prüfen | | Application Firewall erlaubt App, trotzdem blockiert | `pf`, Network Extension oder VPN | weitere Filter prüfen | | Docker-Port veröffentlicht, Hostzugriff scheitert | Forward-/Docker-Regel oder Container | Docker-Regeln und Listener | | Hostdienst funktioniert, Container nicht | Namespace oder Forward-Pfad | Container-Socket und NAT | | nur IPv6 blockiert | fehlende IPv6-Regel | `ip6`, `inet` oder ICMPv6 | | nur VPN betroffen | Schnittstellen-, Profil- oder VPN-Filter | Zustand mit und ohne VPN | | Antwort verlässt Host, Client sieht sie nicht | Problem nach dem Host | Rückweg und Netzwerkfirewall | --- **Typische Diagnosefehler** - Firewall prüfen, bevor der Listener geprüft wurde. - Dienststatus mit Listener gleichsetzen. - lokalen Loopbacktest als externen Nachweis verwenden. - nur die GUI prüfen. - persistente Konfiguration statt aktiver Richtlinie prüfen. - Windows `PersistentStore` mit `ActiveStore` verwechseln. - nur nach einer Allow-Regel suchen. - Blockregeln nicht berücksichtigen. - Windows-Regeln wie eine einfache ACL-Liste interpretieren. - aktives Windows-Profil nicht prüfen. - VPN- und virtuelle Schnittstellen ignorieren. - Programmpfad und Dienstfilter nicht prüfen. - Quelladressbereich nicht prüfen. - TCP und UDP verwechseln. - IPv4- und IPv6-Regeln nicht getrennt prüfen. - Ping als vollständigen Firewalltest verwenden. - ICMPv6 vollständig blockieren. - firewalld-Standardzone mit aktiver Zone gleichsetzen. - firewalld-Runtime und Permanent nicht vergleichen. - UFW-Status als vollständigen Netfilterzustand bewerten. - iptables und nftables unkontrolliert parallel verändern. - Chain-Hooks und Policies nicht prüfen. - Regelcounter ohne Vorher-Nachher-Vergleich bewerten. - Containerverkehr im `INPUT`- statt `FORWARD`-Pfad suchen. - Docker-Regeln vorsorglich löschen. - Kubernetes NetworkPolicy mit Host-Firewall gleichsetzen. - macOS Application Firewall mit `pf` gleichsetzen. - Network Extensions und Endpoint Security ignorieren. - Paketaufzeichnung allein als Nachweis der Firewallaktion verwenden. - Firewallprotokollierung dauerhaft und unbegrenzt aktivieren. - die Firewall vollständig deaktivieren. - Sicherheitssoftware beenden oder deinstallieren. - mehrere Regeln gleichzeitig ändern. - keine Rückfallmöglichkeit dokumentieren. - nur einen einzelnen erfolgreichen Test durchführen. - temporäre Diagnosefreigaben aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - der erwartete Listener ist vorhanden; - richtige Adresse und richtiger Port sind gebunden; - der richtige Prozess besitzt den Socket; - das richtige Firewallprofil ist aktiv; - die richtige Linux-Zone ist aktiv; - richtige Schnittstelle ist zugeordnet; - wirksame Standardaktionen entsprechen dem Sollzustand; - die vorgesehene Regel ist aktiviert; - Regelrichtung stimmt; - TCP, UDP, ICMPv4 oder ICMPv6 stimmt; - lokale und entfernte Ports stimmen; - lokale und entfernte Adressbereiche stimmen; - Programm- und Dienstfilter stimmen; - Profil- beziehungsweise Zonenumfang stimmt; - keine widersprechende Blockregel greift; - Richtlinienquelle ist dokumentiert; - lokaler Test funktioniert; - Test über die konkrete Schnittstellenadresse funktioniert; - entfernter Test funktioniert; - ursprüngliche Anwendung funktioniert; - IPv4 funktioniert, sofern vorgesehen; - IPv6 funktioniert, sofern vorgesehen; - UDP funktioniert, sofern vorgesehen; - notwendige ICMP- und ICMPv6-Meldungen funktionieren; - Container- oder VM-Pfad funktioniert; - Firewallcounter zeigen den erwarteten Pfad; - keine neuen unerwarteten Drops entstehen; - Sicherheitsumfang wurde nicht unnötig erweitert; - temporäre Regeln wurden entfernt; - temporäre Protokollierung wurde zurückgesetzt; - mehrere repräsentative Clients funktionieren; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine vollständig deaktivierte Firewall ist keine gültige Verifikation einer sicheren Lösung. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Client: Server: Anwendung: Richtung: Transportprotokoll: Quelladresse und Port: Zieladresse und Port: Listener: Schnittstelle: Firewalltechnik: Aktives Profil oder Zone: Standardaktion: Wirksame Regel: Richtlinienquelle: Portfilter: Adressfilter: Programm- oder Dienstfilter: Firewallprotokoll: Paketaufzeichnung: Zusätzliche Filter: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Sicherheitsauswirkung: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Zeitpunkt und Zeitzone erfasst - [ ] Client und Server bestimmt - [ ] Anwendung bestimmt - [ ] Prozess und Dienst bestimmt - [ ] Richtung bestimmt - [ ] TCP, UDP, ICMPv4 oder ICMPv6 bestimmt - [ ] Quelladresse erfasst - [ ] Zieladresse erfasst - [ ] Quellport erfasst - [ ] Zielport erfasst - [ ] Listener geprüft - [ ] Bindungsadresse geprüft - [ ] Prozessbesitzer geprüft - [ ] lokalen Loopbacktest durchgeführt - [ ] konkrete lokale Adresse getestet - [ ] entfernten Clienttest durchgeführt - [ ] Host-, Container- und VM-Pfad unterschieden - [ ] aktive Firewalltechnik bestimmt - [ ] Windows-Profil geprüft - [ ] Linux-Zone geprüft - [ ] Schnittstellenzuordnung geprüft - [ ] Firewallstatus geprüft - [ ] eingehende Standardaktion geprüft - [ ] ausgehende Standardaktion geprüft - [ ] wirksame aktive Regeln erfasst - [ ] Allow-Regeln geprüft - [ ] Blockregeln geprüft - [ ] Regelrichtung geprüft - [ ] Profil- oder Zonenumfang geprüft - [ ] Protokollfilter geprüft - [ ] lokalen Port geprüft - [ ] entfernten Port geprüft - [ ] lokale Adresse geprüft - [ ] entfernte Adresse geprüft - [ ] Programmpfad geprüft - [ ] Dienstfilter geprüft - [ ] Schnittstellenfilter geprüft - [ ] Richtlinienquelle bestimmt - [ ] lokale Regelzusammenführung geprüft - [ ] GPO oder MDM berücksichtigt - [ ] Firewallcounter ausgewertet - [ ] vorhandene Protokolle ausgewertet - [ ] Client- und Serverzeit korreliert - [ ] Paketaufzeichnung durchgeführt - [ ] zweiten Aufzeichnungspunkt berücksichtigt - [ ] IPv4 geprüft - [ ] IPv6 geprüft - [ ] ICMPv4 geprüft - [ ] ICMPv6 geprüft - [ ] Container-Firewallregeln berücksichtigt - [ ] Hypervisorfilter berücksichtigt - [ ] VPN-Filter berücksichtigt - [ ] Endpoint Security berücksichtigt - [ ] nftables und iptables unterschieden - [ ] firewalld-Runtime geprüft - [ ] firewalld-Permanent geprüft - [ ] UFW-Rohzustand bei Bedarf geprüft - [ ] macOS Application Firewall geprüft - [ ] macOS `pf` geprüft - [ ] macOS Network Extensions berücksichtigt - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Sicherheitsauswirkung dokumentiert - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Regel entfernt - [ ] Protokollierung zurückgesetzt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Netzwerkprofil | `Get-NetConnectionProfile` | | Windows-Firewallprofile | `Get-NetFirewallProfile` | | wirksame Windows-Regeln | `Get-NetFirewallRule -PolicyStore ActiveStore` | | aktivierte Windows-Regeln | `Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True` | | Windows-Blockregeln | `Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Action Block` | | Windows-Portfilter | `Get-NetFirewallPortFilter -PolicyStore ActiveStore` | | Windows-Adressfilter | `Get-NetFirewallAddressFilter -PolicyStore ActiveStore` | | Windows-Programmfilter | `Get-NetFirewallApplicationFilter -PolicyStore ActiveStore` | | Windows-Dienstfilter | `Get-NetFirewallServiceFilter -PolicyStore ActiveStore` | | vollständige Windows-Regeln | `Show-NetFirewallRule -PolicyStore ActiveStore` | | Windows-Firewallprotokoll | `Get-Content "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" -Tail 100` | | Windows-WFP-Blockereignisse | `Get-WinEvent -FilterHashtable @{LogName="Security"; Id=5152,5155,5157,5159}` | | Windows-netsh-Profile | `netsh advfirewall show allprofiles` | | Windows-netsh-Regeln | `netsh advfirewall firewall show rule name=all verbose` | | nftables-Regelsatz | `sudo nft list ruleset` | | nftables mit Handles | `sudo nft -a list ruleset` | | iptables-Regeln | `sudo iptables -L -n -v --line-numbers` | | IPv6-iptables | `sudo ip6tables -L -n -v --line-numbers` | | iptables-Gesamtsicht | `sudo iptables-save -c` | | firewalld-Zustand | `firewall-cmd --state` | | aktive firewalld-Zonen | `firewall-cmd --get-active-zones` | | firewalld-Zone | `firewall-cmd --zone= --list-all` | | permanente firewalld-Zone | `firewall-cmd --permanent --zone= --list-all` | | firewalld-Port prüfen | `firewall-cmd --zone= --query-port=/` | | UFW-Status | `sudo ufw status verbose` | | nummerierte UFW-Regeln | `sudo ufw status numbered` | | vollständige UFW-Sicht | `sudo ufw show raw` | | Kernelprotokoll | `journalctl -k --since "15 minutes ago"` | | macOS-Firewallstatus | `sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | macOS-App-Liste | `sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | | macOS-Firewallübersicht | `system_profiler SPFirewallDataType` | | macOS-pf-Status | `sudo pfctl -s info` | | macOS-pf-Regeln | `sudo pfctl -sr` | | macOS-pf-States | `sudo pfctl -ss` | | macOS-System-Extensions | `systemextensionsctl list` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -Port ` | | Linux/macOS-TCP-Test | `nc -vz ` | | Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 200` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Set-NetFirewallProfile -Enabled False netsh advfirewall set allprofiles state off Disable-NetFirewallRule ohne exakte Regelbegrenzung Enable-NetFirewallRule ohne exakte Regelbegrenzung Remove-NetFirewallRule New-NetFirewallRule ohne dokumentierten Scope netsh int ip reset netsh winsock reset nft flush ruleset iptables -F iptables -X ip6tables -F ufw disable ufw reset firewall-cmd --reload firewall-cmd --complete-reload systemctl stop firewalld systemctl restart firewalld pfctl -d pfctl -F all Änderung oder Entfernen von Docker-Regeln Deaktivieren der Docker-Firewallverwaltung Entfernen von Kubernetes- oder CNI-Regeln Deaktivieren eines VPN-Filters Beenden oder Deinstallieren von Endpoint Security dauerhafte ungefilterte Paketprotokollierung ``` Ein vollständiges Deaktivieren der Firewall verändert den Sicherheitszustand, kann Richtlinien verletzen und liefert keinen präzisen Nachweis darüber, welche Regel den ursprünglichen Fehler verursacht hat. --- **Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Windows Firewall overview](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/) - [Microsoft Learn – Windows Firewall rules](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules) - [Microsoft Learn – Manage Windows Firewall with the command line](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line) - [Microsoft Learn – Configure Windows Firewall logging](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging) - [Microsoft Learn – Get-NetFirewallProfile](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallprofile) - [Microsoft Learn – Get-NetFirewallRule](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallrule) - [Microsoft Learn – Show-NetFirewallRule](https://learn.microsoft.com/en-us/powershell/module/netsecurity/show-netfirewallrule) - [Microsoft Learn – Get-NetFirewallPortFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallportfilter) - [Microsoft Learn – Get-NetFirewallAddressFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewalladdressfilter) - [Microsoft Learn – Get-NetFirewallApplicationFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallapplicationfilter) - [Microsoft Learn – Get-NetFirewallServiceFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallservicefilter) - [Microsoft Learn – WFP auditing and logging](https://learn.microsoft.com/en-us/windows/win32/fwp/auditing-and-logging) - [Microsoft Learn – Event 5152](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5152) - [Microsoft Learn – Event 5157](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5157) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – netsh advfirewall](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior) **Offizielle Netfilter- und Linux-Dokumentation** - [nftables Documentation](https://wiki.nftables.org/wiki-nftables/index.php/Main_Page) - [nftables – Counters](https://wiki.nftables.org/wiki-nftables/index.php/Counters) - [Linux man-pages – nft(8)](https://man7.org/linux/man-pages/man8/nft.8.html) - [Linux man-pages – iptables(8)](https://man7.org/linux/man-pages/man8/iptables.8.html) - [Linux man-pages – iptables-save(8)](https://man7.org/linux/man-pages/man8/iptables-save.8.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) **Offizielle firewalld- und Ubuntu-Dokumentation** - [firewalld – Documentation](https://firewalld.org/documentation/) - [firewalld – firewall-cmd](https://firewalld.org/documentation/man-pages/firewall-cmd.html) - [firewalld – Runtime and permanent configuration](https://firewalld.org/documentation/man-pages/firewalld.html) - [firewalld – Zone configuration](https://firewalld.org/documentation/man-pages/firewalld.zone.html) - [firewalld – Policy Objects](https://firewalld.org/documentation/man-pages/firewalld.policies.html) - [Ubuntu Manpage – ufw(8)](https://manpages.ubuntu.com/manpages/noble/man8/ufw.8.html) **Offizielle Apple-Dokumentation** - [Apple – Change Firewall settings on Mac](https://support.apple.com/guide/mac-help/change-firewall-settings-on-mac-mh11783/mac) - [Apple – Block connections to your Mac with a firewall](https://support.apple.com/guide/mac-help/block-connections-to-your-mac-with-a-firewall-mh34041/mac) - [Apple Platform Security – Firewall security in macOS](https://support.apple.com/guide/security/firewall-security-in-macos-seca0e83763f/web) - [Apple Deployment – Firewall payload settings](https://support.apple.com/guide/deployment/firewall-payload-settings-dep8d306275f/web) - [Apple – TCP and UDP ports used by Apple software products](https://support.apple.com/en-us/103229) - [Apple Developer – Packet Filter is not API](https://developer.apple.com/documentation/technotes/tn3165-packet-filter-is-not-api) **Offizielle Containerdokumentation** - [Docker Docs – Packet filtering and firewalls](https://docs.docker.com/engine/network/packet-filtering-firewalls/) - [Docker Docs – Docker with iptables](https://docs.docker.com/engine/network/firewall-iptables/) - [Docker Docs – Docker with nftables](https://docs.docker.com/engine/network/firewall-nftables/) - [Docker Docs – Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) - [Kubernetes – Services](https://kubernetes.io/docs/concepts/services-networking/service/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection Eine Netzwerkfirewall kontrolliert den Datenverkehr zwischen Netzen, Sicherheitszonen, Standorten, Cloud-Umgebungen oder einzelnen Netzsegmenten. Eine vorhandene Freigaberegel beweist jedoch noch nicht, dass der Datenverkehr tatsächlich erlaubt wird. Entscheidend sind unter anderem: - die tatsächlich durchlaufene Firewall; - die Eingangs- und Ausgangsschnittstelle; - Quell- und Zielzone; - Quell- und Zieladresse; - Quell- und Zielport; - Protokoll; - Regelreihenfolge und Priorität; - NAT-Verarbeitung; - Routingentscheidung; - bestehender Sitzungszustand; - zusätzliche Sicherheitsprofile; - Rückweg; - Hochverfügbarkeitszustand; - verwendeter virtueller Firewallkontext; - Zeitpunkt und Konfigurationsversion. Diese Seite behandelt Netzwerkfirewalls und zentrale Netzwerk-ACLs. Die lokale Firewall eines Endgeräts oder Servers wurde bereits unter **9.4 Lokale Host-Firewall prüfen** behandelt. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - ob der betroffene Datenverkehr die vorgesehene Firewall durchläuft; - welche Regel tatsächlich angewendet wird; - ob eine allgemeinere Regel eine spezifische Regel überschattet; - ob ein implizites Verbot greift; - ob die Firewall zustandsbehaftet oder zustandslos arbeitet; - ob eine vorhandene Sitzung den aktuellen Test beeinflusst; - ob der Rückverkehr einer bestehenden Sitzung zugeordnet wird; - ob NAT, Routing oder Zonenwahl die Regelzuordnung verändern; - ob ein Sicherheitsprofil trotz erlaubender Netzwerkregel blockiert; - ob die Störung an der Firewall oder an einem anderen Netzabschnitt liegt; - wie eine Änderung kontrolliert und anschließend verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Eine Netzwerkfirewall ist häufig ein zentraler Sicherheits- und Verfügbarkeitsbestandteil. Unkontrollierte Änderungen können viele Systeme gleichzeitig betreffen. Vor jeder Änderung sind mindestens festzuhalten: - betroffene Anwendung; - Quelle und Ziel; - benötigtes Protokoll; - benötigte Ports; - Datenflussrichtung; - betroffene Sicherheitszonen; - aktuell passende Regel; - aktuelle Konfigurationsversion; - zuständige Freigabe; - Risiko; - Rückweg; - Erfolgskriterium; - vorgesehenes Testverfahren; - Wartungs- oder Änderungsfenster. Nicht als erste Diagnosemaßnahme geeignet sind: - Firewall deaktivieren; - eine allgemeine `any`-zu-`any`-Freigabe erstellen; - Regelwerk vollständig neu laden; - produktive Regeln ungeprüft verschieben; - Sitzungs- oder Verbindungstabellen vollständig löschen; - NAT-Tabellen vollständig leeren; - Hochverfügbarkeitsumschaltung erzwingen; - Sicherheitsprofile pauschal deaktivieren; - Intrusion Prevention abschalten; - TLS-Inspektion global ausschalten; - Paketfilterung durch eine direkte Umgehungsroute umgehen; - Firewall oder Cluster vorsorglich neu starten; - Zähler vor der Beweissicherung zurücksetzen. Eine kurzfristige Testregel muss genauso präzise wie eine dauerhafte Regel begrenzt werden. Sie benötigt: - eindeutigen Namen; - dokumentierten Zweck; - exakte Quelle; - exaktes Ziel; - erforderliches Protokoll; - erforderlichen Zielport; - Protokollierung; - verantwortliche Person; - Ablaufzeitpunkt; - dokumentierte Entfernung. --- **Netzwerkfirewall und Host-Firewall unterscheiden** | Merkmal | Netzwerkfirewall | Host-Firewall | |---|---|---| | Standort | zwischen Netzen oder Sicherheitszonen | direkt auf dem Endgerät oder Server | | Sichtbarer Datenverkehr | nur Verkehr, der die Firewall tatsächlich durchläuft | ein- und ausgehender Verkehr des lokalen Systems | | Typische Regeln | Zonen, Netze, Adressen, Dienste, Anwendungen | Programme, Dienste, Profile, lokale Ports, Benutzer | | Zustandsverwaltung | zentrale Sitzungstabelle | lokale Verbindungstabelle | | Protokollierung | zentrale Firewall- und Sicherheitsprotokolle | lokales Betriebssystemprotokoll | | Häufige Fehlerquelle | falsche Zone, Regelreihenfolge, NAT, Route, Sitzung | falsches Profil, Dienstregel, Programmpfad | | Umgehungsmöglichkeit | lokales Routing oder direkter Pfad zwischen Systemen | normalerweise nicht für lokalen Netzwerkverkehr | Eine Netzwerkfirewall kann nur Datenverkehr prüfen, der tatsächlich über sie geleitet wird. Befinden sich Quelle und Ziel beispielsweise im selben VLAN, kann der Verkehr die zentrale Firewall vollständig umgehen. --- **Vereinfachter Datenfluss** Ein typischer Datenfluss kann folgende Verarbeitungsschritte enthalten: 1. Paket trifft auf einer Eingangsschnittstelle ein. 2. Eingangszone oder Sicherheitskontext wird bestimmt. 3. Vorhandene Sitzung wird gesucht. 4. NAT- und Routingregeln werden ausgewertet. 5. Ausgangsschnittstelle und Ausgangszone werden bestimmt. 6. Sicherheitsregel wird ermittelt. 7. Zusätzliche Prüfungen werden ausgeführt. 8. Paket wird weitergeleitet oder verworfen. 9. Eine neue Sitzung wird angelegt oder eine vorhandene aktualisiert. 10. Rückverkehr wird einer Sitzung zugeordnet. 11. Ereignisse, Zähler und Sitzungsdaten werden protokolliert. Die genaue Reihenfolge von NAT, Routing, Sicherheitsrichtlinie, Anwendungserkennung und Inhaltsprüfung ist produktspezifisch. Sie muss für das eingesetzte Firewallprodukt und die verwendete Softwareversion geprüft werden. --- **Einen Datenfluss eindeutig beschreiben** Vor der Regelprüfung muss der betroffene Datenfluss vollständig beschrieben werden. Beispiel: ```text Zeitpunkt: 2026-08-02 10:15:32 Europe/Berlin Quelle: 192.0.2.100 Quellzone: CLIENTS Quellport: 53124 Ziel: 198.51.100.25 Zielzone: SERVER Zielport: 443 Protokoll: TCP Anwendung: HTTPS-Zugriff auf app.example.test Erwarteter Pfad: CLIENTS -> FW-CLUSTER-01 -> SERVER Erwartete Regel: ALLOW-CLIENTS-APP-HTTPS Erwartete NAT-Verarbeitung: keine ``` Bei TCP und UDP wird ein Datenfluss typischerweise über das Fünf-Tupel beschrieben: ```text Quelladresse Quellport Zieladresse Zielport IP-Protokoll ``` Für die Firewalldiagnose kommen weitere Merkmale hinzu: - Eingangsschnittstelle; - Ausgangsschnittstelle; - Quellzone; - Zielzone; - Mandant oder virtueller Kontext; - Benutzeridentität; - erkannte Anwendung; - NAT-Adressen und NAT-Ports; - Zeitplan; - Sicherheitsprofil; - VPN- oder Tunnelzuordnung; - Regel-ID; - Sitzungs-ID. --- **Quellport und Zielport nicht verwechseln** Bei einer üblichen Clientverbindung verwendet der Client einen dynamischen Quellport und der Server einen bekannten Zielport. Beispiel: ```text 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` Dabei gilt: | Feld | Bedeutung | |---|---| | `192.0.2.100` | Clientadresse | | `53124` | dynamischer Quellport des Clients | | `198.51.100.25` | Serveradresse | | `443` | Zielport des HTTPS-Dienstes | Eine Freigabe, die irrtümlich den Quellport `443` statt des Zielports `443` prüft, passt normalerweise nicht auf diesen Verbindungsaufbau. Der Rückverkehr besitzt vertauschte Adressen und Ports: ```text 198.51.100.25:443 -> 192.0.2.100:53124/TCP ``` Bei einer zustandsbehafteten Firewall wird dieser Rückverkehr üblicherweise über den bestehenden Sitzungszustand erlaubt. Bei einer zustandslosen ACL muss der Rückverkehr ausdrücklich berücksichtigt werden. --- **Eingehend und ausgehend richtig einordnen** `Inbound`, `ingress`, `outbound` und `egress` beziehen sich auf eine bestimmte Schnittstelle, Zone oder Ressource. Die Begriffe dürfen nicht ohne diesen Bezug verwendet werden. Beispiel: ```text Clientnetz -> Firewall -> Servernetz ``` Aus Sicht der Firewall: - auf der Client-Schnittstelle trifft der Verbindungsaufbau eingehend ein; - zur Server-Schnittstelle verlässt er die Firewall ausgehend; - der Rückverkehr trifft auf der Server-Schnittstelle eingehend ein; - zum Clientnetz verlässt er die Firewall ausgehend. Bei Cloud-ACLs kann sich `inbound` oder `outbound` auf ein Subnetz, eine Netzwerkschnittstelle oder eine virtuelle Maschine beziehen. Deshalb müssen Ressource und Richtung immer gemeinsam dokumentiert werden. --- **Arten der Filterung** | Verfahren | Auswertung | Sitzungszustand | Typische Eigenschaft | |---|---|---:|---| | zustandslose ACL | jedes Paket einzeln | nein | Rückverkehr benötigt eigene passende Regel | | Stateful Inspection | Paket und bestehende Sitzung | ja | Rückverkehr bestehender Sitzungen wird zugeordnet | | Proxy-Firewall | beendet und vermittelt die Verbindung | ja | Client und Ziel kommunizieren nicht direkt miteinander | | Application Firewall | Anwendung oder Protokollinhalt | ja | Entscheidung kann von erkannter Anwendung abhängen | | Next-Generation Firewall | Netzwerk-, Sitzungs-, Benutzer- und Anwendungsdaten | ja | zusätzliche URL-, Malware-, IPS- oder TLS-Prüfung | | Cloud Security Group | ressourcenbezogene Regeln | häufig ja | Verhalten unterscheidet sich von Subnetz-ACLs | | Cloud Network ACL | subnetzbezogene Paketfilterung | häufig nein | Priorität und Rückregeln sind besonders wichtig | Die Produktbezeichnung allein reicht nicht zur Bewertung. Es muss geprüft werden, welche Regelkomponente den betroffenen Datenfluss tatsächlich verarbeitet. --- **ACL-Reihenfolge** Viele Netzwerkfirewalls und Router prüfen Regeln in einer definierten Reihenfolge. Häufig gilt: 1. Regeln werden von oben nach unten oder nach Priorität geprüft. 2. Die erste vollständig passende Regel bestimmt die Aktion. 3. Nach einem Treffer werden nachfolgende Regeln nicht mehr geprüft. 4. Trifft keine Regel zu, greift häufig eine implizite Standardaktion. Dieses Verhalten ist verbreitet, aber nicht für jedes Produkt und jede Regelart identisch. Zu prüfen sind: - globale Regeln; - lokale Regeln; - geerbte Regeln; - Schnittstellen-ACLs; - Zonenregeln; - Vorregeln und Nachregeln; - Parent- und Child-Policies; - Regelgruppen; - Sicherheitsprofile; - herstellerspezifische Ausnahme- und Standardregeln. --- **Beispiel für eine sinnvolle Reihenfolge** Anforderung: - Host `192.0.2.66` darf den Server nicht erreichen. - Andere Clients aus `192.0.2.0/24` dürfen HTTPS verwenden. - Nicht ausdrücklich erlaubter Verkehr wird protokolliert verworfen. Vereinfachte Regelreihenfolge: ```text 10 deny tcp 192.0.2.66/32 -> 198.51.100.25/32 port 443 log 20 permit tcp 192.0.2.0/24 -> 198.51.100.25/32 port 443 log 90 deny ip any -> any log ``` Die spezifische Sperre steht vor der allgemeineren Freigabe. Fehlerhafte Reihenfolge: ```text 10 permit tcp 192.0.2.0/24 -> 198.51.100.25/32 port 443 log 20 deny tcp 192.0.2.66/32 -> 198.51.100.25/32 port 443 log 90 deny ip any -> any log ``` Wenn das Produkt nach dem ersten Treffer beendet, wird Host `192.0.2.66` bereits durch Regel `10` erlaubt. Regel `20` ist für diesen Datenfluss nicht erreichbar. --- **Überschattete, redundante und widersprüchliche Regeln** | Regelproblem | Beschreibung | Auswirkung | |---|---|---| | überschattete Regel | frühere allgemeinere Regel deckt alle Treffer der späteren Regel ab | spätere Regel wird nie verwendet | | teilweise überschattete Regel | frühere Regel deckt einen Teil des späteren Bereichs ab | Regel wirkt nur für den verbleibenden Teil | | redundante Regel | Regel erlaubt oder verbietet bereits identisch behandelten Verkehr | unnötige Komplexität | | widersprüchliche Regel | gleiche oder überlappende Kriterien besitzen andere Aktion | Ergebnis hängt von Reihenfolge ab | | veraltete Regel | zugehöriger Dienst oder Eigentümer existiert nicht mehr | unnötige Angriffsfläche | | ungebundene ACL | ACL ist definiert, aber keiner Schnittstelle oder Zone zugeordnet | keine Wirkung | | falscher Kontext | Regel liegt in anderem Mandanten oder virtuellen System | keine Wirkung auf den betroffenen Verkehr | | falsche Richtung | Regel ist für Gegenrichtung angelegt | erwarteter Verbindungsaufbau bleibt blockiert | | falsche Adressphase | Regel verwendet falsche NAT-Adresse | kein Treffer | | falsche Regelart | Netzwerkregel statt Anwendungsregel oder umgekehrt | unerwartete Verarbeitung | Regelanalysen des Herstellers können bei der Erkennung helfen. Das Ergebnis muss trotzdem mit realen Trefferzählern, Protokollen und einem kontrollierten Verbindungstest bestätigt werden. --- **Implizite Standardaktion** Viele ACL- und Firewallregelwerke besitzen am Ende eine implizite Verweigerung. Diese Regel ist möglicherweise nicht als normale Konfigurationszeile sichtbar. Vereinfachtes Modell: ```text permit deny deny any any ``` Ein explizites abschließendes Verbot mit Protokollierung kann die Diagnose erleichtern: ```text deny any any log ``` Ob eine solche Regel sinnvoll und zulässig ist, hängt vom Produkt und der Protokollierungsleistung ab. Eine stark ausgelastete abschließende Protokollregel kann sehr viele Ereignisse erzeugen. Zu prüfen sind: - existiert eine implizite Verweigerung? - welche Regelart besitzt sie? - gilt sie pro Schnittstelle, Zone, Regelgruppe oder Kontext? - wird ein Treffer protokolliert? - existieren Ausnahmen für System- oder Verwaltungsverkehr? - greifen vorher noch globale oder geerbte Regeln? - existiert eine vom Hersteller bereitgestellte Standardregel? Ein fehlender sichtbarer `deny`-Eintrag beweist nicht, dass nicht passender Verkehr erlaubt wird. --- **Regelkriterien vollständig prüfen** Eine moderne Firewall kann deutlich mehr als nur IP-Adresse und Port auswerten. | Kriterium | Zu prüfender Punkt | |---|---| | Quellzone | stimmt die Zone der tatsächlichen Eingangsschnittstelle? | | Zielzone | entspricht sie der durch Routing bestimmten Ausgangszone? | | Quelladresse | Originaladresse, NAT-Adresse oder Adressobjekt? | | Zieladresse | Originalziel oder übersetztes Ziel? | | Quellport | dynamischer Port oder fest definierter Dienstport? | | Zielport | tatsächlich verwendeter Dienstport? | | Protokoll | TCP, UDP, ICMP, ESP, GRE oder anderes IP-Protokoll? | | Anwendung | bereits erkannt, noch unbekannt oder verschlüsselt? | | Dienst | fest definierter Port oder anwendungsabhängiger Standardport? | | Benutzer | konnte die Firewall die Identität ermitteln? | | Gerät | passt die Geräte- oder Endpunktklassifizierung? | | Zeitplan | ist die Regel zum Fehlerzeitpunkt aktiv? | | URL-Kategorie | wird das Ziel einer anderen Kategorie zugeordnet? | | FQDN-Objekt | auf welche Adressen wurde der Name aufgelöst? | | Sicherheitsprofil | Malware-, IPS-, Datei- oder URL-Prüfung aktiv? | | Mandant | richtiger virtueller Router oder Firewallkontext? | | VPN | gilt eine zusätzliche VPN- oder Tunnelregel? | Eine Regel kann auf Netzwerkebene `allow` ergeben und anschließend trotzdem durch ein Sicherheitsprofil blockiert werden. --- **Adress- und Dienstobjekte prüfen** Regeln verwenden häufig Objekte statt direkt eingetragener IP-Adressen und Ports. Zu prüfen sind: - aktueller Objektinhalt; - CIDR-Präfix; - IPv4- oder IPv6-Zuordnung; - einzelne Adresse oder gesamtes Netz; - verschachtelte Objektgruppen; - doppelte Gruppenmitgliedschaften; - dynamische Gruppen; - Cloud-Tags; - FQDN-Auflösung; - Aktualisierungszeitpunkt; - Portbereich; - TCP- oder UDP-Zuordnung; - deaktivierte oder abgelaufene Objekte; - Synchronisation zwischen Clusterknoten. Beispiel für eine häufige Netzmaskenverwechslung: ```text 192.0.2.0/24 ``` umfasst: ```text 192.0.2.0 bis 192.0.2.255 ``` Dagegen umfasst: ```text 192.0.2.100/32 ``` nur die einzelne Adresse: ```text 192.0.2.100 ``` Bei Produkten mit Wildcard-Masken ist die Schreibweise nicht mit einer normalen Subnetzmaske gleichzusetzen. --- **FQDN- und dynamische Objekte** Ein FQDN-Objekt kann von der Firewall regelmäßig in eine oder mehrere IP-Adressen aufgelöst werden. Zu prüfen sind: - welcher DNS-Server von der Firewall verwendet wird; - ob die DNS-Auflösung erfolgreich ist; - welche A- und AAAA-Adressen gespeichert sind; - TTL und Aktualisierungszeitpunkt; - unterschiedliche Antworten durch Geo-DNS oder CDN; - Erreichbarkeit über IPv4 und IPv6; - maximale Anzahl unterstützter Adressen; - Verhalten bei fehlgeschlagener Aktualisierung; - Synchronisation im Cluster. Ein Client und eine Firewall können denselben FQDN zu unterschiedlichen Zieladressen auflösen. Dann kann eine scheinbar passende FQDN-Regel den tatsächlichen Clientverkehr verfehlen. --- **Stateful Inspection** Eine zustandsbehaftete Firewall bewertet nicht jedes Paket vollständig unabhängig. Sie führt eine Sitzungstabelle und ordnet weitere Pakete einem bekannten Datenfluss zu. Vereinfachter TCP-Ablauf: 1. Client sendet `SYN`. 2. Firewall findet keine vorhandene Sitzung. 3. Firewall prüft Route, Zone, NAT und Richtlinie. 4. Bei Erlaubnis wird ein Sitzungseintrag angelegt. 5. Server sendet `SYN, ACK`. 6. Firewall ordnet das Paket der bestehenden Sitzung zu. 7. Client sendet `ACK`. 8. Sitzung wechselt in den etablierten Zustand. 9. Weitere Pakete werden anhand der Sitzung verarbeitet. 10. `FIN`, `RST` oder Timeout beendet die Sitzung. Eine zustandsbehaftete Firewall kann Pakete verwerfen, wenn diese nicht zum erwarteten Zustand passen, beispielsweise: - `ACK` ohne bekannte Sitzung; - unerwartete TCP-Flags; - Rückverkehr mit abweichenden Adressen oder Ports; - Sequenznummer außerhalb des akzeptierten Fensters; - verspäteter Rückverkehr nach Sitzungsablauf; - Rückverkehr über einen anderen nicht synchronisierten Firewallknoten; - fragmentierter Verkehr, der nicht korrekt zugeordnet werden kann. --- **Typische Daten eines Sitzungseintrags** Ein Sitzungseintrag kann unter anderem enthalten: ```text Sitzungs-ID Protokoll Quellzone Zielzone Eingangsschnittstelle Ausgangsschnittstelle Original-Quelladresse Original-Quellport Original-Zieladresse Original-Zielport übersetzte Quelladresse übersetzter Quellport übersetzte Zieladresse übersetzter Zielport passende Regel Anwendung TCP-Zustand Startzeit letzte Aktivität Timeout gesendete Pakete empfangene Pakete gesendete Bytes empfangene Bytes Sitzungsendgrund Clusterbesitzer ``` Die Sitzungstabelle ist ein wichtiger Nachweis, ersetzt aber nicht die Prüfung der tatsächlichen Anwendung. Eine vorhandene Sitzung beweist nur, dass die Firewall einen Zustand führt. Sie beweist nicht automatisch: - dass der Serverprozess korrekt antwortet; - dass TLS funktioniert; - dass die Anwendung ein gültiges Ergebnis liefert; - dass Nutzdaten in beide Richtungen übertragen werden; - dass die Sitzung nicht bereits festhängt; - dass alle weiteren Sicherheitsprüfungen erfolgreich sind. --- **Zustandslos und zustandsbehaftet vergleichen** | Prüfpunkt | Zustandslose ACL | Stateful Firewall | |---|---|---| | Verarbeitung | jedes Paket einzeln | Paket plus Sitzungszustand | | Rückverkehr | benötigt passende Gegenregel | bestehender Sitzung zugeordnet | | TCP-Zustand | normalerweise nicht vollständig verfolgt | Handshake und Status werden verfolgt | | UDP | jedes Datagramm nach Regel | häufig zeitlich begrenzte Pseudositzung | | ICMP | eigene Regeln pro Richtung erforderlich | kann Anfrage und Antwort zuordnen | | Asymmetrischer Pfad | Regel kann trotzdem passen | häufig Sitzungsproblem | | Ressourcenverbrauch | geringer | Sitzungstabelle benötigt Speicher | | Timeoutwirkung | keine Sitzung | Rückverkehr kann nach Ablauf verworfen werden | | Regeländerung | wirkt auf folgende Pakete | bestehende Sitzungen können abweichend behandelt werden | Das Verhalten bei Regeländerungen und bestehenden Sitzungen ist produktspezifisch. Einige Systeme prüfen bestehende Sitzungen nicht sofort erneut, andere beenden betroffene Sitzungen oder bewerten bestimmte Eigenschaften erneut. --- **TCP-Verkehr prüfen** Bei TCP sind mindestens folgende Punkte zu unterscheiden: - erreicht das `SYN` die Firewall? - welche Regel trifft auf das `SYN`? - verlässt das `SYN` die Firewall? - erreicht das `SYN` den Server? - sendet der Server ein `SYN, ACK` oder `RST`? - erreicht die Antwort dieselbe Firewallinstanz? - wird die Antwort der Sitzung zugeordnet? - erreicht die Antwort den Client? - wird der Handshake vollständig abgeschlossen? - endet die Sitzung durch `FIN`, `RST`, Timeout oder Richtlinie? Befundbeispiele: | Paketfolge | Mögliche Einordnung | |---|---| | wiederholte `SYN`, keine Antwort | Paketverlust, Firewall-Drop, falsche Route oder Server antwortet nicht | | `SYN`, danach sofortiges `RST` | Ziel lehnt aktiv ab oder Zwischenkomponente erzeugt Reset | | `SYN`, `SYN-ACK`, anschließend kein `ACK` | Rückweg zum Client oder Clientseite prüfen | | vollständiger Handshake, danach sofortiger `RST` | Anwendung, Proxy, Sicherheitsprofil oder Protokollproblem | | Daten nur in eine Richtung | Rückweg, asymmetrischer Pfad oder Sicherheitsprüfung | | Sitzung in Firewall vorhanden, keine Serverantwort | Zielsystem, nachgelagerte Firewall oder Route prüfen | --- **UDP-Verkehr prüfen** UDP besitzt keinen TCP-Handshake. Stateful Firewalls führen deshalb häufig eine zeitlich begrenzte Pseudositzung. Beispiel: ```text 192.0.2.100:54000 -> 198.51.100.53:53/UDP ``` Die Firewall kann anschließend eine passende Antwort erlauben: ```text 198.51.100.53:53 -> 192.0.2.100:54000/UDP ``` Zu prüfen sind: - wurde das erste Datagramm durch eine Regel erlaubt? - wurde eine Pseudositzung angelegt? - trifft die Antwort vor Ablauf des UDP-Timeouts ein? - stimmen Antwortadresse und Antwortport mit dem erwarteten Datenfluss überein? - verwendet die Anwendung mehrere Zieladressen oder Ports? - wechselt das Protokoll von UDP zu TCP? - wird ICMP `Destination Unreachable` zurückgegeben? - blockiert eine zustandslose Gegen-ACL den Rückverkehr? Ein vorhandener UDP-Sitzungseintrag beweist keine erfolgreiche Anwendungskommunikation. --- **ICMP und ICMPv6 prüfen** ICMP transportiert nicht nur Echo-Anfrage und Echo-Antwort, sondern auch wichtige Fehlermeldungen. Beispiele: - Ziel nicht erreichbar; - Port nicht erreichbar; - Fragmentierung erforderlich; - Time Exceeded; - Parameter Problem; - Packet Too Big bei IPv6. Zu prüfen sind: - ICMP-Typ und ICMP-Code; - Richtung; - Quell- und Zieladresse; - Zuordnung zu einer ursprünglichen Sitzung; - separate ICMP-Regeln; - ICMP-Inspektionsfunktion; - IPv4- und IPv6-Regeln; - Rate Limits; - vorgeschaltete Router-ACLs. Das pauschale Blockieren von ICMP kann Diagnose, Path-MTU-Discovery und besonders IPv6-Funktionen beeinträchtigen. --- **Sitzungstimeouts** Stateful Firewalls entfernen inaktive Sitzungen nach definierten Zeiträumen. Zu prüfen sind: - TCP-Handshake-Timeout; - TCP-Idle-Timeout; - TCP-Time-Wait- oder Closing-Timeout; - UDP-Timeout; - ICMP-Timeout; - anwendungsspezifischer Timeout; - halb offene Verbindungen; - Langzeitverbindungen; - Keepalive-Verhalten; - maximale Sitzungsdauer; - benutzerdefinierte Timeoutprofile; - Sitzungslast und Tabellenfüllstand. Typische Symptome eines Timeoutproblems: - kurze Verbindungen funktionieren; - lange Leerlaufphasen beenden die Verbindung; - Anwendung meldet nach einer festen Zeit einen Abbruch; - die nächste Übertragung nach Inaktivität schlägt fehl; - eine neue Verbindung funktioniert sofort wieder; - Client und Server halten die Sitzung unterschiedlich lange für gültig. Ein Timeout sollte nur geändert werden, wenn der zeitliche Zusammenhang nachgewiesen wurde. Eine pauschale Erhöhung kann den Speicherverbrauch und die Anzahl gleichzeitig geführter Sitzungen vergrößern. --- **Bestehende Sitzungen bei Regeländerungen** Nach einer Regeländerung sind neue und bestehende Verbindungen getrennt zu prüfen. Mögliche produktabhängige Verhaltensweisen: - neue Sitzungen verwenden die neue Regel; - vorhandene Sitzungen laufen nach alter Entscheidung weiter; - vorhandene Sitzungen werden neu bewertet; - verweigernde Änderung beendet passende Sitzungen; - NAT-Änderung wirkt erst auf neue Sitzungen; - Anwendungserkennung ändert die verwendete Regel während der Sitzung; - Clusterknoten besitzen vorübergehend unterschiedliche Zustände. Deshalb muss ein Test dokumentieren: ```text Test A: bereits vor der Änderung bestehende Verbindung Test B: nach der Änderung vollständig neu aufgebaute Verbindung ``` Wenn ein neuer Test erforderlich ist, sollte nur die einzelne betroffene Anwendungssitzung kontrolliert beendet werden. Das vollständige Löschen der Sitzungstabelle ist unverhältnismäßig und kann viele produktive Verbindungen unterbrechen. --- **Routing und Zielzone** Die Zielzone wird bei vielen Firewalls anhand der Ausgangsschnittstelle oder Routingentscheidung bestimmt. Zu prüfen sind: - aktive Route zur Zieladresse; - Präfixlänge; - nächster Hop; - Routinginstanz oder VRF; - Policy-Based Routing; - ECMP; - Tunnelroute; - dynamisches Routing; - Failoverroute; - Ausgangsschnittstelle; - daraus resultierende Zielzone. Eine Sicherheitsregel kann inhaltlich korrekt aussehen, aber nicht passen, wenn die Firewall aufgrund einer falschen Route eine andere Zielzone bestimmt. Beispiel: ```text Erwartet: CLIENTS -> SERVER Tatsächlich: CLIENTS -> WAN ``` In diesem Fall ist nicht zuerst die Regel `CLIENTS -> SERVER` zu verändern. Zunächst muss geklärt werden, warum die Route zur falschen Ausgangszone führt. --- **NAT und Sicherheitsrichtlinie** NAT kann Adressen und Ports verändern. Beispiel einer Zielübersetzung: ```text Original: 203.0.113.40:55000 -> 198.51.100.10:443 Nach DNAT: 203.0.113.40:55000 -> 10.20.30.40:8443 ``` Beispiel einer Quellübersetzung: ```text Original: 10.10.20.25:53124 -> 203.0.113.80:443 Nach SNAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Für die Diagnose sind beide Ansichten zu dokumentieren: | Merkmal | Vor NAT | Nach NAT | |---|---|---| | Quelladresse | ursprünglicher Absender | übersetzte Quelladresse | | Quellport | ursprünglicher Quellport | übersetzter Quellport | | Zieladresse | aufgerufene Zieladresse | internes oder übersetztes Ziel | | Zielport | aufgerufener Zielport | übersetzter Zielport | Je nach Hersteller, Regelart und Richtung kann die Sicherheitsrichtlinie vor oder nach einer bestimmten NAT-Verarbeitung ausgewertet werden. Es darf nicht angenommen werden, dass eine Firewallregel immer die öffentliche oder immer die private Adresse verwenden muss. Zu prüfen sind: - NAT-Regel; - Sicherheitsregel; - Reihenfolge der Verarbeitung; - Original- und Übersetzungsadresse; - Original- und Übersetzungsport; - NAT-Ausnahme; - Hairpin- oder U-Turn-NAT; - doppelte NAT-Regeln; - Proxy-ARP; - Rückroute; - NAT-Sitzung; - Porterschöpfung; - Clusterzustand. Eine passende Sicherheitsregel kann durch eine falsche NAT-Regel wirkungslos bleiben. --- **Zonen und virtuelle Kontexte** Viele Firewalls besitzen: - Sicherheitszonen; - virtuelle Router; - virtuelle Systeme; - Mandanten; - Security Contexts; - Routinginstanzen; - Verwaltungs- und Datenebenen; - zentrale und lokale Richtlinien. Zu prüfen sind: - richtige Firewall; - aktiver Clusterknoten; - richtiger Mandant; - richtiger virtueller Kontext; - richtige Routinginstanz; - richtige Policy-Version; - richtige Eingangszone; - richtige Ausgangszone; - globale oder geerbte Regeln; - lokale Ausnahmen; - zentral verwaltete und lokal definierte Regeln. Eine Regel in einem anderen virtuellen Kontext kann denselben Namen besitzen, aber für den betroffenen Datenverkehr vollständig wirkungslos sein. --- **Zusätzliche Sicherheitsprüfungen** Eine Regel mit der Aktion `allow` bedeutet bei modernen Firewalls häufig nur, dass der Datenfluss weiter geprüft werden darf. Weitere mögliche Prüfungen: - Intrusion Prevention; - Malware-Erkennung; - Antivirus; - Dateitypprüfung; - URL-Filterung; - DNS-Sicherheitsprüfung; - Anwendungskontrolle; - Benutzeridentifikation; - Data Loss Prevention; - Botnet-Erkennung; - TLS-Entschlüsselung; - Zertifikatsprüfung; - Protokolldekodierung; - Geo-IP-Regel; - Reputationsprüfung; - Threat-Intelligence-Regel; - DoS-Schutz; - Zone Protection; - Flood Protection. Deshalb sind mindestens zwei Entscheidungen zu unterscheiden: ```text Netzwerkregel: allow Sicherheitsprofil: block ``` Im Protokoll können dafür mehrere Einträge entstehen. Ein `allow`-Ereignis darf nicht isoliert als Nachweis einer erfolgreichen Verbindung bewertet werden. --- **Application-Awareness** Eine anwendungsbasierte Firewall kann eine Sitzung zunächst anhand des Ports behandeln und später die erkannte Anwendung berücksichtigen. Zu prüfen sind: - erkannte Anwendung; - Zeitpunkt der Erkennung; - unbekannte oder unvollständige Anwendung; - abweichender Port; - verschlüsselter Datenverkehr; - SNI; - HTTP-Hostheader; - ALPN; - QUIC; - Portwechsel; - abhängige Anwendungen; - benötigte Grundanwendung; - Regel mit `application-default`; - TLS-Entschlüsselungsstatus. Beispiel: ```text TCP-Port: 443 Erkannte Anwendung: quic Erwartete Anwendung: ssl/web-browsing ``` Eine reine Portfreigabe sagt nicht aus, welche Anwendung tatsächlich transportiert wird. --- **Regelbindung prüfen** Eine definierte ACL oder Policy wirkt nur, wenn sie an der richtigen Stelle eingebunden ist. Zu prüfen sind: - Schnittstelle; - Richtung; - Sicherheitszone; - Regelgruppe; - Policy-Paket; - virtueller Kontext; - Mandant; - Gerätegruppe; - Zielgerät; - aktive Konfiguration; - erfolgreicher Commit; - erfolgreicher Deploymentstatus; - Synchronisation im Cluster; - zentrale Vererbung. Beispielbefund: ```text ACL: WEB-IN Konfiguriert: ja Gebunden an: DMZ-Schnittstelle eingehend Tatsächlicher Verkehr: tritt an WAN-Schnittstelle ein Ergebnis: ACL WEB-IN verarbeitet diesen Datenfluss nicht ``` --- **Aktive und gespeicherte Konfiguration unterscheiden** Je nach Produkt können unterschiedliche Konfigurationsstände existieren: - bearbeitete Konfiguration; - Kandidatenkonfiguration; - gespeicherte Startkonfiguration; - laufende Konfiguration; - zuletzt erfolgreich ausgerollte Richtlinie; - zentral vorgesehene Richtlinie; - lokale Gerätekonfiguration; - Konfiguration des aktiven Knotens; - Konfiguration des passiven Knotens. Zu prüfen sind: - wurde die Änderung gespeichert? - wurde sie erfolgreich geprüft? - wurde sie committed? - wurde sie auf das richtige Gerät ausgerollt? - ist das Deployment abgeschlossen? - existieren Warnungen oder Fehler? - verwenden alle Clusterknoten dieselbe Version? - wurde eine lokale Änderung durch zentrale Verwaltung überschrieben? Eine im Managementsystem sichtbare Regel beweist nicht, dass sie bereits auf der Datenebene aktiv ist. --- **Hochverfügbarkeit und Cluster** Bei einem Firewallcluster sind zusätzlich zu prüfen: - aktiver und passiver Knoten; - Clusterzustand; - Konfigurationssynchronisation; - Sitzungssynchronisation; - NAT-Synchronisation; - Routingzustand; - Linkstatus; - Split-Brain-Schutz; - Eigentümer der Sitzung; - Datenpfad des Hinverkehrs; - Datenpfad des Rückverkehrs; - Zustand nach Failover; - Zeitstempel der letzten Umschaltung. Typischer Fehler: ```text Hinverkehr: FW-A Rückverkehr: FW-B Sitzungssynchronisation: fehlerhaft ``` FW-B kennt die durch FW-A aufgebaute Sitzung möglicherweise nicht und verwirft den Rückverkehr als ungültig. Asymmetrische Pfade und Connection Tracking werden in **9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking** weiter vertieft. --- **Cloud-Firewalls und Cloud-ACLs** Cloud-Plattformen können mehrere Filterebenen kombinieren: - Security Group an der Netzwerkschnittstelle; - Subnetz-ACL; - zentrale Cloud-Firewall; - Load Balancer; - Web Application Firewall; - Kubernetes Network Policy; - Plattformdienst-Firewall; - lokaler Hostfilter; - On-Premises-Firewall; - Routing- und Transitkomponente. Diese Ebenen müssen einzeln geprüft werden. --- **AWS Security Groups und Network ACLs** | Merkmal | AWS Security Group | AWS Network ACL | |---|---|---| | Zuordnung | Netzwerkschnittstelle oder Ressource | Subnetz | | Zustand | stateful | stateless | | Regeln | Freigaberegeln | Erlauben und Verweigern | | Rückverkehr | für verfolgte Verbindung automatisch berücksichtigt | muss durch Gegenregel erlaubt werden | | Reihenfolge | keine klassische First-Match-Reihenfolge der Freigaberegeln | nach Regelnummer | | Diagnosefokus | tatsächlich zugeordnete Gruppen | tatsächlich zugeordnete Subnetz-ACL | | Ephemeral Ports | Rückverkehr durch Zustand | ausdrücklich berücksichtigen | Bei einer AWS Network ACL muss beispielsweise für eine eingehend erlaubte TCP-Verbindung auch der ausgehende Rückverkehr zum dynamischen Clientport erlaubt sein. Vereinfachtes Beispiel: ```text Inbound: TCP von 192.0.2.0/24 zu Zielport 443 erlauben Outbound: TCP zu 192.0.2.0/24 und benötigtem dynamischem Clientportbereich erlauben ``` Der tatsächlich verwendete Portbereich hängt vom Clientbetriebssystem, der Anwendung und gegebenenfalls weiteren NAT-Komponenten ab. --- **Azure Network Security Groups** Azure Network Security Groups arbeiten zustandsbehaftet und verwenden Regeln mit Prioritätswerten. Grundprinzip: ```text kleinere Prioritätszahl = höhere Priorität ``` Beispiel: ```text Priorität 100: Deny TCP 192.0.2.66 -> 10.20.30.40:443 Priorität 200: Allow TCP 192.0.2.0/24 -> 10.20.30.40:443 ``` Zu prüfen sind: - NSG am Subnetz; - NSG an der Netzwerkschnittstelle; - effektive Sicherheitsregeln; - Priorität; - Standardregeln; - Service Tags; - Application Security Groups; - NAT-Bezug; - Azure Firewall; - User Defined Routes; - Load Balancer; - Network Watcher Flow Logs; - tatsächlich verwendete private Zieladresse. Bei eingehendem Verkehr verarbeitet eine Azure NSG die Regeln nach der Übersetzung einer öffentlichen in eine private IP-Adresse. Bei ausgehendem Verkehr erfolgt die NSG-Verarbeitung vor der Übersetzung einer privaten in eine öffentliche Adresse. --- **Netzwerkregel und Anwendungsfirewall unterscheiden** Eine Netzwerkfirewall prüft typischerweise IP-Adressen, Ports, Protokolle, Sitzungen und gegebenenfalls Anwendungen. Eine Web Application Firewall prüft dagegen HTTP- oder HTTPS-Anfragen auf Anwendungsebene. Beispiel: ```text Netzwerkfirewall: TCP 443 erlaubt Web Application Firewall: HTTP-Anfrage wegen Regelverletzung blockiert ``` Ein erfolgreicher TCP-Handshake bis zum Reverse Proxy beweist daher nicht, dass die Webanwendung die Anfrage akzeptiert. --- **Ausgangszustand erfassen** Vor Veränderungen sind folgende Informationen zu sichern: ```text Datum und Uhrzeit Zeitzone Clientname und Clientadresse Servername und Serveradresse Quellport Zielport Protokoll Anwendung exakte Fehlermeldung betroffener Benutzer Eingangs- und Ausgangszone erwarteter Firewallpfad aktiver Firewallknoten Regelname und Regel-ID NAT-Regel Sitzungs-ID Policy-Version Logeinträge Trefferzähler Paketaufzeichnungen ``` Die Uhren von Client, Server, Firewall und zentralem Protokollsystem müssen ausreichend synchronisiert sein. Andernfalls können zusammengehörige Ereignisse falsch zugeordnet werden. --- **Fehlerumfang bestimmen** Zu klären ist: - betrifft die Störung nur einen Client? - betrifft sie ein gesamtes Quellnetz? - betrifft sie nur eine Zieladresse? - betrifft sie alle Ziele einer Zone? - betrifft sie nur einen Port? - betrifft sie TCP, UDP oder ICMP? - betrifft sie IPv4, IPv6 oder beide? - tritt sie nur über VPN auf? - tritt sie nur über einen Standort auf? - betrifft sie neue oder auch bestehende Sitzungen? - tritt sie erst seit einer Regeländerung auf? - betrifft sie nur einen Clusterknoten? - tritt sie nur zu bestimmten Uhrzeiten auf? - betrifft sie nur eine erkannte Anwendung? - ist sie von der Nutzlastgröße abhängig? Ein präzise begrenzter Fehlerumfang verhindert unnötig weitreichende Regeländerungen. --- **Firewallpfad nachweisen** Der vorgesehene Firewallpfad darf nicht nur aus dem Netzplan abgeleitet werden. Mögliche Nachweise: - Traceroute; - Routingtabellen; - Flow Logs; - NetFlow oder IPFIX; - Firewall-Sitzungstabelle; - Eingangs- und Ausgangsaufzeichnung; - Schnittstellenzähler; - MAC- und ARP-Tabellen; - Cloud Network Watcher; - zentrale SD-WAN- oder Transitprotokolle; - Logeintrag mit Eingangs- und Ausgangszone. Zu beachten ist, dass Traceroute nicht jede Firewall sichtbar macht. Eine transparente Firewall oder ein Gerät, das TTL-Abläufe nicht beantwortet, kann im Traceroute fehlen. --- **Regelwerk zunächst nur lesend prüfen** Zu erfassen sind: - Name der aktiven Policy; - Regel-ID; - Regelname; - Position oder Priorität; - Quelle; - Ziel; - Zonen; - Protokoll; - Quellport; - Zielport; - Anwendung; - Aktion; - Sicherheitsprofile; - Zeitplan; - Protokollierung; - Trefferzähler; - letztes Trefferdatum; - Ersteller; - Änderungsreferenz; - Objektinhalte; - Standardaktion. Ein Screenshot allein ist kein idealer technischer Nachweis. Wenn möglich, sollten zusätzlich exportierbare Text- oder Konfigurationsdaten mit Zeitstempel gesichert werden. Dabei sind Zugangsdaten, Schlüssel und andere schützenswerte Informationen zu entfernen. --- **Trefferzähler richtig auswerten** Ein Trefferzähler kann zeigen, dass Verkehr eine Regel erreicht hat. Er muss jedoch vorsichtig interpretiert werden. Zu beachten sind: - einige Produkte zählen nur den ersten Paket- oder Sitzungsaufbau; - andere zählen alle passenden Pakete; - Hardware-Offloading kann separate Zähler verwenden; - Zähler können pro Clusterknoten geführt werden; - zentrale Ansicht kann verzögert sein; - ein breites Regelobjekt kann Verkehr vieler Systeme zählen; - alte Treffer beweisen keinen Treffer beim aktuellen Test; - Zähler können nach Neustart oder Deployment zurückgesetzt sein; - ein Zähleranstieg bei einer `allow`-Regel beweist keine erfolgreiche Anwendung; - ein Zählerstand von null kann auf falschen Pfad, falsche Regel oder falschen Kontext hinweisen. Belastbarer Ablauf: 1. aktuellen Zählerstand mit Uhrzeit dokumentieren; 2. genau einen kontrollierten Test ausführen; 3. Zähler erneut ablesen; 4. Differenz bewerten; 5. gleichzeitig Firewallprotokoll und Anwendungsergebnis prüfen. Zähler dürfen erst nach der Beweissicherung und nur mit Freigabe zurückgesetzt werden. --- **Firewallprotokolle auswerten** Ein brauchbarer Protokolleintrag enthält möglichst: - Ereigniszeit; - Firewallname; - Clusterknoten; - virtuellen Kontext; - Eingangszone; - Ausgangszone; - Eingangs- und Ausgangsschnittstelle; - Quelladresse; - Quellport; - Zieladresse; - Zielport; - Protokoll; - NAT-Adressen und NAT-Ports; - Regelname; - Regel-ID; - Aktion; - erkannte Anwendung; - Sicherheitsprofil; - Sitzungs-ID; - Pakete und Bytes je Richtung; - Sitzungsendgrund; - Drop-Grund. Nach exakt diesen Merkmalen sollte gefiltert werden: ```text source = 192.0.2.100 destination = 198.51.100.25 destination_port = 443 protocol = TCP time = 2026-08-02 10:15:00 bis 10:16:00 ``` Ein fehlender Logeintrag beweist nicht automatisch, dass die Firewall den Datenfluss nicht gesehen hat. Mögliche Gründe: - Protokollierung ist für die Regel deaktiviert; - nur Sitzungsende wird protokolliert; - Sitzung läuft noch; - Ereignisse werden verzögert übertragen; - falscher Clusterknoten wurde geprüft; - falscher Mandant wurde geprüft; - Protokolle werden gefiltert oder begrenzt; - Datenfluss verwendet einen anderen Pfad; - Paket wird vor der normalen Sicherheitsregel verworfen; - Hardware-Offload verwendet andere Diagnosezähler; - Rate Limiting unterdrückt Ereignisse. --- **Erlaubt-, Verworfen- und Sitzungsendgründe unterscheiden** Mögliche Aktionen und Endgründe: | Befund | Mögliche Bedeutung | |---|---| | `allow` | Netzwerkregel hat den Datenfluss zugelassen | | `deny` | Sicherheitsregel hat den Datenfluss verworfen | | `drop` | Paket wurde ohne aktive Ablehnungsantwort verworfen | | `reject` | Firewall sendet eine aktive Ablehnungsantwort | | `reset-client` | Firewall sendet TCP-RST zum Client | | `reset-server` | Firewall sendet TCP-RST zum Server | | `aged-out` | Sitzung ist durch Timeout abgelaufen | | `tcp-rst-from-client` | Client hat die Sitzung beendet | | `tcp-rst-from-server` | Server hat die Sitzung beendet | | `policy-deny` | Richtlinie hat den Aufbau blockiert | | `threat` oder `ips-drop` | Sicherheitsprofil hat blockiert | | `decrypt-error` | TLS-Entschlüsselung ist fehlgeschlagen | | `resources-unavailable` | Kapazitäts- oder Ressourcengrenze | | `invalid-state` | Paket passt nicht zum erwarteten Sitzungszustand | | `no-route` | keine verwendbare Route | | `nat-failure` | NAT-Verarbeitung ist fehlgeschlagen | Die genaue Benennung ist herstellerspezifisch. --- **Policy-Match- und Packet-Tracer-Werkzeuge** Viele Hersteller bieten Werkzeuge an, die einen hypothetischen Datenfluss gegen die aktuelle Konfiguration prüfen. Benötigte Eingaben: ```text Eingangsschnittstelle Quellzone Quelladresse Quellport Zieladresse Zielport Protokoll Benutzer oder Anwendung, sofern erforderlich ``` Solche Werkzeuge können unter anderem zeigen: - Routingentscheidung; - NAT-Regel; - Sicherheitsregel; - Ausgangsschnittstelle; - Zielzone; - zulassende oder verweigernde Phase; - implizite Standardaktion. Ein Simulationsergebnis beweist nicht: - dass das reale Paket die Firewall erreicht; - dass die physische Schnittstelle funktioniert; - dass der Server erreichbar ist; - dass der Rückweg stimmt; - dass die Anwendung antwortet; - dass eine nachgelagerte Firewall erlaubt; - dass ein Sicherheitsprofil den realen Inhalt akzeptiert; - dass derselbe Clusterknoten den realen Datenfluss verarbeitet. Die Simulation muss mit einem realen Test, Protokollen und gegebenenfalls Paketaufzeichnungen kombiniert werden. --- **Cisco IOS ACLs lesend prüfen** Beispielbefehle: ```text show ip access-lists ``` ```text show ip access-lists ``` ```text show running-config | section access-list ``` ```text show running-config | include ip access-group ``` ```text show ip interface ``` Zu prüfen sind: - Reihenfolge der Einträge; - `permit` oder `deny`; - Trefferzähler; - implizites Verbot; - Schnittstellenbindung; - Richtung `in` oder `out`; - Wildcard-Masken; - Protokoll; - Quell- und Zielport; - IPv4- oder IPv6-ACL. Die genaue Syntax hängt von Plattform und Softwareversion ab. --- **Cisco Secure Firewall ASA lesend prüfen** ACLs und Bindungen: ```text show access-list ``` ```text show access-group ``` Verbindungen und NAT: ```text show conn ``` ```text show conn address 192.0.2.100 ``` ```text show xlate ``` Routing: ```text show route ``` Simulation eines TCP-Pakets: ```text packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed ``` Drop-Zähler: ```text show asp drop ``` `show asp drop` liefert interne Drop-Zähler und ist für gezielte Fehleranalysen vorgesehen. Die Ausgabe ist umfangreich und muss zeitlich mit einem kontrollierten Test korreliert werden. Bei Cisco ASA verwenden normale Zugriffsregeln für NAT-Verkehr die reale Adresse des Ziels. Dieses Verhalten darf nicht ungeprüft auf andere Firewallprodukte übertragen werden. --- **Juniper SRX lesend prüfen** Beispielbefehle: ```text show security policies ``` ```text show security policies hit-count ``` ```text show security flow session ``` ```text show security flow session source-prefix 192.0.2.100 ``` ```text show security flow session destination-prefix 198.51.100.25 ``` ```text show route 198.51.100.25 ``` Für eine Richtlinienzuordnung kann abhängig von Junos-Version und Konfiguration `show security match-policies` verwendet werden. Die vollständige lokale Syntax ist mit der CLI-Hilfe zu prüfen. Juniper-Sicherheitsrichtlinien werden innerhalb des zutreffenden Zonenkontexts in Reihenfolge ausgewertet. Die erste passende Richtlinie bestimmt die Aktion. --- **Palo Alto Networks lesend prüfen** Sitzungssuche: ```text show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443 ``` Routingprüfung: ```text test routing fib-lookup virtual-router ip 198.51.100.25 ``` Policy-Match-Tests und genaue Filteroptionen sind versionsabhängig. Vor der Ausführung ist die lokale CLI-Hilfe zu verwenden: ```text test security-policy-match ? ``` ```text show session all filter ? ``` Bei der Auswertung sind unter anderem zu prüfen: - Regelname; - Quell- und Zielzone; - Anwendung; - Dienst; - NAT-Regel; - Sicherheitsprofile; - Sitzungsendgrund; - Pakete und Bytes je Richtung. Palo-Alto-Sicherheitsregeln werden innerhalb der Regelbasis von oben nach unten ausgewertet. Die erste passende Regel wird angewendet. Spezifische Regeln müssen daher vor allgemeineren Regeln stehen. --- **Linux als Netzwerkfirewall lesend prüfen** Wenn ein Linux-System als Router oder Firewall eingesetzt wird, können abhängig von der Konfiguration folgende Prüfungen relevant sein. Aktives nftables-Regelwerk: ```bash sudo nft list ruleset ``` Regelwerk mit Handles: ```bash sudo nft -a list ruleset ``` Routing: ```bash ip route show ``` ```bash ip -6 route show ``` Weiterleitungseinstellung: ```bash sysctl net.ipv4.ip_forward ``` ```bash sysctl net.ipv6.conf.all.forwarding ``` Connection Tracking, sofern das Werkzeug vorhanden ist: ```bash sudo conntrack -L ``` Gezielte Suche: ```bash sudo conntrack -L \ -s 192.0.2.100 \ -d 198.51.100.25 \ -p tcp ``` Zu beachten sind: - richtige Chain; - Hook; - Priorität; - Tabelle; - Familie `ip`, `ip6` oder `inet`; - Eingangs- und Ausgangsschnittstelle; - Default Policy; - NAT-Chain; - Connection-Tracking-Zustand; - Paketzähler; - Weiterleitung im Kernel. Das Löschen von Conntrack-Einträgen ist eine verändernde Maßnahme und darf nicht als erster Diagnoseschritt erfolgen. --- **Paketaufzeichnung an der Firewall** Eine Paketaufzeichnung ist sinnvoll, wenn nicht eindeutig ist: - ob das Paket die Firewall erreicht; - ob es die Firewall wieder verlässt; - ob die Antwort zurückkommt; - ob NAT wie vorgesehen angewendet wird; - ob ein Reset erzeugt wird; - ob Pakete wiederholt werden; - ob nur eine Richtung sichtbar ist; - ob Fragmentierung auftritt; - ob der Datenfluss einen anderen Ausgang verwendet. Idealer Vergleich: ```text Aufzeichnung A: Eingangsschnittstelle Aufzeichnung B: Ausgangsschnittstelle ``` Befundbeispiele: | Eingang | Ausgang | Einordnung | |---|---|---| | Paket nicht sichtbar | Paket nicht sichtbar | Pfad vor der Firewall prüfen | | Paket sichtbar | Paket nicht sichtbar | Firewallverarbeitung, Regel, NAT oder Route prüfen | | Paket mit übersetztem Ziel sichtbar | Paket erreicht Server | Firewall hat Hinverkehr weitergeleitet | | Serverantwort am Ausgangsnetz sichtbar | Antwort nicht zum Clientnetz | Firewallzustand, NAT oder Rückroute prüfen | | vollständiger Verkehr auf beiden Seiten | Client meldet trotzdem Fehler | Host, Anwendung, Proxy oder TLS prüfen | Bei Hardware-Offloading kann eine allgemeine Paketaufzeichnung möglicherweise nicht alle weitergeleiteten Pakete zeigen. Dann sind herstellerspezifische Capture-Funktionen, Dataplane-Diagnosen oder ein externer SPAN/TAP erforderlich. Aufzeichnungen müssen: - zeitlich begrenzt; - auf Quelle und Ziel gefiltert; - vor unberechtigtem Zugriff geschützt; - nach der Auswertung kontrolliert gelöscht oder archiviert; - datenschutzrechtlich und organisatorisch freigegeben werden. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Die allgemeine Freigaberegel mit Priorität 100 erlaubt das gesamte Clientnetz und überschattet die nachfolgende Sperrregel für 192.0.2.66. Erwarteter Befund: Ein Policy-Match-Test für 192.0.2.66 -> 198.51.100.25:443 nennt die allgemeine Freigaberegel. Der Trefferzähler der Sperrregel ändert sich beim Test nicht. Gegenbeweis: Der reale Datenfluss trifft nachweislich die Sperrregel und wird durch diese verworfen. Testmethode: Policy-Match, kontrollierter Verbindungsversuch, Regelzähler und Firewallprotokoll zeitlich korrelieren. Risiko: Nur lesende Diagnose; keine Auswirkung auf Produktivverkehr. Erfolgskriterium: Tatsächlich angewendete Regel ist mit Regel-ID und Logeintrag eindeutig nachgewiesen. ``` Weitere mögliche Hypothesen: - Datenverkehr durchläuft eine andere Firewall. - Falsche Route führt zur falschen Zielzone. - Firewallregel verwendet die öffentliche statt der intern ausgewerteten Adresse. - Eine vorgelagerte globale Regel blockiert vor der lokalen Regel. - Bestehende Sitzung verwendet noch den alten Richtlinienzustand. - Sicherheitsprofil blockiert nach einer erlaubenden Netzwerkregel. - Rückverkehr erreicht einen anderen Clusterknoten. - Eine zustandslose Cloud-ACL blockiert den dynamischen Rückport. - FQDN-Objekt enthält nicht die vom Client verwendete Zieladresse. - IPv4 ist erlaubt, IPv6 jedoch nicht. - Die Regel ist konfiguriert, aber nicht ausgerollt. --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | Regelreihenfolge korrigieren | Überschattung nachgewiesen | andere Datenflüsse können anders behandelt werden | vorherige Reihenfolge wiederherstellen | | spezifische Freigabe ergänzen | fehlende Freigabe bestätigt | zusätzliche Angriffsfläche | neue Regel deaktivieren oder entfernen | | Adressobjekt korrigieren | Objektinhalt nachweislich falsch | alle Regeln mit diesem Objekt betroffen | vorherigen Objektstand wiederherstellen | | Dienstobjekt korrigieren | Port oder Protokoll falsch | weitere Anwendungen können betroffen sein | vorherige Definition wiederherstellen | | Zonenbezug korrigieren | tatsächlicher Pfad nachgewiesen | Segmentierungswirkung ändert sich | vorherige Zonenregel wiederherstellen | | NAT-Regel korrigieren | Übersetzungsfehler bestätigt | Erreichbarkeit und Rückweg ändern sich | vorherige NAT-Regel aktivieren | | Route korrigieren | falsche Ausgangszone oder falscher Next Hop | viele Ziele können betroffen sein | vorherige Route wiederherstellen | | Logging aktivieren | fehlende Beweisdaten | zusätzliche Last und Datenmenge | Logging zurücknehmen | | einzelne Sitzung beenden | alte Sitzung beeinflusst Test | eine produktive Verbindung wird unterbrochen | Anwendung baut neue Sitzung auf | | Timeout anpassen | zeitabhängiger Sitzungsabbruch nachgewiesen | höhere Sitzungsanzahl und Ressourcennutzung | alten Timeoutwert wiederherstellen | | Sicherheitsprofil korrigieren | Fehlklassifizierung nachgewiesen | Schutzwirkung kann sinken | vorheriges Profil wiederherstellen | | Cluster-Synchronisation reparieren | Zustandsabweichung nachgewiesen | Failover- und Sitzungsrisiko | herstellerspezifischer Rückfallplan | Eine allgemeine Testfreigabe ist kein geeigneter Ersatz für eine präzise Ursachenanalyse. --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung, Anwendung, Client, Benutzer und Uhrzeit dokumentieren. 2. Quelladresse und tatsächlichen Quellport bestimmen. 3. Zieladresse, Zielport und Protokoll bestimmen. 4. IPv4 und IPv6 unterscheiden. 5. Erwarteten Datenfluss und Sollzustand dokumentieren. 6. Umfang der Störung bestimmen. 7. Host-Firewalls als eigene Filterebenen berücksichtigen. 8. Direkte Erreichbarkeit und Dienstzustand prüfen. 9. Erwarteten Netzwerkpfad dokumentieren. 10. Tatsächlichen Firewallpfad nachweisen. 11. Aktiven Firewall- oder Clusterknoten bestimmen. 12. Richtigen Mandanten und virtuellen Kontext bestimmen. 13. Eingangs- und Ausgangsschnittstelle bestimmen. 14. Quell- und Zielzone bestimmen. 15. Route zur Zieladresse prüfen. 16. Policy-Based Routing, VRF und Tunnel berücksichtigen. 17. Originaladressen und Originalports dokumentieren. 18. NAT-Adressen und NAT-Ports dokumentieren. 19. Aktive NAT-Regel bestimmen. 20. Aktive Sicherheitsrichtlinie bestimmen. 21. Regelreihenfolge und Prioritäten prüfen. 22. Globale, geerbte und lokale Regeln berücksichtigen. 23. Implizite Standardaktion bestimmen. 24. Adress-, Dienst- und FQDN-Objekte auflösen. 25. Zeitpläne und Identitätskriterien prüfen. 26. Anwendungs- und Sicherheitsprofile prüfen. 27. Policy-Match- oder Packet-Tracer-Test durchführen. 28. Ergebnis nicht mit realem Durchsatz gleichsetzen. 29. Regelzähler mit Ausgangswert dokumentieren. 30. Genau einen kontrollierten Verbindungstest ausführen. 31. Zähleränderung und Protokolle auswerten. 32. Sitzungstabelle prüfen. 33. TCP-, UDP- oder ICMP-Zustand auswerten. 34. Pakete und Bytes je Richtung vergleichen. 35. Sitzungsendgrund auswerten. 36. Bestehende und neue Sitzung unterscheiden. 37. Bei Bedarf Eingangs- und Ausgangsaufzeichnung durchführen. 38. Hin- und Rückverkehr vergleichen. 39. Cluster- und Zustandssynchronisation prüfen. 40. Weitere Cloud- oder Subnetz-ACLs prüfen. 41. Hypothese, erwarteten Befund und Gegenbeweis formulieren. 42. Genau eine kontrollierte Maßnahme vorbereiten. 43. Risiko, Rückweg und Erfolgskriterium dokumentieren. 44. Maßnahme freigeben und umsetzen. 45. Neue Verbindung mit identischen Parametern testen. 46. Regel, Sitzung, Pakete, Bytes und Anwendungsergebnis verifizieren. 47. Repräsentative weitere Datenflüsse auf Nebenwirkungen prüfen. 48. Temporäre Logging- und Testregeln zurücknehmen. 49. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein Firewalllog | falscher Pfad, Logging deaktiviert oder früher Drop | Route, Capture und Regelprotokollierung prüfen | | `deny` durch erwartete Regel | Freigabe fehlt oder Regelinhalt falsch | Regelkriterien und Sollzustand vergleichen | | `deny` durch andere Regel | Überschattung oder falscher Kontext | Reihenfolge und Priorität prüfen | | implizites `deny` | keine ausdrückliche Regel passt | Zonen, Adressen, Protokoll und Ports prüfen | | Allow-Regel hat Zähler null | Verkehr trifft Regel nicht | Pfad, Bindung, Kontext und Objekte prüfen | | Allow-Regel zählt, Anwendung scheitert | späterer Filter, Rückweg oder Anwendung | Sitzungsende, Sicherheitsprofil und Capture | | nur Hinpakete gezählt | Rückweg oder Serverantwort fehlt | Serverseite und Rückroute prüfen | | Pakete in beide Richtungen, null Nutzdaten | Handshake- oder Anwendungsproblem | TCP-Flags, TLS und Anwendung prüfen | | Sitzung `aged-out` | keine Antwort oder Idle-Timeout | Paketfluss und Timeoutdauer prüfen | | Sitzung endet mit Server-RST | Server oder Zwischenkomponente lehnt ab | servernahe Aufzeichnung und Dienstprotokoll | | Sitzung endet mit Client-RST | Client oder Anwendung beendet | Clientaufzeichnung und Anwendungsprotokoll | | Policy-Test erlaubt, reales Paket fehlt | Firewall wird nicht erreicht | vorgelagertes Routing und Filter prüfen | | Policy-Test erlaubt, reales Paket wird verworfen | zusätzliche Prüfung oder Zustand | Drop-Grund und Sicherheitsprofil | | Zielzone unerwartet | Route oder VRF falsch | Routingentscheidung prüfen | | NAT-Ziel unerwartet | falsche oder frühere NAT-Regel | NAT-Reihenfolge und Übersetzungstabelle | | neue Verbindung scheitert, alte funktioniert | neue Richtlinie oder NAT-Entscheidung | alte und neue Sitzung vergleichen | | alte Verbindung scheitert, neue funktioniert | veralteter Sitzungszustand | gezielt einzelne Sitzung untersuchen | | nur UDP-Rückverkehr fehlt | stateless ACL oder Timeout | Gegenrichtung und UDP-Sitzung prüfen | | nur große Pakete scheitern | MTU, Fragmentierung oder ICMP-Block | Paketgröße und ICMP-Fehler prüfen | | nur IPv6 scheitert | fehlende IPv6-Regel oder Route | IPv6-Regelwerk und `ip -6 route` | | nur ein Clusterknoten betroffen | Konfigurations- oder Zustandsabweichung | Knoten direkt vergleichen | | AWS Security Group erlaubt, Verkehr scheitert | NACL, Route, Hostfilter oder Dienst | alle Filterebenen prüfen | | AWS NACL erlaubt Hinweg, Rückweg fehlt | zustandslose Rückregel fehlt | dynamischen Rückportbereich prüfen | | Azure NSG-Regel vorhanden, trifft nicht | Priorität oder andere NSG | effektive Regeln an NIC und Subnetz | | `allow`, danach Threat-Drop | Sicherheitsprofil blockiert | Bedrohungs- oder IPS-Protokoll | | FQDN-Regel trifft nicht | andere DNS-Auflösung | Firewall- und Clientauflösung vergleichen | | nur bestimmte Uhrzeit betroffen | Regelzeitplan oder automatisches Deployment | Zeitplan und Änderungsprotokoll | | nur nach Failover betroffen | Sitzungs- oder NAT-Synchronisation | HA-Status und neue Sitzung prüfen | --- **Typische Diagnosefehler** - Netzwerkfirewall und Host-Firewall verwechseln. - Nur den vorgesehenen und nicht den tatsächlichen Netzwerkpfad betrachten. - Von einer vorhandenen Regel auf eine wirksame Regel schließen. - Quellport und Zielport verwechseln. - Eingehend oder ausgehend ohne Bezug auf Schnittstelle oder Ressource angeben. - Sicherheitszonen nicht dokumentieren. - Regelreihenfolge ignorieren. - Implizite Verweigerung übersehen. - Globale oder geerbte Regeln nicht berücksichtigen. - Regel in falschem Mandanten oder Kontext prüfen. - Definierte, aber nicht gebundene ACL übersehen. - Bearbeitete und aktive Konfiguration verwechseln. - Fehlerhaftes Deployment nicht prüfen. - Adressobjekte nur nach Namen bewerten. - Verschachtelte Objektgruppen nicht auflösen. - Wildcard-Maske als Subnetzmaske lesen. - IPv4-Freigabe als IPv6-Freigabe interpretieren. - FQDN-Auflösung der Firewall nicht mit der Clientauflösung vergleichen. - Öffentliche und private NAT-Adresse verwechseln. - Herstellerabhängige NAT-Reihenfolge annehmen. - Falsche Route durch eine zusätzliche Firewallfreigabe verdecken. - Eine `allow`-Aktion als vollständigen Erfolgsnachweis bewerten. - Sicherheitsprofile und Anwendungserkennung ignorieren. - Policy-Simulation als Nachweis realer Weiterleitung verwenden. - Nur einen Clusterknoten prüfen. - Sitzungszähler ohne Zeitbezug auswerten. - Regelzähler vor der Beweissicherung zurücksetzen. - Alte und neue Sitzungen nicht unterscheiden. - Sitzungstabelle vollständig löschen. - UDP wie TCP diagnostizieren. - Bei zustandsloser ACL den Rückverkehr vergessen. - ICMP pauschal sperren. - Nur Echo-Anfragen als ICMP betrachten. - Pro Verbindungstest mehrere Variablen ändern. - Paketaufzeichnung ohne präzisen Filter starten. - Nur die Eingangsschnittstelle aufzeichnen. - Hardware-Offloading bei Captures ignorieren. - Firewall vorsorglich neu starten. - Allgemeine `any any`-Regel als Test erstellen. - Temporäre Freigaben oder Protokollierungen aktiv lassen. - Nur das Diagnosewerkzeug und nicht die ursprüngliche Anwendung testen. - Ursache und Präventionsmaßnahme nicht dokumentieren. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Client verwendet die erwartete Quelladresse; - Zieladresse entspricht dem Sollzustand; - Protokoll und Zielport sind korrekt; - der Datenfluss durchläuft die vorgesehene Firewall; - richtiger Clusterknoten und Kontext werden verwendet; - Eingangs- und Ausgangszone sind korrekt; - Routingentscheidung ist korrekt; - NAT verwendet die erwarteten Adressen und Ports; - die vorgesehene Sicherheitsregel trifft; - keine allgemeinere Regel überschattet sie; - Regelzähler steigt beim kontrollierten Test; - Firewallprotokoll enthält die erwartete Aktion; - keine nachgelagerte Sicherheitsprüfung blockiert; - Sitzung wird korrekt angelegt; - TCP-Handshake wird vollständig abgeschlossen; - UDP-Antwort wird der Sitzung zugeordnet; - benötigte ICMP-Fehlermeldungen werden transportiert; - Pakete und Bytes sind in beiden Richtungen plausibel; - Sitzungsendgrund ist erwartungsgemäß; - neue Verbindung funktioniert; - bestehende Verbindungen wurden nicht unbeabsichtigt beeinflusst; - IPv4 und IPv6 funktionieren, sofern erforderlich; - weitere repräsentative Quellen funktionieren; - weitere repräsentative Ziele funktionieren; - Hochverfügbarkeit und Synchronisation sind fehlerfrei; - Cloud-Sicherheitsgruppen und Subnetz-ACLs sind konsistent; - ursprüngliche Anwendung funktioniert; - temporäre Testregeln wurden entfernt; - temporäre Protokollierung wurde zurückgenommen; - Konfigurationsstand wurde gesichert; - Ursache, Änderung, Rückweg und Prävention wurden dokumentiert. Eine erfolgreiche Policy-Simulation oder ein einzelner steigender Regelzähler ist keine ausreichende Gesamtverifikation. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: Quelle: Ziel: Protokoll: Erwarteter Pfad: Tatsächlicher Pfad: Firewall: Virtueller Kontext: Eingang: Ausgang: Originaldatenfluss: Ziel-IP:Port> Übersetzter Datenfluss: NAT-Ziel-IP:Port> Routingentscheidung: Erwartete Regel: Tatsächlich passende Regel: Sicherheitsprofile: Sitzungs-ID: Pakete und Bytes: Sitzungsendgrund: Protokollbefund: Paketaufzeichnung: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] betroffenen Client erfasst - [ ] betroffene Anwendung erfasst - [ ] Quelladresse ermittelt - [ ] Quellport ermittelt - [ ] Zieladresse ermittelt - [ ] Zielport ermittelt - [ ] Protokoll bestimmt - [ ] IPv4 und IPv6 unterschieden - [ ] erwarteten Datenfluss dokumentiert - [ ] Fehlerumfang bestimmt - [ ] lokale Host-Firewalls berücksichtigt - [ ] tatsächlichen Netzwerkpfad nachgewiesen - [ ] tatsächlich durchlaufene Firewall bestimmt - [ ] aktiven Clusterknoten bestimmt - [ ] richtigen Mandanten oder Kontext bestimmt - [ ] Eingangsschnittstelle bestimmt - [ ] Ausgangsschnittstelle bestimmt - [ ] Quellzone bestimmt - [ ] Zielzone bestimmt - [ ] Routingentscheidung geprüft - [ ] VRF oder virtuellen Router geprüft - [ ] Policy-Based Routing berücksichtigt - [ ] Originaladressen dokumentiert - [ ] Originalports dokumentiert - [ ] NAT-Adressen dokumentiert - [ ] NAT-Ports dokumentiert - [ ] NAT-Regel bestimmt - [ ] aktive Sicherheitsrichtlinie bestimmt - [ ] Regel-ID dokumentiert - [ ] Regelposition oder Priorität dokumentiert - [ ] Regelreihenfolge geprüft - [ ] globale Regeln geprüft - [ ] geerbte Regeln geprüft - [ ] implizite Standardaktion geprüft - [ ] ACL-Bindung geprüft - [ ] aktive Konfigurationsversion geprüft - [ ] Deploymentstatus geprüft - [ ] Cluster-Synchronisation geprüft - [ ] Quellobjekt aufgelöst - [ ] Zielobjekt aufgelöst - [ ] Dienstobjekt aufgelöst - [ ] verschachtelte Gruppen geprüft - [ ] FQDN-Objekt geprüft - [ ] Firewall- und Client-DNS-Ergebnis verglichen - [ ] Zeitplan geprüft - [ ] Benutzer- oder Geräteidentität geprüft - [ ] erkannte Anwendung geprüft - [ ] Sicherheitsprofile geprüft - [ ] Policy-Match-Test durchgeführt - [ ] Simulation nicht als alleinigen Nachweis verwendet - [ ] Ausgangszähler dokumentiert - [ ] kontrollierten Test durchgeführt - [ ] Regelzähler erneut geprüft - [ ] Firewallprotokolle korreliert - [ ] erlaubende und blockierende Ereignisse unterschieden - [ ] Sitzungstabelle geprüft - [ ] Sitzungs-ID dokumentiert - [ ] TCP-Zustand geprüft - [ ] UDP-Pseudositzung berücksichtigt - [ ] ICMP-Typ und Code berücksichtigt - [ ] Pakete je Richtung geprüft - [ ] Bytes je Richtung geprüft - [ ] Sitzungsendgrund ausgewertet - [ ] bestehende und neue Sitzung unterschieden - [ ] Sitzungstimeouts geprüft - [ ] bei Bedarf Eingangscapture durchgeführt - [ ] bei Bedarf Ausgangscapture durchgeführt - [ ] Hin- und Rückverkehr verglichen - [ ] Hardware-Offloading berücksichtigt - [ ] weitere Netzwerk-ACLs geprüft - [ ] Cloud Security Groups geprüft - [ ] Cloud-Subnetz-ACLs geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung verifiziert - [ ] repräsentative weitere Datenflüsse geprüft - [ ] temporäre Testregel entfernt - [ ] temporäre Protokollierung zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Beispiel | |---|---| | Datenfluss dokumentieren | `192.0.2.100:53124 -> 198.51.100.25:443/TCP` | | Cisco IOS ACLs anzeigen | `show ip access-lists` | | Cisco IOS ACL-Bindung prüfen | `show ip interface` | | ASA ACLs anzeigen | `show access-list` | | ASA ACL-Bindung anzeigen | `show access-group` | | ASA Sitzungen anzeigen | `show conn` | | ASA Sitzung nach Adresse filtern | `show conn address 192.0.2.100` | | ASA NAT-Zustand anzeigen | `show xlate` | | ASA Route anzeigen | `show route` | | ASA Datenfluss simulieren | `packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed` | | ASA Drop-Zähler anzeigen | `show asp drop` | | Juniper Policies anzeigen | `show security policies` | | Juniper Policy-Treffer anzeigen | `show security policies hit-count` | | Juniper Sitzungen anzeigen | `show security flow session` | | Juniper Route prüfen | `show route 198.51.100.25` | | Palo Alto Sitzung suchen | `show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443` | | Palo Alto Route prüfen | `test routing fib-lookup virtual-router ip 198.51.100.25` | | Linux nftables anzeigen | `sudo nft list ruleset` | | Linux nftables mit Handles | `sudo nft -a list ruleset` | | Linux Routing anzeigen | `ip route show` | | Linux IPv6-Routing anzeigen | `ip -6 route show` | | Linux Conntrack anzeigen | `sudo conntrack -L` | Befehle, die nicht als erste Diagnosemaßnahme verwendet werden dürfen: ```text clear conn clear xlate clear access-list counters clear security flow session clear session all conntrack -F nft flush ruleset iptables -F policy commit ohne geprüften Änderungsplan Firewall deaktivieren Cluster-Failover erzwingen Firewalldienst neu starten allgemeine any-any-Freigabe erstellen Sicherheitsprofile global deaktivieren ``` --- **Quellen** **Grundlagen und Standards** - [NIST SP 800-41 Revision 1 – Guidelines on Firewalls and Firewall Policy](https://csrc.nist.gov/pubs/sp/800/41/r1/final) - [RFC 793 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc793) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 4443 – Internet Control Message Protocol for IPv6](https://datatracker.ietf.org/doc/html/rfc4443) - [RFC 3022 – Traditional IP Network Address Translator](https://datatracker.ietf.org/doc/html/rfc3022) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 7857 – NAT Behavioral Requirements Updates](https://datatracker.ietf.org/doc/html/rfc7857) **Cisco** - [Cisco – Configure IP Access Lists](https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html) - [Cisco Secure Firewall ASA – Access Rules](https://www.cisco.com/c/en/us/td/docs/security/asa/asa919/configuration/firewall/asa-919-firewall-config/access-rules.html) - [Cisco Secure Firewall ASA – `packet-tracer` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/pa-pn-commands.html) - [Cisco Secure Firewall ASA – `show` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/S/asa-command-ref-S/show-t-commands.html) - [Cisco Secure Firewall ASA – `show asp drop` Usage](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/show_asp_drop_command_usage/show-asp-drop-command-usage.html) **Juniper Networks** - [Juniper – Configuring Security Policies](https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-policy-configuration.html) - [Juniper – Reordering Security Policies](https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-reordering-policies.html) - [Juniper – `show security match-policies`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-match-policies.html) - [Juniper – Monitoring and Troubleshooting Security Policies](https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/monitoring-troubleshooting-security-policy.html) **Palo Alto Networks** - [Palo Alto Networks – Security Policy Rules](https://docs.paloaltonetworks.com/network-security/security-policy/administration/security-rules) - [Palo Alto Networks – Security Policy](https://docs.paloaltonetworks.com/network-security/security-policy/administration/security-policy) - [Palo Alto Networks – Security Policy Rule Best Practices](https://docs.paloaltonetworks.com/best-practices/security-policy-best-practices/security-policy-best-practices/deploy-security-policy-best-practices/security-policy-rule-best-practices) - [Palo Alto Networks – Traffic Log Fields](https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslog-field-descriptions/traffic-log-fields) **Amazon Web Services** - [AWS – Control Subnet Traffic with Network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) - [AWS – Control Traffic Using Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) - [AWS – Security Group Rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) - [AWS – Network ACL Examples](https://docs.aws.amazon.com/vpc/latest/userguide/nacl-examples.html) - [AWS – Infrastructure Security in Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html) **Microsoft Azure** - [Microsoft Learn – Azure Network Security Groups Overview](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview) - [Microsoft Learn – Azure Firewall Rule Processing Logic](https://learn.microsoft.com/en-us/azure/firewall/rule-processing) - [Microsoft Learn – Azure Virtual Network Traffic Routing](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview) - [Microsoft Learn – Azure Network Security Best Practices](https://learn.microsoft.com/en-us/azure/security/fundamentals/network-best-practices) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet. # 9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking Bei asymmetrischem Routing verwenden Hin- und Rückverkehr einer Kommunikation unterschiedliche Netzwerkpfade. Für gewöhnliche Router ist das nicht grundsätzlich fehlerhaft: Jeder Router entscheidet für jedes Paket anhand seiner eigenen Routingtabelle. Zustandsbehaftete Firewalls, NAT-Gateways, Load Balancer und andere Stateful-Systeme müssen jedoch zusammengehörige Pakete einer gespeicherten Sitzung zuordnen können. Erreicht der Verbindungsaufbau eine Firewall, der Rückverkehr aber eine andere Firewall ohne synchronisierten Sitzungszustand, kann das Antwortpaket als unbekannt oder ungültig verworfen werden. Eine vorhandene Freigaberegel löst dieses Problem nicht, weil nicht die Regel, sondern der fehlende Sitzungszustand die Ursache ist. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - ob Hin- und Rückverkehr denselben zustandsbehafteten Datenpfad verwenden; - welche Firewall oder welcher Clusterknoten eine Sitzung angelegt hat; - ob eine passende Sitzungstabelle vorhanden ist; - welchen Zustand eine TCP-, UDP- oder ICMP-Kommunikation besitzt; - ob Connection Tracking ausgelastet oder fehlerhaft ist; - ob ECMP, Policy-Based Routing, dynamisches Routing oder NAT eine Asymmetrie erzeugt; - ob Sitzungszustände zwischen HA-Knoten synchronisiert werden; - ob bestehende Sitzungen einen Test verfälschen; - an welcher Stelle der Hin- oder Rückweg abweicht; - wie eine Routing- oder Sitzungsänderung kontrolliert verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Sessiontabellen und Connection Tracking enthalten den aktuellen Zustand produktiver Verbindungen. Unkontrollierte Eingriffe können gleichzeitig unterbrechen: - Benutzerverbindungen; - Datenbankverbindungen; - VPN-Tunnel; - Dateiübertragungen; - VoIP-Sitzungen; - Streamingverbindungen; - Backups; - Replikation; - Clusterkommunikation; - Verwaltungszugriffe. Nicht als erste Diagnosemaßnahme geeignet sind: - vollständige Sessiontabelle löschen; - Conntrack-Tabelle leeren; - Firewallcluster neu starten; - Failover erzwingen; - Routingprotokoll neu starten; - ECMP vollständig deaktivieren; - produktive Routen ungeprüft entfernen; - Source NAT pauschal aktivieren; - Stateful Inspection deaktivieren; - TCP State Bypass einschalten; - Timeouts ohne Nachweis erhöhen; - Conntrack-Maximalwert ohne Kapazitätsprüfung verändern; - Hardware-Offloading global abschalten; - allgemeine Stateless-Regeln erstellen; - Paketprüfungen global lockern. Vor einer Änderung sind mindestens zu dokumentieren: - Ausgangszustand; - betroffene Datenflüsse; - aktuelle Route in beiden Richtungen; - aktive Sitzung; - zuständiger Firewallknoten; - NAT-Zustand; - Clusterzustand; - Risiko; - Rückweg; - Erfolgskriterium; - Wartungsfenster; - verantwortliche Freigabe. --- **Symmetrischen und asymmetrischen Pfad unterscheiden** Symmetrischer Pfad: ```text Hinweg: Client -> Router A -> Firewall A -> Router B -> Server Rückweg: Server -> Router B -> Firewall A -> Router A -> Client ``` Asymmetrischer Pfad: ```text Hinweg: Client -> Router A -> Firewall A -> Router B -> Server Rückweg: Server -> Router C -> Firewall B -> Router D -> Client ``` Entscheidend ist nicht, ob jeder einzelne Router identisch ist. Entscheidend ist, ob zustandsabhängige Komponenten in beiden Richtungen den benötigten Sitzungszustand besitzen. | Situation | Mögliche Wirkung | |---|---| | Hin- und Rückweg nutzen dieselbe Stateful Firewall | Sitzung kann normalerweise korrekt zugeordnet werden | | unterschiedliche Router, aber dieselbe Firewall | kann funktionieren | | unterschiedliche Clusterknoten mit funktionierender State-Synchronisation | kann funktionieren | | unterschiedliche nicht synchronisierte Firewalls | Rückverkehr kann verworfen werden | | rein zustandslose ACLs in beiden Richtungen | kann mit passenden Gegenregeln funktionieren | | NAT nur auf dem Hinweggerät | Rückverkehr kann falsches Ziel oder falschen Pfad verwenden | | asymmetrischer Pfad durch Sicherheitsprofil | vollständige Inhaltsprüfung kann unmöglich sein | | Rückweg umgeht die Firewall vollständig | Firewall sieht nur eine Richtung und Protokolle bleiben unvollständig | --- **Asymmetrie ist nicht automatisch ein Routingfehler** IP-Routing verlangt nicht grundsätzlich, dass Hin- und Rückweg identisch sind. Asymmetrie wird problematisch, wenn eine beteiligte Komponente Informationen aus beiden Richtungen benötigt. Typische zustandsabhängige Komponenten: - Stateful Firewall; - NAT-Gateway; - Intrusion Prevention System; - Application Delivery Controller; - Load Balancer; - Reverse Proxy; - VPN-Gateway; - WAN-Optimierer; - DDoS-Schutzsystem; - Carrier-Grade NAT; - Cloud Network Firewall; - Linux-Router mit Netfilter Connection Tracking. Die Diagnosefrage lautet deshalb nicht nur: ```text Existiert ein Rückweg? ``` Sondern: ```text Verwendet der Rückweg alle zustandsabhängigen Komponenten, die den Hinweg verarbeitet haben? ``` --- **Einen Datenfluss eindeutig identifizieren** Für TCP und UDP wird ein Datenfluss üblicherweise über das Fünf-Tupel beschrieben: ```text Quelladresse Quellport Zieladresse Zielport IP-Protokoll ``` Beispiel: ```text Originalrichtung: 192.0.2.100:53124 -> 198.51.100.25:443/TCP Antwortrichtung: 198.51.100.25:443 -> 192.0.2.100:53124/TCP ``` Zusätzlich zu dokumentieren sind: - Datum und Uhrzeit; - Zeitzone; - Eingangs- und Ausgangsschnittstelle; - Quell- und Zielzone; - VRF oder Routinginstanz; - ursprüngliche Adressen; - übersetzte Adressen; - ursprüngliche Ports; - übersetzte Ports; - Firewallknoten; - Sitzungs-ID; - Routingentscheidung; - Anwendung; - Tunnel oder VPN; - Mandant oder virtueller Kontext. Nur die Zieladresse und den Zielport zu dokumentieren reicht nicht. Mehrere gleichzeitige Sitzungen können dasselbe Ziel verwenden und sich nur durch Quelladresse oder Quellport unterscheiden. --- **Sessiontabelle und Connection Tracking** Eine Sessiontabelle speichert Informationen über aktuell bekannte Datenflüsse. Linux Netfilter bezeichnet diese Funktion als Connection Tracking oder kurz Conntrack. Ein Eintrag kann unter anderem enthalten: ```text IP-Protokoll Original-Quelladresse Original-Quellport Original-Zieladresse Original-Zielport Antwort-Quelladresse Antwort-Quellport Antwort-Zieladresse Antwort-Zielport TCP-Zustand NAT-Status Sitzungsmarkierung Timeout Pakete je Richtung Bytes je Richtung erkannte Anwendung passende Richtlinie Eingangs- und Ausgangsschnittstelle Clusterbesitzer ``` Die Sessiontabelle ermöglicht unter anderem: - Rückverkehr einer erlaubten Verbindung zuordnen; - ungültige TCP-Pakete erkennen; - UDP-Antworten einer Pseudositzung zuordnen; - ICMP-Fehler einer ursprünglichen Kommunikation zuordnen; - NAT in beiden Richtungen konsistent anwenden; - zusammengehörige Anwendungsdatenflüsse erkennen; - Sitzungen zwischen HA-Knoten synchronisieren. --- **Conntrack-Zustände** Bei Netfilter und vergleichbaren Systemen werden häufig folgende generische Zustände unterschieden: | Zustand | Bedeutung | |---|---| | `NEW` | gültiger Beginn oder frühes Paket eines noch nicht in beide Richtungen bestätigten Datenflusses | | `ESTABLISHED` | gültige Pakete wurden in beiden Richtungen gesehen | | `RELATED` | neuer Datenfluss steht in erwarteter Beziehung zu einer vorhandenen Verbindung | | `INVALID` | Paket kann keiner gültigen Verbindung zugeordnet werden oder verletzt Erwartungen | | `UNTRACKED` | Paket wurde ausdrücklich von Connection Tracking ausgenommen | Die Zustände sind nicht mit dem gleichnamigen TCP-Zustand `ESTABLISHED` gleichzusetzen. Ein Firewall- oder Conntrack-Zustand beschreibt die Sicht des Tracking-Systems. Beispiel eines üblichen nftables-Prinzips: ```nft ct state established,related accept ct state invalid drop ``` Das ist nur ein vereinfachtes Beispiel. Das vollständige Regelwerk, die Richtung und der Sicherheitsbedarf müssen separat geprüft werden. --- **TCP-Zustände innerhalb der Sitzung** TCP besitzt zusätzlich protokollspezifische Zustände. | Zustand | Einordnung | |---|---| | `SYN_SENT` | Verbindungsanfrage wurde in Originalrichtung gesehen | | `SYN_RECV` | passende Antwort mit SYN und ACK wurde gesehen | | `ESTABLISHED` | TCP-Verbindungsaufbau wurde bestätigt | | `FIN_WAIT` | eine Seite hat die reguläre Beendigung begonnen | | `CLOSE_WAIT` | Gegenstelle hat die Beendigung begonnen | | `LAST_ACK` | letztes Bestätigungspaket für Verbindungsabbau wird erwartet | | `TIME_WAIT` | Schutzphase nach regulärem Verbindungsende | | `CLOSE` | Verbindung gilt als geschlossen | | `RETRANS` oder vergleichbarer Zustand | Wiederholungen oder fehlende Bestätigungen wurden erkannt | | `UNACK` | Daten oder Steuerinformationen wurden noch nicht bestätigt | Die genaue Benennung und Zustandslogik hängen vom verwendeten Produkt ab. --- **Typischen Conntrack-Eintrag lesen** Beispiel: ```text tcp 6 431982 ESTABLISHED src=192.0.2.100 dst=198.51.100.25 sport=53124 dport=443 src=198.51.100.25 dst=192.0.2.100 sport=443 dport=53124 packets=169 bytes=14322 packets=113 bytes=34787 [ASSURED] ``` Einordnung: | Feld | Bedeutung | |---|---| | `tcp` | Transportprotokoll | | `6` | IP-Protokollnummer für TCP | | `431982` | verbleibender Timeout in Sekunden | | `ESTABLISHED` | protokollspezifischer Tracking-Zustand | | erster Adressblock | Originalrichtung | | zweiter Adressblock | Antwortrichtung | | `packets` | gezählte Pakete der jeweiligen Richtung | | `bytes` | gezählte Bytes der jeweiligen Richtung | | `[ASSURED]` | Antwortverkehr und ausreichend bestätigter Zustand wurden erkannt | Die genaue Darstellung hängt von Kernel-, Conntrack- und Distributionsversion ab. --- **Wichtige Conntrack-Markierungen** | Markierung | Bedeutung | |---|---| | `[UNREPLIED]` | bisher wurde keine passende Antwortrichtung gesehen | | `[ASSURED]` | der Datenfluss wurde in beiden Richtungen ausreichend bestätigt | | `src-nat` | Quellübersetzung ist beteiligt | | `dst-nat` | Zielübersetzung ist beteiligt | | `expected` | Datenfluss wurde durch eine Erwartung einer anderen Verbindung angekündigt | | `seen-reply` | Antwortverkehr wurde erkannt | | `offload` | Sitzung wurde in einen beschleunigten Datenpfad ausgelagert | | `hw-offload` | Verarbeitung erfolgt zumindest teilweise in Hardware | `[UNREPLIED]` bedeutet nicht automatisch, dass der Server nicht geantwortet hat. Die Antwort könnte: - einen anderen Rückweg genommen haben; - vor dem Tracking-System verworfen worden sein; - nach dem Timeout eingetroffen sein; - eine abweichende Adresse oder einen abweichenden Port verwenden; - von einer anderen Firewall verarbeitet worden sein. --- **RELATED-Verbindungen und Erwartungen** Einige Protokolle verwenden zusätzliche Datenverbindungen, die zu einer bestehenden Steuerverbindung gehören. Mögliche Beispiele: - FTP; - bestimmte RPC-Verfahren; - SIP und dynamische Medienströme; - TFTP; - ältere oder herstellerspezifische Protokolle. Ein Connection-Tracking-Helper kann für den zusätzlichen Datenfluss eine Erwartung anlegen. Dieser Datenfluss kann anschließend als `RELATED` eingeordnet werden. Zu prüfen sind: - wird ein Helper verwendet? - ist der Helper ausdrücklich zugewiesen? - ist die Protokollerkennung verschlüsselt oder unverschlüsselt? - stimmen dynamisch ausgehandelte Adressen und Ports? - verändert NAT die Nutzdaten? - nimmt der zusätzliche Datenfluss denselben zustandsbehafteten Pfad? - ist der Helper auf der verwendeten Version noch vorgesehen und sicher? Helpers dürfen nicht pauschal aktiviert werden. Sie greifen in die Protokollverarbeitung ein und können zusätzliche Sicherheits- und Kompatibilitätsauswirkungen besitzen. --- **Warum asymmetrischer Rückverkehr verworfen wird** Beispiel: 1. Client sendet ein TCP-`SYN`. 2. Firewall A prüft die Sicherheitsregel. 3. Firewall A legt eine Sitzung an. 4. Server sendet `SYN, ACK`. 5. Routing leitet die Antwort über Firewall B. 6. Firewall B besitzt keine passende Sitzung. 7. Firewall B sieht ein Antwortpaket ohne bekannten Verbindungsaufbau. 8. Firewall B verwirft es als unbekannt oder ungültig. Vereinfachte Sicht: ```text Firewall A: SYN gesehen Sitzung vorhanden SYN-ACK nicht gesehen Firewall B: SYN nicht gesehen Sitzung nicht vorhanden SYN-ACK gesehen ``` Mögliche Symptome: - Client sendet wiederholt `SYN`; - Server sendet wiederholt `SYN, ACK`; - Client empfängt keine Antwort; - eine Firewall zeigt `SYN_SENT` oder `[UNREPLIED]`; - andere Firewall zeigt Invalid-State-Drops; - Regelprotokolle zeigen nur eine Richtung; - Verbindung funktioniert nach manchen Routingänderungen zufällig; - Verbindung funktioniert nur über einen bestimmten Clusterknoten. --- **Asymmetrie innerhalb derselben Firewall** Auch wenn beide Richtungen dieselbe physische Firewall verwenden, können unterschiedliche Kontexte die Zuordnung verhindern: - unterschiedliche virtuelle Systeme; - unterschiedliche VRFs; - unterschiedliche Sicherheitszonen; - unterschiedliche Routinginstanzen; - unterschiedliche Mandanten; - unterschiedliche Tunnel; - unterschiedliche logische Systeme; - unterschiedliche virtuelle Router; - getrennte Sessiontabellen. Deshalb muss nicht nur der Gerätename, sondern auch der vollständige Verarbeitungskontext übereinstimmen. --- **Häufige Ursachen asymmetrischer Pfade** - unterschiedliche Standardrouten; - unterschiedlich gelernte dynamische Routen; - ECMP; - per-Packet Load Balancing; - Policy-Based Routing; - Source-Based Routing; - mehrere Internetanschlüsse; - SD-WAN-Pfadauswahl; - BGP-Multihoming; - unterschiedliche OSPF-Kosten; - längeres oder kürzeres Präfix; - statische Route nur auf einer Seite; - VRF-Leak; - fehlende Rückroute; - Load Balancer; - Direct Server Return; - NAT Gateway; - unterschiedliche VPN-Tunnel; - mehrere Transit-Gateways; - Cloud User Defined Routes; - Kubernetes- oder Overlay-Netz; - Cluster mit unvollständiger State-Synchronisation; - Failover während einer aktiven Sitzung; - fehlerhafte Route Redistribution; - serverseitige zweite Netzwerkkarte; - falsches Standardgateway des Servers; - Proxy- oder Reverse-Proxy-Pfad; - Container- oder Host-NAT. --- **Längstes Präfix und Routenauswahl** Router bevorzugen grundsätzlich die spezifischste passende Route. Beispiel: ```text 10.0.0.0/8 über Firewall A 10.20.30.0/24 über Firewall B ``` Für das Ziel: ```text 10.20.30.40 ``` wird die spezifischere Route `/24` verwendet. Eine allgemeine Standardroute über die erwartete Firewall garantiert deshalb nicht, dass ein bestimmtes Ziel tatsächlich diese Firewall verwendet. Zu prüfen sind: - Zielpräfix; - Präfixlänge; - Routingprotokoll; - administrative Distanz oder Preference; - Metrik; - nächster Hop; - Ausgangsschnittstelle; - Routinginstanz; - Route Policy; - aktive und alternative Route. --- **ECMP** Equal-Cost Multi-Path ermöglicht die Nutzung mehrerer gleichwertiger Routen. Mögliche Verteilungsverfahren: - pro Paket; - pro Datenfluss; - Hash über Quell- und Zieladresse; - Hash über Fünf-Tupel; - gewichtete Verteilung; - resilienter Hash; - dynamische Auslastungsverteilung. Per-Flow-ECMP hält normalerweise alle Pakete eines Datenflusses auf demselben Hinweg. Es garantiert jedoch nicht automatisch, dass die Gegenstelle für den Rückweg denselben Firewallknoten auswählt. Zu prüfen sind: - welche Felder in den Hash einfließen; - ob Hin- und Rückrichtung denselben Hash ergeben; - ob beide Seiten dieselben Pfade kennen; - ob Link- oder Routingänderungen den Hash neu verteilen; - ob Clusterknoten Sitzungen synchronisieren; - ob der nächste Hop ein Stateful-Gerät ist; - ob Fragmentierung die Hash-Auswahl verändert; - ob NAT vor oder nach der ECMP-Auswahl erfolgt. Ein Problem, das nur bei einem Teil der Verbindungen auftritt, kann auf ECMP oder eine fehlerhafte Teilstrecke hinweisen. --- **Policy-Based Routing** Policy-Based Routing kann die normale Zielroutenauswahl überschreiben. Mögliche Kriterien: - Quelladresse; - Zieladresse; - Protokoll; - Quellport; - Zielport; - Eingangsschnittstelle; - DSCP; - Benutzer; - Anwendung; - Sicherheitszone; - Routingmarkierung. Zu prüfen sind: - passende PBR-Regel; - Regelreihenfolge; - nächster Hop; - Zustand des nächsten Hops; - Fallbackverhalten; - Rückrichtung; - Routingmarkierungen; - NAT-Abhängigkeit; - Verfügbarkeitstracking; - lokale Ausnahmen. Typischer Fehler: ```text Hinweg: PBR erzwingt Firewall A Rückweg: normale Route verwendet Firewall B ``` Die korrekte Sicherheitsregel auf beiden Firewalls löst den fehlenden gemeinsamen Sitzungszustand nicht. --- **Dynamisches Routing** Bei OSPF, IS-IS, BGP oder anderen dynamischen Routingprotokollen können sich Hin- und Rückwege unabhängig ändern. Zu prüfen sind: - empfangene Präfixe; - angekündigte Präfixe; - Route Policies; - Filterlisten; - lokale Preference; - MED; - AS-PATH; - OSPF-Kosten; - administrative Distanz; - Route Redistribution; - zusammengefasste Routen; - spezifischere Präfixe; - ECMP; - Konvergenzzeit; - Flapping; - Graceful Restart; - aktiver nächster Hop; - Zeitpunkt der letzten Änderung. Ein Pfad kann im stabilen Zustand symmetrisch und während einer Routingkonvergenz vorübergehend asymmetrisch sein. --- **Mehrere Netzwerkkarten am Server** Ein Server mit mehreren Netzwerkkarten kann den Rückverkehr über eine andere Schnittstelle senden. Zu prüfen sind: - IP-Adresse je Schnittstelle; - Standardgateway; - spezifische Routen; - Routingmetrik; - Source Address Selection; - Policy Routing; - Bonding oder Teaming; - VRF; - Container- oder Namespace-Routen; - virtuelle Switches; - Hypervisor-Routing; - Reverse Path Filtering. Beispiel: ```text Anfrage erreicht: eth1 / 10.20.30.40 Serverantwort verlässt: eth0 / Standardgateway über anderes Netz ``` Der Serverdienst kann korrekt antworten, während die Antwort einen unzulässigen oder nicht zustandsbehafteten Rückweg verwendet. --- **Reverse Path Filtering** Reverse Path Filtering prüft, ob die Quelladresse eines eingehenden Pakets aus Sicht der Routingtabelle über einen plausiblen Pfad erreichbar ist. Unter Linux sind typischerweise folgende Betriebsarten relevant: - deaktiviert; - strikte Prüfung; - lose Prüfung. Lesende Prüfung: ```bash sysctl net.ipv4.conf.all.rp_filter ``` ```bash sysctl net.ipv4.conf.default.rp_filter ``` Schnittstellenspezifisch: ```bash sysctl net.ipv4.conf.eth0.rp_filter ``` Eine strikte Prüfung kann legitimen asymmetrischen Verkehr verwerfen. Sie darf jedoch nicht ohne Sicherheitsbewertung deaktiviert werden. Zuerst sind Route, Quelladresse und tatsächlicher Datenpfad nachzuweisen. --- **NAT und asymmetrische Pfade** NAT benötigt normalerweise einen konsistenten Zustand für Original- und Antwortrichtung. Beispiel mit Source NAT: ```text Originalrichtung: 10.10.20.25:53124 -> 203.0.113.80:443 Nach SNAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Der Server antwortet an: ```text 203.0.113.80:443 -> 198.51.100.5:61001 ``` Nur die NAT-Komponente mit der passenden Übersetzung weiß, dass die Antwort zurückübersetzt werden muss zu: ```text 203.0.113.80:443 -> 10.10.20.25:53124 ``` Erreicht die Antwort ein anderes NAT-Gateway ohne synchronisierten Zustand, fehlt die Zuordnung. Zu prüfen sind: - welches Gerät SNAT oder DNAT durchführt; - Original- und Übersetzungsadressen; - Original- und Übersetzungsports; - NAT-Sitzungs-ID; - NAT-Pool; - Port Address Translation; - Rückroute zur übersetzten Adresse; - HA-Synchronisation; - Porterschöpfung; - NAT-Regelreihenfolge; - Hairpin- oder U-Turn-NAT; - doppelte NAT-Verarbeitung. Source NAT kann bewusst verwendet werden, um den Rückverkehr zu einer bestimmten Komponente zurückzuführen. Diese Maßnahme verändert jedoch Quelladressen und kann Protokollierung, Zugriffskontrolle und Nachvollziehbarkeit beeinflussen. --- **Load Balancer und Direct Server Return** Bei einem normalen Proxy- oder Full-NAT-Load-Balancer verlaufen Hin- und Rückverkehr häufig über den Load Balancer. Bei Direct Server Return kann der Server direkt zum Client antworten, ohne den Load Balancer erneut zu durchlaufen. Das kann beabsichtigt sein, erfordert aber ein passendes Design. Zu prüfen sind: - Betriebsart des Load Balancers; - Full Proxy, NAT oder Direct Server Return; - virtuelle IP-Adresse; - Backendadresse; - Source NAT; - Rückroute des Backends; - Firewallzustand; - Health Probes; - Client-IP-Erhaltung; - Server-Loopschnittstelle; - ARP-Verhalten; - Sicherheitsprofile; - Protokollierung in beiden Richtungen. Eine Firewall darf nicht fälschlich erwarten, beide Richtungen zu sehen, wenn das freigegebene Architekturdesign bewusst Direct Server Return verwendet. --- **Firewallcluster und State-Synchronisation** Ein HA-Cluster kann unter anderem synchronisieren: - TCP-Sitzungen; - UDP-Pseudositzungen; - NAT-Übersetzungen; - VPN-Zustände; - Authentifizierungsinformationen; - Sequenznummern; - Zeitstempel; - Anwendungszustände; - Persistenzinformationen. Nicht jede Sitzungsart und nicht jede Funktion wird zwangsläufig synchronisiert. Zu prüfen sind: - Clusterbetriebsart; - Active/Passive oder Active/Active; - Zustandssynchronisationsschnittstelle; - Paketverlust auf dem Synchronisationslink; - Latenz; - Synchronisationswarteschlangen; - unterstützte Sitzungsarten; - NAT-Synchronisation; - Anwendungssynchronisation; - Softwareversionsgleichheit; - Konfigurationsgleichheit; - aktiver Sitzungseigentümer; - letzter Failoverzeitpunkt; - Split-Brain-Zustand; - Neustart eines Knotens; - Initialsynchronisation; - Tabellenfüllstand. Eine erfolgreiche Konfigurationssynchronisation beweist keine erfolgreiche Sitzungssynchronisation. --- **Active/Passive** Bei Active/Passive verarbeitet normalerweise nur der aktive Knoten den produktiven Verkehr. Der passive Knoten erhält je nach Produkt Sitzungsinformationen. Nach einem Failover sind folgende Ergebnisse möglich: - bestehende Sitzungen laufen weiter; - nur bestimmte Sitzungsarten laufen weiter; - NAT bleibt erhalten, Anwendungszustand jedoch nicht; - Verbindungen müssen neu aufgebaut werden; - Sitzungen gehen wegen unvollständiger Synchronisation verloren; - der neue aktive Knoten besitzt veraltete Zustände. Zu prüfen sind: - war die Sitzung vor dem Failover synchronisiert? - war die Synchronisationsschnittstelle fehlerfrei? - besitzt der neue aktive Knoten die passende Sitzung? - blieb die NAT-Zuordnung erhalten? - wurde die Route zusammen mit der Firewallrolle umgeschaltet? - erreichen beide Richtungen den neuen aktiven Knoten? --- **Active/Active** Bei Active/Active können mehrere Knoten gleichzeitig produktiven Verkehr verarbeiten. Das erfordert je nach Architektur: - Flow-Pinning; - konsistentes Hashing; - State Sharing; - Session Ownership; - Cluster-Forwarding; - symmetrische Next-Hop-Auswahl; - funktionierende NAT-Synchronisation. Besonders kritisch ist: ```text SYN: Knoten A SYN-ACK: Knoten B Folgepakete: abwechselnd A und B ``` Wenn die Plattform diesen Datenpfad nicht ausdrücklich unterstützt, können Sitzungen verworfen oder Sicherheitsprüfungen umgangen werden. --- **Synchronisationsverzögerung** State-Synchronisation erfolgt nicht immer vollständig synchron vor der Paketweiterleitung. Bei kurzen Datenflüssen oder einem schnellen Pfadwechsel kann das Antwortpaket den zweiten Knoten erreichen, bevor der Zustand übertragen wurde. Mögliche Symptome: - nur erste Verbindung nach Failover scheitert; - Wiederholung funktioniert; - sehr kurze UDP-Anfragen sind besonders betroffen; - Probleme treten nur unter hoher Last auf; - Clusterprotokolle zeigen verlorene oder verspätete Updates; - Sitzung ist auf dem aktiven, aber nicht auf dem anderen Knoten sichtbar. Die Lösung ist nicht automatisch ein längerer Timeout. Zu prüfen sind Synchronisationslink, unterstützte Betriebsart, Flow-Pinning und Routingdesign. --- **Connection-Tracking-Kapazität** Eine Sessiontabelle besitzt eine begrenzte Kapazität. Bei Linux sind insbesondere relevant: ```text nf_conntrack_count nf_conntrack_max nf_conntrack_buckets ``` Lesende Prüfung: ```bash sysctl net.netfilter.nf_conntrack_count ``` ```bash sysctl net.netfilter.nf_conntrack_max ``` ```bash sysctl net.netfilter.nf_conntrack_buckets ``` Alternative direkte Anzeige: ```bash cat /proc/sys/net/netfilter/nf_conntrack_count ``` ```bash cat /proc/sys/net/netfilter/nf_conntrack_max ``` Auslastung berechnen: ```text Auslastung in Prozent = nf_conntrack_count / nf_conntrack_max × 100 ``` Beispiel: ```text nf_conntrack_count = 245760 nf_conntrack_max = 262144 Auslastung = 245760 / 262144 × 100 = 93,75 % ``` Ein hoher Tabellenfüllstand kann zu folgenden Symptomen führen: - neue Verbindungen schlagen fehl; - bestehende Sitzungen funktionieren weiterhin; - Kernel meldet volle Conntrack-Tabelle; - Einträge werden vorzeitig entfernt; - Drop- oder Insert-Failed-Zähler steigen; - UDP- oder Kurzzeitsitzungen erhöhen die Last stark; - NAT-Verbindungen können nicht mehr angelegt werden. Eine Vergrößerung von `nf_conntrack_max` benötigt eine Speicher- und Lastbewertung. Sie beseitigt keine Ursache wie Portscan, DDoS, fehlerhafte Anwendung oder ungeeignete Timeouts. --- **Conntrack-Statistiken** Sofern `conntrack-tools` installiert ist: ```bash sudo conntrack -S ``` Mögliche Statistikfelder sind: - gefundene Einträge; - Suchvorgänge; - eingefügte Einträge; - fehlgeschlagene Einfügungen; - Drops; - Early Drops; - Fehler; - Hash-Kollisionen; - zu lange Suchketten. Ein einzelner Gesamtzähler ohne Zeitbezug ist wenig aussagekräftig. Belastbarer Ablauf: 1. Zähler und Uhrzeit erfassen. 2. definierten Testzeitraum starten. 3. genau einen reproduzierbaren Test durchführen. 4. Zähler erneut erfassen. 5. Differenz mit Paketaufzeichnung und Protokollen korrelieren. --- **Timeouts** Sessiontabellen entfernen inaktive Einträge nach protokoll- und zustandsabhängigen Zeiträumen. Unter Linux können unter anderem relevant sein: ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_sent ``` ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv ``` ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_established ``` ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait ``` ```bash sysctl net.netfilter.nf_conntrack_udp_timeout ``` ```bash sysctl net.netfilter.nf_conntrack_udp_timeout_stream ``` ```bash sysctl net.netfilter.nf_conntrack_icmp_timeout ``` Die konkreten Werte sind Systemzustand und Konfiguration und dürfen nicht aus einer allgemeinen Dokumentation als garantierte lokale Werte übernommen werden. Typische Timeoutbefunde: | Befund | Mögliche Einordnung | |---|---| | Verbindung bricht nach fester Leerlaufzeit ab | Idle-Timeout | | neue Verbindung funktioniert sofort | vorherige Sitzung ist abgelaufen oder wurde verworfen | | UDP-Antwort kommt verspätet und wird verworfen | UDP-Tracking-Eintrag bereits entfernt | | Langzeitverbindungen scheitern unter Last | vorzeitiges Aging oder Tabellenknappheit | | nach Failover fehlen nur ältere Sitzungen | unvollständige Zustandssynchronisation | --- **Offloading berücksichtigen** Firewalls und Linux-Netfilter können etablierte Datenflüsse in einen beschleunigten Pfad oder in Hardware auslagern. Mögliche Auswirkungen: - allgemeine Softwarezähler steigen nicht bei jedem Paket; - Paketaufzeichnung auf der Steuer- oder Softwareebene sieht nicht alle Pakete; - Sitzungsdaten werden verzögert aktualisiert; - ein Flow erscheint als `offload` oder `hw-offload`; - Fehlerzähler befinden sich auf einer anderen Datenebene; - eine Änderung wirkt erst nach Rückkehr aus dem Offloadpfad oder nach Sitzungsende. Zu prüfen sind: - ist der Datenfluss ausgelagert? - wo werden Hardwarezähler angezeigt? - kann das Produkt gezielt einen Flow erfassen? - verändert die Diagnosefunktion den Offloadstatus? - besitzt jeder Clusterknoten eigene Hardwaretabellen? Offloading darf nicht pauschal deaktiviert werden, da dies die Leistungsfähigkeit der Firewall erheblich beeinflussen kann. --- **Hin- und Rückweg getrennt prüfen** Eine Traceroute nur vom Client zum Server zeigt nicht den Rückweg. Erforderlich sind nach Möglichkeit: ```text Test A: Client -> Server Test B: Server -> Client ``` Windows: ```powershell tracert 198.51.100.25 ``` ```powershell Test-NetConnection ` -ComputerName "198.51.100.25" ` -Port 443 ` -InformationLevel Detailed ``` Linux: ```bash traceroute 198.51.100.25 ``` ```bash tracepath 198.51.100.25 ``` macOS: ```bash traceroute 198.51.100.25 ``` Traceroute-Ergebnisse sind nur ein Teilnachweis. Firewalls können: - TTL-Fehlermeldungen unterdrücken; - transparent arbeiten; - auf Traceroute-Protokolle anders reagieren; - mehrere Pfade verwenden; - ICMP, UDP und TCP unterschiedlich routen; - im Rückweg nicht sichtbar sein. Für anwendungsnahes Tracing kann abhängig von Plattform und Freigabe ein TCP-basierter Traceroute zum tatsächlichen Zielport verwendet werden. --- **Lokale Routingentscheidung prüfen** Windows: ```powershell Get-NetRoute ` -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric ``` Bestimmte Zielroute: ```powershell Find-NetRoute ` -RemoteIPAddress "198.51.100.25" ``` Klassische Anzeige: ```cmd route print ``` Linux: ```bash ip route get 198.51.100.25 ``` Mit angenommener Quelladresse: ```bash ip route get 198.51.100.25 from 192.0.2.100 ``` Policy-Regeln: ```bash ip rule show ``` Alle Routingtabellen: ```bash ip route show table all ``` IPv6: ```bash ip -6 route get 2001:db8::25 ``` macOS: ```bash route -n get 198.51.100.25 ``` Die lokale Routenausgabe zeigt nur die Entscheidung des untersuchten Systems. Sie beweist nicht den vollständigen End-to-End-Pfad. --- **Linux-Conntrack lesend prüfen** Alle Einträge anzeigen: ```bash sudo conntrack -L ``` Nur TCP: ```bash sudo conntrack -L -p tcp ``` Nach Originalquelle und Originalziel filtern: ```bash sudo conntrack -L \ -p tcp \ -s 192.0.2.100 \ -d 198.51.100.25 \ --dport 443 ``` Nach UDP filtern: ```bash sudo conntrack -L \ -p udp \ -s 192.0.2.100 \ -d 198.51.100.53 \ --dport 53 ``` Anzahl anzeigen: ```bash sudo conntrack -C ``` Statistiken anzeigen: ```bash sudo conntrack -S ``` Conntrack-Ereignisse beobachten: ```bash sudo conntrack -E ``` Gezielt TCP-Ereignisse beobachten: ```bash sudo conntrack -E -p tcp ``` Mögliche Ereignisse: ```text [NEW] [UPDATE] [DESTROY] ``` Die Ereignisbeobachtung sollte auf einen kurzen Testzeitraum begrenzt werden. Auf stark ausgelasteten Systemen kann eine ungefilterte Ausgabe sehr groß werden und interne Kommunikationsdaten enthalten. --- **Direkte Kernelansicht** Falls `conntrack` nicht installiert ist, kann abhängig vom System eine Kernelansicht existieren: ```bash sudo cat /proc/net/nf_conntrack ``` Gezielte Textfilterung: ```bash sudo grep 'dst=198.51.100.25' /proc/net/nf_conntrack ``` Diese Schnittstelle kann fehlen oder durch Namespace- und Berechtigungseinstellungen eingeschränkt sein. Das `conntrack`-Werkzeug bietet normalerweise bessere Filter- und Ereignisfunktionen. --- **Netzwerk-Namespaces und Container** Container, Kubernetes und Linux-Netzwerk-Namespaces können eigene Routing-, Firewall- und Conntrack-Kontexte besitzen. Zu prüfen sind: - Host-Namespace; - Container-Namespace; - Pod-Namespace; - Bridge; - veth-Schnittstellen; - Overlay-Netz; - Service-NAT; - kube-proxy-Betriebsart; - CNI-Plugin; - Node-Firewall; - Cloud-Firewall; - eBPF-Datenpfad; - Host- und Podroute; - Rückweg zum ursprünglichen Node. Namespaces anzeigen: ```bash ip netns list ``` Routing in einem Namespace: ```bash sudo ip netns exec ip route show ``` Schnittstellen: ```bash sudo ip netns exec ip address show ``` Ein Conntrack-Eintrag auf dem Host muss anhand der vor und nach NAT sichtbaren Adressen geprüft werden. Die Anwendung kann innerhalb des Containers andere Adressen sehen als die Host-Firewall. --- **Cisco Secure Firewall ASA prüfen** Verbindungen anzeigen: ```text show conn ``` Nach Adresse filtern: ```text show conn address 192.0.2.100 ``` Anzahl und Kapazität: ```text show conn count ``` NAT-Zustände: ```text show xlate ``` HA-Zustand: ```text show failover ``` Routing: ```text show route ``` Drop-Zähler: ```text show asp drop ``` Datenfluss simulieren: ```text packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed ``` Zu vergleichen sind: - existiert die Sitzung? - welcher Knoten besitzt sie? - stimmen Original- und Übersetzungsadressen? - steigen Bytes in beiden Richtungen? - welcher TCP-Zustand oder welche Flags werden angezeigt? - sind Failover und State-Synchronisation fehlerfrei? - steigt ein Drop-Zähler beim kontrollierten Test? Cisco ASA bietet für bestimmte ausdrücklich geplante asymmetrische Szenarien einen TCP State Bypass. Dieser deaktiviert jedoch wesentliche zustandsabhängige Prüfungen und unterstützt nicht alle Funktionen. Er ist keine allgemeine Reparaturmaßnahme für fehlerhaftes Routing. --- **Juniper SRX prüfen** Aktive Sitzungen: ```text show security flow session ``` Nach Quelle: ```text show security flow session source-prefix 192.0.2.100 ``` Nach Ziel: ```text show security flow session destination-prefix 198.51.100.25 ``` Route: ```text show route 198.51.100.25 ``` Flow-Statistiken: ```text show security flow statistics ``` Clusterzustand: ```text show chassis cluster status ``` Zu prüfen sind: - Ingress- und Egress-Interface; - Quell- und Zielzone; - Sitzungsstatus; - NAT; - Timeout; - Pakete und Bytes; - Session Owner; - HA- oder Clusterknoten; - Drop-Statistiken; - verwendete Routinginstanz. Die verfügbaren Filter unterscheiden sich nach Junos-Version und Plattform. Die lokale CLI-Hilfe ist deshalb zusätzlich zu verwenden. --- **Palo Alto Networks prüfen** Sitzung nach Datenfluss suchen: ```text show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443 ``` Filtermöglichkeiten prüfen: ```text show session all filter ? ``` Routingentscheidung: ```text test routing fib-lookup virtual-router ip 198.51.100.25 ``` HA-Zustand: ```text show high-availability state ``` Zu prüfen sind: - Session-ID; - Session Owner; - Quell- und Zielzone; - Original- und NAT-Tupel; - Anwendung; - Sicherheitsregel; - Pakete und Bytes beider Richtungen; - Sitzungsendgrund; - Hardware-Offload; - HA-Synchronisation; - virtueller Router. Die genaue Syntax und Feldbezeichnung hängt von PAN-OS-Version, Plattform und Betriebsart ab. --- **AWS Network Firewall** AWS Network Firewall benötigt für zustandsbehaftete Verarbeitung, dass Anfrage und Antwort denselben Firewallendpunkt durchlaufen. Zu prüfen sind: - Firewallendpunkt je Availability Zone; - VPC-Routingtabellen; - Transit Gateway; - Appliance Mode; - Ingress- und Egress-Routen; - NAT Gateway; - Internet Gateway; - Gateway Load Balancer; - zentrale Inspection VPC; - Flow Logs; - Alert Logs; - Stateful Rule Groups; - Availability-Zone-Affinität. AWS Network Firewall unterstützt keine asymmetrische Weiterleitung zu unterschiedlichen Firewallendpunkten. Anfrage und Antwort müssen demselben Endpunkt zugeführt werden. Ein Reachability-Analyzer-Ergebnis kann die modellierte Erreichbarkeit prüfen, ersetzt aber nicht die Auswertung realer Flow- und Alert-Logs. --- **AWS Security Group Connection Tracking** AWS Security Groups sind zustandsbehaftet und verfolgen Verbindungen. Zu prüfen sind: - tatsächlich zugeordnete Security Groups; - eingehende und ausgehende Regeln; - Netzwerkschnittstellen; - Connection-Tracking-Kapazität; - Idle-Timeouts; - asymmetrische Pfade über mehrere Netzwerkschnittstellen; - Network ACLs; - Gateway- und Transitpfade. Asymmetrisches Routing über verschiedene Netzwerkschnittstellen kann bei verfolgten Datenflüssen die erreichbare Leistung beeinträchtigen. AWS empfiehlt nach Möglichkeit symmetrische Topologien. --- **Azure Firewall und Network Virtual Appliances** Bei Azure sind unter anderem zu prüfen: - User Defined Routes; - effektive Routen der Netzwerkschnittstelle; - Azure Firewall; - Network Virtual Appliance; - Load Balancer; - Virtual WAN; - ExpressRoute; - VPN Gateway; - VNet Peering; - NAT Gateway; - Hub-and-Spoke-Routing; - aktive und aktive NVA-Instanzen; - Zustandssynchronisation; - SNAT-Verhalten. Effektive Routen per PowerShell: ```powershell Get-AzEffectiveRouteTable ` -NetworkInterfaceName "" ` -ResourceGroupName "" ``` Ein öffentlicher Load Balancer und eine private Firewallroute können einen asymmetrischen Pfad erzeugen, wenn der Hinverkehr über die öffentliche Load-Balancer-Adresse eintrifft und der Rückverkehr über die private Firewalladresse geführt wird. Bei Active/Active-NVAs muss geprüft werden, ob: - beide Richtungen dieselbe Instanz verwenden; - Flow-Pinning existiert; - Session Sharing unterstützt wird; - ECMP zu unterschiedlichen Instanzen führt. --- **Paketaufzeichnung systematisch planen** Für einen vollständigen Pfadvergleich sind möglichst vier Beobachtungspunkte hilfreich: | Punkt | Beobachtung | |---|---| | A | Paket verlässt den Client | | B | Paket erreicht und verlässt die zustandsbehaftete Komponente | | C | Paket erreicht den Server und Antwort verlässt ihn | | D | Antwort erreicht oder verfehlt die zustandsbehaftete Komponente | Empfohlener Filter: ```text host 192.0.2.100 and host 198.51.100.25 and tcp port 443 ``` Mit `tcpdump`: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.100 and host 198.51.100.25 and tcp port 443' ``` Nur TCP-Flags und Zeitverhalten prüfen: ```bash sudo tcpdump \ -ni any \ -tttt \ 'host 192.0.2.100 and host 198.51.100.25 and tcp port 443' ``` Für NAT müssen gegebenenfalls zwei Filter verwendet werden: ```text vor NAT: 10.10.20.25:53124 -> 203.0.113.80:443 nach NAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Paketaufzeichnungen dürfen nur autorisiert, zielgerichtet und zeitlich begrenzt durchgeführt werden. --- **Zeitstempel korrelieren** Alle beteiligten Systeme sollten eine ausreichend genaue Zeitbasis verwenden: - Client; - Server; - Router; - Firewallknoten; - Load Balancer; - Cloud-Logs; - SIEM; - Paketaufzeichnungssystem. Zu dokumentieren sind: ```text Datum Uhrzeit Zeitzone Zeitquelle ungefähre Zeitabweichung ``` Schon wenige Sekunden Unterschied können bei kurzen Verbindungsversuchen zu einer falschen Zuordnung führen. --- **Pakete und Bytes je Richtung auswerten** | Befund | Mögliche Einordnung | |---|---| | nur Originalpakete, keine Antwortpakete | Serverantwort fehlt oder verwendet anderen Rückweg | | Antwortpakete am Server, nicht an Firewall | Route zwischen Server und Firewall prüfen | | Antwortpakete an anderer Firewall | asymmetrischer Rückweg | | beide Richtungen in Sitzung, Client empfängt nichts | nachgelagerter Pfad zum Client prüfen | | wenige Pakete, Sitzung bleibt `SYN_SENT` | SYN-ACK fehlt | | Pakete in beide Richtungen, aber kaum Bytes | Handshake ohne Anwendungsdaten | | hohe Bytes nur in einer Richtung | Anwendung, ACK-Pfad oder Filterproblem | | Sitzung verschwindet sofort | RST, Policy-Drop, Timeout oder Tabellenproblem | | Sitzung bleibt lange `[UNREPLIED]` | keine zugeordnete Antwort | Zähler müssen während genau eines reproduzierbaren Tests verglichen werden. --- **NetFlow, IPFIX und Flow Logs** Flow-Daten können Hinweise liefern auf: - Quelle; - Ziel; - Ports; - Protokoll; - Eingangs- und Ausgangsschnittstelle; - Pakete; - Bytes; - Start- und Endzeit; - TCP-Flags; - nächste Hops; - zulassende oder verweigernde Aktion. Einschränkungen: - Sampling kann einzelne Datenflüsse übersehen; - Export erfolgt möglicherweise verzögert; - NAT kann unterschiedliche Datensätze erzeugen; - Flow Logs zeigen nicht immer den vollständigen Paketinhalt; - mehrere Geräte können denselben Datenfluss unterschiedlich darstellen; - fehlender Flow-Datensatz beweist nicht zwingend fehlenden Verkehr. Flow-Daten sind besonders hilfreich, wenn Hin- und Rückrichtung auf unterschiedlichen Geräten sichtbar werden. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der TCP-Verbindungsaufbau läuft über Firewall A, der Rückverkehr aufgrund einer spezifischeren Serverroute jedoch über Firewall B. Firewall B besitzt keinen synchronisierten Sitzungszustand und verwirft das SYN-ACK. Erwarteter Befund: Firewall A zeigt eine Sitzung im Zustand SYN_SENT oder UNREPLIED. Firewall B zeigt keinen passenden Sitzungseintrag, aber einen Invalid-State-Drop für das SYN-ACK. Eine serverseitige Paketaufzeichnung zeigt, dass das SYN-ACK den Server verlässt. Gegenbeweis: Hin- und Rückverkehr durchlaufen nachweislich Firewall A, und Firewall A sieht das SYN-ACK in derselben Sitzung. Testmethode: Routingtabellen, Sessiontabellen und zeitgleiche Paketaufzeichnungen auf Client-, Server- und Firewallseite vergleichen. Risiko: Nur lesende Diagnose und begrenzte Paketaufzeichnung. Erfolgskriterium: Abweichender Rückweg und verwerfendes Gerät sind mit Zeitstempel, Sitzungsdaten und Routingentscheidung eindeutig belegt. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | spezifische Rückroute korrigieren | falscher Rückweg nachgewiesen | weitere Ziele können betroffen sein | alte Route wiederherstellen | | Routingmetrik korrigieren | falsche Pfadauswahl bestätigt | Konvergenz und Lastverteilung ändern sich | alte Metrik wiederherstellen | | PBR-Regel korrigieren | asymmetrische PBR-Entscheidung bestätigt | andere markierte Flows betroffen | vorherige PBR-Regel aktivieren | | ECMP-Hash oder Flow-Pinning korrigieren | Verteilung auf unterschiedliche Stateful-Knoten bestätigt | Lastverteilung verändert sich | vorherige Einstellung wiederherstellen | | Cluster-State-Synchronisation reparieren | fehlende Synchronisation nachgewiesen | HA-Verhalten betroffen | herstellerspezifischer Rückfallplan | | SNAT gezielt einsetzen | Rückweg muss technisch gebunden werden | Originalquelle wird verdeckt | SNAT-Regel entfernen | | NAT-Regel korrigieren | falscher NAT-Besitzer oder falsche Übersetzung bestätigt | Erreichbarkeit vieler Verbindungen | alte NAT-Regel wiederherstellen | | einzelne Sitzung löschen | veralteter Eintrag nachgewiesen | genau diese Verbindung wird unterbrochen | Anwendung baut Sitzung neu auf | | Timeout korrigieren | nachweislicher Timeoutkonflikt | höhere Tabellenbelegung | alten Wert wiederherstellen | | Conntrack-Kapazität erhöhen | Tabellenlimit und ausreichender Speicher nachgewiesen | höherer Speicherbedarf | alten Grenzwert wiederherstellen | | fehlerhafte Quelle begrenzen | ungewöhnlich viele Sessions einer Quelle bestätigt | legitime Kommunikation kann betroffen sein | Begrenzung entfernen | | Active/Active-Design anpassen | Plattform unterstützt Asymmetrie nicht | Verfügbarkeit und Verteilung ändern sich | vorheriges Routingdesign wiederherstellen | Eine Änderung an Routing, NAT oder HA muss als zusammenhängende Ende-zu-Ende-Änderung bewertet werden. --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung dokumentieren. 2. Datum, Uhrzeit und Zeitzone erfassen. 3. Betroffene Anwendung bestimmen. 4. Quell- und Zielsystem bestimmen. 5. Quelladresse und Quellport erfassen. 6. Zieladresse und Zielport erfassen. 7. Protokoll bestimmen. 8. IPv4 und IPv6 unterscheiden. 9. Originalrichtung dokumentieren. 10. Antwortrichtung dokumentieren. 11. NAT vor und nach Übersetzung dokumentieren. 12. Fehlerumfang bestimmen. 13. Erwarteten Hinweg dokumentieren. 14. Erwarteten Rückweg dokumentieren. 15. Lokale Clientroute prüfen. 16. Lokale Serverroute prüfen. 17. Policy Routing auf beiden Endsystemen prüfen. 18. Routinginstanzen und VRFs berücksichtigen. 19. Tatsächlichen Hinweg nachweisen. 20. Tatsächlichen Rückweg unabhängig nachweisen. 21. Alle zustandsbehafteten Komponenten erfassen. 22. Aktive Firewall- und Clusterknoten bestimmen. 23. Sessiontabellen auf allen möglichen Knoten prüfen. 24. Sitzungs-ID dokumentieren. 25. Original- und Antwort-Tupel vergleichen. 26. TCP-, UDP- oder ICMP-Zustand auswerten. 27. `[UNREPLIED]`, `[ASSURED]` oder vergleichbare Markierung prüfen. 28. Pakete und Bytes je Richtung vergleichen. 29. NAT-Sitzung und NAT-Besitzer prüfen. 30. Regel- und Drop-Protokolle korrelieren. 31. Cluster- und State-Synchronisation prüfen. 32. Zeitpunkt des letzten Failovers prüfen. 33. ECMP und Hash-Verfahren prüfen. 34. PBR und Source Routing prüfen. 35. dynamische Routen und spezifischere Präfixe prüfen. 36. Load Balancer und Direct Server Return berücksichtigen. 37. Cloud-Routingtabellen und Firewallendpunkte prüfen. 38. Conntrack-Auslastung erfassen. 39. Conntrack-Fehlerzähler erfassen. 40. Timeouts dokumentieren. 41. Hardware-Offloading berücksichtigen. 42. kontrollierten Verbindungstest durchführen. 43. bei Bedarf Conntrack-Ereignisse beobachten. 44. bei Bedarf Paketaufzeichnung an mehreren Punkten durchführen. 45. Hypothese und Gegenbeweis formulieren. 46. genau eine kontrollierte Maßnahme vorbereiten. 47. Risiko, Rückweg und Erfolgskriterium dokumentieren. 48. Maßnahme freigeben und umsetzen. 49. vollständig neue Sitzung aufbauen. 50. Hin- und Rückweg erneut prüfen. 51. Session- und NAT-Zustand erneut prüfen. 52. ursprüngliche Anwendung verifizieren. 53. weitere repräsentative Datenflüsse prüfen. 54. temporäre Aufzeichnungen und Diagnoseregeln zurücknehmen. 55. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | Sitzung nur auf Firewall A | Firewall B besitzt keinen Zustand | Rückweg und State-Synchronisation prüfen | | Firewall A zeigt `[UNREPLIED]` | keine zugeordnete Antwort | serverseitige Aufzeichnung und Rückroute | | Server sendet SYN-ACK, Client empfängt nichts | Rückweg wird verworfen | Firewalls des Rückwegs erfassen | | Firewall B meldet `INVALID` | unbekannter oder fehlerhafter Zustand | ursprünglichen SYN-Pfad bestimmen | | Verbindung funktioniert nur manchmal | ECMP oder einzelner fehlerhafter Pfad | mehrere Tests mit Quellports vergleichen | | Verbindung funktioniert nach Wiederholung | Synchronisationsverzögerung oder Routingkonvergenz | Cluster- und Routingzeitpunkte prüfen | | nur neue Verbindungen scheitern | Conntrack-Tabelle voll oder neue Policy | Kapazität und Insert-Failed-Zähler | | bestehende Verbindungen funktionieren | Zustand vorhanden, neue Einträge scheitern | Sessionlimit und Ressourcenauslastung | | nach Failover brechen Sitzungen ab | State- oder NAT-Synchronisation unvollständig | HA-Protokoll und Tabellen vergleichen | | nur lange Leerlaufverbindungen brechen ab | Idle-Timeout | Timeout und Keepalive vergleichen | | UDP bleibt `[UNREPLIED]` | Antwort fehlt oder anderer Rückweg | Antwortaufzeichnung und UDP-Timeout | | unterschiedliche NAT-Abbildung je Knoten | NAT-Synchronisation fehlerhaft | Übersetzungstabellen vergleichen | | gleicher Firewallname, Sitzung fehlt | anderer VSYS, VRF oder Kontext | vollständigen Verarbeitungskontext prüfen | | Hinweg über VPN, Rückweg über Internet | Präfixankündigung oder PBR | Routen auf Server- und Gatewayseite | | nur ein Zielpräfix betroffen | spezifischere Route | Longest-Prefix-Match prüfen | | nur ein Teil der Clients betroffen | Quellrouting, Hash oder PBR | Quellen und Quellports vergleichen | | Conntrack-Auslastung nahe Grenzwert | Tabellenknappheit | Neu-, Drop- und Early-Drop-Rate | | `insert_failed` steigt | neue Einträge können nicht angelegt werden | Tabellenlimit und Speicher prüfen | | viele `UNREPLIED`-Einträge | Scans, nicht erreichbare Ziele oder Rückwegproblem | Quellen, Ziele und Rate analysieren | | Flow ist hardware-offloaded | Softwarecapture eventuell unvollständig | Hardwarezähler oder externen TAP verwenden | | AWS Firewall sieht nur eine Richtung | unterschiedliche Firewallendpunkte | Routingtabellen je Availability Zone | | Azure NVA-Instanzen sehen je eine Richtung | Active/Active ohne Flow-Symmetrie | ECMP und Session Sharing prüfen | | Traceroute wirkt symmetrisch, Sitzung fehlt | Traceroute nutzt anderen Datenfluss | Capture mit echtem Protokoll und Port | | Sitzung vorhanden, keine Anwendung | Netzwerkpfad möglicherweise korrekt | TLS, Protokoll und Serverdienst prüfen | --- **Typische Diagnosefehler** - Hin- und Rückweg als automatisch identisch betrachten. - Nur eine Traceroute vom Client ausführen. - Traceroute-Ergebnis als vollständigen Pfadnachweis bewerten. - Nur die Routingtabelle der Firewall prüfen. - Lokale Serverroute und Standardgateway ignorieren. - Längstes Präfix übersehen. - Policy-Based Routing nicht prüfen. - ECMP nur auf dem Hinweg betrachten. - Per-Flow-ECMP mit garantierter Ende-zu-Ende-Symmetrie gleichsetzen. - Mehrere virtuelle Kontexte einer Firewall übersehen. - Sessiontabelle nur auf einem Clusterknoten prüfen. - Konfigurations- und Zustandssynchronisation verwechseln. - `[UNREPLIED]` automatisch als Serverausfall interpretieren. - `ESTABLISHED` als erfolgreichen Anwendungsnachweis bewerten. - Generischen Conntrack-Zustand und TCP-Zustand verwechseln. - Original- und Antwort-Tupel nicht vergleichen. - Vor-NAT- und Nach-NAT-Adressen verwechseln. - NAT-Besitzer nicht bestimmen. - Bestehende und neue Sitzungen nicht unterscheiden. - Alle Sessions vorsorglich löschen. - Conntrack-Tabelle vollständig leeren. - Timeouts ohne zeitlichen Nachweis verändern. - Conntrack-Maximalwert ohne Speicherprüfung erhöhen. - `INVALID` pauschal erlauben. - Stateful Inspection deaktivieren. - TCP State Bypass als Standardlösung einsetzen. - Sicherheitsauswirkungen von Stateless-Betrieb ignorieren. - Direct Server Return als Fehler behandeln, obwohl es Teil des Designs ist. - Hardware-Offloading bei Capture und Zählern ignorieren. - Nur eine Richtung der Paket- und Bytezähler auswerten. - Flow Logs ohne Berücksichtigung von Sampling bewerten. - Uhren und Zeitzonen nicht synchronisieren. - Mehrere Variablen gleichzeitig verändern. - Nur den Porttest und nicht die ursprüngliche Anwendung verifizieren. - Temporäre Captures und Diagnoseprotokollierung aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Client verwendet die erwartete Quelladresse; - Server verwendet die erwartete Antwortadresse; - Quell- und Zielports entsprechen dem Sollzustand; - Hinweg entspricht dem freigegebenen Design; - Rückweg entspricht dem freigegebenen Design; - alle zustandsabhängigen Komponenten sehen beide Richtungen; - richtige Firewall- und Clusterknoten verarbeiten die Sitzung; - Sitzung wird im richtigen virtuellen Kontext angelegt; - NAT-Übersetzung ist in beiden Richtungen konsistent; - TCP-Handshake wird vollständig abgeschlossen; - UDP-Antwort wird der Pseudositzung zugeordnet; - ICMP-Fehler werden korrekt zugeordnet; - Sessiontabelle zeigt Pakete und Bytes in beiden Richtungen; - Sitzung erreicht den erwarteten Zustand; - kein Invalid-State-Drop entsteht; - Conntrack-Auslastung bleibt innerhalb der Baseline; - Insert-Failed- und Drop-Zähler steigen nicht; - State-Synchronisation ist fehlerfrei; - bestehende und neue Sitzungen verhalten sich erwartungsgemäß; - Failoververhalten entspricht dem Sollzustand; - IPv4 und IPv6 funktionieren, sofern erforderlich; - ursprüngliche Anwendung funktioniert; - weitere repräsentative Quellen funktionieren; - weitere repräsentative Ziele funktionieren; - kein unbeabsichtigter Bypass der Sicherheitskontrolle entstand; - temporäre Diagnosen wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Verbindung nach einer Routingänderung ist keine ausreichende Verifikation. Bei ECMP- oder Clusterproblemen müssen mehrere neue Verbindungen mit unterschiedlichen Quellports geprüft werden. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: Originalrichtung: Ziel-IP:Port/Protokoll> Antwortrichtung: Quell-IP:Port/Protokoll> NAT vor Übersetzung: NAT nach Übersetzung: Erwarteter Hinweg: Tatsächlicher Hinweg: Erwarteter Rückweg: Tatsächlicher Rückweg: Zustandsbehaftete Komponenten: Firewall- oder Clusterknoten: Virtueller Kontext: Sitzungs-ID: Sitzungszustand: Session Owner: Pakete und Bytes: Timeout: NAT-Sitzung: <Übersetzung und Besitzer> Conntrack-Auslastung: Fehlerzähler: Cluster-Synchronisation: Paketaufzeichnung: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] betroffene Anwendung bestimmt - [ ] Quelladresse erfasst - [ ] Quellport erfasst - [ ] Zieladresse erfasst - [ ] Zielport erfasst - [ ] Protokoll bestimmt - [ ] IPv4 und IPv6 unterschieden - [ ] Originalrichtung dokumentiert - [ ] Antwortrichtung dokumentiert - [ ] Vor-NAT-Tupel dokumentiert - [ ] Nach-NAT-Tupel dokumentiert - [ ] Fehlerumfang bestimmt - [ ] erwarteten Hinweg dokumentiert - [ ] tatsächlichen Hinweg nachgewiesen - [ ] erwarteten Rückweg dokumentiert - [ ] tatsächlichen Rückweg nachgewiesen - [ ] lokale Clientroute geprüft - [ ] lokale Serverroute geprüft - [ ] Standardgateways geprüft - [ ] längstes passendes Präfix geprüft - [ ] Policy Routing geprüft - [ ] VRFs und Routinginstanzen geprüft - [ ] dynamische Routen geprüft - [ ] ECMP geprüft - [ ] ECMP-Hash-Verfahren berücksichtigt - [ ] SD-WAN-Pfadauswahl geprüft - [ ] VPN- und Tunnelpfade geprüft - [ ] Load Balancer berücksichtigt - [ ] Direct Server Return berücksichtigt - [ ] zustandsabhängige Komponenten erfasst - [ ] richtige Firewall bestimmt - [ ] aktiven Clusterknoten bestimmt - [ ] virtuellen Firewallkontext bestimmt - [ ] Sessiontabellen aller möglichen Knoten geprüft - [ ] Sitzungs-ID dokumentiert - [ ] Session Owner bestimmt - [ ] generischen Tracking-Zustand geprüft - [ ] TCP-Zustand geprüft - [ ] UDP-Pseudositzung berücksichtigt - [ ] ICMP-Zuordnung berücksichtigt - [ ] `[UNREPLIED]` oder vergleichbaren Zustand geprüft - [ ] `[ASSURED]` oder vergleichbaren Zustand geprüft - [ ] Pakete je Richtung verglichen - [ ] Bytes je Richtung verglichen - [ ] Timeout geprüft - [ ] Sitzungsendgrund geprüft - [ ] NAT-Sitzung geprüft - [ ] NAT-Besitzer bestimmt - [ ] Cluster-State-Synchronisation geprüft - [ ] Konfigurationssynchronisation getrennt geprüft - [ ] letzten Failoverzeitpunkt geprüft - [ ] Conntrack-Anzahl erfasst - [ ] Conntrack-Maximalwert erfasst - [ ] Conntrack-Auslastung berechnet - [ ] Conntrack-Statistiken geprüft - [ ] Insert-Failed-Zähler geprüft - [ ] Drop- und Early-Drop-Zähler geprüft - [ ] Hardware-Offloading berücksichtigt - [ ] Flow Logs geprüft - [ ] Paketaufzeichnung am Client durchgeführt, sofern erforderlich - [ ] Paketaufzeichnung an der Firewall durchgeführt, sofern erforderlich - [ ] Paketaufzeichnung am Server durchgeführt, sofern erforderlich - [ ] Zeitstempel korreliert - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] vollständig neue Sitzung getestet - [ ] mehrere Verbindungen bei ECMP geprüft - [ ] ursprüngliche Anwendung verifiziert - [ ] repräsentative weitere Datenflüsse geprüft - [ ] temporäre Diagnosen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Routingtabelle | `route print` | | Windows-Routen | `Get-NetRoute` | | Windows-Zielroute | `Find-NetRoute -RemoteIPAddress "198.51.100.25"` | | Windows-Traceroute | `tracert 198.51.100.25` | | Linux-Zielroute | `ip route get 198.51.100.25` | | Linux-Zielroute mit Quelle | `ip route get 198.51.100.25 from 192.0.2.100` | | Linux-Policy-Routing | `ip rule show` | | Linux-alle Routingtabellen | `ip route show table all` | | Linux-IPv6-Route | `ip -6 route get 2001:db8::25` | | Linux-Traceroute | `traceroute 198.51.100.25` | | Linux-Path-MTU/Pfad | `tracepath 198.51.100.25` | | macOS-Zielroute | `route -n get 198.51.100.25` | | macOS-Traceroute | `traceroute 198.51.100.25` | | Conntrack-Einträge | `sudo conntrack -L` | | Conntrack-Anzahl | `sudo conntrack -C` | | Conntrack-Statistiken | `sudo conntrack -S` | | Conntrack-Ereignisse | `sudo conntrack -E` | | aktueller Conntrack-Füllstand | `sysctl net.netfilter.nf_conntrack_count` | | maximales Conntrack-Limit | `sysctl net.netfilter.nf_conntrack_max` | | Conntrack-Hash-Buckets | `sysctl net.netfilter.nf_conntrack_buckets` | | Reverse Path Filtering | `sysctl net.ipv4.conf.all.rp_filter` | | Cisco ASA Sitzungen | `show conn` | | Cisco ASA Sitzungsanzahl | `show conn count` | | Cisco ASA NAT | `show xlate` | | Cisco ASA HA | `show failover` | | Cisco ASA Drops | `show asp drop` | | Juniper Sitzungen | `show security flow session` | | Juniper Flow-Statistik | `show security flow statistics` | | Juniper Cluster | `show chassis cluster status` | | Palo Alto Sitzungssuche | `show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443` | | Palo Alto HA | `show high-availability state` | Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen: ```text conntrack -F conntrack -D clear conn clear xlate clear session all clear security flow session Firewall-State-Bypass aktivieren TCP State Bypass aktivieren Stateful Inspection deaktivieren Conntrack-Limit ungeprüft erhöhen Sessiontimeout ungeprüft erhöhen Routingprotokoll neu starten Cluster-Failover erzwingen Firewallcluster neu starten ECMP global deaktivieren produktive Route ungeprüft entfernen SNAT pauschal aktivieren Hardware-Offloading global deaktivieren ``` --- **Quellen** **Standards und Grundlagen** - [NIST SP 800-41 Revision 1 – Guidelines on Firewalls and Firewall Policy](https://csrc.nist.gov/pubs/sp/800/41/r1/final) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 4443 – Internet Control Message Protocol for IPv6](https://datatracker.ietf.org/doc/html/rfc4443) - [RFC 3022 – Traditional IP Network Address Translator](https://datatracker.ietf.org/doc/html/rfc3022) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 7857 – Updates to NAT Behavioral Requirements](https://datatracker.ietf.org/doc/html/rfc7857) **Linux Kernel und Netfilter** - [Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) - [Linux Kernel Documentation – Conntrack Netlink Specification](https://docs.kernel.org/next/netlink/specs/conntrack.html) - [Netfilter – Conntrack Tools User Manual](https://conntrack-tools.netfilter.org/manual.html) - [Netfilter – `conntrack` Command Documentation](https://conntrack-tools.netfilter.org/conntrack.html) - [nftables – Matching Connection Tracking Stateful Metadata](https://wiki.nftables.org/wiki-nftables/index.php/Matching_connection_tracking_stateful_metainformation) - [nftables – Flowtables](https://wiki.nftables.org/wiki-nftables/index.php/Flowtable) **Cisco** - [Cisco Secure Firewall ASA – Connection Settings](https://www.cisco.com/c/en/us/td/docs/security/asa/asa920/configuration/firewall/asa-920-firewall-config/conns-connlimits.html) - [Cisco – Configure TCP State Bypass on ASA](https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118995-configure-asa-00.html) - [Cisco Secure Firewall ASA – `show` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/S/asa-command-ref-S/show-t-commands.html) - [Cisco Secure Firewall ASA – `packet-tracer` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/pa-pn-commands.html) - [Cisco Secure Firewall ASA – `show asp drop` Usage](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/show_asp_drop_command_usage/show-asp-drop-command-usage.html) **Juniper Networks** - [Juniper – `show security flow session`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-flow-session.html) - [Juniper – Express Path Overview](https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html) **Amazon Web Services** - [AWS Network Firewall – Avoiding Asymmetric Routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/asymmetric-routing.html) - [AWS Network Firewall – Troubleshooting General Issues](https://docs.aws.amazon.com/network-firewall/latest/developerguide/troubleshooting-general-issues.html) - [AWS Network Firewall – Analyzing Stateless Rule Groups](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateless-rule-group-analyzer.html) - [Amazon EC2 – Security Group Connection Tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) **Microsoft Azure** - [Microsoft Learn – Asymmetrisches Routing mit mehreren Netzwerkpfaden](https://learn.microsoft.com/de-de/azure/expressroute/expressroute-asymmetric-routing) - [Microsoft Learn – Integrate Azure Firewall with Azure Standard Load Balancer](https://learn.microsoft.com/en-us/azure/firewall/integrate-lb) - [Microsoft Learn – Diagnose an Azure Virtual Machine Routing Problem](https://learn.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem) - [Microsoft Learn – Virtual WAN Hub Routing Policies](https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet. # 9.7 Ephemeral Ports und Verbindungsgrenzen Beim Aufbau einer ausgehenden TCP- oder UDP-Kommunikation benötigt das initiierende System normalerweise einen freien lokalen Quellport. Dieser kurzzeitig verwendete Port wird als dynamischer, temporärer oder ephemerer Port bezeichnet. Beispiel: ```text Client: 192.0.2.100:53124 Server: 198.51.100.25:443 Datenfluss: 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` Der Server verwendet den bekannten Zielport `443`. Der Client verwendet den dynamisch ausgewählten Quellport `53124`. Wenn kein geeigneter Quellport, Socket, Dateideskriptor, NAT-Eintrag oder Verbindungseintrag mehr verfügbar ist, können neue Verbindungen fehlschlagen, obwohl: - das Ziel erreichbar ist; - die Firewallregel stimmt; - der Serverdienst läuft; - bestehende Verbindungen weiterhin funktionieren; - Ping erfolgreich ist; - DNS korrekt auflöst. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - welcher dynamische Portbereich auf einem System tatsächlich gilt; - wie viele Ports dieses Bereichs belegt sind; - welcher Prozess besonders viele Verbindungen erzeugt; - ob `TIME_WAIT`, `CLOSE_WAIT` oder andere Zustände auffällig sind; - ob lokale Porterschöpfung oder SNAT-Porterschöpfung vorliegt; - ob ein NAT-Gateway, Load Balancer oder eine Firewall die Grenze erreicht; - ob statt Ports eine andere Verbindungsgrenze betroffen ist; - warum bestehende Sitzungen funktionieren, während neue Verbindungen scheitern; - wie Verbindungswiederverwendung und Connection Pooling die Last reduzieren; - wie eine Kapazitätsänderung sicher geplant und verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Port- und Verbindungsgrenzen dürfen nicht ohne Ursachenanalyse verändert werden. Eine größere Grenze kann das Symptom verschieben, während die eigentliche Ursache bestehen bleibt. Mögliche Ursachen sind: - fehlerhafte Anwendungsschleife; - fehlende Verbindungswiederverwendung; - nicht geschlossene Sockets; - ungewöhnlich hohe Verbindungsrate; - langsames oder nicht antwortendes Ziel; - zu großer Retry-Sturm; - Portscan; - Schadsoftware; - DDoS; - ungeeignete NAT-Architektur; - fehlerhafte Timeouts; - fehlende Kapazitätsplanung. Nicht als erste Diagnosemaßnahme geeignet sind: - Server vorsorglich neu starten; - NAT-Gateway neu erstellen; - Firewall-Sitzungstabelle vollständig löschen; - Conntrack-Tabelle leeren; - dynamischen Portbereich ungeprüft erweitern; - `TIME_WAIT`-Dauer ungeprüft verkürzen; - Socket- oder Dateideskriptorgrenzen maximal erhöhen; - Verbindungsbegrenzungen deaktivieren; - mehrere öffentliche IP-Adressen ohne Kapazitätsnachweis ergänzen; - alle Anwendungspools neu starten; - Keepalive- oder Timeoutwerte pauschal verändern; - Sicherheitssoftware deaktivieren. Vor jeder Änderung sind zu dokumentieren: - Ausgangszustand; - aktueller Portbereich; - Anzahl belegter Ports; - Verbindungszustände; - betroffene Prozesse; - häufigste Ziele; - Verbindungsrate; - NAT- oder SNAT-Auslastung; - weitere Ressourcenlimits; - Risiko; - Rückweg; - Erfolgskriterium; - Testverfahren. --- **Portnummernbereiche** IANA unterscheidet folgende Bereiche: | Bereich | Bezeichnung | Typische Verwendung | |---:|---|---| | `0–1023` | System Ports | bekannte und besonders geschützte Dienste | | `1024–49151` | User Ports | registrierte Anwendungsdienste | | `49152–65535` | Dynamic/Private Ports | dynamische oder private Verwendung | Der IANA-Bereich `49152–65535` ist eine allgemeine Einteilung. Er beweist nicht, dass ein Betriebssystem lokal genau diesen Bereich verwendet. Der tatsächlich verwendete Bereich kann abhängen von: - Betriebssystem; - Betriebssystemversion; - TCP oder UDP; - IPv4 oder IPv6; - Netzwerknamespace; - Anwendung; - expliziter Socketbindung; - Systemrichtlinie; - Containerplattform; - Cloudplattform; - NAT-Gerät; - benutzerdefinierter Konfiguration. Deshalb muss der aktuelle Bereich auf dem betroffenen System ausgelesen werden. --- **Ephemeren Quellport und Serverport unterscheiden** Normale Clientverbindung: ```text 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` | Port | Rolle | |---:|---| | `53124` | dynamischer Quellport des Clients | | `443` | Zielport des Serverdienstes | Rückverkehr: ```text 198.51.100.25:443 -> 192.0.2.100:53124/TCP ``` Der Server benötigt nicht für jeden eingehenden Client einen neuen lokalen Listenerport. Alle HTTPS-Verbindungen können lokal den Serverport `443` verwenden, weil die vollständigen Verbindungen durch unterschiedliche Adressen und Ports unterscheidbar bleiben. --- **Das Verbindungstupel** Eine TCP- oder UDP-Kommunikation wird typischerweise über folgende Merkmale unterschieden: ```text Quelladresse Quellport Zieladresse Zielport Protokoll ``` Beispiel: ```text 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` Eine gleichzeitig bestehende Verbindung kann denselben lokalen Port möglicherweise gegenüber einem anderen Ziel verwenden: ```text 192.0.2.100:53124 -> 203.0.113.80:443/TCP ``` Ob und wie ein Betriebssystem lokale Ports zwischen verschiedenen Zielen wiederverwendet, hängt von Implementierung, Bindungsart und Socketoptionen ab. Deshalb gilt nicht allgemein: ```text Anzahl dynamischer Ports = maximale Gesamtzahl aller ausgehenden Verbindungen ``` Die Grenze muss immer im Zusammenhang mit Quelladresse, Zieladresse, Zielport, Protokoll, NAT und Verbindungszustand bewertet werden. --- **Anzahl eines Portbereichs berechnen** Allgemeine Berechnung: ```text Anzahl = Endport - Startport + 1 ``` Beispiel: ```text Startport: 49152 Endport: 65535 Anzahl: 65535 - 49152 + 1 = 16384 Ports ``` Davon können abzuziehen sein: - reservierte Ports; - bereits gebundene Ports; - Ports in aktiven Verbindungen; - noch nicht wiederverwendbare Verbindungstupel; - Ports in `TIME_WAIT`; - anwendungsspezifische Ausschlüsse; - System- oder Plattformreservierungen; - Sicherheitsrichtlinien; - NAT- oder Providerbeschränkungen. Die theoretische Anzahl ist deshalb keine garantierte Verbindungskapazität. --- **TCP und UDP getrennt betrachten** TCP und UDP besitzen getrennte Protokollräume. Derselbe numerische Port kann gleichzeitig für TCP und UDP verwendet werden. Beispiel: ```text TCP 53124 UDP 53124 ``` Das sind zwei unterschiedliche Transportendpunkte. Zu prüfen sind daher getrennt: - dynamischer TCP-Portbereich; - dynamischer UDP-Portbereich; - TCP-Verbindungen; - UDP-Endpunkte; - TCP-Time-Wait-Zustände; - UDP-Tracking- und NAT-Timeouts; - protokollspezifische Cloudlimits. Eine funktionierende UDP-Verbindung beweist nicht, dass noch TCP-Ports verfügbar sind. --- **IPv4 und IPv6 getrennt prüfen** Betriebssysteme und Plattformen können Portbereiche oder Zustände für IPv4 und IPv6 getrennt verwalten. Zu prüfen sind: - verwendete Adressfamilie; - IPv4-Portbereich; - IPv6-Portbereich; - Dual-Stack-Verhalten; - Happy-Eyeballs-Verbindungen; - getrennte Firewallregeln; - getrennte NAT- oder SNAT-Pfade; - IPv4-mapped IPv6 Sockets; - Anwendung mit mehreren parallelen Verbindungsversuchen. Eine Anwendung kann bei einem Namensaufruf mehrere IPv6- und IPv4-Verbindungen starten. Dadurch kann die Zahl der Verbindungsversuche höher sein als die Zahl sichtbarer Benutzeranfragen. --- **Lokale und übersetzte Ports unterscheiden** Ein NAT- oder SNAT-Gerät kann den lokalen Quellport verändern. Beispiel: ```text Vor SNAT: 10.10.20.25:53124 -> 203.0.113.80:443 Nach SNAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Dabei existieren zwei unterschiedliche Portbetrachtungen: | Ebene | Port | |---|---:| | lokaler Clientport | `53124` | | externer SNAT-Port | `61001` | Der Client kann lokal noch Ports besitzen, während der SNAT-Portpool des Gateways erschöpft ist. Umgekehrt kann das NAT-Gateway noch Kapazität besitzen, während das lokale Betriebssystem keinen geeigneten Quellport mehr findet. --- **Lokale Porterschöpfung** Lokale Porterschöpfung liegt vor, wenn ein System für eine neue ausgehende Kommunikation keinen geeigneten lokalen Port beziehungsweise kein verwendbares lokales Verbindungstupel mehr zuweisen kann. Typische Symptome: - neue ausgehende TCP-Verbindungen schlagen fehl; - bestehende TCP-Verbindungen funktionieren weiter; - Fehler tritt nach längerer Laufzeit auf; - Neustart behebt das Problem nur vorübergehend; - viele Verbindungen besitzen denselben Prozess; - viele Einträge befinden sich in `TIME_WAIT`; - sehr viele Einträge befinden sich in `CLOSE_WAIT`; - hohe Anzahl von Verbindungen zu demselben Ziel; - DNS, Kerberos, RPC, Datenbank- oder API-Aufrufe scheitern gleichzeitig; - eingehende Verbindungen können teilweise weiter funktionieren; - Fehler verschwindet, sobald Verbindungen aus der Tabelle altern. Mögliche Fehlermeldungen sind abhängig von Betriebssystem und Anwendung: ```text Cannot assign requested address Address already in use No buffer space available Too many open files Only one usage of each socket address is normally permitted Connection timed out Connection failed ``` Diese Meldungen sind nicht gleichbedeutend. Beispielsweise kann `Address already in use` auch auf eine einzelne explizite Portkollision hinweisen. --- **SNAT-Porterschöpfung** Bei SNAT teilen sich mehrere interne Systeme eine oder mehrere externe IP-Adressen. Beispiel: ```text 10.10.20.11 -> 198.51.100.5 10.10.20.12 -> 198.51.100.5 10.10.20.13 -> 198.51.100.5 ``` Das NAT-Gateway muss die Verbindungen über externe Quellports eindeutig zuordnen. Eine hohe Konzentration auf dasselbe Ziel kann besonders kritisch sein: ```text viele interne Systeme -> eine öffentliche NAT-Adresse -> eine Zieladresse -> ein Zielport ``` Beispiel: ```text 1000 interne Anwendungsinstanzen -> 198.51.100.5 -> 203.0.113.80:443 ``` Mögliche Symptome: - nur ausgehende Verbindungen über das NAT-Gateway scheitern; - interne Ziele funktionieren; - bestehende Verbindungen funktionieren; - neue Verbindungen zu einem häufig genutzten Ziel schlagen fehl; - Verbindungen zu anderen Zieladressen funktionieren; - Fehler tritt nur unter Last auf; - Cloudmetrik zeigt Port Allocation Errors; - zusätzliche NAT-IP verbessert das Verhalten; - Connection Pooling reduziert die Fehler. --- **Porterschöpfung pro Ziel einordnen** Der kritische Grenzfall ist häufig nicht die Gesamtzahl aller Ziele, sondern eine hohe Zahl gleichzeitiger oder schnell wiederholter Verbindungen zu genau derselben Kombination aus: ```text Ziel-IP-Adresse Zielport Protokoll ``` Beispiel: ```text 203.0.113.80:443/TCP ``` Ein API-Gateway, Datenbankserver, Proxy oder zentrales Authentifizierungssystem kann dadurch einen besonders konzentrierten Portbedarf erzeugen. Zu prüfen sind: - Anzahl unterschiedlicher Zieladressen; - Anzahl unterschiedlicher Zielports; - Verbindungen je Ziel; - neue Verbindungen pro Sekunde; - durchschnittliche Lebensdauer; - Anteil wiederverwendeter Verbindungen; - Retryrate; - Timeoutdauer; - DNS-Lastverteilung; - NAT-IP-Adressen; - Backend- oder Zielverteilung. --- **TIME_WAIT** Nach dem regulären Ende einer TCP-Verbindung kann das System das Verbindungstupel für eine bestimmte Zeit im Zustand `TIME_WAIT` halten. Zweck ist unter anderem: - verspätete Segmente einer alten Verbindung abzufangen; - eine neue gleichartige Verbindung nicht mit alten Paketen zu vermischen; - den abschließenden Verbindungsabbau zuverlässig behandeln zu können. Viele `TIME_WAIT`-Einträge sind nicht automatisch ein Fehler. Sie zeigen jedoch eine hohe Rate kurzlebiger TCP-Verbindungen. Kritisch wird die Situation, wenn gleichzeitig: - neue ausgehende Verbindungen scheitern; - der dynamische Portbereich stark belegt ist; - Windows-Ereignisse auf Porterschöpfung hinweisen; - ein einzelner Prozess besonders viele Verbindungen erzeugt; - ein einzelnes Ziel stark konzentriert ist; - die Einträge schneller entstehen als sie freigegeben werden. Ein hoher `TIME_WAIT`-Bestand ohne Verbindungsfehler beweist keine aktuelle Porterschöpfung. --- **CLOSE_WAIT** `CLOSE_WAIT` bedeutet vereinfacht: 1. Die Gegenstelle hat das Ende der Verbindung angekündigt. 2. Das lokale Betriebssystem hat dies an die Anwendung gemeldet. 3. Die lokale Anwendung hat ihren Socket noch nicht vollständig geschlossen. Viele dauerhaft bestehende `CLOSE_WAIT`-Einträge können auf eine Anwendung hinweisen, die Verbindungen nicht korrekt schließt. Zu prüfen sind: - betroffener Prozess; - Alter der Verbindungen; - Wachstum über die Zeit; - Remoteziele; - Anwendungsprotokolle; - Thread- oder Taskzustand; - Fehlerbehandlung; - Connection Pool; - Dateideskriptorverbrauch. `CLOSE_WAIT` beweist nicht automatisch eine erschöpfte dynamische Portmenge. Es kann jedoch gleichzeitig Sockets, Dateideskriptoren, Speicher und lokale Verbindungstupel binden. --- **SYN_SENT** Viele Verbindungen im Zustand `SYN_SENT` bedeuten, dass das lokale System Verbindungsanfragen gesendet hat, aber der TCP-Handshake noch nicht abgeschlossen wurde. Mögliche Ursachen: - Ziel antwortet nicht; - Firewall verwirft; - Rückroute fehlt; - Ziel ist überlastet; - falsche Zieladresse; - Paketverlust; - zu lange Anwendungstimeouts; - Retry-Sturm; - SYN-Pakete werden schneller erzeugt als sie ablaufen. Viele lang anhaltende `SYN_SENT`-Verbindungen können Ports und Sockets binden, obwohl keine erfolgreiche Anwendungskommunikation entsteht. --- **ESTABLISHED** Viele `ESTABLISHED`-Verbindungen können beabsichtigt sein, beispielsweise bei: - Datenbank-Connection-Pools; - HTTP-Keepalive; - HTTP/2; - WebSockets; - Message Brokern; - Streaming; - Replikation; - persistenten Agentenverbindungen. Zu prüfen sind: - sind die Verbindungen aktiv oder ungenutzt? - entspricht die Anzahl der Konfiguration? - werden alte Verbindungen ersetzt, ohne geschlossen zu werden? - existiert eine obere Poolgrenze? - besitzt jede Anwendungsinstanz einen eigenen Pool? - wächst die Zahl dauerhaft? - passt die Summe aller Instanzpools zur Zielkapazität? Eine hohe Zahl etablierter Verbindungen ist nicht automatisch Porterschöpfung. Sie kann jedoch andere Grenzwerte erreichen. --- **FIN_WAIT und LAST_ACK** Viele Verbindungen in Zuständen des Verbindungsabbaus können auf Probleme beim sauberen Beenden hinweisen. Zu prüfen sind: - antwortet die Gegenstelle auf den Verbindungsabbau? - besitzt die Anwendung geeignete Schließ- und Abbruchlogik? - blockiert eine Firewall abschließende Pakete? - existiert ein asymmetrischer Rückweg? - werden Verbindungen durch Timeouts statt kontrolliert beendet? - treten Paketverluste auf? - ist das Ziel überlastet? Die genaue Bedeutung ist anhand der TCP-Zustandsfolge und einer Paketaufzeichnung zu prüfen. --- **UDP und QUIC** UDP besitzt keinen TCP-Verbindungsabbau und keinen TCP-`TIME_WAIT`-Zustand. Trotzdem können UDP-Sockets, NAT-Zuordnungen und Connection-Tracking-Einträge Ports belegen. Betroffene Anwendungen können sein: - DNS; - VoIP; - Streaming; - QUIC und HTTP/3; - VPN; - Telemetrie; - Gaming; - Monitoring. Zu prüfen sind: - lokale UDP-Endpunkte; - NAT-Timeout; - Conntrack-Timeout; - Portwiederverwendung; - Antwortverkehr; - QUIC-Verbindungsrate; - Anzahl externer Ziele; - Firewallzustand; - anwendungsspezifische Socketverwaltung. Eine Analyse ausschließlich der TCP-Verbindungen übersieht UDP- oder QUIC-bedingte Engpässe. --- **RPC-Dynamik nicht mit Clientports verwechseln** Windows RPC kann nach dem Kontakt zum RPC Endpoint Mapper auf TCP-Port `135` einen dynamischen Serverport verwenden. Vereinfachter Ablauf: 1. Client kontaktiert Ziel auf TCP `135`. 2. Endpoint Mapper nennt den dynamischen Serverport. 3. Client verbindet sich mit diesem Zielport. 4. Der Client verwendet dafür zusätzlich einen eigenen dynamischen Quellport. Beispiel: ```text Client: 192.0.2.100:53124 RPC-Server: 198.51.100.25:52044 Verbindung: 192.0.2.100:53124 -> 198.51.100.25:52044/TCP ``` Dabei sind beide Ports dynamisch, aber mit unterschiedlichen Rollen: | Port | Rolle | |---:|---| | `53124` | dynamischer Clientquellport | | `52044` | dynamisch zugewiesener RPC-Serverzielport | Firewallregeln müssen diese Rollen korrekt berücksichtigen. --- **Porterschöpfung und andere Verbindungsgrenzen unterscheiden** | Grenze | Typischer Befund | |---|---| | dynamischer lokaler Portbereich | kein geeigneter Quellport für neue Verbindung | | SNAT-Portpool | NAT-Gerät kann keine neue Übersetzung anlegen | | Socketgrenze | Anwendung oder Kernel kann keinen weiteren Socket anlegen | | Dateideskriptorgrenze | Prozess erhält beispielsweise `Too many open files` | | Prozesshandlegrenze | Betriebssystem oder Prozess erreicht Handlegrenze | | Conntrack-Tabelle | Firewall oder Router kann keinen neuen Zustand anlegen | | Firewall-Sessionlimit | neue Sitzungen werden verworfen | | NAT-Sessionlimit | neue NAT-Zuordnungen schlagen fehl | | TCP-SYN-Backlog | neue Handshakes warten oder werden verworfen | | Accept-Backlog | vollständig aufgebaute Verbindungen werden nicht schnell genug angenommen | | Anwendungslimit | Dienst erlaubt nur definierte Zahl paralleler Verbindungen | | Connection-Pool-Limit | Anwendung wartet auf freien Poolplatz | | Thread- oder Workerlimit | Verbindungen werden nicht rechtzeitig verarbeitet | | Datenbanklimit | maximale Datenbanksitzungen erreicht | | Load-Balancer-Limit | Flow-, Port- oder Zielgrenze erreicht | | Cloudquote | plattformspezifische Obergrenze erreicht | | Zielsystemlimit | Gegenstelle begrenzt Quellen oder Verbindungsrate | | API-Rate-Limit | Anwendung lehnt Anfragen trotz funktionierender TCP-Verbindung ab | Ein erfolgreicher TCP-Porttest beweist nicht, dass die Anwendung noch einen Datenbankpoolplatz oder Worker besitzt. --- **Windows: dynamischen Portbereich anzeigen** IPv4 TCP: ```cmd netsh int ipv4 show dynamicport tcp ``` IPv4 UDP: ```cmd netsh int ipv4 show dynamicport udp ``` IPv6 TCP: ```cmd netsh int ipv6 show dynamicport tcp ``` IPv6 UDP: ```cmd netsh int ipv6 show dynamicport udp ``` Bei aktuellen unterstützten Windows-Versionen ist der Standardbereich normalerweise: ```text Startport: 49152 Endport: 65535 Anzahl: 16384 ``` Der tatsächliche Systemwert ist trotzdem mit `netsh` zu prüfen. TCP, UDP, IPv4 und IPv6 werden getrennt angezeigt. --- **Windows: TCP-Verbindungen anzeigen** Alle TCP-Verbindungen: ```powershell Get-NetTCPConnection ``` Etablierte Verbindungen: ```powershell Get-NetTCPConnection ` -State Established ``` `TIME_WAIT`: ```powershell Get-NetTCPConnection ` -State TimeWait ``` `CLOSE_WAIT`: ```powershell Get-NetTCPConnection ` -State CloseWait ``` Ausgehende Verbindungsversuche: ```powershell Get-NetTCPConnection ` -State SynSent ``` Nach Ziel filtern: ```powershell Get-NetTCPConnection ` -RemoteAddress "198.51.100.25" ` -RemotePort 443 ``` Nach Prozess-ID filtern: ```powershell Get-NetTCPConnection ` -OwningProcess ``` Prozess bestimmen: ```powershell Get-Process ` -Id ``` --- **Windows: Zustände zählen** ```powershell Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Count, Name ``` Mögliche Ausgabe: ```text Count Name ----- ---- 8200 TimeWait 1450 Established 200 CloseWait 35 SynSent ``` Die Werte müssen mit einer Baseline und dem aktuellen Fehlerzeitpunkt verglichen werden. --- **Windows: Verbindungen je Prozess zählen** ```powershell Get-NetTCPConnection | Group-Object OwningProcess | Sort-Object Count -Descending | Select-Object -First 20 Count, Name ``` Die Spalte `Name` enthält in diesem Fall die Prozess-ID. Einzelne Prozess-IDs auflösen: ```powershell Get-Process ` -Id ``` Ausführlicher Zusammenhang: ```powershell Get-NetTCPConnection | ForEach-Object { $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue [PSCustomObject]@{ State = $_.State LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort RemoteAddress = $_.RemoteAddress RemotePort = $_.RemotePort PID = $_.OwningProcess Process = $process.ProcessName } } | Sort-Object Process, State ``` Auf stark belasteten Systemen kann diese Auswertung umfangreich sein. Sie sollte gezielt und während des Fehlerzeitraums durchgeführt werden. --- **Windows: häufigste Ziele ermitteln** ```powershell Get-NetTCPConnection | Where-Object State -ne Listen | Group-Object RemoteAddress, RemotePort | Sort-Object Count -Descending | Select-Object -First 20 Count, Name ``` Damit kann festgestellt werden, ob sich sehr viele Verbindungen auf ein einzelnes Ziel konzentrieren. --- **Windows: klassische Netstat-Auswertung** Verbindungen, Ports und Prozess-IDs: ```cmd netstat -ano ``` Mit ausführbarer Datei, administrative Eingabeaufforderung erforderlich: ```cmd netstat -anob ``` Gebundene Ports einschließlich bestimmter nicht aktiver TCP-Bindungen: ```cmd netstat -anoq ``` `TIME_WAIT` zählen: ```cmd netstat -ano | find /c "TIME_WAIT" ``` `CLOSE_WAIT` zählen: ```cmd netstat -ano | find /c "CLOSE_WAIT" ``` `SYN_SENT` zählen: ```cmd netstat -ano | find /c "SYN_SENT" ``` Ein einfacher Textzähler ist nur ein Indikator. Für die Zuordnung zu Prozess, Ziel, Zeit und Portbereich ist die vollständige Ausgabe erforderlich. --- **Windows: Ereignisse prüfen** Windows kann bei Porterschöpfung unter anderem TCP/IP-Ereignisse `4227` und `4231` protokollieren. Gezielte Suche: ```powershell Get-WinEvent ` -FilterHashtable @{ LogName = "System" Id = 4227, 4231 StartTime = (Get-Date).AddHours(-24) } | Select-Object TimeCreated, Id, ProviderName, Message ``` Die Ereignisse müssen zeitlich mit den tatsächlichen Verbindungsfehlern korreliert werden. Ein hoher `TIME_WAIT`-Bestand allein bestätigt keine Porterschöpfung. Microsoft empfiehlt zusätzlich, reale ausgehende Verbindungsfehler und passende Ereignisse nachzuweisen. --- **Windows: Portbereich eines Tests berücksichtigen** Wenn der ausgelesene TCP-Bereich beispielsweise `49152–65535` lautet: ```powershell $startPort = 49152 $endPort = 65535 Get-NetTCPConnection | Where-Object { $_.LocalPort -ge $startPort -and $_.LocalPort -le $endPort } | Group-Object State | Sort-Object Count -Descending | Select-Object Count, Name ``` Die Werte müssen an den tatsächlich mit `netsh` ermittelten Bereich angepasst werden. --- **Linux: lokalen Portbereich anzeigen** ```bash sysctl net.ipv4.ip_local_port_range ``` Alternative: ```bash cat /proc/sys/net/ipv4/ip_local_port_range ``` Beispielausgabe: ```text 32768 60999 ``` Das ist nur ein Beispiel. Die lokale Ausgabe ist maßgeblich. Reservierte lokale Ports: ```bash sysctl net.ipv4.ip_local_reserved_ports ``` Alternative: ```bash cat /proc/sys/net/ipv4/ip_local_reserved_ports ``` `ip_local_port_range` und `ip_local_reserved_ports` sind getrennte Einstellungen. Beide beeinflussen, welche Ports für automatische Zuweisungen zur Verfügung stehen. --- **Linux: Socketübersicht** ```bash ss -s ``` Mögliche Bereiche der Zusammenfassung: - Gesamtzahl der Sockets; - TCP-Sockets; - etablierte Verbindungen; - geschlossene Zustände; - `TIME_WAIT`; - UDP-Sockets; - RAW-Sockets; - fragmentierte Zustände. Die genaue Darstellung hängt von der installierten `iproute2`-Version ab. --- **Linux: TCP-Verbindungen anzeigen** Alle TCP-Sockets: ```bash ss -tan ``` Mit Prozessinformationen: ```bash sudo ss -tanp ``` Etablierte Verbindungen: ```bash ss -tan state established ``` `TIME_WAIT`: ```bash ss -tan state time-wait ``` `CLOSE_WAIT`: ```bash ss -tan state close-wait ``` `SYN_SENT`: ```bash ss -tan state syn-sent ``` Listener: ```bash ss -lntp ``` Nach Ziel filtern: ```bash ss -tanp \ dst 198.51.100.25:443 ``` --- **Linux: Zustände zählen** ```bash ss -Htan | awk '{print $1}' | sort | uniq -c | sort -nr ``` Nur `TIME_WAIT` zählen: ```bash ss -Htan state time-wait | wc -l ``` Nur `CLOSE_WAIT` zählen: ```bash ss -Htan state close-wait | wc -l ``` Nur `SYN_SENT` zählen: ```bash ss -Htan state syn-sent | wc -l ``` --- **Linux: Kernel-Socketstatistik** IPv4 und allgemeine Socketstatistik: ```bash cat /proc/net/sockstat ``` IPv6: ```bash cat /proc/net/sockstat6 ``` Mögliche Felder sind unter anderem: - verwendete Sockets; - TCP in use; - orphaned; - `TIME_WAIT`; - zugewiesener Speicher; - UDP in use; - RAW in use; - fragmentierte Pakete. Die Werte sind Momentaufnahmen und müssen mit einer Baseline verglichen werden. --- **Linux: Dateideskriptorgrenzen** Grenze der aktuellen Shell: ```bash ulimit -n ``` Grenzen eines laufenden Prozesses: ```bash cat /proc//limits ``` Offene Dateideskriptoren eines Prozesses zählen: ```bash ls -1 /proc//fd | wc -l ``` Systemweite Dateideskriptorinformationen: ```bash cat /proc/sys/fs/file-nr ``` Systemweite Obergrenze: ```bash sysctl fs.file-max ``` Sockets werden unter Unix-ähnlichen Betriebssystemen über Dateideskriptoren angesprochen. Ein Prozess kann deshalb die Dateideskriptorgrenze erreichen, obwohl im dynamischen Portbereich noch Ports frei sind. --- **Linux: Listener- und Backloggrenzen** Aktuelle Listener: ```bash ss -lnt ``` Globale Obergrenze des Listen-Backlogs: ```bash sysctl net.core.somaxconn ``` TCP-SYN-Backlog: ```bash sysctl net.ipv4.tcp_max_syn_backlog ``` Bei einem Listening Socket zeigt `ss` abhängig von Version und Kontext unter anderem aktuelle und maximale Warteschlangenwerte an. Ein Backlogproblem betrifft eingehende Verbindungen und ist nicht mit ausgehender Porterschöpfung gleichzusetzen. --- **Linux: Conntrack zusätzlich prüfen** Anzahl aktuell verfolgter Verbindungen: ```bash sysctl net.netfilter.nf_conntrack_count ``` Maximalwert: ```bash sysctl net.netfilter.nf_conntrack_max ``` Statistiken, sofern `conntrack-tools` installiert ist: ```bash sudo conntrack -S ``` Eine volle Conntrack-Tabelle kann neue Verbindungen verhindern, obwohl das lokale Betriebssystem noch Quellports besitzt. --- **macOS: Portbereich prüfen** Verfügbare Portbereichsparameter anzeigen: ```bash sysctl -a | awk '/net\.inet\.ip\.portrange/' ``` Je nach macOS-Version können unter anderem folgende Werte verfügbar sein: ```bash sysctl net.inet.ip.portrange.first ``` ```bash sysctl net.inet.ip.portrange.last ``` ```bash sysctl net.inet.ip.portrange.hifirst ``` ```bash sysctl net.inet.ip.portrange.hilast ``` Die tatsächlich vorhandenen Parameter und Werte sind auf dem betroffenen Mac zu prüfen. --- **macOS: Verbindungen und Prozesse prüfen** TCP-Verbindungen: ```bash netstat -anv -p tcp ``` TCP-Sockets mit Prozessen: ```bash sudo lsof -nP -iTCP ``` Nur etablierte TCP-Verbindungen: ```bash sudo lsof -nP -iTCP -sTCP:ESTABLISHED ``` Nur Listener: ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` TCP-Statistik: ```bash netstat -s -p tcp ``` Interaktive Netzwerksicht: ```bash nettop -m tcp ``` Die genaue Ausgabe unterscheidet sich je nach macOS-Version. --- **Prozess statt nur Portbereich untersuchen** Die wichtigste Frage lautet häufig: ```text Welcher Prozess erzeugt die Verbindungen? ``` Zu dokumentieren sind: - Prozessname; - Prozess-ID; - Dienst; - ausführbare Datei; - Benutzerkonto; - Startzeit; - Anzahl TCP-Verbindungen; - Anzahl UDP-Sockets; - Zustandsverteilung; - häufigste Ziele; - neue Verbindungen pro Sekunde; - Retryrate; - Fehlerprotokolle; - Connection-Pool-Konfiguration; - zuletzt durchgeführte Änderung. Ein Portbereich sollte nicht erweitert werden, bevor der verursachende Prozess und sein Verbindungsverhalten bekannt sind. --- **Verbindungsrate und gleichzeitige Verbindungen unterscheiden** | Metrik | Bedeutung | |---|---| | gleichzeitige Verbindungen | aktuell parallel bestehende Datenflüsse | | neue Verbindungen pro Sekunde | Geschwindigkeit des Verbindungsaufbaus | | geschlossene Verbindungen pro Sekunde | Geschwindigkeit des Abbaus | | `TIME_WAIT`-Bestand | noch nicht vollständig wiederverwendbare TCP-Zustände | | durchschnittliche Lebensdauer | Zeit bis zum Verbindungsende | | Retryrate | zusätzliche Versuche nach Fehler oder Timeout | | Wiederverwendungsquote | Anfragen pro bestehender Verbindung | Eine Anwendung mit nur wenigen gleichzeitig aktiven Anfragen kann trotzdem sehr viele Ports verbrauchen, wenn sie für jede Anfrage eine neue Verbindung erstellt. --- **Planungsnäherung für kurzlebige Verbindungen** Vereinfachte Abschätzung: ```text dauerhaft mögliche neue Verbindungen pro Sekunde ≈ verfügbare Portkombinationen / Belegungsdauer ``` Beispiel: ```text verfügbare Ports: 16384 angenommene Belegungsdauer: 240 Sekunden Näherung: 16384 / 240 ≈ 68 neue Verbindungen pro Sekunde ``` Diese Rechnung ist nur ein vereinfachtes Planungsmodell für eine konzentrierte Zielkombination. Das reale Verhalten hängt unter anderem ab von: - Betriebssystem; - Portauswahl; - Portwiederverwendung; - Zieladressen; - Zielports; - Quelladressen; - NAT; - TCP-Zustand; - Socketoptionen; - Sicherheitsrichtlinien; - Plattformlimits. Die Näherung darf nicht als garantierter Grenzwert verwendet werden. --- **Connection Pooling** Connection Pooling hält eine begrenzte Menge bestehender Verbindungen bereit und verwendet sie für mehrere Vorgänge erneut. Mögliche Vorteile: - weniger TCP-Handshakes; - weniger TLS-Handshakes; - geringere Verbindungsrate; - weniger `TIME_WAIT`; - geringerer Portverbrauch; - geringere CPU-Last; - geringere Latenz; - weniger Last auf NAT und Firewall. Zu prüfen sind: - minimale Poolgröße; - maximale Poolgröße; - Pool pro Prozess; - Pool pro Instanz; - Pool pro Benutzer; - Pool pro Ziel; - Idle-Timeout; - maximale Lebensdauer; - Health Check; - Validierung vor Wiederverwendung; - Verhalten bei Zielausfall; - Retrylogik; - Schließen beim Anwendungsende. Ein unbegrenzt großer Pool beseitigt keine Kapazitätsgrenzen und kann das Zielsystem überlasten. --- **HTTP-Verbindungen wiederverwenden** Für HTTP-basierte Anwendungen sind relevant: - HTTP/1.1 Keep-Alive; - HTTP/2-Multiplexing; - HTTP/3 über QUIC; - Proxyverbindungen; - maximale parallele Verbindungen pro Ziel; - DNS-Änderungen; - TLS-Sitzungswiederverwendung; - Clientbibliothek; - Lebensdauer des HTTP-Clients. Ein häufiges Fehlmuster ist die Erstellung eines neuen HTTP-Clients und einer neuen TCP-/TLS-Verbindung für jede einzelne Anfrage. Besser ist eine kontrollierte Wiederverwendung mit: - begrenztem Pool; - korrekten Timeouts; - Fehlerbehandlung; - DNS-Aktualisierung; - Gesundheitsprüfung; - sauberem Schließen beim Anwendungsende. Die konkrete Implementierung hängt von Programmiersprache, Framework und Bibliothek ab. --- **Retries kontrollieren** Ein langsames oder ausgefallenes Ziel kann einen Retry-Sturm auslösen. Beispiel: ```text 100 Anfragen × 5 sofortige Wiederholungen = 500 Verbindungsversuche ``` Bei mehreren Anwendungsinstanzen: ```text 500 Versuche × 20 Instanzen = 10000 Verbindungsversuche ``` Zu prüfen sind: - maximale Anzahl von Wiederholungen; - Wartezeit; - exponentielles Backoff; - zufällige Streuung oder Jitter; - Circuit Breaker; - Gesamtzeitlimit; - Wiederholung nur idempotenter Operationen; - gemeinsames Ziel aller Instanzen; - Verhalten bei DNS- oder TLS-Fehlern. Sofortige und unbegrenzte Retries können eine kleine Störung zu Port-, Socket- und Zielüberlastung verstärken. --- **AWS NAT Gateway** AWS dokumentiert für ein NAT Gateway pro zugeordneter IPv4-Adresse bis zu `55.000` gleichzeitige Verbindungen zu jedem eindeutigen Ziel. Ein eindeutiges Ziel wird dabei bestimmt durch: ```text Ziel-IP-Adresse Zielport Protokoll ``` Zu prüfen sind: - NAT-Gateway-Typ; - zugeordnete IPv4-Adressen; - Anzahl Verbindungen je Ziel; - CloudWatch-Metriken; - Port Allocation Errors; - Verbindungsversuche; - Idle Timeouts; - Availability Zone; - Routing; - Zielkonzentration. Mögliche relevante CloudWatch-Metriken sind abhängig vom Ressourcentyp unter anderem: - `ActiveConnectionCount`; - `ConnectionAttemptCount`; - `ErrorPortAllocation`; - `IdleTimeoutCount`; - `PacketsDropCount`. Zusätzliche NAT-IP-Adressen können die Kapazität erhöhen. Vorher muss jedoch geprüft werden, ob die Anwendung unnötig viele neue Verbindungen erstellt. --- **Azure NAT Gateway** Azure NAT Gateway stellt pro öffentlicher IPv4-Adresse `64.512` SNAT-Ports bereit. Ein NAT Gateway kann mehrere öffentliche IP-Adressen verwenden. Microsoft dokumentiert außerdem eine Grenze gleichzeitiger Verbindungen je eindeutigem Zielendpunkt. Die jeweils aktuelle Plattformdokumentation ist für die eingesetzte Ressource zu prüfen. Zu prüfen sind: - Anzahl öffentlicher IP-Adressen; - zugeordnete Subnetze; - SNAT Connection Count; - Failed SNAT Connection Count; - Zieladresse und Zielport; - Verbindungsrate; - TCP- und UDP-Nutzung; - Idle Timeouts; - Load-Balancer-Outbound-Regeln; - Azure Firewall; - NAT-Gateway-Zuordnung. TCP und UDP besitzen beim Azure NAT Gateway getrennte SNAT-Portinventare. --- **Azure Load Balancer** Ein Azure Load Balancer kann ausgehende SNAT-Ports nach konfigurierten Outbound Rules und Backendanzahl zuteilen. Zu prüfen sind: - Load-Balancer-SKU; - Outbound Rule; - Anzahl Backendinstanzen; - zugewiesene SNAT-Ports je Instanz; - verwendete öffentliche IP-Adressen; - Idle Timeout; - Port-Reuse; - SNAT-Port-Metriken; - Port Allocation Failures; - NAT-Gateway-Zuordnung. Eine ungleichmäßige Verbindungsverteilung kann dazu führen, dass eine einzelne Backendinstanz ihre Portzuteilung erreicht, obwohl andere Instanzen noch Kapazität besitzen. --- **Google Cloud NAT** Google Cloud NAT kann Ports statisch oder dynamisch auf VMs verteilen. Zu prüfen sind: - NAT-IP-Adressen; - minimale Ports pro VM; - maximale Ports pro VM; - dynamische Portzuweisung; - Endpoint-Independent Mapping; - Portnutzung je VM; - verworfene Pakete; - Zielkonzentration; - VM- und Podanzahl; - Verbindungsrate; - Logging und Monitoring. Bei dynamischer Portzuweisung kann eine schnelle Laststeigerung vorübergehend Pakete verlieren, während die Portzuweisung erweitert wird. Lasttests sollten deshalb auch den Anstieg der Verbindungsrate berücksichtigen. --- **Container und Kubernetes** Mehrere Container oder Pods können sich einen Host-, Node- oder NAT-Portpool teilen. Zu prüfen sind: - Netzwerkmodus; - eigener oder gemeinsamer Network Namespace; - Node-IP; - Pod-IP; - Host-NAT; - kube-proxy; - CNI-Plugin; - eBPF-Datenpfad; - Cloud NAT; - Service Mesh; - Sidecar Proxy; - Zahl der Pods; - Poolgröße pro Pod; - Retryverhalten; - Rolling Deployment; - Horizontal Scaling. Beispiel: ```text 50 Pods × 200 ausgehende Poolverbindungen = 10000 Verbindungen ``` Ein Scale-out kann den Gesamtportbedarf erhöhen, obwohl jede einzelne Instanz unverändert arbeitet. --- **Proxies und Gateways** Forward Proxies, Reverse Proxies, API Gateways und Service-Mesh-Sidecars initiieren eigene ausgehende Verbindungen. Dadurch existieren getrennte Verbindungsabschnitte: ```text Client -> Proxy Proxy -> Ziel ``` Zu prüfen sind für jeden Abschnitt: - Quelladresse; - Quellport; - Zieladresse; - Zielport; - Connection Pool; - maximale Verbindungen; - Idle Timeout; - Retrylogik; - NAT; - TLS-Terminierung; - Zahl der Worker; - Backendverteilung. Der Client kann ausreichend Ports besitzen, während der Proxy seinen ausgehenden Portpool erschöpft. --- **Firewalls und Connection Tracking** Zusätzlich zum Quellport muss eine Stateful Firewall oder ein NAT-Router häufig einen Sitzungseintrag anlegen. Zu prüfen sind: - aktuelle Sitzungsanzahl; - maximales Sitzungslimit; - Neuverbindungen pro Sekunde; - NAT-Übersetzungen; - Verbindungen je Quelle; - Verbindungen je Ziel; - halb offene Sitzungen; - UDP-Pseudositzungen; - Timeouts; - Drop-Zähler; - Tabellenfüllstand; - Cluster-Synchronisation. Eine Portbereichserweiterung am Client kann die Firewall stärker belasten und dort die nächste Grenze erreichen. --- **Serverseitige Verbindungsgrenzen** Wenn eingehende Verbindungen scheitern, sind zusätzlich zu prüfen: - Listener vorhanden; - Listeneradresse; - Listenerport; - SYN-Backlog; - Accept-Backlog; - maximale Clients; - Workerzahl; - Threadzahl; - Prozessgrenze; - Dateideskriptorgrenze; - Datenbankpool; - Zielabhängigkeiten; - CPU; - Speicher; - Garbage Collection; - Lizenzgrenze; - Rate Limit; - Reverse Proxy; - Load Balancer. Typische Unterscheidung: | Befund | Mögliche Einordnung | |---|---| | SYN erhält keine Antwort | Netzwerk, Firewall, Backlog oder Überlastung | | SYN erhält RST | kein Listener oder aktive Ablehnung | | TCP-Handshake erfolgreich, Anwendung wartet | Worker-, Pool- oder Backendproblem | | bestehende Clients funktionieren, neue nicht | Backlog, Verbindungslimit oder Ressourcenerschöpfung | | nur ausgehende Serveraufrufe scheitern | lokale Ports, NAT, Pool oder Zielproblem | --- **Baseline erfassen** Eine Port- und Verbindungsdiagnose benötigt Vergleichswerte. Sinnvolle Baseline: ```text dynamischer Portbereich TCP-Verbindungen gesamt UDP-Sockets gesamt ESTABLISHED TIME_WAIT CLOSE_WAIT SYN_SENT LISTEN Verbindungen je Prozess Verbindungen je Ziel neue Verbindungen pro Sekunde Dateideskriptoren je Prozess Conntrack-Auslastung NAT-Sitzungen SNAT-Portnutzung Fehlerzähler CPU und Speicher ``` Messpunkte: - Normalbetrieb; - Lastspitze; - unmittelbar vor der Störung; - während der Störung; - nach der Erholung; - nach einer kontrollierten Maßnahme. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der Anwendungsdienst erstellt für jeden API-Aufruf eine neue HTTPS-Verbindung zum Ziel 203.0.113.80:443. Die Verbindungen verbleiben anschließend in TIME_WAIT, bis der dynamische TCP-Portbereich erschöpft ist. Erwarteter Befund: Während der Störung schlagen neue ausgehende Verbindungen fehl. Windows protokolliert Ereignis 4227 oder 4231. Die Anzahl der TIME_WAIT-Verbindungen zum Ziel 203.0.113.80:443 ist sehr hoch und gehört überwiegend zum gleichen Prozess. Gegenbeweis: Der dynamische Portbereich besitzt während der Störung ausreichend freie Kapazität, es existieren keine passenden TCP/IP-Ereignisse, und der Verbindungsfehler tritt bereits vor der lokalen Portzuweisung oder ausschließlich am Zielsystem auf. Testmethode: Portbereich, Get-NetTCPConnection, Prozesszuordnung, Systemereignisse und eine kontrollierte Testverbindung zeitlich korrelieren. Risiko: Nur lesende Diagnose. Erfolgskriterium: Portbelegung, verursachender Prozess, Zielkonzentration und Verbindungsfehler sind für denselben Zeitpunkt nachgewiesen. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | Connection Pooling aktivieren | hohe Rate kurzlebiger Verbindungen bestätigt | fehlerhafte Altverbindungen können wiederverwendet werden | vorherige Clientkonfiguration | | HTTP-Verbindungen wiederverwenden | neue Verbindung pro Anfrage nachgewiesen | DNS- und Lebensdauerverhalten beachten | vorheriges Clientverhalten | | Poolgröße begrenzen | unkontrolliert großer Pool bestätigt | Wartezeiten bei Last | vorherige Poolgröße | | Retries begrenzen | Retry-Sturm nachgewiesen | einzelne Anfrage schlägt früher fehl | vorherige Retrykonfiguration | | Backoff und Jitter ergänzen | gleichzeitige Wiederholungen vieler Instanzen | längere Wiederherstellungszeit | alte Retryrichtlinie | | Anwendung korrigieren | nicht geschlossene Sockets bestätigt | Deploymentrisiko | vorherige Anwendungsversion | | Portbereich erweitern | tatsächliche lokale Porterschöpfung bestätigt | Überschneidungen und höhere Folgelast | vorherigen Bereich wiederherstellen | | zusätzliche Quell-IP verwenden | Kapazitätsbedarf und Architektur bestätigt | Routing, Firewall und Freigaben ändern sich | alte IP-Zuordnung | | zusätzliche NAT-IP verwenden | SNAT-Erschöpfung bestätigt | Kosten und Ziel-Allowlisting | zusätzliche IP entfernen | | NAT-Gateway skalieren | Plattformmetrik bestätigt Engpass | Kosten und Architekturänderung | vorherige Ressourcengröße | | Timeouts anpassen | ungeeigneter Timeout nachgewiesen | veraltete Zustände oder höhere Last | alten Timeoutwert wiederherstellen | | Dateideskriptorgrenze erhöhen | FD-Limit nachgewiesen und Speicher ausreichend | höherer Ressourcenverbrauch | alten Grenzwert wiederherstellen | | Conntrack-Kapazität erhöhen | Tabellenlimit nachgewiesen | höherer Speicherverbrauch | alten Wert wiederherstellen | | Serverpool skalieren | Zielkapazität nachgewiesen | zusätzliche Verbindungen und Kosten | Skalierung zurücknehmen | Die Ursachenbehebung in der Anwendung ist einer dauerhaften rein infrastrukturellen Vergrößerung vorzuziehen, wenn die Anwendung unnötig viele Verbindungen erzeugt. --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung erfassen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Betroffene Anwendung bestimmen. 4. Ausgehende und eingehende Verbindungen unterscheiden. 5. Quell- und Zielsystem bestimmen. 6. Quelladresse und Zieladresse erfassen. 7. Quellport und Zielport erfassen. 8. TCP, UDP und QUIC unterscheiden. 9. IPv4 und IPv6 unterscheiden. 10. Umfang der Störung bestimmen. 11. Prüfen, ob bestehende Verbindungen weiter funktionieren. 12. Prüfen, ob nur neue Verbindungen scheitern. 13. Dynamischen Portbereich auslesen. 14. Reservierte und ausdrücklich gebundene Ports berücksichtigen. 15. Anzahl aktueller TCP-Verbindungen erfassen. 16. UDP-Sockets erfassen. 17. TCP-Zustände gruppieren. 18. `TIME_WAIT` auswerten. 19. `CLOSE_WAIT` auswerten. 20. `SYN_SENT` auswerten. 21. Verbindungen nach Prozess gruppieren. 22. Verbindungen nach Ziel gruppieren. 23. Verbindungsrate messen. 24. Retryrate bestimmen. 25. Connection-Pool-Konfiguration prüfen. 26. Dateideskriptoren und Handles prüfen. 27. Listener- und Backloggrenzen prüfen. 28. Anwendungs- und Workerlimits prüfen. 29. Conntrack-Auslastung prüfen. 30. Firewall- und NAT-Sitzungsgrenzen prüfen. 31. Vor-NAT- und Nach-NAT-Ports dokumentieren. 32. SNAT-Portnutzung prüfen. 33. Cloudmetriken und Port Allocation Errors prüfen. 34. Container-, Node- und Podkontext berücksichtigen. 35. Proxy- und Sidecar-Verbindungen getrennt prüfen. 36. Anwendungsprotokolle auswerten. 37. Betriebssystemereignisse auswerten. 38. kontrollierte Testverbindung durchführen. 39. bei Bedarf Paketaufzeichnung durchführen. 40. Hypothese und Gegenbeweis formulieren. 41. genau eine kontrollierte Maßnahme vorbereiten. 42. Risiko, Rückweg und Erfolgskriterium dokumentieren. 43. Maßnahme freigeben und umsetzen. 44. neue Verbindungen unter gleicher Last testen. 45. Portbelegung und Zustände erneut messen. 46. SNAT-, Conntrack- und Fehlerzähler erneut prüfen. 47. ursprüngliche Anwendung verifizieren. 48. Nebenwirkungen auf andere Dienste prüfen. 49. temporäre Diagnosemaßnahmen zurücknehmen. 50. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | bestehende Verbindungen funktionieren, neue nicht | Port-, NAT-, Conntrack- oder Backloggrenze | jeweilige Auslastungszähler prüfen | | viele `TIME_WAIT` | hohe Rate kurzlebiger TCP-Verbindungen | Prozess, Ziel und Verbindungsrate | | viele `CLOSE_WAIT` | Anwendung schließt Sockets nicht | Prozess und Anwendungscode prüfen | | viele `SYN_SENT` | Ziel antwortet nicht oder Rückweg fehlt | Paketaufzeichnung und Route | | viele `ESTABLISHED` | Pool oder Langzeitverbindungen | Aktivität, Poolgrenze und Alter | | Windows-Ereignis 4227 | lokaler Endpunkt kann nicht sicher wiederverwendet werden | Portbestand und Prozesszuordnung | | Windows-Ereignis 4231 | Zuweisung eines ephemeren Ports fehlgeschlagen | dynamischen Bereich und Belegung prüfen | | `Cannot assign requested address` | kein verwendbarer lokaler Endpunkt oder falsche Bindung | Ports, lokale IP und Anwendung | | `Too many open files` | Dateideskriptorgrenze | Prozesslimits und offene FDs | | lokale Ports frei, Cloudfehler bleibt | SNAT- oder Plattformgrenze | Cloudmetrik und NAT-Gateway | | nur ein Ziel betroffen | Verbindungen pro Zielkombination erschöpft | Ziel-IP, Port und Protokoll gruppieren | | andere Ziele funktionieren | zielbezogene NAT- oder Gegenstellenbegrenzung | Zielkonzentration und Plattformlimit | | Neustart hilft nur vorübergehend | Zustände werden geleert, Ursache bleibt | Wachstum über die Zeit erfassen | | zusätzliche NAT-IP hilft | SNAT-Kapazität wahrscheinlich betroffen | Port Allocation Error vor und nach Änderung | | mehr Pods verschlechtern Fehler | Gesamtpool und Verbindungsrate steigen | Poolgröße × Podanzahl berechnen | | nur Lastspitzen betroffen | Portzuweisung oder Rate überschritten | Verbindungen pro Sekunde messen | | TCP funktioniert, UDP nicht | getrennte UDP-Port- oder NAT-Grenze | UDP-Sockets und NAT-Timeout | | HTTP/1.1 problematisch, HTTP/2 besser | Multiplexing reduziert Verbindungen | Verbindungsrate vergleichen | | Firewall-Sessions voll | Connection Tracking oder Sessionlimit | Firewallstatistik und Drops | | Serverhandshake gelingt, Anfrage wartet | Worker-, Pool- oder Backendgrenze | Anwendungsmetriken | | Listener-Queue wächst | Anwendung akzeptiert zu langsam | CPU, Worker und Backlog | | Pool erschöpft, Ports frei | Anwendungslimit statt Portlimit | Poolwartezeit und Poolbelegung | | viele Retries | Fehler verstärkt Verbindungslast | Backoff- und Retrykonfiguration | | Portbereich angepasst, Fehler wandert zur Firewall | nachgelagerte Grenze erreicht | Firewall- und Conntrack-Kapazität | --- **Typische Diagnosefehler** - IANA-Portbereich ungeprüft als lokalen Betriebssystembereich annehmen. - Quellport und Zielport verwechseln. - RPC-Zielports und Clientquellports gleichsetzen. - TCP und UDP nicht getrennt prüfen. - IPv4 und IPv6 nicht getrennt prüfen. - Lokalen Port und SNAT-Port verwechseln. - Portanzahl als garantierte Gesamtverbindungszahl interpretieren. - Zieladresse und Zielport bei der Kapazität ignorieren. - Nur Gesamtverbindungen und nicht Verbindungen je Ziel prüfen. - `TIME_WAIT` allein als Beweis der Porterschöpfung verwenden. - `CLOSE_WAIT` als normalen Portablauf behandeln. - `SYN_SENT` ohne Netzwerkprüfung als Portproblem bewerten. - Prozesszuordnung nicht durchführen. - Verbindungsrate nicht messen. - Retries und Backoff nicht prüfen. - Connection Pooling nicht berücksichtigen. - Poolgröße nur pro Instanz und nicht über alle Instanzen berechnen. - Container, Pods oder Sidecars übersehen. - Proxy- und Zielverbindung als eine einzige Verbindung betrachten. - Dateideskriptorgrenze mit Portgrenze verwechseln. - Conntrack-Tabelle nicht prüfen. - Firewall-Sessionlimit ignorieren. - NAT-Gateway-Metriken nicht prüfen. - Cloudlimits aus einer anderen Ressource übertragen. - Portbereich als erste Maßnahme erweitern. - `TIME_WAIT`-Dauer vorsorglich verkürzen. - Server neu starten, bevor Beweisdaten gesichert sind. - Alle Sitzungen löschen. - Anwendungslimit durch Infrastrukturvergrößerung verdecken. - Nur eine einzelne Testverbindung durchführen. - Last- und Langzeittest nach der Maßnahme auslassen. - Temporäre Diagnoseaufzeichnungen aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - tatsächlicher dynamischer Portbereich ist dokumentiert; - reservierte Ports überschneiden sich nicht unerwartet; - neue Verbindungen werden zuverlässig aufgebaut; - bestehende Verbindungen bleiben stabil; - `TIME_WAIT`-Bestand entspricht der erwarteten Verbindungsrate; - `CLOSE_WAIT` wächst nicht dauerhaft; - `SYN_SENT` wächst nicht dauerhaft; - verursachender Prozess ist eindeutig bestimmt; - Connection Pool arbeitet innerhalb seiner Grenze; - Verbindungen werden wiederverwendet; - Retryrate entspricht der Vorgabe; - Dateideskriptorverbrauch bleibt unterhalb des Limits; - Listener- und Accept-Backlogs sind unauffällig; - Conntrack-Tabelle besitzt ausreichende Reserve; - Firewall-Sitzungslimit wird nicht erreicht; - NAT-Sitzungen besitzen ausreichende Reserve; - SNAT-Portfehler treten nicht mehr auf; - Cloudmetriken zeigen keine fehlgeschlagenen Portzuweisungen; - TCP und UDP funktionieren, sofern erforderlich; - IPv4 und IPv6 funktionieren, sofern erforderlich; - alle Anwendungsinstanzen funktionieren; - mehrere Ziele funktionieren; - konzentrierte Verbindungen zum Hauptziel funktionieren; - Lastspitze wird erfolgreich verarbeitet; - ursprüngliche Anwendung funktioniert; - keine neue Sicherheitsumgehung entstand; - keine unnötige allgemeine Portfreigabe besteht; - temporäre Diagnosen wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine erfolgreiche Einzelverbindung direkt nach einem Neustart ist keine ausreichende Verifikation. Porterschöpfung muss unter repräsentativer Last und über einen ausreichend langen Zeitraum ausgeschlossen werden. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: Betroffenes System: Datenfluss: Ziel-IP:Port/Protokoll> Adressfamilie: Dynamischer Portbereich: Reservierte Ports: Verbindungen gesamt: ESTABLISHED: TIME_WAIT: CLOSE_WAIT: SYN_SENT: UDP-Sockets: Hauptverursachender Prozess: Häufigstes Ziel: Verbindungsrate: Connection Pool: Retryverhalten: Dateideskriptoren: Conntrack: Firewall-Sitzungen: NAT vor Übersetzung: NAT nach Übersetzung: <öffentliche IP und SNAT-Port> SNAT-Portnutzung: Plattformlimit: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] betroffene Anwendung bestimmt - [ ] Quelladresse erfasst - [ ] Quellport erfasst - [ ] Zieladresse erfasst - [ ] Zielport erfasst - [ ] TCP und UDP unterschieden - [ ] IPv4 und IPv6 unterschieden - [ ] ausgehende und eingehende Verbindung unterschieden - [ ] Fehlerumfang bestimmt - [ ] bestehende Verbindungen getestet - [ ] neue Verbindungen getestet - [ ] dynamischen TCP-Portbereich ausgelesen - [ ] dynamischen UDP-Portbereich ausgelesen - [ ] reservierte Ports geprüft - [ ] theoretische Portanzahl berechnet - [ ] tatsächliche Portbelegung erfasst - [ ] TCP-Verbindungen gezählt - [ ] UDP-Sockets gezählt - [ ] `ESTABLISHED` gezählt - [ ] `TIME_WAIT` gezählt - [ ] `CLOSE_WAIT` gezählt - [ ] `SYN_SENT` gezählt - [ ] FIN-Zustände berücksichtigt - [ ] Prozesszuordnung durchgeführt - [ ] häufigste Prozesse bestimmt - [ ] häufigste Ziele bestimmt - [ ] Verbindungen je Ziel bestimmt - [ ] Verbindungsrate gemessen - [ ] Retryrate gemessen - [ ] Connection Pool geprüft - [ ] Poolgröße über alle Instanzen berechnet - [ ] HTTP-Verbindungswiederverwendung geprüft - [ ] Dateideskriptorgrenze geprüft - [ ] offene Dateideskriptoren gezählt - [ ] Prozesshandles berücksichtigt - [ ] Listener geprüft - [ ] SYN-Backlog geprüft - [ ] Accept-Backlog geprüft - [ ] Worker- und Threadgrenzen geprüft - [ ] Anwendungslimit geprüft - [ ] Datenbankverbindungslimit geprüft - [ ] Conntrack-Auslastung geprüft - [ ] Firewall-Sitzungsgrenze geprüft - [ ] NAT-Sitzungsgrenze geprüft - [ ] Vor-NAT-Port dokumentiert - [ ] Nach-NAT-Port dokumentiert - [ ] SNAT-Portpool geprüft - [ ] Cloudmetriken geprüft - [ ] Port Allocation Errors geprüft - [ ] Cloudressource und Ressourcentyp bestimmt - [ ] Container- oder Podkontext berücksichtigt - [ ] Proxy- und Sidecar-Verbindungen berücksichtigt - [ ] Betriebssystemereignisse geprüft - [ ] Anwendungsprotokolle geprüft - [ ] Baseline verglichen - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] Einzeltest durchgeführt - [ ] Lasttest durchgeführt - [ ] Langzeitverhalten geprüft - [ ] ursprüngliche Anwendung verifiziert - [ ] Nebenwirkungen geprüft - [ ] temporäre Diagnosen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows IPv4-TCP-Portbereich | `netsh int ipv4 show dynamicport tcp` | | Windows IPv4-UDP-Portbereich | `netsh int ipv4 show dynamicport udp` | | Windows IPv6-TCP-Portbereich | `netsh int ipv6 show dynamicport tcp` | | Windows IPv6-UDP-Portbereich | `netsh int ipv6 show dynamicport udp` | | Windows TCP-Verbindungen | `Get-NetTCPConnection` | | Windows etablierte Verbindungen | `Get-NetTCPConnection -State Established` | | Windows `TIME_WAIT` | `Get-NetTCPConnection -State TimeWait` | | Windows `CLOSE_WAIT` | `Get-NetTCPConnection -State CloseWait` | | Windows `SYN_SENT` | `Get-NetTCPConnection -State SynSent` | | Windows Netstat | `netstat -ano` | | Windows gebundene Ports | `netstat -anoq` | | Windows relevante Ereignisse | `Get-WinEvent -FilterHashtable @{LogName="System"; Id=4227,4231}` | | Linux-Portbereich | `sysctl net.ipv4.ip_local_port_range` | | Linux-reservierte Ports | `sysctl net.ipv4.ip_local_reserved_ports` | | Linux-Socketübersicht | `ss -s` | | Linux-TCP-Sockets | `ss -tan` | | Linux-TCP mit Prozessen | `sudo ss -tanp` | | Linux `TIME_WAIT` | `ss -tan state time-wait` | | Linux `CLOSE_WAIT` | `ss -tan state close-wait` | | Linux `SYN_SENT` | `ss -tan state syn-sent` | | Linux-Listener | `ss -lntp` | | Linux-Socketstatistik | `cat /proc/net/sockstat` | | Linux-FD-Limit der Shell | `ulimit -n` | | Linux-Prozesslimits | `cat /proc//limits` | | Linux-systemweites FD-Limit | `sysctl fs.file-max` | | Linux-Listen-Backlog | `sysctl net.core.somaxconn` | | Linux-SYN-Backlog | `sysctl net.ipv4.tcp_max_syn_backlog` | | Linux-Conntrack-Anzahl | `sysctl net.netfilter.nf_conntrack_count` | | Linux-Conntrack-Maximum | `sysctl net.netfilter.nf_conntrack_max` | | macOS-Portparameter | `sysctl -a \| awk '/net\.inet\.ip\.portrange/'` | | macOS-TCP-Verbindungen | `netstat -anv -p tcp` | | macOS-TCP-Prozesse | `sudo lsof -nP -iTCP` | | macOS-Netzwerkübersicht | `nettop -m tcp` | Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen: ```text netsh int ipv4 set dynamicport ... netsh int ipv6 set dynamicport ... sysctl -w net.ipv4.ip_local_port_range=... sysctl -w net.ipv4.tcp_fin_timeout=... TcpTimedWaitDelay ungeprüft verändern MaxUserPort ungeprüft verändern ulimit pauschal maximal erhöhen LimitNOFILE ungeprüft erhöhen fs.file-max ungeprüft erhöhen net.core.somaxconn ungeprüft erhöhen net.ipv4.tcp_max_syn_backlog ungeprüft erhöhen nf_conntrack_max ungeprüft erhöhen conntrack -F Firewall-Sitzungen vollständig löschen NAT-Sitzungen vollständig löschen Server vorsorglich neu starten NAT-Gateway vorsorglich neu erstellen öffentliche IP-Adressen ohne Kapazitätsplanung ergänzen Connection Pool unbegrenzt vergrößern Timeouts pauschal verkürzen Sicherheitsbegrenzungen deaktivieren ``` --- **Quellen** **Standards und Portregistrierung** - [IANA – Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/) - [RFC 6335 – Internet Assigned Numbers Authority Procedures for Service Names and Transport Protocol Port Numbers](https://datatracker.ietf.org/doc/html/rfc6335) - [RFC 7605 – Recommendations on Using Assigned Transport Port Numbers](https://datatracker.ietf.org/doc/html/rfc7605) - [RFC 6056 – Recommendations for Transport-Protocol Port Randomization](https://datatracker.ietf.org/doc/html/rfc6056) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 7857 – Updates to NAT Behavioral Requirements](https://datatracker.ietf.org/doc/html/rfc7857) **Microsoft Windows** - [Microsoft Learn – TCP/IP Port Exhaustion Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Configure RPC Dynamic Port Allocation with Firewalls](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-rpc-dynamic-port-allocation-with-firewalls) **Linux Kernel und Manpages** - [Linux Kernel Documentation – IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) - [Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) - [Linux man-pages – `IP_LOCAL_PORT_RANGE`](https://man7.org/linux/man-pages/man2/IP_LOCAL_PORT_RANGE.2const.html) - [Linux man-pages – `ip(7)`](https://man7.org/linux/man-pages/man7/ip.7.html) - [Linux man-pages – `tcp(7)`](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – `socket(7)`](https://man7.org/linux/man-pages/man7/socket.7.html) - [iproute2 – `ss(8)`](https://man7.org/linux/man-pages/man8/ss.8.html) - [Netfilter – Conntrack Tools User Manual](https://conntrack-tools.netfilter.org/manual.html) **Amazon Web Services** - [AWS – NAT Gateway Basics](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html) - [AWS – Work with NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-working-with.html) - [AWS – Troubleshoot NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html) **Microsoft Azure** - [Microsoft Learn – Source Network Address Translation with Azure NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-snat) - [Microsoft Learn – Azure NAT Gateway Resource](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-resource) - [Microsoft Learn – Troubleshoot Azure NAT Gateway Connectivity](https://learn.microsoft.com/en-us/troubleshoot/azure/nat-gateway/troubleshoot-nat-connectivity) - [Microsoft Learn – Azure Load Balancer Outbound Connections](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections) - [Microsoft Learn – Troubleshoot Azure Load Balancer Outbound Connectivity](https://learn.microsoft.com/en-us/troubleshoot/azure/load-balancer/troubleshoot-outbound-connection) **Google Cloud** - [Google Cloud – Cloud NAT IP Addresses and Ports](https://cloud.google.com/nat/docs/ports-and-addresses) - [Google Cloud – Troubleshoot Cloud NAT](https://cloud.google.com/nat/docs/troubleshooting) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet. # 9.8 NAT, Portweiterleitung und Hairpin NAT im Datenpfad Network Address Translation verändert IP-Adressen und gegebenenfalls Transportports innerhalb eines Datenflusses. Eine Verbindung kann deshalb an verschiedenen Stellen des Netzwerkpfads mit unterschiedlichen Adressen und Ports sichtbar sein. Beispiel einer eingehenden Portweiterleitung: ```text Externer Client: 198.51.100.40:53124 Öffentliche Adresse: 203.0.113.10:8443 Interner Server: 192.0.2.25:443 ``` Vor der Zielübersetzung: ```text 198.51.100.40:53124 -> 203.0.113.10:8443/TCP ``` Nach der Zielübersetzung: ```text 198.51.100.40:53124 -> 192.0.2.25:443/TCP ``` Eine scheinbar richtige Firewallregel kann wirkungslos bleiben, wenn sie die falsche Adressphase, das falsche Protokoll, die falsche Schnittstelle oder den falschen Übersetzungsport verwendet. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - welche Adressen und Ports vor und nach NAT verwendet werden; - ob Source NAT, Destination NAT oder Port Address Translation greift; - welche NAT-Regel tatsächlich angewendet wird; - ob eine Portweiterleitung auf das richtige interne Ziel zeigt; - ob Firewallregel, Routing und NAT zusammenpassen; - ob der Rückverkehr dieselbe NAT-Komponente durchläuft; - ob ein vorgeschaltetes NAT oder Carrier-Grade NAT eingehende Verbindungen verhindert; - ob Hairpin NAT beziehungsweise NAT Loopback unterstützt wird; - warum eine Verbindung intern, extern oder nur über die öffentliche Adresse fehlschlägt; - wie Container-, Cloud- und Load-Balancer-NAT berücksichtigt werden; - wie eine NAT-Änderung kontrolliert verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Eine Portweiterleitung veröffentlicht einen internen Dienst über einen zusätzlichen Netzwerkpfad. Vor der Einrichtung sind mindestens zu prüfen: - geschäftlicher Zweck; - verantwortlicher Diensteigentümer; - erforderliches Protokoll; - erforderlicher Port; - erlaubte Quelladressen; - Authentifizierung; - Verschlüsselung; - Patchstand; - Protokollierung; - Rate Limiting; - Monitoring; - Rückweg; - Rücknahmezeitpunkt; - Risiko; - Freigabe. Besonders schützenswerte Verwaltungs- und Dateidienste sollten nicht ohne zusätzliche Schutzarchitektur direkt aus dem Internet veröffentlicht werden. Dazu gehören beispielsweise: - RDP; - SMB; - SSH mit schwacher Authentifizierung; - Datenbankports; - Hypervisorverwaltung; - NAS-Verwaltung; - Router- oder Firewallverwaltung; - unverschlüsselte Weboberflächen; - interne Verzeichnisdienste. Geeignetere Zugriffsmöglichkeiten können sein: - VPN; - Zero-Trust-Zugriff; - Bastion Host; - Jump Host; - Reverse Proxy mit starker Authentifizierung; - Application Gateway; - Web Application Firewall; - privater Cloudendpunkt. Nicht als erste Diagnosemaßnahme geeignet sind: - alle Ports weiterleiten; - DMZ-Host-Funktion eines Routers aktivieren; - Exposed Host einrichten; - Firewall vollständig deaktivieren; - allgemeine `any`-zu-`any`-Regel erstellen; - NAT-Tabelle vollständig leeren; - alle Verbindungstabellen löschen; - UPnP pauschal aktivieren; - Server direkt mit öffentlicher Adresse verbinden; - Managementport testweise veröffentlichen; - Router oder Firewall vorsorglich neu starten; - mehrere NAT-Regeln gleichzeitig verändern. --- **NAT ist keine Firewall** NAT verändert Adressen oder Ports. Eine Firewall entscheidet anhand einer Sicherheitsrichtlinie, ob Datenverkehr erlaubt oder verworfen wird. Beide Funktionen können sich im selben Gerät befinden, bleiben aber logisch getrennt. Beispiel: ```text NAT-Regel: 203.0.113.10:8443 -> 192.0.2.25:443 Firewallregel: TCP von 198.51.100.0/24 zu 192.0.2.25:443 erlauben ``` Mögliche Kombinationen: | NAT | Firewall | Ergebnis | |---|---|---| | vorhanden | erlaubt | Verbindung kann weiterverarbeitet werden | | vorhanden | blockiert | Übersetzung kann passen, Verkehr wird trotzdem verworfen | | fehlt | erlaubt | Freigabe besitzt möglicherweise kein erreichbares Ziel | | falsch | erlaubt | Verkehr erreicht falsches System oder falschen Port | | vorhanden | falsche Richtung | Verbindungsaufbau bleibt blockiert | | automatisch erstellt | unbekannt | Sicherheitswirkung muss ausdrücklich geprüft werden | Einige Router erzeugen zusammen mit einer Portweiterleitung automatisch eine Firewallfreigabe. Andere Produkte verlangen eine getrennte Regel. Dieses Verhalten ist hersteller- und versionsabhängig. --- **NAT-Begriffe** | Begriff | Bedeutung | |---|---| | NAT | Oberbegriff für die Übersetzung von Netzwerkadressen | | SNAT | Änderung der Quelladresse | | DNAT | Änderung der Zieladresse | | PAT | Übersetzung von Transportports, häufig zusammen mit Adressübersetzung | | NAPT | Übersetzung von Netzwerkadresse und Transportport | | Masquerading | SNAT auf die aktuelle Adresse einer Ausgangsschnittstelle | | statisches NAT | fest definierte Zuordnung | | dynamisches NAT | Zuordnung aus einem Adresspool | | Portweiterleitung | statische eingehende Zieladress- und/oder Portübersetzung | | 1:1-NAT | feste Zuordnung einer internen zu einer externen Adresse | | Twice NAT | Quelle und Ziel werden abhängig voneinander in einer Regel verarbeitet | | NAT Exemption | bestimmter Datenverkehr wird ausdrücklich nicht übersetzt | | Hairpin NAT | interner Client erreicht internes Ziel über dessen externe NAT-Adresse | | NAT Loopback | gebräuchliche Bezeichnung für Hairpin NAT | | NAT Reflection | herstellerabhängige Bezeichnung für Hairpin-Verarbeitung | | U-Turn NAT | weitere gebräuchliche Bezeichnung für Hairpin NAT | | CGNAT | NAT im Netz des Internetzugangsanbieters | | NAT64 | Übersetzung zwischen IPv6 und IPv4 | | NPTv6 | zustandslose Übersetzung von IPv6-Präfixen | Die Begriffe werden von Herstellern nicht immer einheitlich verwendet. --- **Source NAT** Source NAT verändert die Quelladresse eines ausgehenden Datenflusses. Vor SNAT: ```text 192.0.2.100:53124 -> 198.51.100.25:443 ``` Nach SNAT: ```text 203.0.113.10:61001 -> 198.51.100.25:443 ``` Das Zielsystem sieht als Quelle: ```text 203.0.113.10:61001 ``` und normalerweise nicht: ```text 192.0.2.100:53124 ``` Typische Anwendungsfälle: - private IPv4-Clients greifen auf das Internet zu; - mehrere interne Systeme teilen sich eine öffentliche Adresse; - Rückverkehr soll über eine bestimmte Firewall geführt werden; - überlappende Netze werden verbunden; - ein Ziel erlaubt nur definierte Quelladressen; - Hairpin-Verkehr wird symmetrisch über das NAT-Gerät geführt. Auswirkungen: - ursprüngliche Quelladresse ist am Ziel nicht direkt sichtbar; - Protokolle zeigen gegebenenfalls nur die NAT-Adresse; - Portkapazität der NAT-Adresse wird benötigt; - Rückverkehr ist an die NAT-Sitzung gebunden; - Quell-IP-basierte Sicherheitsentscheidungen verändern sich. --- **Destination NAT** Destination NAT verändert die Zieladresse eines eingehenden Datenflusses. Vor DNAT: ```text 198.51.100.40:53124 -> 203.0.113.10:8443 ``` Nach DNAT: ```text 198.51.100.40:53124 -> 192.0.2.25:443 ``` Typische Anwendungsfälle: - Portweiterleitung; - Veröffentlichung eines internen Servers; - Weiterleitung an Reverse Proxy; - Load Balancing; - transparente Proxyfunktion; - Umleitung auf einen lokalen Dienst. Zu prüfen sind: - externe Zieladresse; - externer Zielport; - internes Ziel; - interner Zielport; - Protokoll; - Eingangsschnittstelle; - Quellbereich; - Firewallregel; - Rückroute; - Zustandstabelle. --- **Port Address Translation** PAT ermöglicht die Unterscheidung vieler Datenflüsse über dieselbe externe IP-Adresse. Beispiel: ```text 192.0.2.100:53124 -> 203.0.113.10:61001 192.0.2.101:53124 -> 203.0.113.10:61002 ``` Beide Clients können dasselbe Ziel verwenden: ```text 198.51.100.25:443 ``` Das NAT-Gerät hält dafür getrennte Zuordnungen: ```text 203.0.113.10:61001 -> 192.0.2.100:53124 203.0.113.10:61002 -> 192.0.2.101:53124 ``` PAT benötigt: - freie Übersetzungsports; - eine Sitzungstabelle; - passende Timeouts; - einen symmetrischen Rückweg; - ausreichende NAT-Kapazität. --- **1:1-NAT** Bei 1:1-NAT wird eine interne Adresse fest einer externen Adresse zugeordnet. Beispiel: ```text Öffentlich: 203.0.113.25 Intern: 192.0.2.25 ``` Mögliche Übersetzung: ```text 203.0.113.25 <-> 192.0.2.25 ``` 1:1-NAT bedeutet nicht automatisch, dass alle Ports erlaubt sind. Die Firewallrichtlinie muss weiterhin festlegen: - zulässige Quellen; - zulässige Protokolle; - zulässige Ports; - Richtung; - Protokollierung; - Sicherheitsprofile. --- **Portweiterleitung** Eine Portweiterleitung ordnet eine externe Kombination einer internen Kombination zu. Beispiel: ```text Externe Adresse: 203.0.113.10 Externer Port: 8443 Protokoll: TCP Internes Ziel: 192.0.2.25 Interner Port: 443 ``` Vereinfachte Regel: ```text TCP 203.0.113.10:8443 -> TCP 192.0.2.25:443 ``` Eine vollständige Portweiterleitung benötigt mindestens: - richtige öffentliche Adresse; - richtige Eingangsschnittstelle; - richtiges Protokoll; - richtigen externen Port; - richtige interne Zieladresse; - richtigen internen Port; - aktiven Serverdienst; - lokale Serverfirewall; - zentrale Firewallfreigabe; - korrekte Rückroute; - funktionierenden NAT-Zustand. --- **Externen und internen Port unterscheiden** Die Portnummern müssen nicht identisch sein. Beispiel: ```text Extern: TCP 8443 Intern: TCP 443 ``` Mögliche Diagnosefehler: - extern Port `443` testen, obwohl `8443` veröffentlicht ist; - Firewall für internen Port `8443` öffnen, obwohl Server auf `443` hört; - Server auf `8443` prüfen, obwohl DNAT auf `443` übersetzt; - TCP-Regel anlegen, obwohl Anwendung UDP verwendet; - IPv4-NAT testen, obwohl DNS eine IPv6-Adresse liefert. --- **TCP und UDP getrennt weiterleiten** Eine Portnummer bezeichnet ohne Transportprotokoll keinen vollständigen Dienstendpunkt. Diese beiden Regeln sind verschieden: ```text TCP 203.0.113.10:8443 -> 192.0.2.25:443 ``` ```text UDP 203.0.113.10:8443 -> 192.0.2.25:443 ``` Zu prüfen sind: - TCP; - UDP; - gegebenenfalls beide Protokolle; - ICMP-Verhalten; - QUIC über UDP; - anwendungsspezifische Zusatzports; - dynamisch ausgehandelte Ports. Ein erfolgreicher TCP-Test beweist keine funktionierende UDP-Weiterleitung. --- **Eingangsschnittstelle und Zieladresse** Eine NAT-Regel kann an eine bestimmte Eingangsschnittstelle oder öffentliche Zieladresse gebunden sein. Beispiele: - WAN1; - WAN2; - VPN; - Mobilfunk; - öffentliche Adresse A; - öffentliche Adresse B; - virtuelle IP-Adresse; - Load-Balancer-Adresse. Typischer Fehler: ```text NAT-Regel: gilt nur für WAN1 Tatsächlicher Datenverkehr: trifft über WAN2 ein ``` Die Regel ist vorhanden, verarbeitet diesen Datenfluss aber nicht. --- **Vollständiger eingehender Datenpfad** Ein eingehender Zugriff kann folgende Ebenen durchlaufen: 1. öffentlicher DNS-Eintrag; 2. Internetzugangsanbieter; 3. vorgeschaltetes Provider-NAT; 4. Modem oder Router; 5. Edge-Firewall; 6. öffentliche IP-Adresse; 7. DNAT- oder Portweiterleitungsregel; 8. Sicherheitsregel; 9. interne Route; 10. VLAN- oder Segmentfirewall; 11. Load Balancer; 12. Reverse Proxy; 13. Containerhost; 14. veröffentlichter Hostport; 15. Containerport; 16. lokale Host-Firewall; 17. Serverprozess; 18. Anwendung. Jede Ebene muss mit ihrer vor und nach der Verarbeitung sichtbaren Adresse geprüft werden. --- **Vollständiger Rückweg** Der Rückverkehr einer eingehenden Verbindung muss die zustandsbehaftete NAT-Komponente wieder erreichen. Beispiel: ```text Hinweg: 198.51.100.40 -> 203.0.113.10 -> 192.0.2.25 Rückweg: 192.0.2.25 -> 203.0.113.10 -> 198.51.100.40 ``` Wenn der Server über ein anderes Gateway antwortet: ```text 192.0.2.25 -> anderer Router -> 198.51.100.40 ``` fehlt dort möglicherweise die Rückübersetzung. Mögliche Folgen: - Client erhält eine Antwort mit unerwarteter Quelladresse; - Antwort wird durch eine Firewall verworfen; - TCP-Handshake bleibt unvollständig; - NAT-Sitzung bleibt ohne Rückverkehr; - Server sendet wiederholt `SYN, ACK`; - Client sendet wiederholt `SYN`. --- **NAT-Reihenfolge ist produktspezifisch** Die Verarbeitung kann unter anderem umfassen: - Eingangsschnittstelle bestimmen; - bestehende Sitzung suchen; - DNAT anwenden; - Route bestimmen; - Zielzone bestimmen; - Sicherheitsregel prüfen; - SNAT anwenden; - Ausgangsschnittstelle bestimmen; - Paket weiterleiten. Die genaue Reihenfolge unterscheidet sich zwischen: - Linux Netfilter; - Cisco ASA; - Palo Alto Networks; - Juniper SRX; - Fortinet; - Cloud-Firewalls; - Heimroutern; - Load Balancern; - Containerplattformen. Es darf nicht pauschal angenommen werden, dass eine Firewallregel immer: - die öffentliche Adresse; - die private Adresse; - den externen Port; - den internen Port; - die Vor-NAT-Zone; - die Nach-NAT-Zone verwenden muss. Maßgeblich ist die Dokumentation des eingesetzten Produkts und der Softwareversion. --- **NAT-Regelreihenfolge** NAT-Regeln können priorisiert oder der Reihe nach ausgewertet werden. Mögliche Probleme: - allgemeinere Regel steht vor spezifischer Regel; - bestehende Masquerade-Regel erfasst den Datenfluss; - NAT-Ausnahme überschattet die gewünschte Übersetzung; - doppelte Portweiterleitung verwendet denselben externen Port; - falsche Schnittstelle besitzt höhere Priorität; - Twice-NAT-Regel beendet die weitere Auswertung; - alte Regel ist noch aktiv; - zentrale Policy überschreibt lokale Regel; - IPv6-Regel wird mit IPv4-Regel verwechselt. Zu dokumentieren sind: - Regel-ID; - Regelname; - Reihenfolge; - Quellbereich; - Zielbereich; - Protokoll; - Ports; - Schnittstellen; - Trefferzähler; - letzte Verwendung; - aktive Konfigurationsversion. --- **Statische interne Zieladresse** Das Ziel einer Portweiterleitung muss dauerhaft erreichbar bleiben. Geeignete Möglichkeiten: - statische Serveradresse; - DHCP-Reservierung; - stabile virtuelle IP-Adresse; - Load-Balancer-Adresse; - Serviceadresse. Typischer Fehler: ```text Portweiterleitung: 192.0.2.25 Aktuelle Serveradresse: 192.0.2.37 ``` Die NAT-Regel ist syntaktisch korrekt, zeigt aber auf ein nicht mehr verwendetes Ziel. Zu prüfen sind: - aktuelle IP-Adresse; - DHCP-Lease; - Adressreservierung; - DNS; - ARP- oder Neighbor-Tabelle; - Serverroute; - Mehrfachadressierung; - Cluster- oder Failoveradresse. --- **Öffentliche Erreichbarkeit prüfen** Eine eingehende Portweiterleitung benötigt eine von außen erreichbare Zieladresse. Zu prüfen sind: - WAN-Adresse des eigenen Routers; - öffentliche DNS-Adresse; - von einem autorisierten externen System beobachtete Quelladresse; - vorgeschaltetes Modem; - weiterer Router; - Provider-NAT; - Carrier-Grade NAT; - DS-Lite; - Mobilfunk-NAT; - VPN oder Tunnel; - dynamische öffentliche Adresse; - IPv4 oder IPv6. Eine private Adresse auf der WAN-Schnittstelle ist nicht direkt aus dem öffentlichen Internet erreichbar. --- **Private IPv4-Bereiche** RFC 1918 definiert: ```text 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 ``` Das bedeutet: ```text 10.0.0.0 bis 10.255.255.255 172.16.0.0 bis 172.31.255.255 192.168.0.0 bis 192.168.255.255 ``` Befindet sich die WAN-Adresse des eigenen Routers in einem dieser Bereiche, existiert mindestens ein weiteres vorgeschaltetes Routing- oder NAT-System. --- **Shared Address Space und CGNAT** RFC 6598 reserviert für Provider-NAT: ```text 100.64.0.0/10 ``` Das umfasst: ```text 100.64.0.0 bis 100.127.255.255 ``` Dieser Bereich ist kein RFC-1918-Privatnetz, wird aber für Shared Address Space und häufig für Carrier-Grade NAT verwendet. Hinweise auf vorgeschaltetes NAT: - WAN-Adresse liegt in einem privaten Bereich; - WAN-Adresse liegt in `100.64.0.0/10`; - Router-WAN-Adresse weicht von der extern beobachteten Adresse ab; - Portweiterleitung funktioniert trotz richtiger lokaler Konfiguration nicht; - Internetzugang funktioniert ausschließlich ausgehend; - Anbieter nennt DS-Lite oder CGNAT; - öffentliche IPv4-Adresse ist nicht Bestandteil des Anschlusses. Eine Abweichung der Adressen ist ein Hinweis und muss unter Berücksichtigung von VPN, Proxy, mehreren Leitungen und Providerarchitektur bewertet werden. --- **Doppeltes NAT** Beispiel: ```text Internet -> Providerrouter 192.168.0.1 -> eigener Router 192.168.0.2 -> Server 192.0.2.25 ``` Für eine eingehende Verbindung können zwei Weiterleitungen erforderlich sein: ```text Providerrouter: 203.0.113.10:8443 -> 192.168.0.2:8443 Eigener Router: 192.168.0.2:8443 -> 192.0.2.25:443 ``` Zusätzlich müssen beide Firewalls und beide Rückwege passen. Besser kann je nach freigegebener Architektur sein: - Bridge- oder Modemmodus; - eigener Router als einziges NAT-Gateway; - statische Route statt zweitem NAT; - öffentliche Adresse direkt am Edge-Gerät; - kontrollierte DMZ-Verbindung zwischen den Geräten. Ein Exposed Host ist keine geeignete Standardlösung, weil dadurch möglicherweise sehr viele Ports weitergeleitet werden. --- **Carrier-Grade NAT und Portweiterleitung** Befindet sich die öffentliche IPv4-Adresse auf einem Provider-NAT, kann der eigene Router keine beliebige eingehende Abbildung auf diesem Providergerät erstellen. Mögliche Lösungen hängen vom Anbieter ab: - öffentliche IPv4-Adresse buchen; - statische öffentliche IPv4-Adresse verwenden; - IPv6 mit geeigneter Firewallfreigabe verwenden; - VPN mit eingehendem Tunnelendpunkt verwenden; - Reverse Tunnel; - Cloud-Reverse-Proxy; - providerseitige Portzuordnung; - Port Control Protocol, sofern tatsächlich unterstützt. Die technische und sicherheitstechnische Eignung muss für den konkreten Dienst bewertet werden. --- **Hairpin NAT** Hairpin NAT ermöglicht einem internen Client den Zugriff auf einen internen Server über dessen externe NAT-Adresse. Beispiel: ```text Interner Client: 192.0.2.100 Öffentliche Dienstadresse: 203.0.113.10:443 Interner Server: 192.0.2.25:443 ``` Der Client verwendet: ```text 192.0.2.100:53124 -> 203.0.113.10:443 ``` Das NAT-Gerät übersetzt das Ziel: ```text 192.0.2.100:53124 -> 192.0.2.25:443 ``` Abhängig von Topologie und Produkt muss zusätzlich die Quelle übersetzt werden, damit der Server über dasselbe NAT-Gerät antwortet. --- **Hairpin NAT mit Quellübersetzung** Mögliche Verarbeitung: ```text Ursprünglich: 192.0.2.100:53124 -> 203.0.113.10:443 Nach Hairpin DNAT und SNAT: 192.0.2.1:61001 -> 192.0.2.25:443 ``` Dabei ist: ```text 192.0.2.1 ``` eine Adresse des NAT-Gateways. Der Server antwortet an das Gateway: ```text 192.0.2.25:443 -> 192.0.2.1:61001 ``` Das Gateway stellt für den Client wieder die erwartete Ansicht her: ```text 203.0.113.10:443 -> 192.0.2.100:53124 ``` Vorteil: - Hin- und Rückverkehr durchlaufen dieselbe NAT-Sitzung. Nachteil: - der Server sieht möglicherweise nicht die ursprüngliche Clientadresse; - Protokolle zeigen die Gatewayadresse; - quelladressbasierte Richtlinien verändern sich. --- **Direkter Rückweg als Hairpin-Problem** Client und Server befinden sich im selben internen Subnetz: ```text Client: 192.0.2.100 Server: 192.0.2.25 ``` Wenn nur das Ziel übersetzt wird, kann der Server direkt antworten: ```text 192.0.2.25:443 -> 192.0.2.100:53124 ``` Der Client hat die Verbindung jedoch zu folgender Adresse aufgebaut: ```text 203.0.113.10:443 ``` Eine direkte Antwort von: ```text 192.0.2.25:443 ``` passt nicht zur erwarteten Gegenstelle. Mögliche Symptome: - interner Zugriff über private Adresse funktioniert; - externer Zugriff über öffentliche Adresse funktioniert; - interner Zugriff über öffentliche Adresse scheitert; - Server sieht das eingehende Paket; - NAT-Gerät sieht keinen Rückverkehr; - Client verwirft die unerwartete Antwort. --- **Hairpin NAT ist nicht überall verfügbar** Mögliche Produktbezeichnungen: - NAT Loopback; - NAT Reflection; - Hairpin NAT; - U-Turn NAT; - Same-Interface NAT; - Intra-Interface NAT. Zu prüfen sind: - wird Hairpin NAT unterstützt? - ist es aktiviert? - gilt es für IPv4, IPv6 oder beide? - gilt es für dieselbe Schnittstelle? - benötigt es eine zusätzliche SNAT-Regel? - wird die ursprüngliche Clientadresse erhalten? - greift die richtige Firewallregel? - verwendet es dieselbe öffentliche Adresse? - funktioniert es bei mehreren WAN-Adressen? - ist es mit Load Balancer oder Proxy kompatibel? Das Verhalten darf nicht von einem anderen Routermodell oder Hersteller übertragen werden. --- **Split DNS als Alternative** Statt Hairpin NAT kann internes DNS den Dienstnamen direkt auf die interne Adresse auflösen. Extern: ```text app.example.test -> 203.0.113.10 ``` Intern: ```text app.example.test -> 192.0.2.25 ``` Vorteile: - interner Verkehr bleibt intern; - keine Hairpin-NAT-Sitzung erforderlich; - ursprüngliche Clientadresse bleibt sichtbar; - weniger Last auf der Edge-Firewall; - einfacherer Datenpfad. Zu prüfen sind: - identischer FQDN; - TLS-Zertifikat für den FQDN; - interne und externe DNS-Zone; - TTL; - DNSSEC-Kontext; - VPN- und Split-DNS-Verhalten; - Load-Balancer-Abhängigkeit; - unterschiedliche Anwendungspfade; - IPv4- und IPv6-Antworten. Split DNS ist nicht automatisch besser, wenn intern derselbe Reverse Proxy, dieselbe Web Application Firewall oder dieselben Sicherheitsprüfungen benötigt werden. --- **Internen und externen Test unterscheiden** Mindestens drei Tests sind getrennt zu dokumentieren: ```text Test A: interner Client -> interne Serveradresse Test B: interner Client -> öffentliche Dienstadresse Test C: externer Client -> öffentliche Dienstadresse ``` Einordnung: | Test A | Test B | Test C | Mögliche Einordnung | |---:|---:|---:|---| | erfolgreich | erfolgreich | erfolgreich | grundlegender Pfad funktioniert | | erfolgreich | fehlerhaft | erfolgreich | Hairpin NAT oder internes DNS | | erfolgreich | erfolgreich | fehlerhaft | externe Weiterleitung, Provider, WAN oder Firewall | | fehlerhaft | fehlerhaft | fehlerhaft | Serverdienst, Host-Firewall oder interne Route | | fehlerhaft | erfolgreich | erfolgreich | unterschiedliche interne Adresse oder Sicherheitsregel | | erfolgreich | fehlerhaft | fehlerhaft | DNAT-Regel oder öffentliche Adresszuordnung | | fehlerhaft | fehlerhaft | erfolgreich | externer Proxy oder anderer Backendpfad | Test C muss tatsächlich aus einem externen Netz erfolgen. Ein Mobilgerät im WLAN ist kein externer Test. Auch ein VPN kann den Datenpfad zurück ins interne Netz führen. --- **DNS und NAT gemeinsam prüfen** Ein FQDN kann liefern: - öffentliche IPv4-Adresse; - öffentliche IPv6-Adresse; - interne IPv4-Adresse; - interne IPv6-Adresse; - Load-Balancer-Adresse; - CDN-Adresse; - Proxyadresse. Windows: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type AAAA ``` Linux und macOS: ```bash dig app.example.test A ``` ```bash dig app.example.test AAAA ``` Zu prüfen sind: - welche Adresse verwendet die Anwendung tatsächlich? - ist diese Adresse Bestandteil der NAT-Regel? - greift IPv6 ohne IPv4-NAT? - existiert Split DNS? - verwendet der Browser verschlüsseltes DNS? - ist ein Proxy beteiligt? - ist der DNS-Eintrag nach Adressänderung aktuell? Eine korrekte IPv4-Portweiterleitung hilft nicht, wenn der Client aufgrund eines AAAA-Eintrags direkt IPv6 verwendet. --- **IPv6 und NAT** IPv6 benötigt für normale öffentliche Erreichbarkeit nicht dieselbe Form von IPv4-Portübersetzung. Ein global adressierter IPv6-Server ist trotzdem nicht automatisch erreichbar. Zu prüfen sind: - globale IPv6-Adresse; - Präfixdelegation; - IPv6-Route; - IPv6-Firewall; - Listener auf IPv6; - AAAA-Eintrag; - Privacy Address; - stabile Serveradresse; - NDP; - ICMPv6; - Providerfilter; - Reverse Proxy; - NPTv6 oder NAT64. NAT darf nicht als Ersatz für eine IPv6-Firewall betrachtet werden. NPTv6 übersetzt IPv6-Präfixe zustandslos und besitzt ein anderes Verhalten als klassische IPv4-Portübersetzung. --- **Automatische Portabbildungen** Anwendungen können je nach Umgebung automatische Portabbildungen anfordern, beispielsweise über: - UPnP Internet Gateway Device; - NAT-PMP; - Port Control Protocol; - herstellerspezifische Verfahren. Zu prüfen sind: - ist die Funktion aktiviert? - welche Anwendung hat die Regel erstellt? - welcher interne Host ist Ziel? - welcher externe Port wurde vergeben? - welches Protokoll wird verwendet? - wie lange gilt die Abbildung? - existiert Authentifizierung oder Zugriffskontrolle? - bleibt die Regel nach Anwendungsende bestehen? - wird die Regel protokolliert? - überschneidet sie sich mit administrativen Regeln? Automatische Portabbildungen können die vorgesehene Sicherheitskontrolle umgehen. Sie dürfen nicht nur zur schnellen Fehlerbehebung aktiviert werden. --- **Application Level Gateways** Ein NAT-Gerät kann Protokollinhalte analysieren und Adressen oder Ports innerhalb der Nutzdaten verändern. Mögliche Protokolle: - FTP; - SIP; - H.323; - TFTP; - bestimmte VPN-Protokolle; - ältere RPC-Verfahren. Zu prüfen sind: - ALG aktiviert oder deaktiviert; - verschlüsselte oder unverschlüsselte Nutzdaten; - dynamisch ausgehandelte Ports; - NAT-Helper; - fehlerhafte Protokollumschreibung; - Herstellerfehler; - Interaktion mit TLS; - zusätzliche Firewallregeln. Ein ALG kann helfen, aber auch Verbindungen beschädigen. Es darf nur nach nachgewiesenem Zusammenhang verändert werden. --- **NAT und TLS** NAT verändert normalerweise nicht den TLS-Hostnamen oder das Zertifikat. Beispiel: ```text FQDN: app.example.test Öffentliche Adresse: 203.0.113.10 Interner Server: 192.0.2.25 ``` Das Zertifikat muss zum verwendeten Namen passen: ```text app.example.test ``` und nicht zwangsläufig zur öffentlichen oder privaten IP-Adresse. NAT kann jedoch indirekt TLS-Probleme verursachen, wenn: - falscher Backendserver erreicht wird; - externer und interner Port unterschiedliche Dienste liefern; - SNI an falschen Reverse Proxy gelangt; - Hairpin-Zugriff einen anderen Proxy umgeht; - Split DNS ein anderes Ziel liefert; - TLS-Inspektion beteiligt ist; - Proxy Protocol oder ursprüngliche Clientadresse erwartet wird. --- **Reverse Proxy und Portweiterleitung** Häufig zeigt eine Portweiterleitung nicht direkt auf den Anwendungsserver, sondern auf einen Reverse Proxy. Beispiel: ```text Internet: 203.0.113.10:443 DNAT: 192.0.2.20:443 Reverse Proxy: app.example.test -> 192.0.2.25:8080 ``` Zu prüfen sind zwei getrennte Verbindungen: ```text Client -> Reverse Proxy Reverse Proxy -> Backend ``` Mögliche Fehlerstellen: - öffentliche DNAT-Regel; - Firewall; - TLS-Zertifikat; - SNI; - Proxy-VHost; - Backendadresse; - Backendport; - Proxyroute; - Backendfirewall; - Health Check; - Hostheader; - WebSocket-Weiterleitung; - Timeout; - ursprüngliche Clientadresse. Ein erfolgreicher externer TCP-Handshake bis zum Reverse Proxy beweist nicht, dass das Backend erreichbar ist. --- **Docker-Portveröffentlichung** Ein Docker-Container in einem Bridge-Netz ist normalerweise nicht allein durch `EXPOSE` von außen erreichbar. Der Port muss veröffentlicht oder über einen anderen Proxy bereitgestellt werden. Beispiel: ```bash docker run \ -p 8080:80 \ nginx ``` Bedeutung: ```text Hostport 8080 -> Containerport 80 ``` Ohne ausdrücklich angegebene Hostadresse kann ein veröffentlichter Port auf allen geeigneten Hostadressen gebunden werden. Sicherer auf den lokalen Host begrenzt: ```bash docker run \ -p 127.0.0.1:8080:80 \ nginx ``` Damit ist der Port für einen lokalen Reverse Proxy erreichbar, aber nicht automatisch über jede externe Hostschnittstelle. --- **Docker-Portzuordnung prüfen** Laufende Container und veröffentlichte Ports: ```bash docker ps \ --format 'table {{.Names}}\t{{.Ports}}' ``` Portzuordnung eines Containers: ```bash docker port ``` Vollständige Netzwerkinformation: ```bash docker inspect ``` Hostlistener: ```bash ss -lntp ``` Containerlistener: ```bash docker exec \ ss -lntp ``` Falls `ss` im Container nicht installiert ist, sind Anwendungsprotokolle, Health Checks oder die im Image verfügbaren Diagnosewerkzeuge zu verwenden. Zu unterscheiden sind: ```text Routerport Hostport Containerport Anwendungsport ``` Beispiel: ```text 203.0.113.10:8443 -> 192.0.2.20:6875 -> Container:80 ``` --- **Docker-Netzwerkmodus berücksichtigen** | Netzwerkmodus | NAT- oder Portverhalten | |---|---| | Bridge | Portveröffentlichung und NAT üblich | | Host | Container verwendet den Netzwerkstack des Hosts; `-p` wird nicht angewendet | | Macvlan | Container kann eigene Adresse im Netz besitzen | | Ipvlan | direkte adressbasierte Anbindung je nach Betriebsart | | Overlay | zusätzlicher Overlay- und Orchestrierungspfad | | None | keine normale externe Netzwerkanbindung | Bei `host`-Netzwerkmodus besitzt der Container keinen getrennten Host-zu-Container-Portpfad. Eine konfigurierte `-p`-Option wird nicht als normale Portweiterleitung verwendet. --- **Docker und Firewallregeln** Docker kann für Bridge-Netze eigene Firewall- und NAT-Regeln erzeugen. Zu prüfen sind: - nftables oder iptables; - Docker-spezifische Chains; - veröffentlichte Ports; - Host-Firewall; - Forwarding; - Masquerading; - benutzerdefinierte Regeln; - Docker-Netzwerk; - Startreihenfolge; - Neustart des Docker-Daemons; - Firewallreload. Eigene Regeln dürfen nicht ungeprüft vor, nach oder innerhalb von Docker-verwalteten Regelketten eingefügt werden. --- **Kubernetes-Datenpfad** Mögliche Ebenen: ```text öffentliche Adresse -> Cloud Load Balancer -> Ingress Controller -> Kubernetes Service -> Pod ``` Oder: ```text Node-IP:NodePort -> Service -> Pod ``` Lesende Prüfungen: ```bash kubectl get services \ --all-namespaces \ -o wide ``` ```bash kubectl get ingress \ --all-namespaces ``` ```bash kubectl get endpointslices \ --all-namespaces ``` ```bash kubectl describe service \ \ --namespace ``` Zu prüfen sind: - Service-Typ; - ClusterIP; - NodePort; - LoadBalancer-Adresse; - TargetPort; - Selector; - EndpointSlices; - Podport; - Network Policy; - Ingressregel; - Hostname; - TLS; - External Traffic Policy; - Source NAT; - Health Checks. --- **Windows WinNAT lesend prüfen** NAT-Objekte: ```powershell Get-NetNat ``` Statische Abbildungen: ```powershell Get-NetNatStaticMapping ``` Aktive NAT-Sitzungen: ```powershell Get-NetNatSession ``` Netzwerkschnittstellen: ```powershell Get-NetIPConfiguration ``` Routing: ```powershell Get-NetRoute ``` Listener: ```powershell Get-NetTCPConnection ` -State Listen ``` WinNAT wird unter anderem für Hyper-V- und Windows-Container-Netze verwendet. Die Cmdlets zeigen keine NAT-Konfiguration eines getrennten physischen Routers. --- **Linux nftables lesend prüfen** Vollständiges Regelwerk: ```bash sudo nft list ruleset ``` Tabellen: ```bash sudo nft list tables ``` Eine bekannte NAT-Tabelle anzeigen: ```bash sudo nft list table ip nat ``` Die Tabelle muss nicht `ip nat` heißen. Maßgeblich ist die Ausgabe von: ```bash sudo nft list tables ``` Regelwerk mit Handles: ```bash sudo nft -a list ruleset ``` Zu suchen sind unter anderem: ```text dnat snat masquerade redirect prerouting postrouting output input ``` Bei nftables sind: - `dnat` und `redirect` für geeignete NAT-Chains wie `prerouting` oder `output` vorgesehen; - `snat` und `masquerade` für geeignete NAT-Chains wie `postrouting` vorgesehen. Die tatsächliche Chain, Priorität und Familie sind zu prüfen. --- **Vereinfachtes nftables-DNAT-Beispiel** ```nft table ip nat { chain prerouting { type nat hook prerouting priority dstnat; iifname "wan0" \ ip daddr 203.0.113.10 \ tcp dport 8443 \ dnat to 192.0.2.25:443 } } ``` Dieses Beispiel enthält nur die Zielübersetzung. Zusätzlich erforderlich sein können: - Forwarding; - Filterregel; - Rückroute; - SNAT; - Hairpin-Regel; - Protokollierung; - IPv6-Regel; - dauerhaftes Konfigurationsmanagement. Es darf nicht ungeprüft in ein produktives Regelwerk übernommen werden. --- **Vereinfachtes nftables-Hairpin-Prinzip** ```nft table ip nat { chain prerouting { type nat hook prerouting priority dstnat; ip saddr 192.0.2.0/24 \ ip daddr 203.0.113.10 \ tcp dport 443 \ dnat to 192.0.2.25:443 } chain postrouting { type nat hook postrouting priority srcnat; ip saddr 192.0.2.0/24 \ ip daddr 192.0.2.25 \ tcp dport 443 \ masquerade } } ``` Dieses vereinfachte Prinzip erzwingt, dass der Rückverkehr wieder über das NAT-Gateway läuft. Adressen, Schnittstellen, Sicherheitsregeln und Regelprioritäten müssen an die tatsächliche Umgebung angepasst und freigegeben werden. --- **Linux iptables lesend prüfen** NAT-Regeln: ```bash sudo iptables \ -t nat \ -L \ -n \ -v \ --line-numbers ``` Regeln in speicherbarer Syntax: ```bash sudo iptables \ -t nat \ -S ``` IPv6-Regeln, sofern verwendet: ```bash sudo ip6tables \ -t nat \ -S ``` Filter- und Forwardingregeln: ```bash sudo iptables \ -L FORWARD \ -n \ -v \ --line-numbers ``` Aktive Weiterleitung: ```bash sysctl net.ipv4.ip_forward ``` IPv6-Weiterleitung: ```bash sysctl net.ipv6.conf.all.forwarding ``` --- **Linux Connection Tracking** Aktive NAT- und Verbindungseinträge: ```bash sudo conntrack -L ``` TCP-Einträge zu einem internen Server: ```bash sudo conntrack -L \ -p tcp \ -d 192.0.2.25 \ --dport 443 ``` Ereignisse während eines kontrollierten Tests: ```bash sudo conntrack -E ``` Zu prüfen sind: - Originalrichtung; - Antwortrichtung; - Quell- und Zielports; - `src-nat`; - `dst-nat`; - `[UNREPLIED]`; - `[ASSURED]`; - Timeout; - Paket- und Bytezähler. Das vollständige Leeren der Conntrack-Tabelle ist keine erste Diagnosemaßnahme. --- **Cisco Secure Firewall ASA prüfen** NAT-Regeln: ```text show nat ``` Details und Treffer: ```text show nat detail ``` Übersetzungen: ```text show xlate ``` Verbindungen: ```text show conn ``` Nach Adresse filtern: ```text show conn address 192.0.2.25 ``` Routing: ```text show route ``` Simulation: ```text packet-tracer input outside tcp 198.51.100.40 53124 203.0.113.10 8443 detailed ``` Zu prüfen sind: - passende NAT-Regel; - NAT-Abschnitt und Reihenfolge; - reale und übersetzte Adresse; - externer und interner Port; - ACL; - Route; - Eingangs- und Ausgangsschnittstelle; - Ergebnis jeder Verarbeitungsphase. Bei aktuellen Cisco-ASA-Regelwerken werden Zugriffsregeln im NAT-Kontext anhand realer Adressen ausgewertet. Dieses Verhalten darf nicht auf andere Produkte übertragen werden. --- **Cloud-NAT und eingehende Verbindungen** Ein Cloud-NAT-Gateway dient häufig ausschließlich der ausgehenden Kommunikation privater Ressourcen. Wichtig: ```text Outbound NAT ist nicht automatisch Inbound Port Forwarding ``` Für eingehende Veröffentlichung können stattdessen erforderlich sein: - öffentliche Instanzadresse; - Load Balancer; - Network Load Balancer; - Application Gateway; - Cloud Firewall DNAT; - Reverse Proxy; - API Gateway; - Ingress Controller; - private Verbindung; - VPN. --- **AWS NAT Gateway** AWS NAT Gateway erlaubt privaten Ressourcen ausgehende Verbindungen. Es nimmt keine unaufgeforderten eingehenden Internetverbindungen für diese Ressourcen an. Zu prüfen sind: - public oder private NAT Gateway; - Subnetz; - Routingtabelle; - Internet Gateway; - Elastic IP; - Security Groups der Instanz; - Network ACLs; - Rückverkehr einer ausgehenden Sitzung; - CloudWatch-Metriken. Eine Portweiterleitung auf ein AWS NAT Gateway ist nicht der vorgesehene Weg zur Veröffentlichung eines privaten Servers. Mögliche Alternativen: - Application Load Balancer; - Network Load Balancer; - öffentliche Instanzadresse mit Security Group; - AWS Network Firewall beziehungsweise geeignete zentrale Firewall; - API Gateway; - VPN oder PrivateLink, abhängig vom Anwendungsfall. --- **Azure NAT Gateway** Azure NAT Gateway stellt ausgehende Internetkonnektivität für ein Subnetz bereit. Unaufgeforderte eingehende Internetverbindungen werden nicht bereitgestellt. DNAT wird nur für Antwortpakete einer zuvor ausgehend aufgebauten Kommunikation angewendet. Für eingehende Veröffentlichung können je nach Anforderung verwendet werden: - Azure Load Balancer; - Application Gateway; - Azure Firewall DNAT; - öffentliche IP-Adresse einer Ressource; - API Management; - Front Door; - privater Endpunkt; - VPN. Zu prüfen sind: - Subnetzanbindung; - öffentliche NAT-Adressen; - effektive Route; - Azure Firewall; - Load Balancer; - Network Security Group; - User Defined Route; - Zielressource; - Health Probe. --- **Paketaufzeichnung entlang des NAT-Pfads** Für einen NAT-Nachweis sind mehrere Beobachtungspunkte erforderlich. Beispiel: | Beobachtungspunkt | Erwarteter Datenfluss | |---|---| | vor Edge-Firewall | `198.51.100.40:53124 -> 203.0.113.10:8443` | | nach DNAT | `198.51.100.40:53124 -> 192.0.2.25:443` | | am Server | `198.51.100.40:53124 -> 192.0.2.25:443` | | Serverantwort | `192.0.2.25:443 -> 198.51.100.40:53124` | | nach Rückübersetzung | `203.0.113.10:8443 -> 198.51.100.40:53124` | Mit `tcpdump` auf dem externen Abschnitt: ```bash sudo tcpdump \ -ni \ 'host 198.51.100.40 and host 203.0.113.10 and tcp port 8443' ``` Auf dem internen Abschnitt: ```bash sudo tcpdump \ -ni \ 'host 198.51.100.40 and host 192.0.2.25 and tcp port 443' ``` Am Server: ```bash sudo tcpdump \ -ni any \ 'host 198.51.100.40 and tcp port 443' ``` Die Platzhalter müssen durch autorisierte reale Werte ersetzt werden. --- **Befund aus Paketaufzeichnungen** | WAN-Eingang | LAN-Ausgang | Serverantwort | Einordnung | |---:|---:|---:|---| | nein | nein | nein | Problem vor dem NAT-Gerät | | ja | nein | nein | NAT-, Firewall- oder Routingproblem | | ja | ja | nein | Server, Host-Firewall oder Dienst prüfen | | ja | ja | ja, aber nicht am NAT | falscher Rückweg | | ja | ja | ja und Rückübersetzung | Clientpfad oder Anwendung prüfen | | Hairpin am LAN sichtbar | kein Hairpin-Ausgang | Hairpin NAT fehlt oder passt nicht | | DNAT korrekt | falscher interner Port | NAT-Regel korrigieren | | Paket erreicht falschen Server | falsches Zielobjekt oder alte Regel | Regel und Objekt prüfen | Hardware-Offloading kann verhindern, dass eine allgemeine Softwareaufzeichnung alle Pakete zeigt. Dann sind herstellerspezifische Captures, SPAN oder TAP erforderlich. --- **Porttest richtig ausführen** Windows: ```powershell Test-NetConnection ` -ComputerName "203.0.113.10" ` -Port 8443 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz 203.0.113.10 8443 ``` HTTPS mit FQDN: ```bash curl \ -v \ https://app.example.test:8443/ ``` Ein TCP-Porttest beweist nur den TCP-Aufbau bis zu der Komponente, die antwortet. Er beweist nicht: - richtigen Backendserver; - korrekte Anwendung; - gültiges TLS-Zertifikat; - korrekten Hostheader; - funktionierende Authentifizierung; - funktionierende Datenbank; - korrekte UDP-Weiterleitung. Ein UDP-Test benötigt eine anwendungsspezifische Antwort, Protokollauswertung oder Paketaufzeichnung. --- **Externer Test** Ein externer Test muss aus einem tatsächlich unabhängigen Netz erfolgen. Mögliche Testsysteme: - autorisierter Server in einem anderen Standort; - freigegebene Cloud-VM; - Mobilfunkverbindung ohne WLAN; - externer Monitoringstandort; - vereinbarter Testhost eines Dienstleisters. Zu dokumentieren sind: - externe Quelladresse; - Zeitpunkt; - DNS-Ergebnis; - Zieladresse; - Zielport; - Protokoll; - Ergebnis; - Firewalllog; - NAT-Regeltreffer; - Serversicht. Öffentliche Portscan-Webseiten sollten nicht unkontrolliert für interne oder sensible Dienste verwendet werden. --- **NAT-Protokollierung** Ein geeigneter NAT- oder Firewalllogeintrag enthält möglichst: - Zeitstempel; - Eingangs- und Ausgangsschnittstelle; - Quellzone; - Zielzone; - Original-Quelladresse; - Original-Quellport; - Original-Zieladresse; - Original-Zielport; - übersetzte Quelladresse; - übersetzter Quellport; - übersetzte Zieladresse; - übersetzter Zielport; - Protokoll; - NAT-Regel; - Sicherheitsregel; - Sitzungs-ID; - Aktion; - Pakete; - Bytes; - Sitzungsendgrund. Ein fehlender NAT-Logeintrag kann bedeuten: - Datenverkehr erreicht das Gerät nicht; - Logging ist deaktiviert; - falscher Clusterknoten wird geprüft; - falscher virtueller Kontext wird geprüft; - andere NAT-Regel trifft; - Paket wird vor NAT verworfen; - Sitzung bestand bereits; - Hardware-Offload verwendet andere Zähler. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Die Portweiterleitung 203.0.113.10:8443 zeigt korrekt auf 192.0.2.25:443. Interne Clients können die öffentliche Adresse jedoch nicht verwenden, weil die Firewall kein Hairpin NAT für dieselbe interne Zone ausführt. Erwarteter Befund: Der interne Direktzugriff auf 192.0.2.25:443 funktioniert. Ein externer Zugriff auf 203.0.113.10:8443 funktioniert. Beim internen Zugriff auf 203.0.113.10:8443 steigt der Trefferzähler der normalen WAN-DNAT-Regel nicht oder der Rückverkehr umgeht die NAT-Sitzung. Gegenbeweis: Der Hairpin-Datenfluss wird nachweislich übersetzt, Hin- und Rückverkehr durchlaufen dieselbe NAT-Sitzung und die Antwort erreicht den Client mit der erwarteten öffentlichen Quelladresse. Testmethode: Drei getrennte Zugriffe über interne Adresse, öffentliche Adresse von intern und öffentliche Adresse von extern durchführen. NAT-Zähler, Sitzungstabelle und Paketaufzeichnung korrelieren. Risiko: Nur lesende Diagnose und kontrollierte Verbindungstests. Erfolgskriterium: Fehler ist eindeutig auf Hairpin-Verarbeitung, Rückweg oder eine nachgelagerte Anwendungsebene begrenzt. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | DNAT-Ziel korrigieren | falsche interne Adresse nachgewiesen | anderes System wird veröffentlicht | alte Zieladresse wiederherstellen | | externen Port korrigieren | falscher Port bestätigt | Clients müssen neuen Port verwenden | alten Port wiederherstellen | | internen Port korrigieren | tatsächlicher Listener nachgewiesen | falscher Dienst kann erreicht werden | alten Zielport wiederherstellen | | Protokoll korrigieren | TCP-/UDP-Abweichung bestätigt | zusätzliche Erreichbarkeit | alte Protokollregel | | Quellbereich einschränken | zulässige Quellen bekannt | legitime Quellen können fehlen | vorherigen Bereich wiederherstellen | | Rückroute korrigieren | asymmetrischer Rückweg bestätigt | weitere Ziele betroffen | alte Route wiederherstellen | | Hairpin DNAT ergänzen | interner öffentlicher Zugriff erforderlich | zusätzlicher interner Pfad | Regel entfernen | | Hairpin SNAT ergänzen | direkter Rückweg verhindert Sitzung | ursprüngliche Client-IP geht verloren | SNAT-Regel entfernen | | Split DNS einrichten | interner Direktpfad freigegeben | interner Pfad unterscheidet sich extern | vorherige DNS-Antwort | | Host-Firewall korrigieren | Serverdrop bestätigt | zusätzliche Angriffsfläche | alte Regel | | Containerport korrigieren | Host-/Containerabweichung bestätigt | Dienst wird anders veröffentlicht | alte Portzuordnung | | Reverse-Proxy-Ziel korrigieren | falsches Backend bestätigt | Anwendungspfad verändert sich | alte Proxykonfiguration | | öffentliche IPv4 bereitstellen | CGNAT bestätigt und fachlich erforderlich | Kosten und größere Angriffsfläche | Vertrag oder Zuweisung zurücknehmen | | NAT-Regelreihenfolge korrigieren | Überschattung nachgewiesen | andere Datenflüsse betroffen | alte Reihenfolge | --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung erfassen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Betroffene Anwendung bestimmen. 4. FQDN dokumentieren. 5. DNS-A- und AAAA-Antworten prüfen. 6. tatsächlich verwendete Zieladresse bestimmen. 7. TCP, UDP oder anderes Protokoll bestimmen. 8. externen Zielport bestimmen. 9. internen Zielport bestimmen. 10. externe Quelladresse dokumentieren. 11. öffentliche Zieladresse dokumentieren. 12. internes Ziel dokumentieren. 13. Vor-NAT-Tupel dokumentieren. 14. Nach-NAT-Tupel dokumentieren. 15. Umfang der Störung bestimmen. 16. interne Direktverbindung testen. 17. internen Zugriff über öffentliche Adresse testen. 18. tatsächlich externen Zugriff testen. 19. WAN-Adresse des Edge-Geräts prüfen. 20. vorgeschaltetes NAT oder CGNAT prüfen. 21. doppeltes NAT berücksichtigen. 22. richtige Eingangsschnittstelle bestimmen. 23. richtige öffentliche Zieladresse bestimmen. 24. aktive NAT-Konfiguration prüfen. 25. NAT-Regelreihenfolge prüfen. 26. NAT-Regeltreffer dokumentieren. 27. Firewallregel getrennt prüfen. 28. Routing zum internen Ziel prüfen. 29. Host-Firewall prüfen. 30. Listener des Serverdienstes prüfen. 31. Serverantwort und Rückroute prüfen. 32. NAT-Sitzung oder Translation Table prüfen. 33. Hin- und Rückverkehr vergleichen. 34. Hairpin-Unterstützung prüfen. 35. Hairpin-DNAT und gegebenenfalls SNAT prüfen. 36. Split-DNS-Verhalten berücksichtigen. 37. Reverse Proxy oder Load Balancer prüfen. 38. Container-Hostport und Containerport prüfen. 39. Kubernetes-Servicepfad berücksichtigen. 40. automatische Portabbildungen prüfen. 41. ALG oder NAT-Helper berücksichtigen. 42. IPv4 und IPv6 getrennt prüfen. 43. Cloud-NAT und Inbound-Komponente unterscheiden. 44. bei Bedarf Paketaufzeichnung vor und nach NAT durchführen. 45. Hypothese und Gegenbeweis formulieren. 46. genau eine kontrollierte Maßnahme vorbereiten. 47. Risiko, Rückweg und Erfolgskriterium dokumentieren. 48. Maßnahme freigeben und umsetzen. 49. neue Sitzung aufbauen. 50. internen, Hairpin- und externen Test wiederholen. 51. NAT-, Firewall- und Anwendungslogs verifizieren. 52. weitere repräsentative Quellen testen. 53. temporäre Regeln und Captures zurücknehmen. 54. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | interne Adresse funktioniert, öffentliche intern nicht | Hairpin NAT oder Split DNS | Hairpin-Sitzung und Rückweg prüfen | | öffentliche Adresse extern funktioniert | DNAT und externer Pfad grundsätzlich aktiv | internen Hairpin-Pfad getrennt prüfen | | öffentliche Adresse extern nicht erreichbar | Provider, CGNAT, WAN, DNAT oder Firewall | WAN-IP und NAT-Regeltreffer | | NAT-Regelzähler bleibt null | falsche IP, Schnittstelle, Port oder Pfad | Capture vor dem NAT-Gerät | | NAT-Regel trifft, Firewall blockiert | getrennte Sicherheitsrichtlinie | Firewalllog und Adressphase | | NAT und Firewall erlauben, Server antwortet nicht | Host-Firewall, Listener oder Dienst | serverseitiges Capture | | Server antwortet, NAT sieht Antwort nicht | falsche Rückroute | Serverroute und Gateway | | Rückantwort besitzt private Quelladresse | fehlende Rückübersetzung oder Hairpin-Asymmetrie | NAT-Sitzung und Pfad | | WAN-Adresse ist privat | vorgeschaltetes NAT | Upstreamgerät prüfen | | WAN-Adresse liegt in `100.64.0.0/10` | CGNAT wahrscheinlich | Provider und externe Adresse | | Router-WAN-IP weicht von externer IP ab | vorgeschaltetes NAT, VPN oder Proxy | vollständigen Ausgangspfad prüfen | | TCP funktioniert, UDP nicht | Protokollregel oder UDP-State | UDP-Capture und NAT-Timeout | | IPv4 funktioniert, FQDN nicht | AAAA-Pfad oder DNS | A-/AAAA-Antwort vergleichen | | externer Port offen, falsche Anwendung | falsches DNAT-Ziel oder Reverse Proxy | Backend und Hostheader prüfen | | Docker-Hostport lauscht nicht | Port nicht veröffentlicht oder Container gestoppt | `docker ps` und `docker port` | | Hostport lauscht, Container antwortet nicht | Containerdienst oder Zielport | Containerlistener und Logs | | Container direkt erreichbar, öffentlich nicht | Router-, Host- oder DNAT-Pfad | schrittweise Porttests | | Zugriff nach Routerneustart kurz möglich | Zustand, dynamische Adresse oder Konflikt | Translation Table und WAN-IP | | nur manche Quellen funktionieren | Quellfilter oder NAT-Filterverhalten | Regeln und Quelladressen vergleichen | | Zugriff über IP, nicht über Namen | DNS, SNI oder Zertifikat | FQDN und TLS-Prüfung | | intern anderer Server als extern | Split DNS oder Proxyunterschied | DNS-Antworten und Backend | | AWS NAT Gateway sendet ausgehend, kein Inbound | erwartetes Produktverhalten | Load Balancer oder andere Inbound-Komponente | | Azure NAT Gateway sendet ausgehend, kein Inbound | erwartetes Produktverhalten | Azure Firewall DNAT oder Load Balancer | | nach Regeländerung alte Sitzung bleibt | bestehender Translation State | vollständig neue Sitzung testen | | extern klappt nur über einen WAN-Anschluss | NAT-Regel nur an einer Schnittstelle | WAN-Bindung und Routing | --- **Typische Diagnosefehler** - NAT als Firewall betrachten. - Vorhandene NAT-Regel als vollständige Freigabe bewerten. - Öffentliche und private Adresse verwechseln. - externen und internen Port verwechseln. - TCP und UDP nicht unterscheiden. - IPv4 und IPv6 nicht getrennt prüfen. - FQDN nicht auf A und AAAA prüfen. - Regel an falscher WAN-Schnittstelle übersehen. - NAT-Regelreihenfolge ignorieren. - alte oder überschattete Regel nicht erkennen. - Rückweg nicht prüfen. - nur Hinrichtung aufzeichnen. - NAT-Sitzung nicht auswerten. - bestehende und neue Sitzung nicht unterscheiden. - interne Direktverbindung als Nachweis externer Erreichbarkeit verwenden. - internen Zugriff auf öffentliche Adresse als externen Test bewerten. - Mobilgerät im WLAN als externes System verwenden. - VPN-Pfad beim externen Test übersehen. - CGNAT nicht berücksichtigen. - `100.64.0.0/10` mit normalem RFC-1918-Netz gleichsetzen. - doppeltes NAT übersehen. - DMZ Host oder Exposed Host als schnelle Lösung aktivieren. - Hairpin NAT als überall vorhandene Funktion annehmen. - Split DNS ohne Betrachtung von Proxy und Sicherheitskontrollen einsetzen. - Hairpin-SNAT ohne Auswirkungen auf Clientprotokollierung aktivieren. - NAT als Schutzmechanismus für IPv6 verwenden. - UPnP zur Fehlerbehebung pauschal aktivieren. - automatisch erzeugte Portabbildungen nicht prüfen. - ALG ohne Nachweis deaktivieren oder aktivieren. - Docker-`EXPOSE` mit Portveröffentlichung verwechseln. - Docker-Hostport und Containerport verwechseln. - `-p` bei Host-Netzwerkmodus als wirksam annehmen. - Kubernetes Service Port und TargetPort verwechseln. - Cloud NAT Gateway als Inbound-Portweiterleitung behandeln. - erfolgreichen TCP-Handshake als Anwendungserfolg bewerten. - NAT- oder Conntrack-Tabelle vorsorglich leeren. - mehrere NAT- und Firewallregeln gleichzeitig verändern. - temporäre Portweiterleitung aktiv lassen. - Ursache und Sicherheitswirkung nicht dokumentieren. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - DNS liefert die vorgesehenen Adressen; - Client verwendet die erwartete Adressfamilie; - öffentliche Zieladresse stimmt; - WAN-Adresse stimmt; - vorgeschaltetes NAT ist berücksichtigt; - externes Protokoll stimmt; - externer Port stimmt; - internes Ziel stimmt; - interner Port stimmt; - NAT-Regel trifft; - richtige NAT-Regel trifft; - Regelreihenfolge ist korrekt; - Firewallregel erlaubt nur den benötigten Verkehr; - Quellbereich ist angemessen begrenzt; - internes Routing funktioniert; - Server besitzt die erwartete Adresse; - Serverdienst lauscht; - Host-Firewall erlaubt den benötigten Verkehr; - Rückroute führt über die richtige NAT-Komponente; - NAT-Sitzung enthält korrekte Original- und Antworttupel; - interner Direktzugriff funktioniert; - Hairpin-Zugriff funktioniert, sofern vorgesehen; - Split DNS funktioniert, sofern vorgesehen; - externer Zugriff aus einem unabhängigen Netz funktioniert; - TCP und UDP funktionieren, sofern erforderlich; - IPv4 und IPv6 funktionieren, sofern vorgesehen; - TLS-Zertifikat und SNI stimmen; - Reverse Proxy erreicht das richtige Backend; - Docker-Host- und Containerport stimmen; - Kubernetes Service und Endpoint stimmen; - keine unbeabsichtigte Portveröffentlichung besteht; - keine allgemeine Exposed-Host-Regel aktiv ist; - Logs zeigen die erwartete Quelle und Übersetzung; - Monitoring erkennt Ausfälle; - temporäre Regeln und Captures wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine erfolgreiche Verbindung aus dem internen Netz reicht nicht als Verifikation einer Internet-Portweiterleitung. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: FQDN: DNS-Antworten: Externe Quelle: Öffentliches Ziel: Protokoll: Internes Ziel: Vor-NAT-Tupel: Ziel:Port> Nach-NAT-Tupel: Ziel:Port> NAT-Gerät: Eingangsschnittstelle: Ausgangsschnittstelle: NAT-Regel: Firewallregel: NAT-Sitzung: WAN-Adresse: Extern beobachtete Adresse: Vorgeschaltetes NAT: CGNAT: Rückroute: Serverlistener: Host-Firewall: Containerzuordnung: Hostport -> Containerport> Reverse Proxy: Interner Direktzugriff: Interner Zugriff über öffentliche Adresse: Externer Zugriff: Paketaufzeichnung: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] Anwendung bestimmt - [ ] FQDN dokumentiert - [ ] A-Eintrag geprüft - [ ] AAAA-Eintrag geprüft - [ ] tatsächliche Zieladresse bestimmt - [ ] IPv4 und IPv6 unterschieden - [ ] TCP und UDP unterschieden - [ ] externe Quelladresse erfasst - [ ] öffentlichen Zielport erfasst - [ ] internes Ziel erfasst - [ ] internen Zielport erfasst - [ ] Vor-NAT-Tupel dokumentiert - [ ] Nach-NAT-Tupel dokumentiert - [ ] Fehlerumfang bestimmt - [ ] interne Direktverbindung getestet - [ ] internen Zugriff über öffentliche Adresse getestet - [ ] echten externen Zugriff getestet - [ ] WAN-Adresse geprüft - [ ] extern beobachtete Adresse geprüft - [ ] vorgeschaltetes NAT geprüft - [ ] CGNAT geprüft - [ ] doppeltes NAT geprüft - [ ] öffentliche Adresszuordnung geprüft - [ ] richtige Eingangsschnittstelle geprüft - [ ] richtige Ausgangsschnittstelle geprüft - [ ] NAT-Regel bestimmt - [ ] NAT-Regelposition geprüft - [ ] NAT-Regeltreffer geprüft - [ ] Überschattung geprüft - [ ] NAT-Ausnahme geprüft - [ ] Firewallregel getrennt geprüft - [ ] Quellbereich geprüft - [ ] interne Route geprüft - [ ] Rückroute geprüft - [ ] Serveradresse geprüft - [ ] DHCP-Reservierung geprüft - [ ] Serverlistener geprüft - [ ] Host-Firewall geprüft - [ ] NAT-Sitzung geprüft - [ ] Originalrichtung geprüft - [ ] Antwortrichtung geprüft - [ ] Pakete und Bytes je Richtung geprüft - [ ] Hairpin-Unterstützung geprüft - [ ] Hairpin-DNAT geprüft - [ ] Hairpin-SNAT geprüft - [ ] Auswirkung auf Client-IP-Protokollierung geprüft - [ ] Split DNS geprüft - [ ] TLS-Zertifikat geprüft - [ ] SNI geprüft - [ ] Reverse Proxy geprüft - [ ] Load Balancer geprüft - [ ] Backend geprüft - [ ] Docker-Netzwerkmodus geprüft - [ ] Docker-Hostport geprüft - [ ] Containerport geprüft - [ ] Containerlistener geprüft - [ ] Kubernetes Service geprüft - [ ] Kubernetes TargetPort geprüft - [ ] EndpointSlices geprüft - [ ] automatische Portabbildungen geprüft - [ ] UPnP, NAT-PMP oder PCP geprüft - [ ] ALG und NAT-Helper geprüft - [ ] Cloud-NAT und Inbound-Komponente unterschieden - [ ] Paketaufzeichnung vor NAT durchgeführt, sofern erforderlich - [ ] Paketaufzeichnung nach NAT durchgeführt, sofern erforderlich - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] vollständig neue Sitzung getestet - [ ] ursprüngliche Anwendung verifiziert - [ ] weitere repräsentative Quellen geprüft - [ ] temporäre Weiterleitung entfernt - [ ] temporäre Captures entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-NAT-Objekte | `Get-NetNat` | | Windows-statische NAT-Abbildungen | `Get-NetNatStaticMapping` | | Windows-NAT-Sitzungen | `Get-NetNatSession` | | Windows-Routing | `Get-NetRoute` | | Windows-Listener | `Get-NetTCPConnection -State Listen` | | Windows-DNS A | `Resolve-DnsName -Name "app.example.test" -Type A` | | Windows-DNS AAAA | `Resolve-DnsName -Name "app.example.test" -Type AAAA` | | Windows-TCP-Porttest | `Test-NetConnection -ComputerName "203.0.113.10" -Port 8443` | | Linux-nftables-Regelwerk | `sudo nft list ruleset` | | Linux-nftables-Tabellen | `sudo nft list tables` | | Linux-nftables mit Handles | `sudo nft -a list ruleset` | | Linux-iptables-NAT | `sudo iptables -t nat -L -n -v --line-numbers` | | Linux-iptables-NAT-Regeln | `sudo iptables -t nat -S` | | Linux-Forwardingregeln | `sudo iptables -L FORWARD -n -v --line-numbers` | | Linux-IPv4-Forwarding | `sysctl net.ipv4.ip_forward` | | Linux-Conntrack | `sudo conntrack -L` | | Linux-Conntrack-Ereignisse | `sudo conntrack -E` | | Linux-Listener | `ss -lntp` | | Linux/macOS-DNS A | `dig app.example.test A` | | Linux/macOS-DNS AAAA | `dig app.example.test AAAA` | | Linux/macOS-TCP-Porttest | `nc -vz 203.0.113.10 8443` | | HTTPS-Test | `curl -v https://app.example.test:8443/` | | Docker-Ports | `docker ps --format 'table {{.Names}}\t{{.Ports}}'` | | Docker-Portzuordnung | `docker port ` | | Docker-Details | `docker inspect ` | | Kubernetes-Services | `kubectl get services --all-namespaces -o wide` | | Kubernetes-Ingress | `kubectl get ingress --all-namespaces` | | Kubernetes-Endpunkte | `kubectl get endpointslices --all-namespaces` | | Cisco-ASA-NAT | `show nat` | | Cisco-ASA-NAT-Details | `show nat detail` | | Cisco-ASA-Übersetzungen | `show xlate` | | Cisco-ASA-Verbindungen | `show conn` | | Cisco-ASA-Routing | `show route` | Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen: ```text New-NetNat Add-NetNatStaticMapping Remove-NetNat Remove-NetNatStaticMapping nft add rule ... dnat ... nft add rule ... snat ... nft flush ruleset iptables -t nat -F conntrack -F clear xlate clear conn Firewall deaktivieren Exposed Host aktivieren DMZ Host aktivieren alle Ports weiterleiten UPnP pauschal aktivieren NAT-PMP pauschal aktivieren PCP pauschal aktivieren ALG ungeprüft deaktivieren ALG ungeprüft aktivieren Router vorsorglich neu starten Firewall vorsorglich neu starten öffentliche Verwaltungsports testweise freigeben allgemeine any-any-Regel erstellen ``` --- **Quellen** **Standards** - [RFC 2663 – IP Network Address Translator Terminology and Considerations](https://datatracker.ietf.org/doc/html/rfc2663) - [RFC 3022 – Traditional IP Network Address Translator](https://datatracker.ietf.org/doc/html/rfc3022) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 5382 – NAT Behavioral Requirements for TCP](https://datatracker.ietf.org/doc/html/rfc5382) - [RFC 5508 – NAT Behavioral Requirements for ICMP](https://datatracker.ietf.org/doc/html/rfc5508) - [RFC 7857 – Updates to NAT Behavioral Requirements](https://datatracker.ietf.org/doc/html/rfc7857) - [RFC 1918 – Address Allocation for Private Internets](https://datatracker.ietf.org/doc/html/rfc1918) - [RFC 6598 – Shared Address Space Request](https://datatracker.ietf.org/doc/html/rfc6598) - [RFC 6886 – NAT Port Mapping Protocol](https://datatracker.ietf.org/doc/html/rfc6886) - [RFC 6887 – Port Control Protocol](https://datatracker.ietf.org/doc/html/rfc6887) - [RFC 6296 – IPv6-to-IPv6 Network Prefix Translation](https://datatracker.ietf.org/doc/html/rfc6296) - [RFC 2993 – Architectural Implications of NAT](https://datatracker.ietf.org/doc/html/rfc2993) **Microsoft Windows** - [Microsoft Learn – Get-NetNat](https://learn.microsoft.com/en-us/powershell/module/netnat/get-netnat) - [Microsoft Learn – Get-NetNatStaticMapping](https://learn.microsoft.com/en-us/powershell/module/netnat/get-netnatstaticmapping) - [Microsoft Learn – Get-NetNatSession](https://learn.microsoft.com/en-us/powershell/module/netnat/get-netnatsession) - [Microsoft Learn – Set Up a NAT Network](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network) - [Microsoft Learn – Windows Container Network Drivers](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-drivers-topologies) **Linux Netfilter** - [Netfilter – nftables Manual](https://www.netfilter.org/projects/nftables/manpage.html) - [Netfilter – iptables Extensions Manual](https://ipset.netfilter.org/iptables-extensions.man.html) - [Netfilter – Conntrack Tools User Manual](https://conntrack-tools.netfilter.org/manual.html) - [Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) **Docker und Kubernetes** - [Docker Docs – Port Publishing and Mapping](https://docs.docker.com/engine/network/port-publishing/) - [Docker Docs – Networking Overview](https://docs.docker.com/engine/network/) - [Docker Docs – Bridge Network Driver](https://docs.docker.com/engine/network/drivers/bridge/) - [Docker Docs – Host Network Driver](https://docs.docker.com/engine/network/drivers/host/) - [Docker Docs – Packet Filtering and Firewalls](https://docs.docker.com/engine/network/packet-filtering-firewalls/) - [Kubernetes Documentation – Service](https://kubernetes.io/docs/concepts/services-networking/service/) - [Kubernetes Documentation – Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) **Cisco** - [Cisco Secure Firewall ASA – NAT Basics](https://www.cisco.com/c/en/us/td/docs/security/asa/asa920/configuration/firewall/asa-920-firewall-config/nat-basics.html) - [Cisco – Configure NAT and ACLs on ASA](https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115904-asa-config-dmz-00.html) - [Cisco Secure Firewall ASA – `packet-tracer` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/pa-pn-commands.html) **Amazon Web Services** - [AWS – NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) - [AWS – NAT Gateway Basics](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html) - [AWS – NAT Gateway Use Cases](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html) - [AWS – Internet Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) **Microsoft Azure** - [Microsoft Learn – Azure NAT Gateway Overview](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview) - [Microsoft Learn – Azure NAT Gateway Resource](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-resource) - [Microsoft Learn – Azure Load Balancer Outbound Connections](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections) - [Microsoft Learn – Azure Firewall DNAT](https://learn.microsoft.com/en-us/azure/firewall/dnat-rules) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.