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: Transportprotokoll + lokale IP-Adresse + lokaler Port Beispiel: TCP 192.0.2.25:443 Eine aufgebaute TCP-Verbindung wird durch beide Endpunkte unterschieden: Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port Beispiel: TCP lokal: 192.0.2.25:443 remote: 198.51.100.40:53124 Ein einzelner TCP-Listener auf Port 443 kann deshalb viele gleichzeitige Verbindungen bedienen. Die einzelnen Verbindungen unterscheiden sich mindestens durch die entfernte Adresse oder den entfernten Port. UDP besitzt keinen TCP-Verbindungsaufbau und keinen TCP-Zustand LISTEN . Ein UDP-Endpunkt kann dennoch an eine lokale Adresse und einen lokalen Port gebunden sein und Datagramme empfangen. Gebundene Adressen richtig interpretieren Bindung Bedeutung 127.0.0.1:8080 Nur über IPv4-Loopback des eigenen Systems erreichbar 192.0.2.25:8080 Nur über diese konkrete IPv4-Adresse erreichbar 0.0.0.0:8080 IPv4-Wildcard; Bindung an alle geeigneten lokalen IPv4-Adressen [::1]:8080 Nur über IPv6-Loopback erreichbar [::]:8080 IPv6-Wildcard; Bindung an alle geeigneten lokalen IPv6-Adressen :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 127.0.0.1:8080 [::1]:8080 Der Dienst ist grundsätzlich nur vom eigenen Netzwerk-Namespace erreichbar. Das ist beispielsweise für lokale Backends hinter einem Reverse Proxy sinnvoll. Ein entfernter Client kann diesen Listener nicht direkt erreichen. Wildcard-Bindung 0.0.0.0:8080 [::]:8080 Der Dienst lauscht grundsätzlich auf allen dafür geeigneten Adressen der entsprechenden Protokollfamilie. Dazu können gehören: LAN-Schnittstellen; WLAN-Schnittstellen; VPN-Schnittstellen; öffentliche Schnittstellen; virtuelle Switches; Container-Bridges. Ob der Dienst tatsächlich von jedem Netz erreichbar ist, wird zusätzlich durch Routing, Firewall, NAT, Sicherheitsgruppen und vorgelagerte Systeme bestimmt. Bindung an eine konkrete Adresse 192.0.2.25:8080 Der Dienst nimmt Verbindungen nur über diese lokale Adresse an. Die Bindung kann beim Dienststart fehlschlagen, wenn: die Adresse nicht mehr am System vorhanden ist; die Schnittstelle noch nicht verfügbar ist; DHCP eine andere Adresse vergeben hat; die Adresse erst durch einen später gestarteten VPN-Tunnel entsteht; die Anwendung vor der Netzwerkkonfiguration gestartet wird; sich der Dienst in einem anderen Netzwerk-Namespace befindet. TCP-Zustände Zustand Einordnung LISTEN Lokaler Socket wartet auf neue TCP-Verbindungen. SYN-SENT Verbindungsaufbau wurde begonnen; Antwort steht noch aus. SYN-RECEIVED Ein SYN wurde empfangen und der Aufbau ist noch nicht abgeschlossen. ESTABLISHED TCP-Verbindung ist aufgebaut. FIN-WAIT-1 Lokale Seite hat das Schließen begonnen. FIN-WAIT-2 Lokale Seite wartet nach eigenem FIN auf das FIN der Gegenstelle. CLOSE-WAIT Gegenstelle hat geschlossen; lokale Anwendung muss noch schließen. LAST-ACK Lokale Seite wartet auf die Bestätigung ihres abschließenden FIN. TIME-WAIT Geschlossene Verbindung wird vorübergehend zur sicheren Protokollabwicklung vorgehalten. CLOSED Keine aktive TCP-Verbindung. Viele Einträge in TIME-WAIT sind nicht automatisch ein Fehler. Sie können bei kurzlebigen Verbindungen normal sein. Dauerhaft viele CLOSE-WAIT -Sockets können darauf hindeuten, dass die lokale Anwendung geschlossene Verbindungen nicht ordnungsgemäß freigibt. Dieser Befund muss über Zeitverlauf, Prozesszustand und Anwendungstelemetrie bestätigt werden. Was ein Listener beweist – und was nicht Ein Listener beweist: ein Socket wurde im untersuchten Netzwerk-Namespace angelegt; der Socket ist an einen lokalen Port gebunden; das Betriebssystem führt ihn als empfangsbereiten TCP-Socket; ein Prozess oder Kernelbestandteil besitzt den Socket. Ein Listener beweist nicht: dass die Firewall eingehende Verbindungen erlaubt; dass Routing zum Server funktioniert; dass NAT oder Portweiterleitung korrekt sind; dass ein Load Balancer das richtige Ziel verwendet; dass die Anwendung nach dem Verbindungsaufbau korrekt antwortet; dass TLS, HTTP, DNS oder ein anderes Anwendungsprotokoll funktioniert; dass der Dienst unter dem erwarteten Namen erreichbar ist; dass IPv4 und IPv6 gleichermaßen funktionieren; dass der Listener im richtigen Container oder Netzwerk-Namespace existiert. Erwarteten Endpunkt festlegen Vor der Diagnose müssen mindestens folgende Sollangaben dokumentiert werden: Dienst: 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: Get-NetTCPConnection Nur TCP-Listener: Get-NetTCPConnection ` -State Listen | Sort-Object LocalPort, LocalAddress Bestimmten lokalen Port prüfen: Get-NetTCPConnection ` -State Listen ` -LocalPort 443 Ausgabe auf wesentliche Felder begrenzen: Get-NetTCPConnection ` -State Listen | Select-Object ` LocalAddress, LocalPort, State, OwningProcess | Sort-Object LocalPort, LocalAddress Zu prüfen sind: LocalAddress ; LocalPort ; State ; OwningProcess ; mehrere Listener auf demselben Port; getrennte IPv4- und IPv6-Einträge; unerwartete Loopback-Bindung; unerwartete Wildcard-Bindung. Windows: Prozess eines TCP-Listeners bestimmen LESEND Beispiel für Port 443 : Get-NetTCPConnection ` -State Listen ` -LocalPort 443 | ForEach-Object { $connection = $_ $process = Get-Process ` -Id $connection.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $connection.LocalAddress LocalPort = $connection.LocalPort ProcessId = $connection.OwningProcess ProcessName = $process.ProcessName ProcessPath = $process.Path } } Einen bekannten Prozess prüfen: Get-Process ` -Id 1234 Die ausführbare Datei kann abhängig von Prozessschutz und Berechtigungen nicht immer angezeigt werden. Windows: Prozess einem Dienst zuordnen LESEND $processId = 1234 Get-CimInstance ` -ClassName Win32_Service ` -Filter "ProcessId = $processId" | Select-Object ` Name, DisplayName, State, StartMode, ProcessId, PathName Wenn kein Dienst zurückgegeben wird, kann der Prozess beispielsweise: interaktiv gestartet worden sein; durch einen Task gestartet worden sein; zu einer Desktopanwendung gehören; Teil einer Container- oder Virtualisierungsumgebung sein; durch einen anderen Dienstprozess verwaltet werden. Windows: UDP-Endpunkte erfassen LESEND Alle UDP-Endpunkte: Get-NetUDPEndpoint | Sort-Object LocalPort, LocalAddress Bestimmten UDP-Port prüfen: Get-NetUDPEndpoint ` -LocalPort 53 UDP-Endpunkt mit Prozessinformationen anzeigen: Get-NetUDPEndpoint ` -LocalPort 53 | ForEach-Object { $endpoint = $_ $process = Get-Process ` -Id $endpoint.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $endpoint.LocalAddress LocalPort = $endpoint.LocalPort ProcessId = $endpoint.OwningProcess ProcessName = $process.ProcessName } } Das Vorhandensein eines UDP-Endpunkts beweist noch nicht, dass eine gesendete Anfrage verarbeitet oder beantwortet wird. Windows: netstat als ergänzende Sicht LESEND netstat -ano Nur TCP-Listener: netstat -ano -p tcp UDP-Endpunkte: netstat -ano -p udp Wiederholte Aktualisierung alle fünf Sekunden: netstat -ano 5 Beenden mit Strg+C . Wichtige Optionen: Option Bedeutung -a Zeigt aktive Verbindungen und Listener. -n Zeigt numerische Adressen und Ports. -o Zeigt die zugehörige Prozess-ID. -p tcp Begrenzt die Anzeige auf TCP. -p udp Begrenzt die Anzeige auf UDP. Namensauflösung sollte für die erste Diagnose mit -n vermieden werden. Anderenfalls können DNS-Verzögerungen die Ausgabe verlangsamen oder Adressen durch Namen verdecken. Windows: lokale IP-Adressen bestätigen LESEND Get-NetIPConfiguration Alle verwendbaren IP-Adressen: Get-NetIPAddress | Where-Object AddressState -eq "Preferred" | Sort-Object InterfaceIndex, AddressFamily Eine Bindung an eine konkrete Adresse ist nur sinnvoll, wenn diese Adresse tatsächlich im richtigen Netzwerk-Compartment und auf der vorgesehenen Schnittstelle vorhanden ist. Windows: Kernel- und HTTP.sys-Zuordnungen prüfen Ein Port kann durch einen Kernelbestandteil oder eine gemeinsame HTTP-Infrastruktur verwaltet werden. Der sichtbare Besitzer muss daher nicht unmittelbar der erwartete Anwendungsprozess sein. Bei HTTP- oder HTTPS-Diensten unter Windows: LESEND netsh http show servicestate Registrierte URL-Zuordnungen: netsh http show urlacl Registrierte TLS-Zertifikatbindungen: netsh http show sslcert Portproxy-Konfiguration: netsh interface portproxy show all Zu prüfen sind: welcher Dienst die URL registriert hat; welcher Prozess eine HTTP.sys-Anforderungswarteschlange verwendet; ob eine Portproxy-Regel besteht; ob der sichtbare Hostport an ein anderes Ziel weiterleitet; ob der Prozessbesitzer nur als System erscheint. Eine URL-Reservierung allein beweist keinen aktiven Listener. Linux: TCP- und UDP-Sockets mit ss prüfen ss ist unter Linux das bevorzugte Werkzeug zur Anzeige von Socketinformationen. LESEND TCP-Listener: ss -lnt TCP-Listener einschließlich Prozessinformationen: sudo ss -lntp UDP-Endpunkte: sudo ss -lnup TCP- und UDP-Endpunkte gemeinsam: sudo ss -lntup Bestimmten TCP-Port prüfen: sudo ss -lntp 'sport = :443' Bestimmten UDP-Port prüfen: sudo ss -lnup 'sport = :53' Alle TCP-Verbindungen und Zustände: ss -tan Zusammenfassung: ss -s Wichtige Optionen: Option Bedeutung -l Nur lauschende beziehungsweise unverbundene Endpunkte -n Numerische Adressen und Ports -t TCP -u UDP -p Prozessinformationen -a Alle Sockets -x Unix-Domain-Sockets Prozessinformationen können erhöhte Berechtigungen erfordern. Linux: Prozess mit lsof bestimmen LESEND Alle lauschenden TCP-Sockets: sudo lsof -nP -iTCP -sTCP:LISTEN Bestimmten TCP-Port prüfen: sudo lsof -nP -iTCP:443 -sTCP:LISTEN Bestimmten UDP-Port prüfen: sudo lsof -nP -iUDP:53 Wichtige Optionen: Option Bedeutung -n Keine Namensauflösung der IP-Adressen -P Keine Umwandlung von Ports in Dienstnamen -iTCP TCP-Sockets -iUDP UDP-Sockets -sTCP:LISTEN Nur TCP-Listener Danach können Prozess und Dienst untersucht werden: ps -fp Bei einem systemd-Dienst: systemctl status Prozessbaum: pstree -p Falls pstree nicht installiert ist: ps -ef --forest Linux: Netzwerkadressen und Namespace prüfen LESEND ip address show Kompakte Ansicht: ip -brief address Netzwerk-Namespaces anzeigen: ip netns list Socketansicht eines bekannten Prozess-Namespace: sudo nsenter \ -t \ -n \ ss -lntup Dieser Test ist besonders wichtig, wenn ein Prozess in einem Container oder separaten Netzwerk-Namespace läuft. Ein Listener innerhalb eines Container-Namespace muss nicht als normaler Listener in der Sockettabelle des Hosts erscheinen. macOS: TCP- und UDP-Sockets prüfen Linux- ss ist unter macOS standardmäßig nicht verfügbar. Für die Prozesszuordnung ist lsof besonders geeignet. LESEND Alle TCP-Listener: sudo lsof -nP -iTCP -sTCP:LISTEN Bestimmten TCP-Port prüfen: sudo lsof -nP -iTCP:443 -sTCP:LISTEN UDP-Endpunkte: sudo lsof -nP -iUDP Bestimmten UDP-Port prüfen: sudo lsof -nP -iUDP:53 TCP-Socketzustände mit netstat : netstat -anv -p tcp UDP-Sockets: netstat -anv -p udp Lokale Netzwerkschnittstellen: ifconfig Routing- und Schnittstelleninformationen: route -n get default Für die Zuordnung eines Ports zu einem Prozess sollte unter macOS nicht allein auf netstat vertraut werden. lsof liefert dafür normalerweise die geeignetere Sicht. Unix-Domain-Sockets und andere lokale IPC-Endpunkte Nicht jede lokale Dienstkommunikation verwendet einen TCP- oder UDP-Port. Typische Alternativen sind: Unix-Domain-Sockets; Windows Named Pipes; Shared Memory; lokale Message Queues; anwendungsspezifische IPC-Mechanismen. Linux: sudo ss -lxnp Linux und macOS: sudo lsof -U Ein Reverse Proxy kann beispielsweise über einen Unix-Domain-Socket mit seinem Backend kommunizieren. In diesem Fall ist für die Backendverbindung kein TCP-Listener sichtbar. Die Diagnose muss dann zusätzlich prüfen: Pfad des Sockets; Dateiberechtigungen; Besitzer und Gruppe; Existenz nach dem Dienststart; Namespace oder Container; SELinux- beziehungsweise AppArmor-Richtlinien; Konfiguration von Proxy und Backend. Portkonflikte erkennen Typische Meldungen eines Bindungsfehlers sind: Address already in use EADDRINUSE WSAEADDRINUSE Only one usage of each socket address is normally permitted Mögliche Ursachen: ein anderer Prozess besitzt bereits denselben Endpunkt; eine alte Instanz der Anwendung läuft noch; zwei Dienste verwenden dieselbe konfigurierte Adresse und denselben Port; ein Wildcard-Listener kollidiert mit einer spezifischen Bindung; IPv4- und IPv6-Verhalten wurde falsch eingeschätzt; ein Dienst wird doppelt durch Service Manager und manuellen Start gestartet; ein Container veröffentlicht bereits denselben Hostport; eine Portproxy- oder Kernelkomponente ist beteiligt. Windows: Get-NetTCPConnection ` -State Listen ` -LocalPort 8080 Get-NetUDPEndpoint ` -LocalPort 8080 Linux: sudo ss -lntup 'sport = :8080' macOS: sudo lsof -nP -iTCP:8080 -sTCP:LISTEN Ein Port kann unter bestimmten Bedingungen absichtlich durch mehrere Prozesse oder Sockets gemeinsam verwendet werden. Beispiele sind Socketaktivierung, SO_REUSEPORT , gemeinsam verwaltete Kernel-Listener oder Clustermechanismen. Deshalb darf ein ungewöhnlicher Mehrfachbefund nicht ohne Prüfung als Fehler bewertet werden. Weitere typische Bindungsfehler Meldung oder Fehler Mögliche Einordnung Address already in use Endpunkt wird bereits verwendet. Permission denied Fehlende Berechtigung, Sicherheitsrichtlinie oder geschützter Port. EACCES Zugriff auf Adresse oder Port verweigert. Cannot assign requested address Konfigurierte lokale Adresse ist nicht vorhanden. EADDRNOTAVAIL Lokale Bindungsadresse steht nicht zur Verfügung. Connection refused Zielsystem lehnt aktiv ab; häufig kein passender Listener. Timeout Keine verwertbare Antwort; Paketverlust, Filterung, Routing oder Überlastung möglich. Verbindung erfolgreich, Protokollfehler Transport funktioniert; Anwendung oder Protokollkonfiguration fehlerhaft. Die Zuordnung ist eine erste Einordnung und kein alleiniger Ursachennachweis. Lokalen TCP-Endpunkt testen Ein lokaler Test muss zur tatsächlichen Bindung passen. Windows: NETZAKTIV Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 8080 ` -InformationLevel Detailed Test gegen die konkrete Schnittstellenadresse: Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 8080 ` -InformationLevel Detailed Linux und macOS: nc -vz 127.0.0.1 8080 nc -vz 192.0.2.25 8080 Ein erfolgreicher TCP-Test beweist nur, dass der TCP-Verbindungsaufbau funktioniert hat. Er beweist nicht, dass die Anwendung ein gültiges Ergebnis liefert. Test-NetConnection -Port prüft TCP. Es ist kein allgemeiner UDP-Test. Loopback und Schnittstellenadresse getrennt testen Die folgenden Befunde müssen unterschieden werden: Loopback-Test Test gegen Serveradresse Mögliche Einordnung erfolgreich erfolgreich Listener ist lokal über beide Pfade erreichbar erfolgreich fehlgeschlagen falsche Bindung, lokale Firewall oder Adressproblem fehlgeschlagen erfolgreich Dienst lauscht nur auf konkreter Adresse fehlgeschlagen fehlgeschlagen kein Listener, falscher Port, falsches Protokoll oder Dienstfehler Ein Test gegen localhost kann je nach Namensauflösung zuerst ::1 oder 127.0.0.1 verwenden. Für eine eindeutige Diagnose müssen IPv4- und IPv6-Adressen ausdrücklich getestet werden. Windows: Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 8080 Test-NetConnection ` -ComputerName "::1" ` -Port 8080 Linux und macOS: nc -4 -vz 127.0.0.1 8080 nc -6 -vz ::1 8080 Test von einem entfernten Client Der Test muss von einem System erfolgen, das den realen Zugriffspfad möglichst genau abbildet. Windows: NETZAKTIV Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed Linux und macOS: nc -vz app.example.test 443 Getrennte Prüfung einer bekannten IP-Adresse: nc -vz 192.0.2.25 443 Zu dokumentieren sind: verwendeter Zielname; aufgelöste Zieladresse; Quelladresse; Zielport; TCP-Ergebnis; Zeitpunkt; Teststandort; VPN-Zustand; IPv4 oder IPv6; direkter oder weitergeleiteter Pfad. Nur autorisierte Ziele und Ports dürfen geprüft werden. Breite Portscans sind für die Diagnose eines bekannten Dienstendpunkts normalerweise nicht erforderlich. Anwendungsprotokoll statt nur Port prüfen Nach erfolgreichem TCP-Verbindungsaufbau muss das erwartete Anwendungsprotokoll getestet werden. HTTP: curl -v http://127.0.0.1:8080/ HTTPS mit korrektem Hostnamen und festgelegter Zieladresse: curl -v \ --resolve app.example.test:443:192.0.2.25 \ https://app.example.test/ TLS mit Server Name Indication: openssl s_client \ -connect 192.0.2.25:443 \ -servername app.example.test DNS über UDP: dig @192.0.2.53 example.test A DNS über TCP: dig @192.0.2.53 example.test A +tcp Ein erfolgreicher TCP-Test auf Port 443 beweist beispielsweise nicht: dass der TLS-Handshake funktioniert; dass das richtige Zertifikat geliefert wird; dass SNI korrekt verarbeitet wird; dass HTTP eine gültige Antwort liefert; dass der erwartete virtuelle Host ausgewählt wird. UDP richtig prüfen UDP besitzt keinen TCP-Handshake. Deshalb kann ein allgemeiner UDP-Porttest kein gleichwertiges Ergebnis wie ein erfolgreicher TCP-Verbindungsaufbau liefern. Zu prüfen sind: existiert ein lokaler UDP-Endpunkt? verlässt die Anfrage den Client? erreicht sie den Server? antwortet die Anwendung? erreicht die Antwort den Client? wird ein ICMP-Fehler zurückgegeben? wird ICMP unterwegs gefiltert? wird das richtige Anwendungsprotokoll verwendet? Ein Aufruf wie: nc -vzu 192.0.2.53 53 kann Datagramme erzeugen, liefert aber ohne geeignete Anwendungsantwort keinen belastbaren Nachweis für einen funktionsfähigen UDP-Dienst. Für UDP ist ein protokollspezifischer Test vorzuziehen, beispielsweise: dig für DNS; ntpq , chronyc oder ein geeigneter NTP-Test für NTP; ein herstellerspezifischer Testclient; eine begrenzte Netzwerkaufzeichnung. Firewall und Listener getrennt betrachten Die Diagnoseebenen sind voneinander zu trennen: Anwendungsprozess → lokaler Socket → lokale Firewall → Routing und Netzwerk → externe Firewall oder NAT → Client Mögliche Befunde: Dienst läuft, aber kein Socket wurde gebunden; Socket existiert, lokale Firewall blockiert; lokale Prüfung funktioniert, entfernte Prüfung schlägt fehl; entfernte Verbindung erreicht den Server, Antwortweg fehlt; NAT leitet auf einen falschen Hostport weiter; Load Balancer verwendet den falschen Backendport; Reverse Proxy erreicht sein lokales Backend nicht. Ein laufender Dienststatus beweist keinen Listener. Ein Listener beweist keine Firewallfreigabe. Windows-Firewallbezug lesend prüfen Aktive eingehende Regeln anzeigen: LESEND Get-NetFirewallRule ` -Enabled True ` -Direction Inbound | Select-Object ` DisplayName, Action, Profile, Direction Portfilter zu einer bekannten Regel: Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallPortFilter Adressfilter: Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallAddressFilter Anwendungsfilter: 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: Client → Reverse Proxy auf 0.0.0.0:443 → Backend auf 127.0.0.1:8080 In diesem Fall müssen zwei getrennte Endpunkte geprüft werden: externer Listener des Reverse Proxys; interner Listener des Backends. Mögliche Fehler: Proxy lauscht nicht auf Port 443 ; Backend lauscht nicht auf Port 8080 ; Backend ist nur über IPv6 erreichbar, Proxy verwendet IPv4; Proxy verwendet den falschen Backendport; Backend befindet sich in einem Container und 127.0.0.1 bezeichnet dort einen anderen Namespace; Proxy erwartet einen Unix-Domain-Socket; TLS endet am Proxy, während das Backend fälschlich ebenfalls TLS erwartet; Health Check und produktiver Zielport unterscheiden sich. Ein erfolgreicher externer TCP-Verbindungsaufbau beweist nicht, dass das Backend erreichbar ist. Container und Netzwerk-Namespaces Container besitzen häufig eine eigene Netzwerksicht. Dabei sind mindestens drei Endpunkte zu unterscheiden: Anwendungsport im Container veröffentlichter Port auf dem Host Port des zugreifenden Clients Beispiel: Container: 172.18.0.5:80 Host: 192.0.2.25:8080 Client: verbindet zu 192.0.2.25:8080 Ein Dienst, der innerhalb des Containers nur an 127.0.0.1:80 gebunden ist, ist über eine normale Portveröffentlichung häufig nicht erreichbar. Für den Zugriff über das Container-Netz muss er üblicherweise an der Containeradresse oder an einer geeigneten Wildcard-Adresse lauschen. Docker: Portzuordnung prüfen LESEND Laufende Container und veröffentlichte Ports: docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' Portzuordnungen eines Containers: docker port Ausführliche Portkonfiguration: docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' Netzwerkmodus: docker inspect \ \ --format '{{.HostConfig.NetworkMode}}' Containeradresse: docker inspect \ \ --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' Listener innerhalb des Containers, falls ss vorhanden ist: docker exec \ \ ss -lntup Alternativ, falls lsof vorhanden ist: 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: 127.0.0.1:8080:80 Bedeutung: Host 127.0.0.1:8080 → Containerport 80 Dieser Hostport soll nur lokal erreichbar sein. 8080:80 Bedeutung: Hostport 8080 → Containerport 80 Ohne ausdrücklich angegebene Hostadresse veröffentlicht Docker den Port standardmäßig auf den Hostadressen. Die genaue Erreichbarkeit hängt zusätzlich von Docker-, Firewall- und IPv4-/IPv6-Konfiguration ab. Wichtige Unterscheidungen: EXPOSE im Image veröffentlicht keinen Hostport; -p beziehungsweise --publish erstellt eine Portveröffentlichung; -P veröffentlicht dafür vorgesehene Ports automatisch auf Hostports; Hostport und Containerport können unterschiedlich sein; Container-IP und Host-IP sind unterschiedliche Adressen; der Listener im Container muss zum Containerport passen; im Host-Netzwerkmodus teilt der Container den Netzwerk-Namespace des Hosts; im Host-Netzwerkmodus werden normale Publish-Optionen nicht wie bei einem Bridge-Netzwerk verwendet. Ein veröffentlichter Docker-Port muss nicht immer als gewöhnlicher Benutzerprozess-Listener in der erwarteten Host-Socketliste erscheinen. Weiterleitung kann abhängig von Plattform und Konfiguration über Firewall-, NAT- oder Proxymechanismen erfolgen. Kubernetes: Portebenen unterscheiden Bei Kubernetes sind mehrere Portangaben auseinanderzuhalten: Feld Bedeutung containerPort Deklarative Portangabe am Container; erzwingt keinen Listener. targetPort Port, zu dem ein Service im ausgewählten Pod weiterleitet. port Port des Kubernetes-Service. nodePort Optionaler Port auf den Clusterknoten. Pod-Port Tatsächlicher Socket des Prozesses im Pod. Ingress-/Gateway-Port Extern bereitgestellter Listener eines Proxys oder Gateways. Beispiel: ports: - name: https port: 443 targetPort: 8443 Der Service nimmt Verkehr auf Port 443 an und leitet ihn zum Zielport 8443 weiter. Wenn targetPort nicht angegeben wird, entspricht er standardmäßig dem Wert von port . Ein eingetragener containerPort erzeugt keinen Socket und startet keinen Dienst. Kubernetes-Service und Endpunkte prüfen LESEND Services: kubectl get service \ --all-namespaces Bestimmten Service beschreiben: kubectl describe service \ \ -n Service als YAML anzeigen: kubectl get service \ \ -n \ -o yaml EndpointSlices anzeigen: kubectl get endpointslice \ -n \ -l kubernetes.io/service-name= \ -o wide Pods und Pod-Adressen: kubectl get pods \ -n \ -o wide Pod beschreiben: kubectl describe pod \ \ -n Listener im Pod, falls das Werkzeug vorhanden ist: kubectl exec \ -n \ \ -- ss -lntup Bei mehreren Containern im Pod: 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: externer Listener oder Load Balancer → NodePort beziehungsweise Service → EndpointSlice → Pod-IP und targetPort → Prozess im Pod Die alleinige Suche nach einem Hostprozess mit dem externen Port kann zu einer falschen Schlussfolgerung führen. IPv4 und IPv6 getrennt prüfen Zu prüfen sind: existiert ein IPv4-Listener? existiert ein IPv6-Listener? welche Adresse liefert DNS? welche Adresse wählt der Client zuerst? ist die Firewall für beide Protokollfamilien passend konfiguriert? existiert für beide Adressfamilien eine Route? liefert die Anwendung auf beiden Pfaden dieselbe Antwort? Windows: Get-NetTCPConnection ` -State Listen ` -LocalPort 443 | Select-Object LocalAddress, LocalPort, OwningProcess Linux: sudo ss -lntp 'sport = :443' Gezielter IPv4-Test: curl -4 -v https://app.example.test/ Gezielter IPv6-Test: curl -6 -v https://app.example.test/ Wenn IPv6 fehlschlägt und IPv4 funktioniert, darf der Fehler nicht durch dauerhaftes Abschalten von IPv6 verdeckt werden. Bindung, Routing, DNS und Firewall müssen getrennt untersucht werden. Temporäre und dynamische Clientports Beim Aufbau einer ausgehenden Verbindung verwendet der Client normalerweise einen lokalen Quellport aus einem dynamischen Bereich. Beispiel: Client: 192.0.2.100:53124 Server: 192.0.2.25:443 Der Serverdienst lauscht auf Port 443 . Der Clientport 53124 wurde für diese Verbindung lokal ausgewählt. Typische Diagnosefehler: den dynamischen Clientport mit dem Serverport verwechseln; eine eingehende Firewallregel für den Clientquellport erwarten; einen TIME-WAIT -Eintrag als Serverlistener interpretieren; nur nach dem Zielport suchen und die Verbindungsrichtung ignorieren. Die ausführliche Diagnose dynamischer Ports und Porterschöpfung erfolgt in der dafür vorgesehenen Folgeseite. Dienststatus und Socketstatus vergleichen Dienststatus Socketstatus Einordnung läuft Listener vorhanden Dienst hat mindestens einen erwarteten Socket angelegt läuft Listener fehlt Start teilweise fehlgeschlagen, falsche Konfiguration oder falscher Namespace beendet Listener vorhanden anderer Prozess, Kernelkomponente oder alte Instanz besitzt den Port startet wiederholt Listener erscheint kurz Absturz, Health-Check-Fehler oder Portkonflikt möglich läuft falsche Adresse Bindung oder Schnittstellenkonfiguration fehlerhaft läuft falscher Port Konfigurationsquelle oder Startparameter prüfen Ein grüner Dienststatus ist kein ausreichender Funktionsnachweis. Konfigurationsquelle des Listeners bestimmen Mögliche Quellen der Bindung: Anwendungskonfigurationsdatei; Kommandozeilenparameter; Umgebungsvariable; Windows-Registry; systemd-Unit; Socketaktivierung; Docker-Compose-Datei; Kubernetes-Manifest; Helm-Werte; Reverse-Proxy-Konfiguration; Orchestrator oder Service Discovery; durch Gruppenrichtlinie oder zentrale Verwaltung gelieferte Einstellung. Zu dokumentieren sind: wirksamer Port: 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 sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 100 Auf eine Gegenstelle begrenzen: sudo tcpdump \ -ni any \ 'host 198.51.100.40 and tcp port 443' \ -c 100 UDP-Beispiel: sudo tcpdump \ -ni any \ 'udp port 53' \ -c 100 macOS mit konkreter Schnittstelle: sudo tcpdump \ -ni en0 \ 'tcp port 443' \ -c 100 Lokalen macOS-Verkehr auf Loopback: sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 100 Aufzeichnungen müssen auf den benötigten Port, Host und Zeitraum begrenzt werden. Sie können sensible Adressen und Nutzdaten enthalten. TCP-Paketbefunde einordnen Beobachtung Mögliche Einordnung SYN verlässt Client, erreicht Server nicht Routing, Firewall, NAT oder falsche Zieladresse SYN erreicht Server, keine Antwort Filterung, Überlastung oder falscher Netzwerk-Namespace SYN erreicht Server, RST folgt häufig kein passender Listener oder aktive Ablehnung SYN, SYN/ACK, ACK sichtbar TCP-Verbindungsaufbau erfolgreich Aufbau erfolgreich, sofortiges FIN Anwendung beendet Verbindung kontrolliert Aufbau erfolgreich, sofortiges RST Anwendung, Proxy oder Protokollfehler möglich Server antwortet, Antwort erreicht Client nicht Rückweg, Firewall, asymmetrisches Routing wiederholte SYN-Pakete Client erhält keine verwertbare Antwort Die Paketaufzeichnung muss möglichst auf beiden Seiten oder an einem geeigneten Zwischenpunkt korreliert werden. Eine Aufzeichnung nur am Client zeigt nicht sicher, ob das Paket den Server erreicht hat. Systematischer Diagnoseablauf Exakte Fehlermeldung, Zeitpunkt und betroffene Anwendung dokumentieren. Erwartetes Transportprotokoll bestimmen. Erwarteten lokalen und entfernten Port bestimmen. Erwartete Bindungsadresse festlegen. Erforderliche Erreichbarkeit bestimmen: lokal, LAN, VPN oder öffentlich. Host, Container, Pod und Netzwerk-Namespace unterscheiden. Tatsächliche IP-Adressen des Systems erfassen. DNS-Auflösung des Zielnamens dokumentieren. TCP-Listener oder UDP-Endpunkt erfassen. IPv4- und IPv6-Bindung getrennt auswerten. Besitzenden Prozess bestimmen. Prozess einem Dienst, Container oder Pod zuordnen. Wirksame Konfigurationsquelle bestimmen. Dienstprotokolle zum Startzeitpunkt prüfen. Auf Portkonflikte oder Bindungsfehler prüfen. Loopback-Endpunkt testen. Konkrete lokale Schnittstellenadresse testen. Test von einem repräsentativen entfernten Client durchführen. Firewall, NAT und Portweiterleitung prüfen. Reverse Proxy, Load Balancer oder Kubernetes-Service berücksichtigen. Nach erfolgreichem Transport das Anwendungsprotokoll testen. Bei Bedarf eine begrenzte Netzwerkaufzeichnung durchführen. Hypothese, erwarteten Befund und Gegenbeweis formulieren. Genau eine kontrollierte Maßnahme durchführen. Identische Tests wiederholen. Anwendung und weitere repräsentative Clients verifizieren. Temporäre Diagnoseänderungen zurücknehmen. Ursache und Prävention dokumentieren. Hypothese und Gegenbeweis Beispiel: Hypothese: Der Webdienst ist ausschließlich an 127.0.0.1:8080 gebunden und deshalb von entfernten Clients nicht direkt erreichbar. Erwarteter Befund: Der lokale Test gegen 127.0.0.1:8080 funktioniert. Die Socketliste zeigt keinen Listener auf 192.0.2.25:8080 oder 0.0.0.0:8080. Der Test eines entfernten Clients schlägt fehl. Gegenbeweis: Die Socketliste zeigt einen Listener auf 0.0.0.0:8080 und eine Netzwerkaufzeichnung bestätigt, dass der Server eingehende SYN-Pakete mit SYN/ACK beantwortet. Testmethode: Socketliste, lokaler Test, entfernter Test und begrenzte Aufzeichnung. Risiko: Die lesenden Socketprüfungen sind risikoarm. Aktive Tests erzeugen Netzwerkverkehr, verändern aber nicht die Dienstkonfiguration. Eine Änderung darf erst erfolgen, wenn die vermutete Ursache einen messbaren Befund besitzt. Kontrollierte Maßnahmen Maßnahme Voraussetzung Risiko Bindungsadresse korrigieren falsche Adresse nachgewiesen Dienst kann auf weiteren Netzen erreichbar werden Port korrigieren Soll- und Ist-Port unterscheiden sich nachweislich Clients oder Überwachung verwenden eventuell alten Port kollidierenden Prozess beenden falscher Prozessbesitz eindeutig bestätigt Prozess oder abhängiger Dienst fällt aus Dienst geordnet neu starten Konfigurationsänderung erfordert Neustart bestehende Verbindungen werden unterbrochen Firewallregel anpassen Listener funktioniert lokal und Filterung ist bestätigt unbeabsichtigte Freigabe Docker-Portzuordnung korrigieren falscher Host- oder Containerport bestätigt Container muss eventuell neu erstellt werden Kubernetes- targetPort korrigieren Service und Pod-Listener stimmen nicht überein laufender Dienstverkehr wird umgeleitet Reverse-Proxy-Ziel korrigieren falscher Backendendpunkt nachgewiesen alle über den Proxy laufenden Anfragen betroffen IPv4-/IPv6-Bindung korrigieren Protokollfamilienfehler bestätigt zusätzliche Angriffsfläche oder geänderte Erreichbarkeit Socketdateiberechtigung korrigieren Unix-Socket und Zugriffsfehler bestätigt weitere lokale Prozesse können Zugriff erhalten Vor der Maßnahme sind zu dokumentieren: Ausgangszustand; betroffener Endpunkt; Prozess und Dienst; Konfigurationsquelle; erwartete Wirkung; Sicherheitsauswirkung; Wartungsfenster; Rückweg; Erfolgskriterium. Befundmatrix Befund Mögliche Einordnung Nächster Nachweis Dienst läuft, Port fehlt Bindung fehlgeschlagen oder falsche Konfiguration Startprotokoll und wirksame Konfiguration Port vorhanden, falscher Prozess Portkonflikt oder unerwarteter Dienst Prozesspfad und Dienstzuordnung Listener nur auf 127.0.0.1 nur lokale Erreichbarkeit vorgesehen oder Fehlkonfiguration Sollbindung und Proxyaufbau prüfen Listener auf 0.0.0.0 alle geeigneten IPv4-Adressen Firewall und tatsächliche Erreichbarkeit prüfen Listener nur auf [::] IPv6-Wildcard IPv4 und IPv6 ausdrücklich getrennt testen lokaler Test funktioniert, remote nicht Firewall, Routing, NAT oder Bindungsumfang entfernte Aufzeichnung und Firewallzustand TCP-Verbindung funktioniert, Anwendung nicht Anwendungs- oder Protokollfehler HTTP-, TLS- oder Diensttest Connection refused häufig kein passender Listener Server-Socketliste und Paketaufzeichnung Timeout keine verwertbare Antwort Routing, Filterung und Aufzeichnung UDP-Endpunkt sichtbar, keine Antwort Anwendung, Firewall oder Rückweg protokollspezifischer Test und Aufzeichnung Port erscheint kurz und verschwindet Prozess beendet sich oder startet neu Prozess- und Dienstprotokolle Bindung meldet Address already in use Endpunkt bereits belegt Besitzer des vorhandenen Sockets bestimmen Bindung meldet Address not available konfigurierte lokale IP fehlt Schnittstellen und Startreihenfolge Docker-Port veröffentlicht, Anwendung nicht erreichbar falscher Containerport oder Loopback-Bindung im Container Listener innerhalb des Containers Kubernetes-Service ohne Endpunkte Selektor oder Readiness fehlerhaft Pods und EndpointSlices Service-Port stimmt, targetPort falsch Weiterleitung auf falschen Pod-Port Service-YAML und Pod-Listener Host zeigt keinen Listener, NodePort funktioniert regelbasierte Weiterleitung Kubernetes- und Host-Netzwerkregeln nur localhost schlägt fehl IPv4-/IPv6-Auswahl oder Hosts-Auflösung 127.0.0.1 und ::1 einzeln testen nur einige Clients scheitern Netzpfad, Adressfamilie oder Richtlinie erfolgreiche und fehlerhafte Pfade vergleichen Typische Diagnosefehler TCP und UDP nicht unterscheiden. Einen UDP-Endpunkt als TCP-Listener interpretieren. Nur nach der Portnummer suchen und das Protokoll ignorieren. 0.0.0.0 als verwendbare Zieladresse eines Clients behandeln. Loopback-Bindung und Wildcard-Bindung gleichsetzen. Einen Listener als vollständigen Funktionsnachweis bewerten. Nur den Dienststatus prüfen. Den besitzenden Prozess nicht bestimmen. Prozess-ID aus einer alten Aufnahme verwenden. IPv4 und IPv6 nicht getrennt prüfen. localhost als eindeutigen IPv4-Test behandeln. Wildcard-Bindung automatisch als öffentliche Erreichbarkeit interpretieren. Öffentliche Erreichbarkeit allein durch lokale Socketlisten bewerten. Test-NetConnection -Port als UDP-Test verwenden. Einen offenen TCP-Port mit funktionierendem TLS oder HTTP gleichsetzen. Host- und Containerport verwechseln. Container-IP und Host-IP verwechseln. Den falschen Netzwerk-Namespace untersuchen. EXPOSE mit einer Docker-Portveröffentlichung gleichsetzen. Kubernetes- containerPort als echten Listener interpretieren. port , targetPort und nodePort verwechseln. Bei NodePort nur nach einem Benutzerprozess-Listener suchen. Einen Reverse Proxy und sein Backend als einen einzigen Endpunkt behandeln. Einen Portkonflikt durch wiederholte Neustarts verdecken. Einen Prozess beenden, bevor seine Funktion und Abhängigkeiten geklärt sind. Die Firewall vollständig deaktivieren. Breite Portscans ohne technische Notwendigkeit durchführen. Netzwerkaufzeichnungen unbegrenzt laufen lassen. Sensible Socket- oder Paketdaten ungeschützt speichern. Mehrere Konfigurationsvariablen gleichzeitig verändern. Nach der Maßnahme nur lokal testen. Temporäre Regeln und Diagnosewerkzeuge aktiv lassen. Verifikation Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: der erwartete Prozess läuft; der Prozess besitzt den vorgesehenen Socket; das richtige Transportprotokoll wird verwendet; der richtige lokale Port ist gebunden; die richtige lokale Adresse ist gebunden; die Bindung existiert im richtigen Netzwerk-Namespace; keine unerwartete zusätzliche Bindung besteht; IPv4 funktioniert, sofern vorgesehen; IPv6 funktioniert, sofern vorgesehen; Loopback-Verhalten entspricht der Planung; konkrete Schnittstellenadressen funktionieren; lokale Firewallregeln entsprechen dem Sollzustand; NAT oder Portweiterleitung verwendet den richtigen Zielport; Docker-Host- und Containerport stimmen überein; Kubernetes- port und targetPort stimmen mit dem Pod-Listener überein; EndpointSlices enthalten die vorgesehenen Backends; Reverse Proxy oder Load Balancer erreicht das Backend; ein repräsentativer entfernter Client kann den Endpunkt erreichen; das Anwendungsprotokoll liefert die erwartete Antwort; keine neuen Bindungs-, Prozess- oder Dienstfehler entstehen; temporäre Diagnoseänderungen wurden zurückgenommen; Sicherheitsauswirkungen der Bindung wurden geprüft; Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche lokale TCP-Verbindung ist keine ausreichende Gesamtverifikation. Dokumentationsvorlage Störung: 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 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 Microsoft Learn – Get-NetUDPEndpoint Microsoft Learn – Test-NetConnection Microsoft Learn – netstat Microsoft Learn – Get-NetIPAddress Microsoft Learn – Get-NetFirewallRule Microsoft Learn – netsh http Microsoft Learn – netsh interface portproxy Offizielle Linux- und Unix-Dokumentation Linux man-pages – ss(8) Linux man-pages – lsof(8) Linux man-pages – tcpdump(8) Linux man-pages – ip-netns(8) Linux man-pages – socket(7) Linux man-pages – tcp(7) Linux man-pages – udp(7) Offizielle Docker-Dokumentation Docker Docs – Port publishing and mapping Docker Docs – Networking overview Docker Docs – docker container port Docker Docs – Bridge network driver Docker Docs – Host network driver Offizielle Kubernetes-Dokumentation Kubernetes – Services, Load Balancing, and Networking Kubernetes – EndpointSlices Kubernetes API – Service Kubernetes – Network Policies Standards und Register IANA – Service Name and Transport Protocol Port Number Registry RFC 6335 – Service Name and Transport Protocol Port Number Registry RFC 9293 – Transmission Control Protocol RFC 768 – User Datagram Protocol RFC 3493 – Basic Socket Interface Extensions for IPv6 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: 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: Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port Beispiel: Client: 192.0.2.100:53124 Server: 192.0.2.25:443 Die Verbindung kann kompakt dargestellt werden als: 192.0.2.100:53124 → 192.0.2.25:443 Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar: 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. 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: Der Client sendet ein Segment mit SYN . Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit SYN, ACK . 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: 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: 1000 + 1 = 1001 Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt: 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: 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: 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: 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: 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: 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: 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: Client sendet: Seq = 1001 TCP-Nutzdatenlänge = 500 Bytes Der Server bestätigt als nächste erwartete Sequenznummer: Ack = 1501 Berechnung: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Aufzeichnung am Client. Aufzeichnung am Server. Zeitliche Synchronisation beider Systeme. Vergleich derselben TCP-Verbindung. Prüfung, ob der Reset den Server verlässt. Prüfung, ob der Server den Reset überhaupt empfängt. Protokolle von Firewall, Proxy und Load Balancer korrelieren. Beispiel: 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: 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: Teilnehmer A sendet: FIN, Seq = 5000 Teilnehmer B bestätigt: ACK = 5001 Das FIN signalisiert: 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: 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: 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: 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: Get-NetTCPConnection | Sort-Object State, LocalPort Verbindungen im Zustand SYN-SENT : Get-NetTCPConnection ` -State SynSent Verbindungen im Zustand SYN-RECEIVED : Get-NetTCPConnection ` -State SynReceived Aufgebaute Verbindungen: Get-NetTCPConnection ` -State Established CLOSE-WAIT : Get-NetTCPConnection ` -State CloseWait TIME-WAIT : Get-NetTCPConnection ` -State TimeWait Bestimmten entfernten Port prüfen: Get-NetTCPConnection ` -RemotePort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess Serververbindungen eines lokalen Ports: 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 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 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: Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 ` -InformationLevel Detailed Windows: TCP-Statistiken prüfen LESEND netstat -s -p tcp IPv6-TCP-Statistiken: netstat -s -p tcpv6 Verfügbare Leistungsindikatoren suchen: 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: pktmon stop Vorhandene Filter entfernen: pktmon filter remove Filter für TCP-Port 443 anlegen: pktmon filter add TCP443 -t TCP -p 443 Aufzeichnung starten: pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl Nach reproduziertem Fehler stoppen: pktmon stop In PCAPNG konvertieren: pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng Temporären Filter entfernen: 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: ss -tan TCP-Sockets mit Prozessinformationen: sudo ss -tanp SYN-SENT : ss -tan state syn-sent SYN-RECEIVED : ss -tan state syn-recv Aufgebaute Verbindungen: ss -tan state established CLOSE-WAIT : ss -tan state close-wait TIME-WAIT : ss -tan state time-wait Erweiterte TCP-Informationen für Zielport 443 : sudo ss -tin \ 'dport = :443' Erweiterte Informationen für einen lokalen Serverport: 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 nstat -az Bestimmte Zähler: nstat -az TcpRetransSegs nstat -az TcpAttemptFails nstat -az TcpEstabResets Zusätzliche klassische Statistik: 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 netstat -anv -p tcp TCP-Verbindungen mit Prozesszuordnung: sudo lsof -nP -iTCP Aufgebaute TCP-Verbindungen: sudo lsof \ -nP \ -iTCP \ -sTCP:ESTABLISHED Interaktive TCP-Ansicht: nettop -m tcp TCP-Statistiken: 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 nc -vz app.example.test 443 Linux mit begrenzter Wartezeit, abhängig von der installierten nc -Variante: nc -vz -w 5 app.example.test 443 macOS mit TCP-Verbindungsfrist: nc -vz -G 5 app.example.test 443 HTTP- oder HTTPS-Test mit getrennten Fristen: 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: sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 Auf einen Host und Port begrenzen: sudo tcpdump \ -ni any \ 'host 192.0.2.25 and tcp port 443' \ -c 200 Mit ausführlicheren TCP-Informationen in Datei schreiben: 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: tcpdump -D Auf einer konkreten Schnittstelle: sudo tcpdump \ -ni en0 \ 'host 192.0.2.25 and tcp port 443' \ -c 200 Lokale Loopback-Verbindung: sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 200 In Datei schreiben: 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: tcp.port == 443 Bestimmte IP-Adresse und Port: ip.addr == 192.0.2.25 && tcp.port == 443 Nur initiale SYN-Segmente: tcp.flags.syn == 1 && tcp.flags.ack == 0 SYN/ACK: tcp.flags.syn == 1 && tcp.flags.ack == 1 Reset: tcp.flags.reset == 1 FIN: tcp.flags.fin == 1 Vermutete Wiederholungen: tcp.analysis.retransmission Vermuteter Fast Retransmit: tcp.analysis.fast_retransmission Duplicate ACKs: tcp.analysis.duplicate_ack Zero Window: tcp.analysis.zero_window Ein bestimmter TCP-Datenstrom: 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: 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: 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: 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: Client → Hostport → Container-Netzwerk → Containersocket oder: 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: 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: 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 Exakte Anwendungsmeldung aufnehmen. Datum, Uhrzeit und Zeitzone dokumentieren. Client, Server, Zielname und Zielport bestimmen. Verwendete IP-Adresse und Adressfamilie erfassen. Transportprotokoll bestätigen. Erwarteten Listener auf dem Server prüfen. Besitzenden Prozess bestimmen. Lokalen TCP-Test am Server durchführen. TCP-Test vom betroffenen Client durchführen. Socketzustand während des Versuchs beobachten. Prüfen, ob ein SYN erzeugt wird. Prüfen, ob der Server das SYN empfängt. Prüfen, ob SYN/ACK oder RST zurückgesendet wird. Prüfen, ob das abschließende ACK ankommt. Bei erfolgreichem Handshake Anwendungsdaten prüfen. Connect- und Anwendungs-Timeout unterscheiden. FIN und RST unterscheiden. Reset-Richtung und Reset-Zeitpunkt bestimmen. Client-, Server- und Zwischenprotokolle korrelieren. Retransmissions und Duplicate ACKs auswerten. Captureverlust und Offloading berücksichtigen. NAT-, Firewall- und Proxyzustand prüfen. Load Balancer und Backendverbindung getrennt prüfen. Container- und Netzwerk-Namespace berücksichtigen. Idle-Phase und Timeoutwerte dokumentieren. Frische und wiederverwendete Verbindung vergleichen. Hypothese und Gegenbeweis formulieren. Genau eine kontrollierte Maßnahme durchführen. Identischen Verbindungsversuch wiederholen. Anwendungsprotokoll vollständig verifizieren. Weitere repräsentative Clients prüfen. Temporäre Filter und Aufzeichnungen entfernen. 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 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 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 RFC 1122 – Requirements for Internet Hosts – Communication Layers RFC 5681 – TCP Congestion Control RFC 6298 – Computing TCP's Retransmission Timer RFC 7323 – TCP Extensions for High Performance RFC 2018 – TCP Selective Acknowledgment Options RFC 2883 – An Extension to the Selective Acknowledgement Option RFC 5961 – Improving TCP's Robustness to Blind In-Window Attacks Offizielle Microsoft-Dokumentation Microsoft Learn – Get-NetTCPConnection Microsoft Learn – Test-NetConnection Microsoft Learn – netstat Microsoft Learn – Packet Monitor Microsoft Learn – pktmon filter add Microsoft Learn – Troubleshoot TCP/IP connectivity Microsoft Learn – Guidance for troubleshooting TCP/IP communication Offizielle Linux-Dokumentation Linux man-pages – ss(8) Linux man-pages – tcp(7) Linux man-pages – tcpdump(8) Linux Kernel Documentation – SNMP counters Offizielle Wireshark-Dokumentation Wireshark User’s Guide – TCP Analysis Wireshark Display Filter Reference – TCP Wireshark User’s Guide 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: 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: Quell-IP-Adresse Quellport Ziel-IP-Adresse Zielport Transportprotokoll UDP Beispiel: Client: 192.0.2.100:53124 Server: 192.0.2.53:53 Anfrage: 192.0.2.100:53124 → 192.0.2.53:53 UDP Antwort: 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: 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: 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: 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 Resolve-DnsName ` -Name "example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly Linux und macOS: dig \ @192.0.2.53 \ example.test \ A Vergleich über TCP: 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: 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: Get-NetUDPEndpoint | Sort-Object LocalPort, LocalAddress Bestimmten UDP-Port prüfen: Get-NetUDPEndpoint ` -LocalPort 53 Wesentliche Felder anzeigen: 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 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: Get-Process ` -Id 1234 Einem Windows-Dienst zuordnen: $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 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: netstat -s -p udp IPv6: netstat -s -p udpv6 Verfügbare Leistungsindikatoren: 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: 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: 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 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: sudo ss -lunp Alle UDP-Sockets: sudo ss -uanp Bestimmten lokalen Port prüfen: sudo ss -lunp \ 'sport = :53' Ausgabe ohne Prozessinformationen: 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: sudo lsof \ -nP \ -iUDP Bestimmten UDP-Port prüfen: sudo lsof \ -nP \ -iUDP:53 Prozess prüfen: ps -fp Bei systemd: 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: nstat -az Ausgewählte UDP-Zähler: nstat -az UdpInDatagrams nstat -az UdpNoPorts nstat -az UdpInErrors nstat -az UdpRcvbufErrors nstat -az UdpSndbufErrors Klassische Übersicht: netstat -su Schnittstellenzähler: 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 sudo lsof \ -nP \ -iUDP Bestimmten UDP-Port prüfen: sudo lsof \ -nP \ -iUDP:53 Socketübersicht: netstat -anv -p udp UDP-Statistiken: netstat -s -p udp Netzwerkschnittstellen: ifconfig Interaktive Netzwerkansicht: 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: 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: 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: 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: 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: ICMPv6 Type 1, Code 4 ICMPv6 Packet Too Big ICMPv6 verwendet: 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: 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: 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: 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: 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: 53:53/udp Ohne /udp wird eine Veröffentlichung typischerweise als TCP-Veröffentlichung behandelt. Laufende Container und Ports: LESEND docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' Portzuordnung: docker port Ausführliche Konfiguration: docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' UDP-Endpunkt im Container: docker exec \ \ ss -lunp Compose-Beispiel: 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: ports: - name: dns-udp protocol: UDP port: 53 targetPort: 53 Service anzeigen: kubectl get service \ \ -n \ -o yaml Service beschreiben: kubectl describe service \ \ -n EndpointSlices: kubectl get endpointslice \ -n \ -l kubernetes.io/service-name= \ -o wide UDP-Endpunkt im Pod: kubectl exec \ -n \ \ -- ss -lunp Bei mehreren Containern: 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: pktmon stop Vorhandene Filter entfernen: pktmon filter remove UDP-Port 53 erfassen: pktmon filter add UDP53 -t UDP -p 53 ICMPv4 ergänzen: pktmon filter add ICMPv4 -t ICMP ICMPv6 ergänzen: pktmon filter add ICMPv6 -t ICMPV6 Aufzeichnung starten: pktmon start --capture --pkt-size 0 --file-name C:\Temp\udp53.etl Nach reproduziertem Fehler stoppen: pktmon stop In PCAPNG konvertieren: pktmon etl2pcap C:\Temp\udp53.etl --out C:\Temp\udp53.pcapng Filter zurücknehmen: 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 sudo tcpdump \ -ni any \ '(udp port 53) or icmp or icmp6' \ -c 200 Auf bestimmte Gegenstelle begrenzen: sudo tcpdump \ -ni any \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \ -c 200 In Datei schreiben: 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: tcpdump -D Auf konkreter Schnittstelle: sudo tcpdump \ -ni en0 \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \ -c 200 In Datei schreiben: 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: udp Bestimmter UDP-Port: udp.port == 53 Bestimmte Adresse und Port: ip.addr == 192.0.2.53 && udp.port == 53 ICMPv4: icmp ICMPv6: icmpv6 ICMPv4 Destination Unreachable: icmp.type == 3 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 UDP und beide ICMP-Versionen: 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 Client → Server UDP-Anfrage Server → Client UDP-Antwort Geschlossener UDP-Port Client → Server UDP-Anfrage Server → Client ICMP Port Unreachable Stilles Verwerfen Client → Server UDP-Anfrage keine Antwort keine ICMP-Meldung Server verarbeitet Anfrage nicht Client → Server UDP-Anfrage Anfrage erreicht Serverschnittstelle keine Anwendungsantwort Rückwegfehler Client → Server UDP-Anfrage Server → Client UDP-Antwort Antwort erreicht Client nicht Path-MTU-Problem 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 traceroute \ -U \ -p 33434 \ 192.0.2.53 IPv6: 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: 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: 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 Exakte Fehlermeldung und Zeitpunkt aufnehmen. Anwendung und Protokoll bestimmen. Bestätigen, dass tatsächlich UDP verwendet wird. Quell- und Zieladresse dokumentieren. Quell- und Zielport dokumentieren. IPv4 und IPv6 unterscheiden. Unicast, Broadcast oder Multicast bestimmen. Erwartete Anfrage und Antwort beschreiben. Lokalen UDP-Endpunkt auf dem Server prüfen. Besitzenden Prozess bestimmen. Richtige Bindungsadresse prüfen. Host-, Container- und Pod-Namespace unterscheiden. Anwendungsprotokolle auf dem Server prüfen. Protokollspezifischen Test vom Client durchführen. UDP-Anfrage auf dem Client erfassen. Prüfen, ob die Anfrage den Server erreicht. Prüfen, ob die Anwendung die Anfrage verarbeitet. Prüfen, ob eine Antwort erzeugt wird. Prüfen, ob die Antwort den Client erreicht. Quelladresse und Quellport der Antwort prüfen. ICMPv4- und ICMPv6-Meldungen auswerten. ICMP-Erzeuger und eingebettetes Originalpaket prüfen. Stateful Firewall und UDP-Zustand prüfen. NAT-Übersetzung und Rückweg prüfen. Idle-Timeouts berücksichtigen. UDP- und Schnittstellenzähler vergleichen. Empfangspuffer und Anwendungsleistung prüfen. Kleine und große gültige Datagramme vergleichen. MTU, Fragmentierung und Tunnel berücksichtigen. Bei Multicast Gruppenmitgliedschaft und Switch prüfen. Hypothese und Gegenbeweis formulieren. Genau eine kontrollierte Maßnahme durchführen. Identischen Test wiederholen. Anwendung und mehrere Versuche verifizieren. Temporäre Aufzeichnung und Filter zurücknehmen. 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 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 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 RFC 8085 – UDP Usage Guidelines RFC 1122 – Requirements for Internet Hosts – Communication Layers RFC 792 – Internet Control Message Protocol RFC 1812 – Requirements for IP Version 4 Routers RFC 4443 – ICMPv6 for IPv6 RFC 8200 – Internet Protocol, Version 6 Specification RFC 1191 – Path MTU Discovery RFC 8201 – Path MTU Discovery for IPv6 RFC 4821 – Packetization Layer Path MTU Discovery RFC 8899 – Datagram PLPMTUD RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls RFC 6633 – Deprecation of ICMP Source Quench Messages Offizielle Microsoft-Dokumentation Microsoft Learn – Get-NetUDPEndpoint Microsoft Learn – netstat Microsoft Learn – PortQry command-line tool Microsoft Learn – Packet Monitor Microsoft Learn – Pktmon command formatting Microsoft Learn – Resolve-DnsName Offizielle Linux- und Projektdokumentation Linux man-pages – ss(8) Linux man-pages – udp(7) Linux man-pages – icmp(7) Linux man-pages – ipv6(7) Linux man-pages – tcpdump(8) Linux man-pages – traceroute(8) ISC BIND 9 – Manual Pages und dig Offizielle Wireshark-Dokumentation Wireshark Display Filter Reference – UDP Wireshark Display Filter Reference – ICMP Wireshark Display Filter Reference – ICMPv6 Wireshark User’s Guide Offizielle Containerdokumentation Docker Docs – Port publishing and mapping Docker Docs – Networking overview Kubernetes – Service Kubernetes – EndpointSlices Kubernetes – 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: Client → Netzwerkfirewall → Servernetzwerkschnittstelle → lokale Host-Firewall → lokaler Socket → Anwendung Ausgehender Datenverkehr: Anwendung → lokaler Socket → lokale Host-Firewall → Servernetzwerkschnittstelle → Netzwerkfirewall → Ziel Container- oder VM-Verkehr kann zusätzlich einen Weiterleitungspfad verwenden: 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. 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: 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: 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: 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 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 Get-NetFirewallProfile | Select-Object ` Name, Enabled, DefaultInboundAction, DefaultOutboundAction, AllowInboundRules, AllowLocalFirewallRules, AllowLocalIPsecRules, NotifyOnListen, LogFileName, LogMaxSizeKilobytes, LogAllowed, LogBlocked Wirksame Profile aus dem aktiven Richtlinienspeicher: 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: Get-NetFirewallRule ` -PolicyStore ActiveStore Aktivierte Regeln: Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True Aktivierte eingehende Allow-Regeln: Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Inbound ` -Action Allow Aktivierte eingehende Blockregeln: Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Inbound ` -Action Block Aktivierte ausgehende Blockregeln: Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Outbound ` -Action Block Herkunft der Regeln: 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 Show-NetFirewallRule ` -PolicyStore ActiveStore Für eine bekannte Regel: 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: Get-NetFirewallPortFilter ` -PolicyStore ActiveStore Regeln für lokalen Port 443 suchen: 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 : 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: 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 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: RemoteAddress = 192.0.2.0/24 gilt nicht für einen Client aus: 198.51.100.0/24 Windows: Programmfilter prüfen LESEND 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 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 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: 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: gpresult /scope computer /r Wirksame Firewallregeln enthalten zusätzlich: 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: %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log Letzte Einträge: LESEND · SENSITIV Get-Content ` "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" ` -Tail 100 Nach Adresse oder Port suchen: 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: Get-NetFirewallProfile | Select-Object ` Name, LogFileName, LogMaxSizeKilobytes, LogAllowed, LogBlocked Blockprotokollierung für ein bestimmtes Profil aktivieren: ÄNDERND · SENSITIV 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 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: netsh advfirewall show allprofiles Regeln: netsh advfirewall firewall show rule name=all verbose Überwachungszustand: netsh advfirewall monitor show firewall Der ältere Kontext: 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: 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 nft --version iptables --version Eine iptables-Ausgabe kann auf ein Backend hinweisen: iptables vX.Y.Z (nf_tables) oder: iptables vX.Y.Z (legacy) Aktive Manager: systemctl is-active firewalld 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 sudo nft list ruleset Mit Regel-Handles: 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: 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: counter packets 42 bytes 3360 drop Für einen kontrollierten Test: aktuellen Zählerstand dokumentieren; genau einen Test ausführen; Regelsatz erneut lesen; Zählerdifferenz prüfen; 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: sudo iptables \ -L \ -n \ -v \ --line-numbers IPv6: sudo ip6tables \ -L \ -n \ -v \ --line-numbers Vollständiger IPv4-Regelsatz mit Countern: sudo iptables-save \ -c Vollständiger IPv6-Regelsatz: 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: 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: PREROUTING → FORWARD → POSTROUTING Eine Allow-Regel in INPUT hilft in diesem Fall nicht zwingend. Linux: firewalld-Zustand prüfen LESEND Dienstzustand: firewall-cmd --state Aktive Zonen und Zuordnungen: firewall-cmd --get-active-zones Standardzone: firewall-cmd --get-default-zone Alle Zonen: firewall-cmd --list-all-zones Bestimmte aktive Zone: firewall-cmd \ --zone= \ --list-all Rich Rules: firewall-cmd \ --zone= \ --list-rich-rules Richtlinienobjekte: firewall-cmd --get-policies 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: firewall-cmd \ --zone= \ --list-all Permanente Konfiguration: 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: firewall-cmd \ --zone= \ --query-port=443/tcp Service: firewall-cmd \ --zone= \ --query-service=https Permanent: 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: sudo ufw status verbose Nummerierte Regeln: sudo ufw status numbered Von UFW verwaltete hinzugefügte Regeln: sudo ufw show added Vollständigere Netfilter-Sicht: 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 journalctl \ -k \ --since "15 minutes ago" firewalld-Dienstmeldungen: journalctl \ -u firewalld \ --since "15 minutes ago" UFW-Dienstmeldungen: 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: ip \ -details \ link show \ dev tc -Ingressfilter: sudo tc \ filter show \ dev \ ingress tc -Egressfilter: sudo tc \ filter show \ dev \ egress Falls bpftool vorhanden ist: 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: 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: sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getglobalstate Block-All-Zustand: sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getblockall Tarnmodus: sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getstealthmode Anwendungsliste: sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --listapps Lokale Hilfe und verfügbare Optionen: /usr/libexec/ApplicationFirewall/socketfilterfw \ --help Zusammenfassung über System Profiler: 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: sudo pfctl -s info Filterregeln: sudo pfctl -sr NAT-Regeln: sudo pfctl -sn Zustandstabelle: sudo pfctl -ss Gesamtübersicht: 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 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: docker info docker network ls docker ps \ --format 'table {{.Names}}\t{{.Ports}}' 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: kubectl get networkpolicy \ --all-namespaces kubectl get service \ --all-namespaces kubectl get pods \ --all-namespaces \ -o wide 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: Testzeitpunkt genau dokumentieren. Paketaufzeichnung auf dem Host starten. Firewallcounter oder Protokoll erfassen. Genau einen Test ausführen. Listener und Prozesszustand erfassen. Firewallprotokoll mit dem Flow abgleichen. Paketaufzeichnung und Regelcounter vergleichen. 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 pktmon stop pktmon filter remove Filter für TCP-Port 443 : pktmon filter add TCP443 -t TCP -p 443 Aufzeichnung starten: pktmon start --capture --pkt-size 0 --file-name C:\Temp\firewall443.etl Nach reproduziertem Fehler stoppen: pktmon stop Konvertieren: pktmon etl2pcap C:\Temp\firewall443.etl --out C:\Temp\firewall443.pcapng Filter entfernen: 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 : sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 UDP-Port 53 und ICMP: sudo tcpdump \ -ni any \ '(udp port 53) or icmp or icmp6' \ -c 200 Bestimmte Schnittstelle und Gegenstelle: 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: tcpdump -D Bestimmte Schnittstelle: sudo tcpdump \ -ni en0 \ 'host 192.0.2.100 and tcp port 443' \ -c 200 Loopback: 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 Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 443 Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 Von einem entfernten Client: Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed Linux und macOS: nc -vz 127.0.0.1 443 nc -vz 192.0.2.25 443 Von einem entfernten Client: 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: 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: 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 Exakte Fehlermeldung aufnehmen. Zeitpunkt und Zeitzone dokumentieren. Client, Server und Anwendung bestimmen. TCP, UDP, ICMPv4 oder ICMPv6 bestimmen. Quell- und Zieladressen dokumentieren. Quell- und Zielports dokumentieren. Listener und Bindungsadresse prüfen. Besitzenden Prozess bestimmen. lokalen Loopbacktest durchführen. konkrete lokale Schnittstellenadresse testen. Test von einem repräsentativen entfernten Client durchführen. Paketfluss eingehend, ausgehend oder weitergeleitet bestimmen. aktive Firewalltechnik bestimmen. aktives Profil, aktive Zone oder Schnittstelle bestimmen. Standardaktionen prüfen. wirksame Regeln erfassen. Allow- und Blockregeln prüfen. Protokoll- und Portfilter vergleichen. Adressbereiche vergleichen. Programm- und Dienstfilter vergleichen. Schnittstellenfilter vergleichen. Richtlinienquelle bestimmen. zentrale Richtlinien und lokale Zusammenführung prüfen. Firewallcounter und vorhandene Protokolle auswerten. bei Bedarf zeitlich begrenzte Protokollierung aktivieren. Paketaufzeichnung am Host durchführen. Paketaufzeichnung mit einem zweiten Punkt vergleichen. Container-, VM- und Namespacepfade berücksichtigen. Endpoint Security, VPN und zusätzliche Filter berücksichtigen. Hypothese und Gegenbeweis formulieren. Genau eine kontrollierte Änderung durchführen. identischen Test wiederholen. Anwendung statt nur Porttest verifizieren. weitere repräsentative Clients prüfen. temporäre Protokollierung und Filter zurücknehmen. 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 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 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 Microsoft Learn – Windows Firewall rules Microsoft Learn – Manage Windows Firewall with the command line Microsoft Learn – Configure Windows Firewall logging Microsoft Learn – Get-NetFirewallProfile Microsoft Learn – Get-NetFirewallRule Microsoft Learn – Show-NetFirewallRule Microsoft Learn – Get-NetFirewallPortFilter Microsoft Learn – Get-NetFirewallAddressFilter Microsoft Learn – Get-NetFirewallApplicationFilter Microsoft Learn – Get-NetFirewallServiceFilter Microsoft Learn – WFP auditing and logging Microsoft Learn – Event 5152 Microsoft Learn – Event 5157 Microsoft Learn – Packet Monitor Microsoft Learn – netsh advfirewall Offizielle Netfilter- und Linux-Dokumentation nftables Documentation nftables – Counters Linux man-pages – nft(8) Linux man-pages – iptables(8) Linux man-pages – iptables-save(8) Linux man-pages – tcpdump(8) Offizielle firewalld- und Ubuntu-Dokumentation firewalld – Documentation firewalld – firewall-cmd firewalld – Runtime and permanent configuration firewalld – Zone configuration firewalld – Policy Objects Ubuntu Manpage – ufw(8) Offizielle Apple-Dokumentation Apple – Change Firewall settings on Mac Apple – Block connections to your Mac with a firewall Apple Platform Security – Firewall security in macOS Apple Deployment – Firewall payload settings Apple – TCP and UDP ports used by Apple software products Apple Developer – Packet Filter is not API Offizielle Containerdokumentation Docker Docs – Packet filtering and firewalls Docker Docs – Docker with iptables Docker Docs – Docker with nftables Docker Docs – Port publishing and mapping Kubernetes – Network Policies Kubernetes – Services 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: Paket trifft auf einer Eingangsschnittstelle ein. Eingangszone oder Sicherheitskontext wird bestimmt. Vorhandene Sitzung wird gesucht. NAT- und Routingregeln werden ausgewertet. Ausgangsschnittstelle und Ausgangszone werden bestimmt. Sicherheitsregel wird ermittelt. Zusätzliche Prüfungen werden ausgeführt. Paket wird weitergeleitet oder verworfen. Eine neue Sitzung wird angelegt oder eine vorhandene aktualisiert. Rückverkehr wird einer Sitzung zugeordnet. 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: 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: 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: 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: 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: 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: Regeln werden von oben nach unten oder nach Priorität geprüft. Die erste vollständig passende Regel bestimmt die Aktion. Nach einem Treffer werden nachfolgende Regeln nicht mehr geprüft. 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: 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: 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: permit deny deny any any Ein explizites abschließendes Verbot mit Protokollierung kann die Diagnose erleichtern: 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: 192.0.2.0/24 umfasst: 192.0.2.0 bis 192.0.2.255 Dagegen umfasst: 192.0.2.100/32 nur die einzelne Adresse: 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: Client sendet SYN . Firewall findet keine vorhandene Sitzung. Firewall prüft Route, Zone, NAT und Richtlinie. Bei Erlaubnis wird ein Sitzungseintrag angelegt. Server sendet SYN, ACK . Firewall ordnet das Paket der bestehenden Sitzung zu. Client sendet ACK . Sitzung wechselt in den etablierten Zustand. Weitere Pakete werden anhand der Sitzung verarbeitet. 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: 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: 192.0.2.100:54000 -> 198.51.100.53:53/UDP Die Firewall kann anschließend eine passende Antwort erlauben: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: kleinere Prioritätszahl = höhere Priorität Beispiel: 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: 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: 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: aktuellen Zählerstand mit Uhrzeit dokumentieren; genau einen kontrollierten Test ausführen; Zähler erneut ablesen; Differenz bewerten; 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: 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: 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: show ip access-lists show ip access-lists show running-config | section access-list show running-config | include ip access-group 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: show access-list show access-group Verbindungen und NAT: show conn show conn address 192.0.2.100 show xlate Routing: show route Simulation eines TCP-Pakets: packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed Drop-Zähler: 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: show security policies show security policies hit-count show security flow session show security flow session source-prefix 192.0.2.100 show security flow session destination-prefix 198.51.100.25 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: show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443 Routingprüfung: 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: test security-policy-match ? 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: sudo nft list ruleset Regelwerk mit Handles: sudo nft -a list ruleset Routing: ip route show ip -6 route show Weiterleitungseinstellung: sysctl net.ipv4.ip_forward sysctl net.ipv6.conf.all.forwarding Connection Tracking, sofern das Werkzeug vorhanden ist: sudo conntrack -L Gezielte Suche: 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: 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: 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 Exakte Fehlermeldung, Anwendung, Client, Benutzer und Uhrzeit dokumentieren. Quelladresse und tatsächlichen Quellport bestimmen. Zieladresse, Zielport und Protokoll bestimmen. IPv4 und IPv6 unterscheiden. Erwarteten Datenfluss und Sollzustand dokumentieren. Umfang der Störung bestimmen. Host-Firewalls als eigene Filterebenen berücksichtigen. Direkte Erreichbarkeit und Dienstzustand prüfen. Erwarteten Netzwerkpfad dokumentieren. Tatsächlichen Firewallpfad nachweisen. Aktiven Firewall- oder Clusterknoten bestimmen. Richtigen Mandanten und virtuellen Kontext bestimmen. Eingangs- und Ausgangsschnittstelle bestimmen. Quell- und Zielzone bestimmen. Route zur Zieladresse prüfen. Policy-Based Routing, VRF und Tunnel berücksichtigen. Originaladressen und Originalports dokumentieren. NAT-Adressen und NAT-Ports dokumentieren. Aktive NAT-Regel bestimmen. Aktive Sicherheitsrichtlinie bestimmen. Regelreihenfolge und Prioritäten prüfen. Globale, geerbte und lokale Regeln berücksichtigen. Implizite Standardaktion bestimmen. Adress-, Dienst- und FQDN-Objekte auflösen. Zeitpläne und Identitätskriterien prüfen. Anwendungs- und Sicherheitsprofile prüfen. Policy-Match- oder Packet-Tracer-Test durchführen. Ergebnis nicht mit realem Durchsatz gleichsetzen. Regelzähler mit Ausgangswert dokumentieren. Genau einen kontrollierten Verbindungstest ausführen. Zähleränderung und Protokolle auswerten. Sitzungstabelle prüfen. TCP-, UDP- oder ICMP-Zustand auswerten. Pakete und Bytes je Richtung vergleichen. Sitzungsendgrund auswerten. Bestehende und neue Sitzung unterscheiden. Bei Bedarf Eingangs- und Ausgangsaufzeichnung durchführen. Hin- und Rückverkehr vergleichen. Cluster- und Zustandssynchronisation prüfen. Weitere Cloud- oder Subnetz-ACLs prüfen. Hypothese, erwarteten Befund und Gegenbeweis formulieren. Genau eine kontrollierte Maßnahme vorbereiten. Risiko, Rückweg und Erfolgskriterium dokumentieren. Maßnahme freigeben und umsetzen. Neue Verbindung mit identischen Parametern testen. Regel, Sitzung, Pakete, Bytes und Anwendungsergebnis verifizieren. Repräsentative weitere Datenflüsse auf Nebenwirkungen prüfen. Temporäre Logging- und Testregeln zurücknehmen. 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 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: 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 RFC 793 – Transmission Control Protocol RFC 9293 – Transmission Control Protocol RFC 768 – User Datagram Protocol RFC 792 – Internet Control Message Protocol RFC 4443 – Internet Control Message Protocol for IPv6 RFC 3022 – Traditional IP Network Address Translator RFC 4787 – NAT Behavioral Requirements for UDP RFC 7857 – NAT Behavioral Requirements Updates Cisco Cisco – Configure IP Access Lists Cisco Secure Firewall ASA – Access Rules Cisco Secure Firewall ASA – packet-tracer Command Reference Cisco Secure Firewall ASA – show Command Reference Cisco Secure Firewall ASA – show asp drop Usage Juniper Networks Juniper – Configuring Security Policies Juniper – Reordering Security Policies Juniper – show security match-policies Juniper – Monitoring and Troubleshooting Security Policies Palo Alto Networks Palo Alto Networks – Security Policy Rules Palo Alto Networks – Security Policy Palo Alto Networks – Security Policy Rule Best Practices Palo Alto Networks – Traffic Log Fields Amazon Web Services AWS – Control Subnet Traffic with Network ACLs AWS – Control Traffic Using Security Groups AWS – Security Group Rules AWS – Network ACL Examples AWS – Infrastructure Security in Amazon VPC Microsoft Azure Microsoft Learn – Azure Network Security Groups Overview Microsoft Learn – Azure Firewall Rule Processing Logic Microsoft Learn – Azure Virtual Network Traffic Routing Microsoft Learn – Azure Network Security 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: Hinweg: Client -> Router A -> Firewall A -> Router B -> Server Rückweg: Server -> Router B -> Firewall A -> Router A -> Client Asymmetrischer Pfad: 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: Existiert ein Rückweg? Sondern: 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: Quelladresse Quellport Zieladresse Zielport IP-Protokoll Beispiel: 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: 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: 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: 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: Client sendet ein TCP- SYN . Firewall A prüft die Sicherheitsregel. Firewall A legt eine Sitzung an. Server sendet SYN, ACK . Routing leitet die Antwort über Firewall B. Firewall B besitzt keine passende Sitzung. Firewall B sieht ein Antwortpaket ohne bekannten Verbindungsaufbau. Firewall B verwirft es als unbekannt oder ungültig. Vereinfachte Sicht: 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: 10.0.0.0/8 über Firewall A 10.20.30.0/24 über Firewall B Für das Ziel: 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: 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: 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: sysctl net.ipv4.conf.all.rp_filter sysctl net.ipv4.conf.default.rp_filter Schnittstellenspezifisch: 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: 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: 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: 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: 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: nf_conntrack_count nf_conntrack_max nf_conntrack_buckets Lesende Prüfung: sysctl net.netfilter.nf_conntrack_count sysctl net.netfilter.nf_conntrack_max sysctl net.netfilter.nf_conntrack_buckets Alternative direkte Anzeige: cat /proc/sys/net/netfilter/nf_conntrack_count cat /proc/sys/net/netfilter/nf_conntrack_max Auslastung berechnen: Auslastung in Prozent = nf_conntrack_count / nf_conntrack_max × 100 Beispiel: 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: 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: Zähler und Uhrzeit erfassen. definierten Testzeitraum starten. genau einen reproduzierbaren Test durchführen. Zähler erneut erfassen. 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: sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_sent sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv sysctl net.netfilter.nf_conntrack_tcp_timeout_established sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait sysctl net.netfilter.nf_conntrack_udp_timeout sysctl net.netfilter.nf_conntrack_udp_timeout_stream 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: Test A: Client -> Server Test B: Server -> Client Windows: tracert 198.51.100.25 Test-NetConnection ` -ComputerName "198.51.100.25" ` -Port 443 ` -InformationLevel Detailed Linux: traceroute 198.51.100.25 tracepath 198.51.100.25 macOS: 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: Get-NetRoute ` -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric Bestimmte Zielroute: Find-NetRoute ` -RemoteIPAddress "198.51.100.25" Klassische Anzeige: route print Linux: ip route get 198.51.100.25 Mit angenommener Quelladresse: ip route get 198.51.100.25 from 192.0.2.100 Policy-Regeln: ip rule show Alle Routingtabellen: ip route show table all IPv6: ip -6 route get 2001:db8::25 macOS: 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: sudo conntrack -L Nur TCP: sudo conntrack -L -p tcp Nach Originalquelle und Originalziel filtern: sudo conntrack -L \ -p tcp \ -s 192.0.2.100 \ -d 198.51.100.25 \ --dport 443 Nach UDP filtern: sudo conntrack -L \ -p udp \ -s 192.0.2.100 \ -d 198.51.100.53 \ --dport 53 Anzahl anzeigen: sudo conntrack -C Statistiken anzeigen: sudo conntrack -S Conntrack-Ereignisse beobachten: sudo conntrack -E Gezielt TCP-Ereignisse beobachten: sudo conntrack -E -p tcp Mögliche Ereignisse: [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: sudo cat /proc/net/nf_conntrack Gezielte Textfilterung: 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: ip netns list Routing in einem Namespace: sudo ip netns exec ip route show Schnittstellen: 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: show conn Nach Adresse filtern: show conn address 192.0.2.100 Anzahl und Kapazität: show conn count NAT-Zustände: show xlate HA-Zustand: show failover Routing: show route Drop-Zähler: show asp drop Datenfluss simulieren: 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: show security flow session Nach Quelle: show security flow session source-prefix 192.0.2.100 Nach Ziel: show security flow session destination-prefix 198.51.100.25 Route: show route 198.51.100.25 Flow-Statistiken: show security flow statistics Clusterzustand: 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: show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443 Filtermöglichkeiten prüfen: show session all filter ? Routingentscheidung: test routing fib-lookup virtual-router ip 198.51.100.25 HA-Zustand: 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: 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: host 192.0.2.100 and host 198.51.100.25 and tcp port 443 Mit tcpdump : 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: 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: 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: 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: 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 Exakte Fehlermeldung dokumentieren. Datum, Uhrzeit und Zeitzone erfassen. Betroffene Anwendung bestimmen. Quell- und Zielsystem bestimmen. Quelladresse und Quellport erfassen. Zieladresse und Zielport erfassen. Protokoll bestimmen. IPv4 und IPv6 unterscheiden. Originalrichtung dokumentieren. Antwortrichtung dokumentieren. NAT vor und nach Übersetzung dokumentieren. Fehlerumfang bestimmen. Erwarteten Hinweg dokumentieren. Erwarteten Rückweg dokumentieren. Lokale Clientroute prüfen. Lokale Serverroute prüfen. Policy Routing auf beiden Endsystemen prüfen. Routinginstanzen und VRFs berücksichtigen. Tatsächlichen Hinweg nachweisen. Tatsächlichen Rückweg unabhängig nachweisen. Alle zustandsbehafteten Komponenten erfassen. Aktive Firewall- und Clusterknoten bestimmen. Sessiontabellen auf allen möglichen Knoten prüfen. Sitzungs-ID dokumentieren. Original- und Antwort-Tupel vergleichen. TCP-, UDP- oder ICMP-Zustand auswerten. [UNREPLIED] , [ASSURED] oder vergleichbare Markierung prüfen. Pakete und Bytes je Richtung vergleichen. NAT-Sitzung und NAT-Besitzer prüfen. Regel- und Drop-Protokolle korrelieren. Cluster- und State-Synchronisation prüfen. Zeitpunkt des letzten Failovers prüfen. ECMP und Hash-Verfahren prüfen. PBR und Source Routing prüfen. dynamische Routen und spezifischere Präfixe prüfen. Load Balancer und Direct Server Return berücksichtigen. Cloud-Routingtabellen und Firewallendpunkte prüfen. Conntrack-Auslastung erfassen. Conntrack-Fehlerzähler erfassen. Timeouts dokumentieren. Hardware-Offloading berücksichtigen. kontrollierten Verbindungstest durchführen. bei Bedarf Conntrack-Ereignisse beobachten. bei Bedarf Paketaufzeichnung an mehreren Punkten durchführen. Hypothese und Gegenbeweis formulieren. genau eine kontrollierte Maßnahme vorbereiten. Risiko, Rückweg und Erfolgskriterium dokumentieren. Maßnahme freigeben und umsetzen. vollständig neue Sitzung aufbauen. Hin- und Rückweg erneut prüfen. Session- und NAT-Zustand erneut prüfen. ursprüngliche Anwendung verifizieren. weitere repräsentative Datenflüsse prüfen. temporäre Aufzeichnungen und Diagnoseregeln zurücknehmen. 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 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: 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 RFC 9293 – Transmission Control Protocol RFC 768 – User Datagram Protocol RFC 792 – Internet Control Message Protocol RFC 4443 – Internet Control Message Protocol for IPv6 RFC 3022 – Traditional IP Network Address Translator RFC 4787 – NAT Behavioral Requirements for UDP RFC 7857 – Updates to NAT Behavioral Requirements Linux Kernel und Netfilter Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables Linux Kernel Documentation – Conntrack Netlink Specification Netfilter – Conntrack Tools User Manual Netfilter – conntrack Command Documentation nftables – Matching Connection Tracking Stateful Metadata nftables – Flowtables Cisco Cisco Secure Firewall ASA – Connection Settings Cisco – Configure TCP State Bypass on ASA Cisco Secure Firewall ASA – show Command Reference Cisco Secure Firewall ASA – packet-tracer Command Reference Cisco Secure Firewall ASA – show asp drop Usage Juniper Networks Juniper – show security flow session Juniper – Express Path Overview Amazon Web Services AWS Network Firewall – Avoiding Asymmetric Routing AWS Network Firewall – Troubleshooting General Issues AWS Network Firewall – Analyzing Stateless Rule Groups Amazon EC2 – Security Group Connection Tracking Microsoft Azure Microsoft Learn – Asymmetrisches Routing mit mehreren Netzwerkpfaden Microsoft Learn – Integrate Azure Firewall with Azure Standard Load Balancer Microsoft Learn – Diagnose an Azure Virtual Machine Routing Problem Microsoft Learn – Virtual WAN Hub 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: 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: 192.0.2.100:53124 -> 198.51.100.25:443/TCP Port Rolle 53124 dynamischer Quellport des Clients 443 Zielport des Serverdienstes Rückverkehr: 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: Quelladresse Quellport Zieladresse Zielport Protokoll Beispiel: 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: 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: 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: Anzahl = Endport - Startport + 1 Beispiel: 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: 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: 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: 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: 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: viele interne Systeme -> eine öffentliche NAT-Adresse -> eine Zieladresse -> ein Zielport Beispiel: 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: Ziel-IP-Adresse Zielport Protokoll Beispiel: 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: Die Gegenstelle hat das Ende der Verbindung angekündigt. Das lokale Betriebssystem hat dies an die Anwendung gemeldet. 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: Client kontaktiert Ziel auf TCP 135 . Endpoint Mapper nennt den dynamischen Serverport. Client verbindet sich mit diesem Zielport. Der Client verwendet dafür zusätzlich einen eigenen dynamischen Quellport. Beispiel: 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: netsh int ipv4 show dynamicport tcp IPv4 UDP: netsh int ipv4 show dynamicport udp IPv6 TCP: netsh int ipv6 show dynamicport tcp IPv6 UDP: netsh int ipv6 show dynamicport udp Bei aktuellen unterstützten Windows-Versionen ist der Standardbereich normalerweise: 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: Get-NetTCPConnection Etablierte Verbindungen: Get-NetTCPConnection ` -State Established TIME_WAIT : Get-NetTCPConnection ` -State TimeWait CLOSE_WAIT : Get-NetTCPConnection ` -State CloseWait Ausgehende Verbindungsversuche: Get-NetTCPConnection ` -State SynSent Nach Ziel filtern: Get-NetTCPConnection ` -RemoteAddress "198.51.100.25" ` -RemotePort 443 Nach Prozess-ID filtern: Get-NetTCPConnection ` -OwningProcess Prozess bestimmen: Get-Process ` -Id Windows: Zustände zählen Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Count, Name Mögliche Ausgabe: 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 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: Get-Process ` -Id Ausführlicher Zusammenhang: 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 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: netstat -ano Mit ausführbarer Datei, administrative Eingabeaufforderung erforderlich: netstat -anob Gebundene Ports einschließlich bestimmter nicht aktiver TCP-Bindungen: netstat -anoq TIME_WAIT zählen: netstat -ano | find /c "TIME_WAIT" CLOSE_WAIT zählen: netstat -ano | find /c "CLOSE_WAIT" SYN_SENT zählen: 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: 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: $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 sysctl net.ipv4.ip_local_port_range Alternative: cat /proc/sys/net/ipv4/ip_local_port_range Beispielausgabe: 32768 60999 Das ist nur ein Beispiel. Die lokale Ausgabe ist maßgeblich. Reservierte lokale Ports: sysctl net.ipv4.ip_local_reserved_ports Alternative: 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 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: ss -tan Mit Prozessinformationen: sudo ss -tanp Etablierte Verbindungen: ss -tan state established TIME_WAIT : ss -tan state time-wait CLOSE_WAIT : ss -tan state close-wait SYN_SENT : ss -tan state syn-sent Listener: ss -lntp Nach Ziel filtern: ss -tanp \ dst 198.51.100.25:443 Linux: Zustände zählen ss -Htan | awk '{print $1}' | sort | uniq -c | sort -nr Nur TIME_WAIT zählen: ss -Htan state time-wait | wc -l Nur CLOSE_WAIT zählen: ss -Htan state close-wait | wc -l Nur SYN_SENT zählen: ss -Htan state syn-sent | wc -l Linux: Kernel-Socketstatistik IPv4 und allgemeine Socketstatistik: cat /proc/net/sockstat IPv6: 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: ulimit -n Grenzen eines laufenden Prozesses: cat /proc//limits Offene Dateideskriptoren eines Prozesses zählen: ls -1 /proc//fd | wc -l Systemweite Dateideskriptorinformationen: cat /proc/sys/fs/file-nr Systemweite Obergrenze: 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: ss -lnt Globale Obergrenze des Listen-Backlogs: sysctl net.core.somaxconn TCP-SYN-Backlog: 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: sysctl net.netfilter.nf_conntrack_count Maximalwert: sysctl net.netfilter.nf_conntrack_max Statistiken, sofern conntrack-tools installiert ist: 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: sysctl -a | awk '/net\.inet\.ip\.portrange/' Je nach macOS-Version können unter anderem folgende Werte verfügbar sein: sysctl net.inet.ip.portrange.first sysctl net.inet.ip.portrange.last sysctl net.inet.ip.portrange.hifirst 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: netstat -anv -p tcp TCP-Sockets mit Prozessen: sudo lsof -nP -iTCP Nur etablierte TCP-Verbindungen: sudo lsof -nP -iTCP -sTCP:ESTABLISHED Nur Listener: sudo lsof -nP -iTCP -sTCP:LISTEN TCP-Statistik: netstat -s -p tcp Interaktive Netzwerksicht: nettop -m tcp Die genaue Ausgabe unterscheidet sich je nach macOS-Version. Prozess statt nur Portbereich untersuchen Die wichtigste Frage lautet häufig: 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: dauerhaft mögliche neue Verbindungen pro Sekunde ≈ verfügbare Portkombinationen / Belegungsdauer Beispiel: 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: 100 Anfragen × 5 sofortige Wiederholungen = 500 Verbindungsversuche Bei mehreren Anwendungsinstanzen: 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: 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: 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: 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: 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: 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 Exakte Fehlermeldung erfassen. Datum, Uhrzeit und Zeitzone dokumentieren. Betroffene Anwendung bestimmen. Ausgehende und eingehende Verbindungen unterscheiden. Quell- und Zielsystem bestimmen. Quelladresse und Zieladresse erfassen. Quellport und Zielport erfassen. TCP, UDP und QUIC unterscheiden. IPv4 und IPv6 unterscheiden. Umfang der Störung bestimmen. Prüfen, ob bestehende Verbindungen weiter funktionieren. Prüfen, ob nur neue Verbindungen scheitern. Dynamischen Portbereich auslesen. Reservierte und ausdrücklich gebundene Ports berücksichtigen. Anzahl aktueller TCP-Verbindungen erfassen. UDP-Sockets erfassen. TCP-Zustände gruppieren. TIME_WAIT auswerten. CLOSE_WAIT auswerten. SYN_SENT auswerten. Verbindungen nach Prozess gruppieren. Verbindungen nach Ziel gruppieren. Verbindungsrate messen. Retryrate bestimmen. Connection-Pool-Konfiguration prüfen. Dateideskriptoren und Handles prüfen. Listener- und Backloggrenzen prüfen. Anwendungs- und Workerlimits prüfen. Conntrack-Auslastung prüfen. Firewall- und NAT-Sitzungsgrenzen prüfen. Vor-NAT- und Nach-NAT-Ports dokumentieren. SNAT-Portnutzung prüfen. Cloudmetriken und Port Allocation Errors prüfen. Container-, Node- und Podkontext berücksichtigen. Proxy- und Sidecar-Verbindungen getrennt prüfen. Anwendungsprotokolle auswerten. Betriebssystemereignisse auswerten. kontrollierte Testverbindung durchführen. bei Bedarf Paketaufzeichnung durchführen. Hypothese und Gegenbeweis formulieren. genau eine kontrollierte Maßnahme vorbereiten. Risiko, Rückweg und Erfolgskriterium dokumentieren. Maßnahme freigeben und umsetzen. neue Verbindungen unter gleicher Last testen. Portbelegung und Zustände erneut messen. SNAT-, Conntrack- und Fehlerzähler erneut prüfen. ursprüngliche Anwendung verifizieren. Nebenwirkungen auf andere Dienste prüfen. temporäre Diagnosemaßnahmen zurücknehmen. 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 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: 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 RFC 6335 – Internet Assigned Numbers Authority Procedures for Service Names and Transport Protocol Port Numbers RFC 7605 – Recommendations on Using Assigned Transport Port Numbers RFC 6056 – Recommendations for Transport-Protocol Port Randomization RFC 9293 – Transmission Control Protocol RFC 768 – User Datagram Protocol RFC 4787 – NAT Behavioral Requirements for UDP RFC 7857 – Updates to NAT Behavioral Requirements Microsoft Windows Microsoft Learn – TCP/IP Port Exhaustion Troubleshooting Microsoft Learn – Get-NetTCPConnection Microsoft Learn – Configure RPC Dynamic Port Allocation with Firewalls Linux Kernel und Manpages Linux Kernel Documentation – IP Sysctl Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables Linux man-pages – IP_LOCAL_PORT_RANGE Linux man-pages – ip(7) Linux man-pages – tcp(7) Linux man-pages – socket(7) iproute2 – ss(8) Netfilter – Conntrack Tools User Manual Amazon Web Services AWS – NAT Gateway Basics AWS – Work with NAT Gateways AWS – Troubleshoot NAT Gateways Microsoft Azure Microsoft Learn – Source Network Address Translation with Azure NAT Gateway Microsoft Learn – Azure NAT Gateway Resource Microsoft Learn – Troubleshoot Azure NAT Gateway Connectivity Microsoft Learn – Azure Load Balancer Outbound Connections Microsoft Learn – Troubleshoot Azure Load Balancer Outbound Connectivity Google Cloud Google Cloud – Cloud NAT IP Addresses and Ports Google Cloud – Troubleshoot Cloud NAT 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: 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: 198.51.100.40:53124 -> 203.0.113.10:8443/TCP Nach der Zielübersetzung: 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: 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: 192.0.2.100:53124 -> 198.51.100.25:443 Nach SNAT: 203.0.113.10:61001 -> 198.51.100.25:443 Das Zielsystem sieht als Quelle: 203.0.113.10:61001 und normalerweise nicht: 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: 198.51.100.40:53124 -> 203.0.113.10:8443 Nach DNAT: 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: 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: 198.51.100.25:443 Das NAT-Gerät hält dafür getrennte Zuordnungen: 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: Öffentlich: 203.0.113.25 Intern: 192.0.2.25 Mögliche Übersetzung: 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: Externe Adresse: 203.0.113.10 Externer Port: 8443 Protokoll: TCP Internes Ziel: 192.0.2.25 Interner Port: 443 Vereinfachte Regel: 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: 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: TCP 203.0.113.10:8443 -> 192.0.2.25:443 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: 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: öffentlicher DNS-Eintrag; Internetzugangsanbieter; vorgeschaltetes Provider-NAT; Modem oder Router; Edge-Firewall; öffentliche IP-Adresse; DNAT- oder Portweiterleitungsregel; Sicherheitsregel; interne Route; VLAN- oder Segmentfirewall; Load Balancer; Reverse Proxy; Containerhost; veröffentlichter Hostport; Containerport; lokale Host-Firewall; Serverprozess; 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: 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: 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: 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: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Das bedeutet: 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: 100.64.0.0/10 Das umfasst: 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: 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: 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: Interner Client: 192.0.2.100 Öffentliche Dienstadresse: 203.0.113.10:443 Interner Server: 192.0.2.25:443 Der Client verwendet: 192.0.2.100:53124 -> 203.0.113.10:443 Das NAT-Gerät übersetzt das Ziel: 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: 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: 192.0.2.1 eine Adresse des NAT-Gateways. Der Server antwortet an das Gateway: 192.0.2.25:443 -> 192.0.2.1:61001 Das Gateway stellt für den Client wieder die erwartete Ansicht her: 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: Client: 192.0.2.100 Server: 192.0.2.25 Wenn nur das Ziel übersetzt wird, kann der Server direkt antworten: 192.0.2.25:443 -> 192.0.2.100:53124 Der Client hat die Verbindung jedoch zu folgender Adresse aufgebaut: 203.0.113.10:443 Eine direkte Antwort von: 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: app.example.test -> 203.0.113.10 Intern: 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: 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: Resolve-DnsName ` -Name "app.example.test" ` -Type A Resolve-DnsName ` -Name "app.example.test" ` -Type AAAA Linux und macOS: dig app.example.test A 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: FQDN: app.example.test Öffentliche Adresse: 203.0.113.10 Interner Server: 192.0.2.25 Das Zertifikat muss zum verwendeten Namen passen: 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: 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: 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: docker run \ -p 8080:80 \ nginx Bedeutung: 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: 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: docker ps \ --format 'table {{.Names}}\t{{.Ports}}' Portzuordnung eines Containers: docker port Vollständige Netzwerkinformation: docker inspect Hostlistener: ss -lntp Containerlistener: 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: Routerport Hostport Containerport Anwendungsport Beispiel: 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: öffentliche Adresse -> Cloud Load Balancer -> Ingress Controller -> Kubernetes Service -> Pod Oder: Node-IP:NodePort -> Service -> Pod Lesende Prüfungen: kubectl get services \ --all-namespaces \ -o wide kubectl get ingress \ --all-namespaces kubectl get endpointslices \ --all-namespaces 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: Get-NetNat Statische Abbildungen: Get-NetNatStaticMapping Aktive NAT-Sitzungen: Get-NetNatSession Netzwerkschnittstellen: Get-NetIPConfiguration Routing: Get-NetRoute Listener: 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: sudo nft list ruleset Tabellen: sudo nft list tables Eine bekannte NAT-Tabelle anzeigen: sudo nft list table ip nat Die Tabelle muss nicht ip nat heißen. Maßgeblich ist die Ausgabe von: sudo nft list tables Regelwerk mit Handles: sudo nft -a list ruleset Zu suchen sind unter anderem: 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 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 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: sudo iptables \ -t nat \ -L \ -n \ -v \ --line-numbers Regeln in speicherbarer Syntax: sudo iptables \ -t nat \ -S IPv6-Regeln, sofern verwendet: sudo ip6tables \ -t nat \ -S Filter- und Forwardingregeln: sudo iptables \ -L FORWARD \ -n \ -v \ --line-numbers Aktive Weiterleitung: sysctl net.ipv4.ip_forward IPv6-Weiterleitung: sysctl net.ipv6.conf.all.forwarding Linux Connection Tracking Aktive NAT- und Verbindungseinträge: sudo conntrack -L TCP-Einträge zu einem internen Server: sudo conntrack -L \ -p tcp \ -d 192.0.2.25 \ --dport 443 Ereignisse während eines kontrollierten Tests: 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: show nat Details und Treffer: show nat detail Übersetzungen: show xlate Verbindungen: show conn Nach Adresse filtern: show conn address 192.0.2.25 Routing: show route Simulation: 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: 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: sudo tcpdump \ -ni \ 'host 198.51.100.40 and host 203.0.113.10 and tcp port 8443' Auf dem internen Abschnitt: sudo tcpdump \ -ni \ 'host 198.51.100.40 and host 192.0.2.25 and tcp port 443' Am Server: 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: Test-NetConnection ` -ComputerName "203.0.113.10" ` -Port 8443 ` -InformationLevel Detailed Linux und macOS: nc -vz 203.0.113.10 8443 HTTPS mit FQDN: 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: 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 Exakte Fehlermeldung erfassen. Datum, Uhrzeit und Zeitzone dokumentieren. Betroffene Anwendung bestimmen. FQDN dokumentieren. DNS-A- und AAAA-Antworten prüfen. tatsächlich verwendete Zieladresse bestimmen. TCP, UDP oder anderes Protokoll bestimmen. externen Zielport bestimmen. internen Zielport bestimmen. externe Quelladresse dokumentieren. öffentliche Zieladresse dokumentieren. internes Ziel dokumentieren. Vor-NAT-Tupel dokumentieren. Nach-NAT-Tupel dokumentieren. Umfang der Störung bestimmen. interne Direktverbindung testen. internen Zugriff über öffentliche Adresse testen. tatsächlich externen Zugriff testen. WAN-Adresse des Edge-Geräts prüfen. vorgeschaltetes NAT oder CGNAT prüfen. doppeltes NAT berücksichtigen. richtige Eingangsschnittstelle bestimmen. richtige öffentliche Zieladresse bestimmen. aktive NAT-Konfiguration prüfen. NAT-Regelreihenfolge prüfen. NAT-Regeltreffer dokumentieren. Firewallregel getrennt prüfen. Routing zum internen Ziel prüfen. Host-Firewall prüfen. Listener des Serverdienstes prüfen. Serverantwort und Rückroute prüfen. NAT-Sitzung oder Translation Table prüfen. Hin- und Rückverkehr vergleichen. Hairpin-Unterstützung prüfen. Hairpin-DNAT und gegebenenfalls SNAT prüfen. Split-DNS-Verhalten berücksichtigen. Reverse Proxy oder Load Balancer prüfen. Container-Hostport und Containerport prüfen. Kubernetes-Servicepfad berücksichtigen. automatische Portabbildungen prüfen. ALG oder NAT-Helper berücksichtigen. IPv4 und IPv6 getrennt prüfen. Cloud-NAT und Inbound-Komponente unterscheiden. bei Bedarf Paketaufzeichnung vor und nach NAT durchführen. Hypothese und Gegenbeweis formulieren. genau eine kontrollierte Maßnahme vorbereiten. Risiko, Rückweg und Erfolgskriterium dokumentieren. Maßnahme freigeben und umsetzen. neue Sitzung aufbauen. internen, Hairpin- und externen Test wiederholen. NAT-, Firewall- und Anwendungslogs verifizieren. weitere repräsentative Quellen testen. temporäre Regeln und Captures zurücknehmen. 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 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: 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 RFC 3022 – Traditional IP Network Address Translator RFC 4787 – NAT Behavioral Requirements for UDP RFC 5382 – NAT Behavioral Requirements for TCP RFC 5508 – NAT Behavioral Requirements for ICMP RFC 7857 – Updates to NAT Behavioral Requirements RFC 1918 – Address Allocation for Private Internets RFC 6598 – Shared Address Space Request RFC 6886 – NAT Port Mapping Protocol RFC 6887 – Port Control Protocol RFC 6296 – IPv6-to-IPv6 Network Prefix Translation RFC 2993 – Architectural Implications of NAT Microsoft Windows Microsoft Learn – Get-NetNat Microsoft Learn – Get-NetNatStaticMapping Microsoft Learn – Get-NetNatSession Microsoft Learn – Set Up a NAT Network Microsoft Learn – Windows Container Network Drivers Linux Netfilter Netfilter – nftables Manual Netfilter – iptables Extensions Manual Netfilter – Conntrack Tools User Manual Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables Docker und Kubernetes Docker Docs – Port Publishing and Mapping Docker Docs – Networking Overview Docker Docs – Bridge Network Driver Docker Docs – Host Network Driver Docker Docs – Packet Filtering and Firewalls Kubernetes Documentation – Service Kubernetes Documentation – Ingress Cisco Cisco Secure Firewall ASA – NAT Basics Cisco – Configure NAT and ACLs on ASA Cisco Secure Firewall ASA – packet-tracer Command Reference Amazon Web Services AWS – NAT Gateways AWS – NAT Gateway Basics AWS – NAT Gateway Use Cases AWS – Internet Gateways Microsoft Azure Microsoft Learn – Azure NAT Gateway Overview Microsoft Learn – Azure NAT Gateway Resource Microsoft Learn – Azure Load Balancer Outbound Connections Microsoft Learn – Azure Firewall DNAT Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.