# 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: 1. Was möchte ich mit diesem Befehl feststellen? 2. Welches Ergebnis erwarte ich bei einem funktionierenden System? 3. Welches Ergebnis würde meine Hypothese widerlegen? 4. Kann der Befehl den Zustand des Systems verändern? 5. 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: ```text [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]` ```cmd 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]` ```cmd 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]` ```cmd getmac /v ``` Ausführliche Ausgabe als Liste: ```cmd getmac /v /fo list ``` Ausgabe als CSV: ```cmd 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]` ```cmd ipconfig ``` Der Befehl zeigt unter anderem: - IPv4-Adressen; - IPv6-Adressen; - Subnetzmasken; - Standardgateways; - Adapter mit getrenntem Medium. **Vollständige Konfiguration anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd 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]` ```cmd 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]` ```cmd ipconfig /displaydns > "\dns-cache.txt" ``` **DNS-Clientcache leeren** Kennzeichnung: `[CHANGE]` ```cmd 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: ```cmd ipconfig /displaydns ``` Danach bei begründeter Hypothese: ```cmd ipconfig /flushdns ``` Anschließend denselben Namen erneut testen. **Dynamische DNS-Registrierung anstoßen** Kennzeichnung: `[TEST][CHANGE]` ```cmd 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]` ```cmd ipconfig /release "" ``` Für alle DHCP-konfigurierten IPv4-Adapter: ```cmd ipconfig /release ``` Dadurch wird die aktuelle DHCP-Konfiguration verworfen. Die Netzwerkverbindung kann unterbrochen werden. **DHCP-Konfiguration erneuern** Kennzeichnung: `[TEST][CHANGE]` ```cmd ipconfig /renew "" ``` Für alle DHCP-konfigurierten IPv4-Adapter: ```cmd ipconfig /renew ``` **DHCPv6-Konfiguration freigeben und erneuern** Kennzeichnung: `[CHANGE][DISRUPT]` ```cmd ipconfig /release6 "" ``` Kennzeichnung: `[TEST][CHANGE]` ```cmd 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** ```cmd ipconfig /all ``` **Nachher vergleichen** ```cmd 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]` ```cmd ping /4 192.0.2.25 ``` **IPv6-Ziel testen** Kennzeichnung: `[TEST]` ```cmd ping /6 server.example.test ``` **Namen testen** Kennzeichnung: `[TEST]` ```cmd ping server.example.test ``` Die erste Ausgabezeile zeigt normalerweise, in welche IP-Adresse der Name aufgelöst wurde. **Mehrere Anfragen senden** Kennzeichnung: `[TEST]` ```cmd 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]` ```cmd ping /n 10 /w 1000 192.0.2.25 ``` `/w 1000` wartet pro Anfrage maximal 1000 Millisekunden auf eine Antwort. **Dauerhaft testen** Kennzeichnung: `[TEST]` ```cmd 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** ```cmd ping /4 server.example.test ``` ```cmd ping /6 server.example.test ``` Damit lässt sich erkennen, ob nur einer der beiden Protokollpfade betroffen ist. **Paketgröße testen** Kennzeichnung: `[TEST]` ```cmd 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: ```cmd ping /4 /f /l 1464 192.0.2.25 ``` ```cmd 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** ```cmd ping 127.0.0.1 ``` Prüft grundlegende lokale IPv4-Verarbeitung. Der Test verlässt den Computer nicht. **2. Lokalen IPv6-Loopback testen** ```cmd ping ::1 ``` Prüft grundlegende lokale IPv6-Verarbeitung. **3. Eigene IP-Adresse testen** ```cmd ping ``` Prüft die Bindung der Adresse an den lokalen Netzwerkstack. Der Test beweist noch keine funktionierende physische Verbindung. **4. Standardgateway testen** ```cmd ping ``` Prüft die ICMP-Kommunikation zum Gateway, sofern dieses ICMP beantwortet. **5. Entfernte IP-Adresse testen** ```cmd ping ``` Prüft den gerouteten IP-Pfad ohne Abhängigkeit von der DNS-Namensauflösung. **6. Zielname testen** ```cmd 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]` ```cmd tracert server.example.test ``` **Namensauflösung der Zwischenstationen deaktivieren** Kennzeichnung: `[TEST]` ```cmd 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** ```cmd tracert /4 server.example.test ``` **IPv6 erzwingen** ```cmd tracert /6 server.example.test ``` **Maximale Hopanzahl begrenzen** ```cmd tracert /d /h 15 192.0.2.25 ``` **Wartezeit pro Antwort verringern** ```cmd 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]` ```cmd pathping 192.0.2.25 ``` **Ohne Namensauflösung** Kennzeichnung: `[TEST]` ```cmd pathping /n 192.0.2.25 ``` **Anzahl der Abfragen begrenzen** ```cmd pathping /n /q 20 192.0.2.25 ``` **Zeitabstand zwischen aufeinanderfolgenden Pings festlegen** ```cmd 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]` ```cmd 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]` ```cmd 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** ```text 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: 1. passende Zielpräfixe; 2. die spezifischste passende Route; 3. bei gleich spezifischen Routen die Metriken; 4. 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: ```text 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]` ```cmd arp -a ``` **Ein bestimmtes Ziel anzeigen** ```cmd arp -a 192.0.2.25 ``` **Tabelle eines bestimmten Interfaces anzeigen** ```cmd 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: ```cmd ping 192.0.2.25 ``` Danach ARP-Tabelle prüfen: ```cmd 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]` ```cmd 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: ```cmd 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]` ```cmd nslookup server.example.test ``` **Bestimmten DNS-Server abfragen** ```cmd nslookup server.example.test 192.0.2.53 ``` So können Antworten unterschiedlicher DNS-Server miteinander verglichen werden. **IPv4-A-Record abfragen** ```cmd nslookup -type=A server.example.test 192.0.2.53 ``` **IPv6-AAAA-Record abfragen** ```cmd nslookup -type=AAAA server.example.test 192.0.2.53 ``` **Mailserver abfragen** ```cmd nslookup -type=MX example.test 192.0.2.53 ``` **Nameserver einer Zone abfragen** ```cmd nslookup -type=NS example.test 192.0.2.53 ``` **TXT-Record abfragen** ```cmd nslookup -type=TXT example.test 192.0.2.53 ``` **SRV-Record abfragen** ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs.example.test 192.0.2.53 ``` **Reverse Lookup ausführen** ```cmd nslookup 192.0.2.25 192.0.2.53 ``` Dabei wird nach einem PTR-Record gesucht. **Interaktiven Modus starten** ```cmd nslookup ``` Beispiel innerhalb des interaktiven Modus: ```text 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]` ```cmd nbtstat /n ``` **NetBIOS-Namenscache anzeigen** ```cmd nbtstat /c ``` **Remote-Tabelle über den NetBIOS-Namen abfragen** Kennzeichnung: `[TEST][SENS]` ```cmd nbtstat /a ``` **Remote-Tabelle über die IPv4-Adresse abfragen** ```cmd 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]` ```cmd netstat ``` **Alle Verbindungen und Listener numerisch anzeigen** ```cmd netstat -an ``` **Verbindungen, Listener und Prozess-IDs anzeigen** ```cmd 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]` ```cmd netstat -abno ``` `-b` kann langsam sein und benötigt ausreichende Rechte. **Nach einem Port filtern** Kennzeichnung: `[RO][SENS]` ```cmd 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** ```cmd 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** ```cmd tasklist /FI "PID eq 1234" ``` Wenn mehrere Windows-Dienste von einem gemeinsamen `svchost.exe`-Prozess gehostet werden: ```cmd tasklist /SVC /FI "PID eq 1234" ``` **Protokollstatistiken anzeigen** ```cmd netstat -s ``` **Ethernet- und Protokollstatistiken anzeigen** ```cmd netstat -e -s ``` **Routingtabelle über netstat anzeigen** ```cmd netstat -r ``` Das entspricht funktional weitgehend: ```cmd route print ``` **Ausgabe regelmäßig aktualisieren** ```cmd 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]` ```cmd 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** ```cmd netsh interface ipv4 show interfaces ``` **IPv6-Interfaces anzeigen** ```cmd netsh interface ipv6 show interfaces ``` **IPv4-Konfiguration anzeigen** ```cmd netsh interface ipv4 show config ``` **IPv4-Adressen anzeigen** ```cmd netsh interface ipv4 show addresses ``` **IPv4-Routen anzeigen** ```cmd netsh interface ipv4 show route ``` **IPv4-Nachbarn anzeigen** ```cmd netsh interface ipv4 show neighbors ``` **IPv6-Adressen anzeigen** ```cmd netsh interface ipv6 show addresses ``` **IPv6-Routen anzeigen** ```cmd netsh interface ipv6 show route ``` **IPv6-Nachbarn anzeigen** ```cmd netsh interface ipv6 show neighbors ``` **Subinterfaces und MTU anzeigen** ```cmd 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]` ```cmd 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** ```cmd 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]` ```cmd netsh wlan show networks ``` **Sichtbare WLANs einschließlich BSSIDs anzeigen** ```cmd 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]` ```cmd netsh wlan show profiles ``` **Bestimmtes WLAN-Profil anzeigen** ```cmd netsh wlan show profile name="" ``` Die Liste gespeicherter SSIDs kann sensible Informationen über Standorte oder interne Netzwerknamen enthalten. **WLAN-Bericht erzeugen** Kennzeichnung: `[FILE][SENS]` ```cmd 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]` ```cmd 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: ```text 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]` ```cmd netsh advfirewall show allprofiles state ``` **Aktuelles Firewallprofil anzeigen** ```cmd netsh advfirewall show currentprofile ``` **Firewallrichtlinie des aktuellen Profils anzeigen** ```cmd netsh advfirewall show currentprofile firewallpolicy ``` **Protokollierung des aktuellen Profils anzeigen** ```cmd 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: 1. betroffenes Profil feststellen; 2. Richtung bestimmen; 3. Protokoll und Port bestimmen; 4. lokale und entfernte Adresse bestimmen; 5. passende Regeln und Logs prüfen; 6. nur bei Freigabe eine eng begrenzte temporäre Testregel verwenden; 7. Testregel anschließend wieder entfernen. --- **22. Diagnoseausgaben sichern** **IP-Konfiguration exportieren** Kennzeichnung: `[RO][FILE][SENS]` ```cmd ipconfig /all > "\ipconfig-all.txt" ``` **Routingtabelle exportieren** ```cmd route print > "\route-print.txt" ``` **ARP-Tabelle exportieren** ```cmd arp -a > "\arp-cache.txt" ``` **Verbindungen und Listener exportieren** ```cmd netstat -ano > "\netstat-ano.txt" ``` **Pfadtest exportieren** Kennzeichnung: `[TEST][FILE][SENS]` ```cmd tracert /d 192.0.2.25 > "\tracert.txt" ``` **Standardausgabe und Fehlermeldungen gemeinsam sichern** ```cmd pathping /n 192.0.2.25 > "\pathping.txt" 2>&1 ``` **An eine vorhandene Datei anhängen** ```cmd 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. ```cmd 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: ```cmd 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** ```cmd 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** ```cmd 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** ```cmd 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** ```cmd 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** ```cmd ping /n 50 ping /n 50 tracert /d pathping /n netstat -e -s ``` Bei WLAN zusätzlich: ```cmd 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** ```cmd 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`: - Microsoft Learn – `getmac`: - Microsoft Learn – `ipconfig`: - Microsoft Learn – Automatic Private IP Addressing: - Microsoft Learn – `ping`: - Microsoft Learn – `tracert`: - Microsoft Learn – `pathping`: - Microsoft Learn – `route`: - Microsoft Learn – `arp`: - Microsoft Learn – `nslookup`: - Microsoft Learn – `nbtstat`: - Microsoft Learn – `netstat`: - Microsoft Learn – TCP-Zustände: - Microsoft Learn – `tasklist`: - Microsoft Learn – `findstr`: - Microsoft Learn – Network Shell `netsh`: - Microsoft Learn – `netsh interface`: - Microsoft Learn – `netsh wlan`: - Microsoft Learn – `netsh winhttp`: - Microsoft Learn – `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** ```powershell 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** ```powershell 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** ```powershell 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** ```powershell 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** 1. Aktives Netzwerkprofil mit `Get-NetConnectionProfile` feststellen. 2. Firewallstatus des Profils mit `Get-NetFirewallProfile` prüfen. 3. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht. 4. Passende eingehende oder ausgehende Regel suchen. 5. Port-, Adress-, Programm- und Profilfilter der Regel prüfen. 6. 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** ```powershell $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** ```powershell Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress, ifIndex ``` **Schritt 2 – IP-Konfiguration prüfen** ```powershell Get-NetIPConfiguration -All ``` **Schritt 3 – Standardroute und DNS-Server prüfen** ```powershell Get-NetRoute -DestinationPrefix "0.0.0.0/0" Get-DnsClientServerAddress ``` **Schritt 4 – Lokales Standardgateway testen** ```powershell Test-NetConnection 192.0.2.1 -InformationLevel Detailed ``` **Schritt 5 – Externe IP-Adresse testen** ```powershell Test-NetConnection 1.1.1.1 -InformationLevel Detailed ``` **Schritt 6 – DNS-Auflösung testen** ```powershell Resolve-DnsName example.com -DnsOnly ``` **Schritt 7 – Zielport testen** ```powershell Test-NetConnection example.com -Port 443 -InformationLevel Detailed ``` **Schritt 8 – Route zum Ziel prüfen** ```powershell Find-NetRoute -RemoteIPAddress 1.1.1.1 Test-NetConnection example.com -TraceRoute ``` **Schritt 9 – Lokale Ports und Prozesse prüfen** ```powershell Get-NetTCPConnection -State Listen | Sort-Object LocalPort ``` **Schritt 10 – Firewallstatus prüfen** ```powershell 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](https://learn.microsoft.com/powershell/module/netadapter/) - [Microsoft Learn – NetTCPIP-Modul](https://learn.microsoft.com/powershell/module/nettcpip/) - [Microsoft Learn – DnsClient-Modul](https://learn.microsoft.com/powershell/module/dnsclient/) - [Microsoft Learn – NetSecurity-Modul](https://learn.microsoft.com/powershell/module/netsecurity/) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Windows-Firewall über die Befehlszeile verwalten](https://learn.microsoft.com/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line) # 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** ```text 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** ```bash 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 ' Ein UDP-Test mit `nc` kann ohne Antwort nicht zuverlässig beweisen, ob der UDP-Port offen oder geschlossen ist. UDP besitzt keinen TCP-Verbindungsaufbau.
---
15. Firewallstatus lesend prüfen Linux-Systeme können unterschiedliche Werkzeuge zur Firewallverwaltung einsetzen. Zuerst muss festgestellt werden, welches System tatsächlich aktiv ist. | Aufgabe | Linux-Befehl | |---|---| | nftables-Regelwerk anzeigen | `[RO][PRIV][SENS] sudo nft list ruleset` | | iptables-Filterregeln anzeigen | `[RO][PRIV][SENS] sudo iptables -S` | | iptables-Regeln mit Zählern anzeigen | `[RO][PRIV][SENS] sudo iptables -L -numeric -verbose` | | IPv6-iptables-Regeln anzeigen | `[RO][PRIV][SENS] sudo ip6tables -S` | | UFW-Status anzeigen | `[RO][PRIV] sudo ufw status verbose` | | firewalld-Status prüfen | `[RO] firewall-cmd --state` | | Aktive firewalld-Zonen anzeigen | `[RO][PRIV] sudo firewall-cmd --get-active-zones` | | Regeln der aktiven Zone anzeigen | `[RO][PRIV][SENS] sudo firewall-cmd --list-all` | | Alle firewalld-Zonen anzeigen | `[RO][PRIV][SENS] sudo firewall-cmd --list-all-zones` | | nftables-Dienststatus anzeigen | `[RO] systemctl status nftables --no-pager` | | firewalld-Dienststatus anzeigen | `[RO] systemctl status firewalld --no-pager` | | UFW-Dienststatus anzeigen | `[RO] systemctl status ufw --no-pager` | **Prüfpunkte** - Welches Firewall-Frontend wird tatsächlich verwendet? - Welches Regelwerk ist im Kernel aktiv? - Welche Eingangs- und Ausgangsregeln gelten? - Auf welche Schnittstelle oder Zone bezieht sich eine Regel? - Stimmen IPv4- und IPv6-Regeln überein? - Erhöhen sich die Paket- oder Bytezähler einer relevanten Regel? - Wird ein Port lokal geöffnet, aber durch die Firewall blockiert? > Die Firewall nicht pauschal deaktivieren. Zuerst müssen Dienstbindung, Route, verwendete Schnittstelle und passende Regeln geprüft werden.
---
16. Netzwerkdienste und Protokolle prüfen | Aufgabe | Linux-Befehl | |---|---| | Fehlgeschlagene Dienste anzeigen | `[RO] systemctl --failed` | | NetworkManager-Status anzeigen | `[RO] systemctl status NetworkManager --no-pager` | | systemd-networkd-Status anzeigen | `[RO] systemctl status systemd-networkd --no-pager` | | systemd-resolved-Status anzeigen | `[RO] systemctl status systemd-resolved --no-pager` | | Dienstprotokoll anzeigen | `[RO][PRIV] sudo journalctl -u NetworkManager --since "30 minutes ago"` | | networkd-Protokoll anzeigen | `[RO][PRIV] sudo journalctl -u systemd-networkd --since "30 minutes ago"` | | resolved-Protokoll anzeigen | `[RO][PRIV] sudo journalctl -u systemd-resolved --since "30 minutes ago"` | | Kernelmeldungen zum Netzwerk filtern | `[RO][PRIV] sudo dmesg --human \| grep -Ei 'link|network|ethernet|firmware|renamed|timeout|carrier'` | | Kernelmeldungen des aktuellen Starts | `[RO][PRIV] sudo journalctl -kernel -boot` | | Letzte Kernelmeldungen live verfolgen | `[RO][PRIV] sudo journalctl -kernel -follow` | | Startzeit eines Dienstes anzeigen | `[RO] systemctl show NetworkManager -property ActiveEnterTimestamp` | **Typische Protokollhinweise** - `link is down` - `link becomes ready` - `carrier lost` - `renamed from eth0` - `DHCP timeout` - `no lease` - `firmware failed to load` - `authentication failed` - `activation failed` - `DNSSEC validation failed` - `network unreachable` > Protokolle müssen immer mit Zeitstempel, betroffener Schnittstelle und vorhergehenden Ereignissen ausgewertet werden. Eine einzelne Meldung ohne Kontext reicht selten zur Ursachenbestimmung.
---
17. Diagnoseinformationen sichern und vergleichen | Aufgabe | Linux-Befehl | |---|---| | Linkinformationen speichern | `[RO][FILE][SENS] ip -details -statistics link show > 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** ```bash 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** ```bash cat /etc/os-release systemctl is-active NetworkManager systemctl is-active systemd-networkd ``` **Schritt 2 – Linkstatus prüfen** ```bash ip -brief link show ip -statistics link show ``` **Schritt 3 – IP-Adressen prüfen** ```bash ip -brief address show ``` **Schritt 4 – Standardroute und Routenauswahl prüfen** ```bash ip route show default ip route get 1.1.1.1 ip rule show ``` **Schritt 5 – Nachbartabelle prüfen** ```bash ip neighbour show ``` **Schritt 6 – Standardgateway testen** ```bash ping -c 4 192.0.2.1 ``` **Schritt 7 – Externe IP-Adresse testen** ```bash ping -c 4 1.1.1.1 ``` **Schritt 8 – DNS-Konfiguration prüfen** ```bash cat /etc/resolv.conf resolvectl status ``` **Schritt 9 – DNS-Auflösung testen** ```bash getent hosts example.com dig example.com ``` **Schritt 10 – Zielport testen** ```bash nc -vz -w 3 example.com 443 ``` **Schritt 11 – Lokale Ports und Prozesse prüfen** ```bash sudo ss -lntup ``` **Schritt 12 – Netzwerkpfad untersuchen** ```bash tracepath example.com mtr --report --numeric --report-cycles 20 example.com ``` **Schritt 13 – Firewallstatus prüfen** ```bash sudo nft list ruleset ``` **Schritt 14 – Netzwerkprotokolle prüfen** ```bash 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](https://man7.org/linux/man-pages/man8/ip.8.html) - [Linux-Manpage – ip-address](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [Linux-Manpage – ip-link](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [Linux-Manpage – ip-route](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [Linux-Manpage – ip-neighbour](https://man7.org/linux/man-pages/man8/ip-neighbour.8.html) - [Linux-Manpage – ss](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux-Manpage – ping](https://man7.org/linux/man-pages/man8/ping.8.html) - [NetworkManager-Dokumentation – nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html) - [NetworkManager-Dokumentation – nmcli-Beispiele](https://networkmanager.dev/docs/api/latest/nmcli-examples.html) - [systemd-Dokumentation – networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html) - [systemd-Dokumentation – resolvectl](https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html) - [systemd-Dokumentation – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) # 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** 1. Wahltaste beziehungsweise `Option` gedrückt halten. 2. In der Menüleiste auf das Wi-Fi-Symbol klicken. 3. **Wireless Diagnostics öffnen** auswählen. 4. 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** 1. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht. 2. Bind-Adresse des Dienstes prüfen. 3. Application-Firewallstatus prüfen. 4. PF-Status und Regeln prüfen. 5. Network Extensions und Sicherheitssoftware berücksichtigen. 6. 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|wifi|ethernet|dhcp|dns|route|link'` | **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** ```bash 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** ```bash 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** ```bash sw_vers ``` **Schritt 2 – Netzwerkdienst und Schnittstelle zuordnen** ```bash networksetup -listallhardwareports networksetup -listnetworkserviceorder ``` **Schritt 3 – Schnittstellenstatus prüfen** ```bash ifconfig -a netstat -ibn ``` **Schritt 4 – IP-Konfiguration prüfen** ```bash networksetup -getinfo "Wi-Fi" ipconfig getifaddr en0 ``` **Schritt 5 – Standardroute prüfen** ```bash route -n get default route -n get 1.1.1.1 ``` **Schritt 6 – Nachbartabelle prüfen** ```bash arp -an ndp -an ``` **Schritt 7 – Standardgateway testen** ```bash ping -c 4 192.0.2.1 ``` **Schritt 8 – Externe IP-Adresse testen** ```bash ping -c 4 1.1.1.1 ``` **Schritt 9 – DNS-Konfiguration prüfen** ```bash scutil --dns networksetup -getdnsservers "Wi-Fi" ``` **Schritt 10 – DNS-Auflösung testen** ```bash dscacheutil -q host -a name example.com dig example.com ``` **Schritt 11 – Proxy und VPN prüfen** ```bash scutil --proxy scutil --nwi ifconfig -l | tr ' ' '\n' | grep '^utun' ``` **Schritt 12 – Zielport testen** ```bash nc -vz -w 3 example.com 443 ``` **Schritt 13 – Lokale Ports prüfen** ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` **Schritt 14 – Netzwerkpfad prüfen** ```bash traceroute -n example.com ``` **Schritt 15 – Netzwerkqualität messen** ```bash networkQuality -v ``` **Schritt 16 – Firewall und Protokolle prüfen** ```bash /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](https://support.apple.com/guide/mac-help/mh11395/mac) - [Apple Support – Netzwerkstatus auf dem Mac prüfen](https://support.apple.com/guide/mac-help/check-the-status-of-your-network-on-mac-mchlp2291/mac) - [Apple Support – Wireless Diagnostics verwenden](https://support.apple.com/guide/mac-help/use-wireless-diagnostics-mchlf4de377f/mac) - [Apple Support – Wi-Fi-Statusmenü verwenden](https://support.apple.com/guide/mac-help/mchlfad426fa/mac) - [Apple Support – Wi-Fi-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/mh11935/mac) - [Apple Support – Informationen zu networksetup](https://support.apple.com/guide/remote-desktop/about-networksetup-apdd0c5a2d5/mac) - [Apple Support – Terminal-Benutzerhandbuch](https://support.apple.com/guide/terminal/welcome/mac) - 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** ```text [RO] tshark -D ``` Alternativ: ```text [RO] dumpcap -D ``` Beispielhafte Ausgabe: ```text 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: ```text 1. enp0s31f6 2. wlan0 3. lo ``` oder: ```text 1. en0 2. en1 3. lo0 ``` Die Schnittstelle kann über ihre Nummer oder ihren Namen ausgewählt werden: ```text [TEST][PRIV] tshark -i 1 ``` ```text [TEST][PRIV] tshark -i en0 ``` **Prüfmethode** 1. Die vermutete Schnittstelle auswählen. 2. Einen kurzen Mitschnitt starten. 3. Einen bekannten und autorisierten Test erzeugen, beispielsweise eine DNS-Abfrage oder einen Ping. 4. Prüfen, ob die erwarteten Pakete erscheinen. 5. 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** 1. Wireshark starten. 2. Die Schnittstelle anhand der Paketaktivität und der Systemkonfiguration auswählen. 3. Unter **Capture → Options** die Schnittstelle kontrollieren. 4. Falls erforderlich einen Capture-Filter eintragen. 5. Die Aufzeichnung starten. 6. Den Fehler möglichst einmal gezielt reproduzieren. 7. Die Aufzeichnung sofort danach beenden. 8. Die Datei im Format `pcapng` speichern. 9. Zeitpunkt, Client, Server, Testschritt und beobachtetes Verhalten dokumentieren. 10. 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** ```text tcp port 443 ``` **Display-Filter** ```text 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** ```text [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** ```text ip.addr == 192.0.2.10 && tcp.port == 443 ``` ```text dns || dhcp ``` ```text 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: ```text tcp.flags.syn ``` Um ausschließlich gesetzte SYN-Flags zu finden, muss der Wert geprüft werden: ```text 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** ```text [RO] tshark -D ``` ```text [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** ```text [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** ```text [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** ```text [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** ```text [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** ```text [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: ```text 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** ```text [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** ```text [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** ```text [RO][FILE][SENS] capinfos -T capture.pcapng ``` **Mehrere Dateien zusammenführen** ```text [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: ```text [RO][FILE][SENS] capinfos part1.pcapng part2.pcapng ```
--- **14. Wie wird eine TCP-Verbindung systematisch analysiert?**
TCP-Diagnose anzeigen **Schritt 1: Verbindungsaufbau suchen** ```text 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** ```text tcp.flags.reset == 1 ``` ```text tcp.analysis.retransmission ``` ```text tcp.analysis.duplicate_ack ``` ```text tcp.analysis.zero_window ``` ```text tcp.analysis.window_full ``` **TCP-Stream isolieren** Nach Auswahl eines TCP-Pakets kann in Wireshark verwendet werden: ```text Analyze → Follow → TCP Stream ``` Alternativ lässt sich nach einer Streamnummer filtern: ```text 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** ```text dns ``` **Nur DNS-Anfragen** ```text dns.flags.response == 0 ``` **Nur DNS-Antworten** ```text dns.flags.response == 1 ``` **Bestimmten Namen untersuchen** ```text dns.qry.name == "example.com" ``` **Fehlerantworten anzeigen** ```text 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** ```text [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** ```text dhcp ``` **Capture-Filter** ```text 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** ```text tls ``` **TLS-Handshake** ```text tls.handshake ``` **TLS-Warnungen und Fehler** ```text tls.alert_message ``` **TCP-Port 443 zusammen mit TLS** ```text tcp.port == 443 && tls ``` **Typischer vereinfachter Ablauf** 1. TCP-Verbindung wird aufgebaut. 2. Client sendet einen TLS-ClientHello. 3. Server sendet einen TLS-ServerHello. 4. Zertifikats- und Schlüsselparameter werden ausgetauscht. 5. 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** ```text 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** 1. Störung und erwartetes Verhalten dokumentieren. 2. Client, Server, IP-Adressen, Ports und Protokolle bestimmen. 3. Fehlerzeitpunkt und reproduzierbaren Test festlegen. 4. Berechtigung für den Mitschnitt prüfen. 5. Zeitsynchronisation der beteiligten Systeme prüfen. 6. Speicherort und Speicherplatz kontrollieren. **Aufzeichnung** 7. Richtige Schnittstelle mit `tshark -D` oder Wireshark bestimmen. 8. Einen kurzen Kontrollmitschnitt durchführen. 9. Einen angemessenen Capture-Filter setzen. 10. Zeit-, Paket- oder Dateigrößenbegrenzung festlegen. 11. Aufzeichnung starten. 12. Fehler genau einmal reproduzieren. 13. Aufzeichnung sofort beenden. 14. Datei eindeutig benennen und sicher speichern. **Analyse** 15. Zuerst Protokollhierarchie, Endpunkte und Konversationen prüfen. 16. Relevante Client-Server-Kommunikation isolieren. 17. ARP, DHCP und DNS vor TCP und Anwendung betrachten. 18. TCP-Verbindungsaufbau, Abbruch und Wiederholungen prüfen. 19. Anschließend TLS- oder Anwendungsprotokoll untersuchen. 20. Zeitstempel mit Server-, Firewall- und Anwendungslogs vergleichen. 21. Beobachtung und mögliche Ursache voneinander trennen. **Validierung** 22. Hypothese durch einen kontrollierten Vergleichstest prüfen. 23. Falls erforderlich, Mitschnitte an zwei Punkten vergleichen. 24. Nach einer Änderung denselben Test erneut durchführen. 25. 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](https://www.wireshark.org/docs/wsug_html_chunked/ChapterCapture.html) - [Wireshark User’s Guide – Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [Wireshark User’s Guide – Display Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) - [Wireshark Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [Offizielle TShark-Dokumentation](https://www.wireshark.org/docs/man-pages/tshark.html) - [Offizielle Dumpcap-Dokumentation](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [Offizielle Capinfos-Dokumentation](https://www.wireshark.org/docs/man-pages/capinfos.html) - [Offizielle Mergecap-Dokumentation](https://www.wireshark.org/docs/man-pages/mergecap.html) - [Offizielle Editcap-Dokumentation](https://www.wireshark.org/docs/man-pages/editcap.html) # 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** ```text [RO] tcpdump --version ``` Die Ausgabe nennt normalerweise sowohl die tcpdump- als auch die libpcap-Version. **Linux: Installation prüfen** ```text [RO] command -v tcpdump ``` **macOS: Installationspfad prüfen** ```text [RO] command -v tcpdump ``` **Windows** Unter Windows sollte für eine vergleichbare Aufgabe normalerweise TShark verwendet werden: ```powershell [RO] tshark --version ``` ```powershell [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** ```text [TEST][PRIV][SENS] sudo tcpdump ``` Das Lesen einer bereits vorhandenen Mitschnittdatei benötigt normalerweise keine Capture-Berechtigung: ```text [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** ```text [RO] tcpdump -D ``` Alternativ: ```text [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** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 ``` ```text [TEST][PRIV][SENS] sudo tcpdump -i en0 ``` **Loopbackverkehr aufzeichnen** Linux: ```text [TEST][PRIV][SENS] sudo tcpdump -i lo ``` macOS: ```text [TEST][PRIV][SENS] sudo tcpdump -i lo0 ``` **Mehrere reguläre Schnittstellen erfassen** ```text [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** ```text [TEST][PRIV][SENS] sudo tcpdump -i en0 -nn -c 20 ``` Danach wird ein bekannter, autorisierter Test erzeugt, beispielsweise: ```text 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: ```text [RO] tcpdump --version ``` ```text [RO] man tcpdump ```
--- **5. Wie wird ein kurzer, kontrollierter Mitschnitt durchgeführt?**
Grundlegende Mitschnittbefehle anzeigen **20 Pakete anzeigen und danach beenden** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20 ``` **100 Pakete in eine Datei schreiben** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap ``` **Nur Verkehr eines bestimmten Hosts aufzeichnen** ```text [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** ```text [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: ```text [Strg] + [C] ``` Nach dem Beenden zeigt tcpdump Zähler an: ```text packets captured packets received by filter packets dropped by kernel ``` Die genaue Bedeutung von `packets received by filter` ist betriebssystemabhängig. Besonders wichtig ist: ```text 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** ```text host 192.0.2.10 ``` **Zwei Bedingungen mit `and`** ```text host 192.0.2.10 and tcp port 443 ``` **Alternative Bedingungen mit `or`** ```text tcp port 80 or tcp port 443 ``` **Bedingung ausschließen** ```text not port 22 ``` **Gruppierung mit Klammern** ```text 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: ```text 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** ```text [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** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 192.0.2.10 and dst host 198.51.100.20' ``` **Nur Rückverkehr** ```text [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** ```text port 53 ``` erfasst TCP und UDP auf Port 53. ```text udp port 53 ``` erfasst ausschließlich UDP auf Port 53. ```text 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** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w dns.pcap 'port 53' ``` **DHCPv4-Aufzeichnung** ```text [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** ```text [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|tcp-ack) == tcp-syn` | | SYN und ACK gesetzt | `tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)` | | 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** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' ``` **SYN/ACK-Antworten anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' ``` **TCP-Resets anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' ``` **Nur TCP-Resets eines bestimmten Servers** ```text [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** ```text [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** ```text vlan ``` **Bestimmte VLAN-ID** ```text vlan 100 ``` **IPv4-Verkehr im VLAN 100** ```text vlan 100 and ip ``` **HTTPS-Verkehr im VLAN 100** ```text vlan 100 and tcp port 443 ``` **Aufzeichnung** ```text [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: ```text 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** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -tttt ``` **MAC-Adressen anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e ``` **Ausführliche Ausgabe** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -vv ``` **Hexadezimal- und ASCII-Ausgabe** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10 ``` **Link-Layer-Header, Hexadezimal- und ASCII-Daten** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -XX -c 10 ``` **Kurzausgabe** ```text [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** ```text [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** ```text [RO][FILE][SENS] tcpdump -nn -r capture.pcap ``` **Mit Datum und ausführlicher Ausgabe lesen** ```text [RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap ``` **Nur DNS aus einer vorhandenen Datei lesen** ```text [RO][FILE][SENS] tcpdump -nn -r capture.pcap 'port 53' ``` **Nur Verkehr eines Hosts lesen** ```text [RO][FILE][SENS] tcpdump -nn -r capture.pcap 'host 192.0.2.10' ``` **Paketanzahl einer Datei bestimmen, sofern von der installierten Version unterstützt** ```text [RO][FILE][SENS] tcpdump --count -r capture.pcap ``` Alternativ kann das Wireshark-Werkzeug Capinfos verwendet werden: ```text [RO][FILE][SENS] capinfos capture.pcap ``` **Datei während des Mitschnitts paketweise aktualisieren** ```text [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** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100 -w capture.pcap ``` Ohne Einheit verwendet `-C` Millionen Byte: ```text 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** ```text [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** ```text 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** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap' ``` Beispielhafte Dateinamen: ```text capture-20260731-140000.pcap capture-20260731-140500.pcap capture-20260731-141000.pcap ``` **Nach zwölf Fünf-Minuten-Dateien beenden** ```text [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: ```text 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** ```text -w 'capture-%Y%m%d-%H%M%S.pcap' ``` **Problematisches Beispiel** ```text -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`** ```text [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** ```text [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. ```text -s LÄNGE ``` Beispiel: ```text [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: ```text [|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: ```text 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: 1. Capture-Filter enger setzen. 2. Mitschnitt auf eine Datei schreiben statt alles im Terminal auszugeben. 3. Ausgabeoptionen wie `-A`, `-X`, `-XX` oder `-vvv` während des Live-Mitschnitts vermeiden. 4. Capture-Puffer vorsichtig vergrößern. 5. Snapshot-Länge nur bei fachlicher Begründung verkleinern. 6. Auf einem leistungsfähigeren oder geeigneteren System mitschneiden. 7. Festplattenleistung und freien Speicherplatz prüfen. 8. Netzwerk-TAP oder spezielle Capture-Hardware verwenden. **Capture-Puffer beispielsweise auf 4.096 KiB setzen** ```text [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** ```text [RO][FILE][SENS] tcpdump -K -nn -r capture.pcap ``` Live: ```text [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** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q in -nn ``` **Nur ausgehende DNS-Pakete** ```text [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: ```text src host 192.0.2.10 ``` oder: ```text 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** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 10 'host 192.0.2.10 and tcp port 443' ``` **Kompilierten BPF-Code anzeigen** ```text [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: ```text host 192.0.2.10 and (tcp port 80 or tcp port 443) ``` Filterdatei verwenden: ```text [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** ```text [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** ```text [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: ```text [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: ```text [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: ```text 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** ```text [RO] ip link show ``` ```text [RO] tcpdump -D ``` **Docker-Bridge untersuchen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i docker0 -nn -w docker-bridge.pcap ``` **Host-Schnittstelle und Container-IP filtern** ```text [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** 1. Störung, Sollzustand und Fehlerzeitpunkt dokumentieren. 2. Client, Server, IP-Adressen, Ports und Protokolle ermitteln. 3. Den erwarteten Netzwerkpfad bestimmen. 4. Berechtigung für den Mitschnitt prüfen. 5. Systemzeit und Zeitzone kontrollieren. 6. Freien Speicherplatz prüfen. 7. Schutzbedarf der Mitschnittdatei festlegen. **Schnittstelle prüfen** 8. Verfügbare Schnittstellen mit `tcpdump -D` anzeigen. 9. Einen kurzen Kontrollmitschnitt ohne engen Filter durchführen. 10. Mit einem bekannten Test prüfen, ob die richtige Schnittstelle ausgewählt wurde. **Mitschnitt planen** 11. Einen möglichst gezielten Capture-Filter formulieren. 12. Filter mit einer kleinen Paketanzahl testen. 13. Paket-, Größen- oder Zeitbegrenzung festlegen. 14. Dateinamen, Zielverzeichnis und Berechtigungen prüfen. **Mitschnitt durchführen** 15. tcpdump starten. 16. Fehler genau einmal reproduzieren. 17. Start- und Endzeit notieren. 18. Mitschnitt kontrolliert beenden. 19. Capture-Zähler und Kernel-Drops prüfen. 20. Kontrollieren, ob tcpdump noch läuft. **Analyse** 21. Datei zunächst mit `tcpdump -nn -r` prüfen. 22. Dateieigenschaften mit `capinfos` kontrollieren. 23. Datei anschließend in Wireshark oder TShark öffnen. 24. Kommunikationsrichtung, TCP-Handshake, DNS, TLS und Anwendung untersuchen. 25. Zeitstempel mit System-, Firewall- und Anwendungslogs vergleichen. **Validierung** 26. Beobachtung und vermutete Ursache getrennt dokumentieren. 27. Hypothese durch einen gezielten Vergleichstest prüfen. 28. Falls erforderlich, an einem zweiten Punkt mitschneiden. 29. Nach einer Änderung denselben Test erneut durchführen. 30. 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](https://www.tcpdump.org/) - [Offizieller tcpdump-Quellcode und Dokumentation](https://github.com/the-tcpdump-group/tcpdump) - [Offizielle tcpdump-Manpage im Quellcode](https://github.com/the-tcpdump-group/tcpdump/blob/master/tcpdump.1.in) - [Offizielles libpcap-Projekt](https://github.com/the-tcpdump-group/libpcap) - [Offizielle pcap-filter-Manpage im libpcap-Quellcode](https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-filter.manmisc.in) - [Wireshark User’s Guide – Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [Offizielle TShark-Dokumentation](https://www.wireshark.org/docs/man-pages/tshark.html) - [Offizielle Capinfos-Dokumentation](https://www.wireshark.org/docs/man-pages/capinfos.html) # 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: ```text [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: ```text [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** ```text [TEST][SENS] nmap 192.0.2.10 ``` **Kleines, ausdrücklich freigegebenes Netz** ```text [TEST][SENS] nmap 192.0.2.0/28 ``` **IPv6-Ziel** ```text [TEST][SENS] nmap -6 2001:db8::10 ``` **Ziele aus einer autorisiert erstellten Datei** ```text [TEST][FILE][SENS] nmap -iL targets.txt ``` **Zielbereich nur auflösen und auflisten, ohne Zielpakete zu senden** ```text [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** ```text [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** ```text [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** ```text [TEST][SENS] nmap -sn -n 192.0.2.0/28 ``` **Grund für die Bewertung anzeigen** ```text [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** ```text [TEST][PRIV][SENS] sudo nmap -sn -PE 192.0.2.0/28 ``` **TCP-SYN-Erkennung auf freigegebenen Ports** ```text [TEST][PRIV][SENS] sudo nmap -sn -PS22,80,443 192.0.2.0/28 ``` **TCP-ACK-Erkennung** ```text [TEST][PRIV][SENS] sudo nmap -sn -PA80,443 192.0.2.0/28 ``` **UDP-Erkennung auf einem gezielt freigegebenen Port** ```text [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. ```text [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: ```text Host seems down. ``` Mit `-Pn` wird der Portscan trotzdem durchgeführt. **Risiko bei großen Zielbereichen** ```text 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: ```text 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: ```text [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** ```text [TEST][SENS] nmap -p 22,80,443 192.0.2.10 ``` **Portbereich** ```text [TEST][SENS] nmap -p 8000-8100 192.0.2.10 ``` **Alle TCP-Ports** ```text [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** ```text [TEST][SENS] nmap --top-ports 100 192.0.2.10 ``` **Schneller Scan der häufigsten Ports** ```text [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** ```text [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. ```text [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** ```text [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. ```text [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** ```text [TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10 ``` **Mit Begründung und Versionserkennung** ```text [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** ```text [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: ```text [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** ```text [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. ```text [TEST][SENS] nmap -sV -p 22,80,443 192.0.2.10 ``` **Leichtere Versionserkennung** ```text [TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10 ``` **Intensität festlegen** ```text [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** ```text 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. ```text [TEST][PRIV][SENS] sudo nmap -O 192.0.2.10 ``` **Nur gezielte Ports und OS-Erkennung** ```text [TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10 ``` **Erkennungsversuche begrenzen** ```text [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** ```text [TEST][DISRUPT][SENS] nmap -sC -p 22,80,443 192.0.2.10 ``` `-sC` entspricht: ```text --script=default ``` Auch Standardskripte senden zusätzliche Anfragen an Dienste und sollten nur nach Freigabe verwendet werden. **Bestimmtes, zuvor geprüftes Skript** ```text [TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10 ``` **Skriptbeschreibung anzeigen** ```text [RO] nmap --script-help http-title ``` **Mehrere freigegebene Informationsskripte** ```text [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** ```text --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. ```text [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: ```text [TEST][SENS] nmap -sT -p 443 192.0.2.10 ``` Danach bei Bedarf: ```text [TEST][SENS] nmap -sV --version-light -p 443 192.0.2.10 ``` Und nur bei begründetem Bedarf: ```text [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** ```text [TEST][SENS] nmap -n -p 22,80,443 192.0.2.10 ``` **DNS-Auflösung für alle Ziele erzwingen** ```text [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** ```text [TEST][SENS] nmap -T3 -p 22,80,443 192.0.2.10 ``` **Rücksichtsvollere Prüfung** ```text [TEST][SENS] nmap -T2 -p 22,80,443 192.0.2.10 ``` **Maximale Paketrate begrenzen** ```text [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** ```text [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** ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oN server-scan.txt 192.0.2.10 ``` **XML-Ausgabe** ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oX server-scan.xml 192.0.2.10 ``` **Alle Hauptformate** ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10 ``` Dabei entstehen typischerweise: ```text server-scan.nmap server-scan.xml server-scan.gnmap ``` **Zusätzlich Terminalausgabe mit `tee` speichern** Linux und macOS: ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | tee server-scan.txt ``` PowerShell: ```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** ```text [TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-before 192.0.2.10 ``` **Nach der Änderung** ```text [TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-after 192.0.2.10 ``` Linux und macOS: ```text [RO][FILE][SENS] diff -u server-before.nmap server-after.nmap ``` PowerShell: ```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: ```powershell [RO] Resolve-DnsName server.example.com ``` Linux oder macOS: ```text [RO] dig server.example.com ``` **2. Host Discovery durchführen** ```text [TEST][SENS] nmap -sn --reason 192.0.2.10 ``` **3. Port unabhängig von Host Discovery prüfen** ```text [TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10 ``` **4. Dienst vorsichtig identifizieren** ```text [TEST][SENS] nmap -Pn -n -sV --version-light -p 443 192.0.2.10 ``` **5. Anwendungsebene prüfen** ```text [TEST][SENS] curl -vkI https://192.0.2.10/ ``` Bei namensabhängigen virtuellen Hosts sollte der korrekte DNS-Name verwendet werden: ```text [TEST][SENS] curl -vI https://server.example.com/ ``` **6. TLS gesondert prüfen** ```text [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: ```text 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. ```text Clientnetz A → Firewall → Servernetz Clientnetz B → Firewall → Servernetz ``` **Scan aus Netz A** ```text [TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-a.txt 192.0.2.10 ``` **Scan aus Netz B** ```text [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** 1. Auftrag und Ziel der Prüfung dokumentieren. 2. Zulässige Zieladressen und Ports festlegen. 3. Scanquelle und Netzwerksegment dokumentieren. 4. Empfindliche Systeme identifizieren. 5. Erlaubte Scanarten und maximale Rate festlegen. 6. Ansprechpartner und Abbruchkriterium festlegen. 7. Systemzeit und Speicherort der Ergebnisse prüfen. **Zielkontrolle** 8. Zielbereich zuerst mit `-sL -n` auflisten. 9. CIDR-Präfix und Ausschlüsse kontrollieren. 10. Mit einem einzelnen Testsystem beginnen. **Schrittweise Prüfung** 11. Host Discovery mit `-sn` durchführen. 12. Falls erforderlich einen bekannten Port mit `-Pn` prüfen. 13. Nur benötigte Ports mit `-p` angeben. 14. Zunächst TCP Connect oder SYN Scan verwenden. 15. UDP nur für konkret benötigte Ports prüfen. 16. `--reason` zur Interpretation hinzufügen. 17. Versionserkennung nur bei Bedarf verwenden. 18. NSE-Skripte einzeln prüfen und freigeben. 19. Scanrate und Zielsystemüberwachung beobachten. **Dokumentation** 20. Ausgabe mit `-oA` speichern. 21. Nmap-Version und verwendeten Befehl dokumentieren. 22. Beginn, Ende und Scanquelle festhalten. 23. Ergebnisse als Beobachtung und nicht sofort als Ursache dokumentieren. **Validierung** 24. Offene Ports mit einem Protokollwerkzeug prüfen. 25. Gefilterte Ports mit Firewall-Logs und Paketmitschnitten untersuchen. 26. Lokale Listener auf dem Zielsystem prüfen. 27. Nach einer Änderung denselben Scan erneut ausführen. 28. Ergebnisse vergleichen. 29. Zuständige Personen über Abschluss oder Auffälligkeiten informieren. 30. 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](https://nmap.org/book/man.html) - [Nmap – Target Specification](https://nmap.org/book/man-target-specification.html) - [Nmap – Host Discovery](https://nmap.org/book/man-host-discovery.html) - [Nmap – Port Scanning Basics](https://nmap.org/book/man-port-scanning-basics.html) - [Nmap – Port Scanning Techniques](https://nmap.org/book/man-port-scanning-techniques.html) - [Nmap – Port Specification and Scan Order](https://nmap.org/book/man-port-specification.html) - [Nmap – Service and Version Detection](https://nmap.org/book/man-version-detection.html) - [Nmap – OS Detection](https://nmap.org/book/man-os-detection.html) - [Nmap – Nmap Scripting Engine](https://nmap.org/book/man-nse.html) - [Nmap – Timing and Performance](https://nmap.org/book/man-performance.html) - [Nmap – Output](https://nmap.org/book/man-output.html) - [Nmap – Legal Notices and Inappropriate Usage](https://nmap.org/book/man-legal.html) - [Offizielle Npcap-Dokumentation](https://npcap.com/guide/) # 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: ```text 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: ```text 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: ```text 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** ```text Client → Server: TCP 5201 ``` **UDP-Test** ```text 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: ```text [TEST][DISRUPT] iperf3 -s -p 5002 ``` Client: ```text [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: ```text TCP 5002 UDP 5002 ``` **Port vor dem Test prüfen** Windows: ```powershell [TEST] Test-NetConnection 192.0.2.20 -Port 5201 ``` Linux: ```text [TEST] nc -vz 192.0.2.20 5201 ``` macOS: ```text [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** ```text [TEST][DISRUPT] iperf3 -s ``` **Server auf einem anderen Port** ```text [TEST][DISRUPT] iperf3 -s -p 5002 ``` **Server an eine bestimmte lokale IP-Adresse binden** ```text [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 ``` **Server nur für einen Test starten und danach beenden** ```text [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** ```text [TEST][DISRUPT] iperf3 -s -1 -B 192.0.2.20 -p 5201 ``` **Ausführliche Ausgabe** ```text [TEST][DISRUPT] iperf3 -s -V ``` **Serverausgabe in eine Datei schreiben** ```text [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** ```text [RO] ss -lntp | grep ':5201' ``` **macOS: Listener prüfen** ```text [RO][PRIV] sudo lsof -nP -iTCP:5201 -sTCP:LISTEN ``` **Windows mit Community-Build** ```powershell [RO] Get-NetTCPConnection -LocalPort 5201 -State Listen ``` **Prozess suchen** Linux: ```text [RO] pgrep -a iperf3 ``` macOS: ```text [RO] pgrep -fl iperf3 ``` Windows: ```powershell [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** ```text [TEST][DISRUPT] iperf3 -s -1 ``` **Auf dem Client** ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Ausgabe alle fünf Sekunden** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -i 5 ``` **Einheit Mbit/s erzwingen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -f m ``` **Serverausgabe zusätzlich am Client abrufen** ```text [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** ```text Client → Server ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` Dabei sendet der Client die Testdaten. **Umgekehrte Richtung** ```text Server → Client ``` ```text [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** ```text Client ↔ Server ``` ```text [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** 1. Client zum Server testen. 2. Server zum Client mit `-R` testen. 3. Ergebnisse vergleichen. 4. 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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 ``` **UDP-Test mit 100 Mbit/s** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 ``` **Umgekehrter UDP-Test** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R ``` **UDP-Test ohne iPerf3-interne Bitratenbegrenzung** ```text [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** ```text 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: ```text 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: ```text Niedriger Jitter ≠ automatisch niedrige Latenz ``` Für die absolute Laufzeit werden zusätzlich beispielsweise benötigt: - `ping`; - `fping`; - `pathping`; - Monitoringdaten; - anwendungsspezifische Messungen. **Paketverlust** ```text 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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 ``` **Stufe 2** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 25M -t 30 ``` **Stufe 3** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 50M -t 30 ``` **Stufe 4** ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 ``` **Acht parallele Streams** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 8 -t 30 ``` **Umgekehrte Richtung mit vier Streams** ```text [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** ```text 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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 60 ``` `-t 60` testet 60 Sekunden. **Bestimmte Datenmenge übertragen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -n 1G ``` **Bestimmte Anzahl Blöcke übertragen** ```text [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** ```text [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** ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10 ``` **Server an eine lokale IP-Adresse binden** ```text [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 ``` **Linux: an ein Interface binden, sofern unterstützt** ```text [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: ```powershell [RO] Get-NetIPConfiguration ``` Linux: ```text [RO] ip address show ``` macOS: ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 ``` **IPv6 erzwingen** ```text [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 ``` **IPv6-Reversetest** ```text [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: ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J ``` **Linux und macOS: JSON in Datei schreiben** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J > iperf3-result.json ``` **PowerShell mit Community-iPerf3** ```powershell [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J | Out-File -Encoding utf8 iperf3-result.json ``` **Direkte Logdatei** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile iperf3-result.log ``` **Zeitstempel hinzufügen** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --timestamps --logfile iperf3-result.log ``` **Zeilenweise JSON-Objekte während des Tests** ```text [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: ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **2. Gegenrichtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` **3. Einzelstream** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 1 -t 30 ``` **4. Vier Streams** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 ``` **5. CPU-Auslastung parallel beobachten** Linux: ```text [RO] top ``` macOS: ```text [RO] top ``` Windows: ```powershell [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** ```powershell [RO] Get-NetAdapter ``` ```powershell [RO] Get-NetAdapterStatistics ``` ```powershell [RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed ``` **Linux** ```text [RO] ip -s link show ``` ```text [RO] ethtool eth0 ``` ```text [RO][PRIV] sudo ethtool -S eth0 ``` **macOS** ```text [RO] ifconfig en0 ``` ```text [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** ```text [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: ```text 1500 Byte MTU - 20 Byte IPv4-Header - 20 Byte TCP-Header = 1460 Byte TCP-MSS ``` Bei IPv6 sind die Basisheader größer: ```text 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** ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -l 1200 ``` **IPv4-UDP mit gesetztem Don't-Fragment-Bit** ```text [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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Reverse-Richtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` **Kleinere Schreibgröße** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -l 512 ``` **MSS testweise begrenzen** ```text [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: ```text 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** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` ```text [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** ```text 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** ```text Client → lokaler iPerf3-Server ``` **Messung durch VPN** ```text Client → VPN-Tunnel → entfernter iPerf3-Server ``` **Normalrichtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Reverse-Richtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` **UDP mit kontrollierter Rate** ```text [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** ```text [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: ```text [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** 1. Fehlerbild und erwarteten Durchsatz dokumentieren. 2. Client, Server und Netzwerkpfad festlegen. 3. Testgenehmigung und Wartungszeitraum prüfen. 4. Maximale Testdauer und Datenrate festlegen. 5. iPerf3-Versionen auf beiden Endpunkten dokumentieren. 6. CPU-, Interface- und Monitoringansichten vorbereiten. 7. Firewallfreigabe für TCP und gegebenenfalls UDP prüfen. **Server** 8. Server möglichst kabelgebunden und leistungsfähig auswählen. 9. Server an die richtige Adresse binden. 10. Für Einzeltests möglichst `-1` verwenden. 11. Listener auf Port 5201 kontrollieren. **Basistest** 12. TCP-Einzelstream für 30 Sekunden durchführen. 13. TCP-Reverse-Test durchführen. 14. Sender- und Receiverwerte dokumentieren. 15. CPU- und Interface-Zähler prüfen. **Vertiefung** 16. Vier parallele Streams testen. 17. Ergebnis mit Einzelstream vergleichen. 18. UDP bei niedriger Rate beginnen. 19. Rate schrittweise erhöhen. 20. Jitter und Paketverlust dokumentieren. 21. IPv4 und IPv6 bei Bedarf getrennt testen. 22. WLAN-, VPN- oder VLAN-Pfade separat vergleichen. **Analyse** 23. Langsamen Pfad mit Ping, Traceroute und Paketmitschnitt untersuchen. 24. Firewall-, Switch- und VPN-Monitoring vergleichen. 25. MTU, MSS und Offloading nur bei konkreten Hinweisen untersuchen. 26. iPerf3-Ergebnis mit realer Anwendung vergleichen. **Abschluss** 27. Testbefehle und Ergebnisse speichern. 28. Temporäre Firewallfreigaben zurücknehmen. 29. Nicht mehr benötigten Serverprozess beenden. 30. 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](https://software.es.net/iperf/) - [ESnet – Invoking iPerf3 und offizielle Optionsreferenz](https://software.es.net/iperf/invoking.html) - [Offizielle iPerf3-FAQ von ESnet](https://software.es.net/iperf/faq.html) - [Offizielles iPerf3-Repository von ESnet](https://github.com/esnet/iperf) - [ESnet Fasterdata – iPerf3](https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/) - [ESnet Fasterdata – Throughput Tool Comparison](https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/throughput-tool-comparision/) - [ESnet Fasterdata – Multi-Stream iPerf3](https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/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: ```powershell [RO] curl.exe --version ``` Alias prüfen: ```powershell [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** ```text [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: ```text [TEST][SENS] curl https://example.com/ ``` Windows: ```powershell [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: ```html ... ``` **Explizites URL-Schema verwenden** Empfohlen: ```text https://example.com/ ``` Nicht empfohlen: ```text 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** ```text [TEST][SENS] curl 'https://example.com/search?q=test&lang=de' ``` Besonders Zeichen wie diese können von einer Shell interpretiert werden: ```text & ? * [ ] { } ``` 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: ```text [TEST][SENS] curl "https://example.com/search?q=test&lang=de" ```
--- **3. Wie werden HTTP-Header angezeigt?**
Headeroptionen anzeigen **Nur Antwortheader anfordern** ```text [TEST][SENS] curl -I https://example.com/ ``` `-I` beziehungsweise `--head` veranlasst curl bei HTTP, eine `HEAD`-Anfrage zu senden. **Header und Antwortinhalt anzeigen** ```text [TEST][SENS] curl -i https://example.com/ ``` `-i` fügt die Antwortheader vor dem Inhalt ein. **Antwortheader separat auf die Standardausgabe schreiben** ```text [TEST][SENS] curl -D - https://example.com/ ``` **Header in eine Datei schreiben** ```text [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: ```text [TEST][SENS] curl -sS -o /dev/null -D - https://example.com/ ``` Windows: ```powershell [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: ```text [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -sS -o NUL -w "%{http_code}\n" https://example.com/ ``` **Statuscode und Ziel-URL nach Weiterleitungen** Linux und macOS: ```text [TEST] curl -sS -L -o /dev/null -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ ``` Windows: ```powershell [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. ```text HTTP-Statuscode 404 curl-Exitcode 0 ``` Das bedeutet: ```text Übertragung technisch erfolgreich Anwendung meldet HTTP-Fehler ``` **Bei HTTP-Fehlern mit Exitcode ungleich 0 beenden** ```text [TEST] curl --fail https://example.com/missing ``` Kurzform: ```text [TEST] curl -f https://example.com/missing ``` **HTTP-Fehlercode liefern und Antwortinhalt behalten** ```text [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** ```text [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** ```text [TEST][SENS] curl -I http://example.com/ ``` Mögliche Ausgabe: ```text HTTP/1.1 301 Moved Permanently Location: https://example.com/ ``` **Weiterleitungen automatisch verfolgen** ```text [TEST][SENS] curl -L http://example.com/ ``` **Header aller Weiterleitungsstufen anzeigen** ```text [TEST][SENS] curl -L -I http://example.com/ ``` **Maximale Anzahl Weiterleitungen begrenzen** ```text [TEST][SENS] curl -L --max-redirs 5 https://example.com/ ``` **Effektive Ziel-URL ausgeben** Linux und macOS: ```text [TEST] curl -sS -L -o /dev/null -w "%{url_effective}\n" http://example.com/ ``` Windows: ```powershell [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 ```text [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: ```text > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/... > Accept: */* ``` ```text < HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 1256 ``` **Nur Header und Verbindungsinformationen, Inhalt verwerfen** Linux und macOS: ```text [TEST][SENS] curl -v -o /dev/null https://example.com/ ``` Windows: ```powershell [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** ```text [TEST][FILE][SENS] curl --trace-ascii curl-trace.txt https://example.com/ ``` **Trace mit Zeitstempeln** ```text [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/ ``` **Binären Trace schreiben** ```text [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** ```text -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: ```text [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: ```powershell [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: ```text [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: ```powershell [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** ```text DNS = time_namelookup ``` **TCP-Aufbau nach DNS** ```text TCP-Phase = time_connect - time_namelookup ``` **TLS-Handshake nach TCP-Aufbau** ```text TLS-Phase = time_appconnect - time_connect ``` **Serververarbeitung bis zum ersten Byte** Bei HTTPS vereinfacht: ```text Server-/Anwendungsphase = time_starttransfer - time_appconnect ``` **Übertragung nach dem ersten Byte** ```text 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: ```text 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** ```text [TEST] curl --connect-timeout 5 https://example.com/ ``` **Maximal 15 Sekunden für den gesamten Vorgang** ```text [TEST] curl --max-time 15 https://example.com/ ``` Kurzform: ```text [TEST] curl -m 15 https://example.com/ ``` **Kombination** ```text [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** ```text [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** ```text [TEST] curl -4 -v https://example.com/ ``` **IPv6 erzwingen** ```text [TEST] curl -6 -v https://example.com/ ``` **Nur Status und Ziel-IP vergleichen** Linux und macOS: ```text [TEST] curl -4 -sS -o /dev/null -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` ```text [TEST] curl -6 -sS -o /dev/null -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -4 -sS -o NUL -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` ```powershell [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`. ```text [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ ``` Dieser Befehl bedeutet: ```text 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** ```text [TEST][SENS] curl -v --resolve example.com:443:192.0.2.20 https://example.com/ ``` **HTTP ohne TLS** ```text [TEST][SENS] curl --resolve example.com:80:192.0.2.20 http://example.com/ ``` **Warum nicht nur die IP-Adresse aufrufen?** ```text 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** ```text 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`** ```text [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`** ```text [TEST][SENS] curl --connect-to example.com:443:192.0.2.20:8443 https://example.com/ ``` Damit verbindet sich curl tatsächlich mit: ```text 192.0.2.20:8443 ``` Die ursprüngliche URL bleibt: ```text 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** ```text [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** ```text [TEST][FILE][SENS] curl --cacert company-ca.pem https://internal.example.com/ ``` **TLS 1.2 oder höher anfordern** ```text [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** ```text [TEST][SENS] curl --tlsv1.2 --tls-max 1.2 https://example.com/ ``` **TLS 1.3 oder höher anfordern** ```text [TEST][SENS] curl --tlsv1.3 https://example.com/ ``` Die Unterstützung hängt von curl-Version und TLS-Bibliothek ab. **Clientzertifikat** ```text [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** ```text [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** ```text [TEST][SENS] curl --http1.1 -v https://example.com/ ``` **HTTP/2 anfordern** ```text [TEST][SENS] curl --http2 -v https://example.com/ ``` **HTTP/3 versuchen** ```text [TEST][SENS] curl --http3 -v https://example.com/ ``` **Ausschließlich HTTP/3** ```text [TEST][SENS] curl --http3-only -v https://example.com/ ``` Die Optionen funktionieren nur, wenn der installierte curl-Build die jeweilige Protokollversion unterstützt: ```text [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** ```text [TEST][SENS] curl -H "Accept: application/json" https://api.example.com/status ``` **Benutzerdefinierten Header setzen** ```text [TEST][SENS] curl -H "X-Diagnostic-ID: test-001" https://example.com/ ``` **Mehrere Header** ```text [TEST][SENS] curl -H "Accept: application/json" -H "X-Diagnostic-ID: test-001" https://api.example.com/status ``` **User-Agent setzen** ```text [TEST][SENS] curl -A "IT-Diagnose/1.0" https://example.com/ ``` Alternativ: ```text [TEST][SENS] curl -H "User-Agent: IT-Diagnose/1.0" https://example.com/ ``` **Header entfernen** ```text [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** ```text [TEST][SENS] curl "https://api.example.com/search?q=server&limit=10" ``` **Parameter URL-codieren** ```text [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äß: ```text https://api.example.com/search?q=Server%20Fehleranalyse&limit=10 ``` **Warum URL-Encoding wichtig ist** Zeichen wie diese besitzen in URLs eine besondere Bedeutung: ```text 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** ```text [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: ```text [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" -d "active=true" https://api.example.com/users ``` **POST mit JSON** ```text [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: ```text [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** ```text [TEST][FILE][CHANGE][SENS] curl -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users ``` **PUT** ```text [TEST][CHANGE][SENS] curl -X PUT -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users/123 ``` **PATCH** ```text [TEST][CHANGE][SENS] curl -X PATCH -H "Content-Type: application/json" -d '{"active":false}' https://api.example.com/users/123 ``` **DELETE** ```text [TEST][CHANGE][DISRUPT][SENS] curl -X DELETE https://api.example.com/users/123 ``` **OPTIONS** ```text [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** ```text [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" https://api.example.com/users ``` **Datei binär beziehungsweise unverändert senden** ```text [TEST][FILE][CHANGE][SENS] curl --data-binary @request.json https://api.example.com/import ``` **Wörtliches `@` senden** ```text [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** ```text [TEST][FILE][SENS] curl -o download.bin https://example.com/file.bin ``` **Remote-Dateinamen verwenden** ```text [TEST][FILE][SENS] curl -O https://example.com/file.bin ``` **Weiterleitung verfolgen und Remote-Dateinamen verwenden** ```text [TEST][FILE][SENS] curl -L -O https://example.com/file.bin ``` **Teilweise Übertragung fortsetzen** ```text [TEST][FILE][SENS] curl -C - -O https://example.com/file.bin ``` **Download bei Fehler entfernen** ```text [TEST][FILE][SENS] curl --fail --remove-on-error -o download.bin https://example.com/file.bin ``` **Datei mit PUT hochladen** ```text [TEST][FILE][CHANGE][SENS] curl -T upload.bin https://example.com/upload.bin ``` **Multipart-Formularupload** ```text [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** ```text [TEST][SENS] curl -u "max.mustermann" https://example.com/protected ``` curl fordert das Passwort interaktiv an. **Benutzername und Passwort direkt angeben** ```text [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** ```text [TEST][SENS] curl --basic -u "max.mustermann" https://example.com/protected ``` **Digest Authentication** ```text [TEST][SENS] curl --digest -u "max.mustermann" https://example.com/protected ``` **Unterstützte Methode automatisch auswählen** ```text [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** ```text [TEST][SENS] curl -H "Authorization: Bearer TOKEN_NICHT_HIER_EINTRAGEN" https://api.example.com/status ``` **Negotiate/Kerberos, sofern Build und Umgebung es unterstützen** ```text [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** ```text [TEST][SENS] curl -b "session=BEISPIELWERT" https://example.com/ ``` **Cookies aus Datei lesen** ```text [TEST][FILE][SENS] curl -b cookies.txt https://example.com/ ``` **Empfangene Cookies speichern** ```text [TEST][FILE][SENS] curl -c cookies.txt https://example.com/login ``` **Cookies lesen und aktualisiert wieder speichern** ```text [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** ```text [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/ ``` Langform: ```text [TEST][SENS] curl --proxy http://proxy.example.com:8080 https://example.com/ ``` **Proxy-Benutzername interaktiv verwenden** ```text [TEST][SENS] curl -x http://proxy.example.com:8080 -U "max.mustermann" https://example.com/ ``` **Proxy umgehen** ```text [TEST][SENS] curl --noproxy example.com https://example.com/ ``` **Proxy für alle Ziele umgehen** ```text [TEST][SENS] curl --noproxy "*" https://example.com/ ``` **Umgebungsvariablen prüfen** Linux und macOS: ```text [RO][SENS] env | grep -i proxy ``` PowerShell: ```powershell [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy' ``` Häufig verwendete Variablen: ```text 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: ```text [TEST][SENS] curl --noproxy "*" -v https://example.com/ ``` Über Proxy: ```text [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** ```text [TEST][SENS] curl --socks5-hostname 192.0.2.50:1080 https://example.com/ ``` **SOCKS5-Proxy, lokale DNS-Auflösung** ```text [TEST][SENS] curl --socks5 192.0.2.50:1080 https://example.com/ ``` **SOCKS4a** ```text [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 ```text [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: ```text Accept-Encoding: deflate, gzip, br, zstd ``` Die tatsächlich angebotenen Verfahren hängen vom curl-Build ab. **Header prüfen** ```text [TEST][SENS] curl --compressed -I https://example.com/ ``` Mögliche Antwort: ```text 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. ```text [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** ```text [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** ```text [TEST][SENS] curl --retry 3 https://example.com/ ``` **Maximale Gesamtzeit für Wiederholungen** ```text [TEST][SENS] curl --retry 3 --retry-max-time 30 https://example.com/ ``` **Feste Verzögerung zwischen Versuchen** ```text [TEST][SENS] curl --retry 3 --retry-delay 2 https://example.com/ ``` **Auch abgelehnte TCP-Verbindungen erneut versuchen** ```text [TEST][SENS] curl --retry 3 --retry-connrefused https://example.com/ ``` **Alle Fehler wiederholen** ```text [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: ```text [RO] curl --manual ``` **Exitcode unter Linux und macOS anzeigen** ```text curl -sS --fail-with-body https://example.com/health echo $? ``` **Exitcode unter PowerShell anzeigen** ```powershell curl.exe -sS --fail-with-body https://example.com/health $LASTEXITCODE ``` **Wichtige Unterscheidung** ```text HTTP-Statuscode ≠ curl-Exitcode ``` Beispiel: ```text 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** 1. Erwartete URL, Methode und Antwort dokumentieren. 2. Hostname, IP-Adresse, Port und Protokoll bestimmen. 3. Prüfen, ob Proxy, VPN oder Load Balancer beteiligt sind. 4. Authentifizierung und Schutzbedarf der Daten klären. 5. Ändernde Anfragen nur gegen freigegebene Testressourcen richten. **Grundtest** 6. curl-Version und unterstützte Funktionen prüfen. 7. URL mit explizitem `https://` oder `http://` verwenden. 8. Verbindung mit `-v` untersuchen. 9. HTTP-Statuscode und effektive URL ausgeben. 10. Exitcode kontrollieren. **Eingrenzung** 11. IPv4 mit `-4` und IPv6 mit `-6` vergleichen. 12. DNS mit `--resolve` kontrolliert umgehen. 13. Direktverbindung und Proxyverbindung vergleichen. 14. Redirect-Kette mit `-L -I` prüfen. 15. TLS normal und höchstens vergleichsweise mit `-k` testen. 16. HTTP/1.1 und HTTP/2 bei Bedarf vergleichen. 17. DNS-, TCP-, TLS-, TTFB- und Gesamtzeit messen. **Anwendung** 18. Header und Content-Type prüfen. 19. Erwartete HTTP-Methode verwenden. 20. Request-Body und Zeichenkodierung kontrollieren. 21. Authentifizierung ohne Offenlegung der Zugangsdaten testen. 22. API-Antwort und Serverlogs zeitlich vergleichen. **Validierung** 23. Ergebnis aus einem zweiten Netzwerksegment vergleichen. 24. Reverse-Proxy-, Firewall- und Anwendungslogs prüfen. 25. Bei Netzwerkverdacht Paketmitschnitt erstellen. 26. Nach einer Änderung denselben curl-Befehl erneut ausführen. 27. Befehl, Zeitpunkt, Exitcode, HTTP-Status und Zeiten dokumentieren. 28. 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`:** ```powershell [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](https://curl.se/docs/manpage.html) - [Offizielle curl-Dokumentationsübersicht](https://curl.se/docs/) - [Everything curl – Command Line Transfers](https://everything.curl.dev/usingcurl/) - [Everything curl – Verbose Operations](https://everything.curl.dev/usingcurl/verbose/) - [Everything curl – Name Resolve Tricks](https://everything.curl.dev/usingcurl/connections/name.html) - [Everything curl – HTTP Responses](https://everything.curl.dev/http/response.html) - [Everything curl – Proxies](https://everything.curl.dev/usingcurl/proxies/index.html) - [curl – Exit Codes](https://curl.se/libcurl/c/libcurl-errors.html) - [curl – SSL Certificate Verification](https://curl.se/docs/sslcerts.html) - [curl – Supported Protocols](https://curl.se/docs/manpage.html#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** ```text [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: ```text openssl version openssl s_client -help ```
--- **2. Wie wird eine grundlegende TLS-Verbindung getestet?**
Verbindung mit `s_client` anzeigen ```text [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** ```text [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** ```text [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: ```text [Strg] + [C] ``` Neuere OpenSSL-Versionen unterstützen einen nicht interaktiven Modus: ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -no-interactive ``` Vor Verwendung muss geprüft werden: ```text [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: ```text 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** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com ``` **API prüfen** ```text [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** ```text [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: ```text Hostname: wiki.example.com Test-IP: 192.0.2.20 Port: 443 ``` **Direkter TLS-Test gegen diese IP mit richtigem SNI** ```text [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: ```text [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** ```text [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** ```text 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: ```text [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: ```text 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** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_return_error ``` **Zusätzlich Hostnamen prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error ``` **Erwartetes positives Ergebnis** ```text Verification: OK ``` oder in der ausführlichen Ausgabe: ```text Verify return code: 0 (ok) ``` **Wichtig** ```text 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** ```text [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** ```text [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** ```text [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 ```text [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: ```text 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** ```text 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: ```text [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: ```text [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 ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text ``` **Kompakte Kerninformationen** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates ``` **SHA-256-Fingerabdruck** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 ``` **Public-Key-Information** ```text [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 ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName ``` Beispiel: ```text X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:api.example.com ``` **Weitere Erweiterungen** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext keyUsage ``` ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext extendedKeyUsage ``` ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext basicConstraints ``` ```text [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** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -dates ``` Ausgabe: ```text notBefore=... notAfter=... ``` **Nur Ablaufdatum** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -enddate ``` **Prüfen, ob das Zertifikat mindestens noch 30 Tage gültig ist** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000 ``` Berechnung: ```text 30 Tage × 24 Stunden × 60 Minuten × 60 Sekunden = 2.592.000 Sekunden ``` **Exitcode auswerten** Linux und macOS: ```text openssl x509 -in server-cert.pem -noout -checkend 2592000 echo $? ``` PowerShell: ```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: ```text server-cert.pem intermediate-ca.pem root-ca.pem ``` **Kette prüfen** ```text [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem ``` Erwartetes Ergebnis: ```text server-cert.pem: OK ``` **Zusätzlich Hostnamen prüfen** ```text [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** ```text [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** 1. Leaf-Zertifikat untersuchen. 2. Issuer des Leaf-Zertifikats bestimmen. 3. Passendes Zwischenzertifikat prüfen. 4. Issuer und Subject der Kettenglieder vergleichen. 5. CA-Eigenschaften kontrollieren. 6. Vertrauensanker eindeutig festlegen. 7. Gültigkeitszeiten aller Zertifikate prüfen. 8. 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** ```text [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** ```text [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** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 ``` **Ausschließlich TLS 1.3** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 ``` **Minimalversion festlegen, sofern unterstützt** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -min_protocol TLSv1.2 ``` **Maximalversion festlegen** ```text [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** ```text [RO] openssl ciphers -v ``` **Nur TLS-1.2-kompatible Auswahl untersuchen** ```text [RO] openssl ciphers -v -tls1_2 ``` **Nur TLS-1.3-Cipher-Suites anzeigen, sofern unterstützt** ```text [RO] openssl ciphers -v -tls1_3 ``` **Bestimmte TLS-1.2-Cipher-Auswahl testen** ```text [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** ```text [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** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1' ``` Mögliche Ausgabe: ```text ALPN protocol: h2 ``` oder: ```text ALPN protocol: http/1.1 ``` **Nur HTTP/2 anbieten** ```text [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: ```text [TEST][SENS] curl --http2 -v https://example.com/ ```
--- **19. Wie wird OCSP Stapling geprüft?**
OCSP-Statusantwort anzeigen ```text [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: ```text 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** ```text [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com ``` **SMTP Submission auf Port 587** ```text [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com ``` **IMAP mit STARTTLS** ```text [TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com ``` **POP3 mit STARTTLS** ```text [TEST][SENS] openssl s_client -starttls pop3 -connect mail.example.com:110 -servername mail.example.com ``` **LMTP mit STARTTLS, sofern unterstützt** ```text [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** ```text [TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com ``` **LDAPS mit direktem TLS** ```text [TEST][SENS] openssl s_client -connect ldap.example.com:636 -servername ldap.example.com ``` **PostgreSQL mit TLS-Aushandlung** ```text [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** ```text [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: ```text [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 ```text [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** ```text [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: ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com ``` Über Proxy: ```text [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** ```text [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** ```text [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** ```text [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** ```text [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** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout ``` **Schlüsselinformation ohne private Bestandteile** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -text_pub -noout ``` **Nicht unkontrolliert verwenden** ```text 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: ```text [RO][FILE][SENS] stat server-key.pem ``` macOS: ```text [RO][FILE][SENS] stat -x server-key.pem ``` Windows: ```powershell [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** ```text [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** ```text [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** ```text 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** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -text ``` **Subject anzeigen** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -subject ``` **CSR-Signatur prüfen** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -verify ``` **Öffentlichen Schlüssel des CSR ausgeben** ```text [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** ```text [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** ```text [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** ```text 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: ```text -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` **DER** DER ist ein binäres ASN.1-Format und besitzt keine lesbaren BEGIN-/END-Markierungen. **PEM-Zertifikat anzeigen** ```text [RO][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -noout -text ``` **DER-Zertifikat anzeigen** ```text [RO][FILE][SENS] openssl x509 -in certificate.der -inform DER -noout -text ``` **DER nach PEM konvertieren** ```text [CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM ``` **PEM nach DER konvertieren** ```text [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: ```text .p12 .pfx ``` Sie können enthalten: - Zertifikat; - Zwischenzertifikate; - Root-Zertifikate; - privaten Schlüssel; - Metadaten. **Inhalt anzeigen, aber keine privaten Schlüssel ausgeben** ```text [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout ``` **Nur Zertifikate anzeigen, keine privaten Schlüssel** ```text [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -nokeys ``` **Nur das Client- beziehungsweise Leaf-Zertifikat extrahieren** ```text [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out client-cert.pem ``` **CA-Zertifikate extrahieren** ```text [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -cacerts -nokeys -out ca-chain.pem ``` **Privaten Schlüssel extrahieren** ```text [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** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 ``` **Hash der gesamten Datei** ```text [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: ```powershell [RO][FILE][SENS] Get-FileHash .\server-cert.pem -Algorithm SHA256 ``` Linux: ```text [RO][FILE][SENS] sha256sum server-cert.pem ``` macOS: ```text [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** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -state ``` **TLS-Protokollnachrichten anzeigen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -msg ``` **Umfangreicher Trace, sofern unterstützt** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -trace ``` **TLS-Erweiterungen anzeigen** ```text [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** ```text [TEST][SENS] openssl s_client -4 -connect example.com:443 -servername example.com ``` **IPv6 erzwingen** ```text [TEST][SENS] openssl s_client -6 -connect example.com:443 -servername example.com ``` **Direkte IPv6-Adresse** ```text [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: ```powershell [RO] Resolve-DnsName example.com ``` Linux: ```text [RO] dig example.com ``` macOS: ```text [RO] dig example.com ``` **2. TCP-Port prüfen** Windows: ```powershell [TEST] Test-NetConnection example.com -Port 443 ``` Linux und macOS: ```text [TEST] nc -vz example.com 443 ``` **3. TLS mit SNI prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com ``` **4. Zertifikatsprüfung erzwingen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error ``` **5. Zertifikatsliste anzeigen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts ``` **6. TLS-Versionen getrennt prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 ``` ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 ``` **7. Anwendung prüfen** ```text [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** 1. Erwarteten Hostnamen, Ziel-IP und Port dokumentieren. 2. Klären, ob direktes TLS oder STARTTLS verwendet wird. 3. OpenSSL- beziehungsweise LibreSSL-Version prüfen. 4. Erwartete Zertifizierungsstelle und Zertifikatsnamen ermitteln. 5. Systemzeit und Zeitzone kontrollieren. 6. Private Schlüssel und Passwortquellen schützen. **Verbindung** 7. DNS-Auflösung prüfen. 8. TCP-Port prüfen. 9. TLS-Verbindung mit richtigem SNI aufbauen. 10. Tatsächlich ausgehandelte TLS-Version und Cipher Suite dokumentieren. 11. ALPN bei HTTP-Diensten prüfen. **Zertifikat** 12. Zertifikatsprüffehlermeldungen beachten. 13. Prüfung mit `-verify_return_error` erzwingen. 14. Hostnamen mit `-verify_hostname` prüfen. 15. Serverzertifikate mit `-showcerts` anzeigen. 16. Leaf- und Zwischenzertifikate getrennt untersuchen. 17. SAN, Issuer, Subject und Gültigkeit prüfen. 18. Kette mit `openssl verify` lokal nachvollziehen. **Vertiefung** 19. TLS 1.2 und TLS 1.3 getrennt testen. 20. IPv4 und IPv6 vergleichen. 21. Direkt- und Proxyverbindung vergleichen. 22. Bei mTLS Clientzertifikat und Schlüsselzuordnung prüfen. 23. Bei STARTTLS das richtige Anwendungsprotokoll angeben. 24. Nur bei Bedarf `-state`, `-msg` oder `-trace` verwenden. **Validierung** 25. HTTPS zusätzlich mit curl prüfen. 26. Server-, Proxy- und Firewall-Logs vergleichen. 27. Bei Netzwerkverdacht Paketmitschnitt erstellen. 28. Nach einer Änderung exakt denselben Test wiederholen. 29. Diagnoseausgaben vor Weitergabe auf sensible Daten prüfen. 30. 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](https://docs.openssl.org/) - [OpenSSL `s_client`](https://docs.openssl.org/3.6/man1/openssl-s_client/) - [OpenSSL `x509`](https://docs.openssl.org/3.6/man1/openssl-x509/) - [OpenSSL `verify`](https://docs.openssl.org/3.6/man1/openssl-verify/) - [OpenSSL `pkey`](https://docs.openssl.org/3.6/man1/openssl-pkey/) - [OpenSSL `req`](https://docs.openssl.org/3.6/man1/openssl-req/) - [OpenSSL `pkcs12`](https://docs.openssl.org/3.6/man1/openssl-pkcs12/) - [OpenSSL `ciphers`](https://docs.openssl.org/3.6/man1/openssl-ciphers/) - [OpenSSL `version`](https://docs.openssl.org/3.6/man1/openssl-version/) - [OpenSSL Verification Options](https://docs.openssl.org/3.6/man1/openssl-verification-options/) - [OpenSSL Passphrase Options](https://docs.openssl.org/3.6/man1/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: 1. Werkzeuge ausschließlich von Microsoft beziehungsweise über die offizielle Sysinternals-Seite beziehen. 2. Vor einer Analyse Zeitpunkt, betroffenen Computer, angemeldeten Benutzer und Fehlerbild dokumentieren. 3. Zuerst nur beobachten und Daten erfassen. 4. Prozesse, Handles, Verbindungen oder Autostarteinträge nicht vorschnell beenden beziehungsweise löschen. 5. Administratorrechte nur verwenden, wenn sie für die Untersuchung erforderlich sind. 6. Speicherabbilder, Process-Monitor-Aufzeichnungen und exportierte Listen als vertrauliche Daten behandeln. 7. VirusTotal-Abfragen nur unter Beachtung der betrieblichen Datenschutz- und Sicherheitsvorgaben verwenden. 8. Ä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** ```text C:\Admin\Sysinternals\ ``` **Start über Sysinternals Live** ```text \\live.sysinternals.com\tools\procexp.exe ``` ```text \\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** ```powershell [RO] Get-AuthenticodeSignature "C:\Admin\Sysinternals\procexp.exe" ``` ```powershell [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: ```text -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** 1. Process Explorer möglichst zunächst ohne Administratorrechte starten. 2. Prozessbaum und auffällige Prozesse identifizieren. 3. Bei unvollständiger Sichtbarkeit kontrolliert als Administrator neu starten. 4. Eigenschaften des betroffenen Prozesses öffnen. 5. Pfad, Kommandozeile, Benutzerkonto und übergeordneten Prozess prüfen. 6. CPU-, Speicher-, Datenträger- und Netzwerkentwicklung beobachten. 7. Digitale Signatur kontrollieren. 8. Bei hoher CPU-Auslastung die einzelnen Threads untersuchen. 9. 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. ```text 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** 1. Fehlerbild und genaue Uhrzeit notieren. 2. Process Monitor starten. 3. Laufende Aufzeichnung zunächst anhalten. 4. Bereits angezeigte Ereignisse leeren. 5. Filter auf den betroffenen Prozess setzen. 6. Aufzeichnung starten. 7. Fehler genau einmal reproduzieren. 8. Aufzeichnung sofort wieder anhalten. 9. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. 10. Originalaufzeichnung im PML-Format sichern. 11. 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** ```text Process Name is beispiel.exe Include ``` Weitere nützliche Filter: ```text 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: ```text [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** 1. Autoruns starten und vollständiges Einlesen abwarten. 2. Betroffenen Benutzer und Systemkontext beachten. 3. Eintrag, Pfad, Herausgeber und digitale Signatur prüfen. 4. Vor Veränderungen einen Export oder Screenshot erstellen. 5. Microsoft-Einträge nur ausblenden, um Fremdsoftware übersichtlicher zu prüfen. 6. Bei einem begründeten Verdacht einen Eintrag zunächst deaktivieren. 7. System oder Anmeldung kontrolliert testen. 8. Ergebnis dokumentieren. 9. 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. ```text [CHANGE] Deaktivieren: Eintrag abwählen ``` ```text [CHANGE][DISRUPT] Löschen: Eintrag dauerhaft entfernen ``` Autostarteinträge sollten während der Fehleranalyse nicht vorschnell gelöscht werden. **Autorunsc – Kommandozeilenversion** Alle Kategorien anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a * -s ``` Alle Kategorien mit Signaturprüfung und CSV-Ausgabe erfassen: ```cmd [RO][PRIV][FILE] autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv ``` Microsoft-Einträge ausblenden: ```cmd [RO][PRIV] autorunsc.exe -a * -m -s ``` Geplante Aufgaben anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a t -s ``` Dienste und nicht deaktivierte Treiber anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a s -s ``` Anmeldeeinträge anzeigen: ```cmd [RO] autorunsc.exe -a l -s ``` WMI-Autostarts anzeigen: ```cmd [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. ```text [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** 1. TCPView starten. 2. Nach Prozess, Port oder Zieladresse suchen. 3. Namensauflösung bei Bedarf deaktivieren, damit nur tatsächliche IP-Adressen erscheinen. 4. Prozess-ID und Programmpfad mit Process Explorer abgleichen. 5. Zieladresse, Port, Prozesskontext und Verbindungszeitpunkt dokumentieren. 6. Erst danach bewerten, ob die Verbindung erwartet ist. **Tcpvcon – Kommandozeilenversion** Aktive TCP-Verbindungen anzeigen: ```cmd [RO] tcpvcon.exe ``` Alle TCP- und UDP-Endpunkte anzeigen: ```cmd [RO] tcpvcon.exe -a ``` Namensauflösung deaktivieren: ```cmd [RO] tcpvcon.exe -a -n ``` CSV-Ausgabe erzeugen: ```cmd [RO][FILE] tcpvcon.exe -a -n -c > C:\Temp\tcp-endpoints.csv ``` Bestimmten Prozess untersuchen: ```cmd [RO] tcpvcon.exe -a -n beispiel.exe ``` Bestimmte PID untersuchen: ```cmd [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: ```text [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: ```cmd [RO][PRIV] handle.exe bericht.xlsx ``` Nach einem Pfadbestandteil suchen: ```cmd [RO][PRIV] handle.exe C:\Daten\Projekt ``` Handles eines bestimmten Prozesses anzeigen: ```cmd [RO][PRIV] handle.exe -p explorer ``` Handles einer bestimmten PID anzeigen: ```cmd [RO][PRIV] handle.exe -p 4321 ``` Besitzenden Benutzer anzeigen: ```cmd [RO][PRIV] handle.exe -u bericht.xlsx ``` Anzahl der verschiedenen Handle-Typen anzeigen: ```cmd [RO][PRIV] handle.exe -s ``` Alle Arten von Handles anzeigen: ```cmd [RO][PRIV] handle.exe -a -p 4321 ``` **Beispielausgabe sinngemäß interpretieren** ```text 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: ```cmd [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: ```cmd [RO] sigcheck.exe -nobanner -a "C:\Programme\Beispiel\beispiel.exe" ``` Hashwerte anzeigen: ```cmd [RO] sigcheck.exe -nobanner -h "C:\Programme\Beispiel\beispiel.exe" ``` Signatur und Zertifikatskette anzeigen: ```cmd [RO] sigcheck.exe -nobanner -i "C:\Programme\Beispiel\beispiel.exe" ``` Kombinierte Prüfung: ```cmd [RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe" ``` Nicht signierte ausführbare Dateien in `System32` suchen: ```cmd [RO][PRIV] sigcheck.exe -nobanner -u -e C:\Windows\System32 ``` Unterordner rekursiv untersuchen: ```cmd [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** ```text -v ``` fragt den VirusTotal-Status anhand des Dateihashs ab. ```text -vs ``` kann Dateien, die VirusTotal noch nicht kennt, zur Analyse hochladen. ```text [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: ```cmd [RO] pslist.exe ``` Prozessbaum anzeigen: ```cmd [RO] pslist.exe -t ``` Detaillierte Speicherinformationen anzeigen: ```cmd [RO] pslist.exe -m ``` Bestimmte PID untersuchen: ```cmd [RO] pslist.exe 4321 ``` Entfernten Computer abfragen: ```cmd [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** ```cmd [CHANGE][DISRUPT] pskill.exe 4321 ``` beendet einen Prozess. ```cmd [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** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma 4321 C:\Dumps ``` **Speicherabbild bei nicht reagierendem Fenster** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma -h beispiel.exe C:\Dumps ``` **Bis zu drei Speicherabbilder bei erhöhter CPU-Auslastung** ```cmd [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** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma -e beispiel.exe C:\Dumps ``` **Auf einen noch nicht gestarteten Prozess warten** ```cmd [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. ```text [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: ```cmd [PRIV][CHANGE] procdump.exe -ma -i C:\Dumps ``` Rücknahme: ```cmd [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: ```text [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: ```cmd [RO] listdlls.exe beispiel.exe ``` DLLs einer bestimmten PID anzeigen: ```cmd [RO] listdlls.exe 4321 ``` Nach Prozessen suchen, die eine bestimmte DLL geladen haben: ```cmd [RO] listdlls.exe beispiel.dll ``` Versionsinformationen anzeigen: ```cmd [RO] listdlls.exe -v beispiel.exe ``` Nicht signierte DLLs hervorheben beziehungsweise anzeigen: ```cmd [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: ```text Anwendungs- und Dienstprotokolle └─ Microsoft └─ Windows └─ Sysmon └─ Operational ``` Sysmon ist kein spontanes Read-only-Diagnosewerkzeug. Installation und Konfiguration verändern das System dauerhaft: ```cmd [PRIV][CHANGE] sysmon64.exe -accepteula -i config.xml ``` Aktuelle Konfiguration anzeigen: ```cmd [RO][PRIV] sysmon64.exe -c ``` Konfiguration aktualisieren: ```cmd [PRIV][CHANGE] sysmon64.exe -c config.xml ``` Sysmon deinstallieren: ```cmd [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. 1. Uhrzeit und wahrgenommene Auswirkung dokumentieren. 2. Mit Task-Manager oder Process Explorer den Prozess bestimmen. 3. CPU-Verlauf über einen angemessenen Zeitraum beobachten. 4. Prozesspfad, Benutzer, Kommandozeile und übergeordneten Prozess prüfen. 5. In Process Explorer die Prozesseigenschaften öffnen. 6. Unter `Threads` nach CPU-Auslastung sortieren. 7. Auffälligen Thread und zugehöriges Modul dokumentieren. 8. Ereignisanzeige und Anwendungsprotokolle zum selben Zeitpunkt prüfen. 9. Bei reproduzierbaren Lastspitzen kontrolliert ProcDump einsetzen. 10. 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** 1. Vollständigen Pfad dokumentieren. 2. Berechtigungen und Besitzverhältnisse prüfen. 3. Mit Process Explorer nach Dateiname oder Pfad suchen. 4. Alternativ Handle verwenden: ```cmd [RO][PRIV] handle.exe "C:\Daten\Projekt\bericht.xlsx" ``` 5. Prozessname, PID, Benutzerkonto und Zweck identifizieren. 6. Prüfen, ob der Prozess regulär geschlossen werden kann. 7. Bei einem Dienst den zuständigen Dienst bestimmen. 8. Anwendung oder Dienst kontrolliert schließen. 9. Dateioperation erneut testen. 10. 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** 1. Exakte Fehlermeldung und Uhrzeit dokumentieren. 2. Anwendungspfad und Version prüfen. 3. Digitale Signatur der Programmdatei prüfen: ```cmd [RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe" ``` 4. Ereignisanzeige und anwendungseigene Protokolle prüfen. 5. Process Monitor vorbereiten. 6. Filter auf den Prozessnamen setzen. 7. Aufnahme starten und Anwendung einmal starten. 8. Aufnahme sofort stoppen. 9. Letzte Zugriffe vor dem Prozessende untersuchen. 10. Besonders auf folgende Resultate achten: ```text ACCESS DENIED PATH NOT FOUND NAME NOT FOUND SHARING VIOLATION BAD IMAGE ``` 11. Geladene DLLs und deren Pfade prüfen. 12. Vergleich mit einem funktionierenden Referenzsystem durchführen. 13. 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 1. Lokale und entfernte Adresse dokumentieren. 2. Port, Protokoll und Verbindungsstatus erfassen. 3. Prozess-ID mit TCPView oder Tcpvcon bestimmen: ```cmd [RO] tcpvcon.exe -a -n ``` 4. Prozess-ID in Process Explorer untersuchen. 5. Dateipfad, Kommandozeile, Benutzer und übergeordneten Prozess prüfen. 6. Signatur und Hash der ausführbaren Datei erfassen. 7. DNS-Auflösung und Zielsystem kontrollieren. 8. Prüfen, ob die Verbindung zur Funktion der Anwendung passt. 9. Firewall-, Proxy- und Sicherheitsprotokolle zum selben Zeitpunkt vergleichen. 10. 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 ```text 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](https://learn.microsoft.com/sysinternals/) - [Sysinternals Suite](https://learn.microsoft.com/sysinternals/downloads/sysinternals-suite) - [Process Explorer](https://learn.microsoft.com/sysinternals/downloads/process-explorer) - [Process Monitor](https://learn.microsoft.com/sysinternals/downloads/procmon) - [Autoruns und Autorunsc](https://learn.microsoft.com/sysinternals/downloads/autoruns) - [TCPView und Tcpvcon](https://learn.microsoft.com/sysinternals/downloads/tcpview) - [Handle](https://learn.microsoft.com/sysinternals/downloads/handle) - [Sigcheck](https://learn.microsoft.com/sysinternals/downloads/sigcheck) - [PsTools](https://learn.microsoft.com/sysinternals/downloads/pstools) - [PsList](https://learn.microsoft.com/sysinternals/downloads/pslist) - [ProcDump](https://learn.microsoft.com/sysinternals/downloads/procdump) - [RAMMap](https://learn.microsoft.com/sysinternals/downloads/rammap) - [VMMap](https://learn.microsoft.com/sysinternals/downloads/vmmap) - [ListDLLs](https://learn.microsoft.com/sysinternals/downloads/listdlls) - [Sysmon](https://learn.microsoft.com/sysinternals/downloads/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: 1. Protokolle nur so umfangreich wie erforderlich erfassen. 2. Exportierte Logs geschützt speichern. 3. Zugriff auf autorisierte Personen begrenzen. 4. Vor externer Weitergabe sensible Inhalte redigieren. 5. Originaldateien möglichst unverändert sichern. 6. Arbeitskopien getrennt vom Original anlegen. 7. Aufbewahrungs- und Löschfristen beachten. 8. 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: ```text 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** 1. Uhrzeit und Zeitzone aller beteiligten Systeme prüfen. 2. Fehler reproduzieren und exakten Zeitpunkt notieren. 3. Passendes Protokoll bestimmen. 4. Zeitfenster begrenzen. 5. Nach Quelle, Dienst, Prozess oder Ereignis-ID filtern. 6. Das erste relevante Ereignis suchen. 7. Vorhergehende und nachfolgende Ereignisse betrachten. 8. Meldungen zwischen beteiligten Systemen zeitlich korrelieren. 9. Hypothese aufstellen. 10. 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. ```text 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** ```text 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. ```text 2026-07-31 14:30:00 ``` Ein Zeitstempel mit Offset ist eindeutig zuordenbar: ```text 2026-07-31T14:30:00+02:00 ``` UTC-Darstellung: ```text 2026-07-31T12:30:00Z ```
6. Wie werden Windows-Ereignisprotokolle grafisch untersucht? Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet: ```cmd [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** 1. Passendes Protokoll auswählen. 2. `Aktuelles Protokoll filtern` verwenden. 3. Zeitraum auf den Störungszeitraum begrenzen. 4. Ereignisebene auswählen. 5. Falls bekannt, Quelle und Ereignis-ID eingeben. 6. Ereignis in der Detailansicht öffnen. 7. Allgemeine und XML-Ansicht vergleichen. 8. Ereignisse unmittelbar davor und danach untersuchen. 9. 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** ```powershell [RO] Get-WinEvent -ListLog * | Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes ``` Nur aktivierte Protokolle anzeigen: ```powershell [RO] Get-WinEvent -ListLog * | Where-Object IsEnabled | Sort-Object LogName | Select-Object LogName, RecordCount ``` **Neueste Ereignisse des Systemprotokolls** ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 20 ``` **Neueste Ereignisse des Anwendungsprotokolls** ```powershell [RO] Get-WinEvent -LogName Application -MaxEvents 20 ``` **Ereignisse der letzten Stunde** ```powershell [RO] $Start = (Get-Date).AddHours(-1) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } ``` **Fehler und kritische Ereignisse der letzten 24 Stunden** ```powershell [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** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 7036 } -MaxEvents 20 ``` **Nach Provider filtern** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddHours(-4) } ``` **Mehrere Ereignis-IDs abfragen** ```powershell [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** ```powershell [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** ```powershell [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** ```cmd [RO][PRIV][FILE][SENS] wevtutil epl System C:\Temp\System.evtx ``` **Anwendungsprotokoll exportieren** ```cmd [RO][PRIV][FILE][SENS] wevtutil epl Application C:\Temp\Application.evtx ``` **Ereignisse mit PowerShell als CSV exportieren** ```powershell [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** ```powershell [RO][FILE][SENS] Get-WinEvent -LogName System -MaxEvents 100 | Export-Clixml -Path 'C:\Temp\System-Events.xml' ``` **Verfügbare Protokolle mit wevtutil auflisten** ```cmd [RO] wevtutil el ``` **Letzte zehn Systemereignisse im Textformat anzeigen** ```cmd [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: ```cmd [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** ```bash [RO] journalctl ``` **Neueste Einträge zuerst anzeigen** ```bash [RO] journalctl -r ``` **Aktuellen Systemstart untersuchen** ```bash [RO] journalctl -b ``` **Vorherigen Systemstart untersuchen** ```bash [RO] journalctl -b -1 ``` **Verfügbare Systemstarts anzeigen** ```bash [RO] journalctl --list-boots ``` **Nur Kernelmeldungen anzeigen** ```bash [RO] journalctl -k ``` **Kernelmeldungen des aktuellen Starts** ```bash [RO] journalctl -k -b ``` **Protokoll eines Dienstes anzeigen** ```bash [RO] journalctl -u ssh.service ``` ```bash [RO] journalctl -u nginx.service ``` **Protokoll eines Dienstes live verfolgen** ```bash [RO] journalctl -u nginx.service -f ``` Beenden mit: ```text Strg+C ``` **Ereignisse seit einem Zeitpunkt** ```bash [RO] journalctl --since "2026-07-31 09:30:00" ``` **Zeitfenster eingrenzen** ```bash [RO] journalctl \ --since "2026-07-31 09:30:00" \ --until "2026-07-31 10:00:00" ``` **Relative Zeitangaben** ```bash [RO] journalctl --since "30 minutes ago" ``` ```bash [RO] journalctl --since today ``` **Nach Priorität filtern** ```bash [RO] journalctl -p err ``` Fehler und schwerwiegendere Meldungen des aktuellen Starts: ```bash [RO] journalctl -b -p err ``` Warnungen und schwerwiegendere Meldungen eines Dienstes: ```bash [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** ```bash [RO] journalctl _PID=4321 ``` **Nach ausführbarer Datei filtern** ```bash [RO] journalctl _EXE=/usr/sbin/sshd ``` **Nach Benutzer-ID filtern** ```bash [RO] journalctl _UID=1000 ``` **Ausgabe ohne Pager** ```bash [RO] journalctl -u nginx.service --no-pager ``` **ISO-Zeitstempel verwenden** ```bash [RO] journalctl -u nginx.service -o short-iso ``` **Ausführliche Felder eines Ereignisses anzeigen** ```bash [RO] journalctl -u nginx.service -n 10 -o verbose ```
10. Wie wird der Status eines Linux-Dienstes einschließlich Logs geprüft? **Dienststatus anzeigen** ```bash [RO] systemctl status nginx.service ``` Ohne interaktiven Pager: ```bash [RO] systemctl status nginx.service --no-pager ``` Vollständige Zeilen ohne Kürzung: ```bash [RO] systemctl status nginx.service --no-pager --full ``` **Prüfen, ob der Dienst aktiv ist** ```bash [RO] systemctl is-active nginx.service ``` **Prüfen, ob der Dienst aktiviert ist** ```bash [RO] systemctl is-enabled nginx.service ``` **Fehlgeschlagene Units anzeigen** ```bash [RO] systemctl --failed ``` **Journal des Dienstes seit dem aktuellen Start** ```bash [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: ```text /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** ```bash [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** ```bash [RO] tail -n 50 /var/log/syslog ``` **Neue Zeilen live verfolgen** ```bash [RO] tail -f /var/log/syslog ``` **Datei auch nach Rotation weiterverfolgen** ```bash [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** ```bash [RO] grep -i "error" /var/log/syslog ``` **Mehrere Begriffe suchen** ```bash [RO] grep -Ei "error|failed|timeout|denied" /var/log/syslog ``` **Zeilennummern anzeigen** ```bash [RO] grep -Ein "error|failed|timeout|denied" /var/log/syslog ``` **Treffer mit Kontext anzeigen** ```bash [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: ```text 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** ```bash [RO] zless /var/log/auth.log.2.gz ``` **Komprimiertes Protokoll durchsuchen** ```bash [RO] zgrep -i "failed" /var/log/auth.log.2.gz ``` **Mehrere rotierte Dateien durchsuchen** ```bash [RO] zgrep -Ei "failed|denied|timeout" /var/log/auth.log.*.gz ``` Aktuelle und ältere unkomprimierte Dateien durchsuchen: ```bash [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** ```bash [RO] journalctl -k -b ``` **Klassische dmesg-Ausgabe** ```bash [RO][PRIV] sudo dmesg ``` Menschenlesbare Zeitstempel: ```bash [RO][PRIV] sudo dmesg --human ``` Nur Warnungen und Fehler anzeigen: ```bash [RO][PRIV] sudo dmesg --level=warn,err,crit,alert,emerg ``` Nach typischen Hardware- und Netzwerkproblemen suchen: ```bash [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: ```text Konsole ``` Oder über das Terminal: ```bash [RO] open -a Console ``` **Empfohlenes Vorgehen** 1. In der Seitenleiste den lokalen Mac auswählen. 2. Live-Anzeige nur für einen kurzen Zeitraum aktivieren. 3. Suchfeld nach Prozess, Subsystem, Kategorie oder Meldung filtern. 4. Fehler einmal reproduzieren. 5. Live-Anzeige wieder anhalten. 6. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. 7. Detailbereich des Ereignisses öffnen. 8. 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** ```bash [RO] log show --last 10m ``` **Letzte Stunde anzeigen** ```bash [RO] log show --last 1h ``` **Kompakte Darstellung** ```bash [RO] log show --last 10m --style compact ``` **Nach Prozess filtern** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari"' ``` **Nach Subsystem filtern** ```bash [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** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'eventMessage CONTAINS[c] "error"' ``` **Mehrere Bedingungen kombinieren** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari" AND eventMessage CONTAINS[c] "network"' ``` **Informations- und Debugmeldungen einbeziehen** ```bash [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** ```bash [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** ```bash [RO] log stream ``` **Kompakte Live-Ausgabe** ```bash [RO] log stream --style compact ``` **Bestimmten Prozess verfolgen** ```bash [RO] log stream \ --style compact \ --predicate 'process == "Safari"' ``` **Nach Meldungsinhalt filtern** ```bash [RO] log stream \ --style compact \ --predicate 'eventMessage CONTAINS[c] "timeout"' ``` **Informationsmeldungen einbeziehen** ```bash [RO] log stream --info --style compact ``` Beenden mit: ```text Strg+C ``` **Sicherer Ablauf** 1. Filter vorbereiten. 2. Live-Aufzeichnung starten. 3. Problem genau einmal reproduzieren. 4. Aufzeichnung sofort beenden. 5. 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** ```bash [RO] docker ps ``` Auch beendete Container anzeigen: ```bash [RO] docker ps -a ``` **Logs eines Containers anzeigen** ```bash [RO][SENS] docker logs beispiel-container ``` **Letzte 100 Zeilen anzeigen** ```bash [RO][SENS] docker logs --tail 100 beispiel-container ``` **Zeitstempel einblenden** ```bash [RO][SENS] docker logs --timestamps --tail 100 beispiel-container ``` **Logs live verfolgen** ```bash [RO][SENS] docker logs --follow --tail 100 beispiel-container ``` **Logs seit einem relativen Zeitpunkt** ```bash [RO][SENS] docker logs --since 30m beispiel-container ``` **Logs seit einem absoluten Zeitpunkt** ```bash [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ beispiel-container ``` **Zeitfenster begrenzen** ```bash [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** ```bash [RO] docker compose ps ``` **Logs eines Compose-Dienstes** ```bash [RO][SENS] docker compose logs --tail 100 beispiel-dienst ``` **Compose-Logs live verfolgen** ```bash [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: ```text 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: ```text 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** ```text 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** ```text 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** ```text Microsoft-Windows-DNS-Client Event ID 1014 Windows 11 ``` **Ungenaue Suchanfrage** ```text Internet geht nicht Fehler ``` **Quellenreihenfolge** 1. offizielle Herstellerdokumentation, 2. offizielle Knowledge Base oder Supportartikel, 3. offizielle Quellcode-Repositories und Issue-Tracker, 4. Dokumentation des eingesetzten Projekts, 5. seriöse Fachquellen, 6. 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** ```text 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 ```text 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](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [wevtutil – Microsoft Learn](https://learn.microsoft.com/windows-server/administration/windows-commands/wevtutil) - [Windows-Ereignisprotokollierung – Microsoft Learn](https://learn.microsoft.com/windows/win32/wes/windows-event-log) **Linux und systemd** - [journalctl – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemctl – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd-journald – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) - [systemd Journal Fields](https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html) **Apple** - [Konsole – Benutzerhandbuch für macOS](https://support.apple.com/guide/console/welcome/mac) - [Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/view-log-messages-cnsl1012/mac) - [Protokollmeldungen und Aktivitäten suchen](https://support.apple.com/guide/console/find-log-messages-and-activities-cnslbf30b61a/mac) - Lokale Befehlsreferenz: `man log` und `log help` **Docker** - [docker logs – Docker-Dokumentation](https://docs.docker.com/reference/cli/docker/container/logs/) - [Docker Logging Drivers](https://docs.docker.com/engine/logging/) - [docker compose logs](https://docs.docker.com/reference/cli/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** ```text 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** ```text requests_total = 150000 ``` Der Gesamtwert ist für eine aktuelle Belastung meist weniger aussagekräftig als seine Änderungsrate. PromQL-Beispiel: ```promql rate(http_requests_total[5m]) ``` **Gauge** ```text active_connections = 42 ``` Der Wert beschreibt den aktuellen Zustand und kann steigen oder fallen. PromQL-Beispiele: ```promql avg_over_time(active_connections[15m]) ``` ```promql max_over_time(active_connections[15m]) ``` **Fehlerrate berechnen** ```promql sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) ``` Für eine Prozentdarstellung: ```promql 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** ```text 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** ```text 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** ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ``` Alle logischen Prozessoren: ```powershell [RO] Get-Counter '\Processor(*)\% Processor Time' ``` Prozessbezogene CPU-Werte: ```powershell [RO] Get-Counter '\Process(*)\% Processor Time' ``` Mehrere Messungen im Abstand von zwei Sekunden: ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ` -SampleInterval 2 ` -MaxSamples 10 ``` **Linux** ```bash [RO] uptime ``` ```bash [RO] top ``` ```bash [RO] vmstat 1 10 ``` Falls `sysstat` installiert ist: ```bash [RO] mpstat -P ALL 1 10 ``` Prozesse nach CPU-Auslastung sortieren: ```bash [RO] ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head ``` **macOS** ```bash [RO] top -l 1 -o cpu ``` ```bash [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: ```bash [RO] uptime ``` Beispiel: ```text 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: ```bash [RO] nproc ``` macOS: ```bash [RO] sysctl -n hw.logicalcpu ``` **Vereinfachtes Beispiel** ```text 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. ```text 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** ```powershell [RO] Get-Counter '\Memory\Available MBytes' ``` ```powershell [RO] Get-Counter '\Memory\% Committed Bytes In Use' ``` ```powershell [RO] Get-Counter '\Memory\Pages/sec' ``` Prozesse nach Arbeitsspeichernutzung: ```powershell [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, @{Name='WorkingSetMiB';Expression={ [math]::Round($_.WorkingSet64 / 1MB, 1) }} ``` **Linux** ```bash [RO] free -h ``` ```bash [RO] vmstat 1 10 ``` Prozesse nach Speicheranteil: ```bash [RO] ps -eo pid,user,%mem,rss,vsz,comm --sort=-%mem | head ``` OOM-Ereignisse suchen: ```bash [RO][PRIV] sudo journalctl -k | grep -Ei 'out of memory|oom-killer|killed process' ``` **macOS** ```bash [RO] memory_pressure ``` ```bash [RO] vm_stat ``` ```bash [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** ```powershell [RO] Get-Counter '\PhysicalDisk(*)\% Disk Time' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Current Disk Queue Length' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Disk Reads/sec' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Disk Writes/sec' ``` Freien Speicherplatz prüfen: ```powershell [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** ```bash [RO] df -hT ``` ```bash [RO] df -i ``` Falls `sysstat` installiert ist: ```bash [RO] iostat -xz 1 10 ``` Prozessbezogene I/O-Werte: ```bash [RO] pidstat -d 1 10 ``` Kernelmeldungen zu I/O-Fehlern: ```bash [RO][PRIV] sudo journalctl -k | grep -Ei 'I/O error|timeout|reset|read-only|filesystem' ``` **macOS** ```bash [RO] df -h ``` ```bash [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** ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Adapterstatistiken: ```powershell [RO] Get-NetAdapterStatistics ``` Performance Counter: ```powershell [RO] Get-Counter '\Network Interface(*)\Bytes Total/sec' ``` ```powershell [RO] Get-Counter '\TCPv4\Segments Retransmitted/sec' ``` **Linux** ```bash [RO] ip -s link ``` ```bash [RO] ss -s ``` ```bash [RO] cat /proc/net/dev ``` TCP-Statistik: ```bash [RO] nstat ``` Treiber- und Adapterstatistiken: ```bash [RO][PRIV] sudo ethtool -S eth0 ``` **macOS** ```bash [RO] netstat -ib ``` ```bash [RO] netstat -s ``` ```bash [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: ```bash [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** ```text 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. ```text 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: ```bash [RO] cat /proc/pressure/cpu ``` ```bash [RO] cat /proc/pressure/memory ``` ```bash [RO] cat /proc/pressure/io ``` Beispiel: ```text 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: ```text 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** ```bash [RO] docker stats --no-stream ``` Nur ausgewählte Spalten: ```bash [RO] docker stats --no-stream \ --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}' ``` Containerstatus prüfen: ```bash [RO] docker ps -a ``` Konfigurierte Limits eines Containers untersuchen: ```bash [RO][SENS] docker inspect beispiel-container ``` OOM-Status prüfen: ```bash [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** ```promql up ``` Nur nicht erfolgreich abgefragte Targets: ```promql up == 0 ``` Fehlende Zeitreihe erkennen: ```promql 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** 1. Zeitbereich des Dashboards prüfen. 2. Zeitpunkt des letzten Datenpunkts prüfen. 3. Target- oder Agentstatus kontrollieren. 4. Datenquelle direkt abfragen. 5. Netzwerkverbindung zwischen Monitoring und Ziel prüfen. 6. Konfigurationsänderungen kontrollieren. 7. 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** ```text CPU > 80 % → sofort kritischer Alarm ``` **Bessere Regelidee** ```text 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. ```text 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. ```text 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: ```text 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:** 1. Was ist betroffen? 2. Welche Benutzerwirkung besteht? 3. Seit wann besteht das Problem? 4. Welcher Messwert löste den Alarm aus? 5. Wie lange besteht die Bedingung? 6. Wer ist zuständig? 7. Welches Dashboard und Runbook gehören dazu? 8. 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** 1. Zeitfenster auf den Störungszeitraum einstellen. 2. Zeitzone des Dashboards prüfen. 3. Zeitpunkt einer gemeldeten Störung markieren. 4. Benutzerorientierte Signale prüfen: - Verfügbarkeit, - Antwortzeit, - Fehlerrate, - Anfragemenge. 5. Technische Ressourcen prüfen: - CPU, - RAM, - Datenträger, - Netzwerk. 6. Deployments, Updates und Wartungsereignisse einblenden. 7. Betroffene Instanzen mit funktionierenden Instanzen vergleichen. 8. Zeitfenster vor und nach dem Ereignis betrachten. 9. Rohdaten oder detailliertere Ansicht öffnen. 10. Hypothese anhand von Logs oder Traces prüfen. **Zoomfehler vermeiden** Ein Wert kann je nach gewähltem Zeitraum unterschiedlich wirken: ```text 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** ```text Benutzer melden täglich zwischen 02:00 und 02:30 Uhr lange Antwortzeiten. ``` **Vorgehen** 1. Benutzerwirkung mit p95- oder p99-Antwortzeit bestätigen. 2. Anfragerate und Fehlerrate im selben Zeitraum prüfen. 3. CPU-, RAM-, Datenträger- und Netzwerkverlauf vergleichen. 4. Geplante Aufgaben und Backups prüfen. 5. Datenbankverbindungen und Abfragedauer kontrollieren. 6. Logs nach Timeouts und Warteschlangen durchsuchen. 7. Mit einem störungsfreien Zeitraum vergleichen. 8. Abhängigkeiten und Storage überprüfen. 9. Ursache durch kontrollierte zeitliche oder technische Änderung testen. 10. Ergebnis über mehrere Tage beobachten. **Beispiel einer Korrelation** ```text 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** ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, SizeRemaining, Size ``` Größte Dateien in einem bekannten Untersuchungsverzeichnis: ```powershell [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** ```bash [RO] df -hT ``` ```bash [RO][PRIV] sudo du -xhd 1 /var | sort -h ``` **macOS** ```bash [RO] df -h ``` ```bash [RO][PRIV] sudo du -xhd 1 /Library | sort -h ``` **Prognosebeispiel** ```text 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** ```text 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 ```text 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](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Windows Performance Monitor – Microsoft Learn](https://learn.microsoft.com/windows-server/administration/windows-commands/perfmon) - [Leistungsprobleme unter Windows untersuchen](https://learn.microsoft.com/troubleshoot/windows-server/performance/troubleshoot-performance-problems-in-windows) - [Get-NetAdapterStatistics – Microsoft Learn](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterstatistics) - [Get-Volume – Microsoft Learn](https://learn.microsoft.com/powershell/module/storage/get-volume) **Linux** - [Linux Pressure Stall Information – Kernel-Dokumentation](https://docs.kernel.org/accounting/psi.html) - Lokale Befehlsreferenzen: `man top`, `man vmstat`, `man iostat`, `man mpstat`, `man free` und `man proc` **Prometheus** - [Prometheus-Metriktypen](https://prometheus.io/docs/concepts/metric_types/) - [PromQL-Funktionen](https://prometheus.io/docs/prometheus/latest/querying/functions/) - [Prometheus Alerting Rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) - [Prometheus Best Practices](https://prometheus.io/docs/practices/) **Grafana** - [Grafana Alerting](https://grafana.com/docs/grafana/latest/alerting/) - [Best Practices für Grafana-Dashboards](https://grafana.com/docs/grafana/latest/visualizations/dashboards/build-dashboards/best-practices/) - [Umgang mit No Data und Error](https://grafana.com/docs/grafana/latest/alerting/fundamentals/alert-rule-evaluation/nodata-and-error-states/) **Docker** - [docker stats – Docker-Dokumentation](https://docs.docker.com/reference/cli/docker/container/stats/) - [Docker Runtime Metrics](https://docs.docker.com/engine/containers/runmetrics/) > 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: ```text [TEST][PRIV][FILE][SENS] ``` Vor jeder Aufzeichnung müssen mindestens folgende Punkte geklärt werden: 1. Gibt es einen konkreten technischen Anlass? 2. Liegt eine ausreichende betriebliche und rechtliche Freigabe vor? 3. Welche Systeme und Kommunikationsverbindungen dürfen erfasst werden? 4. Wer ist für die Aufzeichnung verantwortlich? 5. Welcher Zeitraum ist erforderlich? 6. Welche Daten sollen ausdrücklich nicht erfasst werden? 7. Wo wird die Datei gespeichert? 8. Wer darf die Datei auswerten? 9. Darf sie an Hersteller oder Dienstleister weitergegeben werden? 10. 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:** ```text „Es ist nur für die Technik.“ ``` ```text „Die Verbindung ist verschlüsselt.“ ``` ```text „Wir schneiden nur kurz mit.“ ``` Auch ein kurzer technischer Mitschnitt kann personenbezogene oder vertrauliche Daten enthalten.
4. Welche Freigaben sollten vor Beginn dokumentiert werden? ```text 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** ```text So nah wie möglich am vermuteten Problem mitschneiden. ``` Bei komplexen Problemen können zwei gleichzeitige Mitschnitte sinnvoll sein: ```text 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** ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex ``` IP-Konfiguration zuordnen: ```powershell [RO] Get-NetIPConfiguration ``` Wireshark-Schnittstellen anzeigen: ```cmd [RO] dumpcap.exe -D ``` ```cmd [RO] tshark.exe -D ``` **Linux** ```bash [RO] ip -brief address ``` ```bash [RO] ip route ``` ```bash [RO] dumpcap -D ``` ```bash [RO] tcpdump -D ``` **macOS** ```bash [RO] ifconfig ``` Standardroute und verwendetes Interface: ```bash [RO] route -n get default ``` Wireshark-Schnittstellen: ```bash [RO] dumpcap -D ``` ```bash [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? ```text 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: 1. richtige Schnittstelle, 2. enger Capture-Filter, 3. kurze Aufzeichnungsdauer, 4. begrenzte Paketlänge oder Dateigröße. **Capture-Filter nach Host** ```text host 192.0.2.20 ``` **Nur Kommunikation zwischen zwei Systemen** ```text host 192.0.2.10 and host 192.0.2.20 ``` **Nur HTTPS zu einem Ziel** ```text host 192.0.2.20 and tcp port 443 ``` **Nur DNS zu einem bestimmten DNS-Server** ```text host 192.0.2.53 and port 53 ``` **Nur TCP zwischen zwei Systemen** ```text tcp and host 192.0.2.10 and host 192.0.2.20 ``` **Bestimmtes Subnetz ausschließen** ```text 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** ```text host 192.0.2.20 and tcp port 443 ``` **Entsprechender Display-Filter** ```text ip.addr == 192.0.2.20 && tcp.port == 443 ``` Ein Display-Filter reduziert nicht den sensiblen Inhalt der gespeicherten Originaldatei. ```text 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** ```bash [RO] dumpcap -D ``` **60 Sekunden auf Schnittstelle 1 mitschneiden** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -a duration:60 \ -w capture.pcapng ``` **Gezielter HTTPS-Mitschnitt** ```bash [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** ```bash [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** ```bash [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: ```bash [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: ```bash [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** ```bash [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** ```bash [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** ```bash [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** ```bash [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: ```bash [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. ```text 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** ```bash [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: ```text [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: ```powershell [RO] Get-Volume ``` Linux: ```bash [RO] df -h ``` macOS: ```bash [RO] df -h ``` **Dateigröße beobachten** Windows: ```powershell [RO] Get-Item '.\capture.pcapng' | Select-Object FullName, Length, LastWriteTime ``` Linux und macOS: ```bash [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: ```bash [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** ```bash [RO][SENS] tshark -r capture.pcapng -q -z io,phs ``` **Kommunikationsbeziehungen** ```bash [RO][SENS] tshark -r capture.pcapng -q -z endpoints,ip ``` ```bash [RO][SENS] tshark -r capture.pcapng -q -z conv,tcp ``` **Prüffragen** 1. Enthält die Datei den erwarteten Zeitraum? 2. Ist die richtige Schnittstelle erfasst? 3. Ist der Zielverkehr enthalten? 4. Wurde unbeabsichtigter Fremdverkehr gespeichert? 5. Sind unverschlüsselte Inhalte sichtbar? 6. Enthält die Datei eingebettete Entschlüsselungsgeheimnisse? 7. Sind Kommentare oder Metadaten vorhanden? 8. Ist eine weitere Reduktion erforderlich? 9. Muss die Originaldatei erhalten bleiben? 10. 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** ```bash [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: ```bash [RO][FILE][SENS] editcap \ -r \ original.pcapng \ arbeitskopie.pcapng \ 200-750 ``` **Erste 500 Pakete übernehmen** ```bash [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** ```bash [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** ```bash [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: ```bash [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** ```bash [RO][FILE][SENS] editcap \ --discard-all-secrets \ original.pcapng \ ohne-secrets.pcapng ``` **Capture- und Paketkommentare entfernen** ```bash [RO][FILE][SENS] editcap \ --discard-capture-comment \ --discard-packet-comments \ original.pcapng \ ohne-kommentare.pcapng ``` **Kombiniert** ```bash [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: ```bash [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** ```bash [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. ```text 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** ```powershell [RO] Get-FileHash ` 'C:\Diagnose\original.pcapng' ` -Algorithm SHA256 ``` Hash in Datei dokumentieren: ```powershell [RO][FILE] Get-FileHash ` 'C:\Diagnose\original.pcapng' ` -Algorithm SHA256 | Format-List | Out-File 'C:\Diagnose\original.pcapng.sha256.txt' ``` **Linux** ```bash [RO] sha256sum original.pcapng ``` ```bash [RO][FILE] sha256sum original.pcapng \ > original.pcapng.sha256 ``` **macOS** ```bash [RO] shasum -a 256 original.pcapng ``` ```bash [RO][FILE] shasum -a 256 original.pcapng \ > original.pcapng.sha256 ``` **Erneut prüfen** Linux: ```bash [RO] sha256sum -c original.pcapng.sha256 ``` macOS: ```bash [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: ```text 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: ```cmd [CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /inheritance:r ``` Einem ausdrücklich festgelegten Konto Zugriff gewähren: ```cmd [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: ```cmd [RO] icacls "C:\Diagnose\TICKET-4711" ``` **Linux und macOS** Verzeichnis nur für den Eigentümer zugänglich machen: ```bash [CHANGE] chmod 700 /pfad/TICKET-4711 ``` Datei nur für den Eigentümer les- und schreibbar machen: ```bash [CHANGE] chmod 600 /pfad/TICKET-4711/original.pcapng ``` Berechtigungen prüfen: ```bash [RO] ls -ld /pfad/TICKET-4711 ``` ```bash [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: 1. Empfänger und Zweck bestätigen. 2. Vertragliche und datenschutzrechtliche Zulässigkeit prüfen. 3. Nur den erforderlichen Zeit- und Datenbereich exportieren. 4. Unnötige Pakete entfernen. 5. Kommentare und eingebettete Geheimnisse entfernen. 6. Datei auf unverschlüsselte Inhalte prüfen. 7. Freigegebene Kopie getrennt speichern. 8. Hash der freigegebenen Datei berechnen. 9. Sicheren Übertragungsweg verwenden. 10. Kennwort oder Schlüssel über einen getrennten Kanal übermitteln. 11. Übergabe im Ticket dokumentieren. 12. 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: ```text [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 ```text 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](https://www.wireshark.org/docs/wsug_html/) - [Wireshark Capture Options](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureOptions.html) - [Wireshark Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [Wireshark Display Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) - [dumpcap – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) - [editcap – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/editcap.html) - [capinfos – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/capinfos.html) - [Wireshark Manual Pages](https://www.wireshark.org/docs/man-pages/) **tcpdump und libpcap** - [tcpdump – offizielle Dokumentation](https://www.tcpdump.org/manpages/tcpdump.1.html) - [pcap-filter – offizielle Filtersyntax](https://www.tcpdump.org/manpages/pcap-filter.7.html) **Datenschutzrecht** - [Datenschutz-Grundverordnung – EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [Bundesbeauftragte für den Datenschutz und die Informationsfreiheit](https://www.bfdi.bund.de/) - [Datenschutzkonferenz des Bundes und der Länder](https://www.datenschutzkonferenz-online.de/) > 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.