2. Grundwerkzeuge und Befehle 2.0 Werkzeugwahl, Kennzeichnungen und sichere Anwendung Ziel dieser Seite Diese Seite erklärt, wie für eine konkrete Diagnosefrage das passende Werkzeug ausgewählt wird. Sie legt außerdem die Kennzeichnungen fest, die in diesem Kapitel vor den Befehlen verwendet werden. Die wichtigste Grundregel lautet: Erst die Diagnosefrage formulieren, dann das Werkzeug auswählen und erst danach den Befehl ausführen. Ein Werkzeug ist ein Messinstrument. Es ersetzt weder eine Hypothese noch die Bewertung des Ergebnisses. 1. Grundhaltung bei der Werkzeugwahl Administratoren sollten nicht möglichst viele Befehle ausführen, sondern mit möglichst wenigen, gezielten Prüfungen die Fehlerdomäne eingrenzen. Vor jedem Befehl werden deshalb fünf Fragen beantwortet: Was möchte ich mit diesem Befehl feststellen? Welches Ergebnis erwarte ich bei einem funktionierenden System? Welches Ergebnis würde meine Hypothese widerlegen? Kann der Befehl den Zustand des Systems verändern? Welche Daten muss ich zusammen mit dem Ergebnis dokumentieren? Ein Befehl ohne konkrete Diagnosefrage erzeugt häufig nur zusätzliche Informationen, aber noch keine Erkenntnis. Beispiel Ungeeignete Fragestellung: Ich führe erst einmal alle Netzwerkbefehle aus. Geeignete Fragestellung: Ich möchte feststellen, über welches Interface und welches Gateway der Client das Ziel 192.0.2.25 erreichen würde. Dazu wird zunächst die Routingentscheidung geprüft. Ein Paketmitschnitt oder ein Portscan wäre zu diesem Zeitpunkt normalerweise noch nicht erforderlich. 2. Bedeutung der Kennzeichnungen Die folgenden Kennzeichnungen stehen in diesem Buch vor Befehlen. Sie gehören nicht zum Befehl und dürfen nicht mit eingegeben werden. Kennzeichnung Bedeutung Typische Auswirkung [RO] Read-only beziehungsweise nur lesende Abfrage Liest Status oder Konfiguration aus, ohne sie absichtlich zu verändern [TEST] Aktiver Diagnosetest Sendet kontrollierte Anfragen oder Testpakete [PRIV] Erhöhte Rechte erforderlich Benötigt Administrator-, Root- oder vergleichbare Rechte [FILE] Erzeugt oder exportiert eine Datei Benötigt einen geeigneten und geschützten Ablageort [SENS] Möglicherweise sensible Ausgabe Kann interne Adressen, Namen, Benutzer-, Zertifikats- oder Nutzdaten enthalten [LOAD] Erzeugt relevante Last oder Datenverkehr Kann Bandbreite, CPU, Speicher oder einen Zielservice belasten [CHANGE] Verändert Zustand oder Konfiguration Erfordert Prüfung, Dokumentation und normalerweise einen Rückfallplan [DISRUPT] Möglicherweise dienstunterbrechend Darf nur mit geklärter Auswirkung und entsprechender Freigabe eingesetzt werden Kennzeichnungen können kombiniert werden. Beispiele: [RO] ip address 2.1 Windows-Netzwerkbefehle Ziel dieser Seite Diese Seite enthält die wichtigsten klassischen Windows-Befehle für die praktische Netzwerkdiagnose. Sie behandelt vor allem Werkzeuge, die über die Eingabeaufforderung cmd.exe oder aus PowerShell heraus gestartet werden können. Die objektorientierten PowerShell-Cmdlets wie Get-NetIPConfiguration , Get-NetRoute , Resolve-DnsName und Test-NetConnection folgen auf der nächsten Seite. 1. Wichtige Hinweise zur Verwendung Die Kennzeichnungen wie [RO] , [TEST] und [CHANGE] gehören nicht zum Befehl und dürfen nicht mit eingegeben werden. Die Beispiele verwenden reservierte Dokumentationsadressen und -namen: Platzhalter Bedeutung 192.0.2.25 Beispielhafte IPv4-Zieladresse 192.0.2.53 Beispielhafter DNS-Server server.example.test Beispielhafter vollständiger DNS-Name example.test Beispielhafte DNS-Domäne Durch echten Hostnamen oder echte IP-Adresse ersetzen Durch den tatsächlichen Namen des Netzwerkadapters ersetzen Durch eine ermittelte Prozess-ID ersetzen Durch einen vorhandenen und geeigneten Speicherort ersetzen Vor einer Veränderung sollten zuerst die [RO] -Befehle ausgeführt und deren Ergebnisse gesichert werden. 2. Schnellübersicht Aufgabe Kennzeichnung Befehl Computername anzeigen [RO] hostname MAC-Adressen anzeigen [RO] getmac /v Grundlegende IP-Konfiguration [RO] ipconfig Vollständige IP-Konfiguration [RO][SENS] ipconfig /all DNS-Clientcache anzeigen [RO][SENS] ipconfig /displaydns DNS-Clientcache leeren [CHANGE] ipconfig /flushdns DHCP-Lease freigeben [CHANGE][DISRUPT] ipconfig /release DHCP-Lease erneuern [TEST][CHANGE] ipconfig /renew IPv4-Erreichbarkeit testen [TEST] ping /4 IPv6-Erreichbarkeit testen [TEST] ping /6 Netzwerkpfad anzeigen [TEST] tracert /d Pfad und Paketverlust untersuchen [TEST] pathping /n Routingtabelle anzeigen [RO] route print IPv4-ARP-Cache anzeigen [RO] arp -a DNS-Abfrage ausführen [TEST] nslookup Bestimmten DNS-Server abfragen [TEST] nslookup TCP-Verbindungen und Listener anzeigen [RO][SENS] netstat -ano Prozess zu einer PID ermitteln [RO] tasklist /FI "PID eq " Status der Netzwerkinterfaces [RO] netsh interface show interface IPv4-Nachbartabelle anzeigen [RO] netsh interface ipv4 show neighbors IPv6-Nachbartabelle anzeigen [RO] netsh interface ipv6 show neighbors WLAN-Verbindung anzeigen [RO][SENS] netsh wlan show interfaces Sichtbare WLANs anzeigen [TEST][SENS] netsh wlan show networks mode=bssid WLAN-Bericht erzeugen [FILE][SENS] netsh wlan show wlanreport WinHTTP-Proxy anzeigen [RO][SENS] netsh winhttp show proxy Firewallstatus anzeigen [RO] netsh advfirewall show allprofiles state 3. Empfohlene Reihenfolge für eine erste Windows-Netzwerkdiagnose Schritt Diagnosefrage Befehl 1 Auf welchem Computer wird getestet? hostname 2 Welche Netzwerkadapter sind vorhanden und aktiv? netsh interface show interface 3 Welche IP-, Gateway-, DHCP- und DNS-Konfiguration liegt vor? ipconfig /all 4 Funktioniert der lokale TCP/IP-Stack? ping 127.0.0.1 5 Ist das lokale Standardgateway erreichbar? ping 6 Ist eine entfernte IP-Adresse erreichbar? ping /4 7 Funktioniert die Namensauflösung? nslookup 8 Sind IP-Adresse und Name unterschiedlich betroffen? ping und ping 9 Welchen Weg nimmt der Datenverkehr? tracert /d 10 Gibt es Hinweise auf Verlust oder starke Latenz? pathping /n 11 Welche Route wird wahrscheinlich verwendet? route print 12 Existiert eine lokale Nachbarzuordnung? arp -a 13 Lauscht lokal ein Prozess auf dem erwarteten Port? netstat -ano 14 Welcher Prozess gehört zur gefundenen PID? tasklist /FI "PID eq " 15 Sind Proxy oder Windows-Firewall relevant? netsh winhttp show proxy und netsh advfirewall show currentprofile Diese Reihenfolge ist ein Ausgangspunkt. Sie wird an das konkrete Fehlerbild angepasst. 4. Computername und MAC-Adressen Computername anzeigen Kennzeichnung: [RO] hostname Der Befehl zeigt den Hostnamenanteil des vollständigen Computernamens an. Das ist nützlich, um sicherzustellen, dass die Diagnose tatsächlich auf dem vorgesehenen System durchgeführt wird. Computername über die Umgebungsvariable anzeigen Kennzeichnung: [RO] echo %COMPUTERNAME% %COMPUTERNAME% zeigt üblicherweise denselben Computernamen in Großbuchstaben an. In Clusterumgebungen kann sich die Ausgabe von hostname jedoch durch die Variable _CLUSTER_NETWORK_NAME_ unterscheiden. MAC-Adressen und zugehörige Adapter anzeigen Kennzeichnung: [RO] getmac /v Ausführliche Ausgabe als Liste: getmac /v /fo list Ausgabe als CSV: getmac /v /fo csv Wichtige Felder: Feld Bedeutung Connection Name Name des Netzwerkadapters Network Adapter Beschreibung des Netzwerkgeräts Physical Address MAC-Adresse Transport Name Windows-interne Transportzuordnung Wichtig Bei WLAN können private beziehungsweise zufällige MAC-Adressen verwendet werden. Die aktuell verwendete MAC-Adresse muss deshalb nicht dauerhaft mit der auf dem Gerät aufgedruckten Hardwareadresse übereinstimmen. 5. IP-Konfiguration mit ipconfig untersuchen Grundlegende Konfiguration anzeigen Kennzeichnung: [RO] ipconfig Der Befehl zeigt unter anderem: IPv4-Adressen; IPv6-Adressen; Subnetzmasken; Standardgateways; Adapter mit getrenntem Medium. Vollständige Konfiguration anzeigen Kennzeichnung: [RO][SENS] ipconfig /all ipconfig /all ist einer der wichtigsten ersten Diagnosebefehle auf Windows-Systemen. Die Ausgabe kann interne Adressen, DNS-Suffixe, DHCP-Server und andere Infrastrukturinformationen enthalten und sollte deshalb als sensibel behandelt werden. Wichtige Felder in der Ausgabe Feld Diagnosebedeutung Host Name Name des lokalen Systems Primary DNS Suffix Primäres DNS-Suffix des Computers Node Type Verwendeter NetBIOS-Namensauflösungstyp IP Routing Enabled Gibt an, ob IP-Weiterleitung aktiviert ist Adapter Description Treiber- beziehungsweise Adapterbeschreibung Physical Address MAC-Adresse des Adapters DHCP Enabled Gibt an, ob IPv4 per DHCP konfiguriert wird Autoconfiguration Enabled Zeigt, ob automatische Adressierung möglich ist IPv4 Address Aktuelle IPv4-Adresse Subnet Mask Zugehörige IPv4-Subnetzmaske Lease Obtained Beginn des aktuellen DHCP-Leases Lease Expires Ablaufzeit des aktuellen DHCP-Leases Default Gateway Router für nicht lokal erreichbare Ziele DHCP Server DHCP-Server, von dem die Konfiguration stammt DNS Servers Eingetragene DNS-Server in ihrer Reihenfolge Connection-specific DNS Suffix DNS-Suffix des jeweiligen Adapters NetBIOS over Tcpip Status von NetBIOS über TCP/IP Media State Verbindungszustand eines Adapters Typische Auffälligkeiten Beobachtung Mögliche Bedeutung Nächste Prüfung Media disconnected Adapter besitzt derzeit keine aktive Verbindung Kabel, WLAN-Verbindung, Adapterstatus und Switchport IPv4-Adresse aus 169.254.0.0/16 Windows verwendet wahrscheinlich APIPA, weil keine verwendbare DHCP-Konfiguration vorliegt DHCP-Server, VLAN, Relay, Firewall und Link prüfen Kein Standardgateway Ziele außerhalb des lokalen Subnetzes sind normalerweise nicht über eine Default Route erreichbar DHCP-Optionen, statische Konfiguration und Routingtabelle Unerwarteter DNS-Server DNS-Anfragen können an einen falschen Resolver gehen DHCP-Option 6, VPN, statische Konfiguration und Richtlinien Mehrere Standardgateways Windows kann einen unerwarteten Ausgangspfad wählen Routingtabelle und Metriken prüfen Altes Lease Nicht automatisch fehlerhaft, aber bei Netzänderungen relevant Lease-Zeiten und DHCP-Server vergleichen Nur IPv6-Link-Local-Adresse Keine globale oder standortweite IPv6-Konfiguration erkennbar Router Advertisements, DHCPv6 und IPv6-Routing Falsches DNS-Suffix Kurznamen können falsch oder gar nicht aufgelöst werden Adapter-, DHCP-, VPN- und Domänenkonfiguration APIPA richtig bewerten Eine Adresse aus 169.254.0.0/16 wird von Windows automatisch vergeben, wenn ein DHCP-konfigurierter Adapter keine verwendbare DHCP-Antwort erhält. Damit ist unter Umständen Kommunikation mit anderen Systemen im selben lokalen Segment möglich, die ebenfalls eine passende Link-Local-Adresse besitzen. Normale geroutete Kommunikation in andere Subnetze ist damit jedoch nicht möglich. Eine APIPA-Adresse beweist noch nicht, an welcher Stelle DHCP scheitert. Mögliche Ursachen sind unter anderem: keine physische Verbindung; falsches VLAN; DHCP-Server nicht erreichbar; DHCP-Scope erschöpft oder deaktiviert; DHCP-Relay fehlt; Firewall oder DHCP-Snooping blockiert; DHCP-Clientdienst gestört. 6. DNS-Clientcache mit ipconfig prüfen DNS-Clientcache anzeigen Kennzeichnung: [RO][SENS] ipconfig /displaydns Der Cache kann enthalten: Einträge aus der lokalen hosts-Datei; zuvor abgefragte DNS-Einträge; positive DNS-Antworten; negative Cacheeinträge; Record-Typen und TTL-Werte. Die Ausgabe sollte möglichst vor dem Leeren des Caches gesichert werden. DNS-Clientcache in eine Datei schreiben Kennzeichnung: [RO][FILE][SENS] ipconfig /displaydns > "\dns-cache.txt" DNS-Clientcache leeren Kennzeichnung: [CHANGE] ipconfig /flushdns Der Befehl entfernt dynamisch hinzugefügte positive und negative Einträge aus dem DNS-Clientcache. Nicht sofort ausführen Das Leeren des Caches kann: einen wichtigen Fehlerzustand beseitigen; einen veralteten oder negativen Cacheeintrag als Ursache verbergen; die anschließende DNS-Anfrage verändern; dazu führen, dass ein sporadischer Fehler vorübergehend nicht mehr reproduzierbar ist. Deshalb zuerst: ipconfig /displaydns Danach bei begründeter Hypothese: ipconfig /flushdns Anschließend denselben Namen erneut testen. Dynamische DNS-Registrierung anstoßen Kennzeichnung: [TEST][CHANGE] ipconfig /registerdns Der Befehl stößt die manuelle dynamische Registrierung der konfigurierten DNS-Namen und IP-Adressen an. Er ist für Probleme mit dynamischen DNS-Updates gedacht und nicht als allgemeiner erster Reparaturbefehl. Nach der Ausführung sollten zusätzlich geprüft werden: DNS-Zone; Berechtigungen für dynamische Updates; DNS-Server-Ereignisse; Windows-Ereignisprotokolle; tatsächlich angelegte oder aktualisierte Records. 7. DHCP-Lease erneuern Aktuelle DHCP-Konfiguration eines Adapters freigeben Kennzeichnung: [CHANGE][DISRUPT] ipconfig /release "" Für alle DHCP-konfigurierten IPv4-Adapter: ipconfig /release Dadurch wird die aktuelle DHCP-Konfiguration verworfen. Die Netzwerkverbindung kann unterbrochen werden. DHCP-Konfiguration erneuern Kennzeichnung: [TEST][CHANGE] ipconfig /renew "" Für alle DHCP-konfigurierten IPv4-Adapter: ipconfig /renew DHCPv6-Konfiguration freigeben und erneuern Kennzeichnung: [CHANGE][DISRUPT] ipconfig /release6 "" Kennzeichnung: [TEST][CHANGE] ipconfig /renew6 "" Wichtige Sicherheitsregel ipconfig /release darf nicht unüberlegt in einer entfernten Administrationssitzung ausgeführt werden. Die Verbindung zum System kann dadurch sofort abbrechen. Vorher sichern ipconfig /all Nachher vergleichen ipconfig /all Zu vergleichen sind insbesondere: IP-Adresse; Subnetzmaske; Standardgateway; DNS-Server; DHCP-Server; DNS-Suffix; Lease-Beginn; Lease-Ablauf. Auswertung Ergebnis Mögliche Schlussfolgerung Lease wird erfolgreich erneuert DHCP-Kommunikation funktioniert grundsätzlich APIPA-Adresse nach dem Versuch Keine verwendbare DHCP-Antwort erhalten Alte Adresse bleibt bestehen Lease möglicherweise noch gültig oder Erneuerung nicht erfolgreich Neuer falscher Adressbereich Falsches VLAN, falscher Scope oder nicht autorisierter DHCP-Server möglich Gateway oder DNS fehlt DHCP-Antwort beziehungsweise DHCP-Optionen unvollständig oder falsch Befehl betrifft falschen Adapter Adaptername, virtuelle Adapter und aktive Verbindung prüfen 8. Erreichbarkeit mit ping prüfen ping sendet ICMP-Echoanforderungen und zeigt empfangene Echoantworten sowie die jeweilige Round-Trip-Zeit an. Ein erfolgreicher Ping beweist nicht, dass ein bestimmter TCP- oder UDP-Dienst funktioniert. Ein fehlgeschlagener Ping beweist nicht sicher, dass das Ziel ausgeschaltet ist. ICMP kann gefiltert, begrenzt oder deaktiviert sein. IPv4-Ziel testen Kennzeichnung: [TEST] ping /4 192.0.2.25 IPv6-Ziel testen Kennzeichnung: [TEST] ping /6 server.example.test Namen testen Kennzeichnung: [TEST] ping server.example.test Die erste Ausgabezeile zeigt normalerweise, in welche IP-Adresse der Name aufgelöst wurde. Mehrere Anfragen senden Kennzeichnung: [TEST] ping /n 10 192.0.2.25 Windows sendet standardmäßig vier Echoanforderungen. /n 10 erhöht die Anzahl auf zehn. Zeitüberschreitung festlegen Kennzeichnung: [TEST] ping /n 10 /w 1000 192.0.2.25 /w 1000 wartet pro Anfrage maximal 1000 Millisekunden auf eine Antwort. Dauerhaft testen Kennzeichnung: [TEST] ping /t 192.0.2.25 Steuerung: Tastenkombination Wirkung Strg + Unterbrechen Zwischenstatistik anzeigen und Test fortsetzen Strg + C Test beenden und Abschlussstatistik anzeigen Ein dauerhafter Ping sollte nicht unbeaufsichtigt laufen. IPv4 oder IPv6 gezielt erzwingen ping /4 server.example.test ping /6 server.example.test Damit lässt sich erkennen, ob nur einer der beiden Protokollpfade betroffen ist. Paketgröße testen Kennzeichnung: [TEST] ping /4 /f /l 1472 192.0.2.25 Bedeutung: Option Bedeutung /4 IPv4 verwenden /f „Do not Fragment“-Bit setzen /l 1472 ICMP-Datenfeld mit 1472 Byte verwenden 1472 Byte plus 20 Byte IPv4-Header und 8 Byte ICMP-Header ergeben 1500 Byte. Das ist ein üblicher Startwert für Ethernet mit einer MTU von 1500, aber nicht für jeden Pfad passend. Wenn eine Fragmentierungsmeldung erscheint, kann die Nutzlast schrittweise reduziert werden. Beispiel: ping /4 /f /l 1464 192.0.2.25 ping /4 /f /l 1400 192.0.2.25 Dieser Test kann Hinweise auf Probleme mit folgenden Komponenten geben: VPN-Tunnel; PPPoE; IPsec; GRE; Providerpfad; falsch konfigurierte MTU; gestörte Path-MTU-Discovery. Ping-Ausgaben interpretieren Ausgabe Bedeutung Reply from ... Eine ICMP-Echoantwort wurde empfangen Request timed out Innerhalb der Wartezeit wurde keine passende Echoantwort empfangen Destination host unreachable Das meldende System oder ein Router konnte das Ziel nicht erreichen General failure Lokaler Versand ist fehlgeschlagen; lokale Konfiguration, Route, Interface oder Netzwerkstack prüfen Ping request could not find host Der angegebene Name konnte nicht aufgelöst werden Stark wechselnde Laufzeiten Mögliche Überlastung, WLAN-Störung, Warteschlangen oder wechselnde Pfade Paketverlust Mögliche Filterung, Überlastung oder Verbindungsstörung; weitere Messungen erforderlich Bei Destination host unreachable ist entscheidend, welche IP-Adresse die Meldung sendet: eigene Adresse: Problem wahrscheinlich lokal oder im lokalen Segment; Standardgateway: Gateway besitzt möglicherweise keine passende Route; Zwischenrouter: Fehler weiter entfernt im Datenpfad. TTL nicht als exakte Hopanzahl interpretieren Der angezeigte TTL-Wert ist der verbleibende TTL-Wert der empfangenen Antwort. Da der ursprüngliche Startwert des Zielsystems normalerweise nicht sicher bekannt ist, kann daraus nicht zuverlässig die genaue Zahl der durchlaufenen Router berechnet werden. 9. Systematischer Ping-Test Die folgende Reihenfolge grenzt den Fehler schrittweise ein. 1. Lokalen IPv4-Loopback testen ping 127.0.0.1 Prüft grundlegende lokale IPv4-Verarbeitung. Der Test verlässt den Computer nicht. 2. Lokalen IPv6-Loopback testen ping ::1 Prüft grundlegende lokale IPv6-Verarbeitung. 3. Eigene IP-Adresse testen ping Prüft die Bindung der Adresse an den lokalen Netzwerkstack. Der Test beweist noch keine funktionierende physische Verbindung. 4. Standardgateway testen ping Prüft die ICMP-Kommunikation zum Gateway, sofern dieses ICMP beantwortet. 5. Entfernte IP-Adresse testen ping Prüft den gerouteten IP-Pfad ohne Abhängigkeit von der DNS-Namensauflösung. 6. Zielname testen ping server.example.test Vergleich: IP-Test Namenstest Wahrscheinlicher Bereich Erfolgreich Erfolgreich Grundlegende IP-Kommunikation und Namensauflösung funktionieren Erfolgreich Fehlgeschlagen Namensauflösung, Suffix, Cache oder hosts-Datei prüfen Fehlgeschlagen Name wird aufgelöst Routing, Firewall, Zielsystem oder Rückweg prüfen Beide fehlgeschlagen Keine eindeutige Aussage Lokale Konfiguration, Gateway, DNS und Pfad getrennt prüfen 10. Netzwerkpfad mit tracert untersuchen tracert erhöht schrittweise den TTL-Wert und versucht dadurch, die Router auf dem Weg zum Ziel sichtbar zu machen. Pfad zu einem Ziel anzeigen Kennzeichnung: [TEST] tracert server.example.test Namensauflösung der Zwischenstationen deaktivieren Kennzeichnung: [TEST] tracert /d 192.0.2.25 /d verhindert Reverse-DNS-Abfragen für Zwischenrouter. Dadurch wird die Ausgabe häufig schneller und DNS-Verzögerungen beeinflussen die Messung weniger. IPv4 erzwingen tracert /4 server.example.test IPv6 erzwingen tracert /6 server.example.test Maximale Hopanzahl begrenzen tracert /d /h 15 192.0.2.25 Wartezeit pro Antwort verringern tracert /d /w 1000 192.0.2.25 /w 1000 wartet bis zu 1000 Millisekunden auf die jeweilige ICMP-Antwort. Ausgabe interpretieren Beobachtung Mögliche Bedeutung Ziel wird erreicht Ein ICMP-basierter Pfad konnte bis zum Ziel verfolgt werden Einzelner Hop zeigt * , spätere Hops antworten Dieser Router antwortet möglicherweise nicht auf TTL-Überschreitungen; Weiterleitung funktioniert trotzdem Ab einem Hop nur noch * Filterung, fehlende Rückantwort, Pfadunterbrechung oder nicht antwortende Router möglich Erster Hop unerwartet Falsches Gateway, VPN, virtueller Adapter oder unerwartete Route möglich Pfad unterscheidet sich zwischen Tests Dynamisches Routing, Load Balancing, VPN-Wechsel oder andere Pfadauswahl möglich Hohe Laufzeit an einem Hop, spätere Hops wieder normal Der Router priorisiert seine eigenen ICMP-Antworten möglicherweise niedrig; kein sicherer Beweis für Weiterleitungsverzögerung Hohe Laufzeit beginnt an einem Hop und bleibt danach erhöht Möglicher Engpass oder langsamer Abschnitt ab diesem Bereich Wichtig Drei Sternchen bedeuten nur, dass für diese Versuche keine erwartete ICMP-Antwort empfangen wurde. Sie beweisen nicht automatisch einen Paketverlust für normalen Anwendungsverkehr. 11. Paketverlust und Latenz mit pathping untersuchen pathping kombiniert eine Pfadermittlung mit wiederholten ICMP-Messungen zu den Zwischenstationen. Standardtest Kennzeichnung: [TEST] pathping 192.0.2.25 Ohne Namensauflösung Kennzeichnung: [TEST] pathping /n 192.0.2.25 Anzahl der Abfragen begrenzen pathping /n /q 20 192.0.2.25 Zeitabstand zwischen aufeinanderfolgenden Pings festlegen pathping /n /q 20 /p 500 192.0.2.25 Option Bedeutung /n Keine Namensauflösung der Zwischenrouter /q 20 20 Echoanforderungen pro Router /p 500 500 Millisekunden zwischen aufeinanderfolgenden Pings /w 1000 Bis zu 1000 Millisekunden auf eine Antwort warten /4 Nur IPv4 verwenden /6 Nur IPv6 verwenden Wartezeit beachten pathping benötigt deutlich länger als tracert , weil nach der Pfaderkennung über einen Zeitraum Messwerte gesammelt werden. Verlust richtig interpretieren Wenn ein Zwischenrouter bei an ihn gerichteten ICMP-Paketen Verlust zeigt, aber alle folgenden Hops und das Ziel keinen entsprechenden Verlust zeigen, ist die Weiterleitung wahrscheinlich nicht im gleichen Maß betroffen. Mögliche Erklärung: ICMP-Antworten des Routers werden begrenzt; der Router priorisiert Transitverkehr höher als eigene Diagnoseantworten; die Control Plane ist ausgelastet, während die Weiterleitung weiterhin funktioniert. Wird ein Verlust ab einem bestimmten Link angezeigt und setzt sich bis zum Ziel fort, ist dieser Abschnitt wesentlich verdächtiger. Pathping ist kein Beweis für Anwendungsleistung Der Befehl prüft ICMP. Eine TCP-, UDP-, TLS- oder Anwendungsstörung muss mit dem tatsächlichen Protokoll weiter untersucht werden. 12. Routingtabelle mit route anzeigen Gesamte Routingtabelle anzeigen Kennzeichnung: [RO][SENS] route print Die Ausgabe enthält: Interface List; IPv4-Routingtabelle; IPv6-Routingtabelle; aktive Routen; persistente Routen; Netzwerkziele; Netzmasken beziehungsweise Präfixe; Gateways; Interfaceadressen; Metriken. Routen für einen bestimmten Bereich filtern Kennzeichnung: [RO] route print 192.0.2.* Wichtige Bestandteile Spalte Bedeutung Network Destination Zielnetz oder Zielhost Netmask Netzmaske der Route Gateway Nächster Router beziehungsweise Next Hop Interface Lokale Ausgangsadresse Metric Kostenwert der Route On-link Ziel ist über das angegebene Interface direkt erreichbar Default Route erkennen Network Destination: 0.0.0.0 Netmask: 0.0.0.0 Diese Route wird verwendet, wenn keine spezifischere passende IPv4-Route vorhanden ist. Routenauswahl vereinfacht Windows berücksichtigt grundsätzlich: passende Zielpräfixe; die spezifischste passende Route; bei gleich spezifischen Routen die Metriken; die zugehörige Interfacemetrik und Routenkonfiguration. Eine Route zu 192.0.2.0/24 ist beispielsweise spezifischer als die Default Route 0.0.0.0/0 . Typische Auffälligkeiten Beobachtung Mögliche Ursache Keine Default Route Kein Gateway konfiguriert oder DHCP-Konfiguration unvollständig Mehrere Default Routes Mehrere Adapter, VPN, virtuelle Netzwerke oder fehlerhafte Konfiguration Unerwartet niedrige Metrik Datenverkehr verwendet möglicherweise den falschen Adapter Zielroute zeigt auf VPN Split-Tunnel- oder VPN-Routing relevant Spezifische Route zeigt auf falsches Gateway Statische Route oder Software hat die Pfadauswahl verändert Route ist On-link , Ziel liegt aber nicht im lokalen Segment Falsche Subnetzmaske oder Präfixlänge möglich Persistente Route unerwartet vorhanden Frühere manuelle Konfiguration oder Softwareinstallation prüfen Verändernde route-Befehle Folgende Befehle verändern die Routingtabelle und sind keine reinen Diagnosebefehle: route add route change route delete route /f route /f entfernt einen großen Teil der Routingeinträge und kann Netzwerk- sowie Remotesitzungen unterbrechen. Der Befehl darf nicht als allgemeiner Reparaturversuch verwendet werden. 13. ARP-Cache und IPv4-Nachbartabelle prüfen ARP ordnet IPv4-Adressen im lokalen Segment den zugehörigen MAC-Adressen zu. ARP-Cache aller Interfaces anzeigen Kennzeichnung: [RO][SENS] arp -a Ein bestimmtes Ziel anzeigen arp -a 192.0.2.25 Tabelle eines bestimmten Interfaces anzeigen arp -a -N Ausgabe interpretieren Typ Bedeutung dynamic Zuordnung wurde dynamisch per ARP gelernt static Zuordnung wurde statisch eingetragen oder vom System vorgegeben Kein Eintrag Ziel wurde noch nicht lokal aufgelöst, liegt nicht im lokalen Segment oder ARP-Auflösung ist fehlgeschlagen Gezielte Prüfung Zuerst das lokale Ziel ansprechen: ping 192.0.2.25 Danach ARP-Tabelle prüfen: arp -a 192.0.2.25 Wenn das Ziel im selben IPv4-Subnetz liegt, aber trotz eines Kommunikationsversuchs keine passende MAC-Adresse gelernt wird, sollten unter anderem geprüft werden: VLAN-Zuordnung; Switchport; Kabel oder WLAN; falsche Subnetzmaske; Zielsystem ausgeschaltet; ARP-Filterung; Duplicate Address; Security-Funktionen wie Dynamic ARP Inspection; virtuelle Switches und Bridges. ARP-Eintrag löschen Kennzeichnung: [PRIV][CHANGE] arp -d 192.0.2.25 Der Eintrag sollte erst gelöscht werden, nachdem sein vorheriger Zustand dokumentiert wurde. Das Löschen erzwingt bei der nächsten Kommunikation eine neue ARP-Auflösung. Es beweist jedoch nicht, warum ein vorheriger Eintrag falsch oder veraltet war. IPv6 beachten arp gilt für IPv4. IPv6 verwendet Neighbor Discovery. IPv6-Nachbarn anzeigen: netsh interface ipv6 show neighbors 14. DNS mit nslookup prüfen nslookup kann DNS-Server direkt abfragen und unterstützt einen nicht interaktiven sowie einen interaktiven Modus. Einzelnen Namen mit dem Standard-DNS-Server abfragen Kennzeichnung: [TEST][SENS] nslookup server.example.test Bestimmten DNS-Server abfragen nslookup server.example.test 192.0.2.53 So können Antworten unterschiedlicher DNS-Server miteinander verglichen werden. IPv4-A-Record abfragen nslookup -type=A server.example.test 192.0.2.53 IPv6-AAAA-Record abfragen nslookup -type=AAAA server.example.test 192.0.2.53 Mailserver abfragen nslookup -type=MX example.test 192.0.2.53 Nameserver einer Zone abfragen nslookup -type=NS example.test 192.0.2.53 TXT-Record abfragen nslookup -type=TXT example.test 192.0.2.53 SRV-Record abfragen nslookup -type=SRV _ldap._tcp.dc._msdcs.example.test 192.0.2.53 Reverse Lookup ausführen nslookup 192.0.2.25 192.0.2.53 Dabei wird nach einem PTR-Record gesucht. Interaktiven Modus starten nslookup Beispiel innerhalb des interaktiven Modus: server 192.0.2.53 set type=AAAA server.example.test exit Ausgabe interpretieren Ausgabe Bedeutung Server Verwendeter DNS-Server Address Adresse des verwendeten DNS-Servers Name Zurückgegebener kanonischer Name Addresses Zurückgegebene IP-Adressen Aliases Gefundene Aliasnamen Non-authoritative answer Antwort stammt nicht direkt vom autoritativen Server NXDOMAIN beziehungsweise „Non-existent domain“ Angefragter Name existiert laut Antwort nicht Request timed out DNS-Server antwortete innerhalb des Timeouts nicht Server failed DNS-Server meldet einen Verarbeitungsfehler Refused DNS-Server lehnt die Anfrage ab Wichtige Einschränkung Eine erfolgreiche nslookup -Abfrage beweist nicht, dass eine Anwendung denselben Namen auf dieselbe Weise auflöst. Zusätzlich relevant sein können: Windows-DNS-Clientcache; hosts-Datei; DNS-Suffixsuchliste; VPN-Namensauflösung; Split-DNS; DoH in einem Browser; Proxyauflösung; anwendungseigener DNS-Cache; NetBIOS oder LLMNR. Die Anwendung sollte deshalb anschließend ebenfalls direkt getestet werden. 15. NetBIOS-Namensauflösung mit nbtstat prüfen nbtstat ist hauptsächlich für ältere beziehungsweise weiterhin verwendete NetBIOS-over-TCP/IP-Umgebungen relevant. Lokale NetBIOS-Namenstabelle anzeigen Kennzeichnung: [RO][SENS] nbtstat /n NetBIOS-Namenscache anzeigen nbtstat /c Remote-Tabelle über den NetBIOS-Namen abfragen Kennzeichnung: [TEST][SENS] nbtstat /a Remote-Tabelle über die IPv4-Adresse abfragen nbtstat /A 192.0.2.25 Groß- und Kleinschreibung der Optionen ist hier wichtig: Option Abfrage /a Remotecomputer über NetBIOS-Namen /A Remotecomputer über IPv4-Adresse nbtstat sollte nur verwendet werden, wenn NetBIOS, WINS, ältere SMB-Namensauflösung oder eine entsprechende Legacy-Anwendung tatsächlich relevant ist. 16. Verbindungen, Listener und Ports mit netstat prüfen Aktive TCP-Verbindungen anzeigen Kennzeichnung: [RO][SENS] netstat Alle Verbindungen und Listener numerisch anzeigen netstat -an Verbindungen, Listener und Prozess-IDs anzeigen netstat -ano Bedeutung: Option Funktion -a Alle aktiven TCP-Verbindungen sowie TCP- und UDP-Listener anzeigen -n Adressen und Ports numerisch anzeigen -o Zugehörige Prozess-ID anzeigen -b Beteiligte ausführbare Datei anzeigen -e Ethernet-Statistiken anzeigen -r Routingtabelle anzeigen -s Protokollstatistiken anzeigen -p Ausgabe auf ein Protokoll begrenzen Ausführbare Programme anzeigen Kennzeichnung: [RO][PRIV][SENS] netstat -abno -b kann langsam sein und benötigt ausreichende Rechte. Nach einem Port filtern Kennzeichnung: [RO][SENS] netstat -ano | findstr ":443" Achtung Die Suche findet :443 sowohl bei lokalen als auch bei entfernten Adressen. Das Ergebnis muss anhand der Spalte Local Address beziehungsweise Foreign Address bewertet werden. Nur Listener suchen netstat -ano | findstr "LISTENING" Auf einem deutschsprachigen Windows kann die Zustandsbezeichnung lokalisiert ausgegeben werden. Für zuverlässig automatisierbare Abfragen sind die PowerShell-Cmdlets der nächsten Seite besser geeignet. Prozess zu einer PID suchen tasklist /FI "PID eq 1234" Wenn mehrere Windows-Dienste von einem gemeinsamen svchost.exe -Prozess gehostet werden: tasklist /SVC /FI "PID eq 1234" Protokollstatistiken anzeigen netstat -s Ethernet- und Protokollstatistiken anzeigen netstat -e -s Routingtabelle über netstat anzeigen netstat -r Das entspricht funktional weitgehend: route print Ausgabe regelmäßig aktualisieren netstat -ano 5 Die Ausgabe wird alle fünf Sekunden aktualisiert. Mit Strg + C wird die Wiederholung beendet. 17. TCP-Zustände interpretieren Zustand Bedeutung Diagnosehinweis LISTENING Lokaler Prozess wartet auf Verbindungen Erwarteter Dienst besitzt grundsätzlich einen Listener SYN_SENT Verbindungsanfrage wurde gesendet, passende Antwort steht aus Ziel, Firewall, Route oder Rückweg prüfen SYN_RECEIVED Anfrage wurde empfangen und beantwortet, Abschluss des Handshakes steht aus Clientantwort oder Rückweg prüfen ESTABLISHED TCP-Verbindung ist aufgebaut TCP funktioniert; Anwendung kann trotzdem fehlerhaft sein FIN_WAIT_1 Lokale Seite hat das Beenden eingeleitet Kurzzeitig normal FIN_WAIT_2 Bestätigung liegt vor, Beendigung der Gegenseite steht aus Viele dauerhafte Einträge können auf Anwendungsprobleme hindeuten CLOSE_WAIT Gegenseite hat beendet; lokale Anwendung muss noch schließen Viele dauerhafte Einträge deuten häufig auf eine nicht sauber schließende Anwendung LAST_ACK Lokale Seite wartet auf letzte Bestätigung Kurzzeitig normal TIME_WAIT Verbindung wartet vor vollständiger Freigabe Viele Einträge können bei hoher Verbindungsrate normal sein CLOSED Keine aktive TCP-Verbindung Normaler Endzustand Ein einzelner Zustand ist selten ausreichend. Entscheidend sind: Anzahl; Dauer; betroffene lokale und entfernte Endpunkte; zugehöriger Prozess; Entwicklung während der Störung; Vergleich mit einem funktionierenden System. 18. Netzwerkinterfaces mit netsh prüfen Status aller Netzwerkinterfaces anzeigen Kennzeichnung: [RO] netsh interface show interface Typische Felder: Feld Bedeutung Admin State Administrativ aktiviert oder deaktiviert State Aktueller Verbindungszustand Type Art des Interfaces Interface Name Windows-Name des Interfaces IPv4-Interfaces anzeigen netsh interface ipv4 show interfaces IPv6-Interfaces anzeigen netsh interface ipv6 show interfaces IPv4-Konfiguration anzeigen netsh interface ipv4 show config IPv4-Adressen anzeigen netsh interface ipv4 show addresses IPv4-Routen anzeigen netsh interface ipv4 show route IPv4-Nachbarn anzeigen netsh interface ipv4 show neighbors IPv6-Adressen anzeigen netsh interface ipv6 show addresses IPv6-Routen anzeigen netsh interface ipv6 show route IPv6-Nachbarn anzeigen netsh interface ipv6 show neighbors Subinterfaces und MTU anzeigen netsh interface ipv4 show subinterfaces Diese Ausgabe ist unter anderem für folgende Probleme hilfreich: falsche MTU; VPN- oder Tunnelinterface; mehrere aktive Adapter; unerwartete Interface-Metrik; falsche Nachbarzuordnung; IPv4 funktioniert, IPv6 nicht; Datenverkehr verwendet ein virtuelles Interface. 19. WLAN mit netsh untersuchen Aktuelle WLAN-Verbindung anzeigen Kennzeichnung: [RO][SENS] netsh wlan show interfaces Mögliche Angaben: Name des WLAN-Interfaces; Beschreibung und Treiber; Status; SSID; BSSID; verwendeter Funkstandard; Authentifizierung; Verschlüsselung; Kanal; Empfangs- und Senderate; Signalstärke; Profilname. WLAN-Treiber und Fähigkeiten anzeigen netsh wlan show drivers Damit lassen sich unter anderem prüfen: unterstützte Funktypen; unterstützte Authentifizierungsverfahren; unterstützte Verschlüsselungsverfahren; Treiberversion; Hersteller; Datum des Treibers; unterstützte WLAN-Funktionen. Sichtbare WLANs anzeigen Kennzeichnung: [TEST][SENS] netsh wlan show networks Sichtbare WLANs einschließlich BSSIDs anzeigen netsh wlan show networks mode=bssid Damit können unter anderem verglichen werden: SSID; BSSID des Access Points; Signalstärke; Kanal; Authentifizierung; Verschlüsselung; mehrere Access Points derselben SSID. Gespeicherte WLAN-Profile anzeigen Kennzeichnung: [RO][SENS] netsh wlan show profiles Bestimmtes WLAN-Profil anzeigen netsh wlan show profile name="" Die Liste gespeicherter SSIDs kann sensible Informationen über Standorte oder interne Netzwerknamen enthalten. WLAN-Bericht erzeugen Kennzeichnung: [FILE][SENS] netsh wlan show wlanreport Windows erzeugt einen HTML-Bericht und zeigt den Speicherort in der Ausgabe an. Der Bericht kann Informationen enthalten über: WLAN-Sitzungen; Verbindungsabbrüche; Verbindungsdauer; Fehlergründe; Netzwerkadapter; Treiber; gespeicherte oder verwendete Netzwerke; Systemereignisse. Der Bericht ist als sensible Diagnosedatei zu behandeln. Typische WLAN-Auffälligkeiten Beobachtung Mögliche Ursache Interface State ist disconnected Keine WLAN-Verbindung aktiv Unerwartete SSID Client ist mit dem falschen Netz verbunden Unerwartete BSSID Verbindung mit anderem Access Point als erwartet Niedrige Signalstärke Entfernung, Dämpfung, Antenne oder ungünstiger Standort Niedrige Datenrate Schlechte Funkbedingungen, alter Standard oder Störung Stark schwankendes Signal Bewegung, Interferenz, Roaming oder Treiberproblem Überfüllter Kanal Co-Channel-Interference möglich Profil vorhanden, Verbindung scheitert Authentifizierung, Zertifikat, Schlüssel oder Richtlinie prüfen WLAN verbunden, aber APIPA WLAN-Assoziierung funktioniert, DHCP jedoch möglicherweise nicht 20. Proxykonfiguration prüfen WinHTTP-Proxy anzeigen Kennzeichnung: [RO][SENS] netsh winhttp show proxy Der Befehl zeigt die Proxykonfiguration für Anwendungen und Dienste an, die WinHTTP verwenden. Mögliche Ausgaben: direkter Zugriff ohne Proxy; Proxyserver; Proxyport; Bypass-Liste. Wichtige Einschränkung Die WinHTTP-Konfiguration ist nicht automatisch identisch mit: Browser-Proxyeinstellungen; benutzerspezifischen Systemeinstellungen; PAC-Dateien; Proxykonfiguration einer Anwendung; Umgebungsvariablen; VPN- oder Security-Agent-Konfigurationen. Ein funktionierender Browser beweist daher nicht, dass ein Windows-Dienst mit WinHTTP ebenfalls den richtigen Proxy verwendet. Nicht ungeprüft ausführen Folgende Befehle verändern die Proxykonfiguration: netsh winhttp set proxy netsh winhttp reset proxy netsh winhttp import proxy Sie benötigen eine begründete Änderung, eine dokumentierte Ausgangskonfiguration und einen Rückfallplan. 21. Windows-Firewallstatus prüfen Status aller Firewallprofile anzeigen Kennzeichnung: [RO] netsh advfirewall show allprofiles state Aktuelles Firewallprofil anzeigen netsh advfirewall show currentprofile Firewallrichtlinie des aktuellen Profils anzeigen netsh advfirewall show currentprofile firewallpolicy Protokollierung des aktuellen Profils anzeigen netsh advfirewall show currentprofile logging Zu prüfen sind: aktives Profil; Firewallstatus; Standardaktion für eingehende Verbindungen; Standardaktion für ausgehende Verbindungen; Protokollierung verworfener Verbindungen; Speicherort des Firewalllogs; Gruppenrichtlinien oder zentrale Verwaltung. Firewall nicht pauschal deaktivieren Das vollständige Ausschalten der Firewall ist kein geeigneter erster Diagnosetest. Besser: betroffenes Profil feststellen; Richtung bestimmen; Protokoll und Port bestimmen; lokale und entfernte Adresse bestimmen; passende Regeln und Logs prüfen; nur bei Freigabe eine eng begrenzte temporäre Testregel verwenden; Testregel anschließend wieder entfernen. 22. Diagnoseausgaben sichern IP-Konfiguration exportieren Kennzeichnung: [RO][FILE][SENS] ipconfig /all > "\ipconfig-all.txt" Routingtabelle exportieren route print > "\route-print.txt" ARP-Tabelle exportieren arp -a > "\arp-cache.txt" Verbindungen und Listener exportieren netstat -ano > "\netstat-ano.txt" Pfadtest exportieren Kennzeichnung: [TEST][FILE][SENS] tracert /d 192.0.2.25 > "\tracert.txt" Standardausgabe und Fehlermeldungen gemeinsam sichern pathping /n 192.0.2.25 > "\pathping.txt" 2>&1 An eine vorhandene Datei anhängen ipconfig /all >> "\netzdiagnose.txt" Bedeutung: Operator Wirkung > Datei neu erstellen beziehungsweise vorhandenen Inhalt überschreiben >> Ausgabe an vorhandene Datei anhängen 2>&1 Fehlermeldungen zusammen mit der Standardausgabe umleiten Vor dem Überschreiben einer vorhandenen Diagnosedatei muss geprüft werden, ob sie noch benötigt wird. 23. Kompakter Erfassungsblock Die folgenden Befehle verändern keine Netzwerkkonfiguration. Die Ausgabe kann jedoch sensible Informationen enthalten. hostname getmac /v ipconfig /all route print arp -a netstat -ano netsh interface show interface netsh interface ipv4 show neighbors netsh interface ipv6 show neighbors netsh winhttp show proxy netsh advfirewall show allprofiles state Bei WLAN-Systemen zusätzlich: netsh wlan show interfaces netsh wlan show drivers netsh wlan show profiles Diese Sammlung ist nur eine Bestandsaufnahme. Sie ersetzt keine gezielte Bewertung der Ergebnisse. 24. Diagnosepfade für häufige Fehlerbilder Fehlerbild: Keine Netzwerkverbindung netsh interface show interface ipconfig /all route print arp -a Prüfen: Adapter administrativ aktiviert? Medium verbunden? gültige IP-Adresse? Standardgateway vorhanden? DNS-Server vorhanden? APIPA-Adresse? passende Route vorhanden? Fehlerbild: IP-Adresse vorhanden, aber kein Internet ipconfig /all ping ping /4 nslookup tracert /d netsh winhttp show proxy netsh advfirewall show currentprofile Auswertung: Ergebnis Verdächtiger Bereich Gateway nicht erreichbar lokales Netz, VLAN, WLAN, Kabel oder Gateway Gateway erreichbar, externe IP nicht Routing, Firewall, NAT oder Provider Externe IP erreichbar, Name nicht DNS Name und IP erreichbar, Anwendung nicht Port, TLS, Proxy oder Anwendung Nur Dienst verwendet keinen Internetzugriff WinHTTP-Proxy, Dienstkonto oder Firewall Fehlerbild: DNS funktioniert nicht ipconfig /all ipconfig /displaydns nslookup server.example.test nslookup server.example.test 192.0.2.53 ping /4 server.example.test ping /6 server.example.test Prüfen: korrekte DNS-Server? antworten alle eingetragenen DNS-Server? unterschiedliche Antworten je DNS-Server? A- und AAAA-Record korrekt? negativer Cacheeintrag? falsches DNS-Suffix? Split-DNS oder VPN relevant? hosts-Datei oder Anwendungscache relevant? Fehlerbild: Ein lokaler Dienst ist nicht erreichbar netstat -ano | findstr ":443" tasklist /FI "PID eq " netsh advfirewall show currentprofile Prüfen: existiert ein LISTENING -Eintrag? lauscht der Dienst auf der erwarteten Adresse? lauscht er nur auf 127.0.0.1 oder ::1 ? stimmt der Port? stimmt die PID mit dem erwarteten Prozess überein? ist die Firewallregel für das aktive Profil gültig? Der Test eines entfernten TCP-Ports folgt auf der nächsten Seite mit Test-NetConnection . Fehlerbild: Verbindung ist langsam oder instabil ping /n 50 ping /n 50 tracert /d pathping /n netstat -e -s Bei WLAN zusätzlich: netsh wlan show interfaces netsh wlan show networks mode=bssid netsh wlan show wlanreport Prüfen: Verlust bereits zum Gateway? nur entferntes Ziel betroffen? steigende Latenz ab bestimmtem Abschnitt? schwankendes WLAN-Signal? Kanal oder BSSID wechseln? Fehlerzähler steigen während der Störung? ist nur ICMP oder auch die Anwendung betroffen? Fehlerbild: Nur IPv4 oder nur IPv6 funktioniert ipconfig /all ping /4 server.example.test ping /6 server.example.test tracert /4 server.example.test tracert /6 server.example.test route print netsh interface ipv4 show route netsh interface ipv6 show route netsh interface ipv6 show neighbors Prüfen: A- und AAAA-Record vorhanden? IPv6-Adresse außer Link-Local vorhanden? IPv6-Default-Route vorhanden? Router Advertisements funktionieren? VPN oder Firewall behandelt IPv4 und IPv6 unterschiedlich? Anwendung bevorzugt einen nicht funktionierenden IPv6-Pfad? 25. Typische Fehlinterpretationen Fehlinterpretation Richtige Bewertung Ping funktioniert, also funktioniert das Netzwerk vollständig Ping prüft nur eine bestimmte ICMP-Kommunikation Ping funktioniert nicht, also ist das Ziel ausgeschaltet ICMP kann gefiltert oder begrenzt sein Sternchen bei tracert bedeuten Paketverlust Der Router hat möglicherweise nur keine ICMP-Antwort gesendet Verlust an einem pathping-Zwischenhop beweist einen defekten Router Entscheidend ist, ob sich der Verlust bis zum Ziel fortsetzt nslookup funktioniert, also funktioniert DNS für jede Anwendung Anwendungen können andere Resolverpfade, Caches oder Proxys verwenden Eine ARP-Tabelle zeigt alle erreichbaren Systeme Sie enthält nur bereits gelernte oder statische lokale IPv4-Nachbarn ESTABLISHED bedeutet, dass die Anwendung funktioniert Es beweist nur eine aufgebaute TCP-Verbindung Viele TIME_WAIT -Einträge sind automatisch ein Fehler Sie können bei hoher normaler Verbindungsrate entstehen 169.254.x.x bedeutet defekte Netzwerkkarte Es weist normalerweise auf automatische Adressierung ohne verwendbare DHCP-Konfiguration hin Mehrere Gateways sind automatisch redundant Sie können zu unerwarteter Routenauswahl führen Firewall ausschalten ist der schnellste Test Das erzeugt ein Sicherheitsrisiko und liefert oft keine saubere Ursachenanalyse DNS-Cache sofort leeren hilft immer Dabei kann der ursprüngliche Fehlerzustand verloren gehen 26. Befehle mit besonderer Vorsicht Befehl Kennzeichnung Risiko ipconfig /release [CHANGE][DISRUPT] Entfernt die aktuelle DHCP-Konfiguration ipconfig /renew [TEST][CHANGE] Verändert die aktuelle DHCP-Konfiguration ipconfig /flushdns [CHANGE] Entfernt den DNS-Clientcache und mögliche Beweise ipconfig /registerdns [TEST][CHANGE] Stößt dynamische DNS-Registrierungen an arp -d [PRIV][CHANGE] Entfernt eine Nachbarzuordnung route add [PRIV][CHANGE] Fügt eine Route hinzu route change [PRIV][CHANGE] Verändert eine Route route delete [PRIV][CHANGE][DISRUPT] Entfernt eine Route route /f [PRIV][CHANGE][DISRUPT] Entfernt einen großen Teil der Routingtabelle netsh interface set ... [PRIV][CHANGE][DISRUPT] Verändert Interfacekonfiguration netsh winhttp reset proxy [PRIV][CHANGE] Entfernt die WinHTTP-Proxykonfiguration netsh advfirewall set ... [PRIV][CHANGE][DISRUPT] Verändert Firewallrichtlinien netsh wlan disconnect [CHANGE][DISRUPT] Trennt eine WLAN-Verbindung netsh wlan delete profile [PRIV][CHANGE] Löscht ein gespeichertes WLAN-Profil Vor diesen Befehlen müssen Ausgangszustand, Auswirkung und Rückfallplan dokumentiert werden. 27. Grenzen der klassischen Windows-Befehle Die klassischen Befehle sind schnell verfügbar und eignen sich gut für eine erste Diagnose. Sie haben jedoch einige Einschränkungen: Ausgaben sind teilweise sprachabhängig; Textausgaben sind für Automatisierung schlechter geeignet; komplexe Filterungen sind umständlich; IPv4- und IPv6-Informationen sind teilweise getrennt; strukturierte Weiterverarbeitung ist begrenzt; ein beliebiger entfernter TCP-Port lässt sich mit den klassischen Grundbefehlen nicht so bequem testen; mehrere Adapter und Routen sind in Textausgaben schwerer vergleichbar. Für strukturierte und gezielte Windows-Diagnosen folgt deshalb: 2.2 PowerShell-Netzwerkdiagnose Quellen und weiterführende Dokumentation Microsoft Learn – hostname : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/hostname Microsoft Learn – getmac : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/getmac Microsoft Learn – ipconfig : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig Microsoft Learn – Automatic Private IP Addressing: https://learn.microsoft.com/en-us/windows-server/troubleshoot/how-to-use-automatic-tcpip-addressing-without-a-dh Microsoft Learn – ping : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping Microsoft Learn – tracert : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert Microsoft Learn – pathping : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping Microsoft Learn – route : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/route_ws2008 Microsoft Learn – arp : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp Microsoft Learn – nslookup : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup Microsoft Learn – nbtstat : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nbtstat Microsoft Learn – netstat : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat Microsoft Learn – TCP-Zustände: https://learn.microsoft.com/en-us/windows/win32/api/mstcpip/ne-mstcpip-tcpstate Microsoft Learn – tasklist : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tasklist Microsoft Learn – findstr : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/findstr Microsoft Learn – Network Shell netsh : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh Microsoft Learn – netsh interface : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-interface Microsoft Learn – netsh wlan : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan Microsoft Learn – netsh winhttp : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-winhttp Microsoft Learn – netsh advfirewall : https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-advfirewall 2.2 PowerShell-Netzwerkdiagnose PowerShell stellt Netzwerkdaten als strukturierte Objekte bereit. Dadurch lassen sich Informationen gezielt filtern, sortieren, vergleichen und exportieren. Die Cmdlets dieser Seite gehören zu Windows-Modulen wie NetAdapter , NetTCPIP , DnsClient und NetSecurity . Sie sind für die Netzwerkdiagnose unter Windows vorgesehen. Kennzeichnungen Kennzeichnung Bedeutung [RO] Nur lesender Befehl; verändert keine Konfiguration [TEST] Führt einen aktiven Netzwerk- oder Verbindungstest aus [PRIV] Benötigt möglicherweise eine PowerShell mit Administratorrechten [CHANGE] Verändert einen Zustand oder eine Konfiguration [DISRUPT] Kann eine bestehende Verbindung oder einen Dienst unterbrechen [FILE] Schreibt Informationen in eine Datei [SENS] Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten Für die erste Diagnose möglichst mit [RO] -Befehlen beginnen. Veränderungen sollten erst erfolgen, wenn die Ursache ausreichend eingegrenzt und eine Rückfallmöglichkeit vorhanden ist. 1. PowerShell und benötigte Netzwerkmodule prüfen Bevor ein Cmdlet verwendet wird, sollte geprüft werden, welche PowerShell-Version und welche Windows-Netzwerkmodule vorhanden sind. Aufgabe PowerShell-Befehl PowerShell-Version anzeigen [RO] $PSVersionTable Betriebssysteminformationen anzeigen [RO] Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber Netzwerkmodule suchen [RO] Get-Module -ListAvailable NetAdapter, NetTCPIP, DnsClient, NetSecurity Befehle eines Moduls auflisten [RO] Get-Command -Module NetTCPIP Hilfe zu einem Cmdlet anzeigen [RO] Get-Help Test-NetConnection -Full Verwendungsbeispiele anzeigen [RO] Get-Help Resolve-DnsName -Examples Syntax eines Cmdlets anzeigen [RO] Get-Command Get-NetAdapter -Syntax Typische Fehler Meldung oder Beobachtung Mögliche Bedeutung The term ... is not recognized Cmdlet oder Modul ist nicht vorhanden beziehungsweise nicht geladen Access denied Administratorrechte oder zusätzliche Berechtigungen erforderlich Keine Ausgabe Filter ist möglicherweise zu eng oder es existiert kein passendes Objekt Einzelne Eigenschaften fehlen Unterschiedliche Windows-, PowerShell- oder Modulversion 2. Netzwerkadapter und Verbindungsstatus prüfen Get-NetAdapter zeigt physische und virtuelle Netzwerkadapter einschließlich Status, Geschwindigkeit, MAC-Adresse und Schnittstellenindex. Aufgabe PowerShell-Befehl Alle sichtbaren Netzwerkadapter anzeigen [RO] Get-NetAdapter Auch ausgeblendete Adapter anzeigen [RO] Get-NetAdapter -IncludeHidden Wichtige Eigenschaften auswählen [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex Nur aktive Adapter anzeigen [RO] Get-NetAdapter | Where-Object Status -eq "Up" Nicht aktive Adapter anzeigen [RO] Get-NetAdapter | Where-Object Status -ne "Up" Adapter nach Status gruppieren [RO] Get-NetAdapter -IncludeHidden | Group-Object Status Detailinformationen eines Adapters anzeigen [RO] Get-NetAdapter -Name "Ethernet" | Format-List * Adapterstatistik anzeigen [RO] Get-NetAdapterStatistics Fehler- und Verwerfungszähler anzeigen [RO] Get-NetAdapterStatistics | Select-Object Name, ReceivedPacketErrors, OutboundPacketErrors, ReceivedDiscardedPackets, OutboundDiscardedPackets Treiberinformationen anzeigen [RO] Get-NetAdapter | Select-Object Name, DriverDescription, DriverVersion, DriverDate Verbindungstyp und Netzwerkprofil anzeigen [RO] Get-NetConnectionProfile Wichtige Eigenschaften Eigenschaft Bedeutung Status Betriebszustand des Adapters LinkSpeed Ausgehandelte Verbindungsgeschwindigkeit MacAddress Hardwareadresse des Netzwerkadapters ifIndex Schnittstellenindex für weitere Cmdlets ReceivedPacketErrors Fehlerhaft empfangene Pakete OutboundPacketErrors Fehler beim Senden ReceivedDiscardedPackets Empfangene, aber verworfene Pakete OutboundDiscardedPackets Zu sendende, aber verworfene Pakete Hinweise zur Auswertung Status = Up bedeutet nur, dass der Adapter aktiv und eine Verbindung erkannt wurde. Ein aktiver Adapter bestätigt nicht automatisch eine funktionierende IP-Konfiguration. Eine unerwartet niedrige LinkSpeed kann auf Kabel-, Port-, Treiber- oder Aushandlungsprobleme hinweisen. Steigende Fehler- oder Verwerfungszähler können auf Treiberprobleme, Überlastung oder eine gestörte Verbindung hinweisen. Virtuelle Adapter von VPN-, Hyper-V-, Container- oder Sicherheitssoftware müssen von physischen Adaptern unterschieden werden. 3. IP-Konfiguration vollständig erfassen Get-NetIPConfiguration liefert eine zusammengefasste Ansicht der IP-Konfiguration. Für einzelne Eigenschaften stehen zusätzliche Cmdlets zur Verfügung. Aufgabe PowerShell-Befehl Aktive IP-Konfiguration anzeigen [RO] Get-NetIPConfiguration Alle IP-Konfigurationen anzeigen [RO] Get-NetIPConfiguration -All Ausführliche Ausgabe erzeugen [RO] Get-NetIPConfiguration -All | Format-List * IPv4-Adressen anzeigen [RO] Get-NetIPAddress -AddressFamily IPv4 IPv6-Adressen anzeigen [RO] Get-NetIPAddress -AddressFamily IPv6 Verwendbare IPv4-Adressen anzeigen [RO] Get-NetIPAddress -AddressFamily IPv4 | Where-Object AddressState -eq "Preferred" Loopback- und APIPA-Adressen ausblenden [RO] Get-NetIPAddress -AddressFamily IPv4 | Where-Object { $_.IPAddress -notlike "127.*" -and $_.IPAddress -notlike "169.254.*" } IP-Schnittstellen anzeigen [RO] Get-NetIPInterface IPv4-Schnittstellen nach Metrik sortieren [RO] Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric Standardgateways anzeigen [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" DNS-Serveradressen anzeigen [RO] Get-DnsClientServerAddress Nur IPv4-DNS-Server anzeigen [RO] Get-DnsClientServerAddress -AddressFamily IPv4 DHCP-Status anzeigen [RO] Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, Dhcp, ConnectionState Wichtige Prüfpunkte Prüffeld Erwartung beziehungsweise Fehlerhinweis IP-Adresse Muss zum vorgesehenen Netzwerk passen Präfixlänge Muss zur Netzmaske des Netzwerks passen Standardgateway Muss im Regelfall aus dem lokalen Netz erreichbar sein DNS-Server Muss erreichbar und für die benötigten Zonen zuständig sein DHCP Muss zur vorgesehenen statischen oder dynamischen Konfiguration passen InterfaceMetric Niedrigerer Wert wird bei konkurrierenden Schnittstellen bevorzugt 169.254.x.x Kann auf eine fehlgeschlagene DHCP-Zuweisung hinweisen Mehrere Standardrouten Können zu einem unerwarteten Verbindungsweg führen Kompakte Bestandsaufnahme Get-NetIPConfiguration -All | Select-Object InterfaceAlias, InterfaceDescription, NetProfile, IPv4Address, IPv6Address, IPv4DefaultGateway, DNSServer 4. Erreichbarkeit und TCP-Ports testen Test-NetConnection kombiniert mehrere klassische Netzwerkprüfungen und liefert strukturierte Ergebnisse. Aufgabe PowerShell-Befehl Grundlegende Erreichbarkeit testen [TEST] Test-NetConnection 192.0.2.10 Detaillierte Ausgabe anzeigen [TEST] Test-NetConnection 192.0.2.10 -InformationLevel Detailed Standardgateway testen [TEST] Test-NetConnection 192.0.2.1 -InformationLevel Detailed Internet-IP testen [TEST] Test-NetConnection 1.1.1.1 -InformationLevel Detailed HTTPS-Port testen [TEST] Test-NetConnection example.com -Port 443 -InformationLevel Detailed SSH-Port testen [TEST] Test-NetConnection 192.0.2.10 -Port 22 -InformationLevel Detailed RDP-Port testen [TEST] Test-NetConnection 192.0.2.10 -Port 3389 -InformationLevel Detailed SMB-Port testen [TEST] Test-NetConnection 192.0.2.10 -Port 445 -InformationLevel Detailed Routenverfolgung durchführen [TEST] Test-NetConnection example.com -TraceRoute Nur boolesches Testergebnis ausgeben [TEST] Test-NetConnection example.com -Port 443 -InformationLevel Quiet Die Adressen 192.0.2.0/24 , 198.51.100.0/24 und 203.0.113.0/24 sind Dokumentationsnetze. Sie müssen in echten Prüfungen durch die tatsächlichen Zieladressen ersetzt werden. Wichtige Ergebnisfelder Eigenschaft Bedeutung ComputerName Angegebenes Ziel RemoteAddress Aufgelöste Zieladresse NameResolutionResults Ergebnisse der Namensauflösung SourceAddress Verwendete lokale Quelladresse InterfaceAlias Verwendete Netzwerkschnittstelle NetRoute Ausgewählte Route PingSucceeded Ergebnis des ICMP-Tests TcpTestSucceeded Ergebnis des TCP-Verbindungsversuchs RemotePort Getesteter Zielport Interpretation Ergebnis Mögliche Bedeutung PingSucceeded = False , TCP-Test erfolgreich ICMP wird möglicherweise blockiert; der getestete Dienst ist trotzdem erreichbar Namensauflösung schlägt fehl, IP-Test funktioniert DNS-Problem wahrscheinlich Gateway erreichbar, externes Ziel nicht erreichbar Routing, Firewall, Provider oder Upstream-System prüfen IP-Adresse erreichbar, TCP-Port nicht erreichbar Dienst, Zielport oder Firewall prüfen Falsches InterfaceAlias Routingmetrik, VPN oder mehrere aktive Adapter prüfen Falsche SourceAddress IP-Konfiguration oder Routenauswahl prüfen 5. DNS-Auflösung gezielt untersuchen Resolve-DnsName erlaubt präzisere DNS-Abfragen als ein einfacher Verbindungstest. Aufgabe PowerShell-Befehl Namen mit Standardeinstellungen auflösen [TEST] Resolve-DnsName example.com Nur DNS verwenden [TEST] Resolve-DnsName example.com -DnsOnly IPv4-Adresse abfragen [TEST] Resolve-DnsName example.com -Type A -DnsOnly IPv6-Adresse abfragen [TEST] Resolve-DnsName example.com -Type AAAA -DnsOnly Mailserver abfragen [TEST] Resolve-DnsName example.com -Type MX -DnsOnly Nameserver abfragen [TEST] Resolve-DnsName example.com -Type NS -DnsOnly TXT-Einträge abfragen [TEST] Resolve-DnsName example.com -Type TXT -DnsOnly Reverse-DNS-Abfrage durchführen [TEST] Resolve-DnsName 192.0.2.10 -Type PTR -DnsOnly Bestimmten DNS-Server verwenden [TEST] Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly Nur lokalen DNS-Cache abfragen [RO] Resolve-DnsName example.com -CacheOnly DNS-Cache anzeigen [RO] Get-DnsClientCache Cache nach einem Namen durchsuchen [RO] Get-DnsClientCache | Where-Object Entry -like "*example.com*" Konfigurierte DNS-Server anzeigen [RO] Get-DnsClientServerAddress DNS-Clientkonfiguration anzeigen [RO] Get-DnsClient DNS-Vergleichstest Resolve-DnsName example.com -DnsOnly Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly Auswertung Beobachtung Mögliche Ursache Interner DNS-Server antwortet nicht DNS-Dienst, Firewall, Routing oder Erreichbarkeit prüfen Externer DNS-Server funktioniert, interner nicht Problem wahrscheinlich beim internen Resolver Interne Namen funktionieren extern nicht Normal, wenn die Zone nur intern vorhanden ist Unterschiedliche Antworten verschiedener Resolver Split-DNS, Cache, Replikationsverzug oder unterschiedliche Zonen NXDOMAIN Name existiert aus Sicht des verwendeten DNS-Servers nicht SERVFAIL DNS-Server konnte die Anfrage nicht erfolgreich verarbeiten Timeout DNS-Server nicht erreichbar, blockiert oder zu langsam Auflösung funktioniert nur aus dem Cache Aktuelle DNS-Kommunikation möglicherweise gestört Öffentliche DNS-Server dürfen nicht unüberlegt zum Test interner Namen verwendet werden. Interne Hostnamen, Domänennamen und Strukturen können sensible Informationen darstellen. 6. Routing und ausgewählten Netzwerkweg prüfen Aufgabe PowerShell-Befehl Gesamte Routingtabelle anzeigen [RO] Get-NetRoute IPv4-Routen anzeigen [RO] Get-NetRoute -AddressFamily IPv4 IPv6-Routen anzeigen [RO] Get-NetRoute -AddressFamily IPv6 Standardroute anzeigen [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" Routen nach Metrik sortieren [RO] Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric Route einer Schnittstelle anzeigen [RO] Get-NetRoute -InterfaceAlias "Ethernet" Wahrscheinlich verwendete Route bestimmen [RO] Find-NetRoute -RemoteIPAddress 1.1.1.1 Schnittstellenmetriken anzeigen [RO] Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric Routenverfolgung durchführen [TEST] Test-NetConnection example.com -TraceRoute Wichtige Eigenschaften Eigenschaft Bedeutung DestinationPrefix Zielnetz der Route NextHop Nächster Router beziehungsweise Gateway InterfaceAlias Verwendete Netzwerkschnittstelle RouteMetric Metrik der einzelnen Route InterfaceMetric Metrik der Schnittstelle Publish Gibt an, ob die Route veröffentlicht wird Protocol Herkunft beziehungsweise Routingprotokoll der Route Typische Fehlerbilder Mehrere Standardrouten konkurrieren miteinander. Ein VPN installiert eine bevorzugte Route. Eine Route verwendet den falschen Adapter. Das Standardgateway befindet sich nicht im erwarteten lokalen Netz. Eine spezifischere Route überschreibt die allgemeine Standardroute. Eine niedrige Metrik führt zu einem unerwarteten Netzwerkweg. 7. ARP- und IPv6-Nachbartabelle prüfen Get-NetNeighbor zeigt bekannte Nachbarn auf direkt angeschlossenen Netzen. Bei IPv4 entspricht dies funktional weitgehend der ARP-Tabelle; bei IPv6 werden Einträge des Neighbor Discovery Protocols angezeigt. Aufgabe PowerShell-Befehl Gesamte Nachbartabelle anzeigen [RO] Get-NetNeighbor IPv4-Nachbarn anzeigen [RO] Get-NetNeighbor -AddressFamily IPv4 IPv6-Nachbarn anzeigen [RO] Get-NetNeighbor -AddressFamily IPv6 Nachbarn eines Adapters anzeigen [RO] Get-NetNeighbor -InterfaceAlias "Ethernet" Einträge nach Zustand sortieren [RO] Get-NetNeighbor | Sort-Object State, InterfaceAlias Bestimmte IP-Adresse suchen [RO] Get-NetNeighbor -IPAddress 192.0.2.10 Erreichbare Einträge anzeigen [RO] Get-NetNeighbor | Where-Object State -eq "Reachable" Unvollständige Einträge anzeigen [RO] Get-NetNeighbor | Where-Object State -eq "Incomplete" Wichtige Zustände Zustand Bedeutung Reachable Nachbar wurde kürzlich erfolgreich erreicht Stale Eintrag ist vorhanden, wurde aber länger nicht bestätigt Delay Erreichbarkeitsprüfung wird verzögert Probe Aktive Erreichbarkeitsprüfung läuft Incomplete Adressauflösung konnte noch nicht abgeschlossen werden Permanent Statischer beziehungsweise dauerhafter Eintrag Fehlerhinweise Incomplete kann auf ein nicht erreichbares Ziel, falsches VLAN, Layer-2-Probleme oder eine falsche IP-Konfiguration hinweisen. Wechselnde MAC-Adressen zu derselben IP-Adresse können auf doppelte IP-Adressen, Hochverfügbarkeit oder Sicherheitsprobleme hinweisen. Kein Eintrag bedeutet nicht automatisch einen Fehler. Möglicherweise wurde das Ziel noch nicht angesprochen oder befindet sich nicht im lokalen Netz. 8. TCP-Verbindungen, offene Ports und Prozesse untersuchen Get-NetTCPConnection zeigt lokale TCP-Endpunkte und bestehende TCP-Verbindungen. Aufgabe PowerShell-Befehl Alle TCP-Verbindungen anzeigen [RO] Get-NetTCPConnection Lauschende TCP-Ports anzeigen [RO] Get-NetTCPConnection -State Listen Bestehende Verbindungen anzeigen [RO] Get-NetTCPConnection -State Established Verbindungen zu einem Zielport suchen [RO] Get-NetTCPConnection -RemotePort 443 Lokalen Port untersuchen [RO] Get-NetTCPConnection -LocalPort 443 Nach Zustand gruppieren [RO] Get-NetTCPConnection | Group-Object State Verbindungen sortiert anzeigen [RO] Get-NetTCPConnection | Sort-Object State, LocalPort UDP-Endpunkte anzeigen [RO] Get-NetUDPEndpoint Prozess über PID ermitteln [RO] Get-Process -Id 1234 Lauschende Ports mit Prozessnamen anzeigen Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess, @{ Name = "ProcessName" Expression = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName } } | Sort-Object LocalPort Bestehende Verbindungen mit Prozessnamen anzeigen Get-NetTCPConnection -State Established | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess, @{ Name = "ProcessName" Expression = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName } } Interpretation Beobachtung Mögliche Bedeutung Erwarteter Port fehlt im Zustand Listen Dienst läuft nicht, lauscht auf anderem Port oder konnte den Port nicht binden Port lauscht nur auf 127.0.0.1 Dienst ist nur lokal erreichbar Port lauscht auf 0.0.0.0 Dienst lauscht grundsätzlich auf allen IPv4-Schnittstellen Port lauscht auf :: Dienst lauscht grundsätzlich auf IPv6 und möglicherweise abhängig von der Anwendung auch auf IPv4 Viele Verbindungen im Zustand SYN_SENT Ziel, Route, Dienst oder Firewall antwortet möglicherweise nicht Viele Verbindungen im Zustand TIME_WAIT Kann bei vielen kurzlebigen TCP-Verbindungen normal sein Unerwarteter Prozess lauscht auf einem Port Dienstzuordnung und Sicherheitslage prüfen Eine Verbindung im Zustand Listen bestätigt nur, dass lokal ein Prozess auf dem Port wartet. Sie bestätigt nicht, dass der Port aus einem anderen Netz erreichbar ist. 9. Windows-Firewall diagnostizieren Die Firewall sollte zunächst nur ausgelesen werden. Ein vollständiges Abschalten der Firewall ist kein geeigneter erster Diagnoseschritt. Aufgabe PowerShell-Befehl Firewallprofile anzeigen [RO] Get-NetFirewallProfile Status der Profile kompakt anzeigen [RO] Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction Aktivierte Regeln anzeigen [RO] Get-NetFirewallRule -Enabled True Aktivierte Blockierungsregeln anzeigen [RO] Get-NetFirewallRule -Enabled True -Action Block Eingehende Regeln anzeigen [RO] Get-NetFirewallRule -Direction Inbound Regel anhand des Anzeigenamens suchen [RO] Get-NetFirewallRule -DisplayName "*Remote Desktop*" Portfilter anzeigen [RO] Get-NetFirewallPortFilter Regeln für lokalen Port 443 suchen [RO] Get-NetFirewallPortFilter | Where-Object LocalPort -eq 443 | Get-NetFirewallRule Regeln für TCP-Port 445 suchen [RO] Get-NetFirewallPortFilter | Where-Object { $_.Protocol -eq "TCP" -and $_.LocalPort -eq 445 } | Get-NetFirewallRule Adressfilter einer Regel anzeigen [RO] Get-NetFirewallRule -DisplayName "REGELNAME" | Get-NetFirewallAddressFilter Portfilter einer Regel anzeigen [RO] Get-NetFirewallRule -DisplayName "REGELNAME" | Get-NetFirewallPortFilter Anwendungsfilter einer Regel anzeigen [RO] Get-NetFirewallRule -DisplayName "REGELNAME" | Get-NetFirewallApplicationFilter Warum zeigt Get-NetFirewallRule nicht alle Ports und Adressen direkt an? Windows speichert Bedingungen wie Ports, Programme und Adressen in zugeordneten Filterobjekten. Deshalb werden für eine vollständige Analyse zusätzlich folgende Cmdlets verwendet: Get-NetFirewallPortFilter Get-NetFirewallAddressFilter Get-NetFirewallApplicationFilter Get-NetFirewallServiceFilter Get-NetFirewallInterfaceFilter Sinnvolle Prüfreihenfolge Aktives Netzwerkprofil mit Get-NetConnectionProfile feststellen. Firewallstatus des Profils mit Get-NetFirewallProfile prüfen. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht. Passende eingehende oder ausgehende Regel suchen. Port-, Adress-, Programm- und Profilfilter der Regel prüfen. Verbindung von einem autorisierten Testsystem aus testen. Die Firewall nicht pauschal deaktivieren. Dadurch verändert sich die Sicherheitslage und das Testergebnis bildet die ursprüngliche Konfiguration nicht mehr korrekt ab. 10. Diagnoseausgaben filtern, vergleichen und exportieren PowerShell-Ausgaben bestehen aus Objekten. Die Filterung sollte deshalb möglichst vor der Formatierung erfolgen. Aufgabe PowerShell-Befehl Bestimmte Eigenschaften auswählen [RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed Objekte filtern [RO] Get-NetAdapter | Where-Object Status -ne "Up" Ergebnisse sortieren [RO] Get-NetRoute | Sort-Object RouteMetric Ergebnisse gruppieren [RO] Get-NetTCPConnection | Group-Object State Anzahl ermitteln [RO] (Get-NetTCPConnection -State Established).Count Tabellenansicht erzeugen [RO] Get-NetAdapter | Format-Table -AutoSize Detailansicht erzeugen [RO] Get-NetIPConfiguration | Format-List * CSV-Datei exportieren [RO][FILE][SENS] Get-NetTCPConnection | Export-Csv -Path ".\tcp-connections.csv" -NoTypeInformation -Encoding UTF8 Objekte vollständig speichern [RO][FILE][SENS] Get-NetIPConfiguration -All | Export-Clixml -Path ".\ip-configuration.xml" Textprotokoll erzeugen [RO][FILE][SENS] Get-NetIPConfiguration -All | Format-List * | Out-File ".\ip-configuration.txt" -Encoding utf8 Zwei Messzeitpunkte vergleichen $Vorher = Get-NetTCPConnection Start-Sleep -Seconds 10 $Nachher = Get-NetTCPConnection Compare-Object $Vorher $Nachher -Property State, LocalAddress, LocalPort, RemoteAddress, RemotePort Hinweise Where-Object und Select-Object verarbeiten Objekte. Format-Table und Format-List sind für die Darstellung am Ende einer Pipeline gedacht. Für eine spätere Weiterverarbeitung sind Export-Csv oder Export-Clixml geeigneter als formatierter Text. Exportdateien können IP-Adressen, DNS-Namen, Prozesskennungen, Verbindungen und interne Netzstrukturen enthalten. Diagnoseexporte müssen entsprechend den betrieblichen Datenschutz- und Sicherheitsvorgaben behandelt werden. 11. Eingreifende Befehle nur nach der Diagnose verwenden Die folgenden Befehle verändern einen Zustand und gehören nicht zur rein lesenden Bestandsaufnahme. Maßnahme PowerShell-Befehl Auswirkung DNS-Clientcache leeren [CHANGE][PRIV] Clear-DnsClientCache Lokal gespeicherte DNS-Antworten werden entfernt Netzwerkadapter neu starten [CHANGE][PRIV][DISRUPT] Restart-NetAdapter -Name "Ethernet" Adapter wird deaktiviert und erneut aktiviert DHCP-Lease erneuern [CHANGE][PRIV][DISRUPT] ipconfig /release; ipconfig /renew Vorhandene DHCP-Adresse wird zunächst freigegeben DNS-Registrierung anfordern [CHANGE][PRIV] Register-DnsClient Dynamische DNS-Registrierung wird angestoßen Vor einem Eingriff prüfen Besteht eine lokale oder entfernte Administrationsverbindung? Wird die eigene Remoteverbindung durch den Eingriff getrennt? Ist die aktuelle Konfiguration dokumentiert? Ist die Ursache ausreichend eingegrenzt? Gibt es einen Rückfallweg oder lokalen Zugriff? Sind Auswirkungen auf Benutzer, Dienste, VPN-Verbindungen oder Cluster bekannt? Ist ein Wartungsfenster beziehungsweise eine Freigabe erforderlich? Restart-NetAdapter kann eine Remoteverbindung sofort unterbrechen. Der Befehl darf auf entfernten Produktivsystemen nur mit abgesichertem Rückfallweg verwendet werden. 12. Praktische PowerShell-Diagnosereihenfolge Schritt 1 – Adapter prüfen Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress, ifIndex Schritt 2 – IP-Konfiguration prüfen Get-NetIPConfiguration -All Schritt 3 – Standardroute und DNS-Server prüfen Get-NetRoute -DestinationPrefix "0.0.0.0/0" Get-DnsClientServerAddress Schritt 4 – Lokales Standardgateway testen Test-NetConnection 192.0.2.1 -InformationLevel Detailed Schritt 5 – Externe IP-Adresse testen Test-NetConnection 1.1.1.1 -InformationLevel Detailed Schritt 6 – DNS-Auflösung testen Resolve-DnsName example.com -DnsOnly Schritt 7 – Zielport testen Test-NetConnection example.com -Port 443 -InformationLevel Detailed Schritt 8 – Route zum Ziel prüfen Find-NetRoute -RemoteIPAddress 1.1.1.1 Test-NetConnection example.com -TraceRoute Schritt 9 – Lokale Ports und Prozesse prüfen Get-NetTCPConnection -State Listen | Sort-Object LocalPort Schritt 10 – Firewallstatus prüfen Get-NetFirewallProfile Get-NetFirewallRule -Enabled True | Select-Object DisplayName, Direction, Action, Profile Diagnoselogik Ergebnis Nächster Schwerpunkt Adapter nicht aktiv Kabel, WLAN, Adapter, Treiber oder Port prüfen Keine passende IP-Adresse DHCP oder statische IP-Konfiguration prüfen Gateway nicht erreichbar Lokales Netz, VLAN, WLAN, Switch oder Gateway prüfen Externe IP erreichbar, DNS-Name nicht DNS-Konfiguration und Resolver prüfen Ziel-IP erreichbar, Zielport nicht Dienst, Portbindung und Firewall prüfen Falscher Adapter oder falsche Quelladresse Routing, Metrik, VPN und mehrere Adapter prüfen Dienst lauscht lokal, ist extern aber nicht erreichbar Firewall, NAT, Routing und Dienstbindung prüfen Kurzreferenz Diagnoseziel Befehl Adapterstatus [RO] Get-NetAdapter Adapterstatistik [RO] Get-NetAdapterStatistics IP-Gesamtübersicht [RO] Get-NetIPConfiguration -All IP-Adressen [RO] Get-NetIPAddress Schnittstellen und Metriken [RO] Get-NetIPInterface Netzwerkprofil [RO] Get-NetConnectionProfile DNS-Server [RO] Get-DnsClientServerAddress DNS-Auflösung [TEST] Resolve-DnsName example.com -DnsOnly DNS-Cache [RO] Get-DnsClientCache Verbindungstest [TEST] Test-NetConnection example.com TCP-Porttest [TEST] Test-NetConnection example.com -Port 443 Routenverfolgung [TEST] Test-NetConnection example.com -TraceRoute Routingtabelle [RO] Get-NetRoute Route zu einem Ziel [RO] Find-NetRoute -RemoteIPAddress 1.1.1.1 Nachbartabelle [RO] Get-NetNeighbor TCP-Verbindungen [RO] Get-NetTCPConnection UDP-Endpunkte [RO] Get-NetUDPEndpoint Firewallprofile [RO] Get-NetFirewallProfile Firewallregeln [RO] Get-NetFirewallRule Merksatz PowerShell-Netzwerkdiagnose bedeutet nicht, möglichst viele Befehle auszuführen. Entscheidend ist, die Ergebnisse als zusammenhängende Beweiskette auszuwerten: Adapter → IP-Konfiguration → Gateway → Route → DNS → Zielport → lokaler Dienst → Firewall. Quellen Microsoft Learn – NetAdapter-Modul Microsoft Learn – NetTCPIP-Modul Microsoft Learn – DnsClient-Modul Microsoft Learn – NetSecurity-Modul Microsoft Learn – Test-NetConnection Microsoft Learn – Resolve-DnsName Microsoft Learn – Windows-Firewall über die Befehlszeile verwalten 2.3 Linux-Netzwerkbefehle Linux stellt für die Netzwerkdiagnose verschiedene Werkzeuge bereit. Welche Befehle verfügbar sind, hängt von Distribution, Installation und verwendeter Netzwerkverwaltung ab. Die wichtigsten Werkzeuggruppen sind: iproute2 mit ip und ss iputils mit ping und tracepath DNS-Werkzeuge wie resolvectl , dig , host und getent NetworkManager mit nmcli systemd-networkd mit networkctl Treiber- und Linkdiagnose mit ethtool Socket- und Prozessdiagnose mit ss , lsof und fuser Firewallanalyse mit nft , iptables , ufw oder firewall-cmd Protokollanalyse mit journalctl und dmesg Kennzeichnungen Kennzeichnung Bedeutung [RO] Nur lesender Befehl; verändert keine Konfiguration [TEST] Führt einen aktiven Netzwerk- oder Verbindungstest aus [PRIV] Benötigt Root-Rechte beziehungsweise sudo [CHANGE] Verändert einen Zustand oder eine Konfiguration [DISRUPT] Kann eine Verbindung oder einen Dienst unterbrechen [FILE] Schreibt Informationen in eine Datei [SENS] Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten Vor Veränderungen sollten zunächst die lesenden [RO] -Befehle verwendet und deren Ergebnisse dokumentiert werden. 1. Linux-System und verfügbare Werkzeuge prüfen Zunächst muss geklärt werden, welche Distribution, welcher Kernel und welche Netzwerkwerkzeuge vorhanden sind. Aufgabe Linux-Befehl Distribution anzeigen [RO] cat /etc/os-release Kernelversion anzeigen [RO] uname -r Architektur anzeigen [RO] uname -m Hostname anzeigen [RO] hostnamectl Aktuellen Benutzer anzeigen [RO] id Prüfen, ob ein Befehl vorhanden ist [RO] command -v ip Mehrere Werkzeuge prüfen [RO] command -v ip ss ping tracepath traceroute mtr dig resolvectl nmcli networkctl ethtool Version von iproute2 anzeigen [RO] ip -Version Hilfe zum ip -Befehl anzeigen [RO] ip help Handbuchseite öffnen [RO] man ip Handbuch für einen Teilbefehl öffnen [RO] man ip-route Kurzhilfe eines Teilbefehls anzeigen [RO] ip route help Typische Paketnamen Werkzeug Häufiger Paketname ip , ss iproute2 ping , tracepath iputils beziehungsweise iputils-ping und iputils-tracepath dig , host dnsutils , bind-utils oder bind-tools traceroute traceroute mtr mtr ethtool ethtool lsof lsof nc netcat-openbsd , nmap-ncat oder vergleichbares Paket Paketnamen unterscheiden sich zwischen Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, SUSE, Arch Linux und anderen Distributionen. 2. Netzwerkschnittstellen und Linkstatus prüfen ip link zeigt Netzwerkschnittstellen unabhängig davon, ob bereits eine IP-Adresse konfiguriert wurde. Aufgabe Linux-Befehl Alle Schnittstellen anzeigen [RO] ip link show Kompakte Übersicht anzeigen [RO] ip -brief link show Details und Statistiken anzeigen [RO] ip -details -statistics link show Einzelne Schnittstelle anzeigen [RO] ip link show dev enp1s0 Empfangs- und Sendestatistik anzeigen [RO] ip -statistics link show dev enp1s0 Betriebszustand über sysfs lesen [RO] cat /sys/class/net/enp1s0/operstate Physische Trägererkennung lesen [RO] cat /sys/class/net/enp1s0/carrier MTU anzeigen [RO] cat /sys/class/net/enp1s0/mtu MAC-Adresse anzeigen [RO] cat /sys/class/net/enp1s0/address Alle Schnittstellennamen auflisten [RO] ls -1 /sys/class/net enp1s0 ist nur ein Beispiel. Der tatsächliche Name kann beispielsweise eth0 , ens18 , eno1 , enp3s0 , wlan0 oder wlp2s0 lauten. Wichtige Angaben von ip link Angabe Bedeutung UP Schnittstelle wurde administrativ aktiviert LOWER_UP Physische beziehungsweise untergeordnete Verbindung wurde erkannt NO-CARRIER Kein physischer Link erkannt state UP Schnittstelle ist betriebsbereit state DOWN Schnittstelle ist nicht aktiv mtu Maximum Transmission Unit link/ether MAC-Adresse einer Ethernet-Schnittstelle qlen Länge der Sendewarteschlange Typische Fehlerbilder Beobachtung Mögliche Bedeutung state DOWN Schnittstelle wurde deaktiviert oder nicht aktiviert UP , aber kein LOWER_UP Kein physischer Link, Kabel-, Port- oder WLAN-Problem NO-CARRIER Kein Trägersignal erkannt Viele errors Kabel, Port, Treiber, Hardware oder Aushandlung prüfen Viele dropped Überlastung, Warteschlangen, Treiber oder Puffer prüfen Unerwartete MTU Kann Fragmentierungs- oder Tunnelprobleme verursachen Schnittstelle fehlt vollständig Treiber, Hardwareerkennung, virtuelle Maschine oder Gerätezuordnung prüfen 3. IP-Adressen und Adresszustände prüfen Aufgabe Linux-Befehl Alle Adressen anzeigen [RO] ip address show Kompakte Adressübersicht [RO] ip -brief address show IPv4-Adressen anzeigen [RO] ip -4 address show IPv6-Adressen anzeigen [RO] ip -6 address show Adressen einer Schnittstelle anzeigen [RO] ip address show dev enp1s0 Nur globale IPv4-Adressen anzeigen [RO] ip -4 address show scope global Nur globale IPv6-Adressen anzeigen [RO] ip -6 address show scope global Adressen ohne Loopback anzeigen [RO] ip -brief address show | grep -v '^lo' Hostadressen kompakt anzeigen [RO] hostname -I Wichtige Angaben Angabe Bedeutung inet IPv4-Adresse inet6 IPv6-Adresse /24 , /64 Präfixlänge scope host Nur lokal auf diesem System gültig scope link Nur im direkt verbundenen Netz gültig scope global Über das lokale System beziehungsweise Netz hinaus verwendbar dynamic Adresse wurde dynamisch vergeben secondary Zusätzliche Adresse auf derselben Schnittstelle tentative IPv6 Duplicate Address Detection ist noch nicht abgeschlossen deprecated Adresse soll nicht mehr für neue Verbindungen verwendet werden valid_lft Verbleibende Gültigkeitsdauer preferred_lft Verbleibende bevorzugte Nutzungsdauer Prüfpunkte Passt die IP-Adresse zum vorgesehenen Netz? Ist die Präfixlänge korrekt? Ist die Adresse an der richtigen Schnittstelle gebunden? Existieren unerwartete zusätzliche Adressen? Wird eine dynamische Adresse erwartet? Ist eine IPv6-Adresse noch tentative oder bereits deprecated ? Befindet sich eine IPv4-Adresse im Bereich 169.254.0.0/16 ? Existiert nur eine Loopback-Adresse? Eine Adresse aus 169.254.0.0/16 kann darauf hinweisen, dass keine reguläre IPv4-Konfiguration beziehungsweise keine erfolgreiche DHCP-Zuweisung vorhanden ist. 4. Routingtabelle und verwendeten Netzwerkweg prüfen Aufgabe Linux-Befehl IPv4-Routingtabelle anzeigen [RO] ip route show IPv6-Routingtabelle anzeigen [RO] ip -6 route show Alle Routingtabellen anzeigen [RO] ip route show table all Standardroute anzeigen [RO] ip route show default Route zu einem Ziel bestimmen [RO] ip route get 1.1.1.1 Route mit gewünschter Quelladresse prüfen [RO] ip route get 1.1.1.1 from 192.0.2.10 Route über eine Schnittstelle suchen [RO] ip route show dev enp1s0 Policy-Routing-Regeln anzeigen [RO] ip rule show IPv6-Policy-Regeln anzeigen [RO] ip -6 rule show Routingtabellen-Namen anzeigen [RO] cat /etc/iproute2/rt_tables Änderungen an Routen überwachen [RO] ip monitor route Wichtige Angaben Angabe Bedeutung default Standardroute für nicht spezifischer bekannte Ziele via Nächster Router beziehungsweise Gateway dev Verwendete Netzwerkschnittstelle src Bevorzugte lokale Quelladresse metric Routenmetrik proto dhcp Route wurde über DHCP bereitgestellt proto kernel Route wurde automatisch durch den Kernel erzeugt table Verwendete Routingtabelle scope link Ziel befindet sich direkt am lokalen Link Beispielausgabe default via 192.0.2.1 dev enp1s0 proto dhcp src 192.0.2.10 metric 100 192.0.2.0/24 dev enp1s0 proto kernel scope link src 192.0.2.10 metric 100 Interpretation Das Standardgateway ist 192.0.2.1 . Die Schnittstelle enp1s0 wird verwendet. Die bevorzugte Quelladresse ist 192.0.2.10 . Das Netz 192.0.2.0/24 ist direkt angeschlossen. Bei mehreren Routen können Präfixlänge, Policy-Regeln und Metriken die Auswahl beeinflussen. Typische Fehlerbilder Keine Standardroute vorhanden. Standardroute verwendet die falsche Schnittstelle. VPN- oder Tunnelroute überschreibt den erwarteten Weg. Falsche Quelladresse wird ausgewählt. Eine spezifischere Route überschreibt die Standardroute. Policy Routing verwendet eine andere Routingtabelle. Mehrere Standardrouten führen zu einem unerwarteten Netzwerkweg. 5. ARP- und IPv6-Nachbartabelle prüfen ip neigh zeigt IPv4-ARP- und IPv6-Nachbareinträge. Aufgabe Linux-Befehl Nachbartabelle anzeigen [RO] ip neighbour show Kompakte Nachbartabelle anzeigen [RO] ip -brief neighbour show IPv4-Nachbarn anzeigen [RO] ip -4 neighbour show IPv6-Nachbarn anzeigen [RO] ip -6 neighbour show Nachbarn einer Schnittstelle anzeigen [RO] ip neighbour show dev enp1s0 Bestimmte IP-Adresse suchen [RO] ip neighbour show 192.0.2.1 Fehlgeschlagene Einträge anzeigen [RO] ip neighbour show nud failed Unvollständige Einträge anzeigen [RO] ip neighbour show nud incomplete Änderungen überwachen [RO] ip monitor neighbour Wichtige Zustände Zustand Bedeutung REACHABLE Nachbar wurde kürzlich erfolgreich erreicht STALE Eintrag ist vorhanden, wurde aber länger nicht bestätigt DELAY Prüfung der Erreichbarkeit wird verzögert PROBE Aktive Erreichbarkeitsprüfung läuft INCOMPLETE Adressauflösung ist noch nicht abgeschlossen FAILED Adressauflösung beziehungsweise Erreichbarkeitsprüfung ist fehlgeschlagen PERMANENT Dauerhaft konfigurierter Eintrag NOARP Für diesen Eintrag wird keine normale Nachbarauflösung verwendet Fehlerhinweise INCOMPLETE oder FAILED kann auf ein falsches VLAN, eine falsche Netzmaske, einen nicht erreichbaren Nachbarn oder ein Layer-2-Problem hinweisen. Unterschiedliche MAC-Adressen für dieselbe IP-Adresse können auf doppelte IP-Adressen, Hochverfügbarkeit oder einen Sicherheitsvorfall hinweisen. Ein fehlender Eintrag ist nicht automatisch ein Fehler. Das Ziel wurde möglicherweise noch nicht angesprochen oder liegt außerhalb des lokalen Netzes. 6. Erreichbarkeit mit ping prüfen Aufgabe Linux-Befehl Vier ICMP-Anfragen senden [TEST] ping -c 4 192.0.2.1 Externe IP-Adresse testen [TEST] ping -c 4 1.1.1.1 DNS-Namen testen [TEST] ping -c 4 example.com Nur IPv4 verwenden [TEST] ping -4 -c 4 example.com Nur IPv6 verwenden [TEST] ping -6 -c 4 example.com Bestimmte Schnittstelle verwenden [TEST] ping -I enp1s0 -c 4 192.0.2.1 Bestimmte Quelladresse verwenden [TEST] ping -I 192.0.2.10 -c 4 192.0.2.1 Timeout pro Antwort begrenzen [TEST] ping -c 4 -W 2 192.0.2.1 Gesamtlaufzeit begrenzen [TEST] ping -c 4 -w 10 192.0.2.1 Paketgröße prüfen [TEST] ping -c 4 -s 1400 192.0.2.1 Keine Fragmentierung erlauben [TEST] ping -c 4 -M do -s 1400 192.0.2.1 Wichtige Ergebnisse Wert Bedeutung time Antwortzeit beziehungsweise Round Trip Time ttl Verbleibende IPv4 Time to Live icmp_seq Nummer der ICMP-Anfrage packet loss Anteil verlorener Anfragen min/avg/max Minimale, durchschnittliche und maximale Laufzeit mdev Streuung der Laufzeiten unter Linux Interpretation Ergebnis Mögliche Bedeutung IP-Adresse erreichbar, DNS-Name nicht DNS-Problem wahrscheinlich Gateway nicht erreichbar Lokales Netz, VLAN, WLAN, Switch oder Gateway prüfen Ziel nicht erreichbar, Gateway erreichbar Routing, Firewall oder entferntes System prüfen Einzelne Paketverluste Überlastung, Funkstörung, Linkfehler oder Rate Limiting möglich Hohe Laufzeitschwankungen Überlastung, WLAN-Störung oder wechselnder Netzwerkweg Destination Host Unreachable Lokales System oder Router kennt keinen funktionierenden Weg Keine Antwort Ziel offline, ICMP blockiert oder Netzwerkweg gestört Ein fehlgeschlagener Ping beweist nicht, dass ein Ziel vollständig unerreichbar ist. ICMP kann blockiert sein, während ein TCP-Dienst weiterhin funktioniert. 7. Netzwerkpfad mit tracepath, traceroute und mtr untersuchen Aufgabe Linux-Befehl Pfad ohne Root-Rechte prüfen [TEST] tracepath example.com IPv4-Pfad prüfen [TEST] tracepath -4 example.com IPv6-Pfad prüfen [TEST] tracepath -6 example.com Klassische Routenverfolgung [TEST] traceroute example.com Keine Namensauflösung durchführen [TEST] traceroute -n example.com TCP-Traceroute zu Port 443 [TEST][PRIV] sudo traceroute -T -p 443 example.com Laufende kombinierte Messung [TEST] mtr example.com Bericht mit 20 Messzyklen [TEST] mtr --report --report-cycles 20 example.com Bericht ohne DNS-Auflösung [TEST] mtr --report --numeric --report-cycles 20 example.com TCP-MTR zu Port 443 [TEST][PRIV] sudo mtr --tcp --port 443 --report example.com Unterschiede Werkzeug Schwerpunkt tracepath Einfacher Pfadtest und Erkennung der Path MTU; häufig ohne Root-Rechte nutzbar traceroute Klassische Routenverfolgung mit verschiedenen Protokolloptionen mtr Kombiniert laufende Ping- und Traceroute-Messungen Wichtige Hinweise zur Auswertung Ein einzelner nicht antwortender Hop beweist keinen Fehler. Router können Diagnosepakete begrenzen oder ignorieren und trotzdem Nutzdaten weiterleiten. Paketverlust ist besonders relevant, wenn er ab einem Hop beginnt und auch an allen folgenden Hops einschließlich des Ziels sichtbar bleibt. Unterschiedliche Pfade können durch Load Balancing entstehen. Ein erfolgreicher letzter Hop ist wichtiger als einzelne Sterne in der Mitte des Pfades. ICMP-, UDP- und TCP-Traceroute können unterschiedliche Ergebnisse liefern. 8. DNS-Konfiguration und Namensauflösung prüfen Welche DNS-Werkzeuge funktionieren, hängt vom verwendeten Resolver und den installierten Paketen ab. Aufgabe Linux-Befehl Resolver-Konfiguration prüfen [RO] cat /etc/resolv.conf systemd-resolved-Status anzeigen [RO] resolvectl status DNS-Server pro Schnittstelle anzeigen [RO] resolvectl dns DNS-Domänen pro Schnittstelle anzeigen [RO] resolvectl domain Namen über den Systemresolver abfragen [TEST] resolvectl query example.com Auflösung über NSS testen [TEST] getent hosts example.com IPv4- und IPv6-Ergebnisse anzeigen [TEST] getent ahosts example.com Standard-DNS-Abfrage durchführen [TEST] dig example.com IPv4-Adresse abfragen [TEST] dig A example.com IPv6-Adresse abfragen [TEST] dig AAAA example.com Mailserver abfragen [TEST] dig MX example.com Nameserver abfragen [TEST] dig NS example.com Kurzausgabe erzeugen [TEST] dig +short example.com Bestimmten DNS-Server verwenden [TEST] dig @192.0.2.53 example.com Vollständigen Delegationsweg prüfen [TEST] dig +trace example.com Reverse-DNS-Abfrage durchführen [TEST] dig -x 192.0.2.10 Alternative kompakte Abfrage [TEST] host example.com Reverse-Abfrage mit host [TEST] host 192.0.2.10 Warum können die Ergebnisse unterschiedlich sein? Werkzeug Verwendeter Weg getent hosts Systemweite Name Service Switch-Konfiguration aus /etc/nsswitch.conf resolvectl query systemd-resolved dig Direkte DNS-Abfrage; berücksichtigt nicht automatisch alle NSS-Quellen host Direkte DNS-Abfrage Anwendung Kann eigenen Resolver, eigenen Cache oder DNS over HTTPS verwenden Zusätzliche Prüfungen Aufgabe Linux-Befehl NSS-Reihenfolge prüfen [RO] grep '^hosts:' /etc/nsswitch.conf Lokale Hosts-Datei prüfen [RO] cat /etc/hosts Status von systemd-resolved prüfen [RO] systemctl status systemd-resolved --no-pager DNS-Protokoll anzeigen [RO][PRIV] sudo journalctl -u systemd-resolved --since "30 minutes ago" DNS-Statistik anzeigen [RO] resolvectl statistics Typische Fehlerbilder Falscher DNS-Server ist eingetragen. /etc/resolv.conf zeigt auf eine nicht erreichbare Adresse. /etc/resolv.conf ist ein Symlink auf eine unerwartete Datei. Split-DNS oder VPN weist bestimmten Domänen andere Resolver zu. /etc/hosts überschreibt das erwartete DNS-Ergebnis. dig funktioniert, eine Anwendung jedoch nicht. Interne Namen werden fälschlicherweise an einen öffentlichen DNS-Server gesendet. IPv4- und IPv6-Auflösung liefern unterschiedliche Ergebnisse. Interne Hostnamen und DNS-Zonen können sensible Unternehmensinformationen darstellen. Sie sollten nicht unüberlegt an öffentliche Resolver gesendet werden. 9. NetworkManager mit nmcli diagnostizieren nmcli ist das Kommandozeilenwerkzeug für NetworkManager. Aufgabe Linux-Befehl Allgemeinen Status anzeigen [RO] nmcli general status Prüfen, ob NetworkManager läuft [RO] nmcli -terse -fields RUNNING general Gerätestatus anzeigen [RO] nmcli device status Details aller Geräte anzeigen [RO] nmcli device show Details einer Schnittstelle anzeigen [RO] nmcli device show enp1s0 Verbindungprofile auflisten [RO] nmcli connection show Aktive Profile anzeigen [RO] nmcli connection show --active Detailinformationen eines Profils anzeigen [RO] nmcli connection show "PROFILNAME" IP-Adressen eines Profils anzeigen [RO] nmcli -get-values IP4.ADDRESS connection show "PROFILNAME" DNS-Daten eines Profils anzeigen [RO] nmcli -get-values IP4.DNS connection show "PROFILNAME" NetworkManager-Konnektivitätsstatus anzeigen [RO] nmcli networking connectivity Konnektivität neu prüfen [TEST] nmcli networking connectivity check WLAN-Zustand anzeigen [RO] nmcli radio wifi Sichtbare WLANs auflisten [TEST] nmcli device wifi list Änderungen überwachen [RO] nmcli monitor Für Skripte sollten die vollständigen Befehlsnamen statt möglicherweise mehrdeutiger Abkürzungen verwendet werden. Wichtige Gerätezustände Zustand Bedeutung connected Gerät verwendet ein aktives Verbindungsprofil disconnected Gerät ist vorhanden, aber nicht verbunden connecting Verbindungsaufbau läuft unavailable Gerät kann momentan nicht verwendet werden unmanaged NetworkManager verwaltet dieses Gerät nicht Wichtiger Unterschied Device: Tatsächliche physische oder virtuelle Netzwerkschnittstelle. Connection: Gespeichertes NetworkManager-Verbindungsprofil. Ein Gerät kann mehrere passende Profile besitzen, aber normalerweise nur ein aktives Profil gleichzeitig verwenden. 10. systemd-networkd mit networkctl diagnostizieren networkctl zeigt den Zustand von Schnittstellen, wenn systemd-networkd verwendet wird. Aufgabe Linux-Befehl Schnittstellenübersicht anzeigen [RO] networkctl list Gesamtstatus anzeigen [RO] networkctl status Einzelne Schnittstelle anzeigen [RO] networkctl status enp1s0 LLDP-Nachbarn anzeigen [RO] networkctl lldp Status von systemd-networkd anzeigen [RO] systemctl status systemd-networkd --no-pager Protokoll der letzten 30 Minuten anzeigen [RO][PRIV] sudo journalctl -u systemd-networkd --since "30 minutes ago" Konfigurationsdateien auflisten [RO] find /etc/systemd/network /run/systemd/network /usr/lib/systemd/network -maxdepth 1 -type f 2>/dev/null Typische Fehlerbilder Eine Schnittstelle ist unmanaged . Keine passende .network -Datei trifft auf die Schnittstelle zu. Mehrere Konfigurationsdateien konkurrieren miteinander. NetworkManager und systemd-networkd sollen dieselbe Schnittstelle verwalten. DHCP läuft nicht oder liefert keine Adresse. Die Schnittstelle befindet sich im Zustand configuring oder failed . Nicht gleichzeitig davon ausgehen, dass NetworkManager und systemd-networkd dieselbe Schnittstelle verwalten. Zuerst muss festgestellt werden, welcher Dienst tatsächlich zuständig ist. 11. Link, Treiber und Hardware mit ethtool prüfen ethtool liefert Informationen über Ethernet-Schnittstellen, Treiber und Aushandlung. Aufgabe Linux-Befehl Linkeinstellungen anzeigen [RO] ethtool enp1s0 Treiberinformationen anzeigen [RO] ethtool -i enp1s0 Schnittstellenstatistik anzeigen [RO][PRIV] sudo ethtool -S enp1s0 Offload-Funktionen anzeigen [RO] ethtool -k enp1s0 Pause-Parameter anzeigen [RO] ethtool -a enp1s0 Ringpuffer anzeigen [RO][PRIV] sudo ethtool -g enp1s0 Zeitstempelfunktionen anzeigen [RO] ethtool -T enp1s0 Wichtige Angaben Angabe Bedeutung Speed Ausgehandelte Geschwindigkeit Duplex Halb- oder Vollduplex Auto-negotiation Automatische Aushandlung aktiviert oder deaktiviert Link detected Physischer Link erkannt Port Verwendeter Anschlusstyp driver Verwendetes Kernelmodul version Treiberversion firmware-version Firmwareversion des Adapters Typische Fehlerbilder Link detected: no Unerwartet niedrige Geschwindigkeit Half-Duplex statt Full-Duplex Unterschiedliche feste Einstellungen an beiden Link-Enden Steigende CRC-, Frame-, Drop- oder Timeout-Zähler Falscher oder sehr alter Treiber Treiber- oder Firmwarefehler im Kernelprotokoll 12. Offene Ports, Verbindungen und Prozesse mit ss prüfen ss ist das zentrale moderne Werkzeug zur Untersuchung von Sockets und ersetzt viele frühere netstat -Anwendungsfälle. Aufgabe Linux-Befehl Socket-Zusammenfassung anzeigen [RO] ss -summary Lauschende TCP-Ports anzeigen [RO] ss -listen -tcp -numeric Lauschende TCP- und UDP-Ports anzeigen [RO] ss -listen -numeric -tcp -udp Ports mit Prozessen anzeigen [RO][PRIV] sudo ss -listen -numeric -tcp -udp -processes Alle TCP-Verbindungen anzeigen [RO] ss -all -tcp -numeric Bestehende TCP-Verbindungen anzeigen [RO] ss -tcp -numeric state established TCP-Verbindungen mit internen Informationen [RO] ss -tcp -numeric -info Lokalen Port 443 prüfen [RO] ss -listen -tcp -numeric 'sport = :443' Verbindungen zu Zielport 443 anzeigen [RO] ss -tcp -numeric 'dport = :443' UNIX-Sockets anzeigen [RO] ss -x -all Häufig verwendete Kurzform sudo ss -lntup Die Optionen bedeuten: Option Bedeutung -l Nur lauschende Sockets -n Numerische Adressen und Ports -t TCP -u UDP -p Zugehörige Prozesse anzeigen Interpretation Beobachtung Mögliche Bedeutung Erwarteter Port fehlt Dienst läuft nicht oder lauscht auf einem anderen Port Dienst lauscht nur auf 127.0.0.1 Nur lokale Verbindungen möglich Dienst lauscht auf 0.0.0.0 Lauscht grundsätzlich auf allen IPv4-Adressen Dienst lauscht auf :: Lauscht auf IPv6; IPv4-Verhalten hängt zusätzlich von System und Anwendung ab Viele Verbindungen in SYN-SENT Ziel oder Firewall antwortet möglicherweise nicht Viele Verbindungen in SYN-RECV Viele eingehende, noch nicht vollständig aufgebaute Verbindungen Große Send-Q Daten können möglicherweise nicht schnell genug gesendet werden Große Recv-Q Anwendung verarbeitet empfangene Daten möglicherweise nicht schnell genug 13. Ports und Prozesse mit lsof und fuser zuordnen Aufgabe Linux-Befehl Alle Netzwerkdateien anzeigen [RO][PRIV] sudo lsof -numeric -P -i Lauschende TCP-Ports anzeigen [RO][PRIV] sudo lsof -numeric -P -iTCP -sTCP:LISTEN TCP-Port 443 untersuchen [RO][PRIV] sudo lsof -numeric -P -iTCP:443 UDP-Port 53 untersuchen [RO][PRIV] sudo lsof -numeric -P -iUDP:53 Prozess auf TCP-Port 443 suchen [RO][PRIV] sudo fuser -verbose 443/tcp Prozess auf UDP-Port 53 suchen [RO][PRIV] sudo fuser -verbose 53/udp Prozessdetails anhand der PID anzeigen [RO] ps -fp 1234 Ausführliche Prozessinformationen anzeigen [RO] ps -p 1234 -o pid,ppid,user,group,cmd Bei fehlenden Root-Rechten werden möglicherweise nicht alle Prozessinformationen angezeigt. 14. TCP- und UDP-Ports aktiv testen Aufgabe Linux-Befehl TCP-Port testen [TEST] nc -verbose -zero -wait 3 example.com 443 SSH-Port testen [TEST] nc -verbose -zero -wait 3 192.0.2.10 22 Mehrere Ports testen [TEST] nc -verbose -zero -wait 3 192.0.2.10 22 80 443 UDP-Port testen [TEST] nc -verbose -zero -udp -wait 3 192.0.2.53 53 Bash-TCP-Test durchführen [TEST] timeout 3 bash -c ' link-status.txt IP-Adressen speichern [RO][FILE][SENS] ip address show > ip-addresses.txt Routingtabellen speichern [RO][FILE][SENS] ip route show table all > routes.txt Policy-Regeln speichern [RO][FILE][SENS] ip rule show > routing-rules.txt Nachbartabelle speichern [RO][FILE][SENS] ip neighbour show > neighbours.txt Ports und Prozesse speichern [RO][PRIV][FILE][SENS] sudo ss -lntup > listening-ports.txt NetworkManager-Status speichern [RO][FILE][SENS] nmcli device show > networkmanager-devices.txt Resolverstatus speichern [RO][FILE][SENS] resolvectl status > resolver-status.txt Netzwerkprotokolle speichern [RO][PRIV][FILE][SENS] sudo journalctl -u NetworkManager --since "1 hour ago" > networkmanager-log.txt Zwei Messzeitpunkte vergleichen ip -brief address show > addresses-vorher.txt ip route show table all > routes-vorher.txt # Messung oder freigegebene Änderung durchführen ip -brief address show > addresses-nachher.txt ip route show table all > routes-nachher.txt diff -u addresses-vorher.txt addresses-nachher.txt diff -u routes-vorher.txt routes-nachher.txt Hinweise Diagnoseausgaben können interne IP-Adressen, DNS-Namen, MAC-Adressen, Benutzer, Prozesse und Netzstrukturen enthalten. Dateien müssen entsprechend den betrieblichen Datenschutz- und Sicherheitsvorgaben behandelt werden. Vor einer Weitergabe müssen vertrauliche Inhalte geprüft und gegebenenfalls redigiert werden. Passwörter, private Schlüssel, Tokens und vollständige VPN-Konfigurationen gehören nicht in ein allgemeines Diagnoselog. 18. Eingreifende Befehle nur nach der Diagnose verwenden Die folgenden Befehle verändern den Systemzustand und können insbesondere über SSH die eigene Verbindung unterbrechen. Maßnahme Linux-Befehl Auswirkung Schnittstelle deaktivieren [CHANGE][PRIV][DISRUPT] sudo ip link set dev enp1s0 down Verbindung wird unterbrochen Schnittstelle aktivieren [CHANGE][PRIV] sudo ip link set dev enp1s0 up Schnittstelle wird aktiviert NetworkManager-Gerät trennen [CHANGE][PRIV][DISRUPT] sudo nmcli device disconnect enp1s0 Aktive Verbindung wird getrennt NetworkManager-Gerät verbinden [CHANGE][PRIV] sudo nmcli device connect enp1s0 NetworkManager versucht eine Verbindung aufzubauen Verbindungsprofil neu aktivieren [CHANGE][PRIV][DISRUPT] sudo nmcli connection up "PROFILNAME" Profil wird aktiviert beziehungsweise neu angewendet NetworkManager neu starten [CHANGE][PRIV][DISRUPT] sudo systemctl restart NetworkManager Verwaltete Verbindungen können unterbrochen werden systemd-networkd neu starten [CHANGE][PRIV][DISRUPT] sudo systemctl restart systemd-networkd Verwaltete Verbindungen können unterbrochen werden DNS-Cache leeren [CHANGE][PRIV] sudo resolvectl flush-caches Lokale DNS-Cacheeinträge werden entfernt Vor einem Eingriff prüfen Erfolgt der Zugriff lokal oder über SSH? Betrifft die Maßnahme die Schnittstelle der eigenen Sitzung? Ist die aktuelle Konfiguration dokumentiert? Ist bekannt, welcher Netzwerkdienst die Schnittstelle verwaltet? Besteht Konsolen-, Out-of-Band- oder Hypervisorzugriff? Gibt es eine Rückfallmöglichkeit? Sind Auswirkungen auf Container, virtuelle Maschinen, Bridges, Bonds oder VLANs bekannt? Ist eine betriebliche Freigabe erforderlich? Auf einem entfernten System darf die aktive Managementschnittstelle nicht ohne gesicherten Rückfallweg deaktiviert oder neu gestartet werden. 19. Praktische Linux-Diagnosereihenfolge Schritt 1 – System und Netzwerkverwaltung identifizieren cat /etc/os-release systemctl is-active NetworkManager systemctl is-active systemd-networkd Schritt 2 – Linkstatus prüfen ip -brief link show ip -statistics link show Schritt 3 – IP-Adressen prüfen ip -brief address show Schritt 4 – Standardroute und Routenauswahl prüfen ip route show default ip route get 1.1.1.1 ip rule show Schritt 5 – Nachbartabelle prüfen ip neighbour show Schritt 6 – Standardgateway testen ping -c 4 192.0.2.1 Schritt 7 – Externe IP-Adresse testen ping -c 4 1.1.1.1 Schritt 8 – DNS-Konfiguration prüfen cat /etc/resolv.conf resolvectl status Schritt 9 – DNS-Auflösung testen getent hosts example.com dig example.com Schritt 10 – Zielport testen nc -vz -w 3 example.com 443 Schritt 11 – Lokale Ports und Prozesse prüfen sudo ss -lntup Schritt 12 – Netzwerkpfad untersuchen tracepath example.com mtr --report --numeric --report-cycles 20 example.com Schritt 13 – Firewallstatus prüfen sudo nft list ruleset Schritt 14 – Netzwerkprotokolle prüfen sudo journalctl -u NetworkManager --since "30 minutes ago" sudo journalctl -kernel --since "30 minutes ago" Diagnoselogik Ergebnis Nächster Schwerpunkt Schnittstelle fehlt Hardware, Treiber, virtuelle Maschine oder Gerätezuordnung prüfen Schnittstelle DOWN Administrativen Zustand und Netzwerkverwaltung prüfen Kein LOWER_UP beziehungsweise kein Carrier Kabel, WLAN, Switchport oder Linkpartner prüfen Keine passende IP-Adresse DHCP oder statische Konfiguration prüfen Keine Standardroute Gateway- und Profilkonfiguration prüfen Gateway nicht erreichbar Lokales Netz, VLAN, Bridge, Switch oder WLAN prüfen Externe IP erreichbar, DNS-Name nicht DNS-Konfiguration und Resolver prüfen Ziel-IP erreichbar, Zielport nicht Dienst, Portbindung und Firewall prüfen Falsche Quelladresse oder Schnittstelle Routing, Policy Routing, VPN und Metrik prüfen Dienst lauscht lokal, ist extern aber nicht erreichbar Firewall, Routing, NAT und Bind-Adresse prüfen Kurzreferenz Diagnoseziel Linux-Befehl Schnittstellenstatus [RO] ip -brief link show Schnittstellenstatistik [RO] ip -statistics link show IP-Adressen [RO] ip -brief address show IPv4-Adressen [RO] ip -4 address show IPv6-Adressen [RO] ip -6 address show Standardroute [RO] ip route show default Route zu einem Ziel [RO] ip route get 1.1.1.1 Policy Routing [RO] ip rule show Nachbartabelle [RO] ip neighbour show Gateway testen [TEST] ping -c 4 192.0.2.1 Netzwerkpfad [TEST] tracepath example.com Fortlaufende Pfadanalyse [TEST] mtr example.com Resolverstatus [RO] resolvectl status Namensauflösung über NSS [TEST] getent hosts example.com DNS-Abfrage [TEST] dig example.com NetworkManager-Status [RO] nmcli general status NetworkManager-Geräte [RO] nmcli device status systemd-networkd-Status [RO] networkctl status Ethernet-Link [RO] ethtool enp1s0 Treiberinformationen [RO] ethtool -i enp1s0 Lauschende Ports [RO][PRIV] sudo ss -lntup TCP-Port testen [TEST] nc -vz -w 3 example.com 443 Port einem Prozess zuordnen [RO][PRIV] sudo lsof -nP -iTCP:443 nftables-Regeln [RO][PRIV] sudo nft list ruleset Dienststatus [RO] systemctl status DIENST --no-pager Dienstprotokoll [RO][PRIV] sudo journalctl -u DIENST Kernelprotokoll [RO][PRIV] sudo journalctl -kernel Veraltete und moderne Befehle Älterer Befehl Bevorzugter moderner Befehl ifconfig ip address , ip link route -n ip route arp -n ip neighbour netstat -lntup ss -lntup Ältere Werkzeuge können weiterhin installiert sein. Für neue Dokumentationen und aktuelle Linux-Systeme sollten grundsätzlich die iproute2 -Werkzeuge verwendet werden. Merksatz Die Linux-Netzwerkdiagnose folgt einer festen Kette: Schnittstelle → Link → IP-Adresse → Nachbartabelle → Route → Gateway → DNS → Zielport → lokaler Dienst → Firewall → Protokolle. Quellen Linux-Manpage – ip Linux-Manpage – ip-address Linux-Manpage – ip-link Linux-Manpage – ip-route Linux-Manpage – ip-neighbour Linux-Manpage – ss Linux-Manpage – ping NetworkManager-Dokumentation – nmcli NetworkManager-Dokumentation – nmcli-Beispiele systemd-Dokumentation – networkctl systemd-Dokumentation – resolvectl systemd-Dokumentation – journalctl 2.4 macOS-Netzwerkdiagnose macOS basiert auf Darwin und stellt zahlreiche BSD- und Apple-spezifische Netzwerkwerkzeuge bereit. Einige Befehle ähneln Linux-Kommandos, verwenden aber teilweise andere Optionen und Ausgabeformate. Wichtige macOS-Werkzeuge sind: networksetup für Netzwerkdienste und deren Konfiguration scutil für System Configuration, DNS, Proxys und Netzwerkstatus ifconfig für Netzwerkschnittstellen route und netstat für Routingtabellen arp und ndp für Nachbartabellen ping und traceroute für Erreichbarkeit und Netzwerkpfade dig , host und dscacheutil für DNS wdutil und Wireless Diagnostics für WLAN networkQuality für Kapazität und Reaktionsfähigkeit lsof , netstat und nc für Ports und Verbindungen log für das Unified Logging System socketfilterfw und pfctl für die Firewalldiagnose Kennzeichnungen Kennzeichnung Bedeutung [RO] Nur lesender Befehl; verändert keine Konfiguration [TEST] Führt einen aktiven Netzwerk- oder Verbindungstest aus [PRIV] Benötigt Administratorrechte beziehungsweise sudo [CHANGE] Verändert einen Zustand oder eine Konfiguration [DISRUPT] Kann eine Verbindung oder einen Dienst unterbrechen [FILE] Schreibt Informationen in eine Datei [SENS] Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten Vor Änderungen sollten Netzwerkdienst, Schnittstelle, IP-Konfiguration, Route, DNS-Server und aktive VPN- beziehungsweise Proxykonfiguration dokumentiert werden. 1. macOS-Version und verfügbare Werkzeuge prüfen Aufgabe macOS-Befehl macOS-Version anzeigen [RO] sw_vers Produktversion kompakt anzeigen [RO] sw_vers -productVersion Build-Nummer anzeigen [RO] sw_vers -buildVersion Kernelversion anzeigen [RO] uname -a Prozessorarchitektur anzeigen [RO] uname -m Hardwareübersicht anzeigen [RO] system_profiler SPHardwareDataType Softwareübersicht anzeigen [RO] system_profiler SPSoftwareDataType Prüfen, ob ein Befehl vorhanden ist [RO] command -v networkQuality Mehrere Werkzeuge prüfen [RO] command -v networksetup scutil ifconfig route netstat arp ndp ping traceroute dig lsof nc wdutil networkQuality Hilfe zu networksetup anzeigen [RO] networksetup -help Lokale Handbuchseite öffnen [RO] man networksetup Handbuchseite zu scutil öffnen [RO] man scutil Handbuchseite zu ifconfig öffnen [RO] man ifconfig Hinweis zu macOS-Versionen Nicht jedes Werkzeug steht in jeder macOS-Version zur Verfügung: networkQuality ist auf aktuellen macOS-Versionen vorhanden. wdutil ist auf aktuellen macOS-Versionen das Kommandozeilenwerkzeug für WLAN-Diagnosedaten. Das frühere private airport -Werkzeug ist auf aktuellen macOS-Versionen nicht mehr als zuverlässiger Standard verfügbar. Optionen und Ausgaben können sich zwischen macOS-Versionen ändern. 2. Netzwerkdienste und Hardwareports zuordnen Unter macOS muss zwischen einem Netzwerkdienst und der technischen Schnittstelle unterschieden werden. Beispiele: Netzwerkdienst Mögliche Schnittstelle Wi-Fi en0 oder eine andere en -Schnittstelle Ethernet en0 , en1 , en5 oder eine andere Schnittstelle USB-Ethernet Abhängig vom angeschlossenen Adapter Thunderbolt Bridge Bridge- beziehungsweise Thunderbolt-Schnittstelle VPN Häufig utun0 , utun1 oder eine weitere utun -Schnittstelle Zuordnung prüfen Aufgabe macOS-Befehl Alle Hardwareports auflisten [RO] networksetup -listallhardwareports Alle Netzwerkdienste auflisten [RO] networksetup -listallnetworkservices Reihenfolge der Netzwerkdienste anzeigen [RO] networksetup -listnetworkserviceorder Informationen zum Dienst Wi-Fi anzeigen [RO] networksetup -getinfo "Wi-Fi" Informationen zum Dienst Ethernet anzeigen [RO] networksetup -getinfo "Ethernet" Aktive Netzwerksicht anzeigen [RO] scutil --nwi Netzwerkkonfiguration über System Profiler anzeigen [RO][SENS] system_profiler SPNetworkDataType Wichtiger Unterschied Wi-Fi ist normalerweise der Name eines Netzwerkdienstes. en0 ist der Name einer technischen Netzwerkschnittstelle. networksetup erwartet je nach Option entweder einen Dienstnamen oder einen Gerätenamen. Der Gerätename darf nicht anhand eines anderen Macs geraten werden. Vor jedem Befehl mit en0 , en1 oder einem Dienstnamen muss die tatsächliche Zuordnung mit networksetup -listallhardwareports geprüft werden. 3. Netzwerkschnittstellen und Linkstatus prüfen Aufgabe macOS-Befehl Alle Schnittstellen anzeigen [RO] ifconfig -a Einzelne Schnittstelle anzeigen [RO] ifconfig en0 Aktive Schnittstellen anzeigen [RO] ifconfig -u Inaktive Schnittstellen anzeigen [RO] ifconfig -d Schnittstellennamen auflisten [RO] ifconfig -l Schnittstellenstatistik anzeigen [RO] netstat -ibn Netzwerkhardware anzeigen [RO][SENS] system_profiler SPNetworkDataType Ethernet-Hardwareinformationen anzeigen [RO] system_profiler SPEthernetDataType Wichtige Angaben von ifconfig Angabe Bedeutung UP Schnittstelle wurde administrativ aktiviert RUNNING Schnittstelle ist betriebsbereit ACTIVE Aktiver physischer beziehungsweise logischer Link status: active Verbindung wurde erkannt status: inactive Keine aktive Verbindung erkannt ether MAC-Adresse inet IPv4-Adresse inet6 IPv6-Adresse netmask Netzmaske, häufig hexadezimal dargestellt broadcast IPv4-Broadcastadresse mtu Maximum Transmission Unit media Medium, Geschwindigkeit und Duplexmodus Typische Fehlerbilder Beobachtung Mögliche Bedeutung status: inactive Kein Link, WLAN getrennt, Kabel- oder Portproblem Schnittstelle fehlt Adapter, Treiber, USB-/Thunderbolt-Verbindung oder Hardware prüfen Keine inet -Adresse Keine verwendbare IPv4-Konfiguration Nur 169.254.x.x Keine reguläre IPv4-Konfiguration beziehungsweise DHCP-Zuweisung Unerwartete MTU VPN-, Tunnel- oder Fragmentierungsproblem möglich Viele Fehler in netstat -ibn Link-, Adapter-, Treiber- oder Überlastungsproblem möglich 4. IP-Konfiguration und DHCP prüfen Aufgabe macOS-Befehl IPv4-Adresse einer Schnittstelle anzeigen [RO] ipconfig getifaddr en0 Gesamte Schnittstellenkonfiguration anzeigen [RO] ifconfig en0 Informationen des Dienstes Wi-Fi anzeigen [RO] networksetup -getinfo "Wi-Fi" Informationen des Dienstes Ethernet anzeigen [RO] networksetup -getinfo "Ethernet" DHCP-Paketinformationen anzeigen [RO][PRIV][SENS] sudo ipconfig getpacket en0 DHCP-Server auslesen [RO][PRIV] sudo ipconfig getoption en0 server_identifier Subnetzmaske auslesen [RO][PRIV] sudo ipconfig getoption en0 subnet_mask Router aus DHCP auslesen [RO][PRIV] sudo ipconfig getoption en0 router DNS-Server aus DHCP auslesen [RO][PRIV] sudo ipconfig getoption en0 domain_name_server IPv6-Konfiguration anzeigen [RO] ifconfig en0 | grep inet6 Netzwerkstatus zusammengefasst anzeigen [RO] scutil --nwi Prüfpunkte Wurde die erwartete IPv4-Adresse vergeben? Stimmt die Subnetzmaske? Ist der Router korrekt? Ist der erwartete DHCP-Server sichtbar? Sind DNS-Server vorhanden? Befindet sich die Adresse im Bereich 169.254.0.0/16 ? Existieren mehrere aktive Schnittstellen mit konkurrierenden Routen? Ist ein VPN aktiv, das die Routenauswahl verändert? ipconfig getpacket zeigt die zuletzt erhaltenen DHCP-Informationen. Die Ausgabe kann interne Netzwerkinformationen enthalten. 5. Routingtabelle und verwendeten Netzwerkweg prüfen Aufgabe macOS-Befehl Standardroute anzeigen [RO] route -n get default Route zu einer IPv4-Adresse anzeigen [RO] route -n get 1.1.1.1 Route zu einem DNS-Namen anzeigen [RO][TEST] route -n get example.com IPv4-Routingtabelle anzeigen [RO] netstat -rn -f inet IPv6-Routingtabelle anzeigen [RO] netstat -rn -f inet6 Gesamte Routingtabelle anzeigen [RO] netstat -rn Netzwerkstatus anzeigen [RO] scutil --nwi Aktive VPN-/Tunnel-Schnittstellen suchen [RO] ifconfig -l | tr ' ' '\n' | grep '^utun' Details einer Tunnel-Schnittstelle anzeigen [RO] ifconfig utun0 Wichtige Angaben von route -n get Angabe Bedeutung destination Zieladresse gateway Nächster Router interface Verwendete Schnittstelle flags Eigenschaften der Route recvpipe Empfangspufferinformationen sendpipe Sendepufferinformationen Wichtige Flags der Routingtabelle Flag Bedeutung U Route ist aktiv G Ziel wird über ein Gateway erreicht H Hostroute zu einem einzelnen Ziel S Statische Route C Geklonte Route I Schnittstellenroute Typische Fehlerbilder Standardroute fehlt. Standardroute verwendet die falsche Schnittstelle. VPN- oder utun -Schnittstelle übernimmt die Route. Ethernet und WLAN sind gleichzeitig aktiv und besitzen konkurrierende Wege. Die Reihenfolge der Netzwerkdienste entspricht nicht der erwarteten Priorität. Eine spezifischere Route überschreibt den allgemeinen Weg. 6. ARP- und IPv6-Nachbartabelle prüfen Aufgabe macOS-Befehl Gesamte IPv4-ARP-Tabelle anzeigen [RO] arp -an Bestimmte IPv4-Adresse prüfen [RO] arp -n 192.0.2.1 IPv6-Nachbartabelle anzeigen [RO] ndp -an IPv6-Standardrouter anzeigen [RO] ndp -r IPv6-Präfixinformationen anzeigen [RO] ndp -p Schnittstelleninformationen anzeigen [RO] ndp -i en0 Typische Beobachtungen Beobachtung Mögliche Bedeutung (incomplete) MAC-Auflösung wurde nicht abgeschlossen Kein Gateway-Eintrag Gateway wurde noch nicht angesprochen oder ist nicht erreichbar Unerwartete MAC-Adresse Doppelte IP-Adresse, anderes Gateway oder Sicherheitsproblem möglich Gleiche IP mit wechselnder MAC-Adresse Hochverfügbarkeit, doppelte Adresse oder Manipulation prüfen IPv6-Nachbarstatus nicht erreichbar Lokalen IPv6-Link und Router Advertisement prüfen Ein fehlender ARP-Eintrag beweist nicht automatisch einen Fehler. Ein Eintrag entsteht normalerweise erst, wenn das Ziel angesprochen wurde. 7. Erreichbarkeit mit ping prüfen Aufgabe macOS-Befehl Vier Anfragen an das Gateway senden [TEST] ping -c 4 192.0.2.1 Externe IPv4-Adresse testen [TEST] ping -c 4 1.1.1.1 DNS-Namen testen [TEST] ping -c 4 example.com Bestimmte Quelladresse verwenden [TEST] ping -S 192.0.2.10 -c 4 192.0.2.1 IPv6-Ziel testen [TEST] ping6 -c 4 2001:db8::1 IPv6-Link-Local-Ziel mit Schnittstelle testen [TEST] ping6 -c 4 fe80::1%en0 Paketgröße testen [TEST] ping -c 4 -s 1400 192.0.2.1 Akustisches Signal bei Antwort [TEST] ping -a -c 4 192.0.2.1 Wichtige Ergebnisse Wert Bedeutung time Round Trip Time ttl Verbleibende IPv4 Time to Live icmp_seq Nummer der ICMP-Anfrage packet loss Anteil verlorener Pakete min/avg/max/stddev Laufzeitstatistik Interpretation Ergebnis Mögliche Bedeutung Gateway nicht erreichbar Lokales Netz, WLAN, Kabel, VLAN oder Router prüfen IP-Adresse erreichbar, DNS-Name nicht DNS-Problem wahrscheinlich Externe IP nicht erreichbar, Gateway erreichbar Routing, Firewall, Provider oder Upstream prüfen Ping schlägt fehl, TCP-Port funktioniert ICMP wird möglicherweise blockiert Hohe Laufzeitschwankungen WLAN-Störung, Überlastung oder wechselnder Netzwerkweg Paketverlust Funkstörung, Linkproblem, Überlastung oder Rate Limiting möglich 8. Netzwerkpfad mit traceroute untersuchen Aufgabe macOS-Befehl Netzwerkpfad anzeigen [TEST] traceroute example.com Keine DNS-Auflösung durchführen [TEST] traceroute -n example.com Anzahl der Hops begrenzen [TEST] traceroute -m 15 example.com Wartezeit pro Probe begrenzen [TEST] traceroute -w 2 example.com IPv6-Netzwerkpfad anzeigen [TEST] traceroute6 example.com ICMP statt UDP verwenden [TEST][PRIV] sudo traceroute -I example.com Auswertung Ein einzelner Hop ohne Antwort beweist keinen Fehler. Router können Diagnosepakete ignorieren und Nutzdaten trotzdem weiterleiten. Mehrere unterschiedliche Hops können durch Load Balancing entstehen. Entscheidend ist, ob das Ziel erreicht wird. Ein Abbruch ab einem bestimmten Hop kann auf Routing, Firewall oder eine Netzstörung hinweisen. Unterschiedliche Protokolle können unterschiedliche Pfade beziehungsweise Antworten zeigen. 9. DNS-Konfiguration und Namensauflösung prüfen scutil --dns zeigt die tatsächlich vom macOS-System verwendete Resolverkonfiguration. Die Ausgabe kann mehrere Resolver für verschiedene Domänen und Schnittstellen enthalten. Aufgabe macOS-Befehl Gesamte Resolverkonfiguration anzeigen [RO][SENS] scutil --dns DNS-Server des Dienstes Wi-Fi anzeigen [RO] networksetup -getdnsservers "Wi-Fi" DNS-Server des Dienstes Ethernet anzeigen [RO] networksetup -getdnsservers "Ethernet" Suchdomänen anzeigen [RO] networksetup -getsearchdomains "Wi-Fi" Namen über den Systemcache abfragen [TEST] dscacheutil -q host -a name example.com Standard-DNS-Abfrage durchführen [TEST] dig example.com IPv4-Adresse abfragen [TEST] dig A example.com IPv6-Adresse abfragen [TEST] dig AAAA example.com Mailserver abfragen [TEST] dig MX example.com Kurzausgabe erzeugen [TEST] dig +short example.com Bestimmten Resolver verwenden [TEST] dig @192.0.2.53 example.com Vollständigen Delegationsweg prüfen [TEST] dig +trace example.com Reverse-DNS-Abfrage durchführen [TEST] dig -x 192.0.2.10 Alternative Abfrage durchführen [TEST] host example.com Lokale Hosts-Datei anzeigen [RO] cat /etc/hosts Warum kann macOS mehrere Resolver anzeigen? macOS kann Resolver abhängig von folgenden Faktoren auswählen: Netzwerkdienst VPN-Verbindung Suchdomäne Split-DNS-Konfiguration verwaltetes Konfigurationsprofil iCloud Private Relay Network Extension lokale Hosts-Datei Anwendungsinterner DNS-Resolver Typische Fehlerbilder Beobachtung Mögliche Ursache dig funktioniert, Anwendung jedoch nicht Anwendung, Cache, Proxy oder eigener Resolver Öffentlicher Name funktioniert, interner nicht Split-DNS, VPN oder interner Resolver prüfen Falscher DNS-Server in scutil --dns Netzwerkdienst, VPN oder Profil prüfen Mehrere Resolver mit unterschiedlicher Reihenfolge Domänenspezifische Resolver oder VPN-Konfiguration IP-Adresse erreichbar, Name nicht DNS-Problem wahrscheinlich Unterschiedliche Antworten verschiedener DNS-Server Split-DNS, Cache oder unterschiedliche Zonen Für die tatsächliche Resolverauswahl von macOS ist scutil --dns normalerweise aussagekräftiger als eine isolierte Betrachtung einzelner Konfigurationsfelder. 10. Proxy-, VPN- und Network-Extension-Einflüsse prüfen Aufgabe macOS-Befehl Systemweite Proxykonfiguration anzeigen [RO][SENS] scutil --proxy HTTP-Proxy für Wi-Fi anzeigen [RO] networksetup -getwebproxy "Wi-Fi" HTTPS-Proxy für Wi-Fi anzeigen [RO] networksetup -getsecurewebproxy "Wi-Fi" Automatische Proxykonfiguration anzeigen [RO] networksetup -getautoproxyurl "Wi-Fi" Proxy-Bypass-Domänen anzeigen [RO][SENS] networksetup -getproxybypassdomains "Wi-Fi" Aktive Netzwerksicht anzeigen [RO] scutil --nwi Tunnel-Schnittstellen anzeigen [RO] ifconfig -l | tr ' ' '\n' | grep '^utun' Systemerweiterungen anzeigen [RO][SENS] systemextensionsctl list Netzwerkdienste nach Reihenfolge anzeigen [RO] networksetup -listnetworkserviceorder Mögliche Einflussfaktoren Unternehmens-VPN Content-Filter Endpoint-Security-Software DNS-Filter Webproxy PAC-Datei iCloud Private Relay lokale Firewall Network Extension Sicherheitssoftware eines Drittanbieters Typisches Fehlerbild Beobachtung Mögliche Ursache Ping funktioniert, Webseiten nicht Proxy, DNS, TLS, Browser oder Filtersoftware Nur einzelne Anwendungen betroffen Anwendungsproxy oder anwendungsspezifische Network Extension Verbindung funktioniert ohne VPN VPN-Routing, DNS oder Richtlinie prüfen Interne Namen funktionieren nur mit VPN Split-DNS oder interne DNS-Zone Falsche Route über utun VPN- oder Filtersoftware beeinflusst Routing 11. WLAN-Verbindung und Funkqualität prüfen Zuordnung und Status Aufgabe macOS-Befehl Wi-Fi-Hardwareport bestimmen [RO] networksetup -listallhardwareports Wi-Fi-Energiezustand anzeigen [RO] networksetup -getairportpower en0 Verbundenes WLAN anzeigen [RO] networksetup -getairportnetwork en0 WLAN-Informationen anzeigen [RO][PRIV][SENS] sudo wdutil info Ausführliche WLAN-Hardwareinformationen [RO][SENS] system_profiler SPAirPortDataType WLAN-Schnittstelle anzeigen [RO] ifconfig en0 Vor der Verwendung von en0 muss die tatsächliche Wi-Fi-Schnittstelle mit networksetup -listallhardwareports bestimmt werden. Wichtige WLAN-Werte Wert Bedeutung SSID Name des WLANs BSSID MAC-Adresse des Access Points RSSI Empfangssignalstärke Noise Grundrauschen Channel Verwendeter Funkkanal Tx Rate Aktuelle Übertragungsrate PHY Mode Verwendeter WLAN-Standard Security Sicherheitsverfahren MCS Modulation and Coding Scheme NSS Anzahl räumlicher Datenströme Signalbewertung als grobe Orientierung RSSI Grobe Einordnung etwa -30 dBm Sehr stark etwa -50 dBm Gut etwa -67 dBm Für viele Anwendungen noch brauchbar etwa -70 dBm Schwach unter -80 dBm Häufig instabil RSSI-Werte allein beweisen keinen Fehler. Kanalbelegung, Störungen, Rauschen, Wiederholungen, Access-Point-Auslastung und Roaming müssen ebenfalls berücksichtigt werden. Grafische Wireless Diagnostics öffnen Wahltaste beziehungsweise Option gedrückt halten. In der Menüleiste auf das Wi-Fi-Symbol klicken. Wireless Diagnostics öffnen auswählen. Anweisungen des Assistenten befolgen. Wireless Diagnostics verändert laut Apple nicht die Netzwerksettings. Nach einer Analyse kann eine Diagnosedatei unter /var/tmp erzeugt werden. Der Dateiname beginnt mit WirelessDiagnostics und endet mit .tar.gz . 12. Netzwerkqualität und Reaktionsfähigkeit messen networkQuality misst nicht nur die verfügbare Kapazität, sondern auch die Reaktionsfähigkeit der Verbindung unter Last. Aufgabe macOS-Befehl Standardmessung durchführen [TEST] networkQuality Ausführliche Messung durchführen [TEST] networkQuality -v Upload und Download nacheinander messen [TEST] networkQuality -s Bestimmte Schnittstelle verwenden [TEST] networkQuality -I en0 Hilfe anzeigen [RO] networkQuality -h Lokale Handbuchseite öffnen [RO] man networkQuality Typische Ergebnisfelder Ergebnis Bedeutung Downlink capacity Gemessene Downloadkapazität Uplink capacity Gemessene Uploadkapazität Responsiveness Reaktionsfähigkeit unter Last Idle Latency Latenz ohne zusätzliche Last RPM Round-trips per Minute Hinweise Die Messung erzeugt aktiven Netzwerkverkehr. Andere Benutzer und Anwendungen können das Ergebnis beeinflussen. WLAN- und Ethernet-Ergebnisse sollten getrennt betrachtet werden. Ein einzelner Test ist keine belastbare Langzeitmessung. Für Vergleiche sollten mehrere Messungen unter ähnlichen Bedingungen durchgeführt werden. VPN, Proxy, Filtersoftware und Private Relay können das Ergebnis beeinflussen. 13. Offene Ports, Verbindungen und Prozesse prüfen Aufgabe macOS-Befehl Lauschende TCP-Ports anzeigen [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN Alle Netzwerkverbindungen anzeigen [RO][PRIV] sudo lsof -nP -i TCP-Port 443 untersuchen [RO][PRIV] sudo lsof -nP -iTCP:443 UDP-Port 53 untersuchen [RO][PRIV] sudo lsof -nP -iUDP:53 TCP-Sockets anzeigen [RO] netstat -anv -p tcp UDP-Sockets anzeigen [RO] netstat -anv -p udp Netzwerkstatistik anzeigen [RO] netstat -s Schnittstellenstatistik anzeigen [RO] netstat -ibn Prozessdetails anzeigen [RO] ps -p 1234 -o pid,ppid,user,command Interpretation Beobachtung Mögliche Bedeutung Erwarteter Port fehlt Dienst läuft nicht oder lauscht auf einem anderen Port Dienst lauscht auf 127.0.0.1 Nur lokal erreichbar Dienst lauscht auf 0.0.0.0 Lauscht grundsätzlich auf allen IPv4-Schnittstellen Dienst lauscht auf :: Lauscht auf IPv6; IPv4-Verhalten ist zusätzlich zu prüfen Unerwarteter Prozess lauscht Dienstzuordnung und Sicherheitslage prüfen Viele Verbindungen im Verbindungsaufbau Ziel, Route, Dienst oder Firewall antwortet möglicherweise nicht 14. TCP- und UDP-Ports aktiv testen Aufgabe macOS-Befehl HTTPS-Port testen [TEST] nc -vz -w 3 example.com 443 SSH-Port testen [TEST] nc -vz -w 3 192.0.2.10 22 SMB-Port testen [TEST] nc -vz -w 3 192.0.2.10 445 Mehrere Ports testen [TEST] nc -vz -w 3 192.0.2.10 22 80 443 UDP-Port testen [TEST] nc -vzu -w 3 192.0.2.53 53 Mögliche Ergebnisse Ergebnis Bedeutung succeeded TCP-Verbindung konnte aufgebaut werden Connection refused Ziel erreichbar, aber Port geschlossen oder aktiv abgelehnt Timeout Keine rechtzeitige Antwort; Firewall, Route oder Ziel prüfen No route to host Kein verwendbarer Netzwerkweg oder entsprechende Rückmeldung Namensauflösungsfehler DNS-Konfiguration prüfen Bei UDP kann ein fehlendes Ergebnis nicht zuverlässig beweisen, dass ein Port offen oder geschlossen ist. 15. macOS-Firewall und Packet Filter prüfen macOS besitzt verschiedene Sicherheitskomponenten: Application Firewall Packet Filter pf Network Extensions Content Filter und Endpoint-Security-Produkte Application Firewall Aufgabe macOS-Befehl Globalen Firewallstatus anzeigen [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate Stealth-Modus anzeigen [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode Block-all-Modus anzeigen [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall Registrierte Anwendungen anzeigen [RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps Packet Filter Aufgabe macOS-Befehl PF-Status anzeigen [RO][PRIV] sudo pfctl -s info Geladene Regeln anzeigen [RO][PRIV][SENS] sudo pfctl -sr NAT-Regeln anzeigen [RO][PRIV][SENS] sudo pfctl -sn Status und Statistiken anzeigen [RO][PRIV] sudo pfctl -s all PF-Tabellen anzeigen [RO][PRIV][SENS] sudo pfctl -s Tables Prüfreihenfolge Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht. Bind-Adresse des Dienstes prüfen. Application-Firewallstatus prüfen. PF-Status und Regeln prüfen. Network Extensions und Sicherheitssoftware berücksichtigen. Port von einem autorisierten zweiten System testen. Die Firewall nicht pauschal deaktivieren. Dadurch wird die Sicherheitslage verändert und das ursprüngliche Fehlerbild verfälscht. 16. Netzwerkprotokolle mit log untersuchen macOS verwendet das Unified Logging System. Aufgabe macOS-Befehl Meldungen der letzten 30 Minuten anzeigen [RO][PRIV][SENS] sudo log show --last 30m --style compact Meldungen von mDNSResponder anzeigen [RO][PRIV][SENS] sudo log show --last 30m --predicate 'process == "mDNSResponder"' --style compact Meldungen von configd anzeigen [RO][PRIV][SENS] sudo log show --last 30m --predicate 'process == "configd"' --style compact WLAN-Prozesse suchen [RO][PRIV][SENS] sudo log show --last 30m --predicate 'process CONTAINS[c] "airport" OR process CONTAINS[c] "WiFi"' --style compact DNS-Meldungen live verfolgen [RO][PRIV][SENS] sudo log stream --predicate 'process == "mDNSResponder"' --style compact Allgemeine Netzwerkbegriffe suchen `[RO][PRIV][SENS] sudo log show --last 30m --style compact | grep -Ei 'network Prüfpunkte Exakter Zeitstempel der Störung Betroffene Schnittstelle DHCP-Ereignisse DNS-Fehler Verbindungsabbrüche WLAN-Roaming Authentifizierungsfehler VPN- oder Network-Extension-Ereignisse Interface-Wechsel Schlaf- und Aufwachereignisse Das macOS-Protokoll kann private und sensible Inhalte maskieren. Mit Administratorrechten können dennoch schützenswerte System- und Netzwerkdaten sichtbar werden. 17. Diagnoseinformationen sichern und vergleichen Aufgabe macOS-Befehl Schnittstellen sichern [RO][FILE][SENS] ifconfig -a > interfaces.txt Routingtabelle sichern [RO][FILE][SENS] netstat -rn > routes.txt Standardroute sichern [RO][FILE][SENS] route -n get default > default-route.txt DNS-Konfiguration sichern [RO][FILE][SENS] scutil --dns > dns-status.txt Proxykonfiguration sichern [RO][FILE][SENS] scutil --proxy > proxy-status.txt Netzwerkdienste sichern [RO][FILE][SENS] networksetup -listnetworkserviceorder > network-services.txt Netzwerkübersicht sichern [RO][FILE][SENS] system_profiler SPNetworkDataType > network-profiler.txt Offene Ports sichern [RO][PRIV][FILE][SENS] sudo lsof -nP -i > network-connections.txt WLAN-Diagnose sichern [RO][PRIV][FILE][SENS] sudo wdutil info > wifi-status.txt Zwei Zustände vergleichen ifconfig -a > interfaces-vorher.txt netstat -rn > routes-vorher.txt scutil --dns > dns-vorher.txt # Messung oder freigegebene Änderung durchführen ifconfig -a > interfaces-nachher.txt netstat -rn > routes-nachher.txt scutil --dns > dns-nachher.txt diff -u interfaces-vorher.txt interfaces-nachher.txt diff -u routes-vorher.txt routes-nachher.txt diff -u dns-vorher.txt dns-nachher.txt Datenschutz Diagnoseausgaben können enthalten: interne und externe IP-Adressen MAC-Adressen DNS-Suchdomänen WLAN-Namen und BSSIDs VPN- und Proxyinformationen Prozessnamen Benutzerinformationen installierte Network Extensions interne Netzwerkstrukturen Vor einer Weitergabe müssen sensible Angaben redigiert werden. 18. Eingreifende Befehle und Rückfallmöglichkeiten Die folgenden Befehle verändern einen Zustand und können eine Remoteverbindung sofort unterbrechen. Maßnahme macOS-Befehl Auswirkung DNS-Cache leeren [CHANGE][PRIV] sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder Lokale DNS-Cacheeinträge werden verworfen Wi-Fi ausschalten [CHANGE][PRIV][DISRUPT] sudo networksetup -setairportpower en0 off WLAN-Verbindung wird getrennt Wi-Fi einschalten [CHANGE][PRIV] sudo networksetup -setairportpower en0 on WLAN wird wieder aktiviert Schnittstelle deaktivieren [CHANGE][PRIV][DISRUPT] sudo ifconfig en0 down Alle Verbindungen über die Schnittstelle werden getrennt Schnittstelle aktivieren [CHANGE][PRIV] sudo ifconfig en0 up Schnittstelle wird wieder aktiviert Netzwerkdienst auf DHCP setzen [CHANGE][PRIV][DISRUPT] sudo networksetup -setdhcp "Wi-Fi" Vorhandene manuelle IPv4-Konfiguration wird ersetzt en0 und Wi-Fi sind Beispiele. Vorher müssen die tatsächliche Schnittstelle und der tatsächliche Netzwerkdienst bestimmt werden. Vor einem Eingriff prüfen Erfolgt der Zugriff lokal oder per Remotezugriff? Wird die aktive Managementverbindung unterbrochen? Ist die aktuelle manuelle IP-Konfiguration dokumentiert? Sind DNS-, Proxy- und VPN-Einstellungen gesichert? Ist ein lokaler Zugriff auf den Mac möglich? Wird der Mac durch MDM oder ein Konfigurationsprofil verwaltet? Existiert eine geeignete Rückfallmöglichkeit? Rollback-Beispiele Änderung Rückfall Wi-Fi ausgeschaltet Wi-Fi mit networksetup -setairportpower ... on wieder einschalten Schnittstelle deaktiviert Schnittstelle mit ifconfig ... up wieder aktivieren DHCP statt statischer IP gesetzt Dokumentierte IP-, Masken-, Router- und DNS-Werte wiederherstellen Netzwerkumgebung gewechselt Vorherige Netzwerkumgebung wieder auswählen Proxy verändert Dokumentierte Proxywerte wiederherstellen Verifikation nach einer Änderung networksetup -getinfo "Wi-Fi" ifconfig en0 route -n get default scutil --dns ping -c 4 192.0.2.1 ping -c 4 1.1.1.1 dig example.com nc -vz -w 3 example.com 443 19. Praktische macOS-Diagnosereihenfolge Schritt 1 – macOS-Version erfassen sw_vers Schritt 2 – Netzwerkdienst und Schnittstelle zuordnen networksetup -listallhardwareports networksetup -listnetworkserviceorder Schritt 3 – Schnittstellenstatus prüfen ifconfig -a netstat -ibn Schritt 4 – IP-Konfiguration prüfen networksetup -getinfo "Wi-Fi" ipconfig getifaddr en0 Schritt 5 – Standardroute prüfen route -n get default route -n get 1.1.1.1 Schritt 6 – Nachbartabelle prüfen arp -an ndp -an Schritt 7 – Standardgateway testen ping -c 4 192.0.2.1 Schritt 8 – Externe IP-Adresse testen ping -c 4 1.1.1.1 Schritt 9 – DNS-Konfiguration prüfen scutil --dns networksetup -getdnsservers "Wi-Fi" Schritt 10 – DNS-Auflösung testen dscacheutil -q host -a name example.com dig example.com Schritt 11 – Proxy und VPN prüfen scutil --proxy scutil --nwi ifconfig -l | tr ' ' '\n' | grep '^utun' Schritt 12 – Zielport testen nc -vz -w 3 example.com 443 Schritt 13 – Lokale Ports prüfen sudo lsof -nP -iTCP -sTCP:LISTEN Schritt 14 – Netzwerkpfad prüfen traceroute -n example.com Schritt 15 – Netzwerkqualität messen networkQuality -v Schritt 16 – Firewall und Protokolle prüfen /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate sudo pfctl -s info sudo log show --last 30m --style compact Diagnoselogik Ergebnis Nächster Schwerpunkt Schnittstelle fehlt Adapter, USB-/Thunderbolt-Verbindung oder Hardware prüfen Schnittstelle inaktiv WLAN, Kabel, Netzwerkdienst oder Port prüfen Keine passende IP-Adresse DHCP oder manuelle Konfiguration prüfen Keine Standardroute Router, Dienstreihenfolge, VPN oder Konfiguration prüfen Gateway nicht erreichbar Lokales Netz, WLAN, VLAN, Switch oder Router prüfen Externe IP erreichbar, DNS-Name nicht Resolver, DNS-Server und Split-DNS prüfen Ziel-IP erreichbar, Zielport nicht Dienst, Bind-Adresse und Firewall prüfen Nur Anwendungen betroffen Proxy, TLS, Private Relay oder Network Extension prüfen Falsche Route über utun VPN- beziehungsweise Filtersoftware prüfen Schlechte WLAN-Werte Signal, Kanal, Rauschen, Roaming und Access Point prüfen Kurzreferenz Diagnoseziel macOS-Befehl macOS-Version [RO] sw_vers Hardwareports [RO] networksetup -listallhardwareports Netzwerkdienste [RO] networksetup -listallnetworkservices Dienstreihenfolge [RO] networksetup -listnetworkserviceorder Netzwerkschnittstellen [RO] ifconfig -a Schnittstellenstatistik [RO] netstat -ibn IPv4-Adresse [RO] ipconfig getifaddr en0 Dienstinformationen [RO] networksetup -getinfo "Wi-Fi" Standardroute [RO] route -n get default Route zu einem Ziel [RO] route -n get 1.1.1.1 IPv4-Routingtabelle [RO] netstat -rn -f inet ARP-Tabelle [RO] arp -an IPv6-Nachbarn [RO] ndp -an Gateway testen [TEST] ping -c 4 192.0.2.1 Netzwerkpfad [TEST] traceroute -n example.com DNS-Konfiguration [RO] scutil --dns DNS-Abfrage [TEST] dig example.com Systemresolver testen [TEST] dscacheutil -q host -a name example.com Proxykonfiguration [RO] scutil --proxy Netzwerkstatus [RO] scutil --nwi WLAN-Informationen [RO][PRIV] sudo wdutil info Netzwerkqualität [TEST] networkQuality -v Lauschende Ports [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN TCP-Port testen [TEST] nc -vz -w 3 example.com 443 Application Firewall [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate Packet Filter [RO][PRIV] sudo pfctl -s info Systemprotokoll [RO][PRIV] sudo log show --last 30m --style compact Veraltete beziehungsweise nicht mehr zuverlässige Werkzeuge Werkzeug Bewertung Privates airport -Kommandozeilenwerkzeug Auf aktuellen macOS-Versionen nicht als zuverlässiger Standard verwenden ifconfig Unter macOS weiterhin Bestandteil des Systems und für Diagnose geeignet netstat Unter macOS weiterhin für Routing-, Socket- und Schnittstellendiagnose verwendbar wdutil Auf aktuellen macOS-Versionen für WLAN-Diagnose bevorzugen Wireless Diagnostics Von Apple bereitgestelltes grafisches Diagnosewerkzeug Merksatz Die macOS-Netzwerkdiagnose folgt der Kette: Netzwerkdienst → Schnittstelle → Link → IP-Adresse → Nachbartabelle → Route → Gateway → DNS → Proxy/VPN → Zielport → lokaler Dienst → Firewall → Protokolle. Quellen Apple Support – Internetverbindungsprobleme auf dem Mac lösen Apple Support – Netzwerkstatus auf dem Mac prüfen Apple Support – Wireless Diagnostics verwenden Apple Support – Wi-Fi-Statusmenü verwenden Apple Support – Wi-Fi-Einstellungen auf dem Mac Apple Support – Informationen zu networksetup Apple Support – Terminal-Benutzerhandbuch Lokale Apple-Manpages: man networksetup , man scutil , man ifconfig , man route , man netstat , man arp , man ndp , man ping , man traceroute , man networkQuality , man pfctl 2.5 Wireshark und TShark – Netzwerkverkehr aufzeichnen und analysieren Ziel dieser Seite Wireshark und TShark ermöglichen die detaillierte Untersuchung des Netzwerkverkehrs. Sie helfen unter anderem bei der Analyse von: Verbindungsabbrüchen; langsamen Netzwerkverbindungen; DNS-Problemen; TCP-Verbindungsfehlern; Paketverlusten und Übertragungswiederholungen; DHCP-Problemen; TLS-Verbindungsabbrüchen; fehlerhaften Anwendungen und Protokollen; Kommunikationsproblemen zwischen Clients und Servern. Ein Paketmitschnitt sollte erst dann begonnen werden, wenn die betroffenen Systeme, der ungefähre Fehlerzeitpunkt und der erwartete Kommunikationsweg bekannt sind. Wichtig: Paketmitschnitte dürfen ausschließlich in Netzwerken und auf Systemen durchgeführt werden, für die eine entsprechende Berechtigung vorliegt. Aufzeichnungen können Benutzernamen, IP-Adressen, DNS-Anfragen, Sitzungsinformationen und unverschlüsselte Anwendungsdaten enthalten. Kennzeichnungen Kennzeichnung Bedeutung [RO] Nur lesender beziehungsweise auswertender Befehl [TEST] Aktiver Diagnose- oder Aufzeichnungsvorgang [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Der Befehl erstellt oder verarbeitet eine Datei [SENS] Die Ausgabe oder Datei kann sensible Informationen enthalten [DISRUPT] Der Vorgang kann Systeme oder Netzwerkverbindungen beeinflussen 1. Was ist der Unterschied zwischen Wireshark, TShark und Dumpcap? Werkzeuge und Aufgaben anzeigen Werkzeug Aufgabe Typischer Einsatz Wireshark Grafische Paketaufzeichnung und Analyse Interaktive Fehlersuche am Arbeitsplatz TShark Kommandozeilenversion der Wireshark-Analyse Server, Skripte und automatisierte Auswertungen Dumpcap Spezialisierte Paketaufzeichnung Ressourcenarme oder länger laufende Mitschnitte Capinfos Zeigt Eigenschaften einer Mitschnittdatei Kontrolle von Dateiformat, Zeitraum und Paketanzahl Mergecap Führt mehrere Mitschnittdateien zusammen Gemeinsame Analyse mehrerer Aufzeichnungen Editcap Bearbeitet oder verkleinert Mitschnittdateien Zeitbereiche oder einzelne Pakete extrahieren Wireshark und TShark verwenden dieselben Protokoll-Dissektoren und dieselbe Display-Filter-Sprache. Die eigentliche Paketaufzeichnung wird üblicherweise von Dumpcap durchgeführt. Grundlegende Versionsprüfung Aufgabe Befehl Wireshark-Version anzeigen [RO] wireshark --version TShark-Version anzeigen [RO] tshark --version Dumpcap-Version anzeigen [RO] dumpcap --version Capinfos-Version anzeigen [RO] capinfos --version 2. Welche Voraussetzungen müssen vor einem Paketmitschnitt geprüft werden? Vorbedingungen und Berechtigungen anzeigen Vor dem Mitschnitt müssen mindestens folgende Punkte geklärt werden: Prüffrage Bedeutung Welches System ist betroffen? Bestimmt den geeigneten Aufzeichnungspunkt Welche Gegenstelle wird angesprochen? Ermöglicht einen gezielten Host- oder Portfilter Wann tritt der Fehler auf? Verhindert unnötig lange Aufzeichnungen Welches Protokoll wird erwartet? Erleichtert die spätere Analyse Welche Schnittstelle transportiert den Verkehr? Verhindert einen Mitschnitt auf dem falschen Adapter Ist der Mitschnitt autorisiert? Schützt personenbezogene und betriebliche Daten Gibt es ausreichend Speicherplatz? Verhindert eine volle Festplatte Sind die Systemuhren synchronisiert? Ermöglicht den Vergleich mit Server- und Anwendungslogs Betriebssystemspezifische Hinweise Betriebssystem Typische Voraussetzung Windows Für Live-Mitschnitte wird normalerweise Npcap benötigt Linux Der Benutzer benötigt Zugriff auf Dumpcap beziehungsweise die Capture-Gruppe; alternativ sind erhöhte Rechte erforderlich macOS Die Wireshark-Installation richtet üblicherweise die notwendigen BPF-Berechtigungen ein Remote-Server Häufig wird TShark oder Dumpcap ohne grafische Oberfläche verwendet Wireshark oder TShark sollten nicht dauerhaft als Administrator beziehungsweise root ausgeführt werden. Besser ist eine gezielte Berechtigung ausschließlich für die Paketaufzeichnung. 3. Wie wird die richtige Netzwerkschnittstelle ausgewählt? Schnittstellen ermitteln und überprüfen Verfügbare Capture-Schnittstellen anzeigen [RO] tshark -D Alternativ: [RO] dumpcap -D Beispielhafte Ausgabe: 1. \Device\NPF_{...} (Ethernet) 2. \Device\NPF_{...} (WLAN) 3. \Device\NPF_Loopback (Adapter for loopback traffic capture) Unter Linux oder macOS können Namen wie diese erscheinen: 1. enp0s31f6 2. wlan0 3. lo oder: 1. en0 2. en1 3. lo0 Die Schnittstelle kann über ihre Nummer oder ihren Namen ausgewählt werden: [TEST][PRIV] tshark -i 1 [TEST][PRIV] tshark -i en0 Prüfmethode Die vermutete Schnittstelle auswählen. Einen kurzen Mitschnitt starten. Einen bekannten und autorisierten Test erzeugen, beispielsweise eine DNS-Abfrage oder einen Ping. Prüfen, ob die erwarteten Pakete erscheinen. Erst danach den eigentlichen Fehler reproduzieren. Typische Fehler bei der Schnittstellenauswahl WLAN statt Ethernet ausgewählt; VPN-Schnittstelle übersehen; Loopback-Verkehr auf einer physischen Schnittstelle gesucht; virtuelle Schnittstelle einer VM oder eines Containers übersehen; nur den Client untersucht, obwohl der Fehler am Server oder Gateway sichtbar wird; auf einem Switch-Port mitgeschnitten, an dem der betreffende Verkehr nicht vorbeikommt. Ein leerer Mitschnitt beweist nicht, dass kein Netzwerkverkehr vorhanden war. Zuerst müssen Schnittstelle, Aufzeichnungspunkt, Berechtigung und Capture-Filter geprüft werden. 4. Wie wird mit Wireshark ein kontrollierter Mitschnitt erstellt? Vorgehensweise in der grafischen Oberfläche anzeigen Empfohlener Ablauf Wireshark starten. Die Schnittstelle anhand der Paketaktivität und der Systemkonfiguration auswählen. Unter Capture → Options die Schnittstelle kontrollieren. Falls erforderlich einen Capture-Filter eintragen. Die Aufzeichnung starten. Den Fehler möglichst einmal gezielt reproduzieren. Die Aufzeichnung sofort danach beenden. Die Datei im Format pcapng speichern. Zeitpunkt, Client, Server, Testschritt und beobachtetes Verhalten dokumentieren. Für die Analyse Display-Filter verwenden. Empfohlene Dokumentation Feld Beispiel Startzeit 2026-07-31 14:02:10 CEST Endzeit 2026-07-31 14:03:05 CEST Client 192.0.2.10 Server 198.51.100.20 Benutzer Max Mustermann Test Anmeldung an der Beispielanwendung Erwartung Anmeldeseite wird geladen Beobachtung Verbindungsabbruch nach etwa fünf Sekunden Capture-Schnittstelle Ethernet 1 Capture-Filter host 198.51.100.20 Die Aufzeichnung sollte so kurz und zielgerichtet wie möglich sein. Dadurch sinken Speicherbedarf, Analyseaufwand und Datenschutzrisiko. 5. Was ist der Unterschied zwischen Capture-Filter und Display-Filter? Filterarten und wichtige Unterschiede anzeigen Eigenschaft Capture-Filter Display-Filter Zeitpunkt Während der Aufzeichnung Während oder nach der Analyse Wirkung Nicht passende Pakete werden nicht aufgezeichnet Pakete bleiben in der Datei, werden aber ausgeblendet Sprache libpcap-/BPF-Syntax Wireshark-Display-Filter-Syntax TShark-Option -f -Y Nachträglich änderbar Nein Ja Leistungsbedarf Vergleichsweise gering Bei Live-Analyse möglicherweise höher Beispiel tcp port 443 tcp.port == 443 Capture-Filter tcp port 443 Display-Filter tcp.port == 443 Diese beiden Filter dürfen nicht verwechselt werden. Ein Capture-Filter verwirft alle nicht passenden Pakete bereits bei der Aufzeichnung. Fehlende Pakete können später nicht wiederhergestellt werden. Ein Display-Filter verändert die gespeicherte Aufzeichnung nicht. Er kann jederzeit geändert oder entfernt werden. Für eine Live-Aufzeichnung, die gleichzeitig mit -w gespeichert wird, sollte die Eingrenzung mit -f erfolgen. Ein mit -Y angegebener Display-Filter ist dafür kein Ersatz. 6. Welche Capture-Filter werden häufig verwendet? Capture-Filter-Tabelle anzeigen Aufgabe Capture-Filter Verkehr eines IPv4-Hosts host 192.0.2.10 Nur Verkehr von einem Host src host 192.0.2.10 Nur Verkehr zu einem Host dst host 192.0.2.10 Verkehr eines IPv4-Netzes net 192.0.2.0/24 TCP-Port 443 tcp port 443 UDP-Port 53 udp port 53 Zielport 443 tcp dst port 443 Quellport 443 tcp src port 443 DNS über TCP oder UDP port 53 DHCPv4 udp port 67 or udp port 68 HTTP oder HTTPS tcp port 80 or tcp port 443 ICMPv4 icmp ICMPv6 icmp6 ARP arp Host und Port kombinieren host 192.0.2.10 and tcp port 443 Zwei Hosts host 192.0.2.10 or host 198.51.100.20 Host ausschließen not host 192.0.2.10 SSH-Verkehr ausschließen not tcp port 22 Broadcast- oder Multicastverkehr ether broadcast or ether multicast Beispiel: nur HTTPS-Verkehr zu einem Testserver aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 198.51.100.20 and tcp port 443" -a duration:60 -w https-test.pcapng Wichtige Filterregeln Zusammengesetzte Filter in der Shell in Anführungszeichen setzen. Bei and müssen beide Bedingungen zutreffen. Bei or genügt eine der Bedingungen. Mit not wird eine Bedingung ausgeschlossen. Klammern verwenden, wenn die logische Reihenfolge sonst unklar ist. Einen engen Filter erst nach einem kurzen Kontrollmitschnitt einsetzen. 7. Welche Display-Filter werden häufig verwendet? Display-Filter-Tabelle anzeigen Aufgabe Display-Filter IPv4-Adresse als Quelle oder Ziel ip.addr == 192.0.2.10 Nur IPv4-Quelle ip.src == 192.0.2.10 Nur IPv4-Ziel ip.dst == 192.0.2.10 IPv4-Netz ip.addr == 192.0.2.0/24 IPv6-Adresse ipv6.addr == 2001:db8::10 TCP-Port tcp.port == 443 UDP-Port udp.port == 53 Mehrere TCP-Ports tcp.port in {80, 443, 8080} ARP arp ICMPv4 icmp ICMPv6 icmpv6 DNS dns Bestimmter DNS-Name dns.qry.name == "example.com" DNS-Fehlerantworten dns.flags.response == 1 && dns.flags.rcode != 0 DHCPv4 dhcp HTTP-Anfragen http.request TLS-Handshake tls.handshake TCP-SYN ohne ACK tcp.flags.syn == 1 && tcp.flags.ack == 0 TCP-RST tcp.flags.reset == 1 TCP-FIN tcp.flags.fin == 1 TCP-Wiederholungsübertragung tcp.analysis.retransmission TCP-Fast-Retransmission tcp.analysis.fast_retransmission Duplicate ACK tcp.analysis.duplicate_ack Vermutetes verlorenes Segment tcp.analysis.lost_segment TCP-Zero-Window tcp.analysis.zero_window Bestimmte Paketnummer frame.number == 100 Pakete ab Sekunde 10 frame.time_relative >= 10 Zeitbereich von Sekunde 10 bis 20 frame.time_relative >= 10 && frame.time_relative <= 20 Große Frames frame.len > 1500 Expert-Information mit Fehlerstufe _ws.expert.severity == error Filter kombinieren ip.addr == 192.0.2.10 && tcp.port == 443 dns || dhcp ip.addr == 192.0.2.10 && (tcp.analysis.retransmission || tcp.analysis.duplicate_ack) Wichtiger Hinweis zu booleschen Feldern Dieser Filter prüft nur, ob das Feld vorhanden ist: tcp.flags.syn Um ausschließlich gesetzte SYN-Flags zu finden, muss der Wert geprüft werden: tcp.flags.syn == 1 8. Wie werden mit TShark kurze und kontrollierte Mitschnitte erstellt? TShark-Aufzeichnungsbefehle anzeigen Aufgabe Befehl Schnittstellen anzeigen [RO] tshark -D Live-Verkehr auf Schnittstelle 1 anzeigen [TEST][PRIV][SENS] tshark -i 1 Genau 100 Pakete erfassen [TEST][PRIV][FILE][SENS] tshark -i 1 -c 100 -w capture.pcapng 60 Sekunden aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -a duration:60 -w capture.pcapng Auf 100.000 KiB Dateigröße begrenzen [TEST][PRIV][FILE][SENS] tshark -i 1 -a filesize:100000 -w capture.pcapng HTTPS-Verkehr aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "tcp port 443" -a duration:60 -w https.pcapng Verkehr eines Hosts aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 192.0.2.10" -a duration:60 -w host-test.pcapng DNS-Verkehr aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "port 53" -a duration:60 -w dns-test.pcapng -c 100 beendet die Aufzeichnung nach 100 erfassten Paketen. -a duration:60 beendet die Aufzeichnung nach 60 Sekunden. -a filesize:100000 beendet sie nach ungefähr 100.000 KiB. -w capture.pcapng schreibt die Rohpakete in eine Mitschnittdatei. Es handelt sich nicht um eine normale Textdatei. Kontrollierter Beispielablauf [RO] tshark -D [TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 198.51.100.20 and tcp port 443" -a duration:60 -w https-test.pcapng Während der 60 Sekunden wird der Fehler genau einmal reproduziert. Anschließend wird die Datei offline ausgewertet. 9. Wie werden vorhandene Mitschnittdateien mit TShark ausgewertet? Offline-Analyse anzeigen Aufgabe Befehl Datei einlesen [RO][FILE][SENS] tshark -r capture.pcapng Namensauflösung deaktivieren [RO][FILE][SENS] tshark -n -r capture.pcapng Nur DNS anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" Nur TCP-Port 443 anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "tcp.port == 443" Paketdetails anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "frame.number == 100" -V Hexadezimaldaten anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "frame.number == 100" -x Nur bestimmte Protokolldetails [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -O dns Die Option -n deaktiviert die Namensauflösung. Dadurch werden: zusätzliche DNS-Anfragen während der Analyse vermieden; ursprüngliche IP-Adressen unverändert angezeigt; Verzögerungen durch Namensauflösung reduziert; Verwechslungen zwischen aufgezeichneten und nachträglich aufgelösten Namen vermieden. Pakete aus einer Datei filtern und in eine neue Datei schreiben [RO][FILE][SENS] tshark -r capture.pcapng -Y "ip.addr == 192.0.2.10" -w host-only.pcapng Dieser Befehl liest eine vorhandene Datei, wendet einen Display-Filter an und schreibt die passenden Pakete in eine neue Mitschnittdatei. 10. Wie werden gezielt Felder oder CSV-Daten ausgegeben? Feldextraktion und CSV-Ausgabe anzeigen Mit -T fields wird eine tabellarische Feldausgabe erzeugt. Die gewünschten Felder werden mit -e angegeben. DNS-Abfragen extrahieren [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns.qry.name" -T fields -e frame.time -e ip.src -e ip.dst -e dns.qry.name TCP-Verbindungen untersuchen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "tcp" -T fields -e frame.number -e frame.time_relative -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e tcp.flags CSV-Ausgabe mit Kopfzeile [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -T fields -E header=y -E separator=, -E quote=d -e frame.time -e ip.src -e ip.dst -e dns.qry.name Bedeutung der Optionen Option Bedeutung -T fields Gibt ausschließlich ausgewählte Felder aus -e Feldname Fügt ein Feld zur Ausgabe hinzu -E header=y Schreibt die Feldnamen als Kopfzeile -E separator=, Verwendet ein Komma als Trennzeichen -E quote=d Setzt Feldwerte in doppelte Anführungszeichen Bei einem deutschen Tabellenkalkulationsprogramm kann das Komma als Dezimal- oder Listentrennzeichen interpretiert werden. Die Importoptionen müssen deshalb bewusst kontrolliert werden. 11. Welche TShark-Statistiken helfen bei der schnellen Übersicht? Statistikbefehle anzeigen Aufgabe Befehl Protokollhierarchie [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,phs TCP-Konversationen [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,tcp UDP-Konversationen [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,udp IPv4-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ip IPv6-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ipv6 Ethernet-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,eth Statistik pro Sekunde [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,stat,1 DNS-Statistik [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z dns,tree Bedeutung Protocol Hierarchy zeigt die Verteilung der enthaltenen Protokolle. Conversations zeigt Kommunikationsbeziehungen zwischen zwei Endpunkten. Endpoints zeigt einzelne IP- oder MAC-Adressen und deren Datenmengen. I/O Statistics zeigt Paket- und Datenmengen über die Zeit. DNS Statistics zeigt unter anderem DNS-Typen und Antwortcodes. In Wireshark befinden sich entsprechende Ansichten überwiegend im Menü Statistics . 12. Wie werden große oder länger laufende Mitschnitte begrenzt? Ringpuffer und Dateibegrenzung anzeigen Ein unbegrenzter Mitschnitt kann eine Festplatte vollständig füllen. Für längere Aufzeichnungen sollte deshalb ein Ringpuffer verwendet werden. Zwölf Dateien mit jeweils fünf Minuten Aufzeichnungsdauer [TEST][PRIV][FILE][SENS] tshark -i 1 -b duration:300 -b files:12 -w capture.pcapng Damit entsteht ein Ringpuffer für ungefähr eine Stunde: 12 Dateien × 5 Minuten = 60 Minuten Wenn die zwölfte Datei vollständig ist, wird die älteste Datei überschrieben. Fünf Dateien mit jeweils ungefähr 100.000 KiB [TEST][PRIV][FILE][SENS] tshark -i 1 -b filesize:100000 -b files:5 -w capture.pcapng Wichtige Regeln -b files:N benötigt zusätzlich duration , interval oder filesize . Der Zielordner muss ausreichend Speicherplatz besitzen. Der Ringpuffer schützt nicht vor einer zu groß gewählten Gesamtgröße. Nach Auftreten des Fehlers muss die Aufzeichnung rechtzeitig beendet werden, bevor relevante Dateien überschrieben werden. Die erzeugten Dateien können sensible Inhalte enthalten. 13. Wie werden Mitschnittdateien geprüft und zusammengeführt? Capinfos und Mergecap anzeigen Dateieigenschaften anzeigen [RO][FILE][SENS] capinfos capture.pcapng Capinfos zeigt unter anderem: Dateityp; Kapselungstyp; Paketanzahl; Dateigröße; Aufzeichnungsdauer; Zeitpunkt des ersten Pakets; Zeitpunkt des letzten Pakets; durchschnittliche Paket- und Datenrate; vorhandene Schnittstelleninformationen. Kompakte tabellarische Ausgabe [RO][FILE][SENS] capinfos -T capture.pcapng Mehrere Dateien zusammenführen [RO][FILE][SENS] mergecap -w merged.pcapng part1.pcapng part2.pcapng Mergecap ordnet Pakete standardmäßig anhand ihrer Zeitstempel ein. Deshalb müssen die Systemuhren der beteiligten Aufzeichnungssysteme möglichst genau synchronisiert sein. Vor dem Zusammenführen sollten die Zeiträume geprüft werden: [RO][FILE][SENS] capinfos part1.pcapng part2.pcapng 14. Wie wird eine TCP-Verbindung systematisch analysiert? TCP-Diagnose anzeigen Schritt 1: Verbindungsaufbau suchen tcp.flags.syn == 1 && tcp.flags.ack == 0 Ein regulärer TCP-Verbindungsaufbau besteht vereinfacht aus: Schritt Richtung Flags 1 Client → Server SYN 2 Server → Client SYN, ACK 3 Client → Server ACK Interpretation Beobachtung Mögliche Ursache SYN wird wiederholt, aber kein SYN/ACK sichtbar Server nicht erreichbar, Firewall verwirft Pakete, Routingproblem oder falscher Aufzeichnungspunkt SYN wird mit RST beantwortet Zielsystem erreichbar, aber Port geschlossen oder Dienst lehnt Verbindung ab SYN/ACK sichtbar, abschließendes ACK fehlt Rückwegproblem, Clientproblem oder Filter-/Aufzeichnungslücke Drei-Wege-Handshake vollständig Grundlegender TCP-Verbindungsaufbau war erfolgreich RST während der Sitzung Verbindung wurde von einem Endpunkt oder einem Zwischensystem abgebrochen FIN/ACK-Sequenz Geordneter Verbindungsabbau Hilfreiche Filter tcp.flags.reset == 1 tcp.analysis.retransmission tcp.analysis.duplicate_ack tcp.analysis.zero_window tcp.analysis.window_full TCP-Stream isolieren Nach Auswahl eines TCP-Pakets kann in Wireshark verwendet werden: Analyze → Follow → TCP Stream Alternativ lässt sich nach einer Streamnummer filtern: tcp.stream == 0 Eine TCP-Wiederholungsübertragung ist zunächst eine Beobachtung und noch keine eindeutige Ursache. Sie kann durch echten Paketverlust, verspätete Pakete, einen unvollständigen Mitschnitt, asymmetrisches Routing oder den Aufzeichnungspunkt entstehen. 15. Wie werden DNS-Probleme untersucht? DNS-Diagnose anzeigen Grundfilter dns Nur DNS-Anfragen dns.flags.response == 0 Nur DNS-Antworten dns.flags.response == 1 Bestimmten Namen untersuchen dns.qry.name == "example.com" Fehlerantworten anzeigen dns.flags.response == 1 && dns.flags.rcode != 0 Typische Beobachtungen Beobachtung Mögliche Bedeutung Anfrage sichtbar, aber keine Antwort DNS-Server nicht erreichbar, Paketverlust, Firewall oder falscher Rückweg Antwort NXDOMAIN Der angefragte Name existiert aus Sicht des antwortenden DNS-Servers nicht Antwort SERVFAIL DNS-Server konnte die Anfrage nicht erfolgreich verarbeiten Mehrere identische Anfragen Antwort fehlt, kommt verspätet oder wird vom Client nicht akzeptiert Antwort enthält unerwartete Adresse Falscher DNS-Eintrag, falscher DNS-Server, Split-DNS oder Cacheproblem Lange Zeit zwischen Anfrage und Antwort Verzögerter DNS-Server, Weiterleitungs- oder Netzwerkproblem TShark-Auswertung [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -T fields -e frame.time_relative -e ip.src -e ip.dst -e dns.id -e dns.qry.name -e dns.flags.response -e dns.flags.rcode Bei DNS-Problemen müssen Paketmitschnitt und lokale Resolver-Konfiguration gemeinsam betrachtet werden. Ein korrekter DNS-Austausch beweist noch nicht, dass die Anwendung das Ergebnis richtig verarbeitet hat. 16. Wie werden DHCP-Probleme untersucht? DHCP-Diagnose anzeigen Display-Filter dhcp Capture-Filter udp port 67 or udp port 68 Der reguläre DHCPv4-Ablauf wird häufig als DORA bezeichnet: Reihenfolge Nachricht Richtung 1 Discover Client sucht DHCP-Server 2 Offer DHCP-Server bietet eine Konfiguration an 3 Request Client fordert das Angebot an 4 ACK Server bestätigt die Zuweisung Interpretation Beobachtung Mögliche Ursache Discover, aber kein Offer DHCP-Server nicht erreichbar, Relay fehlt, VLAN falsch oder Adresspool erschöpft Offer sichtbar, aber kein Request Client akzeptiert das Angebot nicht oder Mitschnitt ist unvollständig Request, aber kein ACK Serverproblem, Relayproblem oder Paketverlust DHCP NAK Angeforderte Adresse oder Konfiguration wurde abgelehnt Mehrere unterschiedliche Offers Mehrere DHCP-Server antworten; möglicherweise unerwünschter DHCP-Server DORA vollständig DHCP-Kommunikation war grundsätzlich erfolgreich Bei VLAN-übergreifendem DHCP muss zusätzlich der DHCP-Relay beziehungsweise IP-Helper untersucht werden. 17. Wie werden TLS- und HTTPS-Probleme untersucht? TLS-Diagnose anzeigen TLS-Verkehr tls TLS-Handshake tls.handshake TLS-Warnungen und Fehler tls.alert_message TCP-Port 443 zusammen mit TLS tcp.port == 443 && tls Typischer vereinfachter Ablauf TCP-Verbindung wird aufgebaut. Client sendet einen TLS-ClientHello. Server sendet einen TLS-ServerHello. Zertifikats- und Schlüsselparameter werden ausgetauscht. Die verschlüsselte Anwendungskommunikation beginnt. Beobachtungen Beobachtung Mögliche Bedeutung TCP-Handshake fehlt Noch kein TLS-Problem; zuerst Netzwerk und TCP untersuchen ClientHello ohne ServerHello Server, Firewall, TLS-Proxy oder Rückweg prüfen TLS Alert TLS-Seite meldet einen Protokoll- oder Zertifikatsfehler ServerHello vorhanden, späterer Abbruch Zertifikat, Cipher Suites, TLS-Version oder Anwendung prüfen Verschlüsselte Application Data TLS-Verbindung wurde mindestens bis zur verschlüsselten Datenübertragung aufgebaut Der Inhalt moderner HTTPS-Verbindungen ist verschlüsselt. Ohne ausdrücklich autorisierte Schlüssel- oder Debug-Daten sind hauptsächlich Metadaten, TCP-Verhalten und Teile des TLS-Handshakes sichtbar. 18. Welche Analysefehler treten bei Wireshark besonders häufig auf? Fehlinterpretationen und Gegenmaßnahmen anzeigen Fehler Warum problematisch? Richtige Reaktion Capture- und Display-Filter verwechselt Erwartete Pakete werden nicht gespeichert oder Filter funktioniert nicht Syntax und Einsatzzeitpunkt prüfen Falsche Schnittstelle gewählt Relevanter Verkehr fehlt Kurzen Kontrollmitschnitt durchführen Zu enger Capture-Filter Entscheidende Begleitpakete fehlen Zunächst breiter und zeitlich begrenzt aufzeichnen Zu langer Mitschnitt Große Dateien und hoher Analyseaufwand Fehler gezielt reproduzieren und sofort stoppen Namensauflösung aktiviert Adressen erscheinen verändert oder Analyse erzeugt zusätzliche Anfragen Für reproduzierbare CLI-Ausgaben -n verwenden Jedes TCP-Retransmission-Ereignis als Paketverlust bewertet Analyseindikatoren können durch unvollständige Mitschnitte entstehen Sequenznummern, Aufzeichnungspunkt und Gegenmitschnitt prüfen Rote oder schwarze Markierung als Beweis betrachtet Farben beruhen auf konfigurierten Regeln Paketdetails und tatsächliche Felder untersuchen Checksum-Fehler sofort als Netzfehler bewertet Checksum Offloading kann auf dem sendenden Host scheinbar fehlerhafte Prüfsummen erzeugen Gegenstelle oder Netzwerkpfad vergleichen Fehlende Pakete als Beweis für eine Firewall gewertet Falscher Aufzeichnungspunkt oder asymmetrischer Weg möglich Auf beiden Seiten oder an einem geeigneten Übergabepunkt mitschneiden Promiscuous Mode überschätzt Ein Switch sendet fremden Unicast-Verkehr nicht automatisch an jeden Port Autorisierten Mirror-/SPAN-Port oder TAP verwenden Zeitstempel verschiedener Systeme ungeprüft verglichen Abweichende Systemuhren verfälschen die Reihenfolge NTP-Status und Zeitzonen prüfen Verschlüsselten Inhalt erwartet TLS schützt die Nutzdaten Handshake, Metadaten und autorisierte Logs auswerten Checksum Offloading Bei ausgehenden Paketen kann das Betriebssystem die endgültige Prüfsumme erst durch die Netzwerkkarte berechnen lassen. Ein Mitschnitt auf dem sendenden System kann das Paket vor dieser Berechnung erfassen. Wireshark kennzeichnet die Prüfsumme dann möglicherweise als fehlerhaft, obwohl sie auf dem Übertragungsmedium korrekt war. TCP-Analysekennzeichnungen Filter wie tcp.analysis.retransmission sind Ergebnisse der Wireshark-Analyse. Sie sind wertvolle Hinweise, aber keine automatische Ursachenfeststellung. 19. Wo muss der Paketmitschnitt durchgeführt werden? Geeigneten Aufzeichnungspunkt bestimmen Der geeignete Mitschnittpunkt hängt vom vermuteten Fehlerbereich ab. Vermuteter Fehler Geeigneter Mitschnittpunkt Anwendung auf dem Client Direkt auf dem Client Server antwortet nicht Client und möglichst Server Firewall oder Routing Vor und hinter dem betroffenen Übergang DHCP über mehrere VLANs Client-VLAN, Relay und Servernetz DNS-Auflösung Client und gegebenenfalls DNS-Server VPN-Verbindung Physische und virtuelle VPN-Schnittstelle Containerkommunikation Host-, Bridge- und gegebenenfalls Containerschnittstelle Virtuelle Maschine Gastbetriebssystem und gegebenenfalls virtueller Switch Sporadischer Paketverlust Beide Endpunkte oder geeigneter Netzwerk-TAP In einem geswitchten Ethernet-Netz sieht ein Endgerät normalerweise: eigene ein- und ausgehende Pakete; Broadcastverkehr; bestimmten Multicastverkehr; nicht automatisch den gesamten Unicastverkehr anderer Systeme. Für fremden Unicastverkehr ist ein autorisierter Mirror-/SPAN-Port, Netzwerk-TAP oder ein Mitschnitt direkt auf einem Endpunkt erforderlich. Vergleichsmethode Client-Mitschnitt → Netzwerkübergang → Server-Mitschnitt Wenn ein Paket im Client-Mitschnitt vorhanden ist, aber im Server-Mitschnitt fehlt, liegt die Unterbrechung wahrscheinlich zwischen diesen Punkten. Für eine belastbare Aussage müssen Filter, Zeitstempel und Aufzeichnungsvollständigkeit geprüft werden. 20. Wie sieht ein sicherer Diagnoseablauf mit Wireshark oder TShark aus? Empfohlene Schrittfolge anzeigen Vorbereitung Störung und erwartetes Verhalten dokumentieren. Client, Server, IP-Adressen, Ports und Protokolle bestimmen. Fehlerzeitpunkt und reproduzierbaren Test festlegen. Berechtigung für den Mitschnitt prüfen. Zeitsynchronisation der beteiligten Systeme prüfen. Speicherort und Speicherplatz kontrollieren. Aufzeichnung Richtige Schnittstelle mit tshark -D oder Wireshark bestimmen. Einen kurzen Kontrollmitschnitt durchführen. Einen angemessenen Capture-Filter setzen. Zeit-, Paket- oder Dateigrößenbegrenzung festlegen. Aufzeichnung starten. Fehler genau einmal reproduzieren. Aufzeichnung sofort beenden. Datei eindeutig benennen und sicher speichern. Analyse Zuerst Protokollhierarchie, Endpunkte und Konversationen prüfen. Relevante Client-Server-Kommunikation isolieren. ARP, DHCP und DNS vor TCP und Anwendung betrachten. TCP-Verbindungsaufbau, Abbruch und Wiederholungen prüfen. Anschließend TLS- oder Anwendungsprotokoll untersuchen. Zeitstempel mit Server-, Firewall- und Anwendungslogs vergleichen. Beobachtung und mögliche Ursache voneinander trennen. Validierung Hypothese durch einen kontrollierten Vergleichstest prüfen. Falls erforderlich, Mitschnitte an zwei Punkten vergleichen. Nach einer Änderung denselben Test erneut durchführen. Ergebnis, Änderung und Nachweis dokumentieren. 21. Wie müssen Paketmitschnitte geschützt werden? Datenschutz- und Sicherheitsregeln anzeigen Paketmitschnitte können enthalten: interne und externe IP-Adressen; MAC-Adressen; DNS-Anfragen; Hostnamen; Benutzernamen; unverschlüsselte Passwörter; Cookies und Sitzungstoken; E-Mail- oder Chat-Inhalte; übertragene Dateien; Zertifikatsinformationen; Informationen über interne Systeme und Dienste. Mindestmaßnahmen nur mit dokumentierter Berechtigung aufzeichnen; Umfang und Dauer minimieren; möglichst früh einen geeigneten Capture-Filter verwenden; Dateien ausschließlich in geschützten Verzeichnissen speichern; Zugriff auf zuständige Personen beschränken; Dateien nicht unkontrolliert per E-Mail oder Messenger versenden; für externe Analysen nur notwendige Pakete bereitstellen; Aufbewahrungs- und Löschfristen beachten; Weitergabe und Bearbeitung dokumentieren; nicht mehr benötigte Mitschnittdateien sicher löschen. Das Öffnen von Follow TCP Stream , Follow HTTP Stream oder ähnlichen Ansichten kann zusammenhängende Anwendungsdaten sichtbar machen. Diese Funktionen dürfen deshalb nur bei entsprechender Berechtigung verwendet werden. 22. Kurzreferenz Die wichtigsten Befehle und Filter anzeigen TShark-Befehle Aufgabe Befehl Version [RO] tshark --version Schnittstellen [RO] tshark -D 100 Pakete aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -c 100 -w capture.pcapng 60 Sekunden aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -a duration:60 -w capture.pcapng Capture-Filter anwenden [TEST][PRIV][FILE][SENS] tshark -i 1 -f "tcp port 443" -a duration:60 -w capture.pcapng Datei lesen [RO][FILE][SENS] tshark -n -r capture.pcapng Display-Filter anwenden [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" Protokollhierarchie [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,phs TCP-Konversationen [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,tcp IPv4-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ip Dateiinformationen [RO][FILE][SENS] capinfos capture.pcapng Dateien zusammenführen [RO][FILE][SENS] mergecap -w merged.pcapng part1.pcapng part2.pcapng Wichtige Capture-Filter Aufgabe Filter Host host 192.0.2.10 Netz net 192.0.2.0/24 HTTPS tcp port 443 DNS port 53 DHCP udp port 67 or udp port 68 ICMPv4 icmp ICMPv6 icmp6 ARP arp Wichtige Display-Filter Aufgabe Filter Host ip.addr == 192.0.2.10 HTTPS-Port tcp.port == 443 DNS dns DHCP dhcp TLS-Handshake tls.handshake TCP-Verbindungsbeginn tcp.flags.syn == 1 && tcp.flags.ack == 0 TCP-Abbruch tcp.flags.reset == 1 Wiederholungsübertragung tcp.analysis.retransmission Duplicate ACK tcp.analysis.duplicate_ack TCP-Stream tcp.stream == 0 Merksätze Erst Aufzeichnungspunkt und Schnittstelle prüfen, dann den Fehler mitschneiden. Capture-Filter bestimmen, was gespeichert wird; Display-Filter bestimmen, was angezeigt wird. Ein fehlendes Paket ist nur dann aussagekräftig, wenn Aufzeichnungspunkt, Filter und Mitschnitt vollständig geprüft wurden. Wireshark-Markierungen und TCP-Analysehinweise sind Indizien, keine fertige Fehlerursache. Kurze, reproduzierbare und dokumentierte Mitschnitte sind besser als stundenlange unkontrollierte Aufzeichnungen. Paketmitschnitte sind sensible Diagnosedaten und müssen entsprechend geschützt werden. Die Paketaufzeichnung zeigt, was auf dem untersuchten Netzwerkabschnitt sichtbar war – nicht automatisch den vollständigen Kommunikationsweg. Quellen Wireshark User’s Guide – Capturing Live Network Data Wireshark User’s Guide – Capture Filters Wireshark User’s Guide – Display Filters Wireshark Display Filter Reference Offizielle TShark-Dokumentation Offizielle Dumpcap-Dokumentation Offizielle Capinfos-Dokumentation Offizielle Mergecap-Dokumentation Offizielle Editcap-Dokumentation 2.6 tcpdump und Capture-Filter – Paketmitschnitte im Terminal Ziel dieser Seite tcpdump ist ein Kommandozeilenwerkzeug zum Aufzeichnen und Anzeigen von Netzwerkpaketen. Es eignet sich besonders für: Linux- und macOS-Systeme ohne grafische Oberfläche; Server und Netzwerkgeräte; SSH-Sitzungen; kurze, gezielte Paketmitschnitte; automatisierte oder zeitlich begrenzte Aufzeichnungen; die Vorbereitung einer späteren Analyse mit Wireshark oder TShark; die Prüfung, ob ein Paket einen bestimmten Aufzeichnungspunkt erreicht. tcpdump verwendet die Capture-Filter-Sprache von libpcap . Diese Filter bestimmen bereits während des Mitschnitts, welche Pakete verarbeitet und gespeichert werden. Wichtig: Ein Capture-Filter lässt sich nachträglich nicht rückgängig machen. Pakete, die nicht zum Filter passen, werden nicht in die Mitschnittdatei aufgenommen. Kennzeichnungen Kennzeichnung Bedeutung [RO] Nur lesender beziehungsweise auswertender Befehl [TEST] Aktiver Diagnose- oder Aufzeichnungsvorgang [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Der Befehl erstellt oder verarbeitet eine Datei [SENS] Ausgabe oder Datei kann sensible Informationen enthalten [CHANGE] Der Befehl verändert eine Einstellung oder Datei [DISRUPT] Der Vorgang kann Netzwerk oder Systembetrieb beeinflussen 1. Auf welchen Betriebssystemen kann tcpdump verwendet werden? Betriebssystemübersicht anzeigen Betriebssystem Verfügbarkeit Typischer Aufruf Linux Meist über die Paketverwaltung installierbar sudo tcpdump macOS Standardmäßig vorhanden sudo tcpdump FreeBSD/OpenBSD/NetBSD Üblicherweise vorhanden doas tcpdump oder sudo tcpdump Windows Nicht Bestandteil von Windows Vorzugsweise TShark oder Wireshark mit Npcap Netzwerk-Appliance Häufig vorhanden, aber herstellerabhängig Herstellerdokumentation beachten Container Nur mit passenden Netzwerk- und Capture-Berechtigungen Meist besser auf dem Container-Host mitschneiden Version prüfen [RO] tcpdump --version Die Ausgabe nennt normalerweise sowohl die tcpdump- als auch die libpcap-Version. Linux: Installation prüfen [RO] command -v tcpdump macOS: Installationspfad prüfen [RO] command -v tcpdump Windows Unter Windows sollte für eine vergleichbare Aufgabe normalerweise TShark verwendet werden: [RO] tshark --version [RO] tshark -D WinDump existiert als tcpdump-ähnliches Werkzeug für Windows, ist aber kein Bestandteil der aktuellen Windows-Bordmittel. Für ein modernes Administrationsumfeld sind Wireshark und TShark mit Npcap in der Regel die besser dokumentierte Lösung. 2. Welche Berechtigungen benötigt tcpdump? Capture-Berechtigungen und Sicherheitsprinzip anzeigen Das Lesen von Netzwerkpaketen erfordert in der Regel besondere Betriebssystemberechtigungen. Ein normaler Benutzer darf deshalb häufig keinen Live-Mitschnitt starten. Typischer Aufruf unter Linux und macOS [TEST][PRIV][SENS] sudo tcpdump Das Lesen einer bereits vorhandenen Mitschnittdatei benötigt normalerweise keine Capture-Berechtigung: [RO][FILE][SENS] tcpdump -r capture.pcap Sicherheitsprinzip tcpdump nur für den erforderlichen Zeitraum mit erhöhten Rechten starten; nicht dauerhaft als root arbeiten; Ausgabedateien in einem geschützten Verzeichnis speichern; Dateiberechtigungen nach dem Mitschnitt kontrollieren; Paketmitschnitte nicht unkontrolliert weitergeben; nur autorisierte Schnittstellen und Systeme untersuchen. Je nach Linux-Distribution kann tcpdump mit Linux-Capabilities oder einer herstellerspezifischen Berechtigungsregel ausgestattet sein. Solche Änderungen dürfen nicht pauschal aus fremden Anleitungen übernommen werden. Vorher müssen Sicherheitsrichtlinie, Paketquelle und bestehende Berechtigungen geprüft werden. 3. Wie werden Schnittstellen ermittelt und ausgewählt? Schnittstellenbefehle anzeigen Mit tcpdump verfügbare Capture-Schnittstellen anzeigen [RO] tcpdump -D Alternativ: [RO] tcpdump --list-interfaces Beispielhafte Schnittstellennamen: System Typische Namen Linux eth0 , ens18 , enp3s0 , wlan0 , lo macOS en0 , en1 , lo0 , utun0 Container-Host docker0 , br-... , veth... VPN tun0 , tap0 , wg0 , utun... Bestimmte Schnittstelle verwenden [TEST][PRIV][SENS] sudo tcpdump -i eth0 [TEST][PRIV][SENS] sudo tcpdump -i en0 Loopbackverkehr aufzeichnen Linux: [TEST][PRIV][SENS] sudo tcpdump -i lo macOS: [TEST][PRIV][SENS] sudo tcpdump -i lo0 Mehrere reguläre Schnittstellen erfassen [TEST][PRIV][SENS] sudo tcpdump -i any Die Pseudoschnittstelle any wird auf Linux und aktuellen macOS-Versionen unterstützt. Dabei gelten Einschränkungen: der Mitschnitt erfolgt nicht im Promiscuous Mode; unterschiedliche Link-Layer-Typen können auftreten; die Ausgabe kann mehr Verkehr enthalten als erwartet; die konkrete Eingangsschnittstelle sollte bei der Auswertung beachtet werden. Richtige Schnittstelle kontrollieren [TEST][PRIV][SENS] sudo tcpdump -i en0 -nn -c 20 Danach wird ein bekannter, autorisierter Test erzeugt, beispielsweise: ping 192.0.2.1 Sind die erwarteten Pakete nicht sichtbar, müssen folgende Punkte geprüft werden: falsche Schnittstelle; VPN- oder Tunnelschnittstelle übersehen; Loopbackverkehr auf physischer Schnittstelle gesucht; falscher Netzwerk-Namespace; Paket passiert den untersuchten Host nicht; Capture-Berechtigung fehlt; Capture-Filter ist zu eng. 4. Welche Optionen werden bei tcpdump häufig verwendet? Optionstabelle anzeigen Option Bedeutung -D Verfügbare Capture-Schnittstellen anzeigen -i INTERFACE Schnittstelle auswählen -n Adressen und andere numerische Angaben nicht in Namen umwandeln -nn Insbesondere auch Portnummern numerisch anzeigen -c ANZAHL Nach einer bestimmten Paketanzahl beenden -w DATEI Rohpakete in eine Datei schreiben -r DATEI Pakete aus einer Datei lesen -v Ausführlichere Ausgabe -vv Noch ausführlichere Ausgabe -vvv Maximale standardmäßige Detailstufe -q Verkürzte Ausgabe -e Link-Layer-Header, beispielsweise MAC-Adressen, anzeigen -A Nutzdaten als ASCII anzeigen -x Paketdaten hexadezimal anzeigen -X Paketdaten hexadezimal und als ASCII anzeigen -XX Wie -X , einschließlich Link-Layer-Header -tt Zeit als Unix-Zeitstempel ausgeben -ttt Zeitdifferenz zum vorherigen Paket ausgeben -tttt Datum und Uhrzeit pro Paket ausgeben -ttttt Zeitdifferenz zum ersten angezeigten Paket ausgeben -s LÄNGE Maximale Anzahl aufgezeichneter Bytes je Paket festlegen -B GRÖSSE Betriebssystem-Capture-Puffer in KiB festlegen -C GRÖSSE Ausgabedatei nach Erreichen einer Größe wechseln -G SEKUNDEN Ausgabedatei zeitgesteuert wechseln -W ANZAHL Anzahl rotierter Dateien begrenzen -U Pakete zeitnah in die Ausgabedatei schreiben -K Prüfsummenprüfung bei der Anzeige deaktivieren -Q in|out|inout Aufzeichnungsrichtung festlegen, sofern unterstützt -p Promiscuous Mode nicht aktivieren -F DATEI Capture-Filter aus einer Datei lesen Nicht jede Option wird von jeder Betriebssystem- und libpcap-Version unterstützt. Deshalb sollten Version und lokale Hilfeseite geprüft werden: [RO] tcpdump --version [RO] man tcpdump 5. Wie wird ein kurzer, kontrollierter Mitschnitt durchgeführt? Grundlegende Mitschnittbefehle anzeigen 20 Pakete anzeigen und danach beenden [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20 100 Pakete in eine Datei schreiben [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap Nur Verkehr eines bestimmten Hosts aufzeichnen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 500 -w host-test.pcap 'host 192.0.2.10' Nur HTTPS-Verkehr zu einem Server aufzeichnen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 1000 -w https-test.pcap 'host 198.51.100.20 and tcp port 443' Mitschnitt manuell beenden Ein laufender Mitschnitt wird normalerweise mit folgender Tastenkombination beendet: [Strg] + [C] Nach dem Beenden zeigt tcpdump Zähler an: packets captured packets received by filter packets dropped by kernel Die genaue Bedeutung von packets received by filter ist betriebssystemabhängig. Besonders wichtig ist: packets dropped by kernel Ein Wert größer als null weist darauf hin, dass der Capture-Mechanismus Pakete wegen fehlenden Pufferplatzes verworfen hat. Die Aufzeichnung ist dann möglicherweise unvollständig. 6. Wie ist ein tcpdump-Filter grundsätzlich aufgebaut? BPF-Filterlogik anzeigen Ein Capture-Filter besteht aus einer oder mehreren Bedingungen. Diese können mit logischen Operatoren verbunden werden. Operator Bedeutung and Beide Bedingungen müssen zutreffen or Mindestens eine Bedingung muss zutreffen not Bedingung wird ausgeschlossen ( ) Gruppiert mehrere Bedingungen Einzelne Bedingung host 192.0.2.10 Zwei Bedingungen mit and host 192.0.2.10 and tcp port 443 Alternative Bedingungen mit or tcp port 80 or tcp port 443 Bedingung ausschließen not port 22 Gruppierung mit Klammern host 192.0.2.10 and (tcp port 80 or tcp port 443) Filter mit Leerzeichen, Klammern oder Shell-Sonderzeichen sollten immer in einfache Anführungszeichen gesetzt werden: sudo tcpdump -i eth0 -nn 'host 192.0.2.10 and (tcp port 80 or tcp port 443)' Dadurch wird verhindert, dass die Shell Zeichen wie ( , ) , ! , & oder | selbst interpretiert. 7. Welche Host-, Netz- und Richtungsfilter gibt es? Host- und Netzfilter anzeigen Aufgabe Filter Host als Quelle oder Ziel host 192.0.2.10 Nur Pakete von einem Host src host 192.0.2.10 Nur Pakete zu einem Host dst host 192.0.2.10 Einer von zwei Hosts host 192.0.2.10 or host 198.51.100.20 Kommunikation zwischen zwei Hosts host 192.0.2.10 and host 198.51.100.20 Host ausschließen not host 192.0.2.10 IPv4-Netz net 192.0.2.0/24 Nur Quelle aus einem Netz src net 192.0.2.0/24 Nur Ziel in einem Netz dst net 198.51.100.0/24 Netz ausschließen not net 192.0.2.0/24 Bestimmte Ethernet-Adresse ether host 00:11:22:33:44:55 Nur Ethernet-Quelle ether src 00:11:22:33:44:55 Nur Ethernet-Ziel ether dst 00:11:22:33:44:55 Kommunikation zwischen genau zwei IPv4-Systemen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 192.0.2.10 and host 198.51.100.20' Bei zwei unterschiedlichen Hosts bedeutet diese Schreibweise praktisch, dass beide Adressen im Paket vorkommen müssen: eine als Quelle und die andere als Ziel. Nur Verkehr vom Client zum Server [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 192.0.2.10 and dst host 198.51.100.20' Nur Rückverkehr [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 198.51.100.20 and dst host 192.0.2.10' 8. Welche Protokoll- und Portfilter werden häufig verwendet? Protokoll- und Portfilter anzeigen Aufgabe Filter Nur IPv4 ip Nur IPv6 ip6 TCP tcp UDP udp ICMPv4 icmp ICMPv6 icmp6 ARP arp TCP- oder UDP-Port 53 port 53 Nur TCP-Port 53 tcp port 53 Nur UDP-Port 53 udp port 53 TCP-Quellport 443 tcp src port 443 TCP-Zielport 443 tcp dst port 443 Portbereich tcp portrange 8000-8100 Zielportbereich tcp dst portrange 8000-8100 TCP-Port 80 oder 443 tcp port 80 or tcp port 443 TCP-Port 22 ausschließen tcp and not port 22 Broadcastverkehr ether broadcast Multicastverkehr ether multicast Wichtiger Unterschied port 53 erfasst TCP und UDP auf Port 53. udp port 53 erfasst ausschließlich UDP auf Port 53. tcp port 53 erfasst ausschließlich TCP auf Port 53. Dieser Unterschied ist beispielsweise bei DNS wichtig, da DNS sowohl UDP als auch TCP verwenden kann. 9. Welche Filter eignen sich für typische Netzwerkprotokolle? Protokolltabelle anzeigen Protokoll oder Aufgabe Capture-Filter ARP arp ICMPv4 icmp ICMPv6 icmp6 DNS über TCP und UDP port 53 DHCPv4 udp port 67 or udp port 68 DHCPv6 udp port 546 or udp port 547 HTTP tcp port 80 HTTPS tcp port 443 HTTP und HTTPS tcp port 80 or tcp port 443 SSH tcp port 22 SMTP tcp port 25 NTP udp port 123 SNMP udp port 161 or udp port 162 LDAP tcp port 389 or udp port 389 LDAPS tcp port 636 Kerberos port 88 SMB tcp port 445 RDP tcp port 3389 or udp port 3389 SIP port 5060 or port 5061 TFTP udp port 69 WireGuard Üblicherweise der konfigurierte UDP-Port, beispielsweise udp port 51820 IPsec IKE udp port 500 or udp port 4500 VXLAN-Standardport udp port 4789 DNS-Aufzeichnung [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w dns.pcap 'port 53' DHCPv4-Aufzeichnung [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -e -w dhcp.pcap 'udp port 67 or udp port 68' SMB-Kommunikation mit einem Server [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w smb-test.pcap 'host 198.51.100.20 and tcp port 445' Portfilter zeigen Verkehr auf den angegebenen Ports. Sie beweisen nicht automatisch, dass der Verkehr tatsächlich das erwartete Anwendungsprotokoll enthält. 10. Wie werden TCP-Verbindungsaufbau und Verbindungsabbruch gefiltert? TCP-Flag-Filter anzeigen Die TCP-Steuerflags befinden sich im TCP-Header. Mit tcp[tcpflags] lassen sie sich gezielt prüfen. Aufgabe Capture-Filter Alle Pakete mit gesetztem SYN tcp[tcpflags] & tcp-syn != 0 Initiales SYN ohne ACK `tcp[tcpflags] & (tcp-syn SYN und ACK gesetzt `tcp[tcpflags] & (tcp-syn Pakete mit RST tcp[tcpflags] & tcp-rst != 0 Pakete mit FIN tcp[tcpflags] & tcp-fin != 0 Pakete mit PSH tcp[tcpflags] & tcp-push != 0 Neue TCP-Verbindungsversuche anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' SYN/ACK-Antworten anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' TCP-Resets anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' Nur TCP-Resets eines bestimmten Servers [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 198.51.100.20 and tcp[tcpflags] & tcp-rst != 0' Interpretation Beobachtung Mögliche Bedeutung Wiederholte SYN-Pakete ohne SYN/ACK Keine Antwort sichtbar, Paketverlust, Firewall, Routing- oder Serverproblem SYN wird mit RST beantwortet System erreichbar, aber Port geschlossen oder Verbindung abgelehnt SYN/ACK erreicht Client nicht Rückweg, Firewall, asymmetrisches Routing oder Aufzeichnungspunkt prüfen RST während bestehender Verbindung Endpunkt oder Zwischensystem bricht die TCP-Verbindung ab FIN-Sequenz Regulärer geordneter Verbindungsabbau möglich tcpdump kennzeichnet Wiederholungsübertragungen nicht so komfortabel wie Wireshark. Für eine detaillierte TCP-Analyse sollte die Datei anschließend mit Wireshark oder TShark untersucht werden. 11. Wie werden Paketgrößen gefiltert? Längenfilter anzeigen Aufgabe Filter Pakete kleiner oder gleich 100 Byte less 100 Pakete größer oder gleich 1500 Byte greater 1500 TCP-Pakete größer oder gleich 1500 Byte tcp and greater 1500 UDP-Pakete kleiner oder gleich 100 Byte udp and less 100 Große IPv4-Pakete anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'ip and greater 1500' Bei less und greater ist zu beachten: less N bedeutet kleiner oder gleich N ; greater N bedeutet größer oder gleich N ; die Paketlänge allein beweist noch kein MTU-Problem; VLAN-, Tunnel- und Link-Layer-Header beeinflussen die beobachtete Größe; Fragmentierung und Path-MTU-Discovery müssen getrennt untersucht werden. 12. Wie werden VLAN-Pakete gefiltert? VLAN-Filter und Fallstricke anzeigen Pakete mit 802.1Q-VLAN-Tag vlan Bestimmte VLAN-ID vlan 100 IPv4-Verkehr im VLAN 100 vlan 100 and ip HTTPS-Verkehr im VLAN 100 vlan 100 and tcp port 443 Aufzeichnung [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -e -w vlan100.pcap 'vlan 100' Die Option -e zeigt bei der Textausgabe den Link-Layer-Header an und kann dadurch VLAN- und MAC-Informationen sichtbar machen. Wichtige Einschränkungen Netzwerkkarten können VLAN-Tags per Hardware-Offloading entfernen oder separat an das Betriebssystem übergeben. Ein auf dem Endgerät fehlender VLAN-Tag beweist deshalb nicht automatisch, dass auf dem Kabel kein VLAN-Tag vorhanden war. Access-Ports liefern dem Endgerät normalerweise ungetaggte Frames. Trunk-Ports können mehrere getaggte VLANs transportieren. Bei mehrfach getaggten Frames kann ein weiterer vlan -Ausdruck erforderlich sein. Beispiel für doppelte VLAN-Kapselung: vlan 100 and vlan 200 Ob diese Pakete am gewählten Aufzeichnungspunkt sichtbar sind, hängt von Netzwerkkarte, Treiber, Offloading und Switch-Konfiguration ab. 13. Wie wird die Textausgabe sinnvoll formatiert? Ausgabeoptionen und Beispiele anzeigen Numerische Ausgabe mit Datum und Uhrzeit [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -tttt MAC-Adressen anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e Ausführliche Ausgabe [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -vv Hexadezimal- und ASCII-Ausgabe [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10 Link-Layer-Header, Hexadezimal- und ASCII-Daten [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -XX -c 10 Kurzausgabe [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -q Bedeutung der Zeitoptionen Option Ausgabe Keine zusätzliche Option Uhrzeit seit Mitternacht -tt Sekunden seit Unix-Epoche -ttt Differenz zum vorherigen Paket -tttt Datum und Uhrzeit -ttttt Differenz zum ersten Paket -A , -X und -XX können sensible Nutzdaten sichtbar machen. Sie sollten nur gezielt und bei entsprechender Berechtigung verwendet werden. 14. Wie werden Mitschnittdateien gespeichert und gelesen? Dateibefehle anzeigen Pakete als Rohdaten speichern [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap Während -w verwendet wird, schreibt tcpdump die Rohpakete in die Datei. Die normale Paketbeschreibung erscheint dabei nicht automatisch im Terminal. Vorhandene Datei lesen [RO][FILE][SENS] tcpdump -nn -r capture.pcap Mit Datum und ausführlicher Ausgabe lesen [RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap Nur DNS aus einer vorhandenen Datei lesen [RO][FILE][SENS] tcpdump -nn -r capture.pcap 'port 53' Nur Verkehr eines Hosts lesen [RO][FILE][SENS] tcpdump -nn -r capture.pcap 'host 192.0.2.10' Paketanzahl einer Datei bestimmen, sofern von der installierten Version unterstützt [RO][FILE][SENS] tcpdump --count -r capture.pcap Alternativ kann das Wireshark-Werkzeug Capinfos verwendet werden: [RO][FILE][SENS] capinfos capture.pcap Datei während des Mitschnitts paketweise aktualisieren [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -U -w capture.pcap -U sorgt dafür, dass jedes empfangene Paket zeitnah in die Ausgabedatei geschrieben wird. Das kann hilfreich sein, wenn eine Aufzeichnung während eines Absturzes oder Fehlers möglichst aktuell bleiben soll. 15. Wie wird die Größe eines Mitschnitts begrenzt? Dateigröße und Ringpuffer anzeigen Nach ungefähr 100 MB eine neue Datei beginnen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100 -w capture.pcap Ohne Einheit verwendet -C Millionen Byte: 100 = 100.000.000 Byte Moderne tcpdump-Versionen unterstützen zusätzlich Einheiten: Angabe Einheit 100K 100 × 1.024 Byte 100M 100 × 1.048.576 Byte 1G 1 × 1.073.741.824 Byte Zehn Dateien mit jeweils ungefähr 100 MiB als Ringpuffer [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100M -W 10 -w capture.pcap Bei Verwendung von -C zusammen mit -W : wird nach Erreichen der Dateigröße zur nächsten Datei gewechselt; wird die Anzahl der Dateien begrenzt; beginnt tcpdump nach der letzten Datei wieder mit der ersten; werden ältere Dateien überschrieben; entsteht ein echter rotierender Ringpuffer. Ungefähre maximale Gesamtgröße 10 Dateien × 100 MiB = ungefähr 1.000 MiB Die Größenprüfung erfolgt vor dem Schreiben eines neuen Pakets. Eine Datei kann deshalb geringfügig größer als der angegebene Wert werden. 16. Wie werden Mitschnittdateien zeitgesteuert gewechselt? Zeitrotation korrekt verwenden Alle fünf Minuten eine neue Datei [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap' Beispielhafte Dateinamen: capture-20260731-140000.pcap capture-20260731-140500.pcap capture-20260731-141000.pcap Nach zwölf Fünf-Minuten-Dateien beenden [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -W 12 -w 'capture-%Y%m%d-%H%M%S.pcap' Das entspricht ungefähr: 12 Dateien × 5 Minuten = 60 Minuten Wichtiger Unterschied Kombination Verhalten -C und -W Ringpuffer; ältere Dateien werden überschrieben -G und -W Nach der festgelegten Anzahl Dateien wird tcpdump beendet -C , -G und -W gemeinsam -W begrenzt nach aktueller Dokumentation nicht zuverlässig wie bei den einzelnen Varianten und beeinflusst hauptsächlich die Dateinamen Bei -G sollte -w einen eindeutigen Zeitplatzhalter enthalten. Andernfalls kann jede neue Datei denselben Namen erhalten und die vorherige Datei überschreiben. Sicheres Beispiel -w 'capture-%Y%m%d-%H%M%S.pcap' Problematisches Beispiel -w capture.pcap 17. Wie wird die Aufzeichnungsdauer auf Linux und macOS begrenzt? Zeitlich begrenzte Aufzeichnung anzeigen tcpdump besitzt die Option -G für den Dateiw echsel, aber keine allgemeine, plattformübergreifende Option nach dem Muster „nach genau 60 Sekunden stoppen“. Linux mit GNU timeout [TEST][PRIV][FILE][SENS] sudo timeout 60 tcpdump -i eth0 -nn -w capture.pcap 'host 192.0.2.10' timeout gehört nicht zu tcpdump, sondern zu den GNU Coreutils. Der Befehl steht nicht auf jedem Unix-System standardmäßig zur Verfügung. macOS Auf macOS ist GNU timeout standardmäßig nicht vorhanden. Stattdessen sind folgende Methoden geeignet: mit -c eine maximale Paketanzahl festlegen; mit -G und -W 1 genau eine zeitlich begrenzte Datei erstellen; den Mitschnitt kontrolliert mit [Strg] + [C] beenden. macOS: nach einem Zeitintervall beenden [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn -G 60 -W 1 -w 'capture-%Y%m%d-%H%M%S.pcap' 'host 192.0.2.10' Dieser Befehl erstellt eine Aufzeichnungsdatei und beendet tcpdump nach dem ersten Rotationsintervall. Vor dem praktischen Einsatz sollte das Verhalten der lokal installierten tcpdump-Version mit einem kurzen Test geprüft werden. 18. Wie wird die Snapshot-Länge verwendet? Snapshot-Länge und Auswirkungen anzeigen Die Snapshot-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden. -s LÄNGE Beispiel: [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -s 128 -w headers.pcap Damit werden höchstens 128 Byte je Paket aufgezeichnet. Vorteile einer verkürzten Snapshot-Länge kleinere Mitschnittdateien; weniger Nutzdaten werden gespeichert; geringerer Speicherbedarf; bei sehr hohem Datenaufkommen möglicherweise weniger Verarbeitungsaufwand. Nachteile Protokollinformationen können abgeschnitten werden; Anwendungsdaten fehlen; Pakete lassen sich möglicherweise nicht vollständig analysieren; VLAN-, Tunnel- und umfangreiche Protokollheader können mehr Platz benötigen; Wireshark zeigt möglicherweise abgeschnittene Pakete an. Abgeschnittene Pakete können in der tcpdump-Ausgabe mit einer Kennzeichnung wie dieser erscheinen: [|proto] Die aktuelle tcpdump-Standard-Snapshot-Länge ist sehr groß und erfasst normalerweise das vollständige Paket. Eine kleinere Snapshot-Länge sollte nur verwendet werden, wenn klar ist, welche Header und Daten für die Diagnose benötigt werden. 19. Wie werden Paketverluste während des Mitschnitts erkannt? Capture-Drops und Gegenmaßnahmen anzeigen Beim Beenden zeigt tcpdump normalerweise unter anderem: packets captured packets received by filter packets dropped by kernel Bewertung Zähler Bedeutung packets captured Von tcpdump empfangene und verarbeitete Pakete packets received by filter Betriebssystemabhängiger Zähler des Capture-Mechanismus packets dropped by kernel Wegen fehlenden Capture-Pufferplatzes verworfene Pakete Sind Kernel-Drops vorhanden, können folgende Maßnahmen helfen: Capture-Filter enger setzen. Mitschnitt auf eine Datei schreiben statt alles im Terminal auszugeben. Ausgabeoptionen wie -A , -X , -XX oder -vvv während des Live-Mitschnitts vermeiden. Capture-Puffer vorsichtig vergrößern. Snapshot-Länge nur bei fachlicher Begründung verkleinern. Auf einem leistungsfähigeren oder geeigneteren System mitschneiden. Festplattenleistung und freien Speicherplatz prüfen. Netzwerk-TAP oder spezielle Capture-Hardware verwenden. Capture-Puffer beispielsweise auf 4.096 KiB setzen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -B 4096 -w capture.pcap Ein größerer Puffer garantiert keinen verlustfreien Mitschnitt. Der Wert muss zum Betriebssystem, Datenaufkommen und verfügbaren Speicher passen. 20. Warum zeigt tcpdump manchmal fehlerhafte Prüfsummen an? Checksum-Offloading erklären Netzwerkkarten können Prüfsummenberechnungen für IP, TCP oder UDP übernehmen. Bei ausgehenden Paketen kann tcpdump das Paket erfassen, bevor die Netzwerkkarte die endgültige Prüfsumme eingesetzt hat. Dadurch kann tcpdump scheinbar fehlerhafte Prüfsummen anzeigen, obwohl das Paket korrekt übertragen wurde. Prüfsummenprüfung bei der Anzeige deaktivieren [RO][FILE][SENS] tcpdump -K -nn -r capture.pcap Live: [TEST][PRIV][SENS] sudo tcpdump -i eth0 -K -nn -K verhindert lediglich die Prüfsummenprüfung durch tcpdump. Es repariert keine Pakete und verändert nicht die Netzwerkkonfiguration. Sinnvolle Prüfung Mitschnitt auf der empfangenden Gegenstelle vergleichen; Netzwerkpfad oder TAP untersuchen; Offloading-Einstellungen dokumentieren; einen angezeigten Prüfsummenfehler nicht ohne weitere Prüfung als Netzwerkdefekt bewerten. Das Deaktivieren von Hardware-Offloading wäre eine Systemänderung und kann Leistung oder Verhalten beeinflussen. Es gehört deshalb nicht zu den ersten Diagnosemaßnahmen. 21. Wie wird eingehender oder ausgehender Verkehr gefiltert? Richtungsfilter anzeigen Auf unterstützten Plattformen kann -Q verwendet werden: Option Bedeutung -Q in Nur eingehender Verkehr -Q out Nur ausgehender Verkehr -Q inout Beide Richtungen Nur eingehende Pakete [TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q in -nn Nur ausgehende DNS-Pakete [TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q out -nn 'port 53' -Q wird nicht auf jeder Plattform und nicht von jeder Capture-Schnittstelle unterstützt. Eine portablere Alternative besteht darin, Quell- und Zieladresse ausdrücklich zu filtern: src host 192.0.2.10 oder: dst host 192.0.2.10 Dabei wird die Richtung anhand der Paketadressen und nicht anhand der Betriebssystem-Schnittstellenrichtung bestimmt. 22. Wie wird ein Filter vor dem eigentlichen Mitschnitt geprüft? Filtertest und Fehlermeldungen anzeigen Ein falsch formulierter Filter kann dazu führen, dass tcpdump nicht startet oder unerwartete Pakete erfasst. Kurzer Praxistest [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 10 'host 192.0.2.10 and tcp port 443' Kompilierten BPF-Code anzeigen [RO][PRIV] sudo tcpdump -i eth0 -d 'host 192.0.2.10 and tcp port 443' -d kompiliert den Filter, gibt die resultierenden BPF-Anweisungen lesbar aus und beendet tcpdump, ohne einen normalen Mitschnitt zu starten. Filter aus einer Datei lesen Beispielinhalt einer autorisiert erstellten Filterdatei: host 192.0.2.10 and (tcp port 80 or tcp port 443) Filterdatei verwenden: [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -F capture-filter.txt Wird -F verwendet, wird ein zusätzlicher Filterausdruck auf der Kommandozeile ignoriert. Deshalb sollte nicht gleichzeitig ein weiterer Filter hinter dem Befehl angegeben werden. 23. Welche typischen Fehler treten bei tcpdump auf? Fehlertabelle anzeigen Fehler oder Beobachtung Wahrscheinliche Erklärung Prüfung tcpdump: command not found tcpdump nicht installiert oder nicht im Suchpfad command -v tcpdump You don't have permission to capture Capture-Berechtigung fehlt Berechtigungen und Sicherheitsrichtlinie prüfen Keine Pakete sichtbar Falsche Schnittstelle oder zu enger Filter tcpdump -D , Kontrollmitschnitt ohne Filter Namen statt IP-Adressen Namensauflösung aktiv -nn verwenden Mitschnittdatei wächst unbegrenzt Keine Größen- oder Zeitbegrenzung -C , -W oder -G verwenden Nur eine Datei trotz -G Dateiname enthält keinen eindeutigen Zeitplatzhalter Zeitformat in -w ergänzen Alte Dateien werden überschrieben Ringpuffer aktiv oder Dateiname nicht eindeutig Optionen und Zielverzeichnis prüfen Hohe Anzahl dropped by kernel Capture-Puffer oder Systemleistung reicht nicht Filter, -B , Ausgabe und Speicher prüfen bad udp cksum oder ähnliche Meldung Möglicherweise Checksum Offloading Gegenstelle vergleichen oder Anzeige mit -K prüfen Pakete erscheinen abgeschnitten Snapshot-Länge zu klein -s -Einstellung prüfen VLAN-Tag fehlt Access-Port oder Hardware-Offloading Switch-Port, Treiber und Gegenmitschnitt prüfen Fremder Unicastverkehr fehlt Switch sendet ihn nicht an diesen Port Autorisierten SPAN-Port oder TAP verwenden Filter funktioniert in Wireshark, aber nicht in tcpdump Display-Filter mit Capture-Filter verwechselt libpcap-Syntax verwenden SSH-Mitschnitt enthält überwiegend eigene Sitzung Administrationsverbindung wird mitgeschnitten Eigene SSH-Verbindung gezielt ausschließen Eigene SSH-Sitzung ausschließen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not tcp port 22' Dieser Filter schließt allerdings sämtlichen TCP-Verkehr auf Port 22 aus. Falls SSH selbst untersucht werden soll, darf dieser Filter nicht verwendet werden. 24. Wie wird tcpdump über SSH sicher eingesetzt? Remote-Diagnose anzeigen Beim Start von tcpdump über SSH wird auch die eigene SSH-Verbindung sichtbar, sofern sie den untersuchten Netzwerkpfad verwendet. Eigene SSH-Verbindung ausschließen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not tcp port 22' Besser ist ein genauer Ausschluss, wenn die Managementadresse bekannt ist: [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not (host 192.0.2.50 and tcp port 22)' Dabei ist 192.0.2.50 beispielhaft die autorisierte Managementstation. Risiken einer Remote-Sitzung die eigene SSH-Verbindung kann den Mitschnitt vergrößern; die Mitschnittdatei kann auf einem produktiven Server Speicherplatz belegen; ein Verbindungsabbruch kann einen unbegrenzt gestarteten Mitschnitt weiterlaufen lassen; eine Shell-Pipe kann sensible Paketdaten über die Administrationsverbindung übertragen. Deshalb sollten mindestens eine dieser Begrenzungen verwendet werden: Paketanzahl mit -c ; Dateigröße mit -C ; Ringpuffer mit -C und -W ; zeitliche Begrenzung mit -G und -W ; enger Capture-Filter. Nach der Diagnose muss geprüft werden, ob tcpdump noch läuft: [RO] pgrep -a tcpdump Dieser Befehl ist auf Linux üblich. Die genaue Verfügbarkeit ist betriebssystemabhängig. 25. Wie werden Container- und VM-Verbindungen untersucht? Virtuelle Netzwerke und Namespaces anzeigen Bei Containern und virtuellen Maschinen kann der Verkehr an mehreren Stellen sichtbar sein: Anwendung ↓ Container- oder Gast-Schnittstelle ↓ virtuelle Bridge oder virtueller Switch ↓ Host-Schnittstelle ↓ physisches Netzwerk Typische Linux-Schnittstellen Schnittstelle Bedeutung docker0 Standard-Docker-Bridge br-... Benutzerdefinierte Docker-Bridge veth... Virtuelles Ethernet-Paar eines Containers virbr0 Häufige libvirt-Bridge tap... Virtuelle TAP-Schnittstelle eth0 oder ens... Physische oder virtuelle Host-Schnittstelle Schnittstellen anzeigen [RO] ip link show [RO] tcpdump -D Docker-Bridge untersuchen [TEST][PRIV][FILE][SENS] sudo tcpdump -i docker0 -nn -w docker-bridge.pcap Host-Schnittstelle und Container-IP filtern [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn -w container-test.pcap 'host 192.0.2.10' Ein Mitschnitt innerhalb eines Containers benötigt zusätzliche Berechtigungen wie Netzwerk-Capabilities und erweitert die Angriffsfläche. Wenn möglich, sollte deshalb auf dem autorisierten Container-Host oder an der Bridge aufgezeichnet werden. Bei Kubernetes, Overlay-Netzen, VXLAN und Service-Proxys kann die sichtbare Adresse je nach Aufzeichnungspunkt durch NAT oder Kapselung verändert sein. 26. Wie sieht ein systematischer Diagnoseablauf mit tcpdump aus? Empfohlene Schrittfolge anzeigen Vorbereitung Störung, Sollzustand und Fehlerzeitpunkt dokumentieren. Client, Server, IP-Adressen, Ports und Protokolle ermitteln. Den erwarteten Netzwerkpfad bestimmen. Berechtigung für den Mitschnitt prüfen. Systemzeit und Zeitzone kontrollieren. Freien Speicherplatz prüfen. Schutzbedarf der Mitschnittdatei festlegen. Schnittstelle prüfen Verfügbare Schnittstellen mit tcpdump -D anzeigen. Einen kurzen Kontrollmitschnitt ohne engen Filter durchführen. Mit einem bekannten Test prüfen, ob die richtige Schnittstelle ausgewählt wurde. Mitschnitt planen Einen möglichst gezielten Capture-Filter formulieren. Filter mit einer kleinen Paketanzahl testen. Paket-, Größen- oder Zeitbegrenzung festlegen. Dateinamen, Zielverzeichnis und Berechtigungen prüfen. Mitschnitt durchführen tcpdump starten. Fehler genau einmal reproduzieren. Start- und Endzeit notieren. Mitschnitt kontrolliert beenden. Capture-Zähler und Kernel-Drops prüfen. Kontrollieren, ob tcpdump noch läuft. Analyse Datei zunächst mit tcpdump -nn -r prüfen. Dateieigenschaften mit capinfos kontrollieren. Datei anschließend in Wireshark oder TShark öffnen. Kommunikationsrichtung, TCP-Handshake, DNS, TLS und Anwendung untersuchen. Zeitstempel mit System-, Firewall- und Anwendungslogs vergleichen. Validierung Beobachtung und vermutete Ursache getrennt dokumentieren. Hypothese durch einen gezielten Vergleichstest prüfen. Falls erforderlich, an einem zweiten Punkt mitschneiden. Nach einer Änderung denselben Test erneut durchführen. Nicht mehr benötigte Mitschnittdateien gemäß Richtlinie löschen. 27. Kurzreferenz – tcpdump-Befehle Befehlstabelle anzeigen Aufgabe Befehl Version anzeigen [RO] tcpdump --version Schnittstellen anzeigen [RO] tcpdump -D 20 Pakete anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20 100 Pakete speichern [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap Alle regulären Schnittstellen [TEST][PRIV][SENS] sudo tcpdump -i any -nn Datei lesen [RO][FILE][SENS] tcpdump -nn -r capture.pcap Datei ausführlich lesen [RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap MAC-Adressen anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e Hex und ASCII anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10 Host filtern [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 192.0.2.10' HTTPS filtern [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp port 443' DNS filtern [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'port 53' Initiale TCP-SYN-Pakete [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' TCP-RST-Pakete [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' Ringpuffer nach Größe [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100M -W 10 -w capture.pcap Dateien alle fünf Minuten [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap' Nach zwölf Zeitdateien stoppen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -W 12 -w 'capture-%Y%m%d-%H%M%S.pcap' Capture-Puffer setzen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -B 4096 -w capture.pcap Datei sofort aktualisieren [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -U -w capture.pcap 28. Kurzreferenz – Capture-Filter Filtertabelle anzeigen Aufgabe Filter IPv4 ip IPv6 ip6 TCP tcp UDP udp ARP arp ICMPv4 icmp ICMPv6 icmp6 Host host 192.0.2.10 Quellhost src host 192.0.2.10 Zielhost dst host 192.0.2.10 IPv4-Netz net 192.0.2.0/24 Ethernet-Adresse ether host 00:11:22:33:44:55 TCP- oder UDP-Port port 53 TCP-Port tcp port 443 UDP-Port udp port 123 Zielport tcp dst port 443 Portbereich tcp portrange 8000-8100 DHCPv4 udp port 67 or udp port 68 DHCPv6 udp port 546 or udp port 547 HTTP oder HTTPS tcp port 80 or tcp port 443 Initiales TCP-SYN tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn TCP-RST tcp[tcpflags] & tcp-rst != 0 VLAN 100 vlan 100 Broadcast ether broadcast Multicast ether multicast Große Pakete greater 1500 SSH ausschließen not tcp port 22 Host und HTTPS host 192.0.2.10 and tcp port 443 Host und zwei Ports host 192.0.2.10 and (tcp port 80 or tcp port 443) Merksätze tcpdump verwendet Capture-Filter und keine Wireshark-Display-Filter. Capture-Filter bestimmen, welche Pakete überhaupt verarbeitet und gespeichert werden. Filterausdrücke sollten in einfache Anführungszeichen gesetzt werden. -nn verhindert störende Namens- und Dienstauflösungen. -w schreibt Rohpakete und keinen normalen Textbericht. -r liest eine vorhandene Mitschnittdatei. -C zusammen mit -W erzeugt einen größenbasierten Ringpuffer. -G zusammen mit -W beendet tcpdump nach der festgelegten Anzahl Zeitdateien und ist kein Ringpuffer. packets dropped by kernel weist auf einen möglicherweise unvollständigen Mitschnitt hin. Scheinbar fehlerhafte Prüfsummen können durch Hardware-Offloading entstehen. Ein fehlendes Paket ist nur aussagekräftig, wenn Schnittstelle, Aufzeichnungspunkt und Filter nachweislich richtig waren. Paketmitschnitte sind sensible Diagnosedaten und müssen entsprechend geschützt werden. Quellen Offizielles tcpdump-Projekt Offizieller tcpdump-Quellcode und Dokumentation Offizielle tcpdump-Manpage im Quellcode Offizielles libpcap-Projekt Offizielle pcap-filter-Manpage im libpcap-Quellcode Wireshark User’s Guide – Capture Filters Offizielle TShark-Dokumentation Offizielle Capinfos-Dokumentation 2.7 Nmap im autorisierten Netz – Hosts, Ports und Dienste untersuchen Ziel dieser Seite Nmap ist ein Werkzeug zur aktiven Netzwerkerkundung und Portanalyse. Administratoren können damit unter anderem prüfen: welche Systeme in einem autorisierten Netz erreichbar sind; welche TCP- und UDP-Ports antworten; welche Dienste an diesen Ports angeboten werden; welche Dienstversionen wahrscheinlich verwendet werden; ob eine Firewall Pakete verwirft oder zurückweist; ob ein Dienst nur lokal oder auch aus einem anderen Netzsegment erreichbar ist; ob sich die Erreichbarkeit nach einer Änderung verbessert oder verschlechtert hat; ob ein dokumentierter Sollzustand mit dem tatsächlich sichtbaren Zustand übereinstimmt. Nmap sendet aktiv Pakete oder Verbindungsversuche an Zielsysteme. Es ist daher kein rein passives Diagnosewerkzeug. Nmap darf ausschließlich gegen eigene Systeme oder mit eindeutiger Genehmigung des zuständigen Betreibers verwendet werden. Vor einem Scan müssen Zielbereich, Zeitraum, Scanart, Quellsystem und zulässige Intensität festgelegt werden. Kennzeichnungen Kennzeichnung Bedeutung [RO] Lokale Abfrage ohne Netzwerkprüfung [TEST] Aktiver Netzwerk- oder Diensttest [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Befehl erstellt oder verarbeitet Dateien [SENS] Ausgabe kann sensible Infrastrukturinformationen enthalten [DISRUPT] Test kann Dienste, Geräte oder Überwachungssysteme belasten [CHANGE] Befehl verändert eine Einstellung oder Datei 1. Wofür sollte Nmap in der Fehleranalyse verwendet werden? Geeignete und ungeeignete Einsatzbereiche anzeigen Geeignete administrative Aufgaben Aufgabe Beispiel Einzelnen Dienst prüfen Ist TCP-Port 443 vom Clientnetz erreichbar? Erreichbare Systeme erfassen Welche freigegebenen Testsysteme antworten im VLAN? Firewalländerung kontrollieren Ist der freigegebene Port nach der Regeländerung erreichbar? Dienstinventar vergleichen Stimmen offene Ports mit der Dokumentation überein? Dienstidentifikation Welcher Dienst antwortet tatsächlich auf einem Port? TCP und UDP unterscheiden Antwortet nur TCP oder auch UDP? Erreichbarkeit aus verschiedenen Segmenten vergleichen Ist der Dienst intern erreichbar, aus dem Gastnetz aber gefiltert? Fehlerzustand dokumentieren Welche Ergebnisse waren vor und nach einer Änderung sichtbar? Nmap ist nicht geeignet für Scans fremder öffentlicher Systeme ohne Erlaubnis; unkontrollierte Scans kompletter Unternehmensnetze; das Umgehen von Firewalls oder Überwachungssystemen; Verschleierungs-, Spoofing- oder Tarntechniken im normalen Administrationsbetrieb; Brute-Force-, Exploit- oder Denial-of-Service-Tests; den Nachweis, dass ein Dienst fachlich korrekt funktioniert; die alleinige Entscheidung, ob ein System sicher ist. Ein offener Port beweist nur, dass aus Sicht des Scanstandorts eine entsprechende Antwort empfangen wurde. Er beweist nicht, dass: die Anwendung vollständig funktioniert; die Anwendung korrekt konfiguriert ist; eine Benutzeranmeldung möglich ist; der Dienst keine Sicherheitslücken besitzt; alle Clients denselben Netzwerkpfad verwenden. 2. Wie wird Nmap auf Windows, Linux und macOS geprüft? Installations- und Versionsprüfung anzeigen Aufgabe Windows Linux macOS Programmpfad suchen [RO] Get-Command nmap [RO] command -v nmap [RO] command -v nmap Version anzeigen [RO] nmap --version [RO] nmap --version [RO] nmap --version Hilfe anzeigen [RO] nmap -h [RO] nmap -h [RO] nmap -h Lokale Handbuchseite Nicht standardmäßig vorhanden [RO] man nmap [RO] man nmap Windows Die offizielle Windows-Installation von Nmap verwendet normalerweise Npcap für Raw-Packet-Funktionen. Für bestimmte Scanarten sollte PowerShell oder die Eingabeaufforderung als Administrator gestartet werden. Linux und macOS Scanarten, die Raw-IP-Pakete verwenden, benötigen normalerweise erhöhte Rechte: [TEST][PRIV][SENS] sudo nmap -sS -p 443 192.0.2.10 Ein TCP-Connect-Scan kann gewöhnlich ohne erhöhte Rechte ausgeführt werden: [TEST][SENS] nmap -sT -p 443 192.0.2.10 Die tatsächlich verfügbaren Funktionen hängen von Betriebssystem, Nmap-Version, Rechten und Paket-Capture-Treiber ab. 3. Welche Freigaben müssen vor einem Scan vorliegen? Autorisierungscheckliste anzeigen Vor einem Scan sollten mindestens folgende Punkte dokumentiert sein: Punkt Beispiel Auftraggeber Zuständige IT-Abteilung Zielsystem 192.0.2.10 Zielnetz 192.0.2.0/28 Erlaubte Ports TCP 22, 80 und 443 Erlaubte Scanarten Host Discovery, TCP Connect, Versionserkennung Scanquelle Administrationssystem 192.0.2.50 Zeitraum 14:00–14:15 Uhr Verantwortliche Kontaktperson Max Mustermann Abbruchkriterium Dienstfehler, hohe Last oder Alarmmeldung Protokollierung Ausgabe als normale, XML- und grepbare Datei Erwarteter Sollzustand TCP 443 offen, TCP 22 gefiltert Vor dem Start klären Befinden sich empfindliche Altgeräte im Zielbereich? Sind Drucker, Telefonanlagen, Kameras, Steuerungen oder medizinische Geräte betroffen? Gibt es Intrusion-Detection- oder Intrusion-Prevention-Systeme? Muss das Security Operations Center informiert werden? Gibt es eine maximale Scanrate? Darf eine Dienst- oder Betriebssystemerkennung durchgeführt werden? Dürfen NSE-Skripte verwendet werden? Wie lange dürfen Ergebnisse gespeichert werden? Die Erlaubnis, einen einzelnen Server zu prüfen, ist keine Erlaubnis zum Scan des gesamten Subnetzes. 4. Wie werden Zielsysteme sicher angegeben? Zielspezifikation anzeigen Zielart Beispiel Einzelne IPv4-Adresse 192.0.2.10 Mehrere einzelne Ziele 192.0.2.10 192.0.2.20 DNS-Name server.example.com CIDR-Netz 192.0.2.0/28 IPv4-Adressbereich 192.0.2.10-20 IPv6-Adresse 2001:db8::10 Ziele aus einer Datei -iL targets.txt Bestimmtes Ziel ausschließen --exclude 192.0.2.15 Ausschlussliste verwenden --excludefile excluded.txt Einzelnes Ziel [TEST][SENS] nmap 192.0.2.10 Kleines, ausdrücklich freigegebenes Netz [TEST][SENS] nmap 192.0.2.0/28 IPv6-Ziel [TEST][SENS] nmap -6 2001:db8::10 Ziele aus einer autorisiert erstellten Datei [TEST][FILE][SENS] nmap -iL targets.txt Zielbereich nur auflösen und auflisten, ohne Zielpakete zu senden [RO][SENS] nmap -sL 192.0.2.0/28 -sL führt einen List Scan durch. Dabei werden die Ziele aufgelistet und standardmäßig gegebenenfalls Reverse-DNS-Abfragen durchgeführt. Es findet kein normaler Host- oder Portscan gegen die Zielsysteme statt. Ohne DNS-Auflösung auflisten [RO][SENS] nmap -sL -n 192.0.2.0/28 Das Auflisten des Zielbereichs vor dem aktiven Scan hilft, fehlerhafte CIDR-Angaben frühzeitig zu erkennen. 5. Wie wird geprüft, welche Hosts erreichbar sind? Host Discovery anzeigen Nur Host-Erkennung, ohne Portscan [TEST][SENS] nmap -sn 192.0.2.0/28 -sn deaktiviert den anschließenden Portscan. Nmap führt aber weiterhin aktive Host-Erkennungsprüfungen durch. Ohne Namensauflösung [TEST][SENS] nmap -sn -n 192.0.2.0/28 Grund für die Bewertung anzeigen [TEST][SENS] nmap -sn --reason 192.0.2.0/28 Lokales Ethernet-Netz Im lokalen Ethernet-Netz verwendet Nmap für die Host-Erkennung normalerweise ARP beziehungsweise bei IPv6 Neighbor Discovery. Das ist häufig zuverlässiger als ein einfacher ICMP-Echo-Test. Gezielte ICMP-Echo-Erkennung [TEST][PRIV][SENS] sudo nmap -sn -PE 192.0.2.0/28 TCP-SYN-Erkennung auf freigegebenen Ports [TEST][PRIV][SENS] sudo nmap -sn -PS22,80,443 192.0.2.0/28 TCP-ACK-Erkennung [TEST][PRIV][SENS] sudo nmap -sn -PA80,443 192.0.2.0/28 UDP-Erkennung auf einem gezielt freigegebenen Port [TEST][PRIV][SENS] sudo nmap -sn -PU53 192.0.2.0/28 Wichtige Interpretation Ergebnis Aussage Host is up Nmap hat eine als Erreichbarkeitsnachweis bewertete Antwort erhalten Kein Hosteintrag Keine ausreichende Antwort empfangen ICMP antwortet nicht Host kann trotzdem über TCP oder UDP erreichbar sein ARP-Antwort im lokalen Netz Gerät ist auf Layer 2 erreichbar Hohe Latenz Kann durch Netzwerk, Zielsystem oder Scanverfahren entstehen Ein fehlender Hosttreffer beweist nicht, dass das System ausgeschaltet ist. Firewalls können die für die Erkennung verwendeten Pakete verwerfen. 6. Was bedeutet -Pn , und wann sollte es verwendet werden? Portscan ohne vorherige Host-Erkennung anzeigen Mit -Pn behandelt Nmap die angegebenen Ziele als erreichbar und überspringt die normale Host-Erkennung. [TEST][SENS] nmap -Pn -p 443 192.0.2.10 Sinnvoller Einsatz der Host ist nachweislich aktiv; ICMP und andere Discovery-Pakete werden gefiltert; ein bestimmter Port soll unabhängig von der Host-Erkennung geprüft werden; nur ein einzelnes oder sehr kleines freigegebenes Ziel wird untersucht. Auswirkung Ohne erfolgreiche Host-Erkennung würde Nmap möglicherweise melden: Host seems down. Mit -Pn wird der Portscan trotzdem durchgeführt. Risiko bei großen Zielbereichen nmap -Pn 192.0.2.0/16 Dieser Scan würde jedes Ziel im Bereich als aktiv behandeln und entsprechend prüfen. Das kann sehr lange dauern und erhebliche Netzlast oder Sicherheitsmeldungen verursachen. -Pn sollte nicht pauschal für große Netze verwendet werden. Es eignet sich hauptsächlich für bekannte, ausdrücklich freigegebene Einzelziele oder kleine Zielgruppen. 7. Welche Portzustände zeigt Nmap an? Portzustände und Bedeutung anzeigen Zustand Bedeutung open Eine Anwendung nimmt an diesem Port Verbindungen oder Pakete an closed Ziel ist erreichbar, aber an diesem Port antwortet kein Dienst filtered Nmap kann wegen eines Filters oder Netzwerkhindernisses nicht bestimmen, ob der Port offen oder geschlossen ist unfiltered Port ist erreichbar, der verwendete Scan kann aber nicht zwischen offen und geschlossen unterscheiden open|filtered Nmap kann nicht zwischen offen und gefiltert unterscheiden closed|filtered Nmap kann nicht zwischen geschlossen und gefiltert unterscheiden Wichtig filtered bedeutet nicht automatisch: Eine Firewall auf dem Zielsystem blockiert den Port. Mögliche Ursachen sind unter anderem: Host-Firewall; Netzwerk-Firewall; Access Control List; Routerfilter; Security Group; Paketverlust; asymmetrisches Routing; IPS oder Rate Limiting; falscher Rückweg; unvollständige Scanantwort. Mit --reason zeigt Nmap an, auf welcher Antwort oder Nichtantwort die Bewertung beruht: [TEST][SENS] nmap --reason -p 22,80,443 192.0.2.10 8. Welche Ports scannt Nmap standardmäßig? Portauswahl anzeigen Ohne ausdrückliche Portangabe untersucht Nmap standardmäßig die 1.000 häufigsten Ports des jeweiligen gescannten Protokolls. Es handelt sich nicht automatisch um alle 65.535 TCP-Ports. Bestimmte Ports [TEST][SENS] nmap -p 22,80,443 192.0.2.10 Portbereich [TEST][SENS] nmap -p 8000-8100 192.0.2.10 Alle TCP-Ports [TEST][SENS] nmap -p- 192.0.2.10 -p- steht für die Ports 1 bis 65.535. Ein vollständiger Portscan ist wesentlich umfangreicher als ein Standardscan und muss ausdrücklich freigegeben sein. Die häufigsten 100 Ports [TEST][SENS] nmap --top-ports 100 192.0.2.10 Schneller Scan der häufigsten Ports [TEST][SENS] nmap -F 192.0.2.10 -F reduziert die Anzahl der normalerweise untersuchten Ports. Die genaue Portauswahl hängt von der lokalen Nmap-Dienstdatenbank ab. Nur offene Ports anzeigen [TEST][SENS] nmap --open -p 22,80,443,445,3389 192.0.2.10 --open verkürzt die Ausgabe. Für die Fehleranalyse können geschlossene und gefilterte Ports jedoch wichtige Informationen liefern. Die vollständige Ausgabe sollte deshalb häufig bevorzugt werden. 9. Was ist ein TCP-Connect-Scan? TCP-Connect-Scan `-sT` anzeigen Der TCP-Connect-Scan verwendet die normale connect() -Funktion des Betriebssystems. Er kann gewöhnlich ohne Raw-Packet-Rechte ausgeführt werden. [TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10 Eigenschaften Eigenschaft TCP Connect Option -sT Erhöhte Rechte Normalerweise nicht erforderlich Verbindung Vollständiger TCP-Verbindungsaufbau zu offenen Ports Protokollierung am Ziel Wahrscheinlich Eignung Funktionale Erreichbarkeitsprüfung einzelner TCP-Ports Belastung Bei wenigen Ports normalerweise gering, aber aktiv Einzelnen HTTPS-Port prüfen [TEST][SENS] nmap -sT -Pn -p 443 --reason 192.0.2.10 Da bei offenen Ports eine vollständige Verbindung aufgebaut wird, kann der Zielserver den Versuch in seinen Logs erfassen. Für einen gezielten administrativen Funktionstest ist das nicht grundsätzlich nachteilig: Der Scan soll nachvollziehbar und autorisiert sein. 10. Was ist ein TCP-SYN-Scan? TCP-SYN-Scan `-sS` anzeigen Beim SYN-Scan sendet Nmap ein TCP-SYN-Paket, ohne bei einem offenen Port eine vollständige Anwendungssitzung aufzubauen. [TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10 Typische Antworten Antwort Nmap-Bewertung SYN/ACK open RST closed Keine Antwort nach Wiederholungen filtered Bestimmte ICMP-Unreachable-Antwort filtered Eigenschaften Eigenschaft TCP SYN Option -sS Erhöhte Rechte Auf Unix-Systemen normalerweise erforderlich Vollständige TCP-Verbindung Nein Unterscheidung open , closed , filtered Eignung Kontrollierte Portprüfung im autorisierten Netz Der Ausdruck „halb offen“ bedeutet nicht, dass der Scan unsichtbar ist. Firewalls, IDS, IPS und Zielsysteme können SYN-Scans erkennen und protokollieren. 11. Wie werden UDP-Dienste geprüft? UDP-Scan `-sU` anzeigen UDP ist verbindungslos. Ein fehlendes Antwortpaket lässt deshalb häufig keine eindeutige Entscheidung zu. Gezielter UDP-Scan [TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10 Mit Begründung und Versionserkennung [TEST][PRIV][SENS] sudo nmap -sU -sV --reason -p 53,123,161 192.0.2.10 Typische Ergebnisse Antwort Mögliche Bewertung Gültige UDP-Antwort open ICMP Port Unreachable closed Bestimmte andere ICMP-Fehler filtered Keine Antwort open|filtered Warum UDP-Scans länger dauern viele offene UDP-Dienste antworten nur auf gültige Protokollanfragen; gefilterte Pakete erzeugen häufig keine Antwort; ICMP-Fehlermeldungen können begrenzt werden; Nmap muss Zeitüberschreitungen und Wiederholungen abwarten. Nur die tatsächlich benötigten Ports prüfen [TEST][PRIV][SENS] sudo nmap -sU -p 53 192.0.2.10 Ein ungeplanter Scan aller 65.535 UDP-Ports kann sehr lange dauern und unnötige Last verursachen. 12. Wie werden TCP und UDP gemeinsam untersucht? Kombinierten Scan anzeigen TCP-SYN- und UDP-Scan können kombiniert werden: [TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10 Bedeutung Ausdruck Geprüfte Ports T:53,80,443 TCP 53, 80 und 443 U:53,123 UDP 53 und 123 Ohne die Präfixe T: und U: kann die Portzuordnung bei einem kombinierten Scan missverständlich werden. DNS über TCP und UDP prüfen [TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,U:53 192.0.2.10 Ein offener TCP- und UDP-Port bestätigt noch nicht, dass DNS-Anfragen korrekt beantwortet werden. Danach sollte ein protokollspezifischer Test folgen, beispielsweise mit dig , Resolve-DnsName oder nslookup . 13. Wie werden Dienste und Versionen erkannt? Service- und Versionserkennung `-sV` anzeigen Die Versionserkennung sendet zusätzliche, teilweise protokollspezifische Anfragen an offene oder wahrscheinlich offene Ports. [TEST][SENS] nmap -sV -p 22,80,443 192.0.2.10 Leichtere Versionserkennung [TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10 Intensität festlegen [TEST][SENS] nmap -sV --version-intensity 2 -p 22,80,443 192.0.2.10 Der Wertebereich für --version-intensity reicht von 0 bis 9 : Intensität Verhalten 0 Nur wenige, besonders wahrscheinliche Prüfungen 2 Reduzierte, häufig ausreichende Prüfung 7 Standardintensität 9 Alle verfügbaren Versionserkennungs-Probes Interpretation 443/tcp open https nginx 1.24.0 Dabei sind zu unterscheiden: Feld Aussage 443/tcp Untersuchte Port-/Protokollkombination open Nmap erhielt eine Antwort für einen offenen Port https Erkannter oder anhand der Portzuordnung vermuteter Dienst nginx 1.24.0 Von Nmap ermittelte oder geschätzte Produktversion Versionsergebnisse können unvollständig oder irreführend sein, beispielsweise durch: Reverse Proxies; Load Balancer; TLS-Termination; absichtlich veränderte Banner; Backports von Sicherheitskorrekturen; herstellerspezifische Builds; Protokollweiterleitungen; IDS- oder IPS-Antworten. Ein Nmap-Versionshinweis sollte mit der lokalen Paketverwaltung, der Anwendungskonfiguration oder der Herstelleroberfläche bestätigt werden. 14. Wie wird eine Betriebssystemerkennung durchgeführt? OS-Erkennung `-O` anzeigen Nmap versucht anhand verschiedener Netzwerkmerkmale, das Betriebssystem des Zielsystems zu bestimmen. [TEST][PRIV][SENS] sudo nmap -O 192.0.2.10 Nur gezielte Ports und OS-Erkennung [TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10 Erkennungsversuche begrenzen [TEST][PRIV][SENS] sudo nmap -O --osscan-limit 192.0.2.0/28 --osscan-limit beschränkt die OS-Erkennung auf Ziele, bei denen Nmap dafür geeignete Bedingungen erkennt. Voraussetzungen für gute Ergebnisse Nmap erzielt bessere Resultate, wenn mindestens: ein offener TCP-Port; ein geschlossener TCP-Port; ausreichende Antworten des Zielsystems vorhanden sind. Mögliche Ungenauigkeiten Firewall verändert Antworten; NAT oder Proxy liegt zwischen Quelle und Ziel; mehrere Systeme teilen eine IP-Adresse; Netzwerkgerät beantwortet Pakete stellvertretend; zu wenige geeignete Ports antworten; Betriebssystem-Fingerprint ist nicht eindeutig. Die Ausgabe ist eine Netzwerkerkennung beziehungsweise Schätzung und kein sicherer Beweis für das installierte Betriebssystem. 15. Welche einfachen NSE-Skripte können für die Diagnose verwendet werden? Nmap Scripting Engine sicher einordnen Die Nmap Scripting Engine, kurz NSE, erweitert Nmap um Skripte. Diese können von einfachen Informationsabfragen bis zu Sicherheits- und Belastungstests reichen. Standard-Skripte [TEST][DISRUPT][SENS] nmap -sC -p 22,80,443 192.0.2.10 -sC entspricht: --script=default Auch Standardskripte senden zusätzliche Anfragen an Dienste und sollten nur nach Freigabe verwendet werden. Bestimmtes, zuvor geprüftes Skript [TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10 Skriptbeschreibung anzeigen [RO] nmap --script-help http-title Mehrere freigegebene Informationsskripte [TEST][SENS] nmap --script http-title,http-headers -p 80,443 192.0.2.10 Vor einem NSE-Einsatz müssen geprüft werden: Skriptname; Skriptbeschreibung; Kategorie; benötigte Argumente; mögliche Auswirkungen; Zielport; Umfang der Autorisierung. Im normalen Troubleshooting nicht pauschal verwenden --script vuln --script exploit --script brute --script dos --script intrusive Diese Kategorien können Schwachstellenprüfungen, Anmeldeversuche oder belastende Tests enthalten. Sie gehören nicht in eine gewöhnliche Netzwerkdiagnose ohne gesonderten Auftrag. Auch die Kategorie safe ist keine absolute Garantie für Wirkungslosigkeit. Das konkrete Skript muss vor dem Einsatz geprüft werden. 16. Warum sollte -A nicht unüberlegt verwendet werden? Aggressive Erkennung erklären Die Option -A aktiviert mehrere Funktionen gleichzeitig: Betriebssystemerkennung; Versionserkennung; Standardskript-Scan; Traceroute. [TEST][PRIV][DISRUPT][SENS] sudo nmap -A 192.0.2.10 Für eine gezielte Fehleranalyse ist dieser Befehl häufig zu breit. Er sendet mehr unterschiedliche Prüfungen als ein einfacher Portscan und erzeugt umfangreichere Logs und mögliche Sicherheitsmeldungen. Besser ist eine schrittweise Auswahl: [TEST][SENS] nmap -sT -p 443 192.0.2.10 Danach bei Bedarf: [TEST][SENS] nmap -sV --version-light -p 443 192.0.2.10 Und nur bei begründetem Bedarf: [TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10 Dadurch bleibt erkennbar, welche Scanoption welche Reaktion verursacht hat. 17. Wie wird die Namensauflösung kontrolliert? DNS-Optionen anzeigen Keine DNS-Auflösung durchführen [TEST][SENS] nmap -n -p 22,80,443 192.0.2.10 DNS-Auflösung für alle Ziele erzwingen [TEST][SENS] nmap -R -p 22,80,443 192.0.2.10 Bedeutung Option Wirkung -n Keine Reverse-DNS-Auflösung -R Reverse-DNS-Auflösung für alle Ziele Keine Option Nmap entscheidet abhängig vom Scanergebnis Für reproduzierbare Portprüfungen ist -n häufig sinnvoll: Scan wird nicht durch DNS verzögert; keine zusätzlichen DNS-Abfragen; Ergebnisse zeigen die tatsächlichen IP-Adressen; DNS- und Portprobleme werden getrennt untersucht. Wenn die DNS-Zuordnung selbst Teil der Diagnose ist, sollte sie bewusst separat geprüft werden. 18. Wie wird die Scanrate kontrolliert? Timing und Belastungsbegrenzung anzeigen Nmap bietet Timing-Vorlagen: Vorlage Name Einordnung -T0 Paranoid Extrem langsam -T1 Sneaky Sehr langsam -T2 Polite Reduzierte Geschwindigkeit -T3 Normal Standard -T4 Aggressive Schneller, nur in stabilen und freigegebenen Netzen -T5 Insane Sehr aggressiv; für normales Troubleshooting ungeeignet Normale Geschwindigkeit [TEST][SENS] nmap -T3 -p 22,80,443 192.0.2.10 Rücksichtsvollere Prüfung [TEST][SENS] nmap -T2 -p 22,80,443 192.0.2.10 Maximale Paketrate begrenzen [TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10 --max-rate 50 fordert Nmap auf, im Durchschnitt nicht schneller als 50 Pakete pro Sekunde zu senden. Abhängig von Scanart und Betriebssystem können trotzdem kurzfristige Abweichungen auftreten. Host-Zeitüberschreitung [TEST][SENS] nmap --host-timeout 2m -p 22,80,443 192.0.2.10 Wenn ein Ziel nach zwei Minuten nicht vollständig geprüft wurde, beendet Nmap die weitere Bearbeitung dieses Hosts. Für empfindliche Systeme nur einzelne Ziele; nur benötigte Ports; -T2 oder -T3 ; niedrige --max-rate ; keine umfassende Versionserkennung; keine pauschalen NSE-Skripte; System- und Dienstüberwachung parallel beobachten. 19. Wie werden Ergebnisse gespeichert? Ausgabeformate anzeigen Option Format Verwendung -oN DATEI Normale Textausgabe Menschliche Auswertung -oX DATEI XML Automatisierte Verarbeitung -oG DATEI Grepbares Format Älteres zeilenorientiertes Format -oA BASISNAME Alle drei Formate Vollständige Dokumentation Normale Ausgabe speichern [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oN server-scan.txt 192.0.2.10 XML-Ausgabe [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oX server-scan.xml 192.0.2.10 Alle Hauptformate [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10 Dabei entstehen typischerweise: server-scan.nmap server-scan.xml server-scan.gnmap Zusätzlich Terminalausgabe mit tee speichern Linux und macOS: [TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | tee server-scan.txt PowerShell: [TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | Tee-Object -FilePath server-scan.txt tee beziehungsweise Tee-Object speichert nur die sichtbare Textausgabe. Für strukturierte Verarbeitung sollte -oX oder -oA verwendet werden. 20. Wie werden Ergebnisse vor und nach einer Änderung verglichen? Vergleichsdiagnose anzeigen Vor der Änderung [TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-before 192.0.2.10 Nach der Änderung [TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-after 192.0.2.10 Linux und macOS: [RO][FILE][SENS] diff -u server-before.nmap server-after.nmap PowerShell: [RO][FILE][SENS] Compare-Object (Get-Content .\server-before.nmap) (Get-Content .\server-after.nmap) Für einen aussagekräftigen Vergleich müssen identisch sein: Scanquelle; Zieladresse; Scanart; Portliste; Nmap-Version; Berechtigungsstufe; DNS-Einstellung; Timing-Einstellung; Netzwerkpfad. Andernfalls können Unterschiede durch die Testmethode statt durch die eigentliche Änderung entstehen. 21. Wie wird ein bestimmter Dienst systematisch geprüft? Diagnosefolge für einen einzelnen Dienst anzeigen Beispiel: HTTPS auf TCP-Port 443. 1. Namensauflösung getrennt prüfen Windows: [RO] Resolve-DnsName server.example.com Linux oder macOS: [RO] dig server.example.com 2. Host Discovery durchführen [TEST][SENS] nmap -sn --reason 192.0.2.10 3. Port unabhängig von Host Discovery prüfen [TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10 4. Dienst vorsichtig identifizieren [TEST][SENS] nmap -Pn -n -sV --version-light -p 443 192.0.2.10 5. Anwendungsebene prüfen [TEST][SENS] curl -vkI https://192.0.2.10/ Bei namensabhängigen virtuellen Hosts sollte der korrekte DNS-Name verwendet werden: [TEST][SENS] curl -vI https://server.example.com/ 6. TLS gesondert prüfen [TEST][SENS] openssl s_client -connect 192.0.2.10:443 -servername server.example.com Interpretation Ergebnis Nächster Schritt Port closed Dienststatus und lokale Listener prüfen Port filtered Firewall, ACL, Routing und Paketmitschnitt prüfen Port open , curl fehlschlägt HTTP-, TLS-, Proxy- oder Anwendungsproblem untersuchen Port open , TLS falsch Zertifikat, SNI, TLS-Version und Zeit prüfen Nmap erkennt falschen Dienst Direkten Protokolltest durchführen Unterschiedliche Ergebnisse aus zwei Netzen Firewall- und Routingpfad vergleichen Nmap beantwortet hauptsächlich die Frage: Wie reagiert dieser Port aus Sicht dieses Scanstandorts? Für die vollständige Fehlerursache sind weitere Werkzeuge erforderlich. 22. Wie wird ein Firewallproblem eingegrenzt? Vergleich zwischen Netzsegmenten anzeigen Ein Scan sollte von genau den Standorten erfolgen, deren Erreichbarkeit untersucht wird. Clientnetz A → Firewall → Servernetz Clientnetz B → Firewall → Servernetz Scan aus Netz A [TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-a.txt 192.0.2.10 Scan aus Netz B [TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-b.txt 192.0.2.10 Mögliche Beobachtung Netz A Netz B Mögliche Schlussfolgerung open filtered Unterschiedliche Firewall-, ACL- oder Routingbehandlung open closed Möglicherweise anderes Ziel, NAT oder unterschiedliche Antwortquelle filtered filtered Gemeinsamer Filter, fehlender Rückweg oder Ziel nicht erreichbar open open Grundlegende Portfreigabe aus beiden Netzen vorhanden Zusätzlich sollten geprüft werden: Quell-IP des Scanhosts; Ziel-IP nach NAT; Firewall-Logs; Routingtabellen; Security Groups; lokale Host-Firewall; Paketmitschnitt auf Client, Firewall oder Server; Rückweg zum jeweiligen Clientnetz. Ein Nmap-Ergebnis allein zeigt nicht, an welchem Gerät ein Paket verworfen wurde. 23. Welche Scanarten sollten im normalen Troubleshooting vermieden werden? Nicht empfohlene Optionen anzeigen Folgende Funktionen gehören normalerweise nicht zur alltäglichen Fehleranalyse: Scanart oder Option Grund Idle Scan -sI Verwendet ein fremdes System als sogenanntes Zombie-System FTP Bounce -b Missbraucht einen FTP-Server als Relay Eigene TCP-Flags --scanflags Kann Filter- und IDS-Umgehung dienen Decoys -D Verschleiert die tatsächliche Scanquelle Quelladress-Spoofing -S Erschwert Rückverfolgung und kann Netzstörungen verursachen Fragmentierung -f Wird häufig zur Filterumgehung eingesetzt --badsum Erzeugt absichtlich ungültige Prüfsummen NSE-Kategorie brute Führt Anmeldeversuche durch NSE-Kategorie exploit Versucht Sicherheitslücken auszunutzen NSE-Kategorie dos Kann Dienste beeinträchtigen NSE-Kategorie intrusive Kann Systeme oder Anwendungen belasten Ungeprüftes -A gegen viele Systeme Kombiniert mehrere aktive Erkennungsverfahren -T5 Sehr aggressive Zeitsteuerung Solche Funktionen werden in diesem Troubleshooting-Buch nicht als Standardbefehle empfohlen. Für einen gesonderten Sicherheitstest sind ein eigener Auftrag, eine genaue Risikoanalyse und abgestimmte Abbruchkriterien erforderlich. 24. Welche typischen Fehlinterpretationen gibt es? Fehlertabelle anzeigen Fehlinterpretation Korrekte Einordnung Host seems down bedeutet ausgeschaltet Discovery-Pakete können gefiltert worden sein open bedeutet Anwendung funktioniert Nur der Port reagiert; Anwendungstest folgt closed bedeutet Firewall blockiert Das Ziel antwortet normalerweise aktiv mit „kein Listener“ filtered bedeutet lokale Host-Firewall Filter kann an jeder Stelle des Pfads liegen open|filtered bedeutet offen Nmap kann offen und gefiltert nicht unterscheiden Dienstname in der Porttabelle ist sicher erkannt Ohne -sV kann er nur aus der Portzuordnung stammen Angezeigte Version ist garantiert installiert Banner, Proxy oder Backport können abweichen OS-Erkennung ist ein sicherer Beweis Es handelt sich um eine Fingerprint-Schätzung Kein Ergebnis bei UDP bedeutet geschlossen Häufig lautet der Zustand open|filtered -Pn macht den Scan passiv Portscan bleibt aktiv; nur Host Discovery wird übersprungen SYN-Scan ist unsichtbar IDS, IPS, Firewalls und Systeme können ihn erkennen Ein Scan aus dem Servernetz gilt auch für das Clientnetz Unterschiedliche Netzwerkpfade können andere Ergebnisse liefern Nmap ist ein vollständiger Schwachstellenscanner Nmap ist primär ein Netzwerk- und Portscanner Viele Optionen liefern automatisch bessere Ergebnisse Mehr Prüfungen erhöhen Last, Logs und Fehlinterpretationsrisiko 25. Wie werden Nmap-Ergebnisse verifiziert? Gegenprüfungen anzeigen Nmap-Beobachtung Geeignete Gegenprüfung TCP-Port offen Test-NetConnection , nc , curl oder anwendungsspezifischer Client TCP-Port geschlossen Lokale Listener mit Get-NetTCPConnection , ss oder lsof prüfen Port gefiltert Firewall-Logs, Routing und Paketmitschnitt prüfen DNS-Dienst offen Resolve-DnsName , dig oder nslookup HTTP/HTTPS offen curl TLS erkannt openssl s_client SSH offen Autorisierten SSH-Verbindungsaufbau durchführen SMB offen SMB-Client und Serverlogs prüfen Dienstversion erkannt Lokale Paket- oder Anwendungsversion prüfen Betriebssystem erkannt Lokale Systeminformationen oder Inventarsystem prüfen Host nicht erkannt ARP/Neighbor-Tabelle, Ping, TCP-Test und Switchinformationen prüfen Lokale Listener prüfen Betriebssystem Befehl Windows [RO] Get-NetTCPConnection -State Listen Linux [RO] ss -lntup macOS [RO] sudo lsof -nP -iTCP -sTCP:LISTEN Ein Port kann lokal lauschen und trotzdem aus dem untersuchten Netzsegment nicht erreichbar sein. Umgekehrt kann NAT oder Portweiterleitung einen extern erreichbaren Port zeigen, obwohl auf der Zieladresse selbst kein entsprechender lokaler Listener sichtbar ist. 26. Wie sieht ein sicherer Nmap-Diagnoseablauf aus? Empfohlene Schrittfolge anzeigen Vorbereitung Auftrag und Ziel der Prüfung dokumentieren. Zulässige Zieladressen und Ports festlegen. Scanquelle und Netzwerksegment dokumentieren. Empfindliche Systeme identifizieren. Erlaubte Scanarten und maximale Rate festlegen. Ansprechpartner und Abbruchkriterium festlegen. Systemzeit und Speicherort der Ergebnisse prüfen. Zielkontrolle Zielbereich zuerst mit -sL -n auflisten. CIDR-Präfix und Ausschlüsse kontrollieren. Mit einem einzelnen Testsystem beginnen. Schrittweise Prüfung Host Discovery mit -sn durchführen. Falls erforderlich einen bekannten Port mit -Pn prüfen. Nur benötigte Ports mit -p angeben. Zunächst TCP Connect oder SYN Scan verwenden. UDP nur für konkret benötigte Ports prüfen. --reason zur Interpretation hinzufügen. Versionserkennung nur bei Bedarf verwenden. NSE-Skripte einzeln prüfen und freigeben. Scanrate und Zielsystemüberwachung beobachten. Dokumentation Ausgabe mit -oA speichern. Nmap-Version und verwendeten Befehl dokumentieren. Beginn, Ende und Scanquelle festhalten. Ergebnisse als Beobachtung und nicht sofort als Ursache dokumentieren. Validierung Offene Ports mit einem Protokollwerkzeug prüfen. Gefilterte Ports mit Firewall-Logs und Paketmitschnitten untersuchen. Lokale Listener auf dem Zielsystem prüfen. Nach einer Änderung denselben Scan erneut ausführen. Ergebnisse vergleichen. Zuständige Personen über Abschluss oder Auffälligkeiten informieren. Scanresultate gemäß Schutz- und Löschrichtlinie behandeln. 27. Kurzreferenz – sichere Basisbefehle Nmap-Befehlstabelle anzeigen Aufgabe Befehl Version anzeigen [RO] nmap --version Hilfe anzeigen [RO] nmap -h Zielbereich nur auflisten [RO][SENS] nmap -sL -n 192.0.2.0/28 Hosts erkennen [TEST][SENS] nmap -sn -n 192.0.2.0/28 Grund anzeigen [TEST][SENS] nmap -sn -n --reason 192.0.2.0/28 Einzelnen TCP-Port prüfen [TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10 Mehrere TCP-Ports [TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10 SYN-Scan [TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10 UDP-Ports [TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10 TCP und UDP [TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10 Häufigste 100 Ports [TEST][SENS] nmap --top-ports 100 192.0.2.10 Alle TCP-Ports [TEST][SENS] nmap -p- 192.0.2.10 Nur offene Ports ausgeben [TEST][SENS] nmap --open -p 22,80,443 192.0.2.10 Dienstversionen vorsichtig prüfen [TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10 Betriebssystem schätzen [TEST][PRIV][SENS] sudo nmap -O 192.0.2.10 IPv6-Ziel [TEST][SENS] nmap -6 -p 22,80,443 2001:db8::10 Scanrate begrenzen [TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10 Ergebnisse vollständig speichern [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10 Skriptbeschreibung anzeigen [RO] nmap --script-help http-title HTTP-Titel prüfen [TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10 28. Kurzreferenz – wichtigste Optionen Optionstabelle anzeigen Option Bedeutung -sL Ziele nur auflisten -sn Nur Host Discovery, kein Portscan -Pn Host Discovery überspringen -n Keine DNS-Auflösung -R Reverse-DNS-Auflösung erzwingen -sT TCP Connect Scan -sS TCP SYN Scan -sU UDP Scan -p Ports angeben -p- Alle Ports von 1 bis 65.535 -F Schneller Scan mit reduzierter Portauswahl --top-ports N N häufigste Ports prüfen --open Nur offene oder möglicherweise offene Ports anzeigen --reason Grund für Host- und Portbewertung anzeigen -sV Dienst- und Versionserkennung --version-light Reduzierte Versionserkennung -O Betriebssystemerkennung -6 IPv6 verwenden -iL Ziele aus Datei lesen --exclude Ziel ausschließen --excludefile Ausschlüsse aus Datei lesen -T2 Rücksichtsvolle Timing-Vorlage -T3 Normale Timing-Vorlage --max-rate Maximale durchschnittliche Paketrate begrenzen --host-timeout Zeitlimit pro Host -oN Normale Ausgabe speichern -oX XML-Ausgabe speichern -oG Grepbare Ausgabe speichern -oA Alle Hauptformate speichern -sC Standard-NSE-Skripte ausführen --script Bestimmte NSE-Skripte auswählen --script-help Beschreibung eines Skripts anzeigen Merksätze Nmap ist ein aktives Diagnosewerkzeug und benötigt eine eindeutige Autorisierung. Zuerst den Zielbereich prüfen, dann mit einem einzelnen Ziel und wenigen Ports beginnen. -sn führt Host Discovery ohne anschließenden Portscan durch. -Pn macht einen Scan nicht passiv, sondern überspringt nur die Host-Erkennung. -sT verwendet vollständige TCP-Verbindungen und benötigt normalerweise keine Raw-Packet-Rechte. -sS verwendet Raw-Pakete und benötigt auf Unix-Systemen normalerweise erhöhte Rechte. filtered bedeutet, dass Nmap den Portzustand wegen fehlender oder filternder Antworten nicht bestimmen kann. UDP-Ergebnisse sind häufig weniger eindeutig als TCP-Ergebnisse. Ein Dienstname ohne Versionserkennung kann lediglich aus der bekannten Portzuordnung stammen. Versions- und Betriebssystemergebnisse sind Hinweise und müssen lokal bestätigt werden. -A , NSE-Skripte und aggressive Timing-Optionen dürfen nicht unüberlegt eingesetzt werden. Ein offener Port bestätigt noch keine funktionierende Anwendung. Ergebnisse müssen aus dem tatsächlich betroffenen Netzwerksegment erhoben werden. Nmap-Ergebnisse sollten mit Protokolltests, lokalen Listenern, Logs und Paketmitschnitten verifiziert werden. Quellen Offizielle Nmap-Referenz Nmap – Target Specification Nmap – Host Discovery Nmap – Port Scanning Basics Nmap – Port Scanning Techniques Nmap – Port Specification and Scan Order Nmap – Service and Version Detection Nmap – OS Detection Nmap – Nmap Scripting Engine Nmap – Timing and Performance Nmap – Output Nmap – Legal Notices and Inappropriate Usage Offizielle Npcap-Dokumentation 2.8 iPerf3 – Bandbreite, Durchsatz, Jitter und Paketverlust messen Ziel dieser Seite iPerf3 erzeugt kontrollierten Netzwerkverkehr zwischen zwei Systemen und misst dabei die erreichbare Übertragungsleistung. Es hilft unter anderem bei der Untersuchung von: zu geringem TCP-Durchsatz; langsamen LAN-, WLAN-, VPN- oder WAN-Verbindungen; unterschiedlichen Übertragungsraten je Richtung; UDP-Paketverlust; UDP-Jitter; Performanceproblemen zwischen VLANs oder Standorten; möglichen Engpässen an Netzwerkadaptern, Firewalls oder VPN-Gateways; Auswirkungen von Parallelverbindungen; Unterschieden zwischen Anwendungs- und Netzwerkleistung. iPerf3 besteht aus einem Server und einem Client: iPerf3-Client → Netzwerkpfad → iPerf3-Server Standardmäßig sendet der Client TCP-Testdaten an den Server. Mit -R wird die Richtung umgekehrt. Wichtig: iPerf3 erzeugt aktiv Datenverkehr und kann eine Netzwerkverbindung vollständig auslasten. Tests dürfen nur zwischen autorisierten Systemen und mit abgestimmter Testdauer und Datenrate durchgeführt werden. Kennzeichnungen Kennzeichnung Bedeutung [RO] Lokale Abfrage ohne Netzwerktest [TEST] Aktiver Netzwerk- oder Leistungstest [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Befehl erstellt oder verarbeitet eine Datei [SENS] Ausgabe kann sensible Infrastrukturinformationen enthalten [CHANGE] Befehl verändert eine Einstellung oder Datei [DISRUPT] Test kann Netzwerk, Endgeräte oder andere Verbindungen belasten 1. Was misst iPerf3 – und was misst es nicht? Messumfang anzeigen Messwert TCP UDP Übertragene Datenmenge Ja Ja Durchschnittlicher Durchsatz Ja Ja Durchsatz je Messintervall Ja Ja TCP-Wiederholungsübertragungen Systemabhängig, häufig auf Senderseite Nein TCP Congestion Window Systemabhängig Nein UDP-Jitter Nein Ja UDP-Paketverlust Nein Ja Verlorene Datagramme Nein Ja Empfangene Datagramme Nein Ja Reihenfolgefehler Teilweise über UDP-Zähler erkennbar Ja iPerf3 misst den Durchsatz zwischen den beiden iPerf3-Prozessen. Das Ergebnis ist nicht automatisch identisch mit: der Leitungsgeschwindigkeit des Netzwerkadapters; der Brutto-Datenrate eines WLANs; der Geschwindigkeit eines Internetanschlusses; der Geschwindigkeit einer Dateiübertragung; der Leistung einer Webanwendung; der Festplattenleistung; der nutzbaren Geschwindigkeit für jeden einzelnen Benutzer. iPerf3 umgeht normalerweise folgende Anwendungsfaktoren Dateisystem; Festplattenzugriffe; SMB- oder NFS-Protokollverarbeitung; HTTP-Anwendung; Datenbankabfragen; Verschlüsselung einer konkreten Anwendung; Benutzeranmeldung; Virenscan einer übertragenen Datei. Dadurch kann iPerf3 helfen, Netzwerkpfad und Anwendung voneinander zu trennen: iPerf3 schnell + Anwendung langsam → Ursache wahrscheinlich nicht ausschließlich der reine Netzwerkdurchsatz iPerf3 langsam + Anwendung langsam → Netzwerkpfad oder beteiligte Systeme weiter untersuchen 2. Auf welchen Betriebssystemen wird iPerf3 offiziell unterstützt? Betriebssystemübersicht anzeigen Betriebssystem Offizielle ESnet-Unterstützung Hinweis Linux Ja Vollständiger Haupteinsatzbereich FreeBSD Ja Offiziell unterstützt macOS Ja In der ESnet-Dokumentation als OSX bezeichnet Windows Nein ESnet empfiehlt für Windows iPerf2 Andere Systeme Nicht generell zugesichert Funktionsumfang kann abweichen Nach der offiziellen ESnet-FAQ wird iPerf3 nicht offiziell unter Windows unterstützt. Es existieren Community-Builds für Windows, bei denen jedoch nicht alle Optionen funktionieren müssen. Konsequenz für dieses Buch Linux, FreeBSD und macOS: iPerf3 nach offizieller ESnet-Dokumentation; Windows mit Community-iPerf3: Version, Quelle und Funktionsumfang ausdrücklich dokumentieren; Windows mit offiziell unterstützter Alternative: iPerf2 verwenden; iPerf2 und iPerf3 nicht als untereinander kompatibel behandeln. Ein iPerf3-Client benötigt einen iPerf3-Server. Ein iPerf2-Client benötigt einen iPerf2-Server. 3. Wie wird die installierte Version geprüft? Versions- und Hilfebefehle anzeigen Aufgabe Windows mit Community-Build Linux macOS Programmpfad [RO] Get-Command iperf3 [RO] command -v iperf3 [RO] command -v iperf3 Version [RO] iperf3 --version [RO] iperf3 --version [RO] iperf3 --version Kurzform der Version [RO] iperf3 -v [RO] iperf3 -v [RO] iperf3 -v Hilfe [RO] iperf3 -h [RO] iperf3 -h [RO] iperf3 -h Handbuch Nicht standardmäßig [RO] man iperf3 [RO] man iperf3 Die Version muss auf Client und Server dokumentiert werden: Client: iPerf 3.x Server: iPerf 3.x Unterschiedliche iPerf3-Versionen funktionieren häufig miteinander, können aber: unterschiedliche Optionen unterstützen; Ergebnisse unterschiedlich darstellen; andere Standardwerte verwenden; Fehlerkorrekturen enthalten; bei neueren Funktionen inkompatibel sein. Seit iPerf3 3.16 verwendet jeder parallele Teststream einen eigenen Thread. Ältere Versionen waren für den Testdatenverkehr grundsätzlich auf einen Thread begrenzt. Bei hohen Datenraten kann die verwendete Version deshalb das Ergebnis wesentlich beeinflussen. 4. Welche Freigaben müssen vor einem Leistungstest vorliegen? Testplanung anzeigen Punkt Beispiel Client 192.0.2.10 Server 192.0.2.20 Port TCP/UDP 5201 Testprotokoll TCP und anschließend UDP Testdauer 30 Sekunden je Richtung Maximale UDP-Rate 100 Mbit/s Parallelstreams Zunächst 1, anschließend 4 Netzwerkpfad Client-VLAN → Firewall → Server-VLAN Testzeitraum Wartungsfenster Verantwortliche Person Max Mustermann Abbruchkriterium Hohe Last, Paketverlust anderer Anwendungen oder Alarmmeldung Vorher prüfen: Darf die Verbindung ausgelastet werden? Gibt es produktive Sprach-, Video- oder Echtzeitanwendungen? Befindet sich der Testpfad hinter einer volumenbasierten Internetabrechnung? Gibt es QoS- oder Rate-Limit-Regeln? Muss eine Firewallfreigabe zeitlich begrenzt eingerichtet werden? Sind Client und Server leistungsfähig genug? Gibt es WLAN-Teilnehmer, die durch den Test beeinträchtigt werden? Wird der Test über VPN, Mobilfunk oder einen geteilten WAN-Link durchgeführt? Sind Monitoring und zuständige Administratoren informiert? Ein unbegrenzter TCP-Test versucht, so viel Bandbreite wie möglich zu verwenden. Auch ein zehn Sekunden langer Standardtest kann deshalb andere Verbindungen beeinflussen. 5. Welche Netzwerkverbindungen benötigt iPerf3? Ports und Verbindungsaufbau anzeigen Der iPerf3-Server lauscht standardmäßig auf Port 5201 . TCP-Test Client → Server: TCP 5201 UDP-Test Client → Server: TCP 5201 für Steuerung Client → Server: UDP 5201 für Testdaten Auch bei einem UDP-Test verwendet iPerf3 eine TCP-Steuerverbindung. Daher muss neben UDP 5201 auch TCP 5201 erreichbar sein. Benutzerdefinierter Port Server: [TEST][DISRUPT] iperf3 -s -p 5002 Client: [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -p 5002 Für einen UDP-Test auf Port 5002 müssen gegebenenfalls beide Protokolle freigegeben sein: TCP 5002 UDP 5002 Port vor dem Test prüfen Windows: [TEST] Test-NetConnection 192.0.2.20 -Port 5201 Linux: [TEST] nc -vz 192.0.2.20 5201 macOS: [TEST] nc -vz 192.0.2.20 5201 Ein erfolgreicher TCP-Porttest bestätigt nur die Steuerverbindung. Er bestätigt noch nicht, dass ein UDP-Testdatenstrom funktioniert. 6. Wie wird ein iPerf3-Server gestartet? Serverbefehle anzeigen Server auf dem Standardport 5201 starten [TEST][DISRUPT] iperf3 -s Server auf einem anderen Port [TEST][DISRUPT] iperf3 -s -p 5002 Server an eine bestimmte lokale IP-Adresse binden [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 Server nur für einen Test starten und danach beenden [TEST][DISRUPT] iperf3 -s -1 -1 beziehungsweise --one-off bedeutet: höchstens eine Clientverbindung bearbeiten; danach den Serverprozess beenden. Das ist für kontrollierte Einzeltests häufig sicherer als ein dauerhaft laufender Server. Einmaliger Server auf bestimmter Adresse und bestimmtem Port [TEST][DISRUPT] iperf3 -s -1 -B 192.0.2.20 -p 5201 Ausführliche Ausgabe [TEST][DISRUPT] iperf3 -s -V Serverausgabe in eine Datei schreiben [TEST][FILE][SENS][DISRUPT] iperf3 -s --logfile iperf3-server.log --forceflush --forceflush schreibt die Intervallergebnisse zeitnah in die Logdatei, statt sie länger zu puffern. 7. Wie wird der laufende Server kontrolliert? Listener und Prozess prüfen Linux: Listener prüfen [RO] ss -lntp | grep ':5201' macOS: Listener prüfen [RO][PRIV] sudo lsof -nP -iTCP:5201 -sTCP:LISTEN Windows mit Community-Build [RO] Get-NetTCPConnection -LocalPort 5201 -State Listen Prozess suchen Linux: [RO] pgrep -a iperf3 macOS: [RO] pgrep -fl iperf3 Windows: [RO] Get-Process iperf3 -ErrorAction SilentlyContinue Nach dem Test sollte ein nicht mehr benötigter iPerf3-Server beendet werden. Bei Verwendung von -1 beendet er sich nach der Clientverbindung automatisch. 8. Wie wird ein grundlegender TCP-Test durchgeführt? Standardtest anzeigen Auf dem Server [TEST][DISRUPT] iperf3 -s -1 Auf dem Client [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 Standardmäßig: verwendet iPerf3 TCP; sendet der Client zum Server; dauert der Test zehn Sekunden; wird jede Sekunde ein Zwischenergebnis ausgegeben; wird Port 5201 verwendet. Test für 30 Sekunden [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 Ausgabe alle fünf Sekunden [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -i 5 Einheit Mbit/s erzwingen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -f m Serverausgabe zusätzlich am Client abrufen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --get-server-output Die Serverausgabe wird nur abgerufen, wenn der Test vollständig abgeschlossen wird. Bei einem abgebrochenen Test kann sie fehlen. 9. Welche Richtung wird mit iPerf3 gemessen? Normal-, Reverse- und Bidirektionstest anzeigen Standardrichtung Client → Server [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 Dabei sendet der Client die Testdaten. Umgekehrte Richtung Server → Client [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R -R wird auf dem Client angegeben, obwohl anschließend der Server die Testdaten sendet. Beide Richtungen gleichzeitig Client ↔ Server [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir --bidir testet beide Richtungen gleichzeitig. Das erzeugt mehr Last als zwei getrennte Einzeltests und erschwert die Interpretation. Empfohlene Reihenfolge Client zum Server testen. Server zum Client mit -R testen. Ergebnisse vergleichen. Erst bei begründetem Bedarf --bidir verwenden. Mögliche Ursachen für unterschiedliche Richtungen asymmetrisches Routing; unterschiedliche QoS-Regeln; Firewall- oder VPN-Verarbeitung; WLAN-Uplink und WLAN-Downlink; Sender- oder Empfänger-CPU; Netzwerkkartentreiber; TCP-Offloading; unterschiedliche Upload- und Downloadkapazität; unterschiedliche Paketverlustrate. 10. Wie wird ein UDP-Test sicher durchgeführt? UDP-Test mit kontrollierter Datenrate anzeigen Wichtiger Unterschied Bei TCP passt das Protokoll die Senderate unter anderem anhand von Bestätigungen, Verlust und Überlastung an. Bei UDP muss eine gewünschte Senderate festgelegt werden. Die iPerf3-Standardrate für UDP beträgt laut aktueller Dokumentation 1 Mbit/s . UDP-Test mit 10 Mbit/s [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 UDP-Test mit 100 Mbit/s [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 Umgekehrter UDP-Test [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R UDP-Test ohne iPerf3-interne Bitratenbegrenzung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 0 -t 30 -b 0 deaktiviert die interne Begrenzung. Dadurch kann der Test sehr viel Verkehr erzeugen und erheblichen Paketverlust verursachen. -b 0 sollte in produktiven Netzen nicht als erster Test verwendet werden. Sichere Steigerung 10 Mbit/s → 25 Mbit/s → 50 Mbit/s → 100 Mbit/s Nach jeder Stufe werden geprüft: Paketverlust; Jitter; Netzwerkauslastung; CPU-Auslastung; Auswirkungen auf andere Anwendungen. 11. Wie werden UDP-Jitter und Paketverlust interpretiert? UDP-Messwerte anzeigen Eine UDP-Zusammenfassung kann sinngemäß enthalten: 0.00-30.00 sec 350 MBytes 97.9 Mbits/sec 0.250 ms 1250/250000 (0.5%) Wert Bedeutung 350 MBytes Übertragene beziehungsweise empfangene Datenmenge 97.9 Mbits/sec Gemessene durchschnittliche Datenrate 0.250 ms Berechneter Jitter 1250/250000 Verlorene Datagramme im Verhältnis zur erwarteten Gesamtzahl 0.5% Berechnete Verlustquote Jitter Jitter beschreibt bei iPerf3 die Schwankung der Paketlaufzeit, nicht die absolute Latenz. Daher gilt: Niedriger Jitter ≠ automatisch niedrige Latenz Für die absolute Laufzeit werden zusätzlich beispielsweise benötigt: ping ; fping ; pathping ; Monitoringdaten; anwendungsspezifische Messungen. Paketverlust Verlustquote = verlorene Datagramme / erwartete Datagramme × 100 Ein Paketverlust unter hoher UDP-Last bedeutet nicht automatisch einen Defekt. Er kann auch entstehen, weil: die eingestellte Senderate höher als die verfügbare Bandbreite ist; ein QoS-Policer die Rate begrenzt; Empfangs- oder Sendepuffer überlaufen; Client oder Server CPU-limitiert ist; WLAN-Kollisionen oder Funkstörungen auftreten; die Firewall den Datenstrom nicht schnell genug verarbeitet. Der Test sollte deshalb mit mehreren kontrollierten Datenraten wiederholt werden. 12. Wie wird die maximale UDP-Kapazität schrittweise angenähert? Stufentest anzeigen Beispiel für einen freigegebenen 100-Mbit/s-Pfad: Stufe 1 [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 Stufe 2 [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 25M -t 30 Stufe 3 [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 50M -t 30 Stufe 4 [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 90M -t 30 Dokumentation Zielrate Empfangsrate Paketverlust Jitter Bewertung 10 Mbit/s 10 Mbit/s 0 % 0,2 ms Unauffällig 25 Mbit/s 25 Mbit/s 0 % 0,3 ms Unauffällig 50 Mbit/s 49,8 Mbit/s 0,1 % 0,5 ms Beobachten 90 Mbit/s 72 Mbit/s 18 % 5,2 ms Kapazitätsgrenze überschritten Die Werte in dieser Tabelle sind lediglich ein Rechen- und Dokumentationsbeispiel und keine allgemein gültigen Grenzwerte. Die sinnvoll nutzbare Rate liegt unterhalb des Punktes, an dem Verlust und Jitter deutlich ansteigen. 13. Wie werden parallele TCP-Streams verwendet? Parallelverbindungen `-P` anzeigen Vier parallele TCP-Streams [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 Acht parallele Streams [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 8 -t 30 Umgekehrte Richtung mit vier Streams [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 -R Seit iPerf3 3.16 verwendet jeder Teststream einen eigenen Thread. Dadurch können mehrere Streams mehrere CPU-Kerne nutzen. Warum mehrere Streams mehr Durchsatz erreichen können einzelne TCP-Verbindung ist durch Latenz und Empfangsfenster begrenzt; einzelne CPU oder ein einzelner Stream erreicht seine Grenze; Paketverlust reduziert das Congestion Window einer einzelnen Verbindung; Lastverteilung behandelt mehrere Flows unterschiedlich; mehrere Warteschlangen einer Netzwerkkarte werden verwendet. Wichtige Interpretation 1 Stream langsam 4 Streams schnell bedeutet nicht automatisch, dass die Verbindung fehlerfrei ist. Eine einzelne Anwendung verwendet möglicherweise nur eine TCP-Verbindung und erreicht dann weiterhin den niedrigeren Wert. Empfohlener Vergleich Test Zweck -P 1 Leistung einer einzelnen TCP-Verbindung -P 4 Verhalten mehrerer paralleler Verbindungen -P 8 Prüfung auf CPU-, Queue- oder Window-Limit -R Vergleich der Gegenrichtung 14. Wie werden Testdauer, Datenmenge und Warmlaufphase festgelegt? Zeit- und Mengenoptionen anzeigen Testdauer [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 60 -t 60 testet 60 Sekunden. Bestimmte Datenmenge übertragen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -n 1G Bestimmte Anzahl Blöcke übertragen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -k 10000 Die Optionen -t , -n und -k schließen sich gegenseitig aus. Pro Test darf nur eine davon zur Begrenzung verwendet werden. Erste fünf Sekunden nicht in die Statistik aufnehmen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 -O 5 führt zunächst fünf Sekunden Warmlauf durch und lässt diese Messwerte aus der abschließenden Teststatistik heraus. Das hilft, den Einfluss des TCP Slow Start auf die Zusammenfassung zu reduzieren. Sinnvoller stabiler TCP-Test [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 -i 5 Die gesamte Verbindung besteht dabei aus Warmlaufphase und ausgewerteter Testphase. Die genaue Laufzeit ist daher länger als der reine Auswertungszeitraum. 15. Wie wird eine bestimmte lokale IP-Adresse verwendet? Quelladresse und Schnittstellenbindung anzeigen Ein System kann mehrere Netzwerkschnittstellen und IP-Adressen besitzen: Ethernet; WLAN; VPN; Managementnetz; Produktionsnetz; IPv4 und IPv6. Client an eine lokale IP-Adresse binden [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10 Server an eine lokale IP-Adresse binden [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 Linux: an ein Interface binden, sofern unterstützt [TEST][PRIV][DISRUPT][SENS] sudo iperf3 -c 192.0.2.20 --bind-dev eth0 --bind-dev ist nicht auf allen Plattformen verfügbar und kann erhöhte Rechte erfordern. Vorher prüfen Windows: [RO] Get-NetIPConfiguration Linux: [RO] ip address show macOS: [RO] ifconfig Die Quelladresse beeinflusst: Routing; Firewallregeln; VPN-Auswahl; QoS; NAT; Rückweg; Aussagekraft des Messergebnisses. 16. Wie werden IPv4 und IPv6 getrennt getestet? IPv4- und IPv6-Befehle anzeigen IPv4 erzwingen [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 IPv6 erzwingen [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 IPv6-Reversetest [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 -R IPv6-Link-Local-Adresse Bei einer Link-Local-Adresse muss die Schnittstelle beziehungsweise Zone angegeben werden: [TEST][DISRUPT][SENS] iperf3 -6 -c fe80::20%en0 Der genaue Schnittstellenname ist betriebssystemspezifisch. Vergleich Test Ergebnis IPv4 schnell, IPv6 langsam IPv6-Routing, MTU, Firewall oder Tunnel prüfen IPv4 funktioniert, IPv6 nicht IPv6-Adresse, Route, Neighbor Discovery und Firewall prüfen IPv6 funktioniert, IPv4 nicht IPv4-Routing, NAT oder Firewall prüfen Beide langsam Gemeinsamen Netzwerkpfad und Endgeräte untersuchen 17. Wie werden Ergebnisse als JSON gespeichert? JSON- und Logausgabe anzeigen JSON im Terminal ausgeben [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J Linux und macOS: JSON in Datei schreiben [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J > iperf3-result.json PowerShell mit Community-iPerf3 [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J | Out-File -Encoding utf8 iperf3-result.json Direkte Logdatei [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile iperf3-result.log Zeitstempel hinzufügen [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --timestamps --logfile iperf3-result.log Zeilenweise JSON-Objekte während des Tests [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --json-stream > iperf3-stream.jsonl --json-stream ist eine neuere Funktion. Vor Verwendung muss geprüft werden, ob die installierte Version sie unterstützt. Für eine vollständige Dokumentation festhalten Client-IP; Server-IP; Netzwerkpfad; iPerf3-Versionen; Befehl; Datum und Uhrzeit; Testdauer; Protokoll; Richtung; Anzahl paralleler Streams; TCP- oder UDP-Rate; CPU-Auslastung; Interface-Zähler; Ergebnisdatei. 18. Wie werden TCP-Ergebnisse interpretiert? TCP-Ausgabe erklären Eine TCP-Ausgabe enthält am Ende typischerweise eine Sender- und eine Empfängerzeile: [SUM] 0.00-30.00 sec 3.20 GBytes 916 Mbits/sec sender [SUM] 0.00-30.00 sec 3.19 GBytes 913 Mbits/sec receiver Feld Bedeutung Intervall Ausgewerteter Zeitraum Transfer Übertragene Datenmenge Bitrate Durchschnittliche Übertragungsrate Sender Messung aus Sicht des Senders Receiver Messung aus Sicht des Empfängers Retr TCP-Wiederholungsübertragungen, sofern verfügbar Cwnd TCP Congestion Window, sofern ausgegeben Sender und Receiver Die Werte können geringfügig voneinander abweichen, beispielsweise durch: noch unterwegs befindliche Daten; unterschiedliche Messzeitpunkte; kurzen Test; Paketverlust; Abbruch der Steuerverbindung. Bei sehr kurzen Tests kann die Differenz stärker auffallen. Die ESnet-FAQ weist darauf hin, dass Testdaten noch unterwegs sein können, wenn die Steuerverbindung bereits das Testende verarbeitet. Retransmissions Viele Wiederholungsübertragungen können hinweisen auf: Paketverlust; Überlastung; fehlerhafte Leitung; WLAN-Störungen; überfüllte Warteschlangen; MTU- oder Offloading-Probleme. Sie beweisen allein jedoch noch keine bestimmte Ursache. Schwankender Durchsatz Mögliche Ursachen: konkurrierender Datenverkehr; WLAN-Funkbedingungen; TCP Congestion Control; CPU-Auslastung; Firewall- oder VPN-Verarbeitung; thermische Drosselung; Paketverlust; Load Balancing; dynamische QoS-Regeln. 19. Wie wird geprüft, ob Client oder Server der Engpass ist? Endgerätevergleich anzeigen 1. Normalrichtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 2. Gegenrichtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R 3. Einzelstream [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 1 -t 30 4. Vier Streams [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 5. CPU-Auslastung parallel beobachten Linux: [RO] top macOS: [RO] top Windows: [RO] Get-Counter '\Processor(_Total)\% Processor Time' Interpretationsbeispiele Beobachtung Mögliche Ursache Normalrichtung langsam, Reverse schnell Senderseite des Clients oder Empfängerseite des Servers prüfen Normalrichtung schnell, Reverse langsam Senderseite des Servers oder Empfängerseite des Clients prüfen Ein Stream langsam, mehrere schnell Einzelstream-, Latenz-, TCP-Window- oder CPU-Limit Beide Richtungen gleich langsam Gemeinsamer Pfad, Linkrate, Firewall, VPN oder CPU CPU erreicht 100 % Endsystem möglicherweise Messgrenze Durchsatz schwankt mit CPU Verarbeitungslimit wahrscheinlich Nur WLAN langsam Funkstrecke, Kanal, Signal oder Airtime prüfen LAN schnell, VPN langsam VPN-Gateway, Verschlüsselung, MTU oder Routing prüfen 20. Wie werden Netzwerkkarten- und Interface-Zähler einbezogen? Betriebssystemspezifische Kontrollbefehle anzeigen Windows [RO] Get-NetAdapter [RO] Get-NetAdapterStatistics [RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed Linux [RO] ip -s link show [RO] ethtool eth0 [RO][PRIV] sudo ethtool -S eth0 macOS [RO] ifconfig en0 [RO] netstat -ib Vor und nach dem iPerf3-Test vergleichen Zu prüfen sind unter anderem: Linkgeschwindigkeit; empfangene und gesendete Byte; RX- und TX-Fehler; Drops; Kollisionen, sofern relevant; Interface-Resets; Duplexmodus bei Ethernet; WLAN-Signal und Übertragungsrate; CPU-Auslastung. Ein iPerf3-Ergebnis ohne Interface- und Systemauslastung zeigt nur den gemessenen End-to-End-Durchsatz, aber nicht automatisch die Engpassstelle. 21. Welche Rolle spielen MTU, MSS und Paketgröße? MTU- und Längenoptionen anzeigen TCP Maximum Segment Size setzen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460 -M setzt die gewünschte TCP-MSS. Der tatsächlich verwendete Wert kann durch Betriebssystem und Netzwerkpfad beeinflusst werden. Für Ethernet mit einer MTU von 1500 Byte ergibt sich bei IPv4 ohne zusätzliche Optionen häufig: 1500 Byte MTU - 20 Byte IPv4-Header - 20 Byte TCP-Header = 1460 Byte TCP-MSS Bei IPv6 sind die Basisheader größer: 1500 Byte MTU - 40 Byte IPv6-Header - 20 Byte TCP-Header = 1440 Byte TCP-MSS Zusätzliche Header, TCP-Optionen, VLAN, VPN oder Tunnel können die nutzbare Größe beeinflussen. iPerf3-Puffer- beziehungsweise Blocklänge [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512 -l bestimmt die Länge des von iPerf3 gelesenen oder geschriebenen Puffers. Sie ist nicht identisch mit der Ethernet-Framegröße. UDP mit bestimmter Datagrammlänge [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -l 1200 IPv4-UDP mit gesetztem Don't-Fragment-Bit [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 -u -b 10M -l 1400 --dont-fragment --dont-fragment gilt nach der offiziellen Dokumentation nur für UDP über IPv4. Größenoptionen sollten nur gezielt verändert werden. Ungeeignete Werte können Fragmentierung, Verluste oder irreführende Ergebnisse verursachen. 22. Warum kann der TCP-Durchsatz plötzlich fast auf null fallen? Offloading- und Segmentierungsprobleme anzeigen Nach der offiziellen ESnet-FAQ kann ein fast vollständig einbrechender TCP-Durchsatz unter anderem mit fehlerhaftem TCP-Offloading zusammenhängen. Mögliche beteiligte Funktionen: TCP Segmentation Offload, TSO; Large Send Offload, LSO; Generic Segmentation Offload, GSO; Generic Receive Offload, GRO; Large Receive Offload, LRO. Diagnosevergleich Normalrichtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 Reverse-Richtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R Kleinere Schreibgröße [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -l 512 MSS testweise begrenzen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -M 1460 Zusätzliche Prüfung Paketmitschnitt mit Wireshark oder tcpdump; ICMP-Fragmentation-Needed-Nachrichten; Wiederholungsübertragungen; Interface-Fehler; MTU des VPN- oder Tunnelpfads; Treiber- und Firmwarestand. Das Deaktivieren von Offloading ist eine Systemänderung und kann die Leistung beeinflussen. Es sollte erst nach dokumentierter Diagnose, Freigabe und mit Rückfallplan erfolgen. 23. Wie werden WLAN-Verbindungen sinnvoll getestet? WLAN-Testaufbau anzeigen Ein geeigneter WLAN-Testaufbau ist: WLAN-Client ↓ Funkstrecke Access Point ↓ Ethernet Kabelgebundener iPerf3-Server Der Server sollte möglichst per Ethernet angebunden sein. Sind Client und Server beide im WLAN, teilen sie sich möglicherweise dieselbe Funkzeit. Das Ergebnis enthält dann zwei Funkübertragungen und ist schwerer zu interpretieren. Empfohlene Tests [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 Die UDP-Rate wird anschließend vorsichtig erhöht. Zusätzlich dokumentieren Frequenzband; Kanal; Kanalbreite; Signalstärke; Noise Floor, sofern verfügbar; PHY-Linkrate; Abstand zum Access Point; Anzahl aktiver Clients; Roaming; Energiesparmodus; verwendeter Access Point. Wichtiger Unterschied WLAN-Linkrate ≠ nutzbarer TCP-Durchsatz Die angezeigte PHY-Rate enthält Protokoll-, Funk-, Bestätigungs- und Verwaltungsanteile. Der tatsächlich nutzbare TCP-Durchsatz ist daher niedriger. 24. Wie werden VPN- und Standortverbindungen untersucht? Vergleichsmessungen anzeigen Messung ohne VPN Client → lokaler iPerf3-Server Messung durch VPN Client → VPN-Tunnel → entfernter iPerf3-Server Normalrichtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 Reverse-Richtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R UDP mit kontrollierter Rate [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 20M -t 30 Mögliche VPN-Engpässe CPU des VPN-Gateways; Verschlüsselungsleistung; MTU und MSS; Paketfragmentierung; Internet-Uplink; asymmetrische Bandbreite; Paketverlust; hohe Laufzeit; Single-Stream-Limit; QoS oder Traffic Shaping; Cloud-Gateway-Größe; NAT- oder Firewall-Verarbeitung. Vergleichstabelle Test Ohne VPN Mit VPN TCP Client → Server 940 Mbit/s 180 Mbit/s TCP Server → Client 940 Mbit/s 350 Mbit/s UDP ohne Verlust 800 Mbit/s 150 Mbit/s Jitter 0,2 ms 3,5 ms Diese Zahlen sind nur ein Dokumentationsbeispiel. Sie stellen keine allgemeinen Sollwerte dar. 25. Wie wird zwischen Netzwerk- und Speicherproblem unterschieden? iPerf3 und Dateiübertragung vergleichen Netzwerktest [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 Anschließend reale Dateiübertragung prüfen Beispielsweise: SMB; NFS; SFTP; HTTPS; Backupsoftware. Interpretation iPerf3 Dateiübertragung Mögliche Ursache Schnell Schnell Grundsätzlich unauffällig Schnell Langsam Speicher, Dateisystem, Protokoll, Virenscan oder Anwendung Langsam Langsam Netzwerkpfad oder Endsysteme weiter prüfen Schwankend Schwankend Paketverlust, WLAN, CPU, QoS oder konkurrierender Verkehr iPerf3 bietet außerdem -F , um eine Datei als Datenquelle oder -senke zu verwenden: [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -F testfile.bin Diese Funktion bezieht Speicherzugriffe in die Messung ein. -F macht iPerf3 nicht zu einem zuverlässigen Dateiübertragungsprogramm. Die empfangene Datei kann sich in Länge, Eigenschaften oder Inhalt vom Original unterscheiden. 26. Welche typischen Fehler treten bei iPerf3 auf? Fehlertabelle anzeigen Fehler oder Beobachtung Mögliche Ursache Prüfung command not found iPerf3 nicht installiert oder nicht im Suchpfad command -v iperf3 beziehungsweise Get-Command iperf3 unable to connect to server Server läuft nicht, falsche IP oder Firewall Listener und TCP-Port 5201 prüfen Connection refused Ziel erreichbar, aber kein Listener am Port Serverprozess und Port prüfen Connection timed out Firewall, Routing oder Rückwegproblem Nmap, Traceroute und Paketmitschnitt UDP-Test startet nicht TCP-Steuerverbindung fehlt TCP 5201 prüfen TCP funktioniert, UDP nicht UDP-Port gefiltert oder falsche Firewallregel UDP-Freigabe und Paketmitschnitt Ergebnis viel niedriger als Linkrate Protokolloverhead, CPU, Verlust oder Pfadbegrenzung CPU, Interface-Zähler und Gegenrichtung Reverse deutlich schneller Asymmetrie oder unterschiedlicher Endgeräteengpass Sender- und Empfängerseite vergleichen Ein Stream langsam, mehrere schnell Einzelstream-, Window-, Latenz- oder CPU-Limit -P 1 und -P 4 vergleichen Hoher UDP-Verlust Zielrate zu hoch oder Empfangspfad überlastet Rate schrittweise reduzieren Hoher Jitter Warteschlangen, WLAN, Überlastung oder QoS geringere Rate und paralleles Monitoring TCP bricht fast auf null ein Mögliches Offloading- oder MTU-Problem -R , -l , -M und Paketmitschnitt Ergebnis schwankt stark Test zu kurz oder konkurrierender Verkehr längerer Test und Monitoring Windows-Option funktioniert nicht Community-Build nicht vollständig kompatibel Buildquelle und unterstützte Optionen prüfen Server bleibt erreichbar Server ohne -1 gestartet Prozess kontrolliert beenden JSON-Datei leer Test nicht abgeschlossen oder Ausgabeproblem Befehl ohne Umleitung testen Port bereits belegt Anderer iPerf3-Prozess oder Dienst Listener des Ports prüfen 27. Welche Fehlinterpretationen müssen vermieden werden? Prüfungs- und Praxisfallen anzeigen Fehlinterpretation Richtige Einordnung iPerf3 zeigt die Internetgeschwindigkeit Es misst nur zwischen dem iPerf3-Client und -Server 1-Gbit/s-Link muss exakt 1 Gbit/s TCP erreichen Protokoll- und Systemanteile reduzieren den Nutzdurchsatz Hoher TCP-Durchsatz bedeutet null Paketverlust TCP kann Verlust durch Wiederholungen ausgleichen UDP-Verlust bedeutet defektes Kabel Die konfigurierte Senderate kann zu hoch sein Jitter ist dasselbe wie Latenz Jitter ist die Schwankung der Laufzeit -R wird auf dem Server eingegeben -R wird am Client angegeben UDP verwendet nur UDP 5201 Die Steuerverbindung verwendet weiterhin TCP Mehrere Streams zeigen die Leistung einer einzelnen Anwendung Eine Anwendung kann nur einen Stream verwenden --bidir entspricht zwei getrennten Tests Gleichzeitiger Verkehr beeinflusst beide Richtungen Ein kurzer Test ist immer aussagekräftig TCP Slow Start und kurzfristige Schwankungen beeinflussen ihn iPerf3 prüft Festplattenleistung Standardmäßig werden synthetische Daten verwendet iPerf3 und iPerf2 sind kompatibel Beide Werkzeuge verwenden unterschiedliche Protokolle Community-iPerf3 unter Windows ist offiziell unterstützt ESnet unterstützt iPerf3 unter Windows nicht offiziell Höchstmögliche Rate ist automatisch der richtige Test Produktive Netze müssen kontrolliert und stufenweise getestet werden 28. Wie sieht ein systematischer iPerf3-Diagnoseablauf aus? Empfohlene Schrittfolge anzeigen Vorbereitung Fehlerbild und erwarteten Durchsatz dokumentieren. Client, Server und Netzwerkpfad festlegen. Testgenehmigung und Wartungszeitraum prüfen. Maximale Testdauer und Datenrate festlegen. iPerf3-Versionen auf beiden Endpunkten dokumentieren. CPU-, Interface- und Monitoringansichten vorbereiten. Firewallfreigabe für TCP und gegebenenfalls UDP prüfen. Server Server möglichst kabelgebunden und leistungsfähig auswählen. Server an die richtige Adresse binden. Für Einzeltests möglichst -1 verwenden. Listener auf Port 5201 kontrollieren. Basistest TCP-Einzelstream für 30 Sekunden durchführen. TCP-Reverse-Test durchführen. Sender- und Receiverwerte dokumentieren. CPU- und Interface-Zähler prüfen. Vertiefung Vier parallele Streams testen. Ergebnis mit Einzelstream vergleichen. UDP bei niedriger Rate beginnen. Rate schrittweise erhöhen. Jitter und Paketverlust dokumentieren. IPv4 und IPv6 bei Bedarf getrennt testen. WLAN-, VPN- oder VLAN-Pfade separat vergleichen. Analyse Langsamen Pfad mit Ping, Traceroute und Paketmitschnitt untersuchen. Firewall-, Switch- und VPN-Monitoring vergleichen. MTU, MSS und Offloading nur bei konkreten Hinweisen untersuchen. iPerf3-Ergebnis mit realer Anwendung vergleichen. Abschluss Testbefehle und Ergebnisse speichern. Temporäre Firewallfreigaben zurücknehmen. Nicht mehr benötigten Serverprozess beenden. Beobachtung, Hypothese, Änderung und Nachtest dokumentieren. 29. Kurzreferenz – iPerf3-Befehle Befehlstabelle anzeigen Aufgabe Befehl Version [RO] iperf3 --version Hilfe [RO] iperf3 -h Server starten [TEST][DISRUPT] iperf3 -s Server für einen Test [TEST][DISRUPT] iperf3 -s -1 Server an IP binden [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 Anderen Port verwenden [TEST][DISRUPT] iperf3 -s -p 5002 TCP-Standardtest [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 30 Sekunden testen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 Gegenrichtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R Beide Richtungen gleichzeitig [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir Vier TCP-Streams [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 UDP mit 10 Mbit/s [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 UDP mit 100 Mbit/s [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 Reverse-UDP [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R Warmlaufphase auslassen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 Lokale IP binden [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10 IPv4 erzwingen [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 IPv6 erzwingen [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 JSON-Ausgabe [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J Logdatei [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile result.log Serverausgabe abrufen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 --get-server-output MSS setzen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460 Pufferlänge setzen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512 30. Kurzreferenz – wichtigste Optionen Optionstabelle anzeigen Option Bedeutung -s Servermodus -c HOST Clientmodus und Zielserver -p PORT Server- beziehungsweise Zielport -1 Server nach einer Clientverbindung beenden -t SEKUNDEN Testdauer -n MENGE Zu übertragende Datenmenge -k ANZAHL Anzahl zu übertragender Blöcke -i SEKUNDEN Ausgabeintervall -f m Ausgabe beispielsweise in Mbit/s -R Testrichtung umkehren --bidir Beide Richtungen gleichzeitig testen -u UDP statt TCP -b RATE Zielbitrate setzen -P ANZAHL Parallele Streams -O SEKUNDEN Warmlaufzeit aus Statistik auslassen -B ADRESSE An lokale IP-Adresse binden --bind-dev An ein Interface binden, sofern unterstützt -4 IPv4 erzwingen -6 IPv6 erzwingen -J JSON-Ausgabe --json-stream Zeilenweise JSON-Ausgabe --logfile Ausgabe in Logdatei --forceflush Ausgabe je Intervall sofort schreiben --timestamps Zeitstempel voranstellen --get-server-output Serverausgabe am Client abrufen -M TCP-MSS festlegen -l Puffer- beziehungsweise UDP-Datagrammlänge -w Socketpuffergröße setzen -N Nagle-Algorithmus für TCP/SCTP deaktivieren -Z Zero-Copy-Sendemethode verwenden --dont-fragment IPv4-DF-Bit bei UDP setzen Merksätze iPerf3 benötigt immer einen iPerf3-Server und einen iPerf3-Client. iPerf2 und iPerf3 sind nicht miteinander kompatibel. iPerf3 wird von ESnet offiziell für Linux, FreeBSD und macOS, aber nicht für Windows unterstützt. Der Standardport ist 5201. Bei UDP wird weiterhin eine TCP-Steuerverbindung benötigt. Standardmäßig sendet der Client zum Server. -R wird am Client angegeben und kehrt die Datenrichtung um. TCP versucht standardmäßig, die verfügbare Kapazität auszunutzen. UDP sollte immer mit einer kontrollierten niedrigen Rate begonnen werden. Jitter ist eine Laufzeitschwankung und nicht die absolute Latenz. UDP-Paketverlust kann durch eine zu hoch eingestellte Senderate entstehen. Ein Einzelstream und mehrere Parallelstreams beantworten unterschiedliche Fragen. Ein schneller iPerf3-Test beweist nicht, dass eine Anwendung schnell arbeitet. CPU, Interface-Zähler, Linkrate und Netzwerkpfad müssen zusammen mit dem Ergebnis dokumentiert werden. Vergleichstests müssen dieselben Endpunkte, Richtungen, Versionen und Parameter verwenden. Leistungstests können produktiven Datenverkehr beeinträchtigen und müssen abgestimmt durchgeführt werden. Quellen Offizielle iPerf3-Dokumentation von ESnet ESnet – Invoking iPerf3 und offizielle Optionsreferenz Offizielle iPerf3-FAQ von ESnet Offizielles iPerf3-Repository von ESnet ESnet Fasterdata – iPerf3 ESnet Fasterdata – Throughput Tool Comparison ESnet Fasterdata – Multi-Stream iPerf3 2.9 curl – HTTP-, HTTPS-, API-, DNS-, Proxy- und Verbindungsdiagnose Ziel dieser Seite curl überträgt Daten anhand einer URL und eignet sich besonders zur Diagnose von Webdiensten und APIs. Administratoren können damit unter anderem prüfen: ob ein TCP-Dienst erreichbar ist; ob ein Webserver auf HTTP oder HTTPS antwortet; welchen HTTP-Statuscode ein Server zurückgibt; ob Weiterleitungen funktionieren; ob DNS-Auflösung und Zielserver zusammenpassen; ob TLS-Verbindungen und Zertifikatsprüfungen funktionieren; ob SNI und virtuelle Hosts korrekt verarbeitet werden; wie lange DNS, TCP-Verbindungsaufbau, TLS und Serverantwort dauern; ob ein Proxy Verbindungen erlaubt oder verändert; ob bestimmte HTTP-Header übertragen werden; ob eine API auf GET-, POST-, PUT-, PATCH- oder DELETE-Anfragen reagiert; ob IPv4 und IPv6 unterschiedliche Ergebnisse liefern. curl ist kein vollständiger Browser. JavaScript, grafische Darstellung, Browser-Erweiterungen und komplexe Browser-Sitzungen werden nicht wie in einem normalen Webbrowser ausgeführt. Kennzeichnungen Kennzeichnung Bedeutung [RO] Lokale Informationsabfrage [TEST] Aktive Netzwerk- oder Anwendungsanfrage [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Befehl liest oder erstellt eine Datei [SENS] Anfrage oder Ausgabe kann sensible Informationen enthalten [CHANGE] Anfrage kann Daten oder einen Zustand verändern [DISRUPT] Anfrage kann einen Dienst oder produktive Daten beeinflussen 1. Wie wird curl unter Windows, Linux und macOS aufgerufen? Betriebssystemübersicht anzeigen Aufgabe Windows Linux macOS Programmpfad [RO] Get-Command curl.exe [RO] command -v curl [RO] command -v curl Version [RO] curl.exe --version [RO] curl --version [RO] curl --version Kurzhilfe [RO] curl.exe --help [RO] curl --help [RO] curl --help Gesamte Hilfe [RO] curl.exe --manual [RO] curl --manual [RO] curl --manual Lokales Handbuch Nicht standardmäßig [RO] man curl [RO] man curl Wichtig unter Windows PowerShell In älteren Windows-PowerShell-Versionen kann curl als Alias für Invoke-WebRequest definiert sein. Dann verhält sich der Befehl nicht wie das echte curl-Programm. Deshalb unter Windows eindeutig verwenden: [RO] curl.exe --version Alias prüfen: [RO] Get-Command curl Wenn als Befehlstyp Alias und als Ziel Invoke-WebRequest erscheint, muss für die in dieser Seite gezeigte Syntax ausdrücklich curl.exe verwendet werden. Build-Funktionen prüfen [RO] curl --version Die Ausgabe zeigt unter anderem: curl-Version; verwendete TLS-Bibliothek; unterstützte Protokolle; unterstützte Funktionen; HTTP/2- oder HTTP/3-Unterstützung; IPv6-Unterstützung; Kompressionsunterstützung. Nicht jede curl-Installation unterstützt alle Optionen und Protokolle. Entscheidend ist der lokal installierte Build. 2. Was passiert bei einem einfachen curl-Aufruf? Grundlegende Anfrage anzeigen Linux und macOS: [TEST][SENS] curl https://example.com/ Windows: [TEST][SENS] curl.exe https://example.com/ Ohne weitere Optionen schreibt curl den empfangenen Antwortinhalt auf die Standardausgabe. Bei einer HTML-Seite erscheint daher der HTML-Quelltext: ... Explizites URL-Schema verwenden Empfohlen: https://example.com/ Nicht empfohlen: example.com Ohne Schema versucht curl, das Protokoll zu erraten. Für reproduzierbare Diagnosen sollte immer ausdrücklich http:// oder https:// angegeben werden. URL in Anführungszeichen setzen [TEST][SENS] curl 'https://example.com/search?q=test&lang=de' Besonders Zeichen wie diese können von einer Shell interpretiert werden: & ? * [ ] { } In PowerShell und klassischen Windows-Kommandozeilen können sich die Regeln für Anführungszeichen unterscheiden. Bei einfachen URLs funktionieren doppelte Anführungszeichen meist plattformübergreifend: [TEST][SENS] curl "https://example.com/search?q=test&lang=de" 3. Wie werden HTTP-Header angezeigt? Headeroptionen anzeigen Nur Antwortheader anfordern [TEST][SENS] curl -I https://example.com/ -I beziehungsweise --head veranlasst curl bei HTTP, eine HEAD -Anfrage zu senden. Header und Antwortinhalt anzeigen [TEST][SENS] curl -i https://example.com/ -i fügt die Antwortheader vor dem Inhalt ein. Antwortheader separat auf die Standardausgabe schreiben [TEST][SENS] curl -D - https://example.com/ Header in eine Datei schreiben [TEST][FILE][SENS] curl -D response-headers.txt -o response-body.html https://example.com/ Wichtiger Unterschied Option Wirkung -I Sendet bei HTTP eine HEAD-Anfrage -i Zeigt Header und Antwortinhalt einer normalen Anfrage -D DATEI Schreibt empfangene Header separat -o DATEI Schreibt den Antwortinhalt in eine Datei Nicht jeder Server behandelt HEAD und GET identisch. Ein erfolgreicher HEAD-Test beweist deshalb nicht sicher, dass ein GET-Aufruf denselben Status erhält. GET ausführen, aber Antwortinhalt verwerfen Linux und macOS: [TEST][SENS] curl -sS -o /dev/null -D - https://example.com/ Windows: [TEST][SENS] curl.exe -sS -o NUL -D - https://example.com/ Damit wird eine normale GET-Anfrage durchgeführt, ohne den vollständigen Inhalt im Terminal auszugeben. 4. Wie wird nur der HTTP-Statuscode ausgegeben? Statuscode-Prüfung anzeigen Linux und macOS: [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ Windows: [TEST] curl.exe -sS -o NUL -w "%{http_code}\n" https://example.com/ Statuscode und Ziel-URL nach Weiterleitungen Linux und macOS: [TEST] curl -sS -L -o /dev/null -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ Windows: [TEST] curl.exe -sS -L -o NUL -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ HTTP-Statusgruppen Bereich Bedeutung 100–199 Information 200–299 Erfolgreiche Verarbeitung 300–399 Weiterleitung 400–499 Anfrage- oder Clientfehler 500–599 Serverfehler Häufige Statuscodes Status Bedeutung 200 OK Anfrage erfolgreich 201 Created Ressource erstellt 204 No Content Erfolgreich, aber ohne Antwortinhalt 301 Moved Permanently Dauerhafte Weiterleitung 302 Found Temporäre Weiterleitung 304 Not Modified Ressource seit Cacheprüfung nicht geändert 307 Temporary Redirect Temporäre Weiterleitung unter Beibehaltung der Methode 308 Permanent Redirect Dauerhafte Weiterleitung unter Beibehaltung der Methode 400 Bad Request Anfrage syntaktisch oder fachlich ungültig 401 Unauthorized Authentifizierung fehlt oder ist ungültig 403 Forbidden Anfrage verstanden, Zugriff verweigert 404 Not Found Ressource nicht gefunden 405 Method Not Allowed HTTP-Methode nicht erlaubt 408 Request Timeout Server wartete zu lange auf die Anfrage 409 Conflict Konflikt mit aktuellem Ressourcenstatus 429 Too Many Requests Rate Limit erreicht 500 Internal Server Error Interner Serverfehler 502 Bad Gateway Gateway oder Proxy erhielt ungültige Upstream-Antwort 503 Service Unavailable Dienst momentan nicht verfügbar 504 Gateway Timeout Gateway erhielt nicht rechtzeitig eine Upstream-Antwort Ein HTTP-Fehlercode bedeutet, dass die HTTP-Kommunikation grundsätzlich stattgefunden hat. DNS, TCP und normalerweise auch TLS waren bis zu diesem Punkt bereits erfolgreich. 5. Warum liefert curl bei einem HTTP-Fehler trotzdem Exitcode 0? HTTP-Status und curl-Exitcode unterscheiden Ohne --fail bewertet curl eine erfolgreich empfangene HTTP-Antwort als erfolgreiche Übertragung – auch wenn der Server beispielsweise 404 oder 500 zurückgibt. HTTP-Statuscode 404 curl-Exitcode 0 Das bedeutet: Übertragung technisch erfolgreich Anwendung meldet HTTP-Fehler Bei HTTP-Fehlern mit Exitcode ungleich 0 beenden [TEST] curl --fail https://example.com/missing Kurzform: [TEST] curl -f https://example.com/missing HTTP-Fehlercode liefern und Antwortinhalt behalten [TEST][SENS] curl --fail-with-body https://example.com/missing --fail-with-body : liefert bei HTTP-Status 400 oder höher einen curl-Fehler; behält den Server-Antwortinhalt bei; verwendet bei einem entsprechenden HTTP-Fehler normalerweise curl-Exitcode 22 . Für Skripte häufig sinnvoll [TEST] curl -sS --fail-with-body https://example.com/health Option Verhalten -s Fortschrittsanzeige unterdrücken -S Fehlermeldung trotz -s anzeigen --fail-with-body HTTP-Fehler als curl-Fehler behandeln und Inhalt behalten 6. Wie werden Weiterleitungen untersucht? Redirect-Diagnose anzeigen Nur erste Antwort anzeigen [TEST][SENS] curl -I http://example.com/ Mögliche Ausgabe: HTTP/1.1 301 Moved Permanently Location: https://example.com/ Weiterleitungen automatisch verfolgen [TEST][SENS] curl -L http://example.com/ Header aller Weiterleitungsstufen anzeigen [TEST][SENS] curl -L -I http://example.com/ Maximale Anzahl Weiterleitungen begrenzen [TEST][SENS] curl -L --max-redirs 5 https://example.com/ Effektive Ziel-URL ausgeben Linux und macOS: [TEST] curl -sS -L -o /dev/null -w "%{url_effective}\n" http://example.com/ Windows: [TEST] curl.exe -sS -L -o NUL -w "%{url_effective}\n" http://example.com/ Typische Redirect-Probleme HTTP leitet nicht auf HTTPS weiter; Weiterleitung zeigt auf falschen Hostnamen; Endlosschleife zwischen zwei URLs; falscher Port in Location ; interne Serveradresse wird offengelegt; Reverse Proxy erzeugt falsches Schema; Anwendung berücksichtigt X-Forwarded-Proto nicht; Authentifizierungscookie gilt nicht für das neue Ziel; Weiterleitung funktioniert im Browser wegen Cache, mit curl aber nicht. --location-trusted kann Zugangsdaten auch an andere Weiterleitungsziele weitergeben. Diese Option sollte aus Sicherheitsgründen nicht unüberlegt verwendet werden. 7. Wie wird eine ausführliche Verbindungsdiagnose durchgeführt? Verbose-Ausgabe `-v` anzeigen [TEST][SENS] curl -v https://example.com/ Die ausführliche Ausgabe enthält unter anderem: DNS-Ergebnis; ausgewählte IP-Adresse; TCP-Verbindungsaufbau; TLS-Verhandlung; Zertifikatsinformationen; ausgehandeltes Protokoll; gesendete HTTP-Header; empfangene HTTP-Header; Weiterleitungsinformationen; Wiederverwendung einer Verbindung. Kennzeichnungen in der Ausgabe Zeichen Bedeutung * curl-interne Status- oder Verbindungsinformation > Von curl an den Server gesendete Daten beziehungsweise Header < Vom Server empfangene Daten beziehungsweise Header { oder } In bestimmten Trace-Ausgaben übertragene Daten Beispiel: > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/... > Accept: */* < HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 1256 Nur Header und Verbindungsinformationen, Inhalt verwerfen Linux und macOS: [TEST][SENS] curl -v -o /dev/null https://example.com/ Windows: [TEST][SENS] curl.exe -v -o NUL https://example.com/ Die Verbose-Ausgabe kann Zugangsdaten, Cookies, API-Token oder interne Header enthalten. Sie muss vor einer Weitergabe geprüft und bereinigt werden. 8. Wie wird eine detaillierte Ablaufverfolgung erstellt? Trace-Optionen anzeigen ASCII-Trace in eine Datei schreiben [TEST][FILE][SENS] curl --trace-ascii curl-trace.txt https://example.com/ Trace mit Zeitstempeln [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/ Binären Trace schreiben [TEST][FILE][SENS] curl --trace curl-trace.bin https://example.com/ Ein Trace kann deutlich mehr Informationen als -v enthalten, darunter: vollständige Header; Nutzdaten; Cookies; Formulardaten; Authentifizierungsinformationen; API-Antworten; interne Adressen. Trace-Dateien sind daher als sensible Diagnosedaten zu behandeln. Nicht gleichzeitig unkontrolliert verwenden -v --trace --trace-ascii --trace beziehungsweise --trace-ascii überschreibt die frühere Auswahl der Trace-Ausgabe. Für eine reproduzierbare Diagnose sollte nur die tatsächlich benötigte Variante verwendet werden. 9. Wie werden DNS-, TCP-, TLS- und Serverzeiten gemessen? Zeitmessung mit `--write-out` anzeigen Linux und macOS: [TEST] curl -sS -o /dev/null -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/ Windows: [TEST] curl.exe -sS -o NUL -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/ Bedeutung der Zeitwerte Variable Bedeutung time_namelookup Zeit bis zum Abschluss der Namensauflösung time_connect Zeit vom Start bis zur hergestellten TCP-Verbindung time_appconnect Zeit bis zum Abschluss des TLS- oder anderen Anwendungs-Handshakes time_pretransfer Zeit bis unmittelbar vor Beginn der Übertragung time_starttransfer Zeit bis zum ersten empfangenen Antwortbyte time_redirect Gesamtdauer vorheriger Weiterleitungen time_total Gesamtdauer der Übertragung http_code Letzter empfangener HTTP-Statuscode remote_ip Tatsächlich verwendete Ziel-IP-Adresse remote_port Tatsächlich verwendeter Zielport local_ip Verwendete lokale IP-Adresse num_redirects Anzahl verfolgter Weiterleitungen url_effective Effektive URL nach Weiterleitungen Erweiterte Messung Linux und macOS: [TEST] curl -sS -L -o /dev/null -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/ Windows: [TEST] curl.exe -sS -L -o NUL -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/ 10. Wie werden Zeitmessungen richtig interpretiert? Zeitanteile einordnen Die Zeitvariablen sind überwiegend kumulativ seit Beginn des curl-Aufrufs. Für einzelne Phasen müssen Differenzen gebildet werden. DNS-Dauer DNS = time_namelookup TCP-Aufbau nach DNS TCP-Phase = time_connect - time_namelookup TLS-Handshake nach TCP-Aufbau TLS-Phase = time_appconnect - time_connect Serververarbeitung bis zum ersten Byte Bei HTTPS vereinfacht: Server-/Anwendungsphase = time_starttransfer - time_appconnect Übertragung nach dem ersten Byte Downloadphase = time_total - time_starttransfer Beispiel Messwert Wert time_namelookup 0,020 s time_connect 0,050 s time_appconnect 0,120 s time_starttransfer 0,420 s time_total 0,500 s Daraus folgt: DNS = 0,020 s TCP = 0,050 - 0,020 = 0,030 s TLS = 0,120 - 0,050 = 0,070 s Server bis erstes Byte = 0,420 - 0,120 = 0,300 s Restliche Übertragung = 0,500 - 0,420 = 0,080 s Diese Zuordnung ist eine Diagnosehilfe. Proxys, wiederverwendete Verbindungen, Weiterleitungen und unterschiedliche Protokolle können die Interpretation verändern. 11. Wie werden Verbindungs- und Gesamtzeit begrenzt? Timeouts anzeigen Maximal fünf Sekunden für den Verbindungsaufbau [TEST] curl --connect-timeout 5 https://example.com/ Maximal 15 Sekunden für den gesamten Vorgang [TEST] curl --max-time 15 https://example.com/ Kurzform: [TEST] curl -m 15 https://example.com/ Kombination [TEST] curl --connect-timeout 5 --max-time 15 https://example.com/ Option Begrenzter Bereich --connect-timeout Verbindungsphase einschließlich notwendiger DNS-, TCP- und gegebenenfalls Proxy-/TLS-Vorgänge bis zur Verbindung --max-time Gesamter curl-Vorgang Langsame Übertragung abbrechen [TEST] curl --speed-limit 1000 --speed-time 10 https://example.com/large-file Der Vorgang wird abgebrochen, wenn die Übertragungsrate während des festgelegten Zeitraums unter dem Grenzwert liegt. Zu kurze Timeouts können langsame, aber funktionierende Verbindungen fälschlich als Fehler erscheinen lassen. 12. Wie werden IPv4 und IPv6 getrennt geprüft? IPv4-/IPv6-Vergleich anzeigen IPv4 erzwingen [TEST] curl -4 -v https://example.com/ IPv6 erzwingen [TEST] curl -6 -v https://example.com/ Nur Status und Ziel-IP vergleichen Linux und macOS: [TEST] curl -4 -sS -o /dev/null -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ [TEST] curl -6 -sS -o /dev/null -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ Windows: [TEST] curl.exe -4 -sS -o NUL -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ [TEST] curl.exe -6 -sS -o NUL -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ Interpretation IPv4 IPv6 Mögliche Ursache Funktioniert Funktioniert nicht IPv6-DNS, Routing, Firewall, Neighbor Discovery oder MTU Langsam Schnell Unterschiedlicher Netzwerkpfad oder unterschiedliche Gegenstelle Schnell Langsam IPv6-Pfad, Tunnel oder Zielserver prüfen Unterschiedliche Inhalte DNS-/CDN-/Proxy-Zuordnung untersuchen 13. Wie wird ein Hostname gezielt gegen eine bestimmte IP-Adresse getestet? DNS umgehen, Hostname und TLS-SNI erhalten Für HTTPS muss der Hostname normalerweise gleichzeitig für diese Funktionen erhalten bleiben: HTTP- Host -Header; TLS-SNI; Zertifikatsprüfung; virtuelle Hostauswahl. Dafür eignet sich --resolve . [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ Dieser Befehl bedeutet: Hostname in URL: example.com Zielport: 443 Tatsächliche Ziel-IP: 192.0.2.20 HTTP-Host: example.com TLS-SNI: example.com Zertifikatsname: example.com Ausführlicher Test [TEST][SENS] curl -v --resolve example.com:443:192.0.2.20 https://example.com/ HTTP ohne TLS [TEST][SENS] curl --resolve example.com:80:192.0.2.20 http://example.com/ Warum nicht nur die IP-Adresse aufrufen? curl https://192.0.2.20/ Dabei verwendet curl die IP-Adresse als Zielnamen. Das kann verursachen: falschen virtuellen Host; falsches TLS-SNI; Zertifikatsnamensfehler; andere Serverantwort; Standardseite des Reverse Proxys. Nur einen Host-Header setzen curl -H "Host: example.com" https://192.0.2.20/ setzt zwar den HTTP-Host-Header, aber nicht automatisch das passende TLS-SNI für example.com . Für HTTPS ist --resolve deshalb in der Regel die richtige Diagnoseoption. 14. Was ist der Unterschied zwischen --resolve und --connect-to ? Zielumleitung erklären --resolve [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ --resolve fügt für die angegebene Host-/Portkombination eine temporäre Namenszuordnung hinzu. --connect-to [TEST][SENS] curl --connect-to example.com:443:192.0.2.20:8443 https://example.com/ Damit verbindet sich curl tatsächlich mit: 192.0.2.20:8443 Die ursprüngliche URL bleibt: https://example.com/ Dadurch bleiben insbesondere: URL-Hostname; TLS-SNI; Zertifikatsprüfung; HTTP-Host auf example.com bezogen. Typischer Einsatz neuen Reverse Proxy vor DNS-Umschaltung testen; Backend auf einem anderen Port prüfen; Load-Balancer-Knoten gezielt untersuchen; Blue-Green-Deployment vergleichen; fehlerhaften DNS-Eintrag umgehen, ohne Hostname und SNI zu verlieren. Beide Optionen gelten nur für den jeweiligen curl-Aufruf und verändern nicht dauerhaft die lokale DNS-Konfiguration. 15. Wie werden TLS und Zertifikate geprüft? TLS-Diagnose anzeigen Normale Zertifikatsprüfung [TEST][SENS] curl -v https://example.com/ curl prüft dabei abhängig vom verwendeten TLS-Backend unter anderem: Vertrauenskette; Gültigkeitszeitraum; Hostname; unterstützte TLS-Versionen; Zertifizierungsstelle; TLS-Handshake. Bestimmte CA-Datei verwenden [TEST][FILE][SENS] curl --cacert company-ca.pem https://internal.example.com/ TLS 1.2 oder höher anfordern [TEST][SENS] curl --tlsv1.2 https://example.com/ --tlsv1.2 legt die minimale TLS-Version auf 1.2 fest. Neuere Versionen können weiterhin ausgehandelt werden. Maximal TLS 1.2 [TEST][SENS] curl --tlsv1.2 --tls-max 1.2 https://example.com/ TLS 1.3 oder höher anfordern [TEST][SENS] curl --tlsv1.3 https://example.com/ Die Unterstützung hängt von curl-Version und TLS-Bibliothek ab. Clientzertifikat [TEST][FILE][SENS] curl --cert client.pem --key client.key https://example.com/ Format und Optionen können vom verwendeten TLS-Backend abhängen. Zertifikatsprüfung deaktivieren [TEST][SENS] curl -k https://example.com/ -k beziehungsweise --insecure deaktiviert die normale Echtheitsprüfung. Dadurch kann curl keine vertrauenswürdige Identität des Servers garantieren. -k darf höchstens als klar gekennzeichneter Vergleichstest verwendet werden. Es ist keine Lösung für ein Zertifikatsproblem. Sinnvolle Interpretation Normaler Test Mit -k Mögliche Ursache Fehler Erfolgreich Zertifikatsvertrauen, Hostname oder Zertifikatskette prüfen Fehler Fehler Problem wahrscheinlich nicht nur Zertifikatsprüfung Erfolgreich Erfolgreich Kein Grund, -k dauerhaft zu verwenden 16. Wie werden HTTP-Versionen geprüft? HTTP/1.1, HTTP/2 und HTTP/3 anzeigen HTTP/1.1 anfordern [TEST][SENS] curl --http1.1 -v https://example.com/ HTTP/2 anfordern [TEST][SENS] curl --http2 -v https://example.com/ HTTP/3 versuchen [TEST][SENS] curl --http3 -v https://example.com/ Ausschließlich HTTP/3 [TEST][SENS] curl --http3-only -v https://example.com/ Die Optionen funktionieren nur, wenn der installierte curl-Build die jeweilige Protokollversion unterstützt: [RO] curl --version Interpretation Beobachtung Mögliche Ursache HTTP/1.1 funktioniert, HTTP/2 nicht Proxy, TLS-ALPN, Server- oder curl-Buildproblem HTTP/2 funktioniert, HTTP/3 nicht QUIC/UDP, Firewall, Serverunterstützung oder curl-Build HTTP/3 funktioniert nur ohne VPN VPN oder Firewall blockiert beziehungsweise beeinträchtigt UDP Unterschiedliche Antworten Reverse Proxy oder Anwendung behandelt Protokolle unterschiedlich HTTP/3 verwendet QUIC über UDP. Ein erfolgreicher HTTPS-Test über TCP beweist deshalb nicht, dass HTTP/3 erreichbar ist. 17. Wie werden eigene Request-Header gesetzt? Header mit `-H` anzeigen Accept-Header setzen [TEST][SENS] curl -H "Accept: application/json" https://api.example.com/status Benutzerdefinierten Header setzen [TEST][SENS] curl -H "X-Diagnostic-ID: test-001" https://example.com/ Mehrere Header [TEST][SENS] curl -H "Accept: application/json" -H "X-Diagnostic-ID: test-001" https://api.example.com/status User-Agent setzen [TEST][SENS] curl -A "IT-Diagnose/1.0" https://example.com/ Alternativ: [TEST][SENS] curl -H "User-Agent: IT-Diagnose/1.0" https://example.com/ Header entfernen [TEST][SENS] curl -H "User-Agent:" https://example.com/ Ein Header mit leerem Wert nach dem Doppelpunkt wird entfernt. Vorsicht Benutzerdefinierte Header können: Routing im Reverse Proxy verändern; Authentifizierung beeinflussen; Caches umgehen; Sicherheitsregeln auslösen; sensible Informationen enthalten. Header aus Browser-Entwicklerwerkzeugen dürfen nicht ungeprüft übernommen werden. Insbesondere Cookies, Tokens und Sitzungskennungen müssen geschützt werden. 18. Wie werden GET-Parameter korrekt übertragen? Query-Parameter anzeigen Parameter direkt in der URL [TEST][SENS] curl "https://api.example.com/search?q=server&limit=10" Parameter URL-codieren [TEST][SENS] curl -G --data-urlencode "q=Server Fehleranalyse" --data-urlencode "limit=10" https://api.example.com/search -G sorgt dafür, dass die mit --data-urlencode angegebenen Daten als URL-Query und nicht als POST-Body verwendet werden. Ergebnis sinngemäß: https://api.example.com/search?q=Server%20Fehleranalyse&limit=10 Warum URL-Encoding wichtig ist Zeichen wie diese besitzen in URLs eine besondere Bedeutung: Leerzeichen & = ? # + % --data-urlencode verhindert viele Fehler durch nicht korrekt codierte Werte. 19. Wie werden POST-, PUT-, PATCH- und DELETE-Anfragen getestet? HTTP-Methoden und API-Beispiele anzeigen Ändernde API-Anfragen dürfen nur gegen ausdrücklich freigegebene Testressourcen ausgeführt werden. POST mit Formulardaten [TEST][CHANGE][SENS] curl -X POST -d "name=Max Mustermann" -d "active=true" https://api.example.com/users Bei Verwendung von -d wählt curl bei HTTP automatisch POST, sofern keine andere Methode angegeben wird. -X POST ist deshalb häufig nicht erforderlich: [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" -d "active=true" https://api.example.com/users POST mit JSON [TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"name":"Max Mustermann","active":true}' https://api.example.com/users Neuere curl-Versionen unterstützen: [TEST][CHANGE][SENS] curl --json '{"name":"Max Mustermann","active":true}' https://api.example.com/users --json setzt geeignete JSON-Header und verwendet die Daten als Request-Body. Die Verfügbarkeit hängt von der curl-Version ab. JSON aus Datei [TEST][FILE][CHANGE][SENS] curl -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users PUT [TEST][CHANGE][SENS] curl -X PUT -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users/123 PATCH [TEST][CHANGE][SENS] curl -X PATCH -H "Content-Type: application/json" -d '{"active":false}' https://api.example.com/users/123 DELETE [TEST][CHANGE][DISRUPT][SENS] curl -X DELETE https://api.example.com/users/123 OPTIONS [TEST][SENS] curl -i -X OPTIONS https://api.example.com/users OPTIONS kann Hinweise auf erlaubte Methoden oder CORS-Header liefern. Server müssen jedoch nicht alle Fähigkeiten vollständig darüber offenlegen. 20. Was ist der Unterschied zwischen -d und --data-binary ? Übertragung von Request-Daten erklären Option Verhalten -d beziehungsweise --data Sendet HTTP-Daten; Zeilenenden und Dateieinlesung folgen den Regeln dieser Option --data-raw Wie --data , aber @ wird nicht als Dateiverweis behandelt --data-binary Überträgt Daten weitgehend unverändert --data-urlencode URL-codiert die Daten --json Sendet JSON und setzt passende Header Textdaten [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" https://api.example.com/users Datei binär beziehungsweise unverändert senden [TEST][FILE][CHANGE][SENS] curl --data-binary @request.json https://api.example.com/import Wörtliches @ senden [TEST][CHANGE][SENS] curl --data-raw "@example" https://api.example.com/test Bei -d @datei interpretiert curl den Wert als Dateipfad. Bei --data-raw wird ein führendes @ dagegen wörtlich übertragen. 21. Wie werden Dateien hoch- und heruntergeladen? Dateitransfer anzeigen Antwort in benannte Datei schreiben [TEST][FILE][SENS] curl -o download.bin https://example.com/file.bin Remote-Dateinamen verwenden [TEST][FILE][SENS] curl -O https://example.com/file.bin Weiterleitung verfolgen und Remote-Dateinamen verwenden [TEST][FILE][SENS] curl -L -O https://example.com/file.bin Teilweise Übertragung fortsetzen [TEST][FILE][SENS] curl -C - -O https://example.com/file.bin Download bei Fehler entfernen [TEST][FILE][SENS] curl --fail --remove-on-error -o download.bin https://example.com/file.bin Datei mit PUT hochladen [TEST][FILE][CHANGE][SENS] curl -T upload.bin https://example.com/upload.bin Multipart-Formularupload [TEST][FILE][CHANGE][SENS] curl -F "file=@upload.bin" https://example.com/upload Vor einem Upload müssen Ziel, Methode, Überschreibverhalten und Berechtigung geprüft werden. 22. Wie wird eine HTTP-Authentifizierung getestet? Basic, Digest, Bearer und Negotiate anzeigen Benutzername angeben und Passwort interaktiv abfragen [TEST][SENS] curl -u "max.mustermann" https://example.com/protected curl fordert das Passwort interaktiv an. Benutzername und Passwort direkt angeben [TEST][SENS] curl -u "max.mustermann:BEISPIELPASSWORT" https://example.com/protected Diese Schreibweise ist für reale Zugangsdaten nicht empfohlen, weil das Passwort: in der Shell-Historie; in Prozessinformationen; in Bildschirmaufzeichnungen; in Supportprotokollen sichtbar werden kann. Basic Authentication ausdrücklich verwenden [TEST][SENS] curl --basic -u "max.mustermann" https://example.com/protected Digest Authentication [TEST][SENS] curl --digest -u "max.mustermann" https://example.com/protected Unterstützte Methode automatisch auswählen [TEST][SENS] curl --anyauth -u "max.mustermann" https://example.com/protected --anyauth kann eine zusätzliche Anfrage erzeugen, um die angebotenen Methoden zu erkennen. Bearer-Token [TEST][SENS] curl -H "Authorization: Bearer TOKEN_NICHT_HIER_EINTRAGEN" https://api.example.com/status Negotiate/Kerberos, sofern Build und Umgebung es unterstützen [TEST][SENS] curl --negotiate -u : https://example.com/protected Zugangsdaten, Tokens und Cookies dürfen nicht in BookStack-Seiten, Tickets oder allgemein lesbaren Skripten gespeichert werden. 23. Wie werden Cookies untersucht? Cookie-Befehle anzeigen Cookie direkt senden [TEST][SENS] curl -b "session=BEISPIELWERT" https://example.com/ Cookies aus Datei lesen [TEST][FILE][SENS] curl -b cookies.txt https://example.com/ Empfangene Cookies speichern [TEST][FILE][SENS] curl -c cookies.txt https://example.com/login Cookies lesen und aktualisiert wieder speichern [TEST][FILE][SENS] curl -b cookies.txt -c cookies.txt https://example.com/ Option Bedeutung -b beziehungsweise --cookie Cookies senden oder aus Datei lesen -c beziehungsweise --cookie-jar Empfangene Cookies speichern Cookie-Dateien können aktive Sitzungen ermöglichen und sind daher sensible Zugangsdaten. Typische Cookie-Probleme falsche Domain; falscher Pfad; Secure -Cookie über HTTP; abgelaufenes Cookie; SameSite-Verhalten; Weiterleitung zu anderem Host; mehrere Cookies mit gleichem Namen; Anwendung erwartet zusätzliche CSRF-Token. curl bildet nicht jedes Browser-Sicherheitsverhalten vollständig identisch ab. Ein mit curl funktionierender Cookie-Test beweist daher nicht automatisch, dass eine Browseranwendung fehlerfrei arbeitet. 24. Wie wird ein HTTP-Proxy getestet? Proxy-Diagnose anzeigen HTTP-Proxy verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/ Langform: [TEST][SENS] curl --proxy http://proxy.example.com:8080 https://example.com/ Proxy-Benutzername interaktiv verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 -U "max.mustermann" https://example.com/ Proxy umgehen [TEST][SENS] curl --noproxy example.com https://example.com/ Proxy für alle Ziele umgehen [TEST][SENS] curl --noproxy "*" https://example.com/ Umgebungsvariablen prüfen Linux und macOS: [RO][SENS] env | grep -i proxy PowerShell: [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy' Häufig verwendete Variablen: http_proxy https_proxy all_proxy NO_PROXY no_proxy Wichtiger Sicherheitshinweis Die Variable http_proxy wird von curl aus Sicherheitsgründen nur in Kleinschreibung akzeptiert. Andere Proxyvariablen können je nach Protokoll und Umgebung unterschiedliche Groß-/Kleinschreibungen unterstützen. Direkt- und Proxytest vergleichen Direkt: [TEST][SENS] curl --noproxy "*" -v https://example.com/ Über Proxy: [TEST][SENS] curl -x http://proxy.example.com:8080 -v https://example.com/ 25. Wie wird ein SOCKS-Proxy getestet? SOCKS4- und SOCKS5-Optionen anzeigen SOCKS5-Proxy, DNS-Auflösung durch den Proxy [TEST][SENS] curl --socks5-hostname 192.0.2.50:1080 https://example.com/ SOCKS5-Proxy, lokale DNS-Auflösung [TEST][SENS] curl --socks5 192.0.2.50:1080 https://example.com/ SOCKS4a [TEST][SENS] curl --socks4a 192.0.2.50:1080 https://example.com/ Wichtiger Unterschied Option DNS-Auflösung --socks5 Lokal durch curl --socks5-hostname Durch den SOCKS5-Proxy --socks4 Lokal --socks4a Durch den Proxy Der Unterschied ist wichtig, wenn: interne DNS-Namen nur am Proxy auflösbar sind; DNS-Leaks vermieden werden sollen; lokale und entfernte DNS-Ergebnisse voneinander abweichen. 26. Wie werden komprimierte Antworten geprüft? Kompression anzeigen [TEST][SENS] curl --compressed -v https://example.com/ Mit --compressed fordert curl eine unterstützte komprimierte Antwort an und dekomprimiert sie anschließend. In der Anfrage kann beispielsweise erscheinen: Accept-Encoding: deflate, gzip, br, zstd Die tatsächlich angebotenen Verfahren hängen vom curl-Build ab. Header prüfen [TEST][SENS] curl --compressed -I https://example.com/ Mögliche Antwort: Content-Encoding: gzip Typische Probleme Proxy entfernt Accept-Encoding ; Server sendet falschen Content-Length ; Inhalt wird doppelt komprimiert; Reverse Proxy und Anwendung komprimieren gleichzeitig; bestimmte Kompressionsverfahren werden vom curl-Build nicht unterstützt. 27. Wie werden lokale Unix-Sockets getestet? Unix-Domain-Socket-Diagnose anzeigen Auf Linux und anderen Unix-Systemen können HTTP-Dienste über einen Unix-Domain-Socket erreichbar sein. [TEST][SENS] curl --unix-socket /run/example/app.sock http://localhost/health curl verbindet sich dabei mit dem lokalen Socket. Der Hostname in der URL wird weiterhin für die HTTP-Anfrage verwendet. Typische Einsatzbereiche Docker Engine API; lokale Reverse-Proxy-Backends; PHP-FPM-nahe Testdienste; lokale Verwaltungs-APIs; systemd-aktivierte Dienste. Beispiel Docker-Socket [TEST][PRIV][SENS] curl --unix-socket /var/run/docker.sock http://localhost/_ping Zugriff auf /var/run/docker.sock entspricht auf vielen Systemen weitreichenden administrativen Rechten. Dieser Zugriff darf nicht leichtfertig vergeben oder in Container durchgereicht werden. 28. Wie werden Wiederholungsversuche verwendet? Retry-Optionen anzeigen Bis zu drei Wiederholungsversuche [TEST][SENS] curl --retry 3 https://example.com/ Maximale Gesamtzeit für Wiederholungen [TEST][SENS] curl --retry 3 --retry-max-time 30 https://example.com/ Feste Verzögerung zwischen Versuchen [TEST][SENS] curl --retry 3 --retry-delay 2 https://example.com/ Auch abgelehnte TCP-Verbindungen erneut versuchen [TEST][SENS] curl --retry 3 --retry-connrefused https://example.com/ Alle Fehler wiederholen [TEST][CHANGE][DISRUPT][SENS] curl --retry 3 --retry-all-errors https://example.com/ --retry-all-errors darf bei ändernden Anfragen nicht unüberlegt verwendet werden. Ein POST, PUT oder DELETE könnte auf dem Server bereits verarbeitet worden sein, obwohl curl die Antwort nicht erhalten hat. Dadurch könnte eine Wiederholung: eine Ressource doppelt anlegen; eine Buchung doppelt ausführen; eine Nachricht mehrfach senden; einen Löschvorgang wiederholen. Wiederholungsversuche sind bei idempotenten GET- oder HEAD-Anfragen meist leichter zu bewerten als bei ändernden API-Aufrufen. 29. Welche curl-Exitcodes sind für die Diagnose wichtig? Exitcode-Tabelle anzeigen Exitcode Bedeutung 0 Vorgang aus Sicht von curl erfolgreich 3 URL fehlerhaft 5 Proxyname konnte nicht aufgelöst werden 6 Hostname konnte nicht aufgelöst werden 7 Verbindung zum Ziel konnte nicht hergestellt werden 22 HTTP-Fehler bei Verwendung von --fail oder --fail-with-body 23 Fehler beim Schreiben empfangener Daten 26 Fehler beim Lesen lokaler Daten 28 Zeitüberschreitung 35 TLS-/SSL-Verbindungsfehler 47 Zu viele Weiterleitungen 52 Leere Serverantwort 55 Fehler beim Senden von Netzwerkdaten 56 Fehler beim Empfangen von Netzwerkdaten 60 Zertifikat konnte nicht verifiziert werden 77 Problem beim Lesen der CA-Zertifikatsdatei 92 HTTP/2-Protokollfehler Die vollständige Liste hängt von der curl-Version ab: [RO] curl --manual Exitcode unter Linux und macOS anzeigen curl -sS --fail-with-body https://example.com/health echo $? Exitcode unter PowerShell anzeigen curl.exe -sS --fail-with-body https://example.com/health $LASTEXITCODE Wichtige Unterscheidung HTTP-Statuscode ≠ curl-Exitcode Beispiel: HTTP 404 ohne --fail → curl-Exitcode kann 0 sein HTTP 404 mit --fail → curl-Exitcode 22 30. Wie werden Fehler nach Diagnoseebene eingeordnet? Fehlerkette anzeigen curl-Beobachtung Wahrscheinliche Ebene Exitcode 6 DNS-Auflösung Exitcode 7 TCP-Verbindung, Routing, Firewall oder Listener Exitcode 28 DNS, Verbindung, Server oder Übertragung zu langsam Exitcode 35 TLS-Handshake Exitcode 60 Zertifikatsvertrauen oder Hostname HTTP 301/302 Weiterleitung HTTP 401 Authentifizierung HTTP 403 Autorisierung, WAF oder Richtlinie HTTP 404 URL, Routing oder Ressource HTTP 429 Rate Limit HTTP 500 Anwendung oder Backend HTTP 502 Proxy/Gateway und Upstream HTTP 503 Dienst nicht verfügbar oder Wartungszustand HTTP 504 Gateway wartet vergeblich auf Upstream Verbindung funktioniert, Antwort langsam Anwendung, Datenbank, Upstream oder Serverlast IP funktioniert, Name nicht DNS --resolve funktioniert, normaler Aufruf nicht DNS-Zuordnung oder Load-Balancer-Ziel -k funktioniert, normaler Test nicht Zertifikatsprüfung IPv4 funktioniert, IPv6 nicht IPv6-DNS, Routing, Firewall oder MTU Direkt funktioniert, Proxy nicht Proxy, Authentifizierung oder Proxy-Richtlinie 31. Welche typischen Fehlinterpretationen gibt es? Praxisfallen anzeigen Fehlinterpretation Richtige Einordnung curl ohne Fehler bedeutet HTTP 200 Ohne --fail kann auch HTTP 404 oder 500 Exitcode 0 ergeben -I prüft exakt dasselbe wie GET -I sendet bei HTTP eine HEAD-Anfrage -k behebt TLS Es deaktiviert nur die Zertifikatsprüfung Aufruf über IP testet denselben virtuellen Host Host-Header, SNI und Zertifikatsprüfung können abweichen Eigener Host -Header setzt automatisch SNI TLS-SNI wird dadurch nicht zuverlässig angepasst --resolve verändert lokales DNS dauerhaft Gilt nur für den jeweiligen curl-Aufruf time_connect ist nur die TCP-Dauer Wert ist kumulativ seit Beginn des Aufrufs Hohe TTFB beweist Netzwerkproblem Server, Anwendung oder Backend können langsam sein HTTP 403 bedeutet falsches Passwort Authentifizierung kann korrekt sein, aber Zugriff ist verboten HTTP 502 ist immer der Webserver Häufig meldet ein Gateway ein Upstream-Problem Bearer-Token in der Kommandozeile ist sicher Token kann in Historie und Prozessinformationen erscheinen Verbose-Ausgabe kann bedenkenlos geteilt werden Header, Cookies und Tokens können enthalten sein curl verhält sich wie ein Browser JavaScript und Browserkontext fehlen Retry ist bei POST immer sicher Änderung kann bereits verarbeitet worden sein Proxyvariable ist ausgeschlossen, weil -x fehlt curl kann Proxyvariablen aus der Umgebung verwenden 32. Wie sieht ein systematischer curl-Diagnoseablauf aus? Empfohlene Schrittfolge anzeigen Vorbereitung Erwartete URL, Methode und Antwort dokumentieren. Hostname, IP-Adresse, Port und Protokoll bestimmen. Prüfen, ob Proxy, VPN oder Load Balancer beteiligt sind. Authentifizierung und Schutzbedarf der Daten klären. Ändernde Anfragen nur gegen freigegebene Testressourcen richten. Grundtest curl-Version und unterstützte Funktionen prüfen. URL mit explizitem https:// oder http:// verwenden. Verbindung mit -v untersuchen. HTTP-Statuscode und effektive URL ausgeben. Exitcode kontrollieren. Eingrenzung IPv4 mit -4 und IPv6 mit -6 vergleichen. DNS mit --resolve kontrolliert umgehen. Direktverbindung und Proxyverbindung vergleichen. Redirect-Kette mit -L -I prüfen. TLS normal und höchstens vergleichsweise mit -k testen. HTTP/1.1 und HTTP/2 bei Bedarf vergleichen. DNS-, TCP-, TLS-, TTFB- und Gesamtzeit messen. Anwendung Header und Content-Type prüfen. Erwartete HTTP-Methode verwenden. Request-Body und Zeichenkodierung kontrollieren. Authentifizierung ohne Offenlegung der Zugangsdaten testen. API-Antwort und Serverlogs zeitlich vergleichen. Validierung Ergebnis aus einem zweiten Netzwerksegment vergleichen. Reverse-Proxy-, Firewall- und Anwendungslogs prüfen. Bei Netzwerkverdacht Paketmitschnitt erstellen. Nach einer Änderung denselben curl-Befehl erneut ausführen. Befehl, Zeitpunkt, Exitcode, HTTP-Status und Zeiten dokumentieren. Diagnoseausgaben vor Weitergabe von Secrets bereinigen. 33. Kurzreferenz – häufige curl-Befehle Befehlstabelle anzeigen Aufgabe Linux/macOS Version [RO] curl --version Seite abrufen [TEST][SENS] curl https://example.com/ Nur HEAD-Anfrage [TEST][SENS] curl -I https://example.com/ Header und Inhalt [TEST][SENS] curl -i https://example.com/ Ausführliche Diagnose [TEST][SENS] curl -v https://example.com/ Redirects verfolgen [TEST][SENS] curl -L https://example.com/ Statuscode [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ HTTP-Fehler als Fehler behandeln [TEST] curl -sS --fail-with-body https://example.com/ Connect-Timeout [TEST] curl --connect-timeout 5 https://example.com/ Gesamttimeout [TEST] curl --max-time 15 https://example.com/ IPv4 [TEST] curl -4 https://example.com/ IPv6 [TEST] curl -6 https://example.com/ DNS temporär überschreiben [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ Bestimmte CA-Datei [TEST][FILE][SENS] curl --cacert company-ca.pem https://example.com/ HTTP/1.1 [TEST] curl --http1.1 https://example.com/ HTTP/2 [TEST] curl --http2 https://example.com/ JSON senden [TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"active":true}' https://api.example.com/item Datei herunterladen [TEST][FILE][SENS] curl -o file.bin https://example.com/file.bin Proxy verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/ Proxy umgehen [TEST][SENS] curl --noproxy "*" https://example.com/ Trace erstellen [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/ Windows verwendet dieselbe Optionssyntax, aber eindeutig curl.exe und NUL statt /dev/null : [TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ 34. Kurzreferenz – wichtigste Optionen Optionstabelle anzeigen Option Bedeutung -V , --version Version und Build-Funktionen anzeigen -v , --verbose Ausführliche Verbindungsinformationen -I , --head Bei HTTP HEAD-Anfrage senden -i , --show-headers Antwortheader zusammen mit Inhalt anzeigen -D , --dump-header Antwortheader separat schreiben -o , --output Antwortinhalt in Datei schreiben -O , --remote-name Remote-Dateinamen verwenden -s , --silent Fortschritts- und normale Fehlermeldungen unterdrücken -S , --show-error Fehler trotz --silent anzeigen -f , --fail HTTP-Fehler als curl-Fehler behandeln --fail-with-body HTTP-Fehler melden und Inhalt behalten -L , --location Weiterleitungen verfolgen --max-redirs Anzahl der Weiterleitungen begrenzen -w , --write-out Messwerte und Metadaten ausgeben --connect-timeout Verbindungszeit begrenzen -m , --max-time Gesamtdauer begrenzen -4 IPv4 erzwingen -6 IPv6 erzwingen --resolve Temporäre Host-/Port-/IP-Zuordnung --connect-to Tatsächliches Verbindungsziel ändern -k , --insecure Zertifikatsprüfung deaktivieren --cacert Bestimmte CA-Datei verwenden --cert Clientzertifikat verwenden --key Privaten Schlüssel verwenden --tlsv1.2 Mindestens TLS 1.2 --tls-max Maximale TLS-Version --http1.1 HTTP/1.1 verwenden --http2 HTTP/2 anfordern --http3 HTTP/3 versuchen -H , --header Request-Header setzen -A , --user-agent User-Agent setzen -d , --data Request-Daten senden --data-binary Daten weitgehend unverändert senden --data-urlencode Daten URL-codieren --json JSON-Daten senden -X , --request HTTP-Methode ausdrücklich festlegen -u , --user Serverauthentifizierung -U , --proxy-user Proxyauthentifizierung -b , --cookie Cookies senden beziehungsweise lesen -c , --cookie-jar Cookies speichern -x , --proxy Proxy verwenden --noproxy Proxy für Ziele umgehen --compressed Komprimierte Antwort anfordern --retry Wiederholungsversuche --trace-ascii Lesbaren Trace schreiben --trace-time Trace mit Zeitstempeln versehen Merksätze Unter Windows für echte curl-Syntax ausdrücklich curl.exe verwenden. Eine empfangene HTTP-Fehlerseite kann ohne --fail trotzdem curl-Exitcode 0 ergeben. HTTP-Statuscode und curl-Exitcode beantworten unterschiedliche Fragen. -I sendet bei HTTP eine HEAD-Anfrage und ist nicht identisch mit einem GET-Test. -v zeigt DNS, TCP, TLS und HTTP, kann aber sensible Header enthalten. --resolve umgeht DNS für den Test und erhält Hostname, HTTP-Host, TLS-SNI und Zertifikatsprüfung. Ein Aufruf über die reine IP-Adresse kann einen anderen virtuellen Host erreichen. -k deaktiviert die Zertifikatsprüfung und behebt kein TLS-Problem. time_connect , time_appconnect und time_starttransfer sind kumulative Zeitwerte. Eine hohe TTFB kann durch Anwendung, Datenbank, Proxy oder Backend entstehen. Bei UDP-basiertem HTTP/3 können andere Fehler als bei HTTP/1.1 oder HTTP/2 auftreten. Proxyvariablen können einen curl-Aufruf beeinflussen, auch wenn kein -x angegeben wurde. Zugangsdaten, Cookies und Tokens gehören nicht in Dokumentationen oder gemeinsam lesbare Skripte. POST-, PUT-, PATCH- und DELETE-Anfragen können Daten verändern und benötigen besondere Vorsicht. curl ist ein präzises Protokollwerkzeug, aber kein vollständiger Webbrowser. Quellen Offizielle curl-Manpage Offizielle curl-Dokumentationsübersicht Everything curl – Command Line Transfers Everything curl – Verbose Operations Everything curl – Name Resolve Tricks Everything curl – HTTP Responses Everything curl – Proxies curl – Exit Codes curl – SSL Certificate Verification curl – Supported Protocols 2.10 OpenSSL – TLS-Verbindungen, Zertifikate und Zertifikatsketten prüfen Ziel dieser Seite OpenSSL ist eine Sammlung von Werkzeugen und Bibliotheken für Kryptografie, Zertifikate und TLS. In der Fehleranalyse wird der Befehl openssl unter anderem verwendet, um: TLS-Verbindungen direkt zu einem Server aufzubauen; TLS-Version und Cipher Suite zu erkennen; Server Name Indication, kurz SNI, gezielt zu testen; Zertifikate eines Servers anzuzeigen; Zertifikatsketten zu untersuchen; Zertifikatsnamen und Subject Alternative Names zu prüfen; Gültigkeitszeiträume zu kontrollieren; interne Zertifizierungsstellen einzubeziehen; STARTTLS bei SMTP, IMAP, POP3 und LDAP zu testen; Clientzertifikate für mTLS-Verbindungen zu verwenden; Zertifikate, private Schlüssel und CSRs zu untersuchen; zu prüfen, ob Zertifikat und privater Schlüssel zusammengehören; PEM-, DER- und PKCS#12-Dateien zu unterscheiden; Fehler zwischen TCP, TLS, Zertifikat und Anwendung einzugrenzen. OpenSSL kann private Schlüssel und andere hochsensible kryptografische Daten verarbeiten. Befehle mit privaten Schlüsseln dürfen nur auf autorisierten Systemen und in geschützten Verzeichnissen ausgeführt werden. Kennzeichnungen Kennzeichnung Bedeutung [RO] Nur lesende lokale Prüfung [TEST] Aktiver Netzwerk- oder TLS-Test [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Befehl liest oder erstellt eine Datei [SENS] Ausgabe oder Datei enthält möglicherweise sensible Informationen [CHANGE] Befehl erstellt oder verändert Dateien [DISRUPT] Test kann Dienst, Sitzung oder produktive Daten beeinflussen 1. Wie wird die OpenSSL-Version geprüft? Versions- und Buildinformationen anzeigen Aufgabe Windows Linux macOS Programmpfad [RO] Get-Command openssl.exe [RO] command -v openssl [RO] command -v openssl Version [RO] openssl.exe version [RO] openssl version [RO] openssl version Ausführliche Version [RO] openssl.exe version -a [RO] openssl version -a [RO] openssl version -a Befehlsübersicht [RO] openssl.exe help [RO] openssl help [RO] openssl help Hilfe zu s_client [RO] openssl.exe s_client -help [RO] openssl s_client -help [RO] openssl s_client -help Ausführliche Buildinformationen [RO] openssl version -a Die Ausgabe kann unter anderem enthalten: OpenSSL- oder LibreSSL-Version; Erstellungsdatum; Zielplattform; Konfigurationsverzeichnis; Provider- und Modulpfade; Compileroptionen; CPU-Funktionen. Betriebssystemspezifische Hinweise Betriebssystem Hinweis Windows OpenSSL ist kein allgemeines Windows-Bordmittel und muss aus einer vertrauenswürdigen Quelle stammen oder mit einer Anwendung mitgeliefert werden Linux Version und Konfiguration hängen von Distribution und Paketstand ab macOS Der Befehl openssl kann je nach Installation LibreSSL oder eine separat installierte OpenSSL-Version aufrufen Container Der Container kann eine andere OpenSSL-Version als der Host verwenden OpenSSL und LibreSSL sind nicht vollständig optionskompatibel. Vor der Übernahme eines Befehls muss deshalb geprüft werden: openssl version openssl s_client -help 2. Wie wird eine grundlegende TLS-Verbindung getestet? Verbindung mit `s_client` anzeigen [TEST][SENS] openssl s_client -connect example.com:443 Der Befehl baut eine TCP-Verbindung zu Port 443 auf und startet anschließend einen TLS-Handshake. Mit ausdrücklich gesetztem SNI [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -servername setzt die TLS-Erweiterung Server Name Indication. Kompakte Ausgabe, sofern von der installierten Version unterstützt [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief Verbindung beenden Nach dem TLS-Handshake wartet s_client häufig auf weitere Eingaben. Die Sitzung kann normalerweise mit folgender Tastenkombination beendet werden: [Strg] + [C] Neuere OpenSSL-Versionen unterstützen einen nicht interaktiven Modus: [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -no-interactive Vor Verwendung muss geprüft werden: [RO] openssl s_client -help Wichtige Ausgabeinformationen Ziel-IP und Zielport; Serverzertifikat; Zertifikatskette; TLS-Version; Cipher Suite; Schlüsselaustausch; Signaturalgorithmus; ALPN-Ergebnis; Zertifikatsprüfergebnis; Sitzungsinformationen. 3. Warum muss SNI ausdrücklich berücksichtigt werden? SNI und virtuelle Hosts erklären Mehrere HTTPS-Dienste können dieselbe IP-Adresse und denselben Port verwenden: 192.0.2.20:443 ├── wiki.example.com ├── mail.example.com └── api.example.com Der Client teilt dem Server während des TLS-Handshakes mit, welchen Hostnamen er erreichen möchte. Das geschieht über SNI. Wiki prüfen [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com API prüfen [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername api.example.com Der Server kann abhängig vom SNI-Namen unterschiedliche Zertifikate zurückgeben. Ohne SNI [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -noservername Mögliche Folgen: Standardzertifikat des Reverse Proxys; Zertifikat eines anderen virtuellen Hosts; TLS-Abbruch; falsche Anwendung; irreführender Zertifikatsnamensfehler. Ein Test gegen eine IP-Adresse ohne passenden SNI-Namen bildet den Zugriff eines normalen Browsers auf einen DNS-Namen nicht zuverlässig nach. 4. Wie wird ein TLS-Server über eine bestimmte IP-Adresse getestet? Ziel-IP und Hostname getrennt prüfen Angenommen: Hostname: wiki.example.com Test-IP: 192.0.2.20 Port: 443 Direkter TLS-Test gegen diese IP mit richtigem SNI [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com Dadurch wird: die DNS-Auflösung für die Verbindung umgangen; die Verbindung direkt zu 192.0.2.20 aufgebaut; SNI auf wiki.example.com gesetzt. Für eine vollständige Hostnamenprüfung sollte zusätzlich verwendet werden: [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error Vergleich mit curl [TEST][SENS] curl --resolve wiki.example.com:443:192.0.2.20 https://wiki.example.com/ OpenSSL untersucht hauptsächlich TLS und Zertifikate. curl führt zusätzlich eine HTTP-Anfrage aus. 5. Was bedeutet eine erfolgreiche TLS-Verbindung? Handshake, Zertifikat und Anwendung unterscheiden Ein erfolgreicher TLS-Handshake beweist zunächst: TCP-Verbindung wurde hergestellt; Client und Server fanden eine gemeinsame TLS-Version; Client und Server fanden geeignete kryptografische Parameter; der Server konnte ein Zertifikat oder anderes benötigtes Material bereitstellen; verschlüsselte Kommunikation konnte grundsätzlich beginnen. Er beweist nicht automatisch: dass der Zertifikatsname richtig ist; dass die Zertifikatskette vertrauenswürdig ist; dass das Zertifikat nicht abgelaufen ist; dass die Anwendung funktioniert; dass HTTP einen erfolgreichen Statuscode liefert; dass eine Benutzeranmeldung möglich ist; dass eine Sperrprüfung erfolgreich war. Diagnoseebenen DNS ↓ TCP ↓ TLS-Handshake ↓ Zertifikatsprüfung ↓ HTTP oder anderes Anwendungsprotokoll ↓ Anwendung Für HTTPS sollte nach dem OpenSSL-Test zusätzlich eine HTTP-Prüfung erfolgen: [TEST][SENS] curl -v https://wiki.example.com/ 6. Warum kann s_client trotz Zertifikatsfehler eine Verbindung fortsetzen? Wichtige Besonderheit der Zertifikatsprüfung anzeigen openssl s_client ist ein Diagnosewerkzeug. Standardmäßig kann es nach Zertifikatsprüffehlern fortfahren, damit weitere Probleme sichtbar werden. Eine Ausgabe wie: verify error:num=20:unable to get local issuer certificate bedeutet deshalb nicht zwingend, dass der TLS-Handshake sofort abgebrochen wird. Bei Zertifikatsfehlern wirklich abbrechen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_return_error Zusätzlich Hostnamen prüfen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error Erwartetes positives Ergebnis Verification: OK oder in der ausführlichen Ausgabe: Verify return code: 0 (ok) Wichtig TLS-Handshake abgeschlossen ≠ Zertifikat erfolgreich validiert Für eine belastbare Prüfung müssen mindestens berücksichtigt werden: -verify_return_error ; der erwartete Hostname; der richtige Vertrauensspeicher; die vollständige Zertifikatskette. 7. Wie wird der Zertifikatsname geprüft? Hostname und IP-Adresse validieren DNS-Hostname prüfen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error Verbindung gegen IP, aber DNS-Namen prüfen [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error IP-Adresse als Zertifikatsidentität prüfen [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -verify_ip 192.0.2.20 -verify_return_error Ein Zertifikat muss die IP-Adresse dafür als IP-Eintrag im Subject Alternative Name enthalten. Ein DNS-Name oder ein Common Name mit einer IP-ähnlichen Zeichenfolge ist dafür nicht automatisch ausreichend. Zu unterscheiden Option Aufgabe -connect Tatsächliches Netzwerkziel -servername Im TLS-Handshake gesendeter SNI-Name -verify_hostname Erwartete DNS-Identität im Zertifikat -verify_ip Erwartete IP-Identität im Zertifikat Diese Werte können bei gezielten Tests unterschiedlich sein. 8. Wie wird die vom Server gesendete Zertifikatsliste angezeigt? Zertifikate mit `-showcerts` anzeigen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts -showcerts zeigt die Zertifikate so an, wie der Server sie übermittelt hat. Typische Reihenfolge: 1. Server-/Leaf-Zertifikat 2. Zwischenzertifikat 3. weiteres Zwischenzertifikat Ein Root-Zertifikat wird von einem TLS-Server normalerweise nicht mitgesendet, weil es bereits im Vertrauensspeicher des Clients vorhanden sein soll. Wichtiger Hinweis Die Ausgabe von -showcerts ist: die vom Server gesendete Zertifikatsliste; nicht automatisch eine erfolgreich validierte Kette; nicht zwingend vollständig; nicht zwingend in einer brauchbaren Vertrauenskette angeordnet; kein Beweis, dass alle Zertifikate vertrauenswürdig sind. Typischer Fehler Server sendet nur Leaf-Zertifikat → Client kann Aussteller möglicherweise nicht finden → unable to get local issuer certificate 9. Wie wird ein Serverzertifikat in eine Datei übernommen? Leaf-Zertifikat extrahieren Unter Linux und macOS kann das erste vom Server ausgegebene Zertifikat an openssl x509 weitergegeben werden: [TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -outform PEM > server-cert.pem Anschließend prüfen: [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -dates Wichtig Diese Pipeline übernimmt normalerweise das erste PEM-Zertifikat aus der Ausgabe und damit üblicherweise das Leaf-Zertifikat. Sie speichert nicht automatisch die vollständige Zertifikatskette. Für die vollständige Kette sollte die Ausgabe von -showcerts kontrolliert und jedes Zertifikat eindeutig getrennt gespeichert werden. Unter Windows Shell-Pipelines und Umleitungen unterscheiden sich zwischen: PowerShell; Eingabeaufforderung; Git Bash; WSL. Daher sollte unter Windows zunächst die Ausgabe kontrolliert in eine Datei geschrieben und das gewünschte PEM-Zertifikat anschließend eindeutig extrahiert werden. Binärdaten und private Schlüssel dürfen nicht unkontrolliert durch Textkonvertierungen einer Shell verändert werden. 10. Wie wird ein lokales Zertifikat vollständig angezeigt? Zertifikatsinhalt mit `openssl x509` anzeigen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text Kompakte Kerninformationen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates SHA-256-Fingerabdruck [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 Public-Key-Information [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -pubkey Wichtige Zertifikatsfelder Feld Bedeutung Subject Identität des Zertifikatsinhabers Issuer Ausstellende Zertifizierungsstelle Serial Number Seriennummer des Zertifikats Not Before Beginn der Gültigkeit Not After Ende der Gültigkeit Public Key Algorithm Typ des öffentlichen Schlüssels Signature Algorithm Signaturalgorithmus der CA Subject Alternative Name Gültige DNS-Namen, IP-Adressen oder andere Identitäten Key Usage Zulässige grundlegende Schlüsselverwendungen Extended Key Usage Beispielsweise TLS Web Server Authentication Basic Constraints Kennzeichnung als Endzertifikat oder CA-Zertifikat Authority Information Access Hinweise auf Aussteller und OCSP CRL Distribution Points Verweise auf Sperrlisten 11. Wie werden Subject Alternative Names angezeigt? SAN-Felder prüfen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName Beispiel: X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:api.example.com Weitere Erweiterungen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext keyUsage [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext extendedKeyUsage [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext basicConstraints [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext authorityInfoAccess Wichtig Moderne TLS-Clients prüfen die Identität hauptsächlich anhand von Subject Alternative Name. Der Common Name allein sollte nicht als verlässlicher Ersatz für fehlende SAN-Einträge betrachtet werden. 12. Wie wird die Gültigkeitsdauer eines Zertifikats geprüft? Start-, Ablaufdatum und Restlaufzeit anzeigen Gültigkeitszeitraum anzeigen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -dates Ausgabe: notBefore=... notAfter=... Nur Ablaufdatum [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -enddate Prüfen, ob das Zertifikat mindestens noch 30 Tage gültig ist [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000 Berechnung: 30 Tage × 24 Stunden × 60 Minuten × 60 Sekunden = 2.592.000 Sekunden Exitcode auswerten Linux und macOS: openssl x509 -in server-cert.pem -noout -checkend 2592000 echo $? PowerShell: openssl.exe x509 -in server-cert.pem -noout -checkend 2592000 $LASTEXITCODE Exitcode Bedeutung 0 Zertifikat ist über den angegebenen Zeitraum hinaus gültig ungleich 0 Zertifikat läuft innerhalb des Zeitraums ab oder ist bereits abgelaufen Zusätzlich muss die lokale Systemzeit korrekt sein. Eine falsche Uhr kann gültige Zertifikate als noch nicht gültig oder abgelaufen erscheinen lassen. 13. Wie wird eine Zertifikatskette lokal geprüft? Kettenprüfung mit `openssl verify` anzeigen Angenommene Dateien: server-cert.pem intermediate-ca.pem root-ca.pem Kette prüfen [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem Erwartetes Ergebnis: server-cert.pem: OK Zusätzlich Hostnamen prüfen [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem Für TLS-Serverzweck prüfen [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -purpose sslserver server-cert.pem Bedeutung Option Aufgabe -CAfile root-ca.pem Vertrauensanker -untrusted intermediate-ca.pem Nicht direkt vertrautes Zwischenzertifikat zur Kettenbildung -verify_hostname Erwarteten DNS-Namen prüfen -purpose sslserver Eignung für TLS-Server prüfen Das Zwischenzertifikat wird mit -untrusted zur Kettenbildung bereitgestellt. Dadurch wird es nicht automatisch selbst zum Vertrauensanker. 14. Welche typischen Fehler der Zertifikatskette gibt es? Verify-Fehler einordnen Fehlermeldung Mögliche Bedeutung unable to get local issuer certificate Aussteller oder Zwischenzertifikat fehlt beziehungsweise ist nicht auffindbar unable to verify the first certificate Kette kann vom Leaf-Zertifikat nicht zu einem vertrauten Root aufgebaut werden self-signed certificate Zertifikat ist selbstsigniert und nicht als vertrauenswürdig hinterlegt self-signed certificate in certificate chain Selbstsigniertes Zertifikat in der Kette ist nicht als Vertrauensanker akzeptiert certificate has expired Zertifikat liegt nach notAfter certificate is not yet valid Systemzeit liegt vor notBefore hostname mismatch Erwarteter Name passt nicht zum Zertifikat invalid CA certificate Zertifikat ist nicht korrekt als CA verwendbar path length constraint exceeded CA-Pfadlängenbegrenzung verletzt unsupported certificate purpose Zertifikat ist nicht für den geprüften Zweck vorgesehen certificate signature failure Signatur konnte nicht korrekt bestätigt werden Prüfreihenfolge Leaf-Zertifikat untersuchen. Issuer des Leaf-Zertifikats bestimmen. Passendes Zwischenzertifikat prüfen. Issuer und Subject der Kettenglieder vergleichen. CA-Eigenschaften kontrollieren. Vertrauensanker eindeutig festlegen. Gültigkeitszeiten aller Zertifikate prüfen. Hostnamen und Verwendungszweck prüfen. 15. Wie wird eine interne Zertifizierungsstelle verwendet? Eigene CA für einen einzelnen Test angeben TLS-Verbindung mit eigener CA-Datei prüfen [TEST][FILE][SENS] openssl s_client -connect wiki.example.com:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error -CAfile company-root-ca.pem Lokales Zertifikat prüfen [RO][FILE][SENS] openssl verify -CAfile company-root-ca.pem -untrusted company-intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem Wichtig Die Angabe von -CAfile gilt für diesen OpenSSL-Aufruf. Sie installiert die CA nicht automatisch in: Windows-Zertifikatspeicher; macOS-Schlüsselbund; Linux-Systemvertrauensspeicher; Browser-Vertrauensspeicher; Java-KeyStore; Container-Images. Ein erfolgreicher OpenSSL-Test mit eigener CA-Datei beweist deshalb nicht, dass alle Anwendungen dieser CA vertrauen. 16. Wie werden TLS 1.2 und TLS 1.3 getrennt getestet? Protokollversionen anzeigen Ausschließlich TLS 1.2 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 Ausschließlich TLS 1.3 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 Minimalversion festlegen, sofern unterstützt [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -min_protocol TLSv1.2 Maximalversion festlegen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -max_protocol TLSv1.2 Interpretation TLS 1.2 TLS 1.3 Mögliche Aussage Erfolgreich Erfolgreich Beide Versionen werden unterstützt Erfolgreich Fehler Server, Proxy oder Client unterstützt TLS 1.3 nicht oder blockiert es Fehler Erfolgreich Server erlaubt möglicherweise nur TLS 1.3 Beide Fehler TCP, SNI, Zertifikat, Cipher oder Dienst prüfen Ein Versionsfehler kann auch durch einen zwischengeschalteten Proxy, Load Balancer oder TLS-Inspection-Dienst verursacht werden. 17. Wie werden Cipher Suites geprüft? Cipher-Informationen anzeigen Verfügbare Cipher Suites des lokalen OpenSSL-Builds [RO] openssl ciphers -v Nur TLS-1.2-kompatible Auswahl untersuchen [RO] openssl ciphers -v -tls1_2 Nur TLS-1.3-Cipher-Suites anzeigen, sofern unterstützt [RO] openssl ciphers -v -tls1_3 Bestimmte TLS-1.2-Cipher-Auswahl testen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' Bestimmte TLS-1.3-Cipher-Suite testen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 -ciphersuites 'TLS_AES_128_GCM_SHA256' Wichtiger Unterschied Option Gilt hauptsächlich für -cipher TLS 1.2 und älter -ciphersuites TLS 1.3 Die tatsächlich verfügbaren Cipher Suites hängen von: OpenSSL-Version; aktivierten Providern; Sicherheitsstufe; Betriebssystempaket; Build-Konfiguration; kryptografischer Richtlinie ab. Eine einzelne funktionierende Cipher Suite beweist nicht, dass die gesamte TLS-Konfiguration sicher oder vollständig kompatibel ist. 18. Wie wird ALPN für HTTP/2 und HTTP/1.1 geprüft? ALPN-Aushandlung anzeigen HTTP/2 und HTTP/1.1 anbieten [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1' Mögliche Ausgabe: ALPN protocol: h2 oder: ALPN protocol: http/1.1 Nur HTTP/2 anbieten [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn h2 Interpretation Ergebnis Bedeutung h2 Server und Client einigten sich auf HTTP/2 http/1.1 HTTP/1.1 wurde gewählt Keine ALPN-Aushandlung Server, Proxy oder OpenSSL-Build unterstützt beziehungsweise verwendet ALPN nicht TLS-Abbruch Protokoll-, Cipher-, SNI- oder Richtlinienproblem möglich ALPN bestimmt das Anwendungsprotokoll innerhalb der TLS-Verbindung. OpenSSL s_client führt danach nicht automatisch eine vollständige HTTP/2-Anfrage aus. Für den Anwendungstest: [TEST][SENS] curl --http2 -v https://example.com/ 19. Wie wird OCSP Stapling geprüft? OCSP-Statusantwort anzeigen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status Die Option fordert während des TLS-Handshakes eine gestapelte OCSP-Antwort an. Mögliche Ausgabe: OCSP response: ... Cert Status: good Mögliche Ergebnisse Beobachtung Einordnung Gültige Antwort mit good Server lieferte eine auswertbare OCSP-Statusantwort revoked Zertifikat wird als gesperrt gemeldet unknown OCSP-Responder kennt den Status nicht eindeutig OCSP response: no response sent Server lieferte kein OCSP Stapling Fehlerhafte Antwort OCSP-Antwort, Signatur oder Aktualität prüfen Kein OCSP Stapling bedeutet nicht automatisch, dass das Zertifikat gesperrt oder die TLS-Verbindung ungültig ist. Ob Stapling erforderlich ist, hängt von Zertifikat, Anwendung und Richtlinie ab. 20. Wie wird STARTTLS bei Maildiensten geprüft? SMTP, IMAP und POP3 anzeigen Bei STARTTLS beginnt die Verbindung unverschlüsselt und wird anschließend innerhalb des Anwendungsprotokolls auf TLS umgestellt. SMTP auf Port 25 [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com SMTP Submission auf Port 587 [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com IMAP mit STARTTLS [TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com POP3 mit STARTTLS [TEST][SENS] openssl s_client -starttls pop3 -connect mail.example.com:110 -servername mail.example.com LMTP mit STARTTLS, sofern unterstützt [TEST][SENS] openssl s_client -starttls lmtp -connect mail.example.com:24 -servername mail.example.com Direktes TLS ohne STARTTLS Dienst Typischer Port Aufruf SMTPS 465 openssl s_client -connect mail.example.com:465 -servername mail.example.com IMAPS 993 openssl s_client -connect mail.example.com:993 -servername mail.example.com POP3S 995 openssl s_client -connect mail.example.com:995 -servername mail.example.com STARTTLS und direktes TLS dürfen nicht verwechselt werden. 21. Wie wird STARTTLS bei LDAP und Datenbanken geprüft? LDAP-, PostgreSQL- und MySQL-Beispiele anzeigen LDAP mit STARTTLS [TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com LDAPS mit direktem TLS [TEST][SENS] openssl s_client -connect ldap.example.com:636 -servername ldap.example.com PostgreSQL mit TLS-Aushandlung [TEST][SENS] openssl s_client -starttls postgres -connect db.example.com:5432 -servername db.example.com MySQL mit TLS-Aushandlung, sofern von der installierten OpenSSL-Version unterstützt [TEST][SENS] openssl s_client -starttls mysql -connect db.example.com:3306 -servername db.example.com Nicht jede OpenSSL- oder LibreSSL-Version unterstützt alle -starttls -Protokolle. Verfügbarkeit prüfen: [RO] openssl s_client -help Ein erfolgreicher TLS-Handshake beweist nicht, dass anschließend eine Datenbank- oder LDAP-Anmeldung erfolgreich ist. 22. Wie wird eine Verbindung über einen HTTP-Proxy getestet? HTTP-CONNECT-Proxy anzeigen [TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com OpenSSL sendet dabei eine HTTP-CONNECT-Anfrage an den Proxy und baut durch den Tunnel die TLS-Verbindung zum Zielserver auf. Proxybenutzer angeben [TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -proxy_user max.mustermann -proxy_pass stdin -connect example.com:443 -servername example.com Das Passwort wird über die angegebene Passwortquelle eingelesen. Wichtiger Sicherheitshinweis Die von s_client unterstützte Proxy-Basisauthentifizierung überträgt die Zugangsdaten vor dem TLS-Tunnel in leicht rückwandelbarer Base64-Form an den Proxy. Sie ist nur in entsprechend geschützten und autorisierten Umgebungen zu verwenden. Direkt- und Proxytest vergleichen Direkt: [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com Über Proxy: [TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com Unterschiedliche Zertifikate können auf TLS-Inspection oder unterschiedliche Netzwerkpfade hinweisen. 23. Wie wird eine mTLS-Verbindung mit Clientzertifikat geprüft? Clientzertifikat und privaten Schlüssel verwenden Clientzertifikat und Schlüssel getrennt [TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem Zusätzlich Serverzertifikat und Hostname verifizieren [TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -CAfile company-root-ca.pem -verify_hostname api.example.com -verify_return_error Clientzertifikatskette angeben [TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -cert_chain client-chain.pem -build_chain Die Optionen -cert_chain und -build_chain sind versionsabhängig. Mögliche Fehler Clientzertifikat fehlt; privater Schlüssel passt nicht zum Zertifikat; Clientzertifikat abgelaufen; Extended Key Usage erlaubt keine Clientauthentifizierung; ausstellende Client-CA wird vom Server nicht vertraut; Zwischenzertifikat fehlt; falsches Dateiformat; verschlüsselter Schlüssel kann nicht geöffnet werden. Private Schlüssel dürfen niemals in Tickets, BookStack-Seiten, Chatnachrichten oder Diagnoseausgaben eingefügt werden. 24. Wie wird ein privater Schlüssel geprüft, ohne ihn auszugeben? Schlüsselstruktur sicher prüfen Allgemeinen privaten Schlüssel prüfen [RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout Bei einem verschlüsselten Schlüssel wird normalerweise eine Passphrase abgefragt. Nur öffentliche Schlüsselkomponente ausgeben [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout Schlüsselinformation ohne private Bestandteile [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -text_pub -noout Nicht unkontrolliert verwenden openssl pkey -in server-key.pem -text Dieser Befehl kann private Schlüsselbestandteile ausgeben. Solche Ausgaben dürfen nicht in Logs, Terminalsitzungsaufzeichnungen oder Tickets gelangen. Dateiberechtigungen prüfen Linux: [RO][FILE][SENS] stat server-key.pem macOS: [RO][FILE][SENS] stat -x server-key.pem Windows: [RO][FILE][SENS] Get-Acl .\server-key.pem 25. Wie wird geprüft, ob Zertifikat und privater Schlüssel zusammengehören? Öffentliche Schlüssel vergleichen Die zuverlässige allgemeine Methode besteht darin, aus beiden Dateien den öffentlichen Schlüssel zu gewinnen und dessen DER-Darstellung zu hashen. Hash des öffentlichen Schlüssels aus dem Zertifikat [RO][FILE][SENS] openssl x509 -in server-cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 Hash des öffentlichen Schlüssels aus dem privaten Schlüssel [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256 Wenn beide SHA-256-Werte identisch sind, besitzen Zertifikat und privater Schlüssel denselben öffentlichen Schlüssel. Beispiel SHA2-256(stdin)= abcdef... SHA2-256(stdin)= abcdef... Warum nicht nur den RSA-Modulus vergleichen? Der klassische Modulusvergleich funktioniert nur für bestimmte Schlüsselarten wie RSA. Der Vergleich des normalisierten öffentlichen Schlüssels funktioniert auch für andere von OpenSSL unterstützte Schlüsseltypen, beispielsweise EC-Schlüssel. 26. Wie wird eine Certificate Signing Request geprüft? CSR-Inhalt und Signatur anzeigen Gesamten CSR-Inhalt anzeigen [RO][FILE][SENS] openssl req -in request.csr -noout -text Subject anzeigen [RO][FILE][SENS] openssl req -in request.csr -noout -subject CSR-Signatur prüfen [RO][FILE][SENS] openssl req -in request.csr -noout -verify Öffentlichen Schlüssel des CSR ausgeben [RO][FILE][SENS] openssl req -in request.csr -noout -pubkey Zu prüfen Subject; gewünschte DNS-Namen; Subject Alternative Names; Schlüsseltyp; Schlüssellänge beziehungsweise Kurve; Signaturalgorithmus; erfolgreiche CSR-Signaturprüfung. Ein CSR ist noch kein Zertifikat. Er enthält: Identitätsantrag; öffentlichen Schlüssel; angeforderte Erweiterungen; Signatur des zugehörigen privaten Schlüssels. Er enthält nicht den privaten Schlüssel. 27. Wie wird geprüft, ob CSR und privater Schlüssel zusammengehören? CSR-Schlüsselvergleich anzeigen Öffentlichen Schlüssel aus dem CSR hashen [RO][FILE][SENS] openssl req -in request.csr -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 Öffentlichen Schlüssel aus dem privaten Schlüssel hashen [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256 Sind beide Werte identisch, gehört der private Schlüssel zum CSR. Nach Ausstellung zusätzlich vergleichen CSR ↔ privater Schlüssel Zertifikat ↔ privater Schlüssel Dadurch wird geprüft, ob die Zertifizierungsstelle tatsächlich das Zertifikat für den vorgesehenen Schlüssel ausgestellt hat. 28. Wie werden PEM- und DER-Zertifikate unterschieden und konvertiert? Zertifikatsformate anzeigen PEM PEM ist textbasiert und enthält Markierungen wie: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- DER DER ist ein binäres ASN.1-Format und besitzt keine lesbaren BEGIN-/END-Markierungen. PEM-Zertifikat anzeigen [RO][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -noout -text DER-Zertifikat anzeigen [RO][FILE][SENS] openssl x509 -in certificate.der -inform DER -noout -text DER nach PEM konvertieren [CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM PEM nach DER konvertieren [CHANGE][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -out certificate.der -outform DER Die Dateiendung allein beweist das Format nicht. Dateien mit .cer oder .crt können PEM oder DER enthalten. 29. Wie wird eine PKCS#12-Datei untersucht? PFX/P12-Inhalt sicher prüfen PKCS#12-Dateien verwenden häufig die Endungen: .p12 .pfx Sie können enthalten: Zertifikat; Zwischenzertifikate; Root-Zertifikate; privaten Schlüssel; Metadaten. Inhalt anzeigen, aber keine privaten Schlüssel ausgeben [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout Nur Zertifikate anzeigen, keine privaten Schlüssel [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -nokeys Nur das Client- beziehungsweise Leaf-Zertifikat extrahieren [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out client-cert.pem CA-Zertifikate extrahieren [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -cacerts -nokeys -out ca-chain.pem Privaten Schlüssel extrahieren [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -nocerts -out client-key-encrypted.pem Dieser Vorgang erzeugt eine Datei mit privatem Schlüssel und ist besonders sensibel. Die Ausgabedatei sollte verschlüsselt und mit streng beschränkten Dateirechten gespeichert werden. Unverschlüsselten privaten Schlüssel exportieren Optionen wie -nodes beziehungsweise das neuere -noenc können unverschlüsselte private Schlüssel erzeugen. Das sollte nur in begründeten Ausnahmefällen, mit dokumentierter Freigabe und geeigneten Dateirechten erfolgen. 30. Wie werden Zertifikatsfingerabdrücke verglichen? SHA-256-Fingerprints anzeigen Zertifikatsfingerabdruck [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 Hash der gesamten Datei [RO][FILE][SENS] openssl dgst -sha256 server-cert.pem Diese beiden Werte sind nicht dasselbe: Prüfung Gehashte Daten openssl x509 -fingerprint -sha256 DER-codiertes Zertifikat openssl dgst -sha256 server-cert.pem Tatsächliche Datei einschließlich PEM-Darstellung Zwei PEM-Dateien können dasselbe Zertifikat enthalten, aber wegen unterschiedlicher Zeilenenden oder Formatierung unterschiedliche Dateihashes besitzen. Der Zertifikatsfingerabdruck bleibt dagegen identisch. Betriebssystemspezifischer Dateihash Windows: [RO][FILE][SENS] Get-FileHash .\server-cert.pem -Algorithm SHA256 Linux: [RO][FILE][SENS] sha256sum server-cert.pem macOS: [RO][FILE][SENS] shasum -a 256 server-cert.pem 31. Wie werden detaillierte TLS-Zustände und Nachrichten untersucht? Erweiterte Diagnoseoptionen anzeigen TLS-Zustandswechsel anzeigen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -state TLS-Protokollnachrichten anzeigen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -msg Umfangreicher Trace, sofern unterstützt [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -trace TLS-Erweiterungen anzeigen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tlsextdebug Wichtiger Hinweis -debug , -msg und -trace können sehr umfangreiche Hexadezimal- und Protokollausgaben erzeugen. Sie sollten erst verwendet werden, wenn: der normale s_client -Test nicht ausreicht; der Fehler reproduzierbar ist; die Ausgabe geschützt gespeichert wird; keine geheimen Anwendungsdaten eingegeben werden. 32. Wie werden IPv4 und IPv6 getrennt getestet? IPv4-/IPv6-TLS-Vergleich anzeigen IPv4 erzwingen [TEST][SENS] openssl s_client -4 -connect example.com:443 -servername example.com IPv6 erzwingen [TEST][SENS] openssl s_client -6 -connect example.com:443 -servername example.com Direkte IPv6-Adresse [TEST][SENS] openssl s_client -connect '[2001:db8::20]:443' -servername example.com Bei einer IPv6-Adresse in host:port -Schreibweise muss die Adresse in eckige Klammern gesetzt werden. Interpretation IPv4 IPv6 Mögliche Ursache Erfolgreich Fehler IPv6-DNS, Routing, Firewall, MTU oder Zielkonfiguration Fehler Erfolgreich IPv4-Routing, NAT, Firewall oder Zielkonfiguration Unterschiedliches Zertifikat Unterschiedlicher Load Balancer oder Server Unterschiedliche TLS-Version Unterschiedliche Proxy- oder Serverkonfiguration 33. Wie wird ein TLS-Fehler systematisch eingegrenzt? Diagnosekette anzeigen 1. DNS prüfen Windows: [RO] Resolve-DnsName example.com Linux: [RO] dig example.com macOS: [RO] dig example.com 2. TCP-Port prüfen Windows: [TEST] Test-NetConnection example.com -Port 443 Linux und macOS: [TEST] nc -vz example.com 443 3. TLS mit SNI prüfen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com 4. Zertifikatsprüfung erzwingen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error 5. Zertifikatsliste anzeigen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts 6. TLS-Versionen getrennt prüfen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 7. Anwendung prüfen [TEST][SENS] curl -v https://example.com/ 8. Logs vergleichen Reverse Proxy; Webserver; Load Balancer; Firewall; Anwendung; Zertifikatsverwaltung; Systemzeit. 34. Wie werden typische OpenSSL-Fehler eingeordnet? Fehlertabelle anzeigen Fehler oder Beobachtung Mögliche Ursache Connection refused Ziel erreichbar, aber kein Listener am Port Connection timed out Firewall, Routing, Rückweg oder Ziel nicht erreichbar no peer certificate available TLS-Handshake brach vor Zertifikatsübertragung ab wrong version number Falsches Protokoll am Port, beispielsweise direktes TLS gegen einen Klartextport unknown protocol Ziel spricht kein erwartetes TLS-Protokoll handshake failure Keine gemeinsamen Parameter, Richtlinie, Clientzertifikat oder Serverkonfiguration no shared cipher Keine gemeinsame Cipher Suite unsupported protocol TLS-Version nicht unterstützt oder deaktiviert certificate verify failed Vertrauenskette, Zeit, Zweck oder Name fehlerhaft unable to get local issuer certificate Zwischenzertifikat oder Aussteller fehlt self-signed certificate Nicht vertrautes selbstsigniertes Zertifikat certificate has expired Zertifikat abgelaufen certificate is not yet valid Systemzeit falsch oder Gültigkeit noch nicht begonnen hostname mismatch Zertifikat gilt nicht für erwarteten Namen bad certificate Gegenstelle lehnt Zertifikat ab certificate required Server verlangt ein Clientzertifikat tlsv1 alert protocol version Gegenstelle akzeptiert angebotene TLS-Version nicht unexpected eof while reading Gegenstelle oder Zwischenkomponente beendet Verbindung ohne regulären TLS-Abschluss Falsches Zertifikat SNI fehlt, falscher Load Balancer oder falsches Ziel Verify return code: 0 (ok) trotz falscher Anwendung TLS-Zertifikat okay, Anwendungsproblem bleibt möglich 35. Welche Fehlinterpretationen müssen vermieden werden? Praxisfallen anzeigen Fehlinterpretation Richtige Einordnung TLS-Handshake erfolgreich bedeutet Zertifikat gültig s_client kann nach Verify-Fehlern fortfahren CONNECTED bedeutet TLS vollständig erfolgreich Es bestätigt zunächst die hergestellte Transportverbindung -showcerts zeigt eine validierte Kette Es zeigt nur die vom Server gesendeten Zertifikate Root-Zertifikat fehlt in Serverausgabe Root-CA wird normalerweise nicht mitgesendet Common Name reicht immer aus Moderne Clients prüfen hauptsächlich SAN Test über IP entspricht Test über DNS-Namen SNI und Hostnamenprüfung können abweichen -servername prüft automatisch den Zertifikatsnamen SNI und Hostnamenvalidierung sind getrennte Funktionen -verify_hostname setzt automatisch das Netzwerkziel Das Netzwerkziel wird durch -connect bestimmt Selbstsigniert bedeutet automatisch unsicher Es bedeutet zunächst, dass kein externer Vertrauenspfad vorliegt Verify return code: 0 beweist funktionierende Website Nur die geprüfte TLS-/Zertifikatsebene ist erfolgreich Gleiches Subject bedeutet gleiches Zertifikat Seriennummer, Public Key und Fingerprint können verschieden sein Gleicher Dateihash ist der einzige Zertifikatsvergleich PEM-Formatierung kann Dateihash verändern PKCS#12 ist nur ein Zertifikat Datei kann zusätzlich private Schlüssel und Ketten enthalten Private Schlüssel können zur Diagnose angezeigt werden Private Schlüssel dürfen nicht offengelegt werden -tls1_2 bedeutet mindestens TLS 1.2 Bei s_client erzwingt die Option den Test mit TLS 1.2 Fehlendes OCSP Stapling bedeutet gesperrt Server hat lediglich keine Stapling-Antwort geliefert 36. Wie sieht ein sicherer OpenSSL-Diagnoseablauf aus? Empfohlene Schrittfolge anzeigen Vorbereitung Erwarteten Hostnamen, Ziel-IP und Port dokumentieren. Klären, ob direktes TLS oder STARTTLS verwendet wird. OpenSSL- beziehungsweise LibreSSL-Version prüfen. Erwartete Zertifizierungsstelle und Zertifikatsnamen ermitteln. Systemzeit und Zeitzone kontrollieren. Private Schlüssel und Passwortquellen schützen. Verbindung DNS-Auflösung prüfen. TCP-Port prüfen. TLS-Verbindung mit richtigem SNI aufbauen. Tatsächlich ausgehandelte TLS-Version und Cipher Suite dokumentieren. ALPN bei HTTP-Diensten prüfen. Zertifikat Zertifikatsprüffehlermeldungen beachten. Prüfung mit -verify_return_error erzwingen. Hostnamen mit -verify_hostname prüfen. Serverzertifikate mit -showcerts anzeigen. Leaf- und Zwischenzertifikate getrennt untersuchen. SAN, Issuer, Subject und Gültigkeit prüfen. Kette mit openssl verify lokal nachvollziehen. Vertiefung TLS 1.2 und TLS 1.3 getrennt testen. IPv4 und IPv6 vergleichen. Direkt- und Proxyverbindung vergleichen. Bei mTLS Clientzertifikat und Schlüsselzuordnung prüfen. Bei STARTTLS das richtige Anwendungsprotokoll angeben. Nur bei Bedarf -state , -msg oder -trace verwenden. Validierung HTTPS zusätzlich mit curl prüfen. Server-, Proxy- und Firewall-Logs vergleichen. Bei Netzwerkverdacht Paketmitschnitt erstellen. Nach einer Änderung exakt denselben Test wiederholen. Diagnoseausgaben vor Weitergabe auf sensible Daten prüfen. Temporär extrahierte Schlüssel- oder Zertifikatsdateien sicher behandeln. 37. Kurzreferenz – häufige OpenSSL-Befehle Befehlstabelle anzeigen Aufgabe Befehl Version [RO] openssl version -a TLS-Verbindung [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com Kompakte Ausgabe [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief Hostname prüfen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error Zertifikatsliste [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts Eigene CA [TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com -CAfile root-ca.pem -verify_return_error TLS 1.2 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 TLS 1.3 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 ALPN [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1' OCSP Stapling [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status SMTP STARTTLS [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com IMAP STARTTLS [TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com LDAP STARTTLS [TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com Zertifikat anzeigen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text Kerndaten [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates SAN anzeigen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName SHA-256-Fingerprint [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 30 Tage Restlaufzeit [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000 Kette prüfen [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem Privaten Schlüssel prüfen [RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout CSR prüfen [RO][FILE][SENS] openssl req -in request.csr -noout -text -verify PKCS#12 untersuchen [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout DER nach PEM [CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM 38. Kurzreferenz – wichtige s_client -Optionen Optionstabelle anzeigen Option Bedeutung -connect host:port Netzwerkziel festlegen -servername name TLS-SNI setzen -noservername Kein SNI senden -verify_hostname name DNS-Namen des Zertifikats prüfen -verify_ip adresse IP-Identität des Zertifikats prüfen -verify_return_error Bei Zertifikatsprüffehlern abbrechen -CAfile datei Vertrauenswürdige CA-Datei verwenden -showcerts Vom Server gesendete Zertifikate anzeigen -brief Kompakte Verbindungsübersicht -no-interactive Nicht interaktiver Modus, sofern unterstützt -4 IPv4 erzwingen -6 IPv6 erzwingen -tls1_2 TLS 1.2 erzwingen -tls1_3 TLS 1.3 erzwingen -min_protocol Minimale Protokollversion -max_protocol Maximale Protokollversion -cipher Cipher-Auswahl für TLS 1.2 und älter -ciphersuites Cipher-Suites für TLS 1.3 -alpn ALPN-Protokolle anbieten -status OCSP-Stapling-Antwort anfordern -starttls STARTTLS für ein Anwendungsprotokoll -proxy HTTP-CONNECT-Proxy verwenden -cert Clientzertifikat angeben -key Privaten Clientschlüssel angeben -cert_chain Clientzertifikatskette angeben -state TLS-Zustände anzeigen -msg TLS-Protokollnachrichten anzeigen -trace Ausführlichen TLS-Trace anzeigen -tlsextdebug TLS-Erweiterungen anzeigen Merksätze OpenSSL- und LibreSSL-Version sowie lokale Optionen müssen zuerst geprüft werden. -connect bestimmt das Netzwerkziel, -servername das SNI und -verify_hostname den zu prüfenden Zertifikatsnamen. Ein abgeschlossener TLS-Handshake beweist nicht automatisch eine erfolgreiche Zertifikatsprüfung. s_client kann ohne -verify_return_error nach Zertifikatsfehlern fortfahren. Verify return code: 0 (ok) ist wesentlich aussagekräftiger als nur CONNECTED . -showcerts zeigt die vom Server gesendeten Zertifikate, aber keine automatisch validierte Kette. Das Root-Zertifikat wird normalerweise nicht vom TLS-Server mitgesendet. Moderne Clients prüfen DNS-Namen hauptsächlich anhand des Subject Alternative Name. STARTTLS und direktes TLS verwenden unterschiedliche Verbindungsabläufe. -tls1_2 und -tls1_3 erzwingen jeweils eine bestimmte TLS-Version. TLS-1.2-Cipher werden mit -cipher , TLS-1.3-Cipher-Suites mit -ciphersuites gewählt. Eine interne CA mit -CAfile gilt nur für den jeweiligen OpenSSL-Aufruf. Zertifikat, CSR und privater Schlüssel können über ihre öffentlichen Schlüssel sicher miteinander verglichen werden. Private Schlüssel dürfen niemals in BookStack, Tickets, Chats oder Diagnoseprotokollen veröffentlicht werden. Eine erfolgreiche TLS-Prüfung ersetzt nicht den anschließenden Anwendungstest mit curl oder einem protokollspezifischen Client. Quellen Offizielle OpenSSL-Dokumentation OpenSSL s_client OpenSSL x509 OpenSSL verify OpenSSL pkey OpenSSL req OpenSSL pkcs12 OpenSSL ciphers OpenSSL version OpenSSL Verification Options OpenSSL Passphrase Options 2.11 Microsoft Sysinternals – Windows-Prozesse und Systemaktivitäten analysieren Microsoft Sysinternals ist eine Sammlung spezialisierter Werkzeuge zur Diagnose von Windows-Systemen. Die Programme ermöglichen wesentlich tiefere Einblicke als der Task-Manager oder die üblichen Windows-Bordmittel. Mit Sysinternals lassen sich unter anderem folgende Fragen beantworten: Welcher Prozess verursacht eine hohe CPU- oder Arbeitsspeicherauslastung? Welcher Prozess hält eine Datei oder einen Ordner geöffnet? Welche DLLs wurden von einem Prozess geladen? Welche Datei-, Registry- und Prozesszugriffe führt eine Anwendung aus? Welches Programm stellt eine bestimmte Netzwerkverbindung her? Welche Programme, Dienste und Aufgaben werden automatisch gestartet? Ist eine ausführbare Datei digital signiert? Warum startet eine Anwendung nicht? Warum dauert die Anmeldung ungewöhnlich lange? Welcher Prozess verursacht einen Speicher- oder Handle-Anstieg? Wie kann für eine abgestürzte oder nicht reagierende Anwendung ein Speicherabbild erstellt werden? Wichtig: Sysinternals liefert technische Beobachtungen, aber nicht automatisch die Ursache einer Störung. Ein einzelner ungewöhnlicher Eintrag ist noch kein Beweis für einen Fehler oder Schadsoftware. Entscheidend sind Zusammenhang, zeitlicher Ablauf, Vergleichswerte und reproduzierbares Verhalten. 1. Kennzeichnungen und Sicherheitsregeln Kennzeichnung Bedeutung [RO] Read-only: liest Informationen aus, ohne den Zustand absichtlich zu verändern [TEST] Führt einen aktiven Test aus oder erzeugt zusätzliche Systemlast [PRIV] Benötigt möglicherweise Administratorrechte [FILE] Erzeugt oder verändert eine Datei [SENS] Ergebnis kann vertrauliche Daten enthalten [CHANGE] Verändert Einstellungen oder einen Systemzustand [DISRUPT] Kann Programme, Verbindungen oder Dienste unterbrechen Bei der Arbeit mit Sysinternals gelten folgende Grundregeln: Werkzeuge ausschließlich von Microsoft beziehungsweise über die offizielle Sysinternals-Seite beziehen. Vor einer Analyse Zeitpunkt, betroffenen Computer, angemeldeten Benutzer und Fehlerbild dokumentieren. Zuerst nur beobachten und Daten erfassen. Prozesse, Handles, Verbindungen oder Autostarteinträge nicht vorschnell beenden beziehungsweise löschen. Administratorrechte nur verwenden, wenn sie für die Untersuchung erforderlich sind. Speicherabbilder, Process-Monitor-Aufzeichnungen und exportierte Listen als vertrauliche Daten behandeln. VirusTotal-Abfragen nur unter Beachtung der betrieblichen Datenschutz- und Sicherheitsvorgaben verwenden. Änderungen immer mit Rückweg, Sicherung und dokumentiertem Ausgangszustand durchführen. 2. Sysinternals sicher beziehen und starten Die Werkzeuge können einzeln oder als vollständige Sysinternals Suite heruntergeladen werden. Offizielle Bezugsquellen: Sysinternals-Übersicht: https://learn.microsoft.com/sysinternals/ Sysinternals Suite: https://learn.microsoft.com/sysinternals/downloads/sysinternals-suite Sysinternals Live: https://live.sysinternals.com/ Die Suite eignet sich besonders für einen zentral gepflegten administrativen Werkzeugbestand. Beispiel für eine lokale Ablage C:\Admin\Sysinternals\ Start über Sysinternals Live \\live.sysinternals.com\tools\procexp.exe \\live.sysinternals.com\tools\procmon.exe Das direkte Starten über Sysinternals Live kann durch Firewall-, Proxy-, WebDAV-, SMB- oder Sicherheitsrichtlinien verhindert werden. Für reproduzierbare Analysen ist eine lokal bereitgestellte und betrieblich freigegebene Version häufig sinnvoller. Grundlegende Prüfung einer heruntergeladenen Datei [RO] Get-AuthenticodeSignature "C:\Admin\Sysinternals\procexp.exe" [RO] Get-FileHash "C:\Admin\Sysinternals\procexp.exe" -Algorithm SHA256 Die Signatur sollte gültig sein und zu Microsoft gehören. Ein Hashwert dient zur eindeutigen Dokumentation einer untersuchten Version, beweist allein aber nicht deren Vertrauenswürdigkeit. Wichtiger Hinweis zur Lizenzvereinbarung Viele Sysinternals-Kommandozeilenwerkzeuge unterstützen: -accepteula Damit wird die Lizenzvereinbarung ohne interaktive Rückfrage akzeptiert. Diese Option sollte nur eingesetzt werden, wenn die Lizenzvereinbarung organisatorisch geprüft und akzeptiert wurde. 3. Welches Sysinternals-Werkzeug eignet sich für welches Problem? Problem oder Fragestellung Geeignetes Werkzeug Typische Untersuchung Hohe CPU-Auslastung Process Explorer, PsList, ProcDump Verursachenden Prozess und Threads bestimmen Ungewöhnlich hoher Speicherverbrauch Process Explorer, RAMMap, VMMap Speicherverteilung und Prozesswachstum untersuchen Datei oder Ordner ist gesperrt Process Explorer, Handle Prozess mit geöffnetem Handle ermitteln Anwendung startet nicht Process Monitor, Autoruns, Sigcheck Fehlende Dateien, Berechtigungsfehler und Abhängigkeiten suchen Anwendung stürzt ab ProcDump, Process Monitor Speicherabbild und Aktivitäten vor dem Absturz erfassen Anwendung reagiert nicht Process Explorer, ProcDump Threads untersuchen und Hang-Dump erzeugen Unbekannte Netzwerkverbindung TCPView, Process Explorer Verbindung einem Prozess zuordnen Langsame Windows-Anmeldung Autoruns, Process Monitor Anmeldeobjekte, Dienste und Dateizugriffe untersuchen Verdächtiger Autostart Autoruns, Sigcheck Herausgeber, Signatur, Pfad und Startmechanismus prüfen Unbekannte ausführbare Datei Sigcheck, Process Explorer Signatur, Hash, Pfad und laufenden Prozess untersuchen DLL-Konflikt Process Explorer, ListDLLs, Process Monitor Geladene DLL-Versionen und Suchpfade vergleichen Handle-Leak Process Explorer, Handle Entwicklung der Handle-Anzahl beobachten Speicherverteilung des Systems RAMMap Standby-Liste, Dateicache und physische Speichernutzung analysieren Speicherbelegung eines Prozesses VMMap Private, gemeinsam genutzte und zugeordnete Bereiche untersuchen Dauerhafte Ereigniserfassung Sysmon Sicherheitsrelevante Systemereignisse protokollieren Fernadministration PsTools Autorisierte Prozess-, Dienst- und Systemabfragen durchführen 4. Process Explorer – Prozesse genauer untersuchen Process Explorer ist eine erweiterte Prozessanzeige. Das Werkzeug stellt Prozesse hierarchisch dar und zeigt unter anderem: übergeordnete und untergeordnete Prozesse, Prozess-ID und Benutzerkonto, CPU- und Arbeitsspeicherauslastung, gestarteten Programmpfad, Kommandozeile, digitale Signatur, geladene DLLs, geöffnete Handles, Threads und deren CPU-Auslastung, Netzwerk- und Datenträgeraktivitäten. Sinnvoller Diagnoseablauf Process Explorer möglichst zunächst ohne Administratorrechte starten. Prozessbaum und auffällige Prozesse identifizieren. Bei unvollständiger Sichtbarkeit kontrolliert als Administrator neu starten. Eigenschaften des betroffenen Prozesses öffnen. Pfad, Kommandozeile, Benutzerkonto und übergeordneten Prozess prüfen. CPU-, Speicher-, Datenträger- und Netzwerkentwicklung beobachten. Digitale Signatur kontrollieren. Bei hoher CPU-Auslastung die einzelnen Threads untersuchen. Beobachtungen mit Zeitpunkt und Prozess-ID dokumentieren. Wichtige Bewertungsfragen Eigenschaft Fragestellung Image Path Liegt die Datei im erwarteten Programmverzeichnis? Command Line Mit welchen Parametern wurde der Prozess gestartet? Parent Process Welcher Prozess hat ihn gestartet? User Name Unter welchem Benutzer- oder Dienstkonto läuft er? Verified Signer Ist die Signatur gültig und passt der Herausgeber? Start Time Begann das Problem mit dem Prozessstart? Threads Welcher Thread erzeugt die Auslastung? Handles Steigt die Anzahl dauerhaft an? TCP/IP Baut der Prozess unerwartete Verbindungen auf? Datei oder DLL suchen Über die Suchfunktion von Process Explorer kann nach einem Teil des Datei-, Ordner-, Registry- oder DLL-Namens gesucht werden. Dadurch lässt sich beispielsweise ermitteln, welcher Prozess eine Datei geöffnet hält. Find → Find Handle or DLL Wichtige Grenzen Ein unbekannter Prozess ist nicht automatisch schädlich. Eine fehlende digitale Signatur ist kein Malware-Beweis. Eine gültige Signatur beweist nicht, dass ein Programm harmlos ist. Das Beenden eines Prozesses kann Datenverlust und Dienstausfälle verursachen. Systemprozesse dürfen nicht ohne vorherige Identifikation beendet werden. Unterschiedliche Prozesse können denselben Dateinamen verwenden. Eingreifende Funktionen Aktion Risiko Prozess beenden [CHANGE][DISRUPT] Ungespeicherte Daten können verloren gehen Prozessbaum beenden [CHANGE][DISRUPT] Beendet zusätzlich untergeordnete Prozesse Prozess anhalten [CHANGE][DISRUPT] Anwendung oder abhängige Dienste können blockieren Handle schließen [CHANGE][DISRUPT] Anwendung kann abstürzen oder Daten beschädigen Priorität ändern [CHANGE] Kann Leistungsverhalten und Stabilität beeinflussen Diese Funktionen gehören nicht zur ersten Diagnosephase. 5. Process Monitor – Datei-, Registry- und Prozesszugriffe verfolgen Process Monitor, kurz Procmon, zeichnet in Echtzeit folgende Aktivitäten auf: Dateisystemzugriffe, Registry-Zugriffe, Prozess- und Thread-Ereignisse, Laden von Abbildern und DLLs, Zugriffsresultate, Prozess-ID, Benutzer und Aufrufpfad, auf Wunsch zugehörige Aufrufstapel. Process Monitor eignet sich besonders, wenn eine Anwendung: nicht startet, eine Datei nicht findet, keine Konfiguration speichern kann, einen Berechtigungsfehler meldet, eine falsche DLL lädt, auf einen nicht erreichbaren Pfad zugreift, beim Start ungewöhnlich lange wartet. Empfohlener Aufnahmeablauf Fehlerbild und genaue Uhrzeit notieren. Process Monitor starten. Laufende Aufzeichnung zunächst anhalten. Bereits angezeigte Ereignisse leeren. Filter auf den betroffenen Prozess setzen. Aufzeichnung starten. Fehler genau einmal reproduzieren. Aufzeichnung sofort wieder anhalten. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. Originalaufzeichnung im PML-Format sichern. Sensible Daten und Aufbewahrungsregeln beachten. Nützliche Standard-Tastenkombinationen Funktion Tastenkombination Aufzeichnung starten oder anhalten Strg+E bisher angezeigte Ereignisse löschen Strg+X Filterdialog öffnen Strg+L Ereignis suchen Strg+F Aufnahme speichern Strg+S Beispiel für einen Prozessfilter Process Name is beispiel.exe Include Weitere nützliche Filter: Process ID is 4321 Include Result is ACCESS DENIED Include Path contains \Config\ Include Operation is CreateFile Include Mehrere Include -Filter derselben Eigenschaft wirken typischerweise wie eine ODER-Verknüpfung. Unterschiedliche Eigenschaften grenzen das Ergebnis weiter ein. Der Filter sollte deshalb bewusst aufgebaut und im Filterdialog kontrolliert werden. Häufige Resultate richtig interpretieren Resultat Grundbedeutung Bewertung SUCCESS Operation war erfolgreich Kein Fehler für diese einzelne Operation NAME NOT FOUND Name oder Objekt wurde nicht gefunden Kann normaler Suchlauf oder tatsächliche Ursache sein PATH NOT FOUND Ein Bestandteil des Pfades fehlt Pfad, Laufwerk, Freigabe oder Konfiguration prüfen ACCESS DENIED Zugriff wurde verweigert Berechtigungen, Integritätsstufe und Sicherheitssoftware prüfen SHARING VIOLATION Objekt ist inkompatibel geöffnet Öffnenden Prozess und Freigabemodus untersuchen BUFFER OVERFLOW bereitgestellter Puffer war zunächst zu klein Häufig Bestandteil einer normalen Größenabfrage REPARSE Zugriff wurde über einen Reparse Point umgeleitet Junction, symbolischen Link oder Cloud-Platzhalter prüfen END OF FILE Dateiende wurde erreicht Kann bei normalen Lesevorgängen auftreten NAME NOT FOUND und BUFFER OVERFLOW treten bei normalen Windows-Abläufen sehr häufig auf. Entscheidend ist, ob danach ein erfolgreicher Alternativzugriff erfolgt oder die Anwendung unmittelbar anschließend scheitert. PML-Dateien Eine gespeicherte PML-Datei kann enthalten: Benutzernamen, Dateipfade, Registry-Pfade, Server- und Freigabenamen, Prozessnamen und Kommandozeilen, Anwendungs- und Dokumentnamen, Hinweise auf interne Infrastruktur. Daher gilt: [SENS][FILE] PML-Dateien nur geschützt speichern und kontrolliert weitergeben. 6. Autoruns – Autostarts und Anmeldeverzögerungen untersuchen Autoruns zeigt zahlreiche Stellen, über die Programme, Dienste, Treiber und Erweiterungen automatisch gestartet werden können. Dazu gehören unter anderem: Benutzeranmeldung, Dienste, Treiber, geplante Aufgaben, Explorer-Erweiterungen, Winlogon-Komponenten, Browser-Erweiterungen, WMI-basierte Autostarts, Winsock- und Netzwerkkomponenten, Druckmonitor-DLLs, bekannte DLLs und Image-Hijacks. Sicherer Diagnoseablauf Autoruns starten und vollständiges Einlesen abwarten. Betroffenen Benutzer und Systemkontext beachten. Eintrag, Pfad, Herausgeber und digitale Signatur prüfen. Vor Veränderungen einen Export oder Screenshot erstellen. Microsoft-Einträge nur ausblenden, um Fremdsoftware übersichtlicher zu prüfen. Bei einem begründeten Verdacht einen Eintrag zunächst deaktivieren. System oder Anmeldung kontrolliert testen. Ergebnis dokumentieren. Eintrag wieder aktivieren, wenn keine Verbesserung eingetreten ist. Das Entfernen des Häkchens deaktiviert einen Eintrag und ist grundsätzlich leichter rückgängig zu machen als das Löschen. [CHANGE] Deaktivieren: Eintrag abwählen [CHANGE][DISRUPT] Löschen: Eintrag dauerhaft entfernen Autostarteinträge sollten während der Fehleranalyse nicht vorschnell gelöscht werden. Autorunsc – Kommandozeilenversion Alle Kategorien anzeigen: [RO][PRIV] autorunsc.exe -a * -s Alle Kategorien mit Signaturprüfung und CSV-Ausgabe erfassen: [RO][PRIV][FILE] autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv Microsoft-Einträge ausblenden: [RO][PRIV] autorunsc.exe -a * -m -s Geplante Aufgaben anzeigen: [RO][PRIV] autorunsc.exe -a t -s Dienste und nicht deaktivierte Treiber anzeigen: [RO][PRIV] autorunsc.exe -a s -s Anmeldeeinträge anzeigen: [RO] autorunsc.exe -a l -s WMI-Autostarts anzeigen: [RO][PRIV] autorunsc.exe -a m -s Wichtige Kategorien Option Kategorie -a * Alle Kategorien -a b Boot-Execute-Einträge -a d AppInit-DLLs -a e Explorer-Erweiterungen -a h Image Hijacks -a i Internet-Explorer-Erweiterungen -a k Known DLLs -a l Anmeldeeinträge -a m WMI-Einträge -a n Winsock- und Netzwerkprovider -a p Druckmonitor-DLLs -a r LSA-Sicherheitsprovider -a s Dienste und nicht deaktivierte Treiber -a t Geplante Aufgaben -a w Winlogon-Einträge VirusTotal-Hinweis Die Autoruns- und Autorunsc-Integration kann Hashwerte an VirusTotal übermitteln. Abhängig von den gewählten Optionen können unbekannte Dateien auch hochgeladen werden. [SENS] Keine VirusTotal-Abfrage ohne betriebliche Freigabe durchführen. Insbesondere darf eine Upload-Funktion nicht für vertrauliche, proprietäre oder personenbezogene Dateien verwendet werden. Eine VirusTotal-Erkennung ist außerdem nur ein Hinweis und kein abschließender Malware-Beweis. 7. TCPView und Tcpvcon – Netzwerkverbindungen Prozessen zuordnen TCPView zeigt TCP- und UDP-Endpunkte einschließlich: lokalem Endpunkt, entferntem Endpunkt, Verbindungsstatus, Prozessname, Prozess-ID, zugehörigem Dienst. Damit lässt sich beispielsweise feststellen, welches Programm eine Verbindung zu einer bestimmten IP-Adresse aufgebaut hat oder welcher Prozess auf einem lokalen Port lauscht. Typischer Untersuchungsablauf TCPView starten. Nach Prozess, Port oder Zieladresse suchen. Namensauflösung bei Bedarf deaktivieren, damit nur tatsächliche IP-Adressen erscheinen. Prozess-ID und Programmpfad mit Process Explorer abgleichen. Zieladresse, Port, Prozesskontext und Verbindungszeitpunkt dokumentieren. Erst danach bewerten, ob die Verbindung erwartet ist. Tcpvcon – Kommandozeilenversion Aktive TCP-Verbindungen anzeigen: [RO] tcpvcon.exe Alle TCP- und UDP-Endpunkte anzeigen: [RO] tcpvcon.exe -a Namensauflösung deaktivieren: [RO] tcpvcon.exe -a -n CSV-Ausgabe erzeugen: [RO][FILE] tcpvcon.exe -a -n -c > C:\Temp\tcp-endpoints.csv Bestimmten Prozess untersuchen: [RO] tcpvcon.exe -a -n beispiel.exe Bestimmte PID untersuchen: [RO] tcpvcon.exe -a -n 4321 Option Bedeutung -a Alle Endpunkte anzeigen -c CSV-Ausgabe erzeugen -n Adressen nicht in Namen auflösen Prozessname oder PID Ausgabe auf einen Prozess begrenzen TCPView kann eine bestehende TCP-Verbindung schließen: [CHANGE][DISRUPT] Close Connection Dadurch wird nur die konkrete Verbindung unterbrochen. Der Prozess kann anschließend erneut eine Verbindung herstellen. Diese Funktion ersetzt weder eine Firewall-Regel noch das Beenden oder Konfigurieren des verursachenden Programms. 8. Handle – Dateisperren und offene Objekte ermitteln Handle zeigt geöffnete Handles eines Prozesses an. Damit kann insbesondere festgestellt werden, welches Programm eine Datei oder einen Ordner geöffnet hält. Handle benötigt laut Microsoft Administratorrechte. Nach einem Teil eines Dateinamens suchen: [RO][PRIV] handle.exe bericht.xlsx Nach einem Pfadbestandteil suchen: [RO][PRIV] handle.exe C:\Daten\Projekt Handles eines bestimmten Prozesses anzeigen: [RO][PRIV] handle.exe -p explorer Handles einer bestimmten PID anzeigen: [RO][PRIV] handle.exe -p 4321 Besitzenden Benutzer anzeigen: [RO][PRIV] handle.exe -u bericht.xlsx Anzahl der verschiedenen Handle-Typen anzeigen: [RO][PRIV] handle.exe -s Alle Arten von Handles anzeigen: [RO][PRIV] handle.exe -a -p 4321 Beispielausgabe sinngemäß interpretieren beispiel.exe pid: 4321 7C: File C:\Daten\Projekt\bericht.xlsx Feld Bedeutung beispiel.exe Prozessname 4321 Prozess-ID 7C Handle-Wert in hexadezimaler Schreibweise File Objekttyp Pfad geöffnetes Objekt Handle kann ein einzelnes Handle zwangsweise schließen: [CHANGE][DISRUPT][PRIV] handle.exe -c 7C -p 4321 Das erzwungene Schließen eines Handles kann Anwendungen zum Absturz bringen, Daten beschädigen oder das System destabilisieren. Diese Funktion ist kein regulärer erster Lösungsweg. Besser ist es, das verantwortliche Programm geordnet zu schließen oder den zugehörigen Dienst kontrolliert zu beenden. Die Option -y unterdrückt die Sicherheitsabfrage beim Schließen und sollte bei einer manuellen Fehleranalyse nicht eingesetzt werden. 9. Sigcheck – Signaturen, Versionen und Hashwerte prüfen Sigcheck zeigt unter anderem: Dateiversion, Zeitstempel, digitale Signatur, Zertifikatskette, Hashwerte, optional den VirusTotal-Status. Erweiterte Dateiinformationen anzeigen: [RO] sigcheck.exe -nobanner -a "C:\Programme\Beispiel\beispiel.exe" Hashwerte anzeigen: [RO] sigcheck.exe -nobanner -h "C:\Programme\Beispiel\beispiel.exe" Signatur und Zertifikatskette anzeigen: [RO] sigcheck.exe -nobanner -i "C:\Programme\Beispiel\beispiel.exe" Kombinierte Prüfung: [RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe" Nicht signierte ausführbare Dateien in System32 suchen: [RO][PRIV] sigcheck.exe -nobanner -u -e C:\Windows\System32 Unterordner rekursiv untersuchen: [RO][PRIV] sigcheck.exe -nobanner -u -e -s C:\Windows\System32 Option Bedeutung -a Erweiterte Versionsinformationen anzeigen -e Nur ausführbare Images untersuchen -h Hashwerte anzeigen -i Zertifikatskette und Katalog anzeigen -s Unterverzeichnisse rekursiv durchsuchen -u Ohne VirusTotal nur nicht signierte Dateien anzeigen -c CSV-Ausgabe -ct Tabulatorgetrennte Ausgabe -nobanner Startbanner ausblenden -accepteula Lizenzvereinbarung ohne Dialog akzeptieren Bewertung einer Signatur Ergebnis Aussage Gültige Signatur Datei wurde signiert und seit der Signierung nicht entsprechend verändert Ungültige Signatur Signaturprüfung ist fehlgeschlagen Keine Signatur Datei besitzt keine auswertbare digitale Signatur Bekannter Herausgeber Herausgeber ergibt sich aus dem Zertifikat Unbekannter Herausgeber Vertrauenskette oder Signatur fehlt beziehungsweise ist nicht vertrauenswürdig Eine gültige Signatur bedeutet nicht automatisch, dass die Datei sicher oder erwünscht ist. Eine nicht signierte Datei ist umgekehrt nicht automatisch Schadsoftware. VirusTotal-Optionen -v fragt den VirusTotal-Status anhand des Dateihashs ab. -vs kann Dateien, die VirusTotal noch nicht kennt, zur Analyse hochladen. [SENS] `-vs` niemals ohne ausdrückliche Datenschutz- und Sicherheitsfreigabe verwenden. 10. PsList und weitere PsTools – Prozesse und Dienste per Kommandozeile prüfen Die PsTools enthalten verschiedene Kommandozeilenwerkzeuge für lokale und entfernte Windows-Systeme. Werkzeug Aufgabe Risiko PsList Prozessinformationen anzeigen [RO] PsService Dienste abfragen und verwalten Abfrage [RO] , Änderungen [CHANGE][DISRUPT] PsLoggedOn angemeldete Benutzer anzeigen [RO][SENS] PsInfo Systeminformationen anzeigen [RO] PsKill Prozesse beenden [CHANGE][DISRUPT] PsExec Prozesse lokal oder remote starten [PRIV][CHANGE][DISRUPT] PsShutdown Computer herunterfahren oder neu starten [PRIV][CHANGE][DISRUPT] Lokale Prozesse anzeigen: [RO] pslist.exe Prozessbaum anzeigen: [RO] pslist.exe -t Detaillierte Speicherinformationen anzeigen: [RO] pslist.exe -m Bestimmte PID untersuchen: [RO] pslist.exe 4321 Entfernten Computer abfragen: [RO][PRIV] pslist.exe \\PC-023 Remote-Abfragen dürfen ausschließlich auf autorisierten Systemen erfolgen. Windows-Firewall, administrative Freigaben, Namensauflösung, Dienststeuerung und Berechtigungen können den Zugriff beeinflussen. Umgang mit Zugangsdaten PsTools können bei manchen Werkzeugen Benutzername und Kennwort als Parameter entgegennehmen. Kennwörter sollten nicht direkt in Befehlszeilen eingetragen werden, da sie beispielsweise in: Befehlsverläufen, Prozesslisten, Skripten, Protokollen, Bildschirmaufzeichnungen sichtbar werden können. Wenn möglich, sollte ein bereits autorisierter administrativer Kontext oder eine betrieblich freigegebene Lösung zur privilegierten Administration verwendet werden. Besonders eingreifende Werkzeuge [CHANGE][DISRUPT] pskill.exe 4321 beendet einen Prozess. [PRIV][CHANGE][DISRUPT] psexec.exe \\PC-023 Programm.exe startet einen Prozess auf einem entfernten Computer. Diese Befehle sind keine reinen Diagnosebefehle. Vor ihrer Verwendung müssen Zielsystem, Prozess, Auswirkung, Berechtigung und Rückweg eindeutig geklärt sein. 11. ProcDump – Speicherabbilder bei Abstürzen, Hängern und Lastspitzen erstellen ProcDump kann Speicherabbilder eines Prozesses manuell oder beim Eintreten bestimmter Bedingungen erzeugen. Typische Auslöser sind: hohe CPU-Auslastung, nicht reagierendes Programmfenster, unbehandelte Ausnahme, Prozessende, bestimmter Speicherverbrauch, bestimmter Leistungsindikator. Vollständiges Speicherabbild einer PID erzeugen [TEST][PRIV][FILE][SENS] procdump.exe -ma 4321 C:\Dumps Speicherabbild bei nicht reagierendem Fenster [TEST][PRIV][FILE][SENS] procdump.exe -ma -h beispiel.exe C:\Dumps Bis zu drei Speicherabbilder bei erhöhter CPU-Auslastung [TEST][PRIV][FILE][SENS] procdump.exe -ma -n 3 -s 5 -c 80 beispiel.exe C:\Dumps Der Befehl reagiert, wenn der Prozess die angegebene CPU-Schwelle für die festgelegte Anzahl aufeinanderfolgender Sekunden überschreitet. Speicherabbild bei einer unbehandelten Ausnahme [TEST][PRIV][FILE][SENS] procdump.exe -ma -e beispiel.exe C:\Dumps Auf einen noch nicht gestarteten Prozess warten [TEST][PRIV][FILE][SENS] procdump.exe -ma -e -w beispiel.exe C:\Dumps Option Bedeutung -ma vollständiges Speicherabbild -mm Mini-Dump; Standard -n 3 maximal drei Abbilder erzeugen -s 5 Bedingung muss fünf Sekunden bestehen -c 80 CPU-Schwelle von 80 Prozent -h bei einem nicht reagierenden Fenster auslösen -e bei unbehandelter Ausnahme auslösen -e 1 zusätzlich bei First-Chance-Ausnahmen auslösen -w auf den Start des Prozesses warten -t beim Beenden des Prozesses auslösen -o vorhandene Zieldatei überschreiben Warum Speicherabbilder besonders geschützt werden müssen Ein Speicherabbild kann unter anderem enthalten: Kennwörter oder Kennwortfragmente, Sitzungstoken, personenbezogene Daten, Inhalte geöffneter Dokumente, kryptografische Schlüssel, Verbindungszeichenfolgen, interne Servernamen, Anwendungsdaten. [SENS][FILE] Speicherabbilder verschlüsselt ablegen, Zugriff begrenzen und nach der Analyse kontrolliert löschen. Vollständige Abbilder können groß sein und während der Erstellung zusätzliche CPU-, Arbeitsspeicher- und Datenträgerlast verursachen. Auf produktiven Systemen sind Speicherplatz und mögliche Unterbrechungen vorab zu prüfen. ProcDump kann außerdem als systemweiter Postmortem-Debugger registriert werden. Da dies die Systemkonfiguration verändert, gehört eine solche Registrierung nicht in die normale spontane Diagnose: [PRIV][CHANGE] procdump.exe -ma -i C:\Dumps Rücknahme: [PRIV][CHANGE] procdump.exe -u 12. RAMMap und VMMap – Arbeitsspeicher genauer analysieren RAMMap RAMMap untersucht die Verwendung des physischen Arbeitsspeichers des gesamten Windows-Systems. Wichtige Ansichten: Ansicht Aussage Use Counts Speichernutzung nach Verwendungsart Processes physische Speichernutzung nach Prozess Priority Summary Speicher nach Priorität Physical Pages einzelne physische Speicherseiten Physical Ranges physische Speicherbereiche File Summary im RAM befindliche Dateidaten File Details einzelne Dateien und Speicherseiten RAMMap hilft bei Fragen wie: Warum wird sehr viel physischer Speicher verwendet? Wie groß ist der Dateicache? Welche Dateien befinden sich in der Standby-Liste? Wie viel Speicher wird durch Treiber oder Kernelstrukturen verwendet? Entspricht der hohe Speicherverbrauch tatsächlich einem einzelnen Prozess? VMMap VMMap untersucht den virtuellen und physischen Speicher eines einzelnen Prozesses. VMMap zeigt unter anderem: privaten Speicher, gemeinsam genutzten Speicher, Images und DLLs, zugeordnete Dateien, Heap-Bereiche, Thread-Stacks, reservierte und zugesicherte Speicherbereiche. VMMap ist besonders nützlich, wenn der Speicherverbrauch eines bestimmten Prozesses über längere Zeit zunimmt. Beobachtung statt Momentaufnahme Bei einem vermuteten Speicherproblem sollten mehrere Messpunkte dokumentiert werden: Zeitpunkt Private Bytes Working Set Commit Handles Threads Start … … … … … nach 15 Minuten … … … … … nach Reproduktion … … … … … nach 60 Minuten … … … … … Ein hoher Wert allein beweist kein Speicherleck. Entscheidend ist, ob die Nutzung unter vergleichbaren Bedingungen dauerhaft wächst und nicht wieder freigegeben wird. RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Systemzustand und können Messergebnisse verfälschen: [CHANGE][DISRUPT] „Empty“-Funktionen nicht während der ursprünglichen Beweissicherung verwenden. 13. ListDLLs – geladene DLLs eines Prozesses anzeigen ListDLLs zeigt die von Prozessen geladenen DLLs an. Das Werkzeug kann helfen, wenn: eine falsche DLL-Version vermutet wird, eine Anwendung eine DLL aus einem unerwarteten Verzeichnis lädt, 32-Bit- und 64-Bit-Komponenten verwechselt werden, mehrere Versionen einer Bibliothek vorhanden sind, ein Programm nach einem Update nicht mehr startet. DLLs eines bestimmten Prozesses anzeigen: [RO] listdlls.exe beispiel.exe DLLs einer bestimmten PID anzeigen: [RO] listdlls.exe 4321 Nach Prozessen suchen, die eine bestimmte DLL geladen haben: [RO] listdlls.exe beispiel.dll Versionsinformationen anzeigen: [RO] listdlls.exe -v beispiel.exe Nicht signierte DLLs hervorheben beziehungsweise anzeigen: [RO] listdlls.exe -u beispiel.exe Bei der Bewertung sind mindestens folgende Punkte zu prüfen: vollständiger DLL-Pfad, Dateiversion, Produktversion, Architektur, digitaler Herausgeber, Änderungszeitpunkt, Übereinstimmung mit einer funktionierenden Referenzinstallation. Eine DLL mit ungewöhnlichem Pfad ist ein Prüfhinweis, aber noch kein Beweis für Manipulation. 14. Sysmon – dauerhafte sicherheitsrelevante Ereigniserfassung Sysmon installiert einen Windows-Systemdienst und einen Treiber. Anschließend protokolliert es abhängig von der Konfiguration detaillierte Systemereignisse, beispielsweise: Prozessstarts, Netzwerkverbindungen, Dateiänderungen, Treiber- und DLL-Ladevorgänge, Registry-Aktivitäten, DNS-Abfragen, Prozesszugriffe, WMI-Aktivitäten. Die Ereignisse befinden sich üblicherweise unter: Anwendungs- und Dienstprotokolle └─ Microsoft └─ Windows └─ Sysmon └─ Operational Sysmon ist kein spontanes Read-only-Diagnosewerkzeug. Installation und Konfiguration verändern das System dauerhaft: [PRIV][CHANGE] sysmon64.exe -accepteula -i config.xml Aktuelle Konfiguration anzeigen: [RO][PRIV] sysmon64.exe -c Konfiguration aktualisieren: [PRIV][CHANGE] sysmon64.exe -c config.xml Sysmon deinstallieren: [PRIV][CHANGE][DISRUPT] sysmon64.exe -u Vor einer Einführung müssen geklärt werden: Welche Ereignisse werden benötigt? Welche Daten dürfen protokolliert werden? Wie hoch ist das erwartete Datenvolumen? Wie lange werden Protokolle aufbewahrt? Wer darf darauf zugreifen? Werden Ereignisse an ein SIEM weitergeleitet? Wie wird die Konfiguration getestet und versioniert? Welche Datenschutz- und Betriebsratsvorgaben gelten? Sysmon bewertet Ereignisse nicht selbst als gutartig oder bösartig. Die Qualität der Ergebnisse hängt wesentlich von der Konfiguration und der anschließenden Auswertung ab. 15. Praxisfall – hohe CPU-Auslastung untersuchen Ziel: Verursachenden Prozess und möglichst den auslösenden Thread bestimmen. Uhrzeit und wahrgenommene Auswirkung dokumentieren. Mit Task-Manager oder Process Explorer den Prozess bestimmen. CPU-Verlauf über einen angemessenen Zeitraum beobachten. Prozesspfad, Benutzer, Kommandozeile und übergeordneten Prozess prüfen. In Process Explorer die Prozesseigenschaften öffnen. Unter Threads nach CPU-Auslastung sortieren. Auffälligen Thread und zugehöriges Modul dokumentieren. Ereignisanzeige und Anwendungsprotokolle zum selben Zeitpunkt prüfen. Bei reproduzierbaren Lastspitzen kontrolliert ProcDump einsetzen. Speicherabbild an Hersteller oder Entwicklung zur Analyse übergeben. Nicht vorschnell tun: Prozess sofort beenden, Priorität ohne Begründung verändern, Sicherheitssoftware deaktivieren, wiederholt vollständige Dumps ohne Speicherplatzkontrolle erzeugen. 16. Praxisfall – Datei oder Ordner lässt sich nicht ändern, löschen oder umbenennen Typische Meldungen Datei wird von einem anderen Prozess verwendet. Zugriff verweigert. Freigabeverletzung. Ordner kann nicht gelöscht werden. Diagnoseablauf Vollständigen Pfad dokumentieren. Berechtigungen und Besitzverhältnisse prüfen. Mit Process Explorer nach Dateiname oder Pfad suchen. Alternativ Handle verwenden: [RO][PRIV] handle.exe "C:\Daten\Projekt\bericht.xlsx" Prozessname, PID, Benutzerkonto und Zweck identifizieren. Prüfen, ob der Prozess regulär geschlossen werden kann. Bei einem Dienst den zuständigen Dienst bestimmen. Anwendung oder Dienst kontrolliert schließen. Dateioperation erneut testen. Ergebnis dokumentieren. Ein Handle sollte nicht zwangsweise geschlossen werden, solange ein geordnetes Beenden des verantwortlichen Programms möglich ist. 17. Praxisfall – Anwendung startet nicht Diagnoseablauf Exakte Fehlermeldung und Uhrzeit dokumentieren. Anwendungspfad und Version prüfen. Digitale Signatur der Programmdatei prüfen: [RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe" Ereignisanzeige und anwendungseigene Protokolle prüfen. Process Monitor vorbereiten. Filter auf den Prozessnamen setzen. Aufnahme starten und Anwendung einmal starten. Aufnahme sofort stoppen. Letzte Zugriffe vor dem Prozessende untersuchen. Besonders auf folgende Resultate achten: ACCESS DENIED PATH NOT FOUND NAME NOT FOUND SHARING VIOLATION BAD IMAGE Geladene DLLs und deren Pfade prüfen. Vergleich mit einem funktionierenden Referenzsystem durchführen. Erst nach belegter Ursache Berechtigung, Pfad, Konfiguration oder Installation ändern. Viele NAME NOT FOUND -Ereignisse sind Teil eines normalen Suchvorgangs. Relevant ist häufig der letzte nicht erfolgreich ersetzte Zugriff unmittelbar vor dem Abbruch. 18. Praxisfall – unbekannte Netzwerkverbindung untersuchen Lokale und entfernte Adresse dokumentieren. Port, Protokoll und Verbindungsstatus erfassen. Prozess-ID mit TCPView oder Tcpvcon bestimmen: [RO] tcpvcon.exe -a -n Prozess-ID in Process Explorer untersuchen. Dateipfad, Kommandozeile, Benutzer und übergeordneten Prozess prüfen. Signatur und Hash der ausführbaren Datei erfassen. DNS-Auflösung und Zielsystem kontrollieren. Prüfen, ob die Verbindung zur Funktion der Anwendung passt. Firewall-, Proxy- und Sicherheitsprotokolle zum selben Zeitpunkt vergleichen. Bei tatsächlichem Verdacht das Incident-Response-Verfahren des Unternehmens anwenden. Eine unbekannte externe IP-Adresse kann beispielsweise zu einem CDN, Cloudanbieter, Update-Dienst oder Sicherheitsdienst gehören. Eine Eigentümerabfrage allein beweist daher weder Zweck noch Vertrauenswürdigkeit der Verbindung. 19. Häufige Fehlinterpretationen vermeiden Beobachtung Falscher Schluss Richtige Einordnung Prozess ist unbekannt Prozess ist Schadsoftware Pfad, Signatur, Herausgeber, Parent und Funktion prüfen Datei ist nicht signiert Datei ist schädlich Signatur ist nur ein Bewertungskriterium Datei ist signiert Datei ist sicher Auch signierte Software kann unerwünscht oder verwundbar sein Procmon zeigt NAME NOT FOUND Ursache wurde gefunden Suchvorgänge erzeugen diesen Status regelmäßig Procmon zeigt BUFFER OVERFLOW Speicherüberlauf der Anwendung Häufig normale Ermittlung der benötigten Puffergröße Viele TCP-Verbindungen System ist kompromittiert Browser, Cloud- und Kommunikationsprogramme erzeugen viele Verbindungen Hoher RAM-Verbrauch Arbeitsspeicher ist defekt Cache, Commit, Working Set und Speichertypen getrennt prüfen Hohe Handle-Anzahl Sicheres Handle-Leak Verlauf und Referenzwerte beobachten VirusTotal meldet nichts Datei ist garantiert sicher Fehlende Erkennungen sind keine Sicherheitsgarantie Autoruns-Eintrag ist unbekannt Eintrag muss gelöscht werden Zweck, Pfad und Herausgeber zunächst ermitteln Prozess lässt sich beenden Problem ist gelöst Ursache kann weiterbestehen und erneut auftreten 20. Empfohlener Sysinternals-Diagnoseablauf Phase Vorgehen Geeignete Werkzeuge 1. Störung aufnehmen Fehler, Zeitpunkt und Auswirkung dokumentieren Ticket, Screenshot, Ereignisanzeige 2. Prozess bestimmen Prozessname, PID und Benutzer ermitteln Process Explorer, PsList 3. Herkunft prüfen Pfad, Parent, Kommandozeile und Signatur prüfen Process Explorer, Sigcheck 4. Aktivität beobachten Datei-, Registry-, Prozess- und Netzwerkzugriffe erfassen Process Monitor, TCPView 5. Ressourcen untersuchen CPU, Handles und Speicherentwicklung prüfen Process Explorer, Handle, RAMMap, VMMap 6. Autostart prüfen Startmechanismen und Anmeldeobjekte untersuchen Autoruns 7. Fehler reproduzieren Gefilterte, zeitlich begrenzte Aufnahme erstellen Process Monitor 8. Beweise sichern PML, CSV, Screenshots oder Dump geschützt speichern Procmon, Autorunsc, ProcDump 9. Hypothese testen Nur eine kontrollierte Änderung durchführen abhängig von Ursache 10. Ergebnis bestätigen Ausgangsfehler erneut testen und Nebenwirkungen prüfen gleiche Messmethode 11. Dokumentieren Ursache, Änderung, Ergebnis und Rückweg festhalten BookStack, Ticketsystem Merksatz Erst beobachten, dann zuordnen, anschließend vergleichen und erst danach verändern. 21. Kompakte Befehlsübersicht Aufgabe Befehl Kennzeichnung Signatur mit PowerShell prüfen Get-AuthenticodeSignature "C:\Pfad\Datei.exe" [RO] SHA-256-Hash berechnen Get-FileHash "C:\Pfad\Datei.exe" -Algorithm SHA256 [RO] Alle Autostarts anzeigen autorunsc.exe -a * -s [RO][PRIV] Autostarts als CSV speichern autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv [RO][PRIV][FILE] Alle Netzwerkendpunkte anzeigen tcpvcon.exe -a -n [RO] Endpunkte als CSV speichern tcpvcon.exe -a -n -c > C:\Temp\tcp.csv [RO][FILE] Dateiinhaber suchen handle.exe bericht.xlsx [RO][PRIV] Handles eines Prozesses anzeigen handle.exe -p 4321 [RO][PRIV] Dateisignatur und Hash prüfen sigcheck.exe -nobanner -a -h -i Datei.exe [RO] Nicht signierte System32-Dateien suchen sigcheck.exe -nobanner -u -e C:\Windows\System32 [RO][PRIV] Prozessliste anzeigen pslist.exe [RO] Prozessbaum anzeigen pslist.exe -t [RO] DLLs eines Prozesses anzeigen listdlls.exe 4321 [RO] vollständiges Prozessabbild erzeugen procdump.exe -ma 4321 C:\Dumps [TEST][PRIV][FILE][SENS] Dump bei nicht reagierendem Fenster procdump.exe -ma -h beispiel.exe C:\Dumps [TEST][PRIV][FILE][SENS] Sysmon-Konfiguration anzeigen sysmon64.exe -c [RO][PRIV] Handle zwangsweise schließen handle.exe -c 7C -p 4321 [PRIV][CHANGE][DISRUPT] Prozess zwangsweise beenden pskill.exe 4321 [CHANGE][DISRUPT] 22. Dokumentationsvorlage für eine Sysinternals-Analyse Ticketnummer: Analysedatum: Administrator: Betroffener Computer: Betriebssystem: Angemeldeter Benutzer: Fehlerbeginn: Fehlerbeschreibung: Auswirkung: Betroffener Prozess: Prozess-ID: Programmdatei: Dateiversion: Benutzerkonto: Übergeordneter Prozess: Kommandozeile: Digitale Signatur: SHA-256: Verwendete Sysinternals-Werkzeuge: Werkzeugversionen: Verwendete Filter: Aufnahmezeitraum: Beobachtungen: - - - Ermittelte Auffälligkeiten: - - - Arbeitshypothese: Beleg für die Hypothese: Durchgeführter Test: Testergebnis: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Erzeugte Dateien: - PML: - CSV: - Speicherabbild: - Screenshots: Speicherort: Zugriffsberechtigung: Lösch- oder Aufbewahrungsfrist: 23. Offizielle Quellen und weiterführende Dokumentation Microsoft Sysinternals – Übersicht Sysinternals Suite Process Explorer Process Monitor Autoruns und Autorunsc TCPView und Tcpvcon Handle Sigcheck PsTools PsList ProcDump RAMMap VMMap ListDLLs Sysmon Da Microsoft die Sysinternals-Werkzeuge regelmäßig aktualisiert, sollte vor dem produktiven Einsatz immer die aktuelle offizielle Dokumentation der verwendeten Version geprüft werden. 2.12 Protokolle und Logs systematisch auswerten Protokolldateien gehören zu den wichtigsten Informationsquellen bei der Fehleranalyse. Sie dokumentieren Ereignisse, Zustandsänderungen, Warnungen und Fehler, die während des Betriebs eines Systems oder einer Anwendung auftreten. Logs können unter anderem folgende Fragen beantworten: Wann begann die Störung? Welches System oder welcher Dienst meldete den Fehler zuerst? Welcher Benutzer, Prozess oder Dienst war beteiligt? Trat unmittelbar vorher eine Konfigurationsänderung auf? Ist das Problem einmalig oder wiederkehrend? Sind mehrere Systeme zur gleichen Zeit betroffen? Welche Fehlernummer, Ereignis-ID oder Statusmeldung wurde protokolliert? War ein Fehler die Ursache oder nur eine Folge eines anderen Problems? Grundregel: Nicht mit dem auffälligsten Fehler beginnen, sondern mit dem ersten relevanten Ereignis in der zeitlichen Kette. 1. Kennzeichnungen und Sicherheitsregeln Kennzeichnung Bedeutung [RO] Liest Informationen aus, ohne sie absichtlich zu verändern [TEST] Führt einen aktiven Test aus oder erzeugt zusätzliche Logeinträge [PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte [FILE] Erzeugt oder verändert eine Datei [SENS] Ausgabe kann vertrauliche Daten enthalten [CHANGE] Verändert Konfiguration, Protokollierung oder Systemzustand [DISRUPT] Kann Dienste oder Systeme beeinträchtigen Logs können unter anderem folgende vertrauliche Informationen enthalten: Benutzernamen und E-Mail-Adressen, interne Hostnamen und IP-Adressen, vollständige Datei- und Verzeichnispfade, aufgerufene URLs und Suchbegriffe, Sitzungs- und Korrelations-IDs, Kommandozeilen und Programmparameter, Datenbank- und Servernamen, Inhalte von Anfragen und Antworten, Zugangstoken oder andere Geheimnisse, personenbezogene oder geschäftliche Daten. Deshalb gilt: Protokolle nur so umfangreich wie erforderlich erfassen. Exportierte Logs geschützt speichern. Zugriff auf autorisierte Personen begrenzen. Vor externer Weitergabe sensible Inhalte redigieren. Originaldateien möglichst unverändert sichern. Arbeitskopien getrennt vom Original anlegen. Aufbewahrungs- und Löschfristen beachten. Protokolle niemals unkontrolliert in öffentliche Analysedienste hochladen. 2. Wie wird eine Log-Analyse systematisch begonnen? Vor dem Öffnen der ersten Protokolldatei sollten mindestens folgende Informationen bekannt sein: Information Beispiel Betroffenes System CLIENT-023 Betroffener Dienst DNS-Client Fehlerbeginn 2026-07-31 09:42:15 CEST Letzter bekannter funktionierender Zeitpunkt 2026-07-31 09:35 CEST Betroffener Benutzer Max Mustermann Fehlerbeschreibung Interne Anwendung nicht erreichbar Reproduzierbarkeit Bei jedem Anmeldeversuch Kürzliche Änderung VPN-Client aktualisiert Zeitzone des meldenden Systems Europe/Berlin Vergleichssystem CLIENT-024 funktioniert Empfohlener Analysezeitraum Der Zeitraum sollte zunächst eng um das Ereignis gelegt werden: Fehlerzeitpunkt: 09:42 Uhr Erste Untersuchung: 09:37 bis 09:47 Uhr Falls dort keine Ursache erkennbar ist, wird das Zeitfenster schrittweise erweitert. Bewährte Reihenfolge Uhrzeit und Zeitzone aller beteiligten Systeme prüfen. Fehler reproduzieren und exakten Zeitpunkt notieren. Passendes Protokoll bestimmen. Zeitfenster begrenzen. Nach Quelle, Dienst, Prozess oder Ereignis-ID filtern. Das erste relevante Ereignis suchen. Vorhergehende und nachfolgende Ereignisse betrachten. Meldungen zwischen beteiligten Systemen zeitlich korrelieren. Hypothese aufstellen. Hypothese durch einen kontrollierten Test überprüfen. 3. Welche Informationen eines Logeintrags sind wichtig? Feld Bedeutung Prüffrage Zeitstempel Zeitpunkt des Ereignisses Welche Zeitzone wird verwendet? Hostname meldendes System Ist es wirklich das betroffene System? Quelle oder Provider erzeugende Komponente Welcher Dienst oder Treiber meldet das Ereignis? Prozess und PID beteiligter Prozess Läuft derselbe Prozess noch? Benutzer oder UID Sicherheitskontext Unter welchem Konto trat der Fehler auf? Schweregrad Einordnung durch die Anwendung Ist Error wirklich die Ursache? Ereignis-ID typisierter Ereigniscode Ist die ID providerspezifisch? Nachricht menschenlesbare Beschreibung Enthält sie Ursache, Folge oder nur Status? Fehlercode technischer Rückgabewert Ist der Code dezimal oder hexadezimal? Korrelations-ID verbindet zusammengehörige Vorgänge Taucht dieselbe ID in anderen Logs auf? Dienst oder Unit betroffene Komponente Welche Abhängigkeiten besitzt sie? Datei und Zeile Position im Programmcode Passt sie zur eingesetzten Version? Dauer Laufzeit einer Operation Wo entsteht die Verzögerung? Remote-Endpunkt beteiligtes Zielsystem Waren DNS, Routing und Port erreichbar? Eine Ereignis-ID ist normalerweise nur zusammen mit der Quelle eindeutig. Ereignis-ID 1000 von Quelle A ≠ Ereignis-ID 1000 von Quelle B 4. Wie werden Schweregrade richtig interpretiert? Allgemeiner Schweregrad Typische Bedeutung Trace sehr detaillierter interner Ablauf Debug Diagnoseinformationen für Entwicklung und Administration Information reguläres Ereignis oder Statusmeldung Notice bemerkenswertes, aber nicht zwingend fehlerhaftes Ereignis Warning unerwarteter Zustand; Verarbeitung kann weiterlaufen Error Operation ist fehlgeschlagen Critical schwerwiegender Fehler mit deutlicher Beeinträchtigung Alert unmittelbares Eingreifen erforderlich Emergency System oder Dienst ist nicht mehr verwendbar Die genaue Bedeutung hängt von der jeweiligen Anwendung ab. Nicht jedes Programm verwendet dieselbe Einteilung. Wichtige Regeln Eine Warnung ist nicht automatisch die Ursache. Eine Fehlermeldung kann nur die Folge eines früheren Fehlers sein. Eine Informationsmeldung kann den entscheidenden Hinweis enthalten. Debug-Protokollierung kann relevante Informationen liefern, erzeugt aber viel Datenvolumen. Wiederholte Meldungen können auf automatische Wiederholungsversuche hinweisen. Eine erfolgreiche Wiederholung kann einen vorherigen Fehler bereits kompensiert haben. Beispiel einer Ereigniskette 09:42:10 INFO DNS-Abfrage gestartet 09:42:15 WARNING Zeitüberschreitung bei DNS-Server 192.168.10.10 09:42:15 INFO Zweiter DNS-Server wird verwendet 09:42:16 INFO Name erfolgreich aufgelöst 09:42:16 ERROR HTTPS-Verbindung abgelehnt Hier ist die DNS-Warnung möglicherweise nicht die unmittelbare Ursache, weil die Namensauflösung anschließend erfolgreich war. Die abgelehnte HTTPS-Verbindung muss getrennt untersucht werden. 5. Wie werden Datum, Uhrzeit und Zeitzone geprüft? Aufgabe Windows Linux macOS Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z" UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone Zeitquelle [RO] w32tm /query /source [RO] timedatectl timesync-status [TEST] sntp -d time.apple.com Synchronisationsstatus [RO] w32tm /query /status [RO] timedatectl status [TEST] sntp -d time.apple.com chrony-Status Nicht zutreffend [RO] chronyc tracking Nicht standardmäßig vorhanden chrony-Quellen Nicht zutreffend [RO] chronyc sources -v Nicht standardmäßig vorhanden Warum ist das wichtig? Bereits wenige Minuten Zeitabweichung können die Zuordnung zwischen folgenden Systemen erschweren: Client und Server, Firewall und Anwendung, Webserver und Datenbank, Hypervisor und virtuelle Maschine, Reverse Proxy und Backend, Identitätsanbieter und Cloudanwendung. Ein Zeitstempel ohne Zeitzone ist nicht eindeutig. 2026-07-31 14:30:00 Ein Zeitstempel mit Offset ist eindeutig zuordenbar: 2026-07-31T14:30:00+02:00 UTC-Darstellung: 2026-07-31T12:30:00Z 6. Wie werden Windows-Ereignisprotokolle grafisch untersucht? Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet: [RO] eventvwr.msc Wichtige Protokollbereiche: Protokoll Typische Inhalte Anwendung Anwendungs-, Datenbank- und Laufzeitfehler Sicherheit Anmeldungen, Kontoereignisse und überwachte Zugriffe Setup Installation und Systemkonfiguration System Treiber, Dienste, Netzwerk und Betriebssystem Weitergeleitete Ereignisse zentral gesammelte Ereignisse anderer Systeme Anwendungs- und Dienstprotokolle komponentenspezifische Windows-Protokolle Empfohlenes Vorgehen Passendes Protokoll auswählen. Aktuelles Protokoll filtern verwenden. Zeitraum auf den Störungszeitraum begrenzen. Ereignisebene auswählen. Falls bekannt, Quelle und Ereignis-ID eingeben. Ereignis in der Detailansicht öffnen. Allgemeine und XML-Ansicht vergleichen. Ereignisse unmittelbar davor und danach untersuchen. Relevante Ereignisse exportieren oder dokumentieren. Wichtige Felder Protokollname, Quelle beziehungsweise Provider, Ereignis-ID, Ebene, Benutzer, Opcode und Aufgabe, Computername, Zeitstempel, Prozess- und Thread-ID, Ereignisdaten. Die XML-Ansicht kann Informationen enthalten, die in der allgemeinen Beschreibung nicht vollständig dargestellt werden. 7. Wie werden Windows-Ereignisse mit PowerShell gelesen? Verfügbare Ereignisprotokolle auflisten [RO] Get-WinEvent -ListLog * | Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes Nur aktivierte Protokolle anzeigen: [RO] Get-WinEvent -ListLog * | Where-Object IsEnabled | Sort-Object LogName | Select-Object LogName, RecordCount Neueste Ereignisse des Systemprotokolls [RO] Get-WinEvent -LogName System -MaxEvents 20 Neueste Ereignisse des Anwendungsprotokolls [RO] Get-WinEvent -LogName Application -MaxEvents 20 Ereignisse der letzten Stunde [RO] $Start = (Get-Date).AddHours(-1) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } Fehler und kritische Ereignisse der letzten 24 Stunden [RO] $Start = (Get-Date).AddHours(-24) Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2 StartTime = $Start } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message Level Windows-Ebene 1 Kritisch 2 Fehler 3 Warnung 4 Information 5 Ausführlich Nach Ereignis-ID filtern [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 7036 } -MaxEvents 20 Nach Provider filtern [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddHours(-4) } Mehrere Ereignis-IDs abfragen [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 6005, 6006, 6008, 1074 StartTime = (Get-Date).AddDays(-7) } | Select-Object TimeCreated, Id, ProviderName, Message Ergebnis übersichtlich ausgeben [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2, 3 StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message | Format-List Nach Text in der Meldung suchen [RO] Get-WinEvent -LogName Application -MaxEvents 1000 | Where-Object Message -Match 'timeout|Zeitüberschreitung' Die Filterung mit FilterHashtable erfolgt bereits beim Abruf und ist bei großen Protokollen effizienter als eine nachträgliche Filterung mit Where-Object . Eine Textsuche in der formatierten Nachricht erfordert jedoch häufig eine nachträgliche Auswertung. 8. Wie werden Windows-Ereignisse exportiert und archiviert? Systemprotokoll als EVTX exportieren [RO][PRIV][FILE][SENS] wevtutil epl System C:\Temp\System.evtx Anwendungsprotokoll exportieren [RO][PRIV][FILE][SENS] wevtutil epl Application C:\Temp\Application.evtx Ereignisse mit PowerShell als CSV exportieren [RO][FILE][SENS] $Start = (Get-Date).AddHours(-2) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message | Export-Csv -Path 'C:\Temp\System-Events.csv' -NoTypeInformation -Encoding UTF8 Ereignisse als XML sichern [RO][FILE][SENS] Get-WinEvent -LogName System -MaxEvents 100 | Export-Clixml -Path 'C:\Temp\System-Events.xml' Verfügbare Protokolle mit wevtutil auflisten [RO] wevtutil el Letzte zehn Systemereignisse im Textformat anzeigen [RO] wevtutil qe System /c:10 /rd:true /f:text Option Bedeutung qe Ereignisse abfragen epl Protokoll exportieren /c:10 maximal zehn Ereignisse /rd:true neueste Ereignisse zuerst /f:text Textausgabe /f:xml XML-Ausgabe Protokoll nicht während der Analyse löschen Der folgende Befehl löscht ein Ereignisprotokoll und darf nicht als regulärer Diagnoseschritt verwendet werden: [PRIV][CHANGE][DISRUPT] wevtutil cl System Das Löschen vernichtet möglicherweise entscheidende Beweise und kann gegen betriebliche oder rechtliche Vorgaben verstoßen. 9. Wie werden Linux-Protokolle mit journalctl untersucht? Bei systemd-basierten Linux-Systemen werden viele Ereignisse im systemd-Journal gespeichert und mit journalctl ausgewertet. Gesamtes Journal anzeigen [RO] journalctl Neueste Einträge zuerst anzeigen [RO] journalctl -r Aktuellen Systemstart untersuchen [RO] journalctl -b Vorherigen Systemstart untersuchen [RO] journalctl -b -1 Verfügbare Systemstarts anzeigen [RO] journalctl --list-boots Nur Kernelmeldungen anzeigen [RO] journalctl -k Kernelmeldungen des aktuellen Starts [RO] journalctl -k -b Protokoll eines Dienstes anzeigen [RO] journalctl -u ssh.service [RO] journalctl -u nginx.service Protokoll eines Dienstes live verfolgen [RO] journalctl -u nginx.service -f Beenden mit: Strg+C Ereignisse seit einem Zeitpunkt [RO] journalctl --since "2026-07-31 09:30:00" Zeitfenster eingrenzen [RO] journalctl \ --since "2026-07-31 09:30:00" \ --until "2026-07-31 10:00:00" Relative Zeitangaben [RO] journalctl --since "30 minutes ago" [RO] journalctl --since today Nach Priorität filtern [RO] journalctl -p err Fehler und schwerwiegendere Meldungen des aktuellen Starts: [RO] journalctl -b -p err Warnungen und schwerwiegendere Meldungen eines Dienstes: [RO] journalctl -u nginx.service -p warning Priorität Nummer emerg 0 alert 1 crit 2 err 3 warning 4 notice 5 info 6 debug 7 Mit -p warning werden normalerweise warning und alle schwerwiegenderen Prioritäten angezeigt. Nach Prozess-ID filtern [RO] journalctl _PID=4321 Nach ausführbarer Datei filtern [RO] journalctl _EXE=/usr/sbin/sshd Nach Benutzer-ID filtern [RO] journalctl _UID=1000 Ausgabe ohne Pager [RO] journalctl -u nginx.service --no-pager ISO-Zeitstempel verwenden [RO] journalctl -u nginx.service -o short-iso Ausführliche Felder eines Ereignisses anzeigen [RO] journalctl -u nginx.service -n 10 -o verbose 10. Wie wird der Status eines Linux-Dienstes einschließlich Logs geprüft? Dienststatus anzeigen [RO] systemctl status nginx.service Ohne interaktiven Pager: [RO] systemctl status nginx.service --no-pager Vollständige Zeilen ohne Kürzung: [RO] systemctl status nginx.service --no-pager --full Prüfen, ob der Dienst aktiv ist [RO] systemctl is-active nginx.service Prüfen, ob der Dienst aktiviert ist [RO] systemctl is-enabled nginx.service Fehlgeschlagene Units anzeigen [RO] systemctl --failed Journal des Dienstes seit dem aktuellen Start [RO] journalctl -b -u nginx.service Wichtige Unterscheidung Befehl Aussage systemctl is-active Läuft die Unit aktuell? systemctl is-enabled Ist ein automatischer Start konfiguriert? systemctl status Status, PID und letzte Logmeldungen journalctl -u ausführlicher zeitlicher Verlauf der Unit Ein Dienst kann aktiviert, aber aktuell nicht aktiv sein. Umgekehrt kann ein manuell gestarteter Dienst aktiv sein, obwohl er nicht für den automatischen Start aktiviert wurde. 11. Wie werden klassische Linux-Protokolldateien gelesen? Abhängig von Distribution und Dienst befinden sich Textprotokolle häufig unter: /var/log/ Typische Beispiele: Pfad Möglicher Inhalt /var/log/syslog allgemeine Systemmeldungen bei Debian/Ubuntu /var/log/messages allgemeine Systemmeldungen bei RHEL-artigen Systemen /var/log/auth.log Authentifizierungsereignisse bei Debian/Ubuntu /var/log/secure Authentifizierungsereignisse bei RHEL-artigen Systemen /var/log/kern.log Kernelmeldungen /var/log/dmesg gespeicherte Boot- und Kernelmeldungen /var/log/nginx/ Nginx-Zugriffs- und Fehlerprotokolle /var/log/apache2/ Apache-Protokolle bei Debian/Ubuntu /var/log/httpd/ Apache-Protokolle bei RHEL-artigen Systemen Die tatsächlichen Pfade hängen von Distribution, Paket, Konfiguration und Protokollierungsdienst ab. Sie müssen deshalb auf dem konkreten System geprüft werden. Datei mit less öffnen [RO] less /var/log/syslog Nützliche Tasten in less : Taste Funktion G zum Dateiende g zum Dateianfang /text vorwärts suchen ?text rückwärts suchen n nächster Treffer N vorheriger Treffer q beenden Letzte Zeilen anzeigen [RO] tail -n 50 /var/log/syslog Neue Zeilen live verfolgen [RO] tail -f /var/log/syslog Datei auch nach Rotation weiterverfolgen [RO] tail -F /var/log/nginx/error.log tail -F versucht im Gegensatz zu tail -f , die Datei nach einer Rotation oder Neuerstellung erneut zu öffnen. Bestimmten Begriff suchen [RO] grep -i "error" /var/log/syslog Mehrere Begriffe suchen [RO] grep -Ei "error|failed|timeout|denied" /var/log/syslog Zeilennummern anzeigen [RO] grep -Ein "error|failed|timeout|denied" /var/log/syslog Treffer mit Kontext anzeigen [RO] grep -Ein -B 3 -A 5 "timeout" /var/log/syslog Option Bedeutung -i Groß- und Kleinschreibung ignorieren -E erweiterte reguläre Ausdrücke -n Zeilennummer anzeigen -B 3 drei Zeilen vor dem Treffer -A 5 fünf Zeilen nach dem Treffer -C 5 fünf Zeilen vor und nach dem Treffer 12. Wie werden rotierte und komprimierte Linux-Logs durchsucht? Protokolle werden häufig rotiert, damit einzelne Dateien nicht unbegrenzt wachsen. Beispiel: auth.log auth.log.1 auth.log.2.gz auth.log.3.gz Datei Bedeutung auth.log aktuelles Protokoll auth.log.1 vorherige unkomprimierte Generation auth.log.2.gz ältere komprimierte Generation Komprimiertes Protokoll anzeigen [RO] zless /var/log/auth.log.2.gz Komprimiertes Protokoll durchsuchen [RO] zgrep -i "failed" /var/log/auth.log.2.gz Mehrere rotierte Dateien durchsuchen [RO] zgrep -Ei "failed|denied|timeout" /var/log/auth.log.*.gz Aktuelle und ältere unkomprimierte Dateien durchsuchen: [RO] grep -Ei "failed|denied|timeout" /var/log/auth.log /var/log/auth.log.1 Vor einer Analyse sollte geprüft werden, ob der Störungszeitpunkt bereits in einer rotierten Datei liegt. 13. Wie werden Kernel- und Hardwaremeldungen unter Linux geprüft? Kernelmeldungen aus dem Journal [RO] journalctl -k -b Klassische dmesg-Ausgabe [RO][PRIV] sudo dmesg Menschenlesbare Zeitstempel: [RO][PRIV] sudo dmesg --human Nur Warnungen und Fehler anzeigen: [RO][PRIV] sudo dmesg --level=warn,err,crit,alert,emerg Nach typischen Hardware- und Netzwerkproblemen suchen: [RO][PRIV] sudo dmesg --human | grep -Ei "error|failed|timeout|reset|link.*down|I/O" Typische Hinweise: Meldung Mögliche Untersuchungsrichtung I/O error Datenträger, Kabel, Controller oder Dateisystem link down Netzwerkkabel, Switchport, Treiber oder Interface reset Gerät, Bus, Treiber oder Stromversorgung out of memory Speicherdruck und OOM-Killer segfault Programmfehler, Bibliothek oder Speicherproblem read-only filesystem Dateisystemfehler oder Schutzreaktion firmware failed to load fehlende oder inkompatible Firmware Eine Meldung beschreibt zunächst nur eine Beobachtung. Beispielsweise kann ein link down durch das bewusste Abziehen eines Kabels entstanden sein. 14. Wie werden macOS-Protokolle mit der Konsole untersucht? Die App Konsole zeigt unter anderem: Live-Protokollmeldungen, System- und Anwendungsaktivitäten, Absturzberichte, Diagnoseberichte, Spin- und Hang-Berichte, Systemberichte. Öffnen über Spotlight: Konsole Oder über das Terminal: [RO] open -a Console Empfohlenes Vorgehen In der Seitenleiste den lokalen Mac auswählen. Live-Anzeige nur für einen kurzen Zeitraum aktivieren. Suchfeld nach Prozess, Subsystem, Kategorie oder Meldung filtern. Fehler einmal reproduzieren. Live-Anzeige wieder anhalten. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. Detailbereich des Ereignisses öffnen. Prozess, Subsystem, Kategorie und Zeitstempel dokumentieren. Abhängig von Benutzerrechten und Systemeinstellungen sind nicht alle Meldungen sichtbar. Für bestimmte Protokolle kann eine administrative Authentifizierung erforderlich sein. 15. Wie werden macOS-Protokolle mit log show ausgewertet? macOS verwendet das Unified Logging System. Historische Ereignisse werden mit log show untersucht. Letzte zehn Minuten anzeigen [RO] log show --last 10m Letzte Stunde anzeigen [RO] log show --last 1h Kompakte Darstellung [RO] log show --last 10m --style compact Nach Prozess filtern [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari"' Nach Subsystem filtern [RO] log show \ --last 30m \ --style compact \ --predicate 'subsystem == "com.apple.network"' Das konkrete Subsystem muss zuvor aus einem passenden Ereignis ermittelt werden. Es darf nicht allein anhand des Produktnamens angenommen werden. Nach Text in der Ereignismeldung suchen [RO] log show \ --last 30m \ --style compact \ --predicate 'eventMessage CONTAINS[c] "error"' Mehrere Bedingungen kombinieren [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari" AND eventMessage CONTAINS[c] "network"' Informations- und Debugmeldungen einbeziehen [RO] log show \ --last 10m \ --info \ --debug \ --style compact Debugmeldungen können sehr umfangreich sein. Das Zeitfenster sollte deshalb möglichst klein gewählt werden. Bestimmtes Zeitfenster untersuchen [RO] log show \ --start '2026-07-31 09:30:00' \ --end '2026-07-31 09:45:00' \ --style compact Datumsformat, Zeitzone und unterstützte Optionen sollten auf der eingesetzten macOS-Version mit man log beziehungsweise log help show geprüft werden. 16. Wie werden macOS-Protokolle live verfolgt? Live-Ausgabe starten [RO] log stream Kompakte Live-Ausgabe [RO] log stream --style compact Bestimmten Prozess verfolgen [RO] log stream \ --style compact \ --predicate 'process == "Safari"' Nach Meldungsinhalt filtern [RO] log stream \ --style compact \ --predicate 'eventMessage CONTAINS[c] "timeout"' Informationsmeldungen einbeziehen [RO] log stream --info --style compact Beenden mit: Strg+C Sicherer Ablauf Filter vorbereiten. Live-Aufzeichnung starten. Problem genau einmal reproduzieren. Aufzeichnung sofort beenden. Zeitstempel und relevante Ereignisse dokumentieren. Eine ungefilterte Live-Ausgabe kann sehr schnell unübersichtlich werden. 17. Wie werden Docker-Containerlogs untersucht? Docker schreibt standardmäßig die Standardausgabe und Standardfehlerausgabe eines Containers in den konfigurierten Logging-Treiber. Die tatsächlich verfügbaren Logs hängen deshalb von Container, Anwendung und Logging-Konfiguration ab. Laufende Container anzeigen [RO] docker ps Auch beendete Container anzeigen: [RO] docker ps -a Logs eines Containers anzeigen [RO][SENS] docker logs beispiel-container Letzte 100 Zeilen anzeigen [RO][SENS] docker logs --tail 100 beispiel-container Zeitstempel einblenden [RO][SENS] docker logs --timestamps --tail 100 beispiel-container Logs live verfolgen [RO][SENS] docker logs --follow --tail 100 beispiel-container Logs seit einem relativen Zeitpunkt [RO][SENS] docker logs --since 30m beispiel-container Logs seit einem absoluten Zeitpunkt [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ beispiel-container Zeitfenster begrenzen [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ --until "2026-07-31T09:45:00+02:00" \ --timestamps \ beispiel-container Docker-Compose-Dienste anzeigen [RO] docker compose ps Logs eines Compose-Dienstes [RO][SENS] docker compose logs --tail 100 beispiel-dienst Compose-Logs live verfolgen [RO][SENS] docker compose logs --follow --tail 100 beispiel-dienst Wichtige Grenzen Nicht jede Anwendung schreibt alle Fehler nach stdout oder stderr . Ein Container kann zusätzlich interne Logdateien verwenden. Ein nicht mehr vorhandener Container kann auch nicht mehr direkt mit docker logs abgefragt werden. Logrotation und Logging-Treiber beeinflussen die Verfügbarkeit. Das Fehlen einer Meldung beweist nicht, dass kein Fehler aufgetreten ist. 18. Wie werden Webserver- und Reverse-Proxy-Logs interpretiert? Webserver führen häufig mindestens zwei getrennte Protokolle: Protokoll Inhalt Access Log eingegangene HTTP-Anfragen und Antwortstatus Error Log interne Fehler, Verbindungsprobleme und Konfigurationshinweise Typischer Access-Log-Eintrag: 192.0.2.50 - - [31/Jul/2026:09:42:15 +0200] "GET /login HTTP/1.1" 502 157 Bestandteil Bedeutung 192.0.2.50 Client-IP-Adresse Zeitstempel Zeitpunkt und Zeitzone GET HTTP-Methode /login angeforderter Pfad HTTP/1.1 Protokollversion 502 HTTP-Statuscode 157 übertragene Antwortgröße, abhängig vom Logformat Wichtige HTTP-Statusgruppen Bereich Bedeutung 1xx Information 2xx erfolgreiche Verarbeitung 3xx Umleitung 4xx Anfrage konnte aus Clientsicht nicht verarbeitet werden 5xx serverseitige Verarbeitung fehlgeschlagen Typische Statuscodes: Status Bedeutung Untersuchungsrichtung 200 Anfrage erfolgreich Inhalt und Antwortzeit prüfen 301 / 302 Umleitung Ziel und Weiterleitungskette prüfen 400 ungültige Anfrage Header, Syntax und Proxy prüfen 401 Authentifizierung erforderlich oder fehlgeschlagen Anmeldedaten und Authentifizierungsdienst 403 Zugriff verweigert Berechtigungen und Regeln 404 Ressource nicht gefunden Pfad, Routing und Deployment 429 zu viele Anfragen Rate-Limit und Last 500 interner Serverfehler Anwendungslog prüfen 502 ungültige Antwort vom Backend Backend-Erreichbarkeit und Proxy 503 Dienst nicht verfügbar Dienststatus, Wartung und Kapazität 504 Zeitüberschreitung zum Backend Backend-Laufzeit, Netzwerk und Timeout Ein 502 wird häufig am Reverse Proxy sichtbar, obwohl die eigentliche Ursache im Backenddienst liegt. Deshalb müssen Proxy- und Backend-Logs über Zeitstempel, Pfad und Korrelations-ID verbunden werden. 19. Wie werden Authentifizierungsfehler untersucht? Bei Anmeldeproblemen können mehrere Systeme beteiligt sein: Client → Anwendung → Reverse Proxy → Identitätsanbieter → Verzeichnisdienst → MFA-Dienst Zu erfassende Informationen exakter Zeitpunkt, Benutzerkennung, Client und Quell-IP, Zielanwendung, Authentifizierungsverfahren, verwendeter Identitätsanbieter, Korrelations- oder Request-ID, Fehlercode, Ergebnis einer Vergleichsanmeldung, mögliche Uhrzeitabweichung. Typische Ursachen Beobachtung Mögliche Untersuchungsrichtung Benutzer unbekannt falscher Mandant, falsche Domäne oder Synchronisation Kennwort abgelehnt falsches Kennwort, Kontosperre oder abgelaufenes Kennwort Token abgelaufen Zeitabweichung oder zu lange Sitzung Zertifikat ungültig Ablaufdatum, Vertrauenskette oder Hostname MFA fehlgeschlagen Endgerät, Push-Dienst oder Richtlinie Zugriff verweigert Rolle, Gruppe oder Conditional-Access-Regel LDAP nicht erreichbar DNS, Routing, Port, TLS oder Dienststatus Wiederholte Fehlversuche gespeicherte alte Zugangsdaten oder automatischer Dienst Authentifizierungsprotokolle enthalten besonders schützenswerte Informationen. Kennwörter, Tokens oder Cookies dürfen nicht in die Dokumentation kopiert werden. 20. Wie werden Meldungen verschiedener Systeme miteinander korreliert? Beispiel einer verteilten Anfrage 09:42:15.120 Client sendet Anfrage 09:42:15.145 Reverse Proxy nimmt Anfrage an 09:42:15.151 Backend beginnt Verarbeitung 09:42:20.152 Backend meldet Datenbank-Timeout 09:42:20.153 Reverse Proxy erhält keine gültige Antwort 09:42:20.154 Client erhält HTTP 504 Der 504 -Fehler auf dem Client ist hier eine Folge. Der erste technisch relevante Fehler ist der Datenbank-Timeout im Backend. Geeignete Korrelationsmerkmale Merkmal Nutzen Zeitstempel grobe zeitliche Zuordnung Request-ID eindeutige Anfrageverfolgung Trace-ID verteilte Ablaufverfolgung Session-ID Zuordnung zu einer Sitzung Benutzer-ID Zuordnung zu einem Konto Quell-IP Zuordnung zu einem Client Zielpfad Zuordnung zu einer Funktion Prozess-ID Zuordnung zu einem lokalen Prozess Transaktions-ID Zuordnung zu einem Geschäftsvorgang Korrelationsregel Gleiche Uhrzeit allein ist kein Beweis für denselben Vorgang. Je mehr Merkmale übereinstimmen, desto belastbarer ist die Zuordnung. 21. Wie wird nach Fehlercodes und Meldungen gesucht? Vor der Internetrecherche sollten folgende Angaben vollständig erfasst werden: Produktname, Produktversion, Betriebssystemversion, Provider oder Quelle, Ereignis-ID, vollständiger Fehlercode, genaue Fehlermeldung, betroffene Funktion, Zeitpunkt und Kontext. Gute Suchanfrage Microsoft-Windows-DNS-Client Event ID 1014 Windows 11 Ungenaue Suchanfrage Internet geht nicht Fehler Quellenreihenfolge offizielle Herstellerdokumentation, offizielle Knowledge Base oder Supportartikel, offizielle Quellcode-Repositories und Issue-Tracker, Dokumentation des eingesetzten Projekts, seriöse Fachquellen, Community-Beiträge als ergänzende Hinweise. Ein Community-Beitrag kann eine nützliche Hypothese liefern, ersetzt aber keine Prüfung am eigenen System. 22. Welche typischen Fehler werden bei der Log-Analyse gemacht? Fehler Folge Besseres Vorgehen Nur nach dem Wort error suchen relevante Warnungen und Statusmeldungen fehlen Dienst, Zeitfenster und Ereigniskette prüfen Nur das letzte Ereignis betrachten ursprüngliche Ursache wird übersehen zeitlich rückwärts zum ersten relevanten Fehler gehen Zeitzonen ignorieren Ereignisse werden falsch zugeordnet Zeit und UTC-Offset dokumentieren Gesamtes Log ungefiltert lesen relevante Ereignisse gehen in der Menge unter Zeitfenster und Quelle begrenzen Logs vor Sicherung löschen Beweise gehen verloren zuerst exportieren und Integrität sichern Debug-Logging dauerhaft aktivieren Speicherplatz- und Datenschutzprobleme kurzzeitig aktivieren und danach zurücksetzen Fehlermeldung isoliert suchen falsche Produkt- oder Versionslösung Quelle, Version und Kontext ergänzen Nur ein System prüfen verteilte Ursache bleibt verborgen alle beteiligten Systeme korrelieren Fehlerhäufigkeit nicht beachten Einzelereignis wird überbewertet Häufigkeit und Vergleichswerte prüfen Geheimnisse in Tickets kopieren Sicherheitsvorfall möglich Daten vor Weitergabe redigieren Logdatei während der Analyse verändern Beweiskraft sinkt Original sichern und Arbeitskopie verwenden Nur Fehlermeldungen berücksichtigen erfolgreicher Fallback wird übersehen gesamte Ereigniskette betrachten 23. Wie wird eine aussagekräftige Ereigniskette erstellt? Eine gute Ereigniskette enthält nicht sämtliche Logzeilen, sondern die für den Vorgang relevanten Ereignisse. Zeit System Quelle Ereignis Bedeutung 09:42:10.100 CLIENT-023 Anwendung Anfrage gestartet Benutzeraktion beginnt 09:42:10.130 PROXY-01 Nginx Anfrage angenommen Proxy ist erreichbar 09:42:10.150 APP-01 Backend DB-Abfrage gestartet Backend verarbeitet Anfrage 09:42:15.151 APP-01 Backend DB-Timeout erster belegter Fehler 09:42:15.152 PROXY-01 Nginx Upstream timeout Folgefehler 09:42:15.160 CLIENT-023 Anwendung HTTP 504 sichtbare Auswirkung Auswertung Symptom: Client erhält HTTP 504. Erster belegter Fehler: Datenbank-Timeout auf APP-01. Folgefehler: Reverse Proxy erhält keine rechtzeitige Backend-Antwort. Nächster Prüfschritt: Datenbankerreichbarkeit, Datenbanklast und Abfragedauer im Zeitraum 09:42:10 bis 09:42:15 untersuchen. 24. Kompakte Befehlsübersicht für Windows, Linux und macOS Aufgabe Windows Linux macOS Grafische Loganzeige öffnen [RO] eventvwr.msc abhängig von Desktop und Distribution [RO] open -a Console Neueste Systemereignisse [RO] Get-WinEvent -LogName System -MaxEvents 20 [RO] journalctl -n 20 [RO] log show --last 10m --style compact Aktuellen Start untersuchen Ereignis-IDs und Startzeit filtern [RO] journalctl -b [RO] log show --last boot --style compact Vorherigen Start untersuchen Systemprotokoll nach vorherigem Startzeitraum filtern [RO] journalctl -b -1 über Zeitfenster beziehungsweise Logarchiv Kernelmeldungen Systemprotokoll und providerspezifische Logs [RO] journalctl -k -b [RO] log show --last 1h --predicate 'process == "kernel"' Letzte Stunde Get-WinEvent mit StartTime=(Get-Date).AddHours(-1) [RO] journalctl --since "1 hour ago" [RO] log show --last 1h Dienstprotokoll nach Provider oder Dienstprotokoll filtern [RO] journalctl -u nginx.service nach process oder subsystem filtern Live-Anzeige Ereignisanzeige oder providerspezifisch [RO] journalctl -f [RO] log stream --style compact Fehler filtern Get-WinEvent mit Level=1,2 [RO] journalctl -p err Predicate nach Prozess, Typ oder Meldung Textdatei lesen [RO] Get-Content .\app.log [RO] less /var/log/app.log [RO] less /Pfad/app.log Letzte 50 Zeilen [RO] Get-Content .\app.log -Tail 50 [RO] tail -n 50 /var/log/app.log [RO] tail -n 50 /Pfad/app.log Datei live verfolgen [RO] Get-Content .\app.log -Wait -Tail 50 [RO] tail -F /var/log/app.log [RO] tail -F /Pfad/app.log Text suchen [RO] Select-String -Path .\app.log -Pattern 'error' [RO] grep -i 'error' /var/log/app.log [RO] grep -i 'error' /Pfad/app.log Komprimiertes Log lesen abhängig vom Archivformat [RO] zless /var/log/app.log.2.gz [RO] gzcat /Pfad/app.log.gz | less Ereignisse exportieren [FILE][SENS] wevtutil epl System C:\Temp\System.evtx [FILE][SENS] journalctl --since today > journal.txt [FILE][SENS] log show --last 1h > macos-log.txt Containerlogs [RO][SENS] docker logs --tail 100 NAME [RO][SENS] docker logs --tail 100 NAME [RO][SENS] docker logs --tail 100 NAME log show --last boot kann je nach eingesetzter macOS-Version beziehungsweise Werkzeugsyntax nicht verfügbar sein. Die lokal unterstützten Optionen sind mit log help show zu prüfen. Ein festes Zeitfenster mit --start und --end ist die eindeutigere Alternative. 25. Dokumentationsvorlage für eine Log-Analyse Ticketnummer: Analysedatum: Betroffenes System: Betriebssystem: Anwendung oder Dienst: Anwendungsversion: Betroffener Benutzer: Fehlerbeschreibung: Fehlerzeitpunkt: Zeitzone: Letzter funktionierender Zeitpunkt: Reproduzierbar: Ja / Nein Untersuchte Protokolle: - - - Verwendete Filter: - Zeitraum: - Quelle/Provider: - Ereignis-ID: - Prozess/PID: - Dienst/Unit: - Benutzer/UID: - Korrelations-ID: - Suchbegriffe: Erster relevanter Fehler: Zeitpunkt: System: Quelle: Ereignis-ID oder Fehlercode: Vollständige Meldung: Vorhergehende Ereignisse: - - - Nachfolgende Ereignisse: - - - Ereigniskette: 1. 2. 3. 4. Arbeitshypothese: Begründung: Kontrollierter Test: Testergebnis: Ermittelte Ursache: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Gesicherte Dateien: - EVTX: - Journal: - Textlog: - CSV: - Diagnosearchiv: Original unverändert gesichert: Ja / Nein Sensible Daten redigiert: Ja / Nein Speicherort: Zugriffsberechtigung: Aufbewahrungs- oder Löschfrist: 26. Offizielle Quellen und weiterführende Dokumentation Microsoft Get-WinEvent – Microsoft Learn wevtutil – Microsoft Learn Windows-Ereignisprotokollierung – Microsoft Learn Linux und systemd journalctl – systemd-Dokumentation systemctl – systemd-Dokumentation systemd-journald – systemd-Dokumentation systemd Journal Fields Apple Konsole – Benutzerhandbuch für macOS Protokollmeldungen in der Konsole anzeigen Protokollmeldungen und Aktivitäten suchen Lokale Befehlsreferenz: man log und log help Docker docker logs – Docker-Dokumentation Docker Logging Drivers docker compose logs Befehlsoptionen, Protokollpfade und verfügbare Felder können von Betriebssystem-, Distributions- und Anwendungsversion abhängen. Vor dem produktiven Einsatz ist deshalb zusätzlich die lokale Hilfeseite des konkreten Systems zu prüfen. 2.13 Monitoringdaten und Leistungswerte richtig interpretieren Monitoring erfasst den Zustand von Systemen und Diensten über einen längeren Zeitraum. Im Gegensatz zu einer einzelnen Momentaufnahme zeigt es Entwicklungen, wiederkehrende Muster und Zusammenhänge zwischen verschiedenen Messwerten. Monitoringdaten helfen unter anderem bei folgenden Fragen: Wann begann eine Leistungsverschlechterung? Ist ein Problem dauerhaft, periodisch oder nur kurzfristig? Welche Ressource ist ausgelastet oder überlastet? Betrifft die Störung einen einzelnen Host oder mehrere Systeme? Tritt das Problem nur zu bestimmten Tageszeiten auf? Gab es unmittelbar vorher ein Update, Deployment oder Backup? Steigt die Fehlerrate gleichzeitig mit der Antwortzeit? Wird eine technische Auffälligkeit von Benutzern tatsächlich wahrgenommen? Entwickelt sich ein Wert langsam in Richtung eines Kapazitätsproblems? Fehlen Messwerte, weil der Zielhost oder nur das Monitoring ausgefallen ist? Grundregel: Ein einzelner hoher Messwert beweist noch keine Ursache. Entscheidend sind Verlauf, Dauer, Vergleichswerte, Benutzerwirkung und die Korrelation mit anderen Signalen. 1. Kennzeichnungen und Sicherheitsregeln Kennzeichnung Bedeutung [RO] Liest Informationen aus, ohne den Zustand absichtlich zu verändern [TEST] Führt eine aktive Messung durch oder erzeugt zusätzliche Last [PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte [FILE] Erzeugt oder verändert eine Datei [SENS] Ausgabe kann vertrauliche Daten enthalten [CHANGE] Verändert Einstellungen oder den Systemzustand [DISRUPT] Kann Dienste oder Systeme beeinträchtigen Monitoringdaten können vertrauliche Informationen enthalten: Hostnamen und IP-Adressen, Benutzer- und Prozessnamen, interne URLs und Dienstbezeichnungen, Standort- und Kundenzuordnungen, Kapazitäts- und Auslastungsdaten, Datenbank- und Mandantennamen, Informationen über Sicherheits- und Netzwerkinfrastruktur. Dashboards, Exporte und Screenshots dürfen deshalb nur kontrolliert weitergegeben werden. 2. Was ist der Unterschied zwischen Monitoring und Observability? Begriff Bedeutung Monitoring Erfasst vorher festgelegte Zustände und Messwerte Logging Dokumentiert einzelne Ereignisse und Meldungen Metriken Numerische Werte über einen Zeitraum Tracing Verfolgt eine Anfrage durch mehrere Komponenten Observability Ermöglicht, den internen Systemzustand aus Metriken, Logs und Traces abzuleiten Alerting Meldet definierte Zustände oder Abweichungen Dashboard Visualisiert ausgewählte Messwerte Profiling Untersucht, wo ein Programm Rechenzeit oder Speicher verwendet Zusammenhang Metrik zeigt: Die Antwortzeit ist seit 09:42 Uhr erhöht. Log zeigt: Datenbankabfragen laufen in ein Timeout. Trace zeigt: Die Verzögerung entsteht im Datenbankzugriff. Profiling zeigt: Eine bestimmte Funktion erzeugt besonders teure Abfragen. Monitoring zeigt häufig, dass ein Problem besteht. Logs, Traces und weitere Diagnosewerkzeuge helfen anschließend festzustellen, warum es besteht. 3. Wie wird eine Baseline erstellt? Eine Baseline beschreibt den normalen Zustand eines Systems unter vergleichbaren Bedingungen. Sinnvolle Vergleichszeiträume sind beispielsweise: gleicher Wochentag der Vorwoche, gleiche Uhrzeit an mehreren Werktagen, Zeitraum vor einem Update, Zeitraum mit ähnlicher Benutzerzahl, funktionierendes Referenzsystem, Normalbetrieb außerhalb eines Backups, typischer Monats- oder Quartalsverlauf. Beispiel Messwert Normalbetrieb Störungszeitraum CPU-Auslastung 25–45 % 85–100 % Antwortzeit p95 180–260 ms 3.800 ms Fehlerrate 0,2 % 12 % Datenbankverbindungen 20–35 100 Datenträgerlatenz 2–8 ms 140 ms Anfragen pro Sekunde 100–140 110 Da die Anfragemenge nahezu unverändert ist, die Antwortzeit, Fehlerrate und Datenträgerlatenz aber stark gestiegen sind, sollte die Untersuchung auf Datenträger und Datenbank konzentriert werden. Eine sinnvolle Baseline berücksichtigt: Tages- und Wochenmuster, Geschäftszeiten, Backups und Wartungsfenster, geplante Batch-Verarbeitung, saisonale Last, unterschiedliche Hardware, unterschiedliche Softwareversionen, Anzahl der Benutzer oder Anfragen. Ein Grenzwert ohne Baseline ist häufig willkürlich. 4. Welche Arten von Metriken gibt es? Metriktyp Verhalten Beispiel Counter steigt normalerweise an und kann bei Neustart zurückgesetzt werden Gesamtzahl der HTTP-Anfragen Gauge kann steigen und fallen aktuelle Speichernutzung Histogram zählt Beobachtungen in Wertebereichen Verteilung von Antwortzeiten Summary berechnet Beobachtungen und Quantile clientseitig Antwortzeitquantile Rate Änderung eines Counters pro Zeiteinheit Fehler pro Sekunde Ratio Verhältnis zweier Werte Fehleranteil an allen Anfragen Counter requests_total = 150000 Der Gesamtwert ist für eine aktuelle Belastung meist weniger aussagekräftig als seine Änderungsrate. PromQL-Beispiel: rate(http_requests_total[5m]) Gauge active_connections = 42 Der Wert beschreibt den aktuellen Zustand und kann steigen oder fallen. PromQL-Beispiele: avg_over_time(active_connections[15m]) max_over_time(active_connections[15m]) Fehlerrate berechnen sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) Für eine Prozentdarstellung: 100 * sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) rate() ist für Counter vorgesehen. Auf einen Gauge angewendet würde die Abfrage inhaltlich meist keinen sinnvollen Messwert ergeben. 5. Welche Messstrategien eignen sich für Infrastruktur und Dienste? USE-Methode für Ressourcen Buchstabe Bedeutung Fragestellung U Utilization Wie stark wird die Ressource verwendet? S Saturation Gibt es Warteschlangen oder Rückstau? E Errors Treten Fehler auf? Beispiel für einen Datenträger: USE-Bereich Messwert Utilization aktive Zeit des Datenträgers Saturation Warteschlangenlänge Errors I/O-Fehler und Timeouts RED-Methode für Dienste Buchstabe Bedeutung Fragestellung R Rate Wie viele Anfragen werden verarbeitet? E Errors Wie viele Anfragen schlagen fehl? D Duration Wie lange dauert die Verarbeitung? Golden Signals Signal Bedeutung Latency Dauer einer Anfrage Traffic aktuelle Nutzung oder Anfragemenge Errors fehlgeschlagene Operationen Saturation Annäherung an eine Kapazitätsgrenze USE hilft besonders bei der Untersuchung technischer Ressourcen. RED und die Golden Signals zeigen stärker die tatsächliche Benutzerwirkung. 6. Wie werden Durchschnitt, Maximum und Perzentile interpretiert? Beispiel für zehn Antwortzeiten 100, 110, 115, 120, 125, 130, 140, 150, 200, 5000 ms Der Durchschnitt wird durch den einzelnen sehr langsamen Wert deutlich beeinflusst. Gleichzeitig kann ein Durchschnitt die Verteilung und einzelne besonders langsame Anfragen verbergen. Kennzahl Aussage Minimum kleinster gemessener Wert Maximum größter gemessener Wert Durchschnitt arithmetischer Mittelwert Median beziehungsweise p50 50 % der Werte liegen höchstens hier p90 90 % der Werte liegen höchstens hier p95 95 % der Werte liegen höchstens hier p99 99 % der Werte liegen höchstens hier Beispiel p50 = 120 ms p95 = 800 ms p99 = 4.500 ms Interpretation: Die typische Anfrage ist schnell. Ein kleinerer Anteil der Anfragen ist deutlich langsamer. Der Durchschnitt allein würde das Benutzerproblem möglicherweise verbergen. Wichtig: Ein Perzentil ist kein Prozentwert der Auslastung. p95 bedeutet nicht, dass 95 % der Anfragen fehlerhaft sind. Perzentile verschiedener Gruppen dürfen nicht ohne Weiteres gemittelt werden. Bei sehr wenigen Messwerten können hohe Perzentile wenig belastbar sein. Erfolgreiche und fehlgeschlagene Anfragen sollten gegebenenfalls getrennt betrachtet werden. 7. Wie wird CPU-Auslastung richtig interpretiert? Hohe CPU-Auslastung bedeutet zunächst nur, dass Rechenzeit verwendet wird. Sie kann sowohl normal als auch problematisch sein. Zu prüfende Fragen Betrifft die Auslastung einen einzelnen Kern oder alle Kerne? Welcher Prozess verursacht sie? Ist die Auslastung nur kurzzeitig oder dauerhaft? Steigt gleichzeitig die Antwortzeit? Gibt es eine CPU-Warteschlange? Entsteht die Last im Benutzer-, Kernel- oder Interrupt-Kontext? Ist die CPU tatsächlich ausgelastet oder wartet das System auf I/O? Wird die CPU durch Virtualisierung oder Container begrenzt? Tritt Drosselung durch Temperatur oder Leistungsgrenzen auf? Typische CPU-Zustände unter Linux Zustand Bedeutung us Zeit für Benutzerprozesse sy Zeit im Kernel id Leerlauf wa Warten auf I/O st Zeit, die einer VM durch den Hypervisor entzogen wurde hi Hardware-Interrupts si Software-Interrupts Beispiele Beobachtung Untersuchungsrichtung hohes us Anwendungsprozess, Berechnung oder Schleife hohes sy Kernel, Treiber, Systemaufrufe oder Netzwerk hohes wa Datenträger oder anderes blockierendes I/O hohes st in VM Überbelegung oder Belastung des Hypervisors hohe Interruptlast Netzwerkadapter, Treiber oder Hardware ein Kern bei 100 % möglicherweise einzelner nicht parallelisierter Thread Windows [RO] Get-Counter '\Processor(_Total)\% Processor Time' Alle logischen Prozessoren: [RO] Get-Counter '\Processor(*)\% Processor Time' Prozessbezogene CPU-Werte: [RO] Get-Counter '\Process(*)\% Processor Time' Mehrere Messungen im Abstand von zwei Sekunden: [RO] Get-Counter '\Processor(_Total)\% Processor Time' ` -SampleInterval 2 ` -MaxSamples 10 Linux [RO] uptime [RO] top [RO] vmstat 1 10 Falls sysstat installiert ist: [RO] mpstat -P ALL 1 10 Prozesse nach CPU-Auslastung sortieren: [RO] ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head macOS [RO] top -l 1 -o cpu [RO] ps -Ao pid,ppid,user,%cpu,%mem,comm -r | head Eine kurzzeitige CPU-Auslastung von 100 % ist nicht automatisch ein Problem. Kritisch wird sie insbesondere dann, wenn sie länger anhält, Warteschlangen erzeugt und gleichzeitig die Antwortzeit oder Fehlerrate steigt. 8. Was bedeutet Load Average unter Linux und macOS? Load Average wird typischerweise für die letzten 1, 5 und 15 Minuten angezeigt: [RO] uptime Beispiel: load average: 8.20, 6.10, 3.40 Die Werte sind keine Prozentwerte. Unter Linux umfasst die Last unter anderem ausführbare beziehungsweise auf CPU wartende Tasks und Tasks in nicht unterbrechbarem Wartezustand, beispielsweise bei bestimmten I/O-Vorgängen. Logische CPUs bestimmen Linux: [RO] nproc macOS: [RO] sysctl -n hw.logicalcpu Vereinfachtes Beispiel 8 logische CPUs Load Average 1 Minute: 8 Das kann bedeuten, dass die ausführbaren Kapazitäten ungefähr vollständig beansprucht sind. Die genaue Bewertung erfordert jedoch zusätzliche Informationen. 8 logische CPUs Load Average 1 Minute: 16 Das deutet auf mehr gleichzeitig wartende oder nicht unterbrechbar blockierte Tasks hin, als unmittelbar abgearbeitet werden können. Wichtige Einschränkungen Load Average ist nicht gleich CPU-Auslastung. I/O-Wartezustände können die Load erhöhen. Container sehen je nach Konfiguration Host- oder begrenzte Ressourcen. CPU-Quotas und virtuelle CPUs müssen berücksichtigt werden. Ein Wert ist nur im Verhältnis zur verfügbaren Kapazität sinnvoll. 9. Wie wird Arbeitsspeicher richtig interpretiert? Ein fast vollständig belegter physischer Arbeitsspeicher bedeutet nicht automatisch Speichermangel. Betriebssysteme verwenden freien Speicher unter anderem als Cache. Wichtiger als der reine Wert „belegt“ sind: verfügbarer Speicher, Speicherdruck, Paging- beziehungsweise Swap-Aktivität, Commit-Nutzung, OOM-Ereignisse, Entwicklung des Prozessspeichers, Antwortzeit des Systems. Begriffe Begriff Bedeutung Physical Memory tatsächlich vorhandener RAM Available kurzfristig für Anwendungen verfügbarer Speicher Cache für schnellere Zugriffe verwendeter Speicher Working Set aktuell im RAM befindliche Seiten eines Prozesses Private Bytes nur einem Prozess zugeordneter zugesicherter Speicher Commit zugesicherter virtueller Speicher Pagefile beziehungsweise Swap Auslagerungsspeicher Page Fault Zugriff auf nicht aktuell passend zugeordnete Speicherseite Hard Page Fault benötigte Seite muss aus Datei oder Auslagerung geladen werden Viele Page Faults sind normal. Erst eine anhaltend hohe Rate teurer Datenträgerzugriffe zusammen mit Speicherdruck und schlechter Leistung ist ein deutlicher Problemhinweis. Windows [RO] Get-Counter '\Memory\Available MBytes' [RO] Get-Counter '\Memory\% Committed Bytes In Use' [RO] Get-Counter '\Memory\Pages/sec' Prozesse nach Arbeitsspeichernutzung: [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, @{Name='WorkingSetMiB';Expression={ [math]::Round($_.WorkingSet64 / 1MB, 1) }} Linux [RO] free -h [RO] vmstat 1 10 Prozesse nach Speicheranteil: [RO] ps -eo pid,user,%mem,rss,vsz,comm --sort=-%mem | head OOM-Ereignisse suchen: [RO][PRIV] sudo journalctl -k | grep -Ei 'out of memory|oom-killer|killed process' macOS [RO] memory_pressure [RO] vm_stat [RO] top -l 1 -o mem Hinweise auf ein mögliches Speicherproblem verfügbarer Speicher bleibt sehr niedrig, Swap- oder Paging-Aktivität ist dauerhaft hoch, Speicherdruck steigt, Anwendungen reagieren gleichzeitig langsamer, ein Prozess wächst ohne Rückgang weiter, der OOM-Killer beendet Prozesse, Commit nähert sich dauerhaft der Grenze. 10. Wie werden Datenträgerauslastung und I/O-Latenz interpretiert? Zu einer Datenträgeranalyse gehören mindestens: Durchsatz, Ein- und Ausgabeoperationen pro Sekunde, Latenz, Warteschlangen, Auslastungsgrad, Fehler und Timeouts, freier Speicherplatz. Messwert Aussage IOPS Anzahl der Operationen pro Sekunde Throughput übertragene Datenmenge pro Sekunde Latency Dauer einer Operation Queue Length wartende oder laufende I/O-Anfragen Utilization Anteil der aktiven Messzeit Free Space verfügbarer Speicherplatz Errors fehlerhafte oder abgebrochene Operationen Hohe IOPS sind nicht automatisch problematisch. Ein Speichersystem kann viele kleine Operationen oder wenige große Übertragungen verarbeiten. Entscheidend ist, ob Latenz und Warteschlange unter der aktuellen Last steigen. Windows [RO] Get-Counter '\PhysicalDisk(*)\% Disk Time' [RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read' [RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write' [RO] Get-Counter '\PhysicalDisk(*)\Current Disk Queue Length' [RO] Get-Counter '\PhysicalDisk(*)\Disk Reads/sec' [RO] Get-Counter '\PhysicalDisk(*)\Disk Writes/sec' Freien Speicherplatz prüfen: [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, SizeRemaining, Size Windows Performance Counter für Avg. Disk sec/Read und Avg. Disk sec/Write werden in Sekunden ausgegeben. 0,020 entspricht 20 Millisekunden. Linux [RO] df -hT [RO] df -i Falls sysstat installiert ist: [RO] iostat -xz 1 10 Prozessbezogene I/O-Werte: [RO] pidstat -d 1 10 Kernelmeldungen zu I/O-Fehlern: [RO][PRIV] sudo journalctl -k | grep -Ei 'I/O error|timeout|reset|read-only|filesystem' macOS [RO] df -h [RO] iostat -w 1 -c 10 Typische Fehlinterpretationen Beobachtung Fehlinterpretation Datenträger zu 100 % aktiv maximale Datenübertragungsrate erreicht wenig Durchsatz Datenträger ist nicht belastet hoher Durchsatz Datenträger ist überlastet voller Speicherplatz einzige mögliche Ursache ist Datenmenge hohe Latenz physischer Datenträger ist zwingend defekt Ein Datenträger kann bei kleinen zufälligen Zugriffen vollständig beschäftigt sein, obwohl der Datendurchsatz gering bleibt. 11. Wie werden Netzwerkmesswerte interpretiert? Wichtige Netzwerkmesswerte: Messwert Bedeutung Bandbreite theoretische oder konfigurierte Übertragungskapazität Throughput tatsächlich übertragene Datenmenge Utilization genutzter Anteil der Kapazität Packets per Second Pakete pro Sekunde Errors fehlerhafte Frames oder Pakete Discards/Drops verworfene Pakete Retransmissions erneut übertragene TCP-Segmente Latency Laufzeit einer Übertragung Jitter Schwankung der Laufzeit Packet Loss Anteil verlorener Pakete Connections Anzahl aktiver Verbindungen Windows [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress Adapterstatistiken: [RO] Get-NetAdapterStatistics Performance Counter: [RO] Get-Counter '\Network Interface(*)\Bytes Total/sec' [RO] Get-Counter '\TCPv4\Segments Retransmitted/sec' Linux [RO] ip -s link [RO] ss -s [RO] cat /proc/net/dev TCP-Statistik: [RO] nstat Treiber- und Adapterstatistiken: [RO][PRIV] sudo ethtool -S eth0 macOS [RO] netstat -ib [RO] netstat -s [RO] ifconfig Zusammenhänge Beobachtung Mögliche Untersuchungsrichtung steigende RX-Errors Kabel, Transceiver, Port, Duplex oder Hardware steigende Drops ohne Linkfehler Puffer, CPU, Treiber oder Überlastung viele TCP-Retransmissions Paketverlust, Überlastung oder instabile Verbindung hohe Latenz ohne Paketverlust Warteschlangen, Routing oder überlasteter Dienst Bandbreite dauerhaft nahe Kapazität Kapazitätsengpass möglich geringe Bandbreitennutzung und hohe Antwortzeit Problem möglicherweise in Anwendung oder Zielsystem nur ein Client betroffen lokales Interface, WLAN, Treiber oder Clientkonfiguration alle Clients betroffen gemeinsamer Pfad, Dienst oder Upstream Zähler sollten mindestens zweimal gemessen werden. Ein seit dem Systemstart aufgelaufener Fehlerzähler ist ohne zeitliche Änderung nur begrenzt aussagekräftig. 12. Wie werden Latenz, Jitter und Paketverlust gemessen? Erreichbarkeit und Round-Trip-Time Aufgabe Windows Linux macOS vier ICMP-Anfragen [TEST] ping ziel.example [TEST] ping -c 4 ziel.example [TEST] ping -c 4 ziel.example fortlaufender Ping [TEST] ping -t ziel.example [TEST] ping ziel.example [TEST] ping ziel.example Route prüfen [TEST] tracert ziel.example [TEST] traceroute ziel.example [TEST] traceroute ziel.example kombinierte Pfadanalyse [TEST] pathping ziel.example [TEST] mtr ziel.example [TEST] mtr ziel.example Nicht jedes System beantwortet ICMP-Anfragen. Ein fehlgeschlagener Ping beweist daher nicht, dass der eigentliche Dienst nicht erreichbar ist. Anwendungsnahe HTTPS-Messung Windows, Linux und macOS: [TEST] curl -o /dev/null -sS \ -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nGesamt: %{time_total}\n' \ https://example.com/ curl-Wert Bedeutung time_namelookup Dauer bis zum Abschluss der Namensauflösung time_connect Dauer bis zur TCP-Verbindung time_appconnect Dauer bis zum Abschluss von TLS time_starttransfer Zeit bis zum ersten Antwortbyte time_total Gesamtdauer Interpretationsbeispiel DNS: 0,010 s TCP: 0,030 s TLS: 0,080 s TTFB: 3,500 s Gesamt: 3,510 s DNS, TCP und TLS sind schnell. Die lange Zeit bis zum ersten Byte weist eher auf Verarbeitung im Server oder Backend hin. 13. Was bedeutet Sättigung und wie wird sie erkannt? Auslastung und Sättigung sind nicht dasselbe. Auslastung: Wie stark wird eine Ressource verwendet? Sättigung: Wie viel Arbeit muss warten, weil die Ressource nicht sofort verfügbar ist? Beispiele Ressource Auslastung Sättigung CPU CPU-Zeit in Prozent ausführbare Warteschlange RAM belegter Speicher Speicherdruck und Paging Datenträger aktive Zeit I/O-Warteschlange Netzwerk übertragene Bitrate Drops und Warteschlangen Datenbank aktive Verbindungen wartende Abfragen Threadpool aktive Threads wartende Tasks Connection Pool belegte Verbindungen wartende oder abgewiesene Anfragen Ein System kann noch unter 100 % Auslastung liegen und trotzdem bereits Verzögerungen aufweisen. Linux Pressure Stall Information Wenn vom Kernel unterstützt: [RO] cat /proc/pressure/cpu [RO] cat /proc/pressure/memory [RO] cat /proc/pressure/io Beispiel: some avg10=4.20 avg60=2.10 avg300=0.80 total=1234567 full avg10=1.00 avg60=0.40 avg300=0.10 total=234567 Feld Bedeutung some mindestens einige Tasks waren durch die Ressource blockiert full alle nicht untätigen Tasks waren gleichzeitig blockiert avg10 durchschnittlicher Zeitanteil der letzten 10 Sekunden avg60 durchschnittlicher Zeitanteil der letzten 60 Sekunden avg300 durchschnittlicher Zeitanteil der letzten 300 Sekunden total gesamte Stall-Zeit in Mikrosekunden seit dem Start PSI misst den Zeitverlust durch Ressourcenknappheit und ergänzt reine Auslastungswerte. 14. Wie werden virtuelle Maschinen und Container richtig bewertet? Bei virtuellen Systemen existieren mehrere Messebenen: Physischer Host → Hypervisor → virtuelle Maschine → Container → Anwendung Ein Wert innerhalb eines Containers zeigt nicht zwingend die vollständige Situation des Hosts. Zu prüfen zugewiesene virtuelle CPUs, CPU-Limits und CPU-Quotas, Arbeitsspeicherlimit, Swap-Konfiguration, Hypervisor-Überbelegung, Storage-Latenz des Hosts, gemeinsam genutzte Netzwerkressourcen, Container-Restarts, OOM-Beendigungen, Ressourcenreservierungen. Docker-Ressourcen anzeigen [RO] docker stats --no-stream Nur ausgewählte Spalten: [RO] docker stats --no-stream \ --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}' Containerstatus prüfen: [RO] docker ps -a Konfigurierte Limits eines Containers untersuchen: [RO][SENS] docker inspect beispiel-container OOM-Status prüfen: [RO] docker inspect \ --format '{{.Name}} OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}' \ beispiel-container Wichtige Grenzen Die CPU-Prozentdarstellung kann sich auf mehrere Kerne beziehen. Ein Container kann vom Host gedrosselt werden. Host-Caches beeinflussen die wahrgenommene Speicherbelegung. Container-I/O kann durch andere Workloads auf demselben Storage beeinflusst werden. Ein Neustart setzt bestimmte Anwendungszähler zurück. 15. Wie werden fehlende oder veraltete Messwerte erkannt? Keine Daten bedeuten nicht automatisch, dass alles in Ordnung ist. Mögliche Ursachen: Zielsystem ist ausgefallen, Exporter oder Agent läuft nicht, Netzwerkverbindung ist unterbrochen, Firewall blockiert die Abfrage, Monitoringserver ist gestört, Authentifizierung ist fehlgeschlagen, Zeitstempel liegen außerhalb des Abfragefensters, Metrik wurde umbenannt, Ziel wurde aus der Konfiguration entfernt, Abfrage ist fehlerhaft, Dashboardvariable filtert alle Werte heraus. Prometheus-Verfügbarkeit eines Targets up Nur nicht erfolgreich abgefragte Targets: up == 0 Fehlende Zeitreihe erkennen: absent(up{job="beispiel"}) Metriken ohne aktuelle Stichprobe können veraltet sein. Deshalb müssen folgende Zeitpunkte unterschieden werden: Zeitpunkt der Messung, Zeitpunkt der Übertragung, Zeitpunkt der Speicherung, Zeitpunkt der Dashboardabfrage, Zeitpunkt der Alarmauswertung. Prüfreihenfolge Zeitbereich des Dashboards prüfen. Zeitpunkt des letzten Datenpunkts prüfen. Target- oder Agentstatus kontrollieren. Datenquelle direkt abfragen. Netzwerkverbindung zwischen Monitoring und Ziel prüfen. Konfigurationsänderungen kontrollieren. Monitoringfehler getrennt vom überwachten Dienst bewerten. 16. Wie werden sinnvolle Schwellenwerte festgelegt? Ein sinnvoller Schwellenwert basiert auf: normalem Verlauf, Benutzerwirkung, technischer Kapazität, Dauer der Überschreitung, Wachstumsrate, Tages- und Wochenmuster, Wartungsfenstern, genügend Reaktionszeit, Erfahrungen aus früheren Störungen. Ungeeignete Regel CPU > 80 % → sofort kritischer Alarm Bessere Regelidee CPU-Auslastung über 90 % für mindestens 15 Minuten UND Antwortzeit p95 über dem vereinbarten Zielwert Beispiel für mehrstufige Grenzwerte Zustand Bedingung Reaktion Information ungewöhnlicher Trend ohne Auswirkung Dashboard beobachten Warnung Grenzwert länger überschritten während Betriebszeit untersuchen Kritisch Benutzerwirkung oder unmittelbarer Ausfall sofortige Bearbeitung Kapazitätswarnung prognostizierte Erschöpfung in 14 Tagen Kapazität planen Hysterese Unterschiedliche Ein- und Ausschaltschwellen verhindern, dass ein Alarm ständig wechselt. Alarm aktivieren: Wert über 90 % Alarm beenden: Wert unter 80 % Pending Period Eine Bedingung muss für eine festgelegte Dauer bestehen, bevor der Alarm ausgelöst wird. CPU > 90 % für 10 Minuten Dadurch führen kurze Lastspitzen nicht sofort zu einem Alarm. 17. Was sind Flapping und Alert Fatigue? Flapping Ein Alarm wechselt häufig zwischen aktiv und normal: 09:00 Alarm 09:01 behoben 09:02 Alarm 09:03 behoben Mögliche Gegenmaßnahmen: längeres Auswertungsfenster, Pending Period, Hysterese, gleitender Durchschnitt, sinnvollere Schwellenwerte, getrennte Warn- und Kritisch-Stufen. Alert Fatigue Zu viele oder nicht relevante Meldungen führen dazu, dass wichtige Alarme übersehen werden. Typische Ursachen: Alarm bei jeder kurzen Lastspitze, mehrere Meldungen für dieselbe Ursache, fehlende Zuständigkeit, keine Handlungsmöglichkeit, falsche Priorität, keine Wartungsfenster, unklare Meldung, nicht gepflegte Regeln. Ein guter Alarm beantwortet: Was ist betroffen? Welche Benutzerwirkung besteht? Seit wann besteht das Problem? Welcher Messwert löste den Alarm aus? Wie lange besteht die Bedingung? Wer ist zuständig? Welches Dashboard und Runbook gehören dazu? Welche ersten Prüfungen sind erforderlich? Wenn aus einer Meldung keine sinnvolle Handlung folgt, eignet sie sich möglicherweise besser für ein Dashboard als für eine Alarmierung. 18. Wie werden Dashboards bei einer Störung gelesen? Empfohlene Reihenfolge Zeitfenster auf den Störungszeitraum einstellen. Zeitzone des Dashboards prüfen. Zeitpunkt einer gemeldeten Störung markieren. Benutzerorientierte Signale prüfen: Verfügbarkeit, Antwortzeit, Fehlerrate, Anfragemenge. Technische Ressourcen prüfen: CPU, RAM, Datenträger, Netzwerk. Deployments, Updates und Wartungsereignisse einblenden. Betroffene Instanzen mit funktionierenden Instanzen vergleichen. Zeitfenster vor und nach dem Ereignis betrachten. Rohdaten oder detailliertere Ansicht öffnen. Hypothese anhand von Logs oder Traces prüfen. Zoomfehler vermeiden Ein Wert kann je nach gewähltem Zeitraum unterschiedlich wirken: 24-Stunden-Ansicht: kurzer, kaum sichtbarer Ausschlag 5-Minuten-Ansicht: deutliche Lastspitze von drei Minuten Umgekehrt kann ein extrem kurzes Zeitfenster einen normalen Ausschlag dramatischer erscheinen lassen, als er im Betriebszusammenhang ist. Zu prüfen automatische Aggregation, Abfrageintervall, Datenauflösung, Mittelwert oder Maximum, ausgeblendete Datenreihen, verwendete Einheit, logarithmische oder lineare Achse, Beginn der Y-Achse, lokale Zeit oder UTC. 19. Wie werden typische Messwertkombinationen interpretiert? Beobachtung Mögliche Richtung Nächster Prüfschritt CPU hoch, Antwortzeit normal erwartete Verarbeitung Kapazitätsreserve und Dauer prüfen CPU hoch, Antwortzeit hoch CPU-Engpass möglich Prozess, Threads und Run Queue prüfen CPU niedrig, Load hoch I/O-Wartezustände möglich vmstat , iostat und PSI prüfen RAM belegt, Available ausreichend möglicherweise normaler Cache Paging und Speicherdruck prüfen RAM knapp, Swap steigt Speicherdruck Prozesse und Wachstum untersuchen Datenträger aktiv, Latenz niedrig hohe, aber verarbeitbare Last Warteschlange und Trend prüfen Datenträger aktiv, Latenz hoch I/O-Engpass möglich Prozess-I/O und Storage prüfen Netzwerkdurchsatz hoch, keine Fehler möglicherweise normale Übertragung Kapazität und Anwendungskontext Retransmissions steigen Paketverlust möglich Interfacefehler und Pfad prüfen Antwortzeit hoch, Ressourcen normal externe Abhängigkeit möglich Traces, DNS und Backenddienste Fehlerquote hoch, Traffic normal Funktions- oder Backendfehler Logs und Deployments prüfen Traffic steigt, Fehler und Latenz steigen Kapazitätsgrenze möglich Sättigung und Skalierung prüfen Messwerte verschwinden Monitoring- oder Zielausfall Target, Agent und Datenquelle prüfen nur eine Instanz auffällig lokales Problem Konfiguration und Host vergleichen alle Instanzen gleichzeitig auffällig gemeinsame Abhängigkeit Datenbank, Netzwerk und Deployment Diese Kombinationen sind Ausgangspunkte für Hypothesen und keine automatischen Ursachenfeststellungen. 20. Praxisfall – Anwendung ist zu bestimmten Zeiten langsam Ausgangslage Benutzer melden täglich zwischen 02:00 und 02:30 Uhr lange Antwortzeiten. Vorgehen Benutzerwirkung mit p95- oder p99-Antwortzeit bestätigen. Anfragerate und Fehlerrate im selben Zeitraum prüfen. CPU-, RAM-, Datenträger- und Netzwerkverlauf vergleichen. Geplante Aufgaben und Backups prüfen. Datenbankverbindungen und Abfragedauer kontrollieren. Logs nach Timeouts und Warteschlangen durchsuchen. Mit einem störungsfreien Zeitraum vergleichen. Abhängigkeiten und Storage überprüfen. Ursache durch kontrollierte zeitliche oder technische Änderung testen. Ergebnis über mehrere Tage beobachten. Beispiel einer Korrelation 02:00 Uhr: Backup beginnt 02:02 Uhr: Datenträgerlatenz steigt 02:03 Uhr: Datenbankabfragen werden langsamer 02:04 Uhr: Antwortzeit p95 steigt 02:05 Uhr: erste HTTP-Timeouts 02:30 Uhr: Backup endet 02:32 Uhr: Werte normalisieren sich Diese zeitliche Kette ist ein starker Hinweis, aber die Hypothese muss durch einen kontrollierten Test bestätigt werden. 21. Praxisfall – freier Speicherplatz nimmt kontinuierlich ab Erforderliche Messwerte aktueller freier Speicherplatz, Änderungsrate pro Stunde oder Tag, betroffene Partition beziehungsweise Volume, größte Verzeichnisse, Logwachstum, temporäre Dateien, Datenbank- und Backupwachstum, Zeitpunkt der voraussichtlichen Erschöpfung. Windows [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, SizeRemaining, Size Größte Dateien in einem bekannten Untersuchungsverzeichnis: [RO][SENS] Get-ChildItem 'C:\Logs' -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 20 FullName, @{Name='SizeMiB';Expression={ [math]::Round($_.Length / 1MB, 1) }} Linux [RO] df -hT [RO][PRIV] sudo du -xhd 1 /var | sort -h macOS [RO] df -h [RO][PRIV] sudo du -xhd 1 /Library | sort -h Prognosebeispiel Freier Speicher: 100 GB Verbrauch: 5 GB pro Tag Vereinfachte Restzeit: ungefähr 20 Tage Die Wachstumsrate kann schwanken. Eine Prognose sollte deshalb auf mehreren Messpunkten und einem geeigneten Zeitraum beruhen. Dateien dürfen erst gelöscht werden, wenn Zweck, Eigentümer, Aufbewahrungspflicht und Wiederherstellbarkeit geklärt sind. 22. Kompakte Befehlsübersicht für Windows, Linux und macOS Aufgabe Windows Linux macOS Leistungsanzeige öffnen [RO] perfmon.msc abhängig vom Werkzeug [RO] open -a "Activity Monitor" Prozessübersicht [RO] Get-Process [RO] top [RO] top -l 1 CPU messen [RO] Get-Counter '\Processor(_Total)\% Processor Time' [RO] mpstat -P ALL 1 10 [RO] top -l 1 -o cpu Load Average kein direkt gleichwertiger Standardwert [RO] uptime [RO] uptime logische CPUs [RO] (Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors [RO] nproc [RO] sysctl -n hw.logicalcpu verfügbarer RAM [RO] Get-Counter '\Memory\Available MBytes' [RO] free -h [RO] memory_pressure Speicheraktivität [RO] Get-Counter '\Memory\Pages/sec' [RO] vmstat 1 10 [RO] vm_stat 1 Prozesse nach RAM [RO] Get-Process | Sort-Object WorkingSet64 -Descending [RO] ps -eo pid,%mem,rss,comm --sort=-%mem [RO] top -l 1 -o mem Dateisystembelegung [RO] Get-Volume [RO] df -hT [RO] df -h Inode-Nutzung nicht direkt vergleichbar [RO] df -i [RO] df -i Datenträger-I/O [RO] Get-Counter '\PhysicalDisk(*)\% Disk Time' [RO] iostat -xz 1 10 [RO] iostat -w 1 -c 10 Interfaceübersicht [RO] Get-NetAdapter [RO] ip link [RO] ifconfig Interfacezähler [RO] Get-NetAdapterStatistics [RO] ip -s link [RO] netstat -ib TCP-Zusammenfassung [RO] Get-NetTCPConnection [RO] ss -s [RO] netstat -s Erreichbarkeit [TEST] ping ziel.example [TEST] ping -c 4 ziel.example [TEST] ping -c 4 ziel.example Pfadprüfung [TEST] tracert ziel.example [TEST] traceroute ziel.example [TEST] traceroute ziel.example Containerressourcen [RO] docker stats --no-stream [RO] docker stats --no-stream [RO] docker stats --no-stream Linux-Ressourcendruck Nicht zutreffend [RO] cat /proc/pressure/{cpu,memory,io} Nicht standardmäßig vorhanden mpstat , iostat , pidstat , nstat , mtr und ethtool sind nicht auf jeder Linux-Installation standardmäßig vorhanden. Fehlende Werkzeuge dürfen nicht ohne Prüfung der Paketquelle und betriebliche Freigabe installiert werden. 23. Systematischer Ablauf einer Monitoringanalyse Phase Vorgehen 1. Symptom bestimmen Benutzerwirkung und betroffene Funktion dokumentieren 2. Zeitraum festlegen Fehlerbeginn, Ende und Zeitzone bestimmen 3. Datenqualität prüfen letzte Messung, Lücken und Datenquelle kontrollieren 4. Baseline wählen vergleichbaren funktionierenden Zeitraum bestimmen 5. RED prüfen Anfragerate, Fehlerrate und Dauer untersuchen 6. USE prüfen Auslastung, Sättigung und Fehler der Ressourcen untersuchen 7. Änderungspunkte prüfen Updates, Deployments, Backups und Wartung einblenden 8. Umfang bestimmen einzelne Instanz, Dienstgruppe oder gesamte Umgebung 9. Hypothese bilden möglichen Zusammenhang konkret formulieren 10. Logs und Traces prüfen technische Ursache weiter eingrenzen 11. Kontrolliert testen nur eine begründete Änderung durchführen 12. Wirkung bestätigen dieselben Messwerte erneut vergleichen 13. Langfristig beobachten Rückfall und Nebenwirkungen ausschließen 14. Dokumentieren Ursache, Messwerte, Änderung und Ergebnis festhalten Formulierung einer guten Hypothese Wenn die erhöhte Datenträgerlatenz die Ursache der langsamen Anwendung ist, muss die Antwortzeit bei vergleichbarer Anfragemenge mit der Datenträgerlatenz steigen und nach deren Normalisierung wieder sinken. Diese Hypothese ist messbar und überprüfbar. 24. Dokumentationsvorlage für eine Monitoringanalyse Ticketnummer: Analysedatum: Betroffener Dienst: Betroffene Systeme: Benutzerwirkung: Fehlerbeginn: Fehlerende: Zeitzone: Reproduzierbar: Ja / Nein Verwendetes Monitoringsystem: Datenquelle: Abfrageintervall: Auswertungsintervall: Letzter Datenpunkt: Datenlücken vorhanden: Ja / Nein Vergleichszeitraum: Begründung für den Vergleichszeitraum: Benutzerorientierte Messwerte: - Verfügbarkeit: - Anfragerate: - Fehlerrate: - Antwortzeit p50: - Antwortzeit p95: - Antwortzeit p99: Ressourcenwerte: - CPU-Auslastung: - CPU-Sättigung: - verfügbarer RAM: - Paging/Swap: - Datenträgerauslastung: - Datenträgerlatenz: - Datenträgerwarteschlange: - Netzwerkdurchsatz: - Netzwerkfehler: - TCP-Retransmissions: - freier Speicherplatz: Änderungen im Zeitraum: - Deployment: - Update: - Backup: - Wartung: - Konfigurationsänderung: Auffällige Korrelationen: 1. 2. 3. Arbeitshypothese: Erwartetes Messergebnis: Kontrollierter Test: Tatsächliches Ergebnis: Ermittelte Ursache: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Beobachtungszeitraum nach der Änderung: Dashboard: Abfrage: Screenshot oder Export: Sensible Daten redigiert: Ja / Nein 25. Offizielle Quellen und weiterführende Dokumentation Microsoft Get-Counter – Microsoft Learn Windows Performance Monitor – Microsoft Learn Leistungsprobleme unter Windows untersuchen Get-NetAdapterStatistics – Microsoft Learn Get-Volume – Microsoft Learn Linux Linux Pressure Stall Information – Kernel-Dokumentation Lokale Befehlsreferenzen: man top , man vmstat , man iostat , man mpstat , man free und man proc Prometheus Prometheus-Metriktypen PromQL-Funktionen Prometheus Alerting Rules Prometheus Best Practices Grafana Grafana Alerting Best Practices für Grafana-Dashboards Umgang mit No Data und Error Docker docker stats – Docker-Dokumentation Docker Runtime Metrics Bezeichnungen, Einheiten und Berechnungsmethoden können sich zwischen Betriebssystemen, Exportern und Monitoringprodukten unterscheiden. Vor einem direkten Vergleich muss immer geprüft werden, was die konkrete Metrik tatsächlich misst. 2.14 Sichere Paketmitschnitte, Datenschutz und Beweissicherung Ein Paketmitschnitt zeichnet Netzwerkpakete an einer Netzwerkschnittstelle oder einem definierten Messpunkt auf. Je nach Protokoll und Verschlüsselung kann eine Aufzeichnung nicht nur technische Metadaten, sondern auch Kommunikationsinhalte enthalten. Ein Paketmitschnitt kann unter anderem sichtbar machen: Quell- und Ziel-IP-Adressen, MAC-Adressen, Ports und Protokolle, DNS-Anfragen und aufgerufene Hostnamen, Verbindungsaufbau und Verbindungsabbau, Paketgrößen und Zeitstempel, TCP-Wiederholungen und Paketverluste, unverschlüsselte Benutzernamen oder Inhalte, HTTP-Header und Cookies, Authentifizierungsinformationen, interne System- und Dienstnamen, bei vorhandenen Schlüsseln auch entschlüsselte Anwendungsdaten. Grundregel: So wenig wie möglich, so gezielt wie nötig und nur so lange wie erforderlich mitschneiden. 1. Kennzeichnungen und Sicherheitsregeln Kennzeichnung Bedeutung [RO] Liest vorhandene Informationen aus [TEST] Führt eine aktive Messung oder Aufzeichnung durch [PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte [FILE] Erzeugt oder verändert eine Datei [SENS] Datei oder Ausgabe kann vertrauliche Daten enthalten [CHANGE] Verändert Konfiguration oder Systemzustand [DISRUPT] Kann Verbindungen oder Dienste beeinträchtigen Ein Live-Paketmitschnitt ist keine rein passive Read-only-Aktion. Er liest laufende Kommunikation mit und schreibt sie in eine Datei: [TEST][PRIV][FILE][SENS] Vor jeder Aufzeichnung müssen mindestens folgende Punkte geklärt werden: Gibt es einen konkreten technischen Anlass? Liegt eine ausreichende betriebliche und rechtliche Freigabe vor? Welche Systeme und Kommunikationsverbindungen dürfen erfasst werden? Wer ist für die Aufzeichnung verantwortlich? Welcher Zeitraum ist erforderlich? Welche Daten sollen ausdrücklich nicht erfasst werden? Wo wird die Datei gespeichert? Wer darf die Datei auswerten? Darf sie an Hersteller oder Dienstleister weitergegeben werden? Wann wird sie gelöscht? 2. Warum sind Paketmitschnitte besonders sensibel? Eine PCAP- oder PCAPNG-Datei kann mehr Informationen enthalten, als für die technische Untersuchung zunächst sichtbar sind. Mögliche Inhalte: Datenart Beispiel Netzwerkkennungen IP- und MAC-Adressen Benutzerbezug Benutzername, Gerät oder interne Zuordnung Kommunikationspartner interne und externe Zielsysteme DNS-Daten angefragte Domains und Hostnamen Zeitdaten Zeitpunkt und Dauer der Kommunikation Inhaltsdaten unverschlüsselte Nachrichten oder Dateien Authentifizierungsdaten Cookies, Tokens oder Anmeldeinformationen Organisationsdaten interne Server-, Standort- und Kundennamen Sicherheitsdaten Ports, Dienste, Zertifikate und Netzwerkstruktur Entschlüsselungsgeheimnisse TLS-Key-Log oder eingebettete Schlüsselblöcke Auch verschlüsselter Datenverkehr enthält auswertbare Metadaten: beteiligte IP-Adressen, Verbindungszeiten, Datenmengen, Paketgrößen, DNS-Anfragen, sofern nicht verschlüsselt, TLS-Versionen und Zertifikatsinformationen, teilweise Servernamen, zeitliche Kommunikationsmuster. Verschlüsselung macht einen Paketmitschnitt daher nicht automatisch datenschutzrechtlich oder sicherheitstechnisch unbedenklich. 3. Welche betrieblichen und rechtlichen Prüfungen sind erforderlich? Die zulässige Verarbeitung hängt vom konkreten Zweck, der Organisation, den betroffenen Personen und den geltenden Vorgaben ab. Diese Seite ersetzt keine rechtliche Prüfung. Möglicherweise einzubeziehende Stellen: System- oder Serviceverantwortliche, Informationssicherheitsbeauftragte, Datenschutzbeauftragte, Netzwerkverantwortliche, betroffene Fachabteilung, Incident-Response-Team, Betriebs- oder Personalrat, externe Auftragsverarbeiter, Rechtsabteilung. Relevante Datenschutzgrundsätze sind unter anderem: Grundsatz Bedeutung für Paketmitschnitte Rechtmäßigkeit und Transparenz Verarbeitung benötigt eine tragfähige Grundlage Zweckbindung Daten nur für den festgelegten Diagnosezweck verwenden Datenminimierung nur erforderliche Kommunikation erfassen Richtigkeit Zeit, Messpunkt und Dateiintegrität dokumentieren Speicherbegrenzung Datei nicht länger als erforderlich aufbewahren Integrität und Vertraulichkeit Zugriff, Transport und Speicherung schützen Rechenschaftspflicht Zweck, Freigabe und Verarbeitung dokumentieren Nicht ausreichend sind Aussagen wie: „Es ist nur für die Technik.“ „Die Verbindung ist verschlüsselt.“ „Wir schneiden nur kurz mit.“ Auch ein kurzer technischer Mitschnitt kann personenbezogene oder vertrauliche Daten enthalten. 4. Welche Freigaben sollten vor Beginn dokumentiert werden? Ticketnummer: Verantwortliche Person: Auftraggebende Stelle: Technischer Zweck: Betroffene Systeme: Betroffene Netzsegmente: Betroffene Benutzergruppen: Erlaubte Protokolle: Ausgeschlossene Systeme und Daten: Beginn: Geplantes Ende: Maximale Dateigröße: Speicherort: Auswertungsberechtigte Personen: Vorgesehene Weitergabe: Aufbewahrungsfrist: Löschtermin: Datenschutzprüfung erforderlich: Ja / Nein Datenschutzprüfung erfolgt: Ja / Nein Betriebsrat einzubeziehen: Ja / Nein / Nicht zutreffend Informationssicherheit informiert: Ja / Nein Freigabe erteilt durch: Freigabezeitpunkt: Bei einem akuten Sicherheitsvorfall können besondere Incident-Response-Regelungen gelten. Auch dann müssen Zuständigkeit, Beweissicherung und Zugriff nachvollziehbar dokumentiert werden. 5. Wo sollte ein Paketmitschnitt durchgeführt werden? Der Messpunkt bestimmt, welcher Datenverkehr sichtbar ist. Messpunkt Sichtbarer Datenverkehr Typischer Zweck betroffener Client Kommunikation dieses Clients lokales Clientproblem Anwendungsserver ein- und ausgehende Serverkommunikation Backend- oder Dienstproblem Reverse Proxy Client- und Backendverbindungen des Proxys HTTP- und TLS-Fehler eingrenzen DNS-Server DNS-Anfragen am Server Auflösungsprobleme Firewall Verkehr an der jeweiligen Schnittstelle Routing, NAT und Filterung Switch-SPAN-Port gespiegelter Verkehr ausgewählter Ports oder VLANs segmentübergreifende Analyse virtueller Switch Verkehr virtueller Systeme VM- und Hypervisoranalyse Containerhost Verkehr von Containern und Bridges Containerkommunikation Grundsatz So nah wie möglich am vermuteten Problem mitschneiden. Bei komplexen Problemen können zwei gleichzeitige Mitschnitte sinnvoll sein: Client-Mitschnitt + Server-Mitschnitt Damit lässt sich beispielsweise prüfen: ob ein Paket den Client verlassen hat, ob es am Server angekommen ist, wo ein Verlust auftritt, ob NAT oder Firewall Adressen verändert, ob die Zeitstempel deutlich voneinander abweichen. Vor einem Vergleich müssen die Systemuhren geprüft werden. 6. Wie wird die richtige Netzwerkschnittstelle bestimmt? Windows [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex IP-Konfiguration zuordnen: [RO] Get-NetIPConfiguration Wireshark-Schnittstellen anzeigen: [RO] dumpcap.exe -D [RO] tshark.exe -D Linux [RO] ip -brief address [RO] ip route [RO] dumpcap -D [RO] tcpdump -D macOS [RO] ifconfig Standardroute und verwendetes Interface: [RO] route -n get default Wireshark-Schnittstellen: [RO] dumpcap -D [RO] tcpdump -D Typische Schnittstellen Name Mögliche Bedeutung Ethernet kabelgebundener Windows-Adapter Wi-Fi Windows-WLAN eth0 , enp… , ens… Linux-Ethernet wlan0 , wlp… Linux-WLAN en0 , en1 macOS-Netzwerkschnittstelle lo , lo0 Loopback docker0 Docker-Bridge br-… benutzerdefinierte Container-Bridge vEthernet (…) virtueller Windows-Adapter utun… macOS-Tunnel oder VPN any zusammengefasste Linux-Capture-Schnittstelle Die Namenskonvention allein reicht nicht. Die Schnittstelle muss über IP-Adresse, Route und tatsächliche Paketaktivität bestätigt werden. 7. Wie wird vor dem Mitschnitt ein Capture-Plan erstellt? Fehler: HTTPS-Aufruf an app.example.intern schlägt sporadisch fehl. Betroffener Client: CLIENT-023 Ziel: 192.0.2.20 Port: TCP 443 Schnittstelle: Ethernet / Index 4 Geplanter Zeitraum: maximal 120 Sekunden Auslöser: Benutzer führt genau einen Anmeldeversuch aus. Capture-Filter: host 192.0.2.20 and tcp port 443 Datei: TICKET-4711_CLIENT-023_20260731T094200+0200.pcapng Maximale Dateigröße: 100 MB Speicherort: geschütztes Diagnoseverzeichnis Nachbereitung: Zeitfenster weiter reduzieren, Hash bilden, Zugriff begrenzen. Löschtermin: nach Abschluss gemäß Ticket und interner Richtlinie Ein guter Capture-Plan verhindert unkontrollierte Daueraufzeichnungen und unnötig große Dateien. 8. Wie wird bereits bei der Aufnahme Datenminimierung umgesetzt? Vier zentrale Begrenzungen: richtige Schnittstelle, enger Capture-Filter, kurze Aufzeichnungsdauer, begrenzte Paketlänge oder Dateigröße. Capture-Filter nach Host host 192.0.2.20 Nur Kommunikation zwischen zwei Systemen host 192.0.2.10 and host 192.0.2.20 Nur HTTPS zu einem Ziel host 192.0.2.20 and tcp port 443 Nur DNS zu einem bestimmten DNS-Server host 192.0.2.53 and port 53 Nur TCP zwischen zwei Systemen tcp and host 192.0.2.10 and host 192.0.2.20 Bestimmtes Subnetz ausschließen host 192.0.2.20 and not net 198.51.100.0/24 Wichtige Filterbegriffe Ausdruck Bedeutung host 192.0.2.20 Quelle oder Ziel ist dieser Host src host 192.0.2.20 Host ist Quelle dst host 192.0.2.20 Host ist Ziel net 192.0.2.0/24 Verkehr eines Netzes port 53 Quell- oder Zielport 53 src port 53 Quellport 53 dst port 443 Zielport 443 tcp nur TCP udp nur UDP icmp nur ICMP and beide Bedingungen müssen zutreffen or mindestens eine Bedingung trifft zu not Bedingung ausschließen Capture-Filter verwenden die Syntax von libpcap/BPF. Sie unterscheiden sich von Wireshark-Display-Filtern. 9. Was ist der Unterschied zwischen Capture- und Display-Filter? Filterart Zeitpunkt Wirkung Capture-Filter während der Aufnahme nicht passende Pakete werden nicht gespeichert Display-Filter nach beziehungsweise während der Anzeige Pakete bleiben in der Datei, werden aber ausgeblendet Capture-Filter host 192.0.2.20 and tcp port 443 Entsprechender Display-Filter ip.addr == 192.0.2.20 && tcp.port == 443 Ein Display-Filter reduziert nicht den sensiblen Inhalt der gespeicherten Originaldatei. Ausgeblendet ≠ entfernt Vor einer Weitergabe muss eine neue, tatsächlich reduzierte Datei erzeugt und anschließend erneut geprüft werden. 10. Wie wird mit dumpcap eine zeitlich begrenzte Aufnahme erstellt? dumpcap ist die spezialisierte Capture-Komponente von Wireshark. Die grafische Wireshark-Anwendung muss dadurch nicht mit erhöhten Rechten ausgeführt werden. Schnittstellen auflisten [RO] dumpcap -D 60 Sekunden auf Schnittstelle 1 mitschneiden [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -a duration:60 \ -w capture.pcapng Gezielter HTTPS-Mitschnitt [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20 and tcp port 443" \ -a duration:60 \ -w capture.pcapng Nach 10.000 Paketen stoppen [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20" \ -c 10000 \ -w capture.pcapng Nach einer Dateigröße von ungefähr 100.000 kB stoppen [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20" \ -a filesize:100000 \ -w capture.pcapng Bei dumpcap wird filesize in Kilobyte zu jeweils 1.000 Byte angegeben. Wichtige Optionen Option Bedeutung -D Schnittstellen auflisten -i Schnittstelle auswählen -f Capture-Filter -a duration:60 nach 60 Sekunden stoppen -a filesize:100000 bei ungefähr 100 MB stoppen -c 10000 nach 10.000 Paketen stoppen -s 96 maximal 96 Byte jedes Pakets speichern -w Ausgabedatei -p Promiscuous Mode deaktivieren -q reduzierte Statusausgabe Der tatsächliche Schnittstellenname oder die Nummer muss vorher mit dumpcap -D ermittelt werden. 11. Wie wird mit tcpdump eine begrenzte Aufnahme erstellt? tcpdump ist unter Linux und macOS häufig verfügbar. Unter Windows werden üblicherweise Wireshark, Dumpcap oder TShark mit Npcap verwendet. 60 Sekunden gezielt aufzeichnen Linux: [TEST][PRIV][FILE][SENS] sudo timeout 60 \ tcpdump -i eth0 \ -nn \ -w capture.pcap \ 'host 192.0.2.20 and tcp port 443' timeout gehört zum GNU-Coreutils-Umfeld und ist unter macOS nicht standardmäßig in derselben Form vorhanden. Nach 10.000 Paketen stoppen Linux und macOS: [TEST][PRIV][FILE][SENS] sudo tcpdump \ -i en0 \ -nn \ -c 10000 \ -w capture.pcap \ 'host 192.0.2.20 and tcp port 443' Paketlänge auf 96 Byte begrenzen [TEST][PRIV][FILE][SENS] sudo tcpdump \ -i en0 \ -nn \ -s 96 \ -c 10000 \ -w capture-truncated.pcap \ 'host 192.0.2.20 and tcp port 443' Wichtige Optionen Option Bedeutung -i en0 Aufnahmeschnittstelle -nn keine Hostnamen- und Portnamensauflösung -c 10000 nach 10.000 Paketen stoppen -s 96 Snapshot-Länge 96 Byte -w DATEI Rohpakete in Datei schreiben -r DATEI vorhandene Datei lesen Filter am Ende Capture-Filter Eine geringe Snapshot-Länge reduziert den gespeicherten Paketinhalt, kann aber wichtige Protokollinformationen abschneiden. Außerdem bleiben Netzwerkheader, Adressen und möglicherweise Teile der Nutzdaten erhalten. Trunkierung ist keine vollständige Anonymisierung. 12. Wie wird eine Ringpuffer-Aufzeichnung sicher begrenzt? Ein Ringpuffer schreibt mehrere Dateien und überschreibt nach Erreichen der festgelegten Anzahl die älteste Datei. Dadurch wird der maximale Speicherverbrauch begrenzt. Dumpcap: fünf Dateien mit jeweils 60 Sekunden [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20 and tcp port 443" \ -b duration:60 \ -b files:5 \ -w capture.pcapng Dumpcap: fünf Dateien mit jeweils ungefähr 50 MB [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20 and tcp port 443" \ -b filesize:50000 \ -b files:5 \ -w capture.pcapng tcpdump: fünf Dateien mit ungefähr 50 MB [TEST][PRIV][FILE][SENS] sudo tcpdump \ -i eth0 \ -nn \ -C 50 \ -W 5 \ -w capture.pcap \ 'host 192.0.2.20 and tcp port 443' Bei tcpdump können Einheit und Verhalten einzelner Rotationsoptionen von der verwendeten Implementierung und Version abhängen. Vor dem Einsatz muss die lokale Dokumentation geprüft werden: [RO] man tcpdump Wichtiger Hinweis Ein Ringpuffer verhindert unbegrenztes Dateiwachstum, löscht aber ältere Aufzeichnungen automatisch durch Überschreiben. Er ist deshalb nicht geeignet, wenn alle Daten unverändert als Beweismittel erhalten bleiben müssen. 13. Wie wird der Promiscuous Mode bewertet? Im Promiscuous Mode nimmt eine Netzwerkkarte zusätzlich Frames entgegen, die nicht unmittelbar an ihre eigene MAC-Adresse adressiert sind. Promiscuous Mode ≠ automatisch gesamter Netzwerkverkehr In einem geswitchten Netzwerk sieht ein Client normalerweise weiterhin nur: eigenen Unicast-Verkehr, Broadcasts, relevante Multicasts, vom Switch an diesen Port weitergeleiteten Verkehr. Für zusätzlichen Verkehr ist häufig ein korrekt konfigurierter SPAN- beziehungsweise Mirror-Port oder ein anderer geeigneter Messpunkt erforderlich. Promiscuous Mode mit dumpcap deaktivieren [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -p \ -f "host 192.0.2.20" \ -a duration:60 \ -w capture.pcapng Wenn nur lokaler Hostverkehr benötigt wird, kann die Deaktivierung des Promiscuous Mode die Erfassung unbeabsichtigten Verkehrs reduzieren. 14. Was ist bei WLAN-Mitschnitten und Monitor Mode zu beachten? Der WLAN-Monitor-Mode kann rohe 802.11-Frames eines Funkkanals erfassen. Unterstützung und Verhalten hängen ab von: Betriebssystem, WLAN-Chipsatz, Treiber, Kanal, Frequenzband, Verschlüsselung, aktueller Verbindung. Das Aktivieren des Monitor Mode kann die bestehende WLAN-Verbindung unterbrechen: [CHANGE][DISRUPT] Zusätzlich können Kommunikationsdaten anderer Geräte im Funkbereich erfasst werden. Ein WLAN-Mitschnitt benötigt daher eine besonders klare technische und organisatorische Abgrenzung. Für eine gewöhnliche Client-Fehleranalyse ist häufig ein Mitschnitt am regulären Netzwerkinterface ohne Monitor Mode ausreichend. 15. Wie wird eine laufende Aufnahme überwacht? Während der Aufnahme sind folgende Werte zu kontrollieren: Dateigröße, verbleibender Speicherplatz, Paketanzahl, verworfene Pakete, CPU-Auslastung, Schreibgeschwindigkeit, Aufnahmezeit, korrekte Schnittstelle, korrekter Filter, Zeitpunkt der Fehlerreproduktion. Speicherplatz prüfen Windows: [RO] Get-Volume Linux: [RO] df -h macOS: [RO] df -h Dateigröße beobachten Windows: [RO] Get-Item '.\capture.pcapng' | Select-Object FullName, Length, LastWriteTime Linux und macOS: [RO] ls -lh capture.pcapng Wenn Capture-Pakete verworfen werden, ist die Aufzeichnung möglicherweise unvollständig. Mögliche Ursachen: Capture-Puffer zu klein, Datenträger zu langsam, zu hohe Paketrate, System zu stark ausgelastet, zu umfangreiche Live-Anzeige, ungeeigneter Messpunkt. Ein größerer Capture-Puffer kann helfen, benötigt aber zusätzlichen Arbeitsspeicher und ersetzt keine Bewertung der Systemkapazität. 16. Wie wird ein Mitschnitt unmittelbar nach der Aufnahme geprüft? Dateiinformationen anzeigen Windows, Linux und macOS: [RO][SENS] capinfos capture.pcapng Wichtige Informationen: Dateiformat, Dateigröße, Anzahl der Pakete, erstes und letztes Paket, Aufzeichnungsdauer, Schnittstelle, Kapselung, Datenrate, gespeicherte Paketlängen, vorhandene Kommentare oder Geheimnisse. Kurze Protokollübersicht [RO][SENS] tshark -r capture.pcapng -q -z io,phs Kommunikationsbeziehungen [RO][SENS] tshark -r capture.pcapng -q -z endpoints,ip [RO][SENS] tshark -r capture.pcapng -q -z conv,tcp Prüffragen Enthält die Datei den erwarteten Zeitraum? Ist die richtige Schnittstelle erfasst? Ist der Zielverkehr enthalten? Wurde unbeabsichtigter Fremdverkehr gespeichert? Sind unverschlüsselte Inhalte sichtbar? Enthält die Datei eingebettete Entschlüsselungsgeheimnisse? Sind Kommentare oder Metadaten vorhanden? Ist eine weitere Reduktion erforderlich? Muss die Originaldatei erhalten bleiben? Wer darf die Datei öffnen? 17. Wie wird aus einer großen Aufzeichnung eine zeitlich begrenzte Arbeitskopie erstellt? Mit editcap kann ein Zeitbereich aus einer vorhandenen Datei in eine neue Datei geschrieben werden. Zeitbereich mit UTC-Offset auswählen [RO][FILE][SENS] editcap \ -A "2026-07-31T09:42:00+02:00" \ -B "2026-07-31T09:44:00+02:00" \ original.pcapng \ arbeitskopie.pcapng -A nimmt Pakete ab dem angegebenen Zeitpunkt auf. -B begrenzt auf Pakete vor dem angegebenen Endzeitpunkt. Bestimmte Paketnummern übernehmen Nur Pakete 200 bis 750 schreiben: [RO][FILE][SENS] editcap \ -r \ original.pcapng \ arbeitskopie.pcapng \ 200-750 Erste 500 Pakete übernehmen [RO][FILE][SENS] editcap \ -r \ original.pcapng \ erste-500.pcapng \ 1-500 Die neue Datei muss anschließend erneut mit Wireshark, TShark oder Capinfos geprüft werden. Eine erfolgreiche Programmausführung beweist nicht, dass alle unerwünschten Daten entfernt wurden. 18. Wie wird eine Datei nach einem Display-Filter exportiert? Mit TShark kann aus einer vorhandenen Aufzeichnung eine gefilterte Datei erzeugt werden. Nur Verkehr eines bestimmten Hosts exportieren [RO][FILE][SENS] tshark \ -r original.pcapng \ -Y "ip.addr == 192.0.2.20" \ -w gefiltert.pcapng Nur TCP-Port 443 zu einem bestimmten Host [RO][FILE][SENS] tshark \ -r original.pcapng \ -Y "ip.addr == 192.0.2.20 && tcp.port == 443" \ -w gefiltert.pcapng Nur ein bestimmtes TCP-Gespräch Zunächst Streamnummer in Wireshark oder TShark bestimmen. Anschließend beispielsweise: [RO][FILE][SENS] tshark \ -r original.pcapng \ -Y "tcp.stream == 4" \ -w tcp-stream-4.pcapng Wichtig Ein Export nach Display-Filter erzeugt eine neue reduzierte Datei. Das Original bleibt unverändert. Nicht angezeigte Pakete werden beim Export nicht übernommen. Die übernommenen Pakete enthalten weiterhin ihre vollständigen gespeicherten Header und Nutzdaten. Die gefilterte Datei ist deshalb nicht automatisch anonymisiert. 19. Wie werden eingebettete Entschlüsselungsgeheimnisse und Kommentare entfernt? PCAPNG-Dateien können zusätzliche Metadaten enthalten, darunter: Capture-Kommentare, Paketkommentare, Schnittstelleninformationen, Decryption Secrets Blocks. Vor einer Weitergabe muss geprüft werden, ob solche Informationen vorhanden sind. Eingebettete Entschlüsselungsgeheimnisse entfernen [RO][FILE][SENS] editcap \ --discard-all-secrets \ original.pcapng \ ohne-secrets.pcapng Capture- und Paketkommentare entfernen [RO][FILE][SENS] editcap \ --discard-capture-comment \ --discard-packet-comments \ original.pcapng \ ohne-kommentare.pcapng Kombiniert [RO][FILE][SENS] editcap \ --discard-all-secrets \ --discard-capture-comment \ --discard-packet-comments \ original.pcapng \ bereinigt.pcapng Danach muss die Ausgabedatei erneut geprüft werden: [RO][SENS] capinfos bereinigt.pcapng Das Entfernen von Geheimnisblöcken und Kommentaren entfernt nicht automatisch IP-Adressen, MAC-Adressen, Hostnamen oder Nutzdaten. 20. Warum ist Trunkierung keine vollständige Anonymisierung? Mit editcap -s kann die gespeicherte Länge jedes Pakets begrenzt werden. Auf 96 Byte kürzen [RO][FILE][SENS] editcap \ -s 96 \ original.pcapng \ gekuerzt.pcapng Dadurch können Teile der Nutzdaten entfernt werden. Abhängig von den vorhandenen Protokollheadern können aber weiterhin enthalten sein: MAC-Adressen, VLAN-Informationen, IP-Adressen, Ports, TCP-Flags, DNS-Inhalte, TLS-Informationen, Teile der Nutzdaten. Eine feste Snapshot-Länge kann außerdem die technische Analyse beeinträchtigen. Gekürzt ≠ anonymisiert Eine belastbare Anonymisierung erfordert: Definition der zu schützenden Felder, geeignetes Werkzeug und Verfahren, Prüfung der resultierenden Datei, Berücksichtigung eingebetteter Metadaten, Berücksichtigung rekonstruierbarer Zusammenhänge. Wireshark und Editcap bieten keine allgemeine Ein-Klick-Anonymisierung, die für jedes Protokoll zuverlässig sämtliche personenbezogenen oder vertraulichen Inhalte entfernt. 21. Wie werden Hashwerte zur Integritätsprüfung erstellt? Ein kryptografischer Hash dokumentiert den Zustand einer Datei zu einem bestimmten Zeitpunkt. Wird die Datei verändert, ändert sich mit sehr hoher Wahrscheinlichkeit auch der Hash. Windows [RO] Get-FileHash ` 'C:\Diagnose\original.pcapng' ` -Algorithm SHA256 Hash in Datei dokumentieren: [RO][FILE] Get-FileHash ` 'C:\Diagnose\original.pcapng' ` -Algorithm SHA256 | Format-List | Out-File 'C:\Diagnose\original.pcapng.sha256.txt' Linux [RO] sha256sum original.pcapng [RO][FILE] sha256sum original.pcapng \ > original.pcapng.sha256 macOS [RO] shasum -a 256 original.pcapng [RO][FILE] shasum -a 256 original.pcapng \ > original.pcapng.sha256 Erneut prüfen Linux: [RO] sha256sum -c original.pcapng.sha256 macOS: [RO] shasum -a 256 -c original.pcapng.sha256 Ein Hash beweist nicht automatisch, wer die Datei erstellt hat oder ob der ursprüngliche Mitschnitt vollständig war. Er hilft aber festzustellen, ob sich genau diese Datei nach der Hashbildung verändert hat. 22. Wie werden Original und Arbeitskopie getrennt? Empfohlene Struktur: TICKET-4711/ ├── original/ │ ├── TICKET-4711_CLIENT-023_original.pcapng │ └── TICKET-4711_CLIENT-023_original.pcapng.sha256 ├── working/ │ ├── TICKET-4711_zeitfenster.pcapng │ └── TICKET-4711_tcp-stream-4.pcapng ├── export/ │ └── TICKET-4711_freigegebene-kopie.pcapng └── dokumentation/ └── TICKET-4711_capture-protokoll.txt Regeln Original nach der Sicherung nicht mehr bearbeiten. Hash des Originals unmittelbar nach der Aufnahme erstellen. Analysen auf einer Arbeitskopie durchführen. Weitergabekopie getrennt erzeugen. Jede Bearbeitung dokumentieren. Weitergabekopie vor Übergabe erneut kontrollieren. Hashwerte von Original und Export getrennt dokumentieren. Das Original enthält möglicherweise mehr sensible Daten als die freigegebene Weitergabekopie und benötigt entsprechend strengere Zugriffsrechte. 23. Wie werden Dateizugriffe technisch eingeschränkt? Windows-Beispiel Vererbung entfernen: [CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /inheritance:r Einem ausdrücklich festgelegten Konto Zugriff gewähren: [CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /grant:r "DOMÄNE\Diagnosekonto:(OI)(CI)F" Vorher müssen Konto, gewünschte Rechte und bestehende Berechtigungen genau geprüft werden. Ein falscher icacls -Befehl kann berechtigte Personen aussperren. Aktuelle Berechtigungen anzeigen: [RO] icacls "C:\Diagnose\TICKET-4711" Linux und macOS Verzeichnis nur für den Eigentümer zugänglich machen: [CHANGE] chmod 700 /pfad/TICKET-4711 Datei nur für den Eigentümer les- und schreibbar machen: [CHANGE] chmod 600 /pfad/TICKET-4711/original.pcapng Berechtigungen prüfen: [RO] ls -ld /pfad/TICKET-4711 [RO] ls -l /pfad/TICKET-4711 Dateiberechtigungen ersetzen keine Verschlüsselung, keine sichere Übertragung und keine organisatorische Zugriffskontrolle. 24. Wie wird ein Paketmitschnitt sicher weitergegeben? Vor jeder Weitergabe: Empfänger und Zweck bestätigen. Vertragliche und datenschutzrechtliche Zulässigkeit prüfen. Nur den erforderlichen Zeit- und Datenbereich exportieren. Unnötige Pakete entfernen. Kommentare und eingebettete Geheimnisse entfernen. Datei auf unverschlüsselte Inhalte prüfen. Freigegebene Kopie getrennt speichern. Hash der freigegebenen Datei berechnen. Sicheren Übertragungsweg verwenden. Kennwort oder Schlüssel über einen getrennten Kanal übermitteln. Übergabe im Ticket dokumentieren. Löschung beim Empfänger vereinbaren und dokumentieren. Nicht geeignete Übertragungswege öffentlicher Dateilink ohne Zugriffsschutz, unverschlüsselte E-Mail, privater Messenger ohne Freigabe, öffentliches Cloudlaufwerk, frei zugänglicher Webserver, unkontrollierter USB-Datenträger. Ein vom Hersteller bereitgestelltes Supportportal ist nicht automatisch für beliebige vertrauliche Daten freigegeben. Vertragslage, Standort, Auftragsverarbeitung und interne Vorgaben müssen geprüft werden. 25. Was ist bei TLS-Entschlüsselung zu beachten? TLS-Entschlüsselung kann Inhalte sichtbar machen, die gerade durch Verschlüsselung geschützt werden sollen. Mögliche Inhalte: Zugangsdaten, Sitzungscookies, API-Token, personenbezogene Daten, Formulardaten, Dateiinhalte, interne Anwendungsinformationen. TLS-Key-Log-Dateien und private Schlüssel sind besonders schützenswert: [SENS] Eine TLS-Key-Log-Datei kann die Entschlüsselung aufgezeichneter Sitzungen ermöglichen. Regeln nur mit ausdrücklicher Freigabe, nur für den erforderlichen Prozess oder Testbenutzer, möglichst in kontrollierter Testumgebung, Key-Log-Datei getrennt schützen, nicht gemeinsam mit der Aufzeichnung unkontrolliert versenden, nach Abschluss kontrolliert löschen, niemals produktive private Server-Schlüssel exportieren, wenn dies nicht ausdrücklich erforderlich und freigegeben ist. PCAPNG-Dateien können Entschlüsselungsgeheimnisse eingebettet enthalten. Vor einer Weitergabe muss dies ausdrücklich geprüft werden. 26. Welche Fehler treten bei Paketmitschnitten häufig auf? Fehler Folge Besseres Vorgehen falsche Schnittstelle relevanter Verkehr fehlt IP-Konfiguration und Route vorher prüfen Aufnahme am falschen Messpunkt Ursache bleibt unsichtbar Kommunikationsweg zeichnen kein Capture-Filter unnötig viele sensible Daten Zielhost und Port begrenzen nur Display-Filter verwendet Fremdverkehr bleibt in Datei reduzierte Datei exportieren Aufnahme läuft unbegrenzt Speicherplatz und Datenschutzproblem Dauer, Größe oder Ringpuffer begrenzen Fehler nicht reproduziert relevanter Vorgang fehlt exakten Reproduktionszeitpunkt notieren Namensauflösung aktiv Anzeige wird verfälscht oder zusätzliche DNS-Last entsteht bei Analyse gegebenenfalls numerische Anzeige verwenden Zeitabweichung ignoriert Client- und Servermitschnitt passen nicht zusammen Uhren und Zeitzonen prüfen Snapshot-Länge zu klein benötigte Protokolldaten fehlen Anforderung vor Aufnahme bestimmen Snapshot-Länge unbegrenzt unnötige Nutzdaten werden gespeichert erforderliche Länge bewusst festlegen Original direkt bearbeitet Nachvollziehbarkeit geht verloren Original und Arbeitskopie trennen Datei unverschlüsselt versendet Datenabfluss möglich freigegebenen sicheren Kanal verwenden PCAP öffentlich hochgeladen vertrauliche Daten offengelegt interne oder freigegebene Analyse Datei nur umbenannt Inhalt bleibt vollständig erhalten echte Reduktion und Prüfung durchführen Hash erst nach Bearbeitung erstellt ursprünglicher Zustand nicht belegt Hash unmittelbar nach Sicherung bilden Wireshark als Root gestartet unnötig große Angriffsfläche Capture-Funktion auf Dumpcap beschränken 27. Wie läuft ein sicherer Paketmitschnitt vollständig ab? Phase Vorgehen 1. Auftrag klären technisches Problem und Zweck dokumentieren 2. Freigabe einholen Zuständigkeit, Datenschutz und Sicherheit klären 3. Kommunikationsweg zeichnen Client, Netzwerkkomponenten und Server bestimmen 4. Messpunkt wählen so nah wie möglich am vermuteten Problem 5. Schnittstelle prüfen Interface, IP-Adresse und Route bestätigen 6. Filter festlegen Host, Port und Protokoll begrenzen 7. Umfang begrenzen Dauer, Paketanzahl, Dateigröße und Snapshot-Länge 8. Speicher schützen Zugriffsrechte und freien Speicherplatz prüfen 9. Aufnahme starten Startzeit und Werkzeugversion dokumentieren 10. Fehler reproduzieren genau definierte Aktion ausführen 11. Aufnahme stoppen unmittelbar nach dem relevanten Vorgang 12. Datei prüfen Zeitraum, Pakete, Fremdverkehr und Geheimnisse 13. Original sichern Hash bilden und Original unverändert ablegen 14. Arbeitskopie erzeugen Zeitfenster und relevante Kommunikation reduzieren 15. Technisch analysieren Protokollablauf und Fehlerhypothese untersuchen 16. Weitergabe vorbereiten Daten minimieren und Freigabe einholen 17. Ergebnis dokumentieren Ursache, Belege und Grenzen festhalten 18. Daten löschen Aufbewahrungsfrist und Löschbestätigung beachten 28. Kompakte Befehlsübersicht Aufgabe Befehl Kennzeichnung Capture-Schnittstellen anzeigen dumpcap -D [RO] tcpdump-Schnittstellen anzeigen tcpdump -D [RO] 60 Sekunden aufzeichnen dumpcap -i 1 -a duration:60 -w capture.pcapng [TEST][PRIV][FILE][SENS] gefiltert aufzeichnen dumpcap -i 1 -f "host 192.0.2.20 and tcp port 443" -a duration:60 -w capture.pcapng [TEST][PRIV][FILE][SENS] nach 10.000 Paketen stoppen dumpcap -i 1 -c 10000 -w capture.pcapng [TEST][PRIV][FILE][SENS] Paketlänge begrenzen dumpcap -i 1 -s 96 -a duration:60 -w capture.pcapng [TEST][PRIV][FILE][SENS] Ringpuffer dumpcap -i 1 -b duration:60 -b files:5 -w capture.pcapng [TEST][PRIV][FILE][SENS] Dateiinformationen capinfos capture.pcapng [RO][SENS] Protokollhierarchie tshark -r capture.pcapng -q -z io,phs [RO][SENS] IP-Endpunkte tshark -r capture.pcapng -q -z endpoints,ip [RO][SENS] TCP-Gespräche tshark -r capture.pcapng -q -z conv,tcp [RO][SENS] Zeitbereich exportieren editcap -A "START" -B "ENDE" original.pcapng arbeitskopie.pcapng [RO][FILE][SENS] Paketbereich exportieren editcap -r original.pcapng auszug.pcapng 200-750 [RO][FILE][SENS] Pakete nach Filter exportieren tshark -r original.pcapng -Y "ip.addr == 192.0.2.20" -w gefiltert.pcapng [RO][FILE][SENS] Geheimnisblöcke entfernen editcap --discard-all-secrets original.pcapng bereinigt.pcapng [RO][FILE][SENS] Kommentare entfernen editcap --discard-capture-comment --discard-packet-comments original.pcapng bereinigt.pcapng [RO][FILE][SENS] Paketdaten kürzen editcap -s 96 original.pcapng gekuerzt.pcapng [RO][FILE][SENS] SHA-256 unter Windows Get-FileHash .\capture.pcapng -Algorithm SHA256 [RO] SHA-256 unter Linux sha256sum capture.pcapng [RO] SHA-256 unter macOS shasum -a 256 capture.pcapng [RO] 29. Dokumentationsvorlage für einen Paketmitschnitt Ticketnummer: Auftraggebende Stelle: Ausführende Person: Freigabe erteilt durch: Freigabezeitpunkt: Datenschutzprüfung: Informationssicherheit informiert: Betriebsrat einbezogen oder nicht erforderlich: Technischer Zweck: Fehlerbeschreibung: Betroffene Systeme: Betroffene Benutzergruppe: Ausgeschlossene Systeme: Erlaubter Datenumfang: Capture-System: Betriebssystem: Capture-Werkzeug: Werkzeugversion: Capture-Schnittstelle: IP-Adresse der Schnittstelle: Capture-Position: Promiscuous Mode: Ja / Nein Monitor Mode: Ja / Nein Capture-Filter: Snapshot-Länge: Maximale Dauer: Maximale Paketanzahl: Maximale Dateigröße: Ringpuffer: Ja / Nein Anzahl Ringpufferdateien: Startzeit: Endzeit: Zeitzone: Zeitpunkt der Fehlerreproduktion: Durchgeführte Aktion: Originaldatei: Dateigröße: Paketanzahl: Erstes Paket: Letztes Paket: SHA-256 des Originals: Speicherort des Originals: Zugriffsberechtigte Personen: Arbeitskopie: Verwendeter Zeitfilter: Verwendeter Display-Filter: Entfernte Kommentare: Entfernte Entschlüsselungsgeheimnisse: Snapshot-Länge nach Bearbeitung: SHA-256 der Arbeitskopie: Ermittelte Beobachtungen: 1. 2. 3. Arbeitshypothese: Beleg: Gegenprüfung: Ermittelte Ursache: Weitergabe erforderlich: Ja / Nein Empfänger: Rechts- und Datenschutzprüfung: Weitergabedatei: SHA-256 der Weitergabedatei: Übertragungsweg: Übergabezeitpunkt: Löschvereinbarung mit Empfänger: Interne Aufbewahrungsfrist: Geplanter Löschtermin: Tatsächlicher Löschzeitpunkt: Löschung bestätigt durch: 30. Offizielle Quellen und weiterführende Dokumentation Wireshark Wireshark User’s Guide Wireshark Capture Options Wireshark Capture Filters Wireshark Display Filters dumpcap – offizielle Manual Page tshark – offizielle Manual Page editcap – offizielle Manual Page capinfos – offizielle Manual Page Wireshark Manual Pages tcpdump und libpcap tcpdump – offizielle Dokumentation pcap-filter – offizielle Filtersyntax Datenschutzrecht Datenschutz-Grundverordnung – EUR-Lex Bundesbeauftragte für den Datenschutz und die Informationsfreiheit Datenschutzkonferenz des Bundes und der Länder Welche rechtliche Grundlage, Beteiligung oder Dokumentation im konkreten Unternehmen erforderlich ist, muss durch die zuständigen Datenschutz-, Sicherheits- und Rechtsstellen entschieden werden. Die technische Möglichkeit eines Paketmitschnitts stellt keine automatische Berechtigung zur Durchführung dar.