1. Grundlagen der systematischen Fehleranalyse

1.0 Diagnoseansatz – Systematische Fehleranalyse

Zweck dieser Seite

Diese Seite beschreibt die grundlegende Denk- und Arbeitsweise bei der professionellen IT-Fehleranalyse.

Sie ist die Einführungsseite des Kapitels. Konkrete Befehle, Befundformulare und detaillierte Diagnoseabläufe folgen auf den nächsten Seiten.

Was bedeutet systematische Fehleranalyse?

Systematische Fehleranalyse bedeutet, eine Störung nicht durch zufälliges Ausprobieren zu bearbeiten.

Stattdessen wird:

  1. das sichtbare Problem beschrieben;
  2. der betroffene Bereich eingegrenzt;
  3. der technische Datenpfad verstanden;
  4. eine mögliche Ursache als Hypothese formuliert;
  5. die Hypothese mit einem gezielten Test geprüft;
  6. nur die nachgewiesene Ursache behoben;
  7. die vollständige Funktion anschließend verifiziert.

Das Ziel ist nicht nur, das Symptom kurzfristig zu beseitigen. Die tatsächliche technische Ursache soll gefunden, behoben und dokumentiert werden.

Ein Symptom ist keine Ursache

Eine Störung wird zunächst meistens nur als Symptom wahrgenommen.

Beispiele:

Symptom Mögliche Ursachen
„Das Internet funktioniert nicht“ Interface, Kabel, VLAN, DHCP, Gateway, DNS, Proxy, Firewall, VPN oder Provider
„Der Server ist langsam“ CPU, RAM, Datenträger, Netzwerk, DNS, Anwendung, Datenbank, Backup oder Hypervisor
„Die Anmeldung funktioniert nicht“ Konto, Passwort, DNS, Uhrzeit, Kerberos, Domain Controller, MFA oder Berechtigungen
„Die Webseite ist nicht erreichbar“ DNS, Routing, Firewall, TCP-Port, TLS, Proxy, Webserver oder Anwendung
„Der Container startet nicht“ Image, Architektur, Konfiguration, Port, Volume, Rechte, Abhängigkeit oder Ressourcenlimit

Aus einem Symptom dürfen deshalb nicht sofort konkrete Reparaturmaßnahmen abgeleitet werden.

Typische Denkfehler

Vorschnelle Festlegung

Nach dem ersten Hinweis wird sofort eine Ursache angenommen.

Beispiel:

Der Hostname funktioniert nicht. Also ist der DNS-Server ausgefallen.

Der DNS-Server könnte erreichbar sein und trotzdem einen falschen Record liefern. Ebenso könnten DNS-Suffix, Clientcache, hosts-Datei, VPN-DNS oder Split-DNS die Ursache sein.

Bestätigungsfehler

Es werden nur noch Informationen gesucht, welche die eigene Vermutung bestätigen. Widersprechende Befunde werden ignoriert.

Korrelation mit Ursache verwechseln

Ein Fehler tritt nach einem Update auf. Daraus wird geschlossen, dass das Update die Ursache sein muss.

Die zeitliche Nähe ist ein wichtiger Hinweis, aber noch kein Nachweis.

Nur die eigene Komponente untersuchen

Der Clientadministrator untersucht nur den Client, der Netzwerkadministrator nur den Switch und der Serveradministrator nur den Server.

Eine Verbindung funktioniert jedoch nur, wenn der gesamte Datenpfad funktioniert.

Erfolgreichen Einzeltest überbewerten

Ein erfolgreicher Ping beweist nicht, dass DNS, TCP-Port, TLS, Authentifizierung oder Anwendung funktionieren.

Mehrere Änderungen gleichzeitig durchführen

Werden gleichzeitig DNS geändert, Firewallregeln angepasst und Dienste neu gestartet, kann anschließend nicht mehr festgestellt werden, welche Maßnahme tatsächlich wirksam war.

Neustart mit Fehlerbehebung verwechseln

Ein Neustart kann einen fehlerhaften Zustand vorübergehend beseitigen. Die Ursache ist dadurch nicht automatisch bekannt oder dauerhaft behoben.

Grundlegender Diagnosekreislauf

Symptom → Eingrenzung → Datenpfad → Hypothese → Test → Befund → Korrektur → Verifikation → Dokumentation

Nach jedem Test wird entschieden:

Erst eine bestätigte Hypothese führt zu einer konkreten Korrektur.

Die wichtigsten Eingrenzungsmethoden

Methode Grundidee Typischer Einsatz
Bottom-up Von Hardware und Verbindung zur Anwendung arbeiten Link-, Kabel-, VLAN- und Netzwerkprobleme
Top-down Bei Benutzer und Anwendung beginnen Anwendungs-, Zugriffs- und Authentifizierungsfehler
Divide and Conquer Datenpfad in Abschnitte teilen Lange oder komplexe Verbindungswege
Follow the Path Anfrage und Antwort vollständig verfolgen Routing, Firewall, NAT, Proxy und VPN
Known Good Comparison Mit funktionierendem System vergleichen Einzelne Benutzer, Clients oder Ports
Controlled Swap Komponente kontrolliert austauschen Kabel, Port, SFP, Netzteil oder Client
Two-Sided Analysis Sender und Empfänger gleichzeitig untersuchen Paketverlust und Kommunikationsabbrüche
Historical Comparison Aktuellen Zustand mit früherem Zustand vergleichen Änderungen, Updates und Performanceprobleme

Keine Methode ist grundsätzlich immer die richtige. Die Auswahl hängt vom Symptom und vom bekannten Datenpfad ab.

Technischen Datenpfad betrachten

Ein Dienst besteht häufig aus mehreren voneinander abhängigen Komponenten.

Beispiel:

Benutzer → Client → Netzwerkinterface → Switch oder Access Point → VLAN → Gateway → Firewall → Server → Anwendung → Datenbank

Für jede Komponente muss geklärt werden:

Dadurch lässt sich der fehlerhafte Abschnitt schrittweise eingrenzen.

Sender, Empfänger, Hinweg und Rückweg

Eine vollständige Verbindungsanalyse betrachtet immer vier Bereiche:

Bereich Fragestellung
Sender Wird die Anfrage korrekt erzeugt und gesendet?
Hinweg Erreicht die Anfrage das Ziel?
Empfänger Nimmt das Ziel die Anfrage an und antwortet es?
Rückweg Erreicht die Antwort den ursprünglichen Sender?

Eine Anfrage kann den Server erreichen, obwohl die Antwort wegen einer fehlenden Rückroute, einer Firewall oder asymmetrischem Routing verloren geht.

Vergleich mit einem funktionierenden System

Ein bekannt funktionierendes Vergleichssystem ist häufig aussagekräftiger als eine allgemeine Vermutung.

Verglichen werden können:

Entscheidend ist, möglichst nur einen Unterschied gleichzeitig zu untersuchen.

Beweise vor Veränderungen sichern

Viele technische Informationen sind flüchtig.

Dazu gehören:

Deshalb gilt:

Erst den ursprünglichen Zustand erfassen, danach verändern.

Welche Informationen konkret gesichert werden, wird auf der Seite 1.4 Flüchtige Informationen und Beweise sichern behandelt.

Eine Änderung pro Test

Jede Änderung muss eine konkrete Hypothese prüfen.

Beispiel:

Hypothese: Der Client befindet sich im falschen VLAN.

Geeigneter Test:

Switchport-Zuweisung und tatsächlich gelerntes VLAN mit einem funktionierenden Port vergleichen.

Erst wenn die Hypothese bestätigt ist, wird die VLAN-Konfiguration korrigiert.

Mehrere gleichzeitige Änderungen verhindern eine eindeutige Ursachenbestimmung.

Fehlerbehebung und Verifikation trennen

Eine ausgeführte Änderung ist noch keine bestätigte Lösung.

Nach der Korrektur muss geprüft werden:

Ein Fehler gilt erst dann als behoben, wenn die ursprüngliche Funktion vollständig getestet wurde.

Dokumentation als Teil der Fehlerbehebung

Eine vollständige Fehlerdokumentation enthält:

Die Dokumentation verhindert, dass derselbe Fehler später erneut vollständig untersucht werden muss.

Grundregeln

Seiten dieses Kapitels

Quellen

1.1 Störung strukturiert aufnehmen

Zweck dieser Seite

Diese Seite dient der vollständigen und einheitlichen Aufnahme einer IT-Störung.

Bevor mit der technischen Diagnose begonnen wird, müssen das sichtbare Problem, der Zeitpunkt, die betroffenen Systeme und die verfügbaren Beweise dokumentiert werden.

Eine gute Störungsaufnahme verhindert:

Grundregel

Die Störung wird zunächst beschrieben, aber noch nicht bewertet.

Beispiel:

Nicht ausreichend:

Das Netzwerk funktioniert nicht.

Besser:

Der Client erhält seit dem 30.07.2026 um 14:35 Uhr über Ethernet keine DHCP-Adresse. Windows verwendet stattdessen die IPv4-Adresse 169.254.18.24. Über WLAN erhält derselbe Client eine gültige Adresse und kann auf interne Dienste zugreifen.

Die zweite Beschreibung enthält ein beobachtbares Symptom, einen Zeitpunkt, ein betroffenes Interface und einen funktionierenden Vergleich.

Die wichtigsten Informationen

Information Fragestellung
Melder Wer hat die Störung gemeldet?
Zeitpunkt Wann wurde die Störung erstmals festgestellt?
Letzter funktionierender Zustand Wann funktionierte der Dienst zuletzt nachweislich?
Betroffener Benutzer Welcher Benutzer beobachtet das Problem?
Betroffenes Gerät Hostname, Gerätetyp und Betriebssystem
Betroffener Dienst Welche Anwendung, Verbindung oder Funktion ist gestört?
Standort Gebäude, Raum, Homeoffice, Außenstelle oder Cloud
Netzwerkverbindung Ethernet, WLAN, Mobilfunk oder VPN
Fehlermeldung Exakter und vollständiger Wortlaut
Reproduzierbarkeit Kann der Fehler gezielt erneut ausgelöst werden?
Häufigkeit Dauerhaft, gelegentlich, periodisch oder einmalig
Auswirkung Was kann der Benutzer oder das Unternehmen nicht durchführen?
Workaround Gibt es einen vorübergehend funktionierenden Alternativweg?
Letzte Änderungen Was wurde kurz vor dem Auftreten verändert?
Beweise Screenshots, Logs, Zeitstempel, Monitoring oder Paketmitschnitt

Exakte Fehlermeldung erfassen

Fehlermeldungen dürfen nicht nur sinngemäß wiedergegeben werden.

Dokumentiert werden:

Beispiel:

Nicht ausreichend:

Anmeldung geht nicht.

Besser:

Bei der Anmeldung erscheint um 08:14 Uhr die Meldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.“

Exakte Fehlermeldungen ermöglichen eine gezieltere Suche in Logs und Herstellerdokumentationen.

Zeitpunkt dokumentieren

Der genaue Zeitpunkt ist erforderlich, um Ereignisse verschiedener Systeme miteinander zu vergleichen.

Dokumentiert werden:

Beispiel:

Fehler reproduziert am 30.07.2026 um 14:42:18 Uhr MESZ.

Ungefähre Angaben wie „heute Morgen“ oder „vorhin“ reichen für eine Logkorrelation nicht aus.

Zeit und Systeminformationen erfassen

Prüfung Windows Linux macOS
Hostname [RO] hostname [RO] hostname [RO] hostname
Benutzerkontext [RO] whoami [RO] whoami [RO] whoami
Systemzeit [RO] Get-Date -Format o [RO] date "+%Y-%m-%d %H:%M:%S %Z" [RO] date "+%Y-%m-%d %H:%M:%S %Z"
Betriebssystem [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber [RO] cat /etc/os-release [RO] sw_vers
Laufzeit [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Letzter Systemstart [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime [RO] who -b [RO] sysctl -n kern.boottime

Diese Befehle verändern keine Konfiguration.

Betroffenes System erfassen

Für einen Client oder Server werden mindestens folgende Angaben benötigt:

Betroffenen Dienst erfassen

Der betroffene Dienst muss möglichst genau benannt werden.

Nicht ausreichend:

Der Server geht nicht.

Besser:

Die HTTPS-Anwendung auf app.example.internal ist über TCP 443 nicht erreichbar. Der Server antwortet weiterhin auf ICMP und SSH.

Mögliche Dienstangaben:

Sollzustand und Istzustand trennen

Zustand Beschreibung
Sollzustand Was sollte normalerweise geschehen?
Istzustand Was geschieht tatsächlich?
Abweichung Welcher konkrete Unterschied besteht?

Beispiel:

Zustand Beobachtung
Sollzustand Client erhält per DHCP eine Adresse aus 192.168.10.0/24
Istzustand Client verwendet 169.254.18.24/16
Abweichung Kein gültiger DHCP-Lease vorhanden

Reproduzierbarkeit dokumentieren

Ein reproduzierbarer Fehler ist leichter zu untersuchen als ein unregelmäßiger Fehler.

Dokumentiert werden:

  1. Ausgangszustand;
  2. genaue Aktion;
  3. verwendeter Benutzer;
  4. verwendetes Gerät;
  5. Zielsystem oder Zieladresse;
  6. erwartetes Ergebnis;
  7. tatsächliches Ergebnis;
  8. genaue Fehlerzeit.

Beispiel:

  1. Client ist über Ethernet verbunden.
  2. Benutzer öffnet https://app.example.internal.
  3. Browser wartet ungefähr 30 Sekunden.
  4. Anschließend erscheint ein Timeout.
  5. Fehler reproduziert um 14:42:18 Uhr MESZ.
  6. Andere Webseiten funktionieren.

Häufigkeit bestimmen

Auftreten Dokumentation
Dauerhaft Fehler tritt bei jedem Versuch auf
Gelegentlich Fehler tritt unregelmäßig auf
Periodisch Fehler tritt in erkennbaren Zeitabständen auf
Zeitabhängig Fehler tritt nur zu bestimmten Uhrzeiten auf
Lastabhängig Fehler tritt nur bei hoher Nutzung auf
Standortabhängig Fehler tritt nur in einem Gebäude oder Netz auf
Benutzerabhängig Fehler tritt nur mit einem bestimmten Konto auf
Geräteabhängig Fehler tritt nur an einem bestimmten Client auf
Einmalig Fehler konnte bisher nicht erneut erzeugt werden

Bei unregelmäßigen Fehlern müssen Zeitpunkt und Begleitumstände besonders genau dokumentiert werden.

Letzten funktionierenden Zustand festhalten

Die Frage lautet nicht nur:

Seit wann besteht der Fehler?

Zusätzlich muss geklärt werden:

Wann wurde die betroffene Funktion zuletzt nachweislich erfolgreich verwendet?

Beispiele:

Der letzte funktionierende Zustand begrenzt den Zeitraum, in dem eine auslösende Änderung stattgefunden haben kann.

Letzte Änderungen erfassen

An dieser Stelle werden Änderungen zunächst nur gesammelt. Die technische Bewertung erfolgt später auf der Seite 1.3 Zeitpunkt und letzte Änderungen untersuchen.

Mögliche Änderungen:

Auch die Antwort „Keine Änderung bekannt“ wird dokumentiert.

Auswirkung erfassen

Die technische Störung und ihre betriebliche Auswirkung sind getrennt zu dokumentieren.

Technische Störung Mögliche Auswirkung
Ein Client erhält keine IP-Adresse Ein Benutzer kann nicht arbeiten
DHCP für ein VLAN ausgefallen Eine gesamte Abteilung erhält keine Netzwerkverbindung
DNS-Auflösung gestört Mehrere Anwendungen erscheinen gleichzeitig ausgefallen
Fileserver nicht erreichbar Gemeinsame Dokumente können nicht geöffnet werden
VPN ausgefallen Remotezugriff für Außenstellen oder Homeoffice nicht möglich
Datenbank nicht erreichbar Geschäftsanwendung vollständig ausgefallen
Backup fehlgeschlagen Wiederherstellbarkeit möglicherweise gefährdet
Verdächtige Anmeldung Möglicher Security-Vorfall

Workaround dokumentieren

Ein vorhandener Workaround kann bei der Eingrenzung helfen.

Beispiele:

Ein Workaround ist keine dauerhafte Fehlerbehebung.

Beweise sichern

Mögliche Beweise:

Dateinamen sollten den Host und den Zeitpunkt enthalten.

Beispiel:

client01_systemlog_2026-07-30_1442.evtx

server01_network_2026-07-30_1442.pcapng

Sensible Daten, Passwörter, Tokens und private Schlüssel dürfen nicht ungeschützt in Tickets oder Dokumentationen eingefügt werden.

Vorlage für die Störungsaufnahme

Feld Eintrag
Ticket oder Referenz
Gemeldet von
Aufgenommen am
Aufgenommen durch
Beginn der Störung
Letzter funktionierender Zustand
Betroffener Benutzer
Betroffenes Gerät
Hostname
Betriebssystem und Version
Standort
Netzwerkverbindung
Betroffener Dienst
Zielsystem oder Zieladresse
Sollzustand
Istzustand
Exakte Fehlermeldung
Fehlercode oder Event-ID
Reproduzierbar
Schritte zur Reproduktion
Häufigkeit
Bekannte letzte Änderungen
Betriebliche Auswirkung
Vorhandener Workaround
Gesicherte Logs und Beweise
Genaue Fehlerzeit mit Zeitzone
Security-Verdacht
Zusätzliche Hinweise

Beispiel einer ausgefüllten Störungsaufnahme

Feld Eintrag
Ticket oder Referenz INC-2026-0730-01
Gemeldet von Benutzer der Arbeitsstation
Aufgenommen am 30.07.2026, 14:40 Uhr MESZ
Beginn der Störung ungefähr 14:35 Uhr
Letzter funktionierender Zustand 30.07.2026, 12:10 Uhr
Betroffenes Gerät Arbeitsplatzrechner
Hostname CLIENT-01
Betriebssystem und Version Windows 11
Standort Hauptstandort, Raum 204
Netzwerkverbindung Ethernet
Betroffener Dienst DHCP und allgemeiner Netzwerkzugriff
Sollzustand IPv4-Adresse aus 192.168.10.0/24
Istzustand IPv4-Adresse 169.254.18.24/16
Exakte Fehlermeldung Keine Fehlermeldung angezeigt
Reproduzierbar Ja
Häufigkeit Dauerhaft über Ethernet
Bekannte letzte Änderungen Keine Änderung bekannt
Betriebliche Auswirkung Benutzer kann keine internen Dienste erreichen
Vorhandener Workaround WLAN funktioniert
Gesicherte Beweise Ausgabe von ipconfig /all, Screenshot und Fehlerzeit
Security-Verdacht Nein

Diese Aufnahme beschreibt den Zustand. Die technische Eingrenzung erfolgt anschließend auf der Seite 1.2 Fehlerumfang mit Kreuztests bestimmen.

Ungeeignete Störungsbeschreibungen

Diese Aussagen enthalten Vermutungen oder sind technisch nicht ausreichend eingegrenzt.

Ergebnis dieser Seite

Nach Abschluss der Störungsaufnahme müssen folgende Punkte bekannt sein:

Erst danach beginnt die systematische technische Eingrenzung.

Nächste Seite

1.2 Fehlerumfang mit Kreuztests bestimmen

Quellen

1.2 Fehlerumfang mit Kreuztests bestimmen

Zweck dieser Seite

Diese Seite dient dazu, den Umfang einer Störung systematisch einzugrenzen.

Nach der Störungsaufnahme ist bekannt, welches Symptom beobachtet wurde. Jetzt wird geprüft, ob die Ursache wahrscheinlich beim Benutzer, beim Gerät, beim Netzwerk, beim Standort, beim Zielsystem oder bei einem zentralen Dienst liegt.

In dieser Phase wird die Ursache noch nicht behoben. Das Ziel ist zunächst, die Fehlerdomäne möglichst stark zu verkleinern.

Grundprinzip

Ein einzelner Test zeigt häufig nur, dass etwas funktioniert oder nicht funktioniert.

Ein Kreuztest verändert gezielt nur eine Bedingung:

Dadurch lässt sich erkennen, mit welcher Komponente der Fehler mitwandert.

Was ist eine Fehlerdomäne?

Eine Fehlerdomäne ist der technische oder organisatorische Bereich, in dem die Ursache wahrscheinlich liegt.

Mögliche Fehlerdomänen:

Fehlerdomäne Beispiele
Benutzer Konto, Passwort, Gruppen, Rollen, Profil oder persönliche Einstellungen
Gerät Betriebssystem, Treiber, lokale Firewall, Software oder Hardware
Netzwerkinterface Ethernetadapter, WLAN-Adapter, USB-Adapter oder virtuelle NIC
Verkabelung Patchkabel, Dose, Patchfeld oder Gebäudeverkabelung
Switchport Portkonfiguration, VLAN, Port Security oder Hardwarefehler
VLAN oder Subnetz DHCP, Gateway, ACL, Routing oder Broadcast-Domain
Standort Switch, Firewall, WAN, VPN, Provider oder Stromversorgung
Zielsystem Server, Anwendung, Dienst, Listener oder lokale Firewall
Zentraler Dienst DNS, DHCP, Active Directory, NTP, Proxy oder Cloud-Dienst
Benutzergruppe Gruppenrichtlinie, Berechtigung, Lizenz oder Conditional Access
Betriebssystemgruppe Update, Treiber, Softwareversion oder Sicherheitsrichtlinie
Zeitpunkt oder Last Backup, Wartungsjob, hohe Auslastung oder geplante Änderung

Die wichtigsten Eingrenzungsachsen

Achse Fragestellung
Benutzer Ist nur ein bestimmter Benutzer betroffen?
Gerät Tritt der Fehler nur an einem Gerät auf?
Interface Tritt der Fehler nur über Ethernet, WLAN oder VPN auf?
Port Tritt der Fehler nur an einem Switchport auf?
VLAN Sind alle Geräte eines VLANs betroffen?
Subnetz Sind alle Geräte eines IP-Netzes betroffen?
Standort Ist nur ein Gebäude oder eine Außenstelle betroffen?
Dienst Ist nur ein bestimmter Dienst betroffen?
Ziel Ist nur ein bestimmter Server betroffen?
Betriebssystem Sind nur Windows-, Linux- oder macOS-Systeme betroffen?
Version Sind nur Systeme mit einem bestimmten Patchstand betroffen?
Zeit Tritt der Fehler nur zu bestimmten Zeiten auf?
Last Tritt der Fehler nur bei hoher Nutzung auf?

Betroffen und nicht betroffen dokumentieren

Die nicht betroffenen Systeme sind für die Diagnose genauso wichtig wie die betroffenen Systeme.

Kategorie Betroffen Nicht betroffen
Benutzer
Geräte
Betriebssysteme
Standorte
Switchports
VLANs
Subnetze
Netzwerkverbindungen
Anwendungen
Server
Zeiträume

Beispiel:

Kategorie Betroffen Nicht betroffen
Benutzer user andere Benutzer
Gerät CLIENT-01 CLIENT-02
Netzwerkverbindung Ethernet WLAN
Dienst interne Dienste lokale Anwendungen
Standort Raum 204 Raum 205

Aus diesem Beispiel ergibt sich noch keine endgültige Ursache. Der Fehlerbereich wurde aber bereits auf Ethernet, Verkabelung, Switchport, VLAN-Zuweisung oder die Ethernetkonfiguration des Clients eingegrenzt.

Regel für kontrollierte Kreuztests

Bei einem Kreuztest wird möglichst nur eine Bedingung verändert.

Ungeeignet:

Bei diesem Test wurden mehrere Bedingungen verändert. Das Ergebnis ist nicht eindeutig.

Besser:

  1. gleicher Benutzer an anderem Gerät;
  2. anderer Benutzer am ursprünglichen Gerät;
  3. ursprüngliches Gerät über ein anderes Interface;
  4. ursprüngliches Gerät an anderem Switchport.

Kreuztest 1 – Gleicher Benutzer an anderem Gerät

Durchführung

Der betroffene Benutzer testet dieselbe Funktion an einem anderen, nachweislich funktionierenden Gerät.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Fehler tritt auch am anderen Gerät auf Benutzerkonto, Berechtigung, Rolle, Lizenz, Profil oder zentral gespeicherte Einstellung
Fehler tritt am anderen Gerät nicht auf ursprüngliches Gerät, lokale Konfiguration, Interface oder Software
Fehler tritt nur an Geräten eines Standortes auf Standortnetz, Richtlinie oder gemeinsamer Dienst
Ergebnis abhängig vom Betriebssystem Clientsoftware, Treiber, Richtlinie oder Kompatibilität

Wichtig

Es muss wirklich dieselbe Funktion mit demselben Benutzer getestet werden.

Kreuztest 2 – Anderer Benutzer am gleichen Gerät

Durchführung

Ein anderer berechtigter Benutzer testet dieselbe Funktion am betroffenen Gerät.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Anderer Benutzer ist ebenfalls betroffen Gerät, Betriebssystem, Netzwerk oder lokale Software
Anderer Benutzer ist nicht betroffen Benutzerprofil, Konto, Rechte, Gruppen oder persönliche Einstellungen
Administrator funktioniert, Standardbenutzer nicht Rechte, UAC, Richtlinie oder Dateiberechtigung
Lokaler Benutzer funktioniert, Domänenbenutzer nicht AD, DNS, Kerberos, GPO oder Netzwerkerreichbarkeit

Anmeldedaten dürfen nicht zwischen Benutzern weitergegeben werden. Der andere Benutzer meldet sich selbst an.

Kreuztest 3 – Gleiches Gerät über anderes Netzwerkinterface

Mögliche Vergleiche:

Auswertung

Ergebnis Wahrscheinlicher Bereich
Ethernet fehlerhaft, WLAN funktioniert Ethernetadapter, Kabel, Switchport, VLAN oder kabelgebundenes Netz
WLAN fehlerhaft, Ethernet funktioniert WLAN-Adapter, Funkversorgung, SSID, Authentifizierung oder WLAN-VLAN
Direkter Zugriff funktioniert, VPN nicht VPN, Tunnelrouting, VPN-DNS, MTU oder Berechtigung
VPN funktioniert, lokaler Standortzugriff nicht Standortnetz, lokales Routing, Firewall oder DNS
Beide Interfaces fehlerhaft Betriebssystem, zentrale Dienste, Zielsystem oder allgemeine Konfiguration

Ein funktionierendes alternatives Interface ist ein wichtiger Hinweis, aber noch keine dauerhafte Lösung.

Kreuztest 4 – Gleiches Gerät an anderem Switchport

Durchführung

Das betroffene Gerät wird kontrolliert mit einem nachweislich funktionierenden Port verbunden.

Dabei müssen berücksichtigt werden:

Auswertung

Ergebnis Wahrscheinlicher Bereich
Gerät funktioniert am anderen Port ursprünglicher Port, Portprofil, VLAN, Kabelweg oder Switchhardware
Gerät funktioniert auch am anderen Port nicht Client, Adapter, Betriebssystem oder übergeordneter Netzwerkdienst
Mehrere Geräte funktionieren am ursprünglichen Port nicht Port, Kabelweg oder Switchkonfiguration
Andere Geräte funktionieren am ursprünglichen Port ursprünglicher Client oder dessen Authentifizierung

Der Vergleichsport muss für denselben Einsatzzweck und dasselbe VLAN vorgesehen sein.

Kreuztest 5 – Funktionierendes Gerät am betroffenen Port

Durchführung

Ein bekannt funktionierendes Gerät wird mit dem ursprünglichen Kabel und Switchport verbunden.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Vergleichsgerät funktioniert ursprünglicher Client, NIC, Treiber oder Clientkonfiguration
Vergleichsgerät funktioniert nicht Kabel, Dose, Patchfeld, Switchport, VLAN oder Portprofil
Vergleichsgerät erhält anderes VLAN 802.1X, NAC, MAC-basierte Zuweisung oder Portprofil
Vergleichsgerät erhält ebenfalls keine IP DHCP, VLAN, Relay, Snooping oder Portkonfiguration

Kreuztest 6 – Gleiches Gerät, anderes Ziel

Durchführung

Vom betroffenen Client werden mehrere technisch vergleichbare Ziele getestet.

Beispiele:

Auswertung

Ergebnis Wahrscheinlicher Bereich
Nur ein Ziel ist nicht erreichbar Zielserver, Zieldienst, Ziel-Firewall oder Rückroute
Alle Ziele eines Subnetzes sind nicht erreichbar Routing, ACL, Firewall oder Gateway dieses Netzes
Interne Ziele funktionieren, externe nicht WAN, NAT, Proxy, Firewall oder Provider
Externe Ziele funktionieren, interne nicht internes Routing, VPN, interne DNS-Auflösung oder interne Firewall
Nur ein bestimmter Dienst ist nicht erreichbar Port, Listener, Host-Firewall oder Anwendung

Kreuztest 7 – Andere Quelle, gleiches Ziel

Durchführung

Dasselbe Ziel wird von einem anderen Client, VLAN oder Standort getestet.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Andere Quelle erreicht das Ziel ursprünglicher Client oder ursprünglicher Netzwerkpfad
Keine Quelle erreicht das Ziel Zielsystem, zentraler Dienst oder allgemeiner Netzwerkpfad
Nur ein VLAN erreicht das Ziel nicht VLAN-Gateway, ACL, Routing oder Firewallregel
Nur ein Standort erreicht das Ziel nicht WAN, Standortfirewall, VPN oder Provider
Nur ein Betriebssystem ist betroffen Clientsoftware, Zertifikat, Richtlinie oder Protokollkompatibilität

Kreuztest 8 – IP-Adresse gegen Hostname

Durchführung

Das Ziel wird zuerst über die IP-Adresse und anschließend über den Hostnamen geprüft.

Prüfung Windows Linux macOS
Ziel-IP testen [RO] Test-NetConnection <Ziel-IP> [RO] ping -c 4 <Ziel-IP> [RO] ping -c 4 <Ziel-IP>
Hostname testen [RO] Test-NetConnection <Hostname> [RO] ping -c 4 <Hostname> [RO] ping -c 4 <Hostname>
DNS-Abfrage [RO] Resolve-DnsName <Hostname> [RO] dig <Hostname> [RO] dig <Hostname>

Auswertung

Ergebnis Wahrscheinlicher Bereich
IP funktioniert, Hostname nicht DNS, DNS-Suffix, Clientcache oder hosts-Datei
IP und Hostname funktionieren nicht Erreichbarkeit, Routing, Firewall oder Zielsystem
Hostname löst auf falsche IP auf DNS-Record, Split-DNS, Cache oder falscher DNS-Server
A-Record funktioniert, AAAA-Pfad nicht IPv6-Konfiguration oder IPv6-Routing
Kurzname funktioniert nicht, FQDN funktioniert DNS-Suffix oder Suchdomäne

Kreuztest 9 – Ping gegen tatsächlichen Dienstport

Ein Ping prüft nicht den eigentlichen Anwendungsdienst.

Prüfung Windows Linux macOS
ICMP [RO] Test-NetConnection <Ziel> [RO] ping -c 4 <Ziel> [RO] ping -c 4 <Ziel>
TCP-Port [RO] Test-NetConnection <Ziel> -Port <Port> [RO] nc -vz <Ziel> <Port> [RO] nc -vz <Ziel> <Port>
HTTPS [RO] curl -v https://<Ziel>/ [RO] curl -v https://<Ziel>/ [RO] curl -v https://<Ziel>/

Auswertung

Ergebnis Wahrscheinlicher Bereich
Ping und Port funktionieren grundlegende Verbindung vorhanden; Anwendung weiter prüfen
Ping funktioniert, Port nicht Listener, Dienst, Host-Firewall oder Netzwerkfirewall
Ping funktioniert nicht, Port funktioniert ICMP wird wahrscheinlich gefiltert
Port funktioniert, HTTPS-Anfrage nicht TLS, Proxy, Host Header oder Anwendung
TCP-Verbindung wird zurückgesetzt Zielprozess, Firewall, Proxy oder Load Balancer

curl -v kann Header, Zertifikatsinformationen und sensible Sitzungsdaten anzeigen. Ausgaben müssen vor der Weitergabe geprüft werden.

Kreuztest 10 – Lokal gegen entfernt

Test Zweck
Dienst lokal auf dem Server testen Prüft, ob Anwendung und lokaler Listener funktionieren
Dienst aus gleichem VLAN testen Prüft den lokalen Netzwerkzugriff
Dienst aus anderem VLAN testen Prüft Routing und Firewall zwischen Netzen
Dienst über VPN testen Prüft Tunnel, VPN-Routing und VPN-DNS
Dienst aus externem Netz testen Prüft WAN, NAT, Reverse Proxy oder externe Firewall

Auswertung

Ergebnis Wahrscheinlicher Bereich
Lokal funktioniert, entfernt nicht Firewall, Bind-Adresse, Routing, NAT oder Netzwerkpfad
Lokal funktioniert nicht Dienst, Anwendung, Konfiguration oder Abhängigkeit
Gleiches VLAN funktioniert, anderes VLAN nicht Inter-VLAN-Routing, ACL oder Firewall
Intern funktioniert, extern nicht NAT, WAN-Firewall, DNS oder Reverse Proxy
Extern funktioniert, intern nicht Hairpin NAT, internes DNS oder interne Route

System- und Netzwerkidentität prüfen

Prüfung Windows Linux macOS
Benutzer [RO] whoami [RO] whoami [RO] whoami
Hostname [RO] hostname [RO] hostname [RO] hostname
Interfaces [RO] Get-NetAdapter [RO] ip -brief link [RO] ifconfig -l
IP-Adressen [RO] Get-NetIPAddress [RO] ip -brief address [RO] ifconfig
Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
DNS-Server [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO] scutil --dns

Diese Informationen helfen zu prüfen, ob die verglichenen Systeme tatsächlich im erwarteten Netzwerk, VLAN oder Benutzerkontext arbeiten.

Empfohlene Reihenfolge der Kreuztests

  1. Betroffenen Benutzer und betroffenes Gerät bestätigen.
  2. Anderen Benutzer am gleichen Gerät testen.
  3. Gleichen Benutzer an anderem Gerät testen.
  4. Gleiches Gerät über anderes Interface testen.
  5. Anderes Gerät am gleichen Port testen.
  6. Gleiches Gerät an geeignetem Vergleichsport testen.
  7. Andere Ziele von gleicher Quelle testen.
  8. Gleiches Ziel von anderer Quelle testen.
  9. IP-Adresse gegen Hostname testen.
  10. Ping gegen tatsächlichen Dienstport testen.
  11. lokalen, internen und entfernten Zugriff vergleichen.
  12. Ergebnisse in einer Betroffen/Nicht-betroffen-Matrix festhalten.

Nicht jeder Fehler benötigt alle Kreuztests. Sobald die Fehlerdomäne eindeutig eingegrenzt ist, wird mit der passenden technischen Detailseite fortgefahren.

Auswertungsmatrix

Beobachtung Wahrscheinliche Fehlerdomäne Passende Folgeseite
Nur ein Benutzer betroffen Konto, Rechte oder Profil Benutzer- und Identitätsdiagnose
Nur ein Gerät betroffen Client, Treiber oder lokale Konfiguration Windows-, Linux- oder macOS-Diagnose
Nur Ethernet betroffen NIC, Kabel, Port oder VLAN Hardware, Switching und VLAN
Nur WLAN betroffen Funk, SSID, Authentifizierung oder WLAN-VLAN WLAN-Diagnose
Nur ein Port betroffen Switchport, Kabelweg oder Portprofil Switching und Verkabelung
Nur ein VLAN betroffen Gateway, DHCP Relay, ACL oder Routing VLAN, DHCP und Routing
Nur ein Standort betroffen WAN, VPN, Firewall oder Provider WAN- und Standortdiagnose
Nur ein Ziel betroffen Zielserver, Dienst oder Rückroute Server- und Dienstdiagnose
Nur ein Port oder Protokoll betroffen Listener oder Firewall TCP-, UDP- und Firewall-Diagnose
IP funktioniert, Hostname nicht DNS DNS-Diagnose
Alle Benutzer und Geräte betroffen zentraler Dienst oder Infrastruktur zentrale Infrastruktur prüfen
Fehler tritt nur zu bestimmten Zeiten auf Last, Job, Wartung oder Timeout Performance- und Zeitdiagnose

Vorlage zur Dokumentation der Kreuztests

Nummer Unveränderte Bedingung Veränderte Bedingung Ergebnis Schlussfolgerung
1
2
3
4
5

Beispiel

Ausgangssituation

CLIENT-01 erhält über Ethernet keine gültige DHCP-Adresse. Über WLAN funktioniert der Netzwerkzugriff.

Kreuztest Ergebnis
Anderer Benutzer an CLIENT-01 über Ethernet ebenfalls betroffen
Ursprünglicher Benutzer an CLIENT-02 funktioniert
CLIENT-01 über WLAN funktioniert
CLIENT-02 am Port von CLIENT-01 erhält ebenfalls keine DHCP-Adresse
CLIENT-01 an geeignetem Vergleichsport erhält gültige DHCP-Adresse

Schlussfolgerung

Der Fehler ist nicht benutzerabhängig und wahrscheinlich nicht durch die allgemeine Clientkonfiguration verursacht.

Die Fehlerdomäne wurde auf folgende Komponenten eingegrenzt:

Die weitere Diagnose erfolgt im Kapitel zu Verkabelung, Switching und VLAN.

Nicht vorschnell verändern

Während der Eingrenzung nicht gleichzeitig:

Zuerst muss festgestellt werden, mit welcher Komponente der Fehler zusammenhängt.

Ergebnis dieser Seite

Nach Abschluss der Kreuztests sollte bekannt sein, ob die Störung wahrscheinlich abhängig ist von:

Die technische Detaildiagnose beginnt anschließend innerhalb der eingegrenzten Fehlerdomäne.

Nächste Seite

1.3 Zeitpunkt und letzte Änderungen untersuchen

Quellen

1.3 Zeitpunkt und letzte Änderungen untersuchen

1.3 Zeitpunkt und letzte Änderungen untersuchen

Viele Störungen treten kurz nach einer Änderung auf. Deshalb gehört die Frage „Was hat sich verändert?“ zu den wichtigsten Schritten einer systematischen Fehleranalyse.

Dabei gilt jedoch:

Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein Beweis für einen ursächlichen Zusammenhang.

Ein Update kurz vor einer Störung kann die Ursache sein. Es kann aber ebenso Zufall sein, während beispielsweise gleichzeitig eine Firewall-Regel, ein VLAN oder ein Zertifikat geändert wurde.

Ziel dieser Seite

Nach diesem Schritt sollten folgende Fragen beantwortet sein:

1. Das Störungszeitfenster bestimmen

Zuerst wird der Zeitraum eingegrenzt, in dem die Ursache wahrscheinlich entstanden ist.

Zeitpunkt Bedeutung Beispiel
Letzter bekannter funktionierender Zustand Funktion wurde erfolgreich verwendet oder geprüft Benutzer meldete sich um 13:50 Uhr erfolgreich an
Erste bekannte Störung Fehler wurde erstmals sicher beobachtet Anmeldung schlug um 14:35 Uhr fehl
Meldezeitpunkt Störung wurde an den Support gemeldet Ticket wurde um 14:47 Uhr erstellt
Beginn der Untersuchung Technische Analyse wurde gestartet Administrator begann um 15:05 Uhr
Störungszeitfenster Zeitraum zwischen „funktioniert“ und „funktioniert nicht“ 13:50 bis 14:35 Uhr

Je kleiner das Störungszeitfenster ist, desto gezielter können Änderungen, Ereignisse und Protokolle durchsucht werden.

Wichtige Unterscheidung

2. Uhrzeit und Zeitzone prüfen

Bevor Ereignisse verschiedener Systeme verglichen werden, müssen Uhrzeit und Zeitzone geprüft werden.

Abweichende Systemzeiten können eine korrekte Ereignisreihenfolge vortäuschen oder verbergen. Besonders relevant ist dies bei:

Aktuelle Uhrzeit anzeigen

Betriebssystem Befehl
Windows PowerShell [RO] Get-Date -Format o
Windows Eingabeaufforderung [RO] echo %date% %time%
Linux [RO] date "+%Y-%m-%d %H:%M:%S %Z"
macOS [RO] date "+%Y-%m-%d %H:%M:%S %Z"

Aktuelle UTC-Zeit anzeigen

Betriebssystem Befehl
Windows PowerShell [RO] (Get-Date).ToUniversalTime().ToString("o")
Linux [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
macOS [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

Zeitzone und Zeitsynchronisation prüfen

Betriebssystem Befehl
Windows PowerShell [RO] Get-TimeZone
Windows [RO] w32tm /query /status
Windows [RO] w32tm /query /source
Linux mit systemd [RO] timedatectl status
Linux mit chrony [RO] chronyc tracking
Linux mit chrony [RO] chronyc sources -v
macOS [RO] systemsetup -gettimezone
macOS [RO] sntp -d time.apple.com

[RO] bedeutet „Read-only“. Der Befehl liest Informationen aus und soll keine Konfiguration verändern.

Bei der Dokumentation sollte immer angegeben werden, ob eine Uhrzeit als lokale Zeit oder als UTC-Zeit notiert wurde.

3. Letzten Systemstart bestimmen

Ein Neustart kann eine Störung ausgelöst, beseitigt oder sichtbar gemacht haben. Manche Änderungen werden außerdem erst nach einem Neustart wirksam.

Betriebssystem Befehl
Windows PowerShell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Windows Eingabeaufforderung [RO] systeminfo
Linux [RO] uptime -s
Linux [RO] who -b
Linux [RO] last reboot
macOS [RO] sysctl -n kern.boottime
macOS [RO] last reboot
Alle Unix-artigen Systeme [RO] uptime

Windows-Betriebsdauer berechnen

[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Typische Schlussfolgerungen

Beobachtung Mögliche Bedeutung
Störung begann direkt nach einem Neustart Dienststart, Treiber, Update, Abhängigkeit oder Startreihenfolge prüfen
System wurde unerwartet neu gestartet Stromversorgung, Absturz, Watchdog, Hypervisor oder automatischer Neustart prüfen
System wurde lange nicht neu gestartet Ausstehende Updates, Ressourcenprobleme oder nicht aktivierte Konfigurationsänderungen prüfen
Fehler verschwindet nach Neustart Flüchtiger Zustand, Ressourcenleck, blockierter Dienst oder fehlerhafter Cache möglich
Fehler erscheint erst nach Neustart Änderung wurde möglicherweise erst beim Systemstart aktiviert

4. Änderungen im Störungszeitfenster sammeln

Folgende Änderungsquellen sollten systematisch geprüft werden:

Bereich Typische Änderungen
Betriebssystem Updates, Neustarts, Treiber, Sicherheitsrichtlinien
Anwendungen Installation, Update, Deinstallation, Konfigurationsänderung
Dienste Start, Stopp, Absturz, Starttyp oder Dienstkonto geändert
Netzwerk VLAN, Routing, Switchport, ACL, Firewall-Regel, NAT
DNS Neuer, gelöschter oder geänderter Eintrag
DHCP Scope, Reservierung, Option, Lease oder Relay geändert
Active Directory Benutzer, Gruppe, Gruppenrichtlinie, Computerobjekt
Berechtigungen NTFS-, Freigabe-, Rollen- oder Cloud-Berechtigung
Zertifikate Ausstellung, Austausch, Ablauf oder Vertrauenskette
Storage Datenträger, LUN, Mount, Berechtigung, Speicherplatz
Virtualisierung Snapshot, Migration, Ressourcen oder virtuelle Netzwerke
Backup Sicherung, Wiederherstellung, Agent- oder Repository-Änderung
Cloud Sicherheitsgruppe, Rolle, Richtlinie, Netzwerk oder Ressource
Automatisierung Skript, geplante Aufgabe, Cronjob, Pipeline
Hardware Austausch, Firmware, Verkabelung oder Portwechsel
Externe Dienste Provider-Störung, Wartung oder geänderte Schnittstelle

5. Ereignisse im relevanten Zeitfenster anzeigen

Für die folgenden Beispiele wird dieses Störungszeitfenster verwendet:

Die Werte müssen an den tatsächlichen Vorfall angepasst werden.

Windows-Ereignisse mit PowerShell durchsuchen

Systemprotokoll innerhalb eines Zeitfensters

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}

Anwendungsprotokoll innerhalb eines Zeitfensters

[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}

Warnungen und Fehler anzeigen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Level Bedeutung
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich

Ereignisse als übersichtliche Tabelle darstellen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Sort-Object TimeCreated | Format-Table TimeCreated, Id, ProviderName, LevelDisplayName -AutoSize

Nicht jeder Fehler erzeugt ein Ereignis der Stufe „Fehler“. Auch Informationsereignisse können wichtige Hinweise auf Dienststarts, Updates oder Konfigurationsänderungen enthalten.

Linux-Ereignisse mit journalctl durchsuchen

Alle Ereignisse innerhalb eines Zeitfensters

[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Nur Warnungen und schwerwiegendere Meldungen

[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" -p warning

Ereignisse eines bestimmten Dienstes

[RO] journalctl -u <Dienstname> --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Beispiel für SSH:

[RO] journalctl -u sshd --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Ereignisse des aktuellen Systemstarts

[RO] journalctl -b

Ereignisse des vorherigen Systemstarts

[RO] journalctl -b -1

Kernel-Meldungen des aktuellen Systemstarts

[RO] journalctl -k -b

macOS-Ereignisse durchsuchen

Systemprotokoll innerhalb eines Zeitfensters

[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact

Nur Fehler und Störungen

[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'messageType == error OR messageType == fault' --style compact

Ereignisse eines bestimmten Prozesses

[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'process == "<Prozessname>"' --style compact

Beispiel für den Prozess softwareupdated:

[RO] log show --last 2h --predicate 'process == "softwareupdated"' --style compact

Alternativ können Protokolle über die Anwendung Konsole untersucht werden.

6. Betriebssystem- und Softwareupdates prüfen

Windows

Installierte Hotfixes anzeigen

[RO] Get-HotFix | Sort-Object InstalledOn -Descending

Ausgewählte Informationen darstellen

[RO] Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object InstalledOn, HotFixID, Description, InstalledBy

Windows-Update-Ereignisse anzeigen

[RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100 | Select-Object TimeCreated, Id, LevelDisplayName, Message

Windows-Update-Ereignisse innerhalb eines Zeitfensters

[RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}

Windows-Update-Protokolldatei erzeugen

[RO] Get-WindowsUpdateLog

Das Cmdlet erstellt aus den ETL-Dateien eine lesbare Windows-Update-Protokolldatei.

Grafischer Weg

Einstellungen → Windows Update → Updateverlauf

Get-HotFix zeigt nicht zwingend jede installierte Aktualisierung an. Die Ausgabe sollte deshalb mit dem Windows-Updateverlauf, dem Ereignisprotokoll und gegebenenfalls dem eingesetzten Patchmanagement verglichen werden.

Debian und Ubuntu

APT-Transaktionsverlauf anzeigen

[RO] less /var/log/apt/history.log

DPKG-Aktivitäten anzeigen

[RO] less /var/log/dpkg.log

Installationen, Aktualisierungen und Deinstallationen suchen

[RO] grep -E " install | upgrade | remove " /var/log/dpkg.log

Ältere Protokolle können rotiert und komprimiert vorliegen:

[RO] zgrep -hE " install | upgrade | remove " /var/log/dpkg.log*

Red Hat Enterprise Linux, Rocky Linux, AlmaLinux und Fedora

DNF-Transaktionen anzeigen

[RO] dnf history list

Details einer Transaktion anzeigen

[RO] dnf history info <Transaktions-ID>

Letzte Transaktion untersuchen

[RO] dnf history info last

Installierte Pakete nach Installationszeit sortieren

[RO] rpm -qa --last

SUSE Linux Enterprise und openSUSE

Zypper-Verlauf anzeigen

[RO] less /var/log/zypp/history

Nur Paketinstallationen anzeigen

[RO] grep "|install|" /var/log/zypp/history

Nur Paketaktualisierungen anzeigen

[RO] grep "|update|" /var/log/zypp/history

Arch Linux

Paketmanager-Protokoll anzeigen

[RO] less /var/log/pacman.log

Paketänderungen suchen

[RO] grep -E "\[ALPM\] (installed|upgraded|removed)" /var/log/pacman.log

macOS

Verlauf der Softwareupdates anzeigen

[RO] softwareupdate --history

Installationsverlauf anzeigen

[RO] system_profiler SPInstallHistoryDataType

Grafischer Weg

Systeminformationen → Software → Installationen

Die Liste kann nach dem Installationsdatum sortiert werden.

7. Dienständerungen und Dienstabstürze prüfen

Windows

Besonders interessante Ereignisse des Service Control Managers:

Ereignis-ID Typische Bedeutung
7031 Dienst wurde unerwartet beendet
7034 Dienst wurde unerwartet beendet
7036 Dienst hat seinen Status geändert
7040 Starttyp eines Dienstes wurde geändert
7045 Ein neuer Dienst wurde installiert

Relevante Dienstereignisse abfragen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message

Aktuellen Zustand eines Dienstes anzeigen

[RO] Get-Service -Name <Dienstname>

Dienstkonfiguration anzeigen

[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName

Linux

Status eines Dienstes anzeigen

[RO] systemctl status <Dienstname>

Protokoll eines Dienstes anzeigen

[RO] journalctl -u <Dienstname> --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Fehlgeschlagene Dienste anzeigen

[RO] systemctl --failed

Zeitpunkt der Dienstaktivierung anzeigen

[RO] systemctl show <Dienstname> -p ActiveEnterTimestamp -p InactiveEnterTimestamp

macOS

Geladene launchd-Dienste anzeigen

[RO] launchctl list

Nach einem bestimmten Dienst suchen

[RO] launchctl list | grep -i "<Suchbegriff>"

Prozessereignisse untersuchen

[RO] log show --last 2h --predicate 'process == "<Prozessname>"' --style compact

8. Geplante und automatisierte Änderungen prüfen

Nicht jede Änderung wird manuell durch einen Administrator ausgelöst. Häufige Ursachen sind:

Windows

Geplante Aufgaben anzeigen

[RO] Get-ScheduledTask

Laufzeitinformationen anzeigen

[RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending

Aufgaben mit Fehlerergebnis suchen

[RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object {$_.LastTaskResult -ne 0}

Task-Scheduler-Ereignisse anzeigen

[RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100

Ein von 0 abweichender Rückgabewert ist ein Hinweis, muss aber anhand der jeweiligen Aufgabe interpretiert werden.

Linux

Systemd-Timer anzeigen

[RO] systemctl list-timers --all

Cronjobs des aktuellen Benutzers anzeigen

[RO] crontab -l

Systemweite Cron-Verzeichnisse prüfen

[RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Cron-Ereignisse auf Debian und Ubuntu suchen

[RO] journalctl -u cron --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Cron-Ereignisse auf RHEL-kompatiblen Systemen suchen

[RO] journalctl -u crond --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

macOS

Geladene launchd-Aufträge anzeigen

[RO] launchctl list

Systemweite LaunchDaemons anzeigen

[RO] ls -la /Library/LaunchDaemons

Systemweite LaunchAgents anzeigen

[RO] ls -la /Library/LaunchAgents

Benutzerspezifische LaunchAgents anzeigen

[RO] ls -la ~/Library/LaunchAgents

9. Konfigurationsänderungen vergleichen

Wenn eine frühere Konfigurationsversion vorhanden ist, sollte sie mit dem aktuellen Zustand verglichen werden.

Windows PowerShell

[RO] Compare-Object (Get-Content "<Vorherige-Datei>") (Get-Content "<Aktuelle-Datei>")

Linux und macOS

[RO] diff -u "<Vorherige-Datei>" "<Aktuelle-Datei>"

Git-verwaltete Konfigurationen

[RO] git status

[RO] git diff

[RO] git log --oneline --decorate -n 20

[RO] git log -p -- "<Datei>"

Mögliche Quellen früherer Konfigurationen

Der aktuelle Zustand zeigt nur, wie das System jetzt konfiguriert ist. Ohne Auditierung, Versionsverwaltung oder Backup lässt sich daraus nicht zuverlässig ableiten, wann und durch wen eine Änderung vorgenommen wurde.

10. Änderungen an Netzwerkkomponenten prüfen

Bei Netzwerkstörungen sollten nicht nur Server und Clients betrachtet werden.

Komponente Zu prüfende Änderungen
Switch Portstatus, VLAN, Trunk, Port-Security, STP, Firmware
Router Routing, Interface, NAT, ACL, dynamisches Routing
Firewall Regelwerk, NAT, VPN, Objektgruppen, Zertifikate
WLAN-Controller SSID, VLAN-Zuordnung, Authentifizierung, Funkkanal
DHCP-Server Scope, Optionen, Reservierungen, Relay
DNS-Server Einträge, Zonen, Weiterleitungen, Replikation
Load Balancer Backend, Health Check, Zertifikat, Listener
Proxy Ausnahmen, Authentifizierung, Zertifikat, Filterregel
NAC-System Richtlinie, Geräteprofil, Quarantäne
Provider Wartung, Routingänderung, Störung

Zu verwendende Informationsquellen

Besonders wichtige Angaben

11. Active Directory und Gruppenrichtlinien prüfen

Mögliche relevante Änderungen:

Windows-Sicherheitsprotokoll nach Änderungen durchsuchen

[RO] Get-WinEvent -FilterHashtable @{LogName="Security"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message

Der Zugriff auf das Sicherheitsprotokoll benötigt entsprechende Berechtigungen.

Resultierende Gruppenrichtlinien anzeigen

[RO] gpresult /r

Ausführlichen HTML-Bericht erstellen

[RO] gpresult /h "<Zielpfad>\gpresult.html"

Das Erstellen der HTML-Datei ist keine reine Leseoperation, verändert aber keine Systemkonfiguration. Es wird lediglich eine Berichtsdatei geschrieben.

Zeitpunkt der letzten Richtlinienverarbeitung prüfen

[RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100

Für eine zuverlässige Nachverfolgung von Änderungen müssen die passenden Überwachungsrichtlinien bereits vor dem Vorfall aktiviert worden sein.

12. Cloud- und SaaS-Änderungen prüfen

Je nach Umgebung sind unter anderem folgende Protokolle relevant:

Plattform Typische Quelle
Microsoft Entra ID Überwachungsprotokolle und Anmeldeprotokolle
Microsoft 365 Einheitliches Überwachungsprotokoll
Microsoft Azure Activity Log und Resource Logs
Amazon Web Services AWS CloudTrail
Google Cloud Cloud Audit Logs
VMware vCenter Tasks und Events
Proxmox VE Task History und Systemprotokoll
Backup-System Job-, Audit- und Konfigurationsverlauf
Endpoint-Management Geräte-, Richtlinien- und Bereitstellungsverlauf
Softwareverteilung Deployment- und Installationsstatus

Zu prüfen sind insbesondere:

13. Zeitachse erstellen

Alle relevanten Ereignisse werden in einer gemeinsamen Zeitachse dokumentiert.

Zeit Quelle oder System Ereignis oder Änderung Benutzer oder Prozess Beleg Bewertung
13:50 Client-PC Anmeldung erfolgreich Max Mustermann Benutzerangabe Letzter funktionierender Zustand
14:10 Windows Server Sicherheitsupdate installiert Patchmanagement Updateverlauf Zeitlich auffällig
14:31 Switch Port in anderes VLAN verschoben Admin-Konto Auditprotokoll Technisch passend
14:35 Client-PC Anmeldung nicht mehr möglich Max Mustermann Ticket und Ereignisprotokoll Erste bekannte Störung
14:42 Monitoring Domänencontroller weiterhin erreichbar Monitoring-System Messwert Serverausfall unwahrscheinlich
15:12 Testport Anmeldung funktioniert Testbenutzer Kreuztest Switchport als Fehlerbereich bestätigt

Dieses Beispiel zeigt:

14. Änderungen bewerten

Nicht jede gefundene Änderung besitzt dieselbe Bedeutung.

Kriterium Frage
Zeitliche Nähe Liegt die Änderung kurz vor dem ersten Fehler?
Technische Plausibilität Kann die Änderung genau dieses Fehlerbild verursachen?
Betroffener Umfang Entspricht der Änderungsumfang den betroffenen Benutzern oder Systemen?
Reproduzierbarkeit Tritt der Fehler nach der Änderung zuverlässig auf?
Gegenprobe Funktioniert es ohne die Änderung oder auf einem unveränderten Vergleichssystem?
Protokollbeleg Gibt es passende Fehler, Warnungen oder Statusänderungen?
Abhängigkeiten Betrifft die Änderung einen abhängigen Dienst oder ein vorgelagertes System?
Vergleichswerte Funktionieren nicht geänderte Systeme weiterhin?
Bekanntes Problem Ist das Verhalten vom Hersteller dokumentiert?

Praktische Priorisierung

Bewertung Bedeutung
Hoch Änderung liegt im Zeitfenster, passt technisch und wird durch Tests gestützt
Mittel Änderung liegt im Zeitfenster und ist technisch möglich, aber noch nicht bestätigt
Niedrig Änderung liegt nur zeitlich nahe, passt aber kaum zum Fehlerbild
Ausgeschlossen Gegenprobe oder Messung widerlegt den Zusammenhang

15. Korrelation und Ursache unterscheiden

Nur Korrelation

Wahrscheinlicher ursächlicher Zusammenhang

Die stärkste Bestätigung entsteht durch einen kontrollierten A/B-Test:

Zustand A Zustand B Schlussfolgerung
Änderung vorhanden, Fehler vorhanden Änderung entfernt, Fehler verschwunden Zusammenhang wahrscheinlich
Änderung vorhanden, Fehler vorhanden Änderung entfernt, Fehler bleibt Änderung vermutlich nicht ursächlich
Geändertes System gestört Unverändertes Vergleichssystem funktioniert Änderung oder Systemunterschied priorisieren
Beide Systeme gestört Gemeinsame Abhängigkeit untersuchen Lokale Änderung weniger wahrscheinlich

16. Vor einem Rollback beachten

Eine Änderung darf nicht allein aufgrund zeitlicher Nähe unüberlegt zurückgenommen werden.

Vor einem Rollback sollten folgende Punkte geklärt sein:

Sicheres Vorgehen

  1. Aktuellen Zustand dokumentieren.
  2. Relevante Protokolle und Konfigurationen sichern.
  3. Rollback-Auswirkungen bewerten.
  4. Freigabe einholen.
  5. Möglichst nur eine Änderung zurücknehmen.
  6. Den ursprünglichen Fehler erneut testen.
  7. Abhängige Funktionen prüfen.
  8. Ergebnis und Uhrzeit dokumentieren.
  9. System anschließend weiter beobachten.

Ein Rollback ist selbst eine Änderung und kann neue Störungen verursachen.

17. Häufige Fehler bei der Änderungsanalyse

Fehler Folge Besseres Vorgehen
Erstbeste Änderung wird beschuldigt Falsche Ursache wird verfolgt Technische Plausibilität und Gegenprobe prüfen
Nur der Server wird untersucht Netzwerk-, Client- oder Cloud-Änderung bleibt unentdeckt Gesamten Kommunikationsweg betrachten
Uhrzeiten werden ungeprüft verglichen Falsche Ereignisreihenfolge Uhrzeit, Zeitzone und Synchronisation prüfen
Nur Fehlerereignisse werden gelesen Wichtige Informationsereignisse fehlen Auch Starts, Stopps und Statusänderungen prüfen
Aktueller Zustand wird als Verlauf interpretiert Zeitpunkt und Urheber bleiben unbekannt Audit-, Versions- und Änderungsprotokolle verwenden
Mehrere Änderungen werden gleichzeitig zurückgenommen Ursache kann nicht mehr zugeordnet werden Möglichst eine Variable pro Test verändern
Protokolle werden erst nach Neustart gesichert Flüchtige Informationen gehen verloren Beweise vor Änderungen und Neustarts sichern
Benutzerangabe wird als exakter Fehlerbeginn behandelt Suchzeitraum wird zu eng gewählt Letzten sicheren Funktionstest und erste sichere Störung trennen
Nur geplante Änderungen werden geprüft Automatische oder unautorisierte Änderung fehlt Audit-, Deployment- und Automationsprotokolle einbeziehen
Provider oder SaaS wird vergessen Externe Störung bleibt unberücksichtigt Service Health und Anbieterstatus prüfen

18. Dokumentationsvorlage

Feld Eintrag
Letzter bekannter funktionierender Zustand
Quelle dieser Information
Erste bekannte Störung
Quelle dieser Information
Verwendete Zeitzone
Zeitabweichungen festgestellt Ja / Nein
Letzter Systemstart
Änderungen im Zeitfenster
Verantwortlicher Benutzer oder Prozess
Zugehöriges Change-Ticket
Technische Plausibilität Hoch / Mittel / Niedrig
Protokollbeleg vorhanden Ja / Nein
Vergleichssystem geprüft Ja / Nein
Gegenprobe durchgeführt Ja / Nein
Rollback durchgeführt Ja / Nein
Ergebnis
Vermutete Ursache
Ursache bestätigt Ja / Nein
Noch offene Prüfungen

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende sollte eine nachvollziehbare Zeitachse vorliegen. Darin stehen der letzte funktionierende Zustand, der erste bekannte Fehler und alle technisch relevanten Änderungen dazwischen.

Eine Änderung gilt erst dann als wahrscheinliche Ursache, wenn sie:

Nächste Seite:
1.4 Flüchtige Informationen und Beweise sichern

Quellen und weiterführende Dokumentation

1.4 Flüchtige Informationen und Beweise sichern

1.4 Flüchtige Informationen und Beweise sichern

Bei einer Störung ist der erste Impuls häufig:

Diese Maßnahmen können die Funktion wiederherstellen. Gleichzeitig können sie jedoch genau die Informationen vernichten, die zur Ermittlung der Ursache benötigt werden.

Deshalb gilt:

Erst den aktuellen Zustand sichern, danach kontrolliert verändern.

Ein Neustart beseitigt unter anderem laufende Prozesse, bestehende Netzwerkverbindungen, Speicherinhalte, temporäre Zustände und Teile von Caches. Die Störung kann anschließend verschwunden sein, ohne dass ihre Ursache bekannt ist.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Das Stop–Sichern–Ändern-Prinzip

Phase Tätigkeit
Stop Nicht sofort neu starten, zurücksetzen oder bereinigen
Sichern Flüchtige Zustände, Fehlermeldungen und Protokolle erfassen
Bewerten Dringlichkeit und mögliches Sicherheitsrisiko beurteilen
Ändern Eine kontrollierte Maßnahme durchführen
Prüfen Ursprünglichen Fehler erneut testen
Dokumentieren Maßnahme, Zeitpunkt und Ergebnis festhalten

Dieses Vorgehen verhindert, dass eine erfolgreiche Sofortmaßnahme die spätere Ursachenanalyse unmöglich macht.

2. Was sind flüchtige Informationen?

Flüchtige Informationen verändern sich während des laufenden Betriebs oder gehen beim Neustart verloren.

Information Warum flüchtig?
Arbeitsspeicher Inhalt geht beim Ausschalten oder Neustart verloren
Laufende Prozesse Werden beendet und beim Start möglicherweise anders aufgebaut
Prozess-IDs Werden nach einem Neustart oder Prozessstart neu vergeben
Netzwerkverbindungen TCP-Sitzungen und temporäre Verbindungen werden beendet
Offene Dateien Zuordnung zwischen Prozess und Datei geht verloren
ARP-/Neighbor-Cache Wird automatisch aktualisiert oder beim Neustart geleert
DNS-Cache Einträge laufen ab oder werden geleert
Routingzustand Dynamische Routen können sich verändern
Angemeldete Benutzer Sitzungen werden beendet
Temporäre Dateien Können automatisch entfernt werden
Zwischenspeicher Ändern sich durch normalen Betrieb
Auslastungswerte CPU-, RAM-, Datenträger- und Netzwerklast ändern sich fortlaufend
Live-Protokollmeldungen Können durch Logrotation oder begrenzte Speichergröße verschwinden
Fehlermeldung auf dem Bildschirm Verschwindet nach Schließen der Anwendung
Zustand eines hängenden Prozesses Geht beim Beenden oder Neustart verloren

3. Reihenfolge nach Flüchtigkeit

RFC 3227 empfiehlt, Beweise grundsätzlich von den flüchtigsten zu den weniger flüchtigen Informationen zu sichern.

Für die praktische Störungsanalyse kann folgende Reihenfolge verwendet werden:

Priorität Zu sichernde Information Beispiel
1 Sichtbare Fehlermeldung und Uhrzeit Screenshot, Fehlercode, betroffene Funktion
2 Laufende Prozesse und Arbeitsspeicherzustand Prozessliste, CPU- und RAM-Auslastung
3 Aktive Netzwerkverbindungen TCP-/UDP-Verbindungen, Quell- und Zieladressen
4 Temporäre Netzwerkinformationen ARP-, Neighbor- und DNS-Cache
5 Angemeldete Benutzer und Sitzungen Lokale, RDP-, SSH- oder Konsolensitzungen
6 Dienst- und Anwendungszustand Laufende, gestoppte oder fehlgeschlagene Dienste
7 Aktuelle System- und Kernelmeldungen Ereignisanzeige, Journal, Unified Log
8 Temporäre Dateien und Laufzeitdaten PID-Dateien, Sockets, temporäre Verzeichnisse
9 Permanente Protokolle und Konfigurationen Logdateien, Registry, Konfigurationsdateien
10 Zentrale und externe Daten SIEM, Monitoring, Firewall, Cloud-Audit
11 Backups und Archivdaten ältere Konfigurationen, Images, Sicherungen

Die konkrete Reihenfolge muss an den Vorfall angepasst werden. Bei einer laufenden Verschlüsselung oder Datenübertragung kann die Eindämmung wichtiger sein als eine vollständige Sammlung.

4. Normale Störung oder möglicher Sicherheitsvorfall?

Vor der Sammlung muss grob eingeschätzt werden, ob es sich um einen normalen technischen Fehler oder einen möglichen Sicherheitsvorfall handelt.

Normale technische Störung Möglicher Sicherheitsvorfall
Dienst reagiert nicht Unbekannter oder verdächtiger Prozess
Festplatte ist voll Viele Dateien werden unerwartet verschlüsselt
DNS-Eintrag ist falsch Unbekannte externe Netzwerkverbindungen
Update verursacht Kompatibilitätsfehler Sicherheitssoftware meldet Schadsoftware
Anwendung ist abgestürzt Neue unbekannte Administratorkonten
Netzwerkkabel ist defekt Protokolle wurden gelöscht oder deaktiviert
Berechtigung wurde falsch gesetzt Massenhafte fehlgeschlagene Anmeldungen
Zertifikat ist abgelaufen Daten werden unerwartet nach außen übertragen
Systemressourcen sind ausgelastet Sicherheitsrichtlinien wurden unerlaubt verändert
Konfiguration ist fehlerhaft Ransomware-Nachricht oder Erpressung

Bei einer normalen Störung

Bei einem möglichen Sicherheitsvorfall

Bei laufender Verschlüsselung, aktiver Ausbreitung oder möglichem Datenabfluss kann eine schnelle Netzwerkisolation erforderlich sein. Die Entscheidung sollte nach dem Incident-Response-Plan und durch die zuständige Stelle erfolgen. Die Beweissicherung darf eine notwendige Eindämmung nicht gefährlich verzögern.

5. Was vor der Sicherung vermieden werden sollte

Maßnahme Möglicher Informationsverlust
Computer neu starten Prozesse, Arbeitsspeicher und Verbindungen gehen verloren
Dienst neu starten ursprünglicher Dienstzustand und Prozess-ID gehen verloren
Anwendung schließen Fehlermeldung und Prozesszustand verschwinden
Prozess beenden offene Dateien, Verbindungen und Speicherzustand gehen verloren
ipconfig /flushdns ausführen Windows-DNS-Cache wird geleert
ARP- oder Neighbor-Cache leeren Zuordnung zwischen IP- und MAC-Adressen geht verloren
Protokolle leeren Ereignisse werden dauerhaft entfernt
Datenträgerbereinigung starten temporäre Dateien und mögliche Belege verschwinden
Update installieren Ausgangszustand wird verändert
Konfiguration zurücksetzen fehlerverursachende Einstellung ist nicht mehr nachvollziehbar
Snapshot zurückspielen aktueller Systemzustand wird überschrieben
Sicherheitssoftware vollständig scannen lassen Dateien können verändert, verschoben oder gelöscht werden
Diagnosewerkzeuge unkontrolliert installieren Systemzustand und Zeitstempel verändern sich
Kabel sofort abziehen Netzwerkzustand und Verbindungen gehen verloren
Browser oder Anwendung neu laden Sitzung, Cache und Fehlermeldung können verändert werden

Diese Maßnahmen sind nicht grundsätzlich falsch. Sie sollten nur möglichst erst nach der Sicherung des relevanten Ausgangszustands erfolgen.

6. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Liest Informationen aus und soll keine Konfiguration verändern
[FILE] Erstellt oder überschreibt eine Ausgabedatei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[ACTIVE] Startet eine aktive Messung oder Aufzeichnung
[SENSITIV] Ausgabe kann vertrauliche oder personenbezogene Daten enthalten

Auch ein [RO]-Befehl erzeugt einen Prozess und kann Spuren in Protokollen, Shell-Historien oder Zugriffsdaten hinterlassen. Für eine normale Störungsdiagnose ist das meist vertretbar. Bei einer forensischen Untersuchung müssen die freigegebenen Werkzeuge und Verfahren der Organisation verwendet werden.

7. Fehlermeldung vollständig sichern

Folgende Informationen sollten erfasst werden:

Guter Screenshot

Ein guter Screenshot zeigt:

Ein zu stark zugeschnittener Screenshot kann wichtige Informationen wie Anwendung, Zielsystem oder Zeitpunkt entfernen.

Bei einem möglichen Sicherheitsvorfall

Wenn jede Interaktion mit dem System vermieden werden soll, kann der Bildschirm mit einem zweiten Gerät fotografiert werden. Dabei sind Datenschutz- und Unternehmensrichtlinien zu beachten.

8. Aktuellen Zeitpunkt zuerst dokumentieren

Windows

[RO] Get-Date -Format o

[RO] (Get-Date).ToUniversalTime().ToString("o")

[RO] Get-TimeZone

[RO] w32tm /query /status

Linux

[RO] date --iso-8601=seconds

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

[RO] timedatectl status

macOS

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

[RO] systemsetup -gettimezone

Die Zeitprüfung ist wichtig, damit lokale Systemereignisse mit Firewall-, Server-, Cloud- und Monitoring-Protokollen verglichen werden können.

9. Grundzustand des Systems erfassen

Windows

Information Befehl
Hostname [RO] hostname
Betriebssystem [RO] Get-ComputerInfo
Windows-Version kompakt [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, LastBootUpTime
Betriebsdauer [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
Aktueller Benutzer [RO] whoami
Benutzer und Gruppen [RO][SENSITIV] whoami /all
Angemeldete Sitzungen [RO] quser
Umgebungsvariablen [RO][SENSITIV] Get-ChildItem Env:
Laufwerke [RO] Get-Volume
Datenträgerbelegung [RO] Get-PSDrive -PSProvider FileSystem

Umgebungsvariablen können Token, Zugangsdaten, interne Pfade oder andere vertrauliche Werte enthalten. Sie sollten nur erfasst werden, wenn sie für die Störung relevant sind.

Linux

Information Befehl
Hostname und System [RO] hostnamectl
Kernel und Architektur [RO] uname -a
Distribution [RO] cat /etc/os-release
Betriebsdauer [RO] uptime
Letzter Systemstart [RO] uptime -s
Angemeldete Benutzer [RO] who -a
Benutzeraktivität [RO] w
Aktueller Benutzer [RO] id
Dateisystembelegung [RO] df -hT
Blockgeräte [RO] lsblk -f
Arbeitsspeicher [RO] free -h

macOS

Information Befehl
Hostname [RO] hostname
macOS-Version [RO] sw_vers
Kernel und Architektur [RO] uname -a
Systemübersicht [RO] system_profiler SPSoftwareDataType SPHardwareDataType
Betriebsdauer [RO] uptime
Letzter Systemstart [RO] sysctl -n kern.boottime
Angemeldete Benutzer [RO] who
Aktueller Benutzer [RO] id
Dateisystembelegung [RO] df -h
Arbeitsspeicher [RO] vm_stat

10. Laufende Prozesse sichern

Eine Prozessliste sollte möglichst vor dem Beenden oder Neustarten einer Anwendung erfasst werden.

Windows PowerShell

Prozessübersicht

[RO] Get-Process | Sort-Object CPU -Descending

Prozess, übergeordneter Prozess und Befehlszeile

[RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine

Prozess anhand der Prozess-ID untersuchen

[RO] Get-Process -Id <PID> | Format-List *

Prozesse mit hoher Speichernutzung

[RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 20 Name, Id, CPU, WorkingSet64

Linux

Vollständige Prozessliste

[RO][SENSITIV] ps auxww

Prozessbaum

[RO][SENSITIV] ps -ef --forest

Prozesse nach CPU-Auslastung

[RO] ps aux --sort=-%cpu | head -n 20

Prozesse nach Speichernutzung

[RO] ps aux --sort=-%mem | head -n 20

Aktuellen Systemzustand einmalig ausgeben

[RO] top -b -n 1

Offene Dateien eines Prozesses

[RO][PRIV][SENSITIV] lsof -p <PID>

macOS

Vollständige Prozessliste

[RO][SENSITIV] ps auxww

Prozesse nach CPU-Auslastung

[RO] top -l 1 -o cpu

Prozesse nach Speichernutzung

[RO] top -l 1 -o mem

Offene Dateien eines Prozesses

[RO][PRIV][SENSITIV] lsof -p <PID>

11. Aktive Netzwerkverbindungen sichern

Netzwerkverbindungen sollten vor dem Beenden eines Prozesses, dem Trennen des Netzwerks oder einem Neustart gesichert werden.

Windows

TCP-Verbindungen

[RO][PRIV] Get-NetTCPConnection

TCP-Verbindungen mit zugehörigem Prozess

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

UDP-Endpunkte

[RO][PRIV] Get-NetUDPEndpoint

Klassische Übersicht

[RO][PRIV] netstat -ano

Die letzte Spalte enthält unter Windows die Prozess-ID.

Prozess zu einer PID ermitteln

[RO] Get-Process -Id <PID>

Linux

TCP-, UDP- und lauschende Sockets

[RO][PRIV] ss -tulpn

Alle TCP-Verbindungen

[RO][PRIV] ss -tanp

Alle UDP-Endpunkte

[RO][PRIV] ss -uanp

Prozesse mit Netzwerkverbindungen

[RO][PRIV][SENSITIV] lsof -nP -i

Ohne Root-Rechte werden möglicherweise nicht alle Prozessinformationen angezeigt.

macOS

Aktive TCP-Verbindungen

[RO] netstat -anv -p tcp

UDP-Endpunkte

[RO] netstat -anv -p udp

Lauschende TCP-Prozesse

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

Bestehende TCP-Verbindungen

[RO][PRIV] lsof -nP -iTCP -sTCP:ESTABLISHED

12. Netzwerkkonfiguration und Caches sichern

Windows

Information Befehl
Vollständige IP-Konfiguration [RO] ipconfig /all
PowerShell-Netzwerkübersicht [RO] Get-NetIPConfiguration
Routingtabelle [RO] route print
PowerShell-Routen [RO] Get-NetRoute
ARP-/Neighbor-Cache [RO] arp -a
PowerShell-Neighbor-Tabelle [RO] Get-NetNeighbor
DNS-Cache [RO][SENSITIV] ipconfig /displaydns
PowerShell-DNS-Cache [RO][SENSITIV] Get-DnsClientCache
Proxykonfiguration [RO] netsh winhttp show proxy

Linux

Information Befehl
IP-Adressen und Interfaces [RO] ip -details address show
Linkzustand [RO] ip -details link show
Alle Routingtabellen [RO] ip route show table all
IPv6-Routen [RO] ip -6 route show table all
Neighbor-Tabelle [RO] ip neigh show
Resolverzustand [RO] resolvectl status
DNS-Konfiguration [RO] cat /etc/resolv.conf
NetworkManager-Verbindungen [RO][SENSITIV] nmcli connection show
NetworkManager-Geräte [RO] nmcli device status

resolvectl ist nur vorhanden, wenn die entsprechende systemd-Komponente verwendet wird.

macOS

Information Befehl
Interfaces und IP-Adressen [RO] ifconfig -a
Routingtabelle [RO] netstat -rn
Standardroute [RO] route -n get default
ARP-Cache [RO] arp -an
DNS-Konfiguration [RO][SENSITIV] scutil --dns
Netzwerkdienste [RO] networksetup -listallnetworkservices
Hardwareports [RO] networksetup -listallhardwareports
Proxykonfiguration [RO] scutil --proxy

13. Dienstzustand sichern

Windows

Alle Dienste anzeigen

[RO] Get-Service | Sort-Object Status, Name

Detaillierte Dienstinformationen

[RO][SENSITIV] Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, ProcessId, PathName

Nur beendete automatisch startende Dienste

[RO] Get-CimInstance Win32_Service | Where-Object {$_.StartMode -eq "Auto" -and $_.State -ne "Running"} | Select-Object Name, State, StartMode

Linux

Fehlgeschlagene Dienste

[RO] systemctl --failed

Laufende Dienste

[RO] systemctl list-units --type=service --state=running

Alle installierten Diensteinheiten

[RO] systemctl list-unit-files --type=service

Bestimmten Dienst untersuchen

[RO] systemctl status <Dienstname> --no-pager

macOS

Geladene launchd-Dienste

[RO] launchctl list

Nach einem Dienst suchen

[RO] launchctl list | grep -i "<Suchbegriff>"

14. Ressourcen- und Datenträgerzustand sichern

Windows

Information Befehl
Laufwerke und freier Speicher [RO] Get-Volume
Dateisystemlaufwerke [RO] Get-PSDrive -PSProvider FileSystem
Speicherauslastung pro Prozess [RO] Get-Process | Sort-Object WorkingSet64 -Descending
Datenträgerstatus [RO] Get-PhysicalDisk
Ereignisse zu Datenträgern [RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="disk"} -MaxEvents 50

Linux

Information Befehl
Arbeitsspeicher [RO] free -h
Dateisystembelegung [RO] df -hT
Inode-Belegung [RO] df -ih
Blockgeräte [RO] lsblk -f
Mounts [RO] findmnt
Kernelmeldungen [RO][PRIV] dmesg --ctime
Laufende I/O-Statistik [RO][ACTIVE] iostat -xz 1 5

iostat ist nicht auf jeder Installation vorhanden und gehört üblicherweise zum Paket sysstat.

macOS

Information Befehl
Arbeitsspeicherstatistik [RO] vm_stat
Dateisystembelegung [RO] df -h
Laufwerke und Partitionen [RO] diskutil list
Datenträgerinformationen [RO] diskutil info <Datenträger>
Laufende I/O-Statistik [RO][ACTIVE] iostat -w 1 -c 5

15. Protokolle exportieren

Protokolle sollten möglichst in ihrem nativen Format gesichert werden. Dadurch bleiben zusätzliche Felder, Ereigniskennungen und Metadaten erhalten.

Windows-Ereignisprotokolle exportieren

Zuerst muss ein neuer und freigegebener Zielordner angelegt werden.

[FILE] $target = Join-Path "<Zielpfad>" "$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMdd-HHmmss')"

[FILE] New-Item -ItemType Directory -Path $target

Systemprotokoll exportieren

[FILE][PRIV] wevtutil epl System "$target\System.evtx"

Anwendungsprotokoll exportieren

[FILE][PRIV] wevtutil epl Application "$target\Application.evtx"

Sicherheitsprotokoll exportieren

[FILE][PRIV][SENSITIV] wevtutil epl Security "$target\Security.evtx"

PowerShell-Protokoll exportieren

[FILE][PRIV][SENSITIV] wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$target\PowerShell-Operational.evtx"

Ereignisse nur aus einem bestimmten Zeitfenster als CSV sichern

[FILE] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Export-Csv "$target\System-Zeitfenster.csv" -NoTypeInformation -Encoding UTF8

Das Sicherheitsprotokoll kann personenbezogene und sicherheitsrelevante Informationen enthalten und benötigt normalerweise erhöhte Berechtigungen.

Linux-Journal exportieren

Aktuellen Systemstart sichern

[FILE] journalctl -b --no-pager --output=short-iso-precise > "<Zielpfad>/journal-current-boot.log"

Vorherigen Systemstart sichern

[FILE] journalctl -b -1 --no-pager --output=short-iso-precise > "<Zielpfad>/journal-previous-boot.log"

Bestimmtes Zeitfenster sichern

[FILE] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "<Zielpfad>/journal-time-window.log"

Kernelmeldungen sichern

[FILE][PRIV] dmesg --ctime > "<Zielpfad>/dmesg.log"

Dienstprotokoll sichern

[FILE] journalctl -u <Dienstname> --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "<Zielpfad>/<Dienstname>.log"

Die Umleitung mit > erstellt eine Datei oder überschreibt eine vorhandene Datei. Deshalb sollte immer ein neuer Zielordner verwendet werden.

macOS-Protokolle exportieren

Letzte Stunde als Text sichern

[FILE][SENSITIV] log show --last 1h --style compact > "<Zielpfad>/macOS-unified-log.txt"

Bestimmtes Zeitfenster sichern

[FILE][SENSITIV] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact > "<Zielpfad>/macOS-time-window.log"

Nur Fehler und Faults sichern

[FILE][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact > "<Zielpfad>/macOS-errors.log"

Systemdiagnose über die Oberfläche erstellen

Aktivitätsanzeige → Weitere Optionen → Systemdiagnose

Apple beschreibt diese Funktion als Möglichkeit, einen Diagnosebericht mit Informationen und Protokollen über den Mac zu erstellen.

Ein Systemdiagnosebericht kann umfangreiche und vertrauliche Informationen enthalten. Er darf nur an freigegebenen Speicherorten abgelegt und an berechtigte Empfänger weitergegeben werden.

16. Kompakte Windows-Diagnosesammlung

Das folgende Beispiel erstellt einen neuen Diagnoseordner und schreibt den aktuellen Zustand in einzelne Dateien.

<Zielpfad> muss vorher durch einen freigegebenen Speicherort ersetzt werden.

$target = Join-Path "<Zielpfad>" "$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMdd-HHmmss')"
New-Item -ItemType Directory -Path $target

Get-Date -Format o |
    Out-File "$target\collection-start.txt" -Encoding utf8

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, LastBootUpTime |
    Format-List |
    Out-File "$target\operating-system.txt" -Encoding utf8

Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine |
    Export-Csv "$target\processes.csv" -NoTypeInformation -Encoding utf8

Get-Service |
    Sort-Object Status, Name |
    Export-Csv "$target\services.csv" -NoTypeInformation -Encoding utf8

Get-NetTCPConnection |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess |
    Export-Csv "$target\tcp-connections.csv" -NoTypeInformation -Encoding utf8

Get-NetUDPEndpoint |
    Export-Csv "$target\udp-endpoints.csv" -NoTypeInformation -Encoding utf8

ipconfig /all |
    Out-File "$target\ipconfig-all.txt" -Encoding utf8

route print |
    Out-File "$target\routes.txt" -Encoding utf8

arp -a |
    Out-File "$target\arp-cache.txt" -Encoding utf8

ipconfig /displaydns |
    Out-File "$target\dns-cache.txt" -Encoding utf8

Get-Volume |
    Format-List |
    Out-File "$target\volumes.txt" -Encoding utf8

wevtutil epl System "$target\System.evtx"
wevtutil epl Application "$target\Application.evtx"

Get-Date -Format o |
    Out-File "$target\collection-end.txt" -Encoding utf8

Hinweise

17. Kompakte Linux-Diagnosesammlung

<Zielpfad> muss durch einen freigegebenen Speicherort ersetzt werden.

case_dir="<Zielpfad>/$(hostname)-$(date +%Y%m%d-%H%M%S)"
mkdir -p -- "$case_dir"

date --iso-8601=seconds > "$case_dir/collection-start.txt"
uname -a > "$case_dir/kernel.txt"
cat /etc/os-release > "$case_dir/os-release.txt"
uptime > "$case_dir/uptime.txt"
who -a > "$case_dir/logged-in-users.txt"
ps auxww > "$case_dir/processes.txt"
ss -tulpn > "$case_dir/network-sockets.txt" 2>&1
ip -details address show > "$case_dir/ip-addresses.txt"
ip route show table all > "$case_dir/routes.txt"
ip neigh show > "$case_dir/neighbors.txt"
resolvectl status > "$case_dir/dns-status.txt" 2>&1
systemctl --failed --no-pager > "$case_dir/failed-services.txt"
free -h > "$case_dir/memory.txt"
df -hT > "$case_dir/filesystems.txt"
df -ih > "$case_dir/inodes.txt"
lsblk -f > "$case_dir/block-devices.txt"
journalctl -b --no-pager --output=short-iso-precise > "$case_dir/journal-current-boot.log"
dmesg --ctime > "$case_dir/dmesg.log" 2>&1
date --iso-8601=seconds > "$case_dir/collection-end.txt"

Hinweise

18. Kompakte macOS-Diagnosesammlung

<Zielpfad> muss durch einen freigegebenen Speicherort ersetzt werden.

case_dir="<Zielpfad>/$(hostname)-$(date +%Y%m%d-%H%M%S)"
mkdir -p -- "$case_dir"

date "+%Y-%m-%dT%H:%M:%S%z" > "$case_dir/collection-start.txt"
sw_vers > "$case_dir/macos-version.txt"
uname -a > "$case_dir/kernel.txt"
system_profiler SPSoftwareDataType SPHardwareDataType > "$case_dir/system-profile.txt"
uptime > "$case_dir/uptime.txt"
who > "$case_dir/logged-in-users.txt"
ps auxww > "$case_dir/processes.txt"
ifconfig -a > "$case_dir/interfaces.txt"
netstat -rn > "$case_dir/routes.txt"
netstat -anv > "$case_dir/network-connections.txt"
arp -an > "$case_dir/arp-cache.txt"
scutil --dns > "$case_dir/dns-configuration.txt"
scutil --proxy > "$case_dir/proxy-configuration.txt"
launchctl list > "$case_dir/launchd-services.txt"
vm_stat > "$case_dir/memory.txt"
df -h > "$case_dir/filesystems.txt"
log show --last 1h --style compact > "$case_dir/unified-log-last-hour.txt"
date "+%Y-%m-%dT%H:%M:%S%z" > "$case_dir/collection-end.txt"

Hinweise

19. Paketaufzeichnung nur gezielt einsetzen

Eine Paketaufzeichnung kann zeigen:

Sie kann jedoch auch vertrauliche Inhalte, interne IP-Adressen, Hostnamen, Benutzerkennungen und Sitzungsinformationen enthalten.

Vor einer Aufzeichnung müssen deshalb geklärt sein:

Windows mit pktmon

Aufzeichnung starten

[FILE][ACTIVE][PRIV][SENSITIV] pktmon start --capture --pkt-size 0 --file-name "<Zielpfad>\capture.etl"

Aufzeichnung beenden

[ACTIVE][PRIV] pktmon stop

ETL-Datei in PCAPNG umwandeln

[FILE][SENSITIV] pktmon etl2pcap "<Zielpfad>\capture.etl" --out "<Zielpfad>\capture.pcapng"

Linux mit tcpdump

[FILE][ACTIVE][PRIV][SENSITIV] sudo tcpdump -i any -nn -s 0 -w "<Zielpfad>/capture.pcap"

Beenden mit Strg + C.

macOS mit tcpdump

[FILE][ACTIVE][PRIV][SENSITIV] sudo tcpdump -i <Interface> -nn -s 0 -w "<Zielpfad>/capture.pcap"

Beenden mit Strg + C.

Das richtige Interface kann vorher mit folgendem Befehl bestimmt werden:

[RO] networksetup -listallhardwareports

Eine ausführliche Paketanalyse wird später im Netzwerk-Kapitel behandelt.

20. Prüfsummen erstellen

Eine kryptografische Prüfsumme hilft zu erkennen, ob eine gesicherte Datei nachträglich verändert wurde.

Eine Prüfsumme beweist nicht automatisch, woher eine Datei stammt. Sie dokumentiert den Zustand der Datei zum Zeitpunkt der Prüfsummenbildung und ermöglicht spätere Integritätsprüfungen.

Die Prüfsummen sollten erst erstellt werden, nachdem die Sammlung abgeschlossen wurde und keine weiteren Dateien hinzugefügt werden.

Windows

Prüfsumme einer Datei

[RO] Get-FileHash "<Dateipfad>" -Algorithm SHA256

Prüfsummen eines Diagnoseordners als separate CSV-Datei

[FILE] Get-ChildItem "$target" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "$target-SHA256.csv" -NoTypeInformation -Encoding UTF8

Linux

Prüfsumme einer Datei

[RO] sha256sum "<Dateipfad>"

Prüfsummen aller Dateien eines Diagnoseordners

[FILE] (cd "$case_dir" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "${case_dir}-SHA256SUMS.txt"

macOS

Prüfsumme einer Datei

[RO] shasum -a 256 "<Dateipfad>"

Prüfsummen aller Dateien eines Diagnoseordners

[FILE] find "$case_dir" -type f -exec shasum -a 256 {} \; > "${case_dir}-SHA256SUMS.txt"

21. Integrität später überprüfen

Windows

[RO] Get-FileHash "<Dateipfad>" -Algorithm SHA256

Die neu berechnete Prüfsumme wird mit der zuvor dokumentierten Prüfsumme verglichen.

Linux

[RO] sha256sum -c "<SHA256SUMS-Datei>"

macOS

Wenn das Prüfsummenformat kompatibel vorliegt:

[RO] shasum -a 256 -c "<SHA256SUMS-Datei>"

22. Sicheren Speicherort auswählen

Diagnosedaten sollten nicht unkontrolliert auf dem betroffenen System verbleiben.

Geeignete Ziele

Ungeeignete Ziele

23. Mögliche sensible Inhalte

Datenquelle Mögliche sensible Informationen
Prozessliste Benutzernamen, Pfade, Befehlszeilen, Token
Netzwerkverbindungen interne IP-Adressen, externe Ziele, verwendete Dienste
DNS-Cache besuchte oder verwendete Hostnamen
Ereignisprotokolle Benutzerkonten, Systeme, Anmeldeereignisse
Paketaufzeichnung Nutzdaten, Sitzungen, Hostnamen, Identifikatoren
Konfigurationsdateien Kennwörter, API-Schlüssel, Zertifikate
Umgebungsvariablen Token, Schlüssel, Zugangsdaten
Browserdaten URLs, Sitzungsdaten, Benutzerverhalten
Systemdiagnose umfangreiche Hardware-, Benutzer- und Prozessinformationen
Cloud-Auditdaten Benutzeraktionen, IP-Adressen, Ressourcennamen

Vor der Weitergabe muss geprüft werden:

Bei Beweismitteln sollte eine unveränderte Originalkopie erhalten bleiben. Geschwärzte Arbeitskopien werden davon getrennt erstellt.

24. Beweismittelkette dokumentieren

Bei einem möglichen Sicherheitsvorfall oder einer rechtlich relevanten Untersuchung muss nachvollziehbar bleiben, wer wann mit welchen Daten gearbeitet hat.

Feld Dokumentation
Fall- oder Ticketnummer Eindeutige Referenz
System Hostname, Gerätetyp und gegebenenfalls Seriennummer
Eigentümer oder Fachbereich Verantwortliche Organisationseinheit
Sammler Name oder Administratorkonto der erfassenden Person
Beginn der Sammlung Datum, Uhrzeit und Zeitzone
Ende der Sammlung Datum, Uhrzeit und Zeitzone
Quelle System, Datenträger, Anwendung oder Protokoll
Verwendete Befehle Exakte Befehle und Parameter
Verwendete Werkzeuge Name und Version
Zielmedium Speicherort oder Datenträgerkennung
Dateiname Eindeutiger Name
Prüfsumme SHA-256-Wert
Übergabe Von wem, an wen und wann
Zugriff Wer öffnete oder kopierte die Daten?
Zweck Diagnose, Incident Response oder forensische Untersuchung
Veränderungen Jede bekannte Veränderung dokumentieren

Beispiel für einen eindeutigen Dateinamen

INC-2026-0042-SRV-DC01-System-20260730-151500.evtx

Der Dateiname enthält:

25. Prioritäten bei laufendem Produktionsausfall

Bei einem kritischen Produktionsausfall kann nicht unbegrenzt auf eine vollständige Sammlung gewartet werden.

Eine sinnvolle Mindestaufnahme besteht aus:

  1. Fehlermeldung und Zeitpunkt
  2. betroffenem System und Benutzer
  3. Prozess- und Dienstzustand
  4. Netzwerkverbindungen
  5. IP-Konfiguration und Routing
  6. Ressourcen- und Datenträgerzustand
  7. relevanten Ereignissen kurz vor dem Fehler
  8. ausgeführter Maßnahme
  9. Zustand nach der Maßnahme

Anschließend kann eine begründete Wiederherstellungsmaßnahme durchgeführt werden.

Priorität Entscheidung
Menschen oder physische Sicherheit betroffen Sicherheit hat Vorrang
Aktiver Sicherheitsangriff Eindämmung nach Incident-Response-Plan
Kritischer Produktionsstillstand Mindestaufnahme, danach freigegebene Wiederherstellung
Einzelner Arbeitsplatz betroffen Ausführlichere Diagnose meist möglich
Fehler gut reproduzierbar Zustand sichern und kontrollierte Tests durchführen
Fehler selten oder nicht reproduzierbar Vor einer Änderung besonders sorgfältig sichern

26. Nach jeder Änderung erneut sichern

Nach einer Maßnahme sollte nicht nur notiert werden, ob „es wieder geht“.

Zu dokumentieren sind:

Vorher-Nachher-Tabelle

Prüfpunkt Vor der Maßnahme Nach der Maßnahme
Fehler reproduzierbar
Dienstzustand
Prozess-ID
CPU-Auslastung
Speichernutzung
Netzwerkverbindung
DNS-Auflösung
Ereignisprotokoll
Benutzerfunktion
Monitoringstatus

27. Typische Fehler bei der Beweissicherung

Fehler Folge Besseres Vorgehen
Sofortiger Neustart Flüchtige Zustände gehen verloren Mindestzustand zuerst sichern
Screenshot ohne Uhrzeit Ereignis ist schwer einzuordnen Zeit und Zeitzone dokumentieren
Nur Fehlermeldung abschreiben Kontext und Details fehlen Vollständigen Screenshot und Fehlercode sichern
Protokoll als Text kopieren Metadaten können fehlen Wenn möglich natives Format exportieren
Diagnose auf betroffenem System speichern Daten können beim Ausfall verloren gehen Freigegebenes externes Ziel verwenden
Originaldatei bearbeiten Integrität ist nicht mehr nachvollziehbar Original schützen, Arbeitskopie verwenden
Keine Prüfsumme erstellen Spätere Veränderung schwer erkennbar SHA-256 dokumentieren
Mehrere Maßnahmen gleichzeitig Wirkung ist nicht zuordenbar Eine Variable pro Test ändern
Daten unverschlüsselt versenden Datenschutz- und Sicherheitsrisiko Freigegebenen Übertragungsweg verwenden
Vollständige Logs öffentlich hochladen Interne Daten werden offengelegt Daten prüfen, minimieren und schwärzen
Root- oder Admin-Rechte unnötig verwenden Größerer Eingriff in das System Niedrigste erforderliche Berechtigung verwenden
Sicherheitsvorfall wie normalen Fehler behandeln Spuren werden vernichtet oder Angriff breitet sich aus Incident-Response-Prozess aktivieren
Sammlung verzögert notwendige Eindämmung Schaden kann zunehmen Sicherheit und Eindämmung priorisieren
Nur lokale Protokolle sichern Zentrale Hinweise fehlen SIEM, Firewall, Cloud und Monitoring einbeziehen
Shell-Historie enthält sensible Befehle Zugangsdaten können offengelegt werden Geheimnisse niemals direkt in Befehle schreiben

28. Dokumentationsvorlage

Feld Eintrag
Ticket- oder Fallnummer
Datum und Uhrzeit
Zeitzone
Erfasser
Betroffenes System
Hostname
IP-Adresse
Betriebssystem
Betroffener Benutzer
Sichtbare Fehlermeldung
Fehlercode
Letzter funktionierender Zustand
Erste bekannte Störung
Screenshot gesichert Ja / Nein
Prozesse gesichert Ja / Nein
Verbindungen gesichert Ja / Nein
Netzwerkzustand gesichert Ja / Nein
Dienstzustand gesichert Ja / Nein
Ressourcenstatus gesichert Ja / Nein
Protokolle exportiert Ja / Nein
Paketaufzeichnung erstellt Ja / Nein / Nicht erforderlich
Diagnoseordner
Prüfsumme erstellt Ja / Nein
SHA-256-Datei
Sensible Daten enthalten Ja / Nein / Unbekannt
Sicherheitsvorfall vermutet Ja / Nein
Incident Response informiert Ja / Nein / Nicht erforderlich
Erste durchgeführte Änderung
Zeitpunkt der Änderung
Ergebnis der Änderung
Weitere Maßnahmen

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes liegt ein dokumentierter Ausgangszustand vor. Dadurch kann auch nach einem Neustart, Dienstneustart oder einer Konfigurationsänderung nachvollzogen werden, was vor der Maßnahme auf dem System geschah.

Die wichtigste Regel lautet:

Eine schnelle Wiederherstellung behebt möglicherweise die Störung. Eine vorherige Zustandssicherung ermöglicht zusätzlich die Ursachenanalyse.

Bei einem möglichen Sicherheitsvorfall gelten die Incident-Response-Vorgaben der Organisation. Eine normale Diagnosesammlung ersetzt keine professionelle forensische Sicherung.

Nächste Seite:
1.5 Arbeitshypothesen bilden und Prüfungen priorisieren

Offizielle Standards und Herstellerdokumentation

1.5 Arbeitshypothesen bilden und Prüfungen priorisieren

Nachdem Störung, Umfang, Zeitpunkt, Änderungen und Ausgangszustand dokumentiert wurden, beginnt die gezielte Ursachensuche.

Dabei gilt:

Nicht die erste plausible Erklärung beheben, sondern mehrere mögliche Ursachen aufstellen und mit geeigneten Tests unterscheiden.

Eine Arbeitshypothese ist eine vorläufige, überprüfbare Erklärung für das beobachtete Fehlerbild. Sie ist noch keine bestätigte Ursache.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus, beispielsweise eine DNS- oder TCP-Anfrage
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert eine Konfiguration oder einen Betriebszustand
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

Ein [TEST] verändert normalerweise keine Konfiguration, erzeugt aber Netzwerkverkehr und möglicherweise Protokolleinträge. Wiederholte Anmeldeversuche können beispielsweise ein Benutzerkonto sperren.

2. Fakten, Vermutungen und Ursachen unterscheiden

Begriff Bedeutung Beispiel
Symptom Sichtbare Auswirkung der Störung Webseite ist nicht erreichbar
Fakt Durch Messung oder Beleg bestätigte Information TCP-Port 443 ist von Client A nicht erreichbar
Vermutung Nicht ausreichend begründete Annahme „Bestimmt ist die Firewall schuld“
Hypothese Überprüfbare mögliche Erklärung Eine Firewall-Regel blockiert VLAN 30 zu TCP 443
Vorhersage Erwartetes Ergebnis, wenn die Hypothese stimmt Clients aus VLAN 40 funktionieren, VLAN 30 nicht
Test Gezielte Prüfung der Vorhersage Porttest aus beiden VLANs
Ursache Durch Belege und Gegenproben bestätigte Erklärung ACL blockiert VLAN 30 zu TCP 443
Maßnahme Veränderung zur Beseitigung der Ursache Korrektur der freigegebenen ACL-Regel

Wichtig

„Nach dem Neustart funktionierte es wieder“ ist zunächst nur ein Ergebnis. Daraus folgt noch nicht, warum der Fehler auftrat.

Mögliche Erklärungen wären beispielsweise:

3. Eine präzise Problembeschreibung erstellen

Eine brauchbare Hypothese benötigt eine präzise Problembeschreibung.

Ungeeignet

Das Netzwerk funktioniert nicht.

Besser

Seit ungefähr 14:35 Uhr können Windows-Clients aus VLAN 30 den Server server.example über TCP 443 nicht erreichen. DNS liefert die erwartete IP-Adresse. Clients aus VLAN 40 erreichen denselben Port weiterhin.

Eine gute Problembeschreibung enthält:

4. Aufbau einer überprüfbaren Hypothese

Eine gute Arbeitshypothese kann nach diesem Muster formuliert werden:

Wenn <vermutete Ursache> vorliegt, dann müsste <beobachtbares Ergebnis> auftreten, weil <technischer Zusammenhang>. Das prüfen wir mit <Test>. Widerlegt wäre die Hypothese durch <Gegenergebnis>.

Beispiel

Wenn eine Firewall-Regel den Verkehr aus VLAN 30 blockiert, dann müsste der TCP-Port 443 aus VLAN 30 nicht erreichbar sein, während derselbe Port aus einem freigegebenen VLAN erreichbar ist. Widerlegt wäre die Hypothese, wenn die Verbindung aus beiden VLANs identisch fehlschlägt oder die Pakete nachweislich bis zum Server gelangen.

5. Schlechte und gute Hypothesen

Schlechte Formulierung Problem Bessere Formulierung
Die Firewall ist kaputt Zu allgemein und nicht überprüfbar Eine Firewall-Regel blockiert TCP 443 aus VLAN 30
Windows macht Probleme Kein konkreter Mechanismus Der Windows-DNS-Client verwendet einen veralteten Cacheeintrag
Der Server ist down „Down“ ist nicht definiert Der Webdienst lauscht nicht auf TCP 443
Es liegt am Benutzer Keine technische Erklärung Dem Benutzer fehlt die erforderliche Anwendungsrolle
Das Update war schuld Nur zeitliche Korrelation Update KB… hat den verwendeten Treiber ersetzt
DNS geht nicht Nicht eingegrenzt Der Client fragt einen nicht erreichbaren DNS-Server ab
Das Zertifikat ist falsch Zu ungenau Der aufgerufene Hostname fehlt im Subject Alternative Name
Das Netzwerk ist langsam Keine Messgröße Zwischen Client und Server treten Paketverluste auf

6. Mögliche Fehlerbereiche systematisch durchgehen

Für eine erste Hypothesenliste können folgende Bereiche verwendet werden:

Fehlerbereich Typische Ursachen
Benutzer Bedienfehler, falsche Eingabe, fehlende Berechtigung
Benutzerkonto Sperrung, Ablauf, Gruppenmitgliedschaft, MFA
Client-Hardware Netzwerkkarte, Datenträger, Arbeitsspeicher
Client-Betriebssystem Update, Treiber, lokaler Dienst, Richtlinie
Client-Konfiguration IP, DNS, Proxy, Zertifikat, Firewall
Anwendung Absturz, Cache, Version, Konfiguration
Namensauflösung DNS-Server, Eintrag, Suchdomäne, Cache
Netzwerkzugang WLAN, Switchport, VLAN, NAC, Port-Security
Netzwerkpfad Routing, ACL, Firewall, NAT, MTU
Zielserver Dienst, Ressourcen, Betriebssystem, Listener
Authentifizierung Kerberos, LDAP, RADIUS, Zertifikat, Token
Autorisierung Rolle, Gruppe, ACL, Dateiberechtigung
Abhängiger Dienst Datenbank, DNS, Storage, API, Queue
Sicherheitskomponente EDR, Antivirus, Proxy, Webfilter
Automatisierung Skript, GPO, Deployment, geplanter Job
Virtualisierung Ressourcen, virtuelles Netzwerk, Storage
Cloud oder Provider Plattformstörung, Richtlinie, Service Health
Letzte Änderung Update, Migration, Konfiguration, Zertifikat

Nicht jeder Bereich muss ausführlich geprüft werden. Die Eingrenzung aus den vorherigen Seiten bestimmt, welche Bereiche plausibel sind.

7. Hypothesen aus dem Fehlerumfang ableiten

Beobachtung Zu priorisierende Hypothesen
Nur ein Benutzer betroffen Konto, Berechtigung, Profil, Rolle
Alle Benutzer eines Clients betroffen Client, Betriebssystem, lokale Konfiguration
Ein Benutzer auf allen Clients betroffen Identität, Konto, Berechtigung
Nur ein Standort betroffen WAN, Firewall, DNS, Provider, Standortnetz
Nur ein VLAN betroffen Routing, ACL, DHCP, VLAN-Zuordnung
Alle Clients betroffen Server, zentraler Dienst, gemeinsame Abhängigkeit
Nur ein Server betroffen Dienst, Betriebssystem, Ressourcen, Serverkonfiguration
Nur ein Browser betroffen Browserprofil, Proxy, Zertifikat, Erweiterung
Zugriff per IP funktioniert, per Name nicht DNS, Hosts-Datei, Suchdomäne
Port erreichbar, Anwendung funktioniert nicht Protokoll, Authentifizierung, Anwendung
Anwendung lokal erreichbar, remote nicht Listener-Bindung, Firewall, Routing
Fehler nur zu bestimmten Zeiten geplanter Job, Last, Lease, Token, Zertifikat
Fehler nach Update Kompatibilität, Treiber, Richtlinie, Neustart
Fehler verschwindet nach Neustart Prozesszustand, Cache, Ressourcenleck
Neue Geräte betroffen DHCP, NAC, Zertifikat, Provisionierung
Alte Geräte betroffen, neue funktionieren veraltete Konfiguration oder Software

8. Belege für und gegen eine Hypothese sammeln

Eine professionelle Hypothese enthält nicht nur unterstützende Hinweise. Es müssen auch widersprechende Beobachtungen gesucht werden.

Hypothese Unterstützende Hinweise Widersprechende Hinweise
DNS-Problem Name wird nicht aufgelöst Direkte DNS-Abfrage liefert korrekte Adresse
Serverdienst ausgefallen Port ist von allen Clients geschlossen Dienst lauscht und andere Clients funktionieren
Benutzerberechtigung fehlt Nur ein Benutzer betroffen Derselbe Benutzer funktioniert auf anderem Client
Lokale Firewall blockiert Nur ein Client betroffen Verbindung scheitert auch von anderen Clients
VLAN-ACL blockiert Nur ein VLAN betroffen Pakete erreichen nachweislich den Server
Zertifikat abgelaufen TLS-Fehler und Ablaufdatum überschritten Zertifikat ist gültig und Hostname stimmt
Datenträger voll Freier Speicher ist nahezu null Ausreichend Speicher und keine I/O-Fehler
Update verursacht Fehler Fehler beginnt direkt nach Update Identisch aktualisierte Systeme funktionieren

Eine Hypothese sollte herabgestuft werden, wenn mehrere gesicherte Fakten ihr widersprechen.

9. Prüfungen sinnvoll priorisieren

Nicht automatisch die wahrscheinlichste Hypothese wird zuerst geprüft. Sinnvoll ist zunächst ein Test, der mit geringem Risiko möglichst viele Hypothesen unterscheidet.

Priorisierungskriterien

Kriterium Frage
Wahrscheinlichkeit Passt die Hypothese zum Fehlerbild?
Informationsgewinn Wie viele Ursachen kann der Test unterscheiden?
Sicherheit Kann der Test Datenverlust oder Ausfall verursachen?
Aufwand Wie viel Zeit und Vorbereitung benötigt der Test?
Reproduzierbarkeit Kann der Test zuverlässig wiederholt werden?
Reversibilität Lässt sich eine Veränderung sicher zurücknehmen?
Reichweite Betrifft der Test einen Client oder die Produktion?
Beweislage Gibt es bereits unterstützende oder widersprechende Fakten?

10. Prioritätsklassen

Priorität Bedeutung Beispiele
P1 Sicher, schnell und hoher Informationsgewinn Status, Logs, DNS-, TCP- und Vergleichstest
P2 Gezielte Prüfung mit begrenztem Aufwand Testkonto, anderer Client, isolierte Konfiguration
P3 Potenziell störende oder aufwendige Prüfung Dienstneustart, Failover, Rollback
P4 Unwahrscheinlich, widersprochen oder unverhältnismäßig großflächige Änderung ohne ausreichende Belege

Sinnvolle Reihenfolge

  1. passive Zustandsabfrage,
  2. Vergleich mit funktionierendem System,
  3. gezielte Netzwerk- oder Anwendungstests,
  4. Test in isolierter Umgebung,
  5. reversible Änderung,
  6. Dienstneustart oder Failover,
  7. Konfigurationsrollback,
  8. weitreichende Änderung oder Produktionsunterbrechung.

11. Tests müssen Hypothesen unterscheiden

Ein Test ist besonders nützlich, wenn unterschiedliche Hypothesen unterschiedliche Ergebnisse erwarten lassen.

Wenig aussagekräftiger Test

Der Benutzer soll es noch einmal versuchen.

Dieser Test zeigt lediglich, ob der Fehler weiterhin auftritt.

Aussagekräftiger Test

Derselbe Benutzer testet dieselbe Funktion auf einem funktionierenden Vergleichsclient.

Mögliche Interpretation:

Ergebnis Schlussfolgerung
Benutzer funktioniert auf Vergleichsclient Clientbezogene Ursache wahrscheinlicher
Benutzer funktioniert auch dort nicht Konto oder Berechtigung wahrscheinlicher
Andere Benutzer funktionieren auf betroffenem Client Benutzerbezogene Ursache wahrscheinlicher
Kein Benutzer funktioniert auf betroffenem Client Client- oder Netzwerkursache wahrscheinlicher

12. Vor dem Test das erwartete Ergebnis festlegen

Vor jedem Test sollte dokumentiert werden:

Testvorlage

Feld Eintrag
Hypothese
Technische Begründung
Test
Erwartetes Ergebnis
Widerlegendes Ergebnis
Risiko
Rückfallmöglichkeit
Tatsächliches Ergebnis
Bewertung Bestätigt / Gestützt / Unklar / Widerlegt
Nächster Schritt

13. Grundlegender Netzwerk- und Diensttest

Als Beispiel wird ein Webdienst verwendet:

server.example ist ein reservierter Beispieldomainname und muss durch das tatsächliche Ziel ersetzt werden.

14. Stufe 1 – Namensauflösung prüfen

Windows

[TEST] Resolve-DnsName server.example

Bestimmten DNS-Server abfragen

[TEST] Resolve-DnsName server.example -Server <DNS-Server-IP>

Alternative

[TEST] nslookup server.example

Linux

[TEST] getent ahosts server.example

[TEST] dig server.example

Kurze Ausgabe

[TEST] dig +short server.example

Bestimmten DNS-Server abfragen

[TEST] dig @<DNS-Server-IP> server.example

macOS

[TEST] dscacheutil -q host -a name server.example

[TEST] dig server.example

Kurze Ausgabe

[TEST] dig +short server.example

Bestimmten DNS-Server abfragen

[TEST] dig @<DNS-Server-IP> server.example

Interpretation der DNS-Prüfung

Ergebnis Mögliche Bedeutung
Keine Adresse wird geliefert DNS-Eintrag, DNS-Server oder Resolverproblem
Falsche IP-Adresse veralteter Eintrag, falsche Zone, Cache oder Split-DNS
Unterschiedliche Clients erhalten unterschiedliche IPs Split-DNS, Load Balancing, Cache oder andere Resolver
Bestimmter DNS-Server antwortet korrekt, Standardabfrage nicht Client verwendet falschen oder nicht erreichbaren DNS-Server
Name wird korrekt aufgelöst DNS-Grundfunktion wahrscheinlich vorhanden
Auflösung dauert sehr lange DNS-Server, Weiterleitung, Netzwerk oder Suchdomäne prüfen

Eine erfolgreiche DNS-Abfrage beweist noch nicht, dass der Zielservice erreichbar ist.

15. Stufe 2 – IP-Erreichbarkeit mit ICMP prüfen

Windows

[TEST] ping -n 4 <IP-Adresse>

Linux

[TEST] ping -c 4 <IP-Adresse>

macOS

[TEST] ping -c 4 <IP-Adresse>

Interpretation

Ergebnis Bedeutung
Antworten werden empfangen IP-Kommunikation per ICMP funktioniert
Keine Antwort Host, Route, Firewall oder ICMP-Filterung möglich
Hohe Latenz Netzlast, WAN-Strecke, WLAN oder Zielauslastung möglich
Paketverlust instabile Verbindung, Überlastung oder physisches Problem möglich
„Destination unreachable“ Route, Gateway oder Zielnetz nicht erreichbar
Ping per IP funktioniert, per Name nicht Namensauflösung priorisieren

Ein fehlgeschlagener Ping beweist nicht, dass der Server ausgefallen ist. ICMP kann blockiert sein, während der eigentliche TCP-Dienst funktioniert.

16. Stufe 3 – Zielport prüfen

Windows

[TEST] Test-NetConnection server.example -Port 443 -InformationLevel Detailed

Wichtige Felder:

Nur Ergebnis ausgeben

[TEST] Test-NetConnection server.example -Port 443 -InformationLevel Quiet

Linux

[TEST] nc -vz -w 3 server.example 443

macOS

[TEST] nc -vz -w 3 server.example 443

nc kann je nach Linux-Installation fehlen und muss gegebenenfalls als freigegebenes Paket installiert werden.

Interpretation des Porttests

Ergebnis Mögliche Bedeutung
TCP-Verbindung erfolgreich Netzwerkpfad und TCP-Listener grundsätzlich erreichbar
Verbindung abgelehnt Ziel erreichbar, aber kein Listener oder aktive Ablehnung
Zeitüberschreitung Paketfilter, Route, Überlastung oder nicht antwortendes Ziel
Name kann nicht aufgelöst werden DNS zuerst untersuchen
Nur ein Client scheitert Client, lokales Netzwerk oder lokale Firewall
Nur ein VLAN scheitert ACL, Firewall, Routing oder VLAN-Konfiguration
Alle Clients scheitern Dienst, Server, zentrale Firewall oder gemeinsame Abhängigkeit

Ein erfolgreicher TCP-Test beweist nur den Verbindungsaufbau zum Port. Er bestätigt noch nicht, dass Anmeldung, Anwendung oder Datenbank funktionieren.

17. Stufe 4 – Anwendungsebene prüfen

Windows

[TEST] curl.exe -v -o NUL https://server.example/

Linux

[TEST] curl -v -o /dev/null https://server.example/

macOS

[TEST] curl -v -o /dev/null https://server.example/

Die Option -v zeigt unter anderem:

Beim ersten Test sollte nicht -k beziehungsweise --insecure verwendet werden. Diese Option deaktiviert die Zertifikatsprüfung und kann genau den Fehler verbergen, der untersucht werden soll.

18. HTTP-Ergebnisse interpretieren

Ergebnis Interpretation
200 OK Anfrage wurde erfolgreich verarbeitet
301 oder 302 Weiterleitung; Ziel des Location-Headers prüfen
401 Unauthorized Dienst erreichbar, Authentifizierung erforderlich oder fehlgeschlagen
403 Forbidden Dienst erreichbar, Zugriff wird verweigert
404 Not Found Dienst erreichbar, Ressource oder Pfad nicht gefunden
408 Request Timeout Anfrage wurde nicht rechtzeitig verarbeitet
429 Too Many Requests Rate Limit oder zu viele Anfragen
500 Internal Server Error serverseitiger Anwendungsfehler
502 Bad Gateway Proxy oder Gateway erhält ungültige Backend-Antwort
503 Service Unavailable Dienst oder Backend nicht verfügbar
504 Gateway Timeout Proxy oder Gateway wartet vergeblich auf Backend
TLS-Zertifikatsfehler Zertifikat, Hostname, Vertrauenskette oder Uhrzeit prüfen
TCP-Verbindungsfehler Netzwerkpfad, Firewall oder Listener prüfen

Ein HTTP-Status ist ein wichtiger Hinweis, aber die genaue Bedeutung kann von der Anwendung abweichen.

19. TLS-Verbindung untersuchen

Auf Linux und macOS sowie unter Windows mit installiertem OpenSSL:

[TEST] openssl s_client -connect server.example:443 -servername server.example -showcerts

Zu prüfen sind:

Typische Befunde

Befund Mögliche Ursache
Zertifikat abgelaufen Zertifikat wurde nicht rechtzeitig erneuert
Zertifikat noch nicht gültig falsche Systemzeit oder falsches Zertifikat
Hostname stimmt nicht falsches Zertifikat, Alias oder fehlender SAN-Eintrag
Unbekannte CA Stamm- oder Zwischenzertifikat fehlt
Verbindung ohne Zertifikat beendet TLS-Listener oder Proxyproblem
Handshake Failure inkompatible TLS-Version, Cipher oder Clientzertifikat
Browser funktioniert, Anwendung nicht unterschiedlicher Trust Store oder TLS-Stack

20. Netzwerkpfad prüfen

Windows

[TEST] tracert server.example

PowerShell

[TEST] Test-NetConnection server.example -TraceRoute

Linux

[TEST] tracepath server.example

Alternativ, wenn installiert:

[TEST] traceroute server.example

macOS

[TEST] traceroute server.example

Wichtige Einschränkungen

21. Lokal gegen remote testen

Wenn ein Dienst direkt auf dem Server funktioniert, aber von Clients nicht erreichbar ist, wird die Ursache auf Netzwerkpfad, Listener-Bindung oder Firewall eingegrenzt.

Windows-Server

Dienst lokal testen

[TEST] Test-NetConnection localhost -Port <Port>

Listener prüfen

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Zugehörigen Prozess bestimmen

[RO] Get-Process -Id <OwningProcess>

Linux-Server

Dienst lokal testen

[TEST] nc -vz -w 3 localhost <Port>

Listener prüfen

[RO][PRIV] ss -lntp | grep ":<Port>"

HTTP-Dienst lokal prüfen

[TEST] curl -v http://localhost:<Port>/

macOS-Server

Dienst lokal testen

[TEST] nc -vz -w 3 localhost <Port>

Listener prüfen

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

Interpretation

Lokaler Test Remote-Test Wahrscheinlicher Bereich
Erfolgreich Erfolgreich Anwendung, Anmeldung oder Benutzerberechtigung
Erfolgreich Fehlgeschlagen Firewall, Routing, NAT oder Listener-Bindung
Fehlgeschlagen Fehlgeschlagen Dienst, Server oder Anwendung
Fehlgeschlagen Erfolgreich ungewöhnlicher Proxy-, Container- oder Load-Balancer-Pfad
Unterschiedlich je Quellnetz Unterschiedlich VLAN, ACL, Firewall oder Routing

22. Dienstzustand und Protokolle prüfen

Windows

[RO] Get-Service -Name <Dienstname>

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Linux

[RO] systemctl status <Dienstname> --no-pager

[RO] journalctl -u <Dienstname> --since "1 hour ago" --no-pager

macOS

[RO] launchctl list | grep -i "<Dienstname>"

[RO] log show --last 1h --predicate 'process == "<Prozessname>"' --style compact

Zu prüfende Hinweise

23. Benutzer- und Berechtigungshypothesen prüfen

Windows

Benutzeridentität und Gruppen

[RO][SENSITIV] whoami /all

NTFS-Berechtigungen

[RO][SENSITIV] icacls "<Pfad>"

PowerShell-ACL

[RO][SENSITIV] Get-Acl "<Pfad>" | Format-List

Domänenkanal auf Mitgliedscomputern prüfen

[TEST] Test-ComputerSecureChannel -Verbose

Test-ComputerSecureChannel ist für Domänenmitgliedscomputer vorgesehen. Auf Domänencontrollern ist dieses Cmdlet laut Microsoft nicht zur zuverlässigen Prüfung geeignet. Der Parameter -Repair wäre eine Änderung und gehört nicht zum reinen Test.

Linux

Benutzer und Gruppen

[RO] id <Benutzername>

Datei- und Verzeichnisrechte

[RO] ls -ld "<Pfad>"

Rechte des vollständigen Pfades

[RO] namei -l "<Pfad>"

POSIX-ACL anzeigen

[RO][SENSITIV] getfacl "<Pfad>"

macOS

Benutzer und Gruppen

[RO] id <Benutzername>

Dateirechte und ACL

[RO][SENSITIV] ls -lde "<Pfad>"

Typische Vergleichstests

Test Interpretation
Anderer Benutzer funktioniert am selben Client Benutzer oder Berechtigung priorisieren
Derselbe Benutzer funktioniert an anderem Client Client oder Benutzerprofil priorisieren
Testkonto mit gleicher Rolle funktioniert individuelles Konto untersuchen
Testkonto mit anderer Rolle funktioniert Rollen- oder Gruppenberechtigung untersuchen
Dateizugriff direkt möglich, Anwendung nicht Anwendung oder Dienstkonto untersuchen

Bei Anmeldetests muss eine mögliche Kontosperrung berücksichtigt werden.

24. Konfigurationen vergleichen

Windows PowerShell

[RO] Compare-Object (Get-Content "<Funktionierende-Datei>") (Get-Content "<Betroffene-Datei>")

Prüfsumme vergleichen

[RO] Get-FileHash "<Datei>" -Algorithm SHA256

Linux und macOS

[RO] diff -u "<Funktionierende-Datei>" "<Betroffene-Datei>"

Prüfsumme unter Linux

[RO] sha256sum "<Datei>"

Prüfsumme unter macOS

[RO] shasum -a 256 "<Datei>"

Zu vergleichende Werte

Eine unterschiedliche Prüfsumme zeigt nur, dass Dateien verschieden sind. Sie zeigt nicht, welcher Unterschied relevant ist.

25. Diagnosematrix für typische Ergebnisse

Testergebnis Wahrscheinlicher Fehlerbereich
DNS-Abfrage schlägt fehl DNS-Client, DNS-Server oder Netzwerk zum DNS-Server
DNS liefert falsche IP Zone, Cache, Hosts-Datei oder Split-DNS
IP-Ping funktioniert, Name nicht Namensauflösung
Ping scheitert, TCP funktioniert ICMP wird wahrscheinlich blockiert
TCP-Port ist erreichbar, HTTP scheitert Anwendung, TLS, Authentifizierung oder Protokoll
TCP-Verbindung wird abgelehnt Kein Listener oder aktive Ablehnung
TCP-Verbindung läuft in Timeout Filterung, Routing, Überlastung oder Ziel antwortet nicht
Lokal funktioniert, remote nicht Firewall, Routing, Listener-Bindung oder NAT
Andere Clients funktionieren Clientbezogene Ursache
Andere Benutzer funktionieren Benutzer, Konto, Profil oder Berechtigung
Gleiches VLAN betroffen VLAN, ACL, DHCP oder Gateway
Alle VLANs betroffen Server, Dienst oder zentrale Komponente
HTTP 401 Authentifizierung untersuchen
HTTP 403 Autorisierung oder Richtlinie untersuchen
HTTP 500 Anwendung oder Backend untersuchen
HTTP 502/504 Proxy, Load Balancer oder Backend untersuchen
Zertifikatsfehler Zeit, Hostname, Trust Store oder Zertifikatskette
Dienst läuft, aber kein Listener Konfiguration, Bindung oder Startfehler
Listener vorhanden, Anwendung reagiert nicht Prozesszustand, Abhängigkeit oder Ressourcen
Datenträger voll Speicherverbrauch und Logwachstum untersuchen

26. Mehrdeutige Ergebnisse erkennen

Ein einzelner Test liefert häufig keine eindeutige Ursache.

Beispiel: TCP-Timeout

Mögliche Ursachen:

Deshalb folgt auf einen mehrdeutigen Test ein zweiter Test, der diese Möglichkeiten weiter trennt.

Geeignete Folgeprüfungen

27. Beispiel einer vollständigen Hypothesenliste

Störung

Clients aus VLAN 30 können https://server.example nicht öffnen. Clients aus VLAN 40 funktionieren. DNS liefert in beiden VLANs dieselbe IP-Adresse.

Nr. Hypothese Belege dafür Belege dagegen Test Priorität
H1 ACL blockiert VLAN 30 zu TCP 443 Nur VLAN 30 betroffen Noch keine TCP-Test und Firewall-Log P1
H2 Falsches Gateway in VLAN 30 gesamtes VLAN betroffen Andere Ziele erreichbar Route und Gateway prüfen P1
H3 DNS liefert falsche Adresse Webdienst nicht erreichbar Beide VLANs erhalten dieselbe IP DNS-Ergebnisse vergleichen P4
H4 Webdienst ist ausgefallen Verbindung schlägt fehl VLAN 40 funktioniert lokaler und externer Porttest P4
H5 MTU-Problem im Netzwerkpfad HTTPS betroffen noch keine Größenabhängigkeit bekannt Paketgröße und Paketaufzeichnung P2
H6 Proxy wird nur in VLAN 30 verwendet nur bestimmte Clients betroffen möglich noch ungeprüft Proxykonfiguration vergleichen P2

Erste Prüfung

Test-NetConnection server.example -Port 443

Ergebnis:

Dadurch werden H1, H2 oder H6 wahrscheinlicher. H3 und H4 werden weniger wahrscheinlich.

Zweite Prüfung

Damit wird H1 stark gestützt.

Bestätigung

Nach einer freigegebenen Korrektur der betroffenen ACL-Regel funktioniert derselbe definierte Test aus VLAN 30. Die Firewall protokolliert nun eine erlaubte Verbindung.

28. Hypothesenstatus verwenden

Status Bedeutung
Offen Noch nicht geprüft
Gestützt Hinweise sprechen dafür
Teilweise gestützt Einige Ergebnisse passen, andere sind offen
Unklar Test war nicht eindeutig
Widerlegt Ergebnis widerspricht der Vorhersage
Bestätigt Mehrere Belege und Gegenprobe stützen die Ursache
Zurückgestellt Derzeit geringe Priorität
Nicht prüfbar Werkzeug, Zugriff oder Vergleichssystem fehlt

Eine Hypothese sollte nicht bereits nach einem passenden Einzelbefund als bestätigt gelten.

29. Wann gilt eine Ursache als bestätigt?

Eine Ursache ist ausreichend bestätigt, wenn möglichst mehrere Kriterien erfüllt sind:

Besonders starke Bestätigung

Zustand Ergebnis
Fehlerzustand vorhanden definierter Test schlägt fehl
Ursache kontrolliert entfernt derselbe Test funktioniert
Ursache in Testumgebung erneut hergestellt derselbe Test schlägt wieder fehl
Ursache erneut entfernt derselbe Test funktioniert wieder

In Produktionsumgebungen ist ein erneutes absichtliches Herstellen des Fehlers häufig nicht vertretbar. In diesem Fall müssen Protokolle, Vergleichssysteme und technische Plausibilität gemeinsam bewertet werden.

30. Typische Denkfehler vermeiden

Denkfehler Beschreibung Gegenmaßnahme
Bestätigungsfehler Es werden nur Belege für die Lieblingshypothese gesucht aktiv nach widersprechenden Fakten suchen
Fixierung Erste Erklärung wird nicht mehr hinterfragt mindestens mehrere Hypothesen notieren
Zeitliche Verwechslung Änderung vor Fehler wird automatisch zur Ursache technische Verbindung und Gegenprobe verlangen
Autoritätseffekt Aussage einer erfahrenen Person wird ungeprüft übernommen Messwerte und Protokolle verwenden
Verfügbarkeitseffekt Kürzlich erlebter Fehler wird überall vermutet aktuellen Umfang und aktuelle Fakten prüfen
Aktionismus Sichtbare Aktivität ersetzt systematische Diagnose erwartetes Testergebnis vorab definieren
Erfolgsfehlschluss Nach Neustart geht es, daher sei Ursache gefunden Wiederherstellung und Ursachenbestätigung trennen
Werkzeuggläubigkeit Ausgabe eines Werkzeugs wird als absolute Wahrheit angesehen Messgrenzen und Gegenprüfung beachten
Scheingenauigkeit Punktwert wird mit Gewissheit verwechselt Priorisierung als Hilfsmittel verwenden
Gruppendenken Team übernimmt eine Vermutung ohne Gegenargument gezielt eine alternative Erklärung verlangen

31. Regeln für aussagekräftige Tests

32. Dokumentationsvorlage für Hypothesen

Nr. Hypothese Technische Begründung Belege dafür Belege dagegen Geplanter Test Erwartetes Ergebnis Risiko Priorität Ergebnis Status
H1
H2
H3
H4

33. Dokumentationsvorlage für einen Test

Feld Eintrag
Ticketnummer
Hypothese
Testnummer
Datum und Uhrzeit
Zeitzone
Ausführende Person
Quellsystem
Quell-IP
Zielsystem
Ziel-IP
Protokoll und Port
Ausgangszustand
Exakter Befehl
Erwartetes Ergebnis
Tatsächliches Ergebnis
Vollständige Ausgabe gesichert Ja / Nein
Hypothese gestützt Ja / Nein / Unklar
Nebenwirkungen
Rückfall erforderlich Ja / Nein
Nächster Test

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende liegt keine unsortierte Sammlung von Vermutungen mehr vor, sondern ein priorisierter Prüfplan.

Jede wichtige Hypothese enthält:

Dadurch wird die Fehlersuche nachvollziehbar, reproduzierbar und wesentlich effizienter.

Nächste Seite:
1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten

Offizielle Hersteller- und Standarddokumentation

1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten

Eine gute Hypothese ist nur dann nützlich, wenn sie mit einem kontrollierten und aussagekräftigen Test geprüft wird.

Dabei gilt:

Gleicher Ausgangszustand, gleicher Test, nur eine veränderte Variable und ein vorher festgelegtes erwartetes Ergebnis.

Wer mehrere Dinge gleichzeitig verändert, kann die Wirkung später keiner einzelnen Maßnahme zuordnen.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus und kann Netzwerkverkehr oder Protokolleinträge erzeugen
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

Auch ein [RO]- oder [TEST]-Befehl ist nicht vollständig spurlos. Er startet mindestens einen Prozess und kann in Protokollen, Shell-Historien, Firewalls oder SIEM-Systemen erscheinen.

2. Der kontrollierte Prüfablauf

Phase Tätigkeit
1. Prüfziel Welche Frage soll der Test beantworten?
2. Hypothese Welche mögliche Ursache wird geprüft?
3. Ausgangszustand Welche Messwerte liegen vor dem Test vor?
4. Vorhersage Welches Ergebnis wird erwartet?
5. Risiko Welche Nebenwirkungen kann der Test haben?
6. Abbruchkriterium Wann muss der Test sofort beendet werden?
7. Durchführung Exakten Befehl oder Ablauf verwenden
8. Aufzeichnung Zeit, Ausgabe und Rückgabewert sichern
9. Wiederholung Ergebnis bei Bedarf kontrolliert reproduzieren
10. Rückkehr Ausgangszustand wiederherstellen
11. Vergleich Vorher- und Nachher-Ergebnis vergleichen
12. Bewertung Hypothese bestätigen, stützen, offenlassen oder widerlegen

3. Testarten nach Eingriffsrisiko

Testart Beschreibung Beispiel Risiko
Passive Abfrage Liest vorhandenen Zustand Prozessliste, Logs, Routingtabelle Sehr niedrig
Aktiver Funktionstest Sendet eine kontrollierte Anfrage DNS-, Ping-, TCP- oder HTTP-Test Niedrig
Vergleichstest Vergleicht betroffenes und funktionierendes System Client A gegen Client B Niedrig
Wiederholungstest Prüft, ob das Ergebnis reproduzierbar ist fünf identische TCP-Tests Niedrig bis mittel
Isolationstest Verändert nur den Testkontext bestimmtes Backend mit curl --resolve Niedrig bis mittel
Reversible Änderung Verändert vorübergehend eine Einstellung freigegebene Testregel Mittel
Dienstbezogener Test Startet oder beendet einen Dienst Dienstneustart Hoch
Failover-Test Verlagert produktiven Betrieb Wechsel auf zweiten Server Hoch
Lasttest Erzeugt zusätzliche Last viele parallele Anfragen Hoch
Wiederherstellungstest Setzt Konfiguration oder Version zurück Rollback Hoch
Destruktiver Test Kann Daten oder Zustand zerstören Löschen, Zurücksetzen, Neuinstallation Sehr hoch

Passive, aktive und vergleichende Tests sollten normalerweise vor verändernden oder potenziell störenden Tests durchgeführt werden.

4. Prüfung und Reparatur nicht vermischen

Reine Prüfung

[TEST] Test-ComputerSecureChannel -Verbose

Dieser Befehl prüft auf einem Windows-Domänenmitglied den sicheren Kanal.

Verändernde Reparatur

[CHANGE] Test-ComputerSecureChannel -Repair

Der Parameter -Repair verändert den Zustand und ist keine reine Prüfung mehr.

Ein ähnlicher Unterschied besteht bei vielen Werkzeugen:

Prüfung Veränderung
Get-Service Restart-Service
systemctl status systemctl restart
ipconfig /displaydns ipconfig /flushdns
Get-NetRoute New-NetRoute oder Remove-NetRoute
journalctl Löschen oder Rotieren von Logs
diff Überschreiben der Konfiguration
Firewall-Log ansehen Firewall-Regel ändern
Zertifikat anzeigen Zertifikat ersetzen
Updateverlauf anzeigen Update installieren oder entfernen

Prüfung und Reparatur sollten im Ticket als getrennte Schritte dokumentiert werden.

5. Prüfziel präzise formulieren

Ungeeignet

Ich teste das Netzwerk.

Besser

Es wird geprüft, ob Client PC-030 aus VLAN 30 am 30.07.2026 um 15:30 Uhr eine TCP-Verbindung zu server.example auf Port 443 herstellen kann.

Noch besser

Hypothese H1: Eine ACL blockiert TCP 443 aus VLAN 30. Erwartet wird, dass der TCP-Test aus VLAN 30 fehlschlägt und derselbe Test aus VLAN 40 erfolgreich ist.

Ein präzises Prüfziel enthält:

6. Ausgangszustand als Baseline erfassen

Eine Baseline ist der dokumentierte Zustand vor dem Test.

Typische Baseline-Werte

Beispiel

Messwert Vor dem Test
Zeitpunkt 2026-07-30 15:30:00 CEST
Quelle PC-030
Quell-IP 192.0.2.30
Quell-VLAN VLAN 30
Ziel server.example
Ziel-IP 198.51.100.20
Zielport TCP 443
DNS-Auflösung erfolgreich
TCP-Test fehlgeschlagen
HTTP-Test keine Verbindung
Ping keine Antwort
Andere Ziele erreichbar
Vergleichsclient aus VLAN 40 funktioniert

Die IP-Adressen aus den Netzen 192.0.2.0/24 und 198.51.100.0/24 sind für Dokumentationsbeispiele reserviert.

7. Nur eine Variable verändern

Ungeeigneter Test

Gleichzeitig werden:

Wenn der Fehler danach verschwunden ist, bleibt unklar, welche Maßnahme wirksam war.

Besseres Vorgehen

  1. Ausgangszustand sichern.
  2. DNS-Auflösung prüfen.
  3. TCP-Verbindung prüfen.
  4. Vergleichsclient testen.
  5. anderes Kabel oder anderen Port testen.
  6. nach jedem Schritt denselben Funktionstest wiederholen.
  7. erst danach eine freigegebene Konfigurationsänderung durchführen.

8. Kontrollvariable und Vergleichssystem verwenden

Ein Vergleichssystem hilft zu erkennen, ob eine Ursache:

Test Konstante Werte Veränderte Variable
Gleicher Benutzer, anderer Client Benutzer, Ziel, Funktion Client
Anderer Benutzer, gleicher Client Client, Ziel, Funktion Benutzer
Gleicher Client, anderes VLAN Client, Benutzer, Ziel Netzwerkpfad
Gleiches VLAN, anderer Client Netzwerk, Ziel Client
Gleiches Ziel, direkter Porttest Client, Netzwerk, Ziel Anwendungsebene
Gleiche URL, bestimmtes Backend Client, URL, Hostname Backend
Gleiche Datei, anderes Konto Datei, Client, Pfad Berechtigung
Gleicher Dienst, localhost Server, Dienst, Port Netzwerkpfad entfällt

Je weniger Variablen sich zwischen den Testfällen unterscheiden, desto aussagekräftiger ist der Vergleich.

9. Testzeitpunkt dokumentieren

Windows

[RO] Get-Date -Format o

UTC-Zeit

[RO] (Get-Date).ToUniversalTime().ToString("o")

Linux

[RO] date --iso-8601=seconds

macOS

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Der Zeitpunkt sollte unmittelbar vor und nach dem Test erfasst werden. Dadurch kann die Ausgabe mit Server-, Firewall-, Proxy- und SIEM-Protokollen verglichen werden.

10. PowerShell-Sitzung protokollieren

PowerShell kann Befehle und Konsolenausgaben einer Sitzung in einer Transkriptdatei aufzeichnen.

Protokollierung starten

[FILE][SENSITIV] Start-Transcript -Path "<Zielpfad>\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber

Protokollierung beenden

[FILE] Stop-Transcript

-IncludeInvocationHeader ergänzt Zeitinformationen zu den ausgeführten Befehlen.

-NoClobber verhindert, dass eine bereits vorhandene Datei überschrieben wird.

Zu beachten

11. Linux- und macOS-Terminalsitzung protokollieren

Das Werkzeug script erstellt eine Aufzeichnung der Terminalsitzung.

Aufzeichnung starten

[FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt"

Anschließend werden die vorgesehenen Diagnosebefehle ausgeführt.

Aufzeichnung beenden

exit

Alternativ kann die Sitzung mit Strg + D beendet werden.

Zu beachten

12. Einzelne PowerShell-Ausgabe in Datei und Konsole schreiben

Tee-Object zeigt die Ausgabe auf der Konsole an und speichert sie gleichzeitig in einer Datei.

[FILE] Test-NetConnection server.example -Port 443 -InformationLevel Detailed | Tee-Object -FilePath "<Zielpfad>\tcp-test.txt"

Mit Zeitstempel

Get-Date -Format o |
    Tee-Object -FilePath "<Zielpfad>\tcp-test.txt"

Test-NetConnection server.example -Port 443 -InformationLevel Detailed |
    Tee-Object -FilePath "<Zielpfad>\tcp-test.txt" -Append

-Append fügt die Ausgabe an die vorhandene Datei an.

13. Einzelne Linux- oder macOS-Ausgabe sichern

Ausgabe und Fehlermeldungen in eine Datei schreiben

[FILE] <Befehl> > "<Zielpfad>/test-output.txt" 2>&1

Ausgabe gleichzeitig anzeigen und speichern

[FILE] <Befehl> 2>&1 | tee "<Zielpfad>/test-output.txt"

Bei einer Pipeline mit tee kann der direkt danach angezeigte Rückgabewert zur letzten Komponente der Pipeline gehören. Wenn der ursprüngliche Rückgabewert wichtig ist, sollte der Befehl zunächst ohne Pipeline ausgeführt und anschließend die Datei angezeigt werden.

Rückgabewert zuverlässig sichern

started_at=$(date "+%Y-%m-%dT%H:%M:%S%z")
curl --connect-timeout 5 --max-time 15 https://server.example/ > "<Zielpfad>/curl-test.txt" 2>&1
test_rc=$?
ended_at=$(date "+%Y-%m-%dT%H:%M:%S%z")

echo "Start: $started_at"
echo "Ende: $ended_at"
echo "Exit-Code: $test_rc"
cat "<Zielpfad>/curl-test.txt"

Der Rückgabewert muss unmittelbar nach dem geprüften Befehl in einer Variablen gesichert werden.

14. Rückgabewerte unter Windows auswerten

PowerShell-Cmdlets

$? zeigt an, ob die unmittelbar vorherige PowerShell-Operation erfolgreich abgeschlossen wurde.

[RO] $?

Mögliche Werte:

Native Programme

$LASTEXITCODE enthält den Rückgabewert des zuletzt ausgeführten nativen Programms.

curl.exe --connect-timeout 5 --max-time 15 https://server.example/
$curlExitCode = $LASTEXITCODE
"curl Exit-Code: $curlExitCode"

Windows-Eingabeaufforderung

[RO] echo %ERRORLEVEL%

Der Rückgabewert muss direkt nach dem betreffenden Programm geprüft werden. Ein nachfolgender Befehl kann den gespeicherten Wert verändern.

15. Rückgabewerte unter Linux und macOS auswerten

$? enthält den Rückgabewert des zuletzt ausgeführten Befehls.

curl --connect-timeout 5 --max-time 15 https://server.example/
test_rc=$?
echo "Exit-Code: $test_rc"

Unter Unix-artigen Systemen bedeutet üblicherweise:

Rückgabewert Allgemeine Bedeutung
0 Programm meldet Erfolg
ungleich 0 Programm meldet Fehler oder besonderen Zustand

Die genaue Bedeutung hängt vom jeweiligen Programm ab und muss in dessen Dokumentation geprüft werden.

16. Erfolg des Werkzeugs und Erfolg der Funktion unterscheiden

Ein Rückgabewert 0 bedeutet nicht automatisch, dass die vom Benutzer benötigte Funktion erfolgreich war.

Beispiel mit curl

Ohne zusätzliche Option kann curl eine HTTP-Antwort 404, 403 oder 500 empfangen und trotzdem mit Exit-Code 0 enden. Die Netzwerkübertragung war erfolgreich, obwohl die Anwendung einen Fehlerstatus zurückgab.

Deshalb müssen mindestens zwei Ebenen getrennt werden:

Ebene Beispiel
Werkzeugausführung curl konnte eine HTTP-Antwort empfangen
Fachliche Funktion Benutzer konnte sich erfolgreich anmelden
Anwendungsstatus Server antwortete mit HTTP 200
Inhaltliche Richtigkeit Gelieferte Daten sind vollständig und korrekt

HTTP-Fehler als curl-Fehler behandeln

[TEST] curl --fail --connect-timeout 5 --max-time 15 https://server.example/

Die Option --fail lässt curl bei HTTP-Statuscodes ab 400 einen Fehler melden. Dabei wird der Antworttext normalerweise nicht ausgegeben.

Für eine Diagnose ist es häufig besser, zunächst HTTP-Status und Ausgabe separat zu dokumentieren.

17. Zeitbegrenzungen verwenden

Tests sollten nicht unbegrenzt warten.

Windows

[TEST] curl.exe --connect-timeout 5 --max-time 15 https://server.example/

Linux

[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/

macOS

[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/

Option Bedeutung
--connect-timeout 5 maximal fünf Sekunden für die Verbindungsphase
--max-time 15 maximal 15 Sekunden für den gesamten Transfer

Zur Verbindungsphase gehören bei curl unter anderem DNS-Auflösung sowie TCP-, TLS- oder QUIC-Verbindungsaufbau.

18. HTTP-Zeiten gezielt messen

curl kann einzelne Zeitabschnitte einer HTTP-Verbindung ausgeben.

Windows PowerShell

[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https://server.example/

Linux und macOS

[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https://server.example/

Bedeutung der Werte

Wert Bedeutung
http_code empfangener HTTP-Status
remote_ip tatsächlich verwendete Ziel-IP
time_namelookup Zeit bis zum Abschluss der Namensauflösung
time_connect Zeit bis zum TCP-Verbindungsaufbau
time_appconnect Zeit bis zum Abschluss des TLS-Handshakes
time_starttransfer Zeit bis zum ersten empfangenen Byte
time_total gesamte Übertragungszeit

Die Zeitwerte werden in Sekunden ausgegeben.

19. HTTP-Zeitwerte interpretieren

Beobachtung Mögliche Ursache
time_namelookup hoch DNS-Server, Resolver oder Weiterleitung langsam
time_connect hoch Netzwerkpfad, Firewall, Überlastung oder Server
time_appconnect deutlich höher TLS-Handshake, Zertifikat oder Kryptografie
time_starttransfer hoch Anwendung oder Backend benötigt lange
time_total hoch, erstes Byte schnell langsame Datenübertragung oder große Antwort
wechselnde remote_ip DNS-Rotation, Load Balancer oder mehrere Backends
wechselnder HTTP-Status unterschiedliche Backends oder instabiler Dienst
http_code=000 keine gültige HTTP-Antwort empfangen

Ein einzelner Messwert reicht bei sporadischen Fehlern nicht aus. Mehrere Messungen mit Zeitstempel sind aussagekräftiger.

20. Tests wiederholen, ohne unnötige Last zu erzeugen

Windows-Ping

[TEST] ping -n 10 <IP-Adresse>

Linux und macOS

[TEST] ping -c 10 <IP-Adresse>

Wiederholter TCP-Test unter Windows

1..5 | ForEach-Object {
    $result = Test-NetConnection server.example -Port 443 -InformationLevel Detailed

    [pscustomobject]@{
        Time          = Get-Date -Format o
        RemoteAddress = $result.RemoteAddress
        SourceAddress = $result.SourceAddress
        Success       = $result.TcpTestSucceeded
    }

    Start-Sleep -Seconds 2
}

Wiederholter TCP-Test unter Linux und macOS

for test_number in 1 2 3 4 5
do
    date "+%Y-%m-%dT%H:%M:%S%z"
    nc -vz -w 3 server.example 443
    sleep 2
done

Vor Wiederholungstests ist zu prüfen:

21. Sporadische Fehler richtig untersuchen

Ein sporadischer Fehler kann übersehen werden, wenn nur ein einzelner Test durchgeführt wird.

Zu dokumentieren sind:

Beispiel

Versuch Uhrzeit Ziel-IP TCP HTTP Gesamtzeit
1 15:30:00 198.51.100.20 erfolgreich 200 0,21 s
2 15:30:05 198.51.100.21 erfolgreich 503 4,92 s
3 15:30:10 198.51.100.20 erfolgreich 200 0,19 s
4 15:30:15 198.51.100.21 erfolgreich 503 5,01 s
5 15:30:20 198.51.100.20 erfolgreich 200 0,22 s

Das Muster deutet auf ein Problem mit dem Backend 198.51.100.21 hin.

22. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen

Der Aufruf einer HTTPS-Seite direkt über ihre IP-Adresse kann zu falschen Ergebnissen führen, weil:

Mit curl --resolve kann für einen einzelnen Test ein bestimmter Hostname einer bestimmten IP-Adresse zugeordnet werden, ohne DNS oder Hosts-Datei zu verändern.

Windows

[TEST] curl.exe --resolve "server.example:443:<IP-Adresse>" -v -o NUL https://server.example/

Linux und macOS

[TEST] curl --resolve "server.example:443:<IP-Adresse>" -v -o /dev/null https://server.example/

Dadurch bleiben erhalten:

Nur die Ziel-IP wird für diesen curl-Aufruf vorgegeben.

Beispiel für zwei Backends

[TEST] curl --resolve "server.example:443:198.51.100.20" -v -o /dev/null https://server.example/

[TEST] curl --resolve "server.example:443:198.51.100.21" -v -o /dev/null https://server.example/

Das direkte Testen eines Backends kann Load Balancer, WAF oder andere Schutzsysteme umgehen. Es darf nur erfolgen, wenn dieser Test technisch vorgesehen und autorisiert ist.

23. Lokalen Dienst und Netzwerkpfad getrennt testen

Windows-Server

[TEST] Test-NetConnection localhost -Port <Port>

[TEST] Test-NetConnection <Eigene-Server-IP> -Port <Port>

[TEST] Test-NetConnection <Servername> -Port <Port>

Linux-Server

[TEST] nc -vz -w 3 localhost <Port>

[TEST] nc -vz -w 3 <Eigene-Server-IP> <Port>

[TEST] nc -vz -w 3 <Servername> <Port>

macOS-Server

[TEST] nc -vz -w 3 localhost <Port>

[TEST] nc -vz -w 3 <Eigene-Server-IP> <Port>

[TEST] nc -vz -w 3 <Servername> <Port>

Interpretation

localhost Eigene IP Remote-Client Möglicher Fehlerbereich
erfolgreich erfolgreich erfolgreich Netzwerkgrundfunktion vorhanden
erfolgreich erfolgreich fehlgeschlagen Netzwerkpfad oder Firewall
erfolgreich fehlgeschlagen fehlgeschlagen Listener-Bindung oder lokale Firewall
fehlgeschlagen fehlgeschlagen fehlgeschlagen Dienst oder Anwendung
fehlgeschlagen erfolgreich erfolgreich besondere Proxy-, Container- oder Weiterleitungskonfiguration

24. Test mit und ohne Namensauflösung

DNS-basierter Test

[TEST] Test-NetConnection server.example -Port 443

Direkter TCP-Test zur bekannten IP

[TEST] Test-NetConnection <IP-Adresse> -Port 443

Unter Linux und macOS:

[TEST] nc -vz -w 3 server.example 443

[TEST] nc -vz -w 3 <IP-Adresse> 443

Interpretation

Name IP Möglicher Fehlerbereich
erfolgreich erfolgreich DNS und TCP-Grundfunktion vorhanden
fehlgeschlagen erfolgreich DNS oder Namensauswahl
erfolgreich fehlgeschlagen Testfehler oder unterschiedliche Zieladresse prüfen
fehlgeschlagen fehlgeschlagen Netzwerk, Firewall, Dienst oder Zielsystem

Der direkte IP-Test ist für TCP geeignet. Für HTTPS sollte wegen Host-Header, SNI und Zertifikatsprüfung curl --resolve verwendet werden.

25. Anwendungstest und Benutzerfunktion trennen

Ein technischer Test kann erfolgreich sein, obwohl die Benutzerfunktion weiterhin fehlschlägt.

Prüfebene Beispiel
DNS Hostname wird aufgelöst
Netzwerk Ziel-IP ist erreichbar
Transport TCP-Port ist erreichbar
TLS Zertifikat und Handshake funktionieren
HTTP Server liefert eine Antwort
Authentifizierung Benutzer kann sich anmelden
Autorisierung Benutzer darf die Funktion verwenden
Anwendung gewünschte Aktion wird verarbeitet
Datenebene Datenbank speichert oder liefert korrekte Daten
Geschäftsprozess gesamter Arbeitsablauf funktioniert

Beispiel

Die Ursache liegt dann nicht in der grundlegenden Erreichbarkeit, sondern möglicherweise in:

26. Vorher- und Nachher-Test identisch durchführen

Nach einer Maßnahme muss derselbe definierte Test erneut ausgeführt werden.

Ungeeigneter Vergleich

Diese Ergebnisse prüfen unterschiedliche Funktionen.

Geeigneter Vergleich

27. Vorher-Nachher-Protokoll

Feld Vorher Nachher
Zeitpunkt
Quellsystem
Quell-IP
Benutzer
Zielsystem
Ziel-IP
Protokoll und Port
DNS-Ergebnis
TCP-Ergebnis
TLS-Ergebnis
HTTP-Status
Antwortzeit
Anwendungsfunktion
Fehlermeldung
Monitoringstatus
Rückgabewert

28. Erfolgskriterien definieren

Ein Erfolgskriterium muss messbar sein.

Ungeeignet

Das System läuft wieder normal.

Besser

Schwellenwerte dürfen nicht frei erfunden werden. Sie müssen aus:

abgeleitet werden.

29. Abbruchkriterien definieren

Ein Test muss abgebrochen werden, wenn beispielsweise:

Abbruchvorlage

Feld Eintrag
Abbruchbedingung
Messgröße
Grenzwert
Verantwortliche Person
Sofortmaßnahme
Rückfallmaßnahme
Kommunikationsweg

30. Testergebnisse klassifizieren

Status Bedeutung
Bestanden Definiertes Erfolgskriterium vollständig erreicht
Nicht bestanden Definiertes Erfolgskriterium nicht erreicht
Teilweise bestanden Nur ein Teil der Kriterien erreicht
Nicht eindeutig Ergebnis lässt mehrere Erklärungen zu
Nicht reproduzierbar Fehler trat bei Wiederholung nicht erneut auf
Abgebrochen Abbruchkriterium wurde erreicht
Nicht durchgeführt Test konnte nicht ausgeführt werden
Ungültig Testbedingungen oder Messung waren fehlerhaft

„Nicht eindeutig“ ist ein gültiges Ergebnis. Es ist besser als eine unberechtigte Bestätigung.

31. Hypothese nach dem Test bewerten

Testergebnis Bewertung der Hypothese
Vorhersage vollständig eingetroffen Hypothese wird gestützt
Vorhersage mehrfach reproduziert Hypothese wird stark gestützt
Gegenprobe erfolgreich Ursache möglicherweise bestätigt
Ergebnis teilweise passend Hypothese bleibt offen
Ergebnis mehrdeutig neuer trennschärferer Test erforderlich
Vorhersage nicht eingetroffen Hypothese wird geschwächt
Widerlegendes Ergebnis eingetroffen Hypothese gilt als widerlegt
Testbedingungen fehlerhaft keine Bewertung möglich

Ein fehlgeschlagener Test bestätigt nicht automatisch die untersuchte Ursache. Er zeigt zunächst nur, dass die getestete Funktion unter den verwendeten Bedingungen fehlgeschlagen ist.

32. Falsch positive Ergebnisse

Ein Test meldet einen Fehler, obwohl die eigentliche Funktion verfügbar ist.

Beispiele

Test Falsch positives Ergebnis
Ping keine Antwort, weil ICMP blockiert ist
Traceroute Sternchen, obwohl Ziel erreichbar ist
Portscanner Port wirkt gefiltert, weil Sicherheitskomponente reagiert
DNS-Test anderer Load-Balancer wird als „falsche IP“ interpretiert
Zertifikatstest direkter IP-Aufruf erzeugt absichtlich Namensfehler
Dienststatus Dienst ist gestoppt, weil er socket-aktiviert gestartet wird
HTTP-HEAD Server lehnt HEAD ab, verarbeitet aber GET
Monitoring veralteter Alarm bleibt nach Wiederherstellung aktiv

33. Falsch negative Ergebnisse

Ein Test meldet Erfolg, obwohl die Benutzerfunktion weiterhin gestört ist.

Beispiele

Test Falsch negatives Ergebnis
Ping erfolgreich Anwendung oder Port kann trotzdem ausgefallen sein
TCP-Port erreichbar Anwendung kann fehlerhafte Antworten liefern
HTTP 200 Anmeldung oder Fachfunktion kann trotzdem fehlschlagen
Dienststatus „Running“ Prozess kann intern hängen
DNS-Auflösung erfolgreich zurückgegebene Adresse kann falsch sein
Einzelner Test erfolgreich sporadischer Fehler wird nicht erfasst
Testkonto funktioniert normales Benutzerkonto kann weiterhin falsche Rechte haben
Ein Backend funktioniert anderes Backend kann fehlerhaft sein
Speicherplatz vorhanden Inodes oder Quota können trotzdem erschöpft sein

34. Testwerkzeug und Testpunkt dokumentieren

Ein Ergebnis ist nur verständlich, wenn bekannt ist, wo und wie gemessen wurde.

Zu dokumentieren

Werkzeugversionen anzeigen

PowerShell

[RO] $PSVersionTable

curl

[RO] curl --version

OpenSSL

[RO] openssl version -a

Linux-Kernel

[RO] uname -a

macOS

[RO] sw_vers

Unterschiedliche Werkzeugversionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden.

35. Produktivumgebung gegen Testumgebung abwägen

Umgebung Vorteil Nachteil
Produktionssystem reales Fehlerbild Risiko für Benutzer und Daten
Testsystem geringeres Risiko möglicherweise nicht identische Konfiguration
Staging produktionsähnlich möglicherweise andere Daten oder Last
isolierter Client einzelne Variable kontrollierbar nicht jeder Netzwerkpfad wird abgebildet
Snapshot-Kopie Zustand kann untersucht werden flüchtige Informationen fehlen möglicherweise
Labor Tests gut reproduzierbar Produktionsabhängigkeiten fehlen

Ein Testsystem ist nur dann aussagekräftig, wenn relevante Unterschiede zur Produktion dokumentiert sind.

36. Änderungen in der Produktion absichern

Vor einer verändernden Prüfung sollten geklärt sein:

Freigabevorlage

Feld Eintrag
Ticketnummer
Hypothese
geplante Änderung
betroffene Systeme
erwartete Auswirkung
Risiko
Wartungsfenster
Backup vorhanden Ja / Nein
Rückfallplan
Abbruchkriterium
Freigabe durch
ausführende Person
beobachtende Person

37. Tests mit Anmeldungen vorsichtig durchführen

Anmeldetests können:

Vor einem Anmeldetest prüfen:

Kennwörter, Token und API-Schlüssel dürfen nicht in Protokolldateien, Terminaltranskripten oder Befehlszeilen erscheinen.

38. Beispiel eines kontrollierten Tests

Störung

Eine Webanwendung liefert sporadisch HTTP 503.

Hypothesen

Prüfplan

Schritt Test Erwarteter Erkenntnisgewinn
1 DNS mehrfach abfragen verwendete Zieladressen bestimmen
2 curl-Zeitmessung wiederholen HTTP-Status, Ziel-IP und Zeitstufe erfassen
3 Backends einzeln mit --resolve testen fehlerhaftes Backend identifizieren
4 TCP- und TLS-Ergebnisse vergleichen Netzwerk- und TLS-Ursachen bewerten
5 Serverlogs zum Zeitpunkt prüfen Backendfehler bestätigen

Ergebnis

Bewertung

39. Testprotokoll-Vorlage

Feld Eintrag
Ticketnummer
Testnummer
Hypothesennummer
Prüfziel
Datum
Startzeit
Endzeit
Zeitzone
ausführende Person
Quellsystem
Quell-IP und VLAN
Zielsystem
Ziel-IP
Protokoll und Port
Benutzerkontext
Werkzeug und Version
exakter Befehl
Ausgangszustand
erwartetes Ergebnis
widerlegendes Ergebnis
tatsächliches Ergebnis
Rückgabewert
Ausgabedatei
Hypothesenbewertung
Nebenwirkungen
Rückfall durchgeführt Ja / Nein / Nicht erforderlich
Zustand nach dem Test
nächster Schritt

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes liegt ein nachvollziehbares und reproduzierbares Testergebnis vor.

Ein brauchbares Testergebnis beantwortet:

Nächste Seite:
1.7 Ursache bestätigen und alternative Erklärungen ausschließen

Offizielle Hersteller- und Projektdokumentation

1.7 Ursache bestätigen und alternative Erklärungen ausschließen

Eine plausible Hypothese ist noch keine bestätigte Ursache. Auch wenn eine Maßnahme scheinbar erfolgreich war, kann ein anderer gleichzeitig veränderter Zustand für die Wiederherstellung verantwortlich gewesen sein.

Deshalb gilt:

Eine Ursache muss das Fehlerbild technisch erklären, zu Umfang und Zeitpunkt passen und durch Belege oder Gegenproben gestützt werden.

In komplexen IT-Systemen existiert häufig nicht nur eine einzelne Ursache. Meist wirken Auslöser, technische Fehler, Abhängigkeiten und begünstigende Bedingungen zusammen.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

2. Symptom, unmittelbare Ursache und Grundursache unterscheiden

Ebene Bedeutung Beispiel
Symptom Sichtbare Auswirkung Webanwendung liefert HTTP 503
Unmittelbare technische Ursache Zustand, der das Symptom direkt erzeugt Backend kann keine Datenbankverbindung aufbauen
Auslöser Ereignis, das den Fehler aktiviert hat Neue Konfiguration wurde bereitgestellt
Grundursache Systemischer Grund, warum der Fehler möglich war Pipeline prüfte den Datenbank-Hostnamen nicht
Begünstigender Faktor Bedingung, die Entstehung oder Auswirkung verstärkte Änderung wurde gleichzeitig auf allen Backends verteilt
Erkennungslücke Grund für eine verspätete Erkennung Monitoring prüfte nur, ob TCP 443 erreichbar war
Wiederherstellungsfaktor Maßnahme, die den Betrieb wiederherstellte Konfigurationsrollback
Präventionsmaßnahme Maßnahme gegen eine Wiederholung Validierung und schrittweise Bereitstellung einführen

3. Beispiel einer vollständigen Ursachenkette

Ebene Feststellung
Symptom Benutzer erhalten HTTP 503
Direkte Ursache Webanwendung erreicht die Datenbank nicht
Technischer Mechanismus Falscher Datenbank-Hostname in der Anwendungskonfiguration
Auslöser Deployment um 14:31 Uhr
Grundursache Deployment-Pipeline akzeptiert ungeprüfte Konfigurationswerte
Begünstigender Faktor Änderung wurde auf allen Instanzen gleichzeitig ausgerollt
Erkennungslücke Kein Ende-zu-Ende-Monitoring der Anmeldung
Wiederherstellung Vorherige Konfiguration wurde wiederhergestellt
Prävention Schema-Validierung, Staging-Test und schrittweiser Rollout

Die Aussage „Das Deployment war schuld“ wäre zu ungenau. Erst die vollständige Ursachenkette zeigt, was technisch fehlschlug und wodurch eine Wiederholung verhindert werden kann.

4. Nicht vorschnell nach einer einzigen Ursache suchen

Komplexe Störungen entstehen häufig durch eine Kombination mehrerer Bedingungen.

Beispiel

Ein einzelnes fehlerhaftes Backend führt nicht zwangsläufig zu einem Gesamtausfall. Der Ausfall entsteht möglicherweise erst, weil zusätzlich:

In diesem Fall gibt es mehrere relevante Ursachen und beitragende Faktoren.

Zu dokumentierende Ursachenarten

5. Eine Ursache gilt nicht allein durch zeitliche Nähe als bestätigt

Unzureichende Aussage

Der Fehler begann nach dem Update, also war das Update die Ursache.

Erforderliche Zusatzfragen

6. Stärke von Belegen bewerten

Beleg Aussagekraft
Vermutung ohne Messwert Sehr gering
Einzelne Benutzerangabe Gering
Zeitliche Nähe Gering bis mittel
Passende Fehlermeldung Mittel
Reproduzierbares Muster Mittel bis hoch
Konfigurationsunterschied zum funktionierenden System Hoch
Protokoll zeigt direkten technischen Fehler Hoch
Paketaufzeichnung bestätigt Kommunikationsfehler Hoch
Fehler verschwindet nach kontrollierter Entfernung der Ursache Sehr hoch
Fehler erscheint in Testumgebung nach kontrollierter Wiederherstellung der Ursache erneut Sehr hoch
Mehrere voneinander unabhängige Belege stimmen überein Sehr hoch

Eine zuverlässige Bestätigung verwendet möglichst mehrere voneinander unabhängige Belege.

7. Kriterien für eine bestätigte Ursache

Eine Ursache sollte möglichst folgende Fragen beantworten:

Kriterium Frage
Technischer Mechanismus Wie erzeugt die Ursache das beobachtete Symptom?
Fehlerumfang Warum sind genau diese Systeme oder Benutzer betroffen?
Zeitlicher Zusammenhang Warum begann der Fehler zu diesem Zeitpunkt?
Reproduzierbarkeit Lässt sich das Verhalten kontrolliert wiederholen?
Vergleich Warum funktionieren nicht betroffene Systeme?
Gegenprobe Verschwindet das Symptom ohne die vermutete Ursache?
Alternativen Welche anderen Erklärungen wurden geprüft?
Widersprüche Gibt es Fakten, die nicht zur Ursache passen?
Beweislage Welche Logs, Messwerte oder Vergleiche bestätigen sie?
Wiederholungsschutz Welche Maßnahme verhindert ein erneutes Auftreten?

Wenn eine vermutete Ursache den Umfang oder den technischen Mechanismus nicht erklären kann, ist sie wahrscheinlich unvollständig.

8. Die Gegenfrage stellen

Eine besonders wichtige Frage lautet:

Was müsste beobachtet werden, wenn die vermutete Ursache nicht stimmt?

Beispiel

Hypothese:

Eine Firewall-Regel blockiert TCP 443 aus VLAN 30.

Mögliche Gegenbelege:

Gegenbelege müssen genauso sorgfältig dokumentiert werden wie unterstützende Belege.

9. Kontrafaktische Prüfung

Eine kontrafaktische Prüfung untersucht, was ohne die vermutete Ursache geschehen würde.

Frage Bedeutung
Wäre die Störung ohne diese Bedingung aufgetreten? Prüft die Notwendigkeit der Ursache
Existiert dieselbe Bedingung auf funktionierenden Systemen? Prüft, ob sie allein ausreichend ist
Verschwindet der Fehler, wenn die Bedingung entfernt wird? Prüft den direkten Zusammenhang
Erscheint der Fehler in einer Testumgebung erneut? Prüft Reproduzierbarkeit
Erklärt die Ursache auch die nicht betroffenen Systeme? Prüft den Fehlerumfang
Gibt es einen anderen Faktor mit derselben Wirkung? Prüft alternative Erklärungen

Eine Bedingung kann notwendig, aber allein nicht ausreichend sein. Beispielsweise kann ein fehlerhaftes Backend erst zusammen mit einer fehlerhaften Load-Balancer-Konfiguration einen vollständigen Ausfall verursachen.

10. Ursachenbestätigung mit A/B-Vergleich

Zustand A Zustand B Mögliche Interpretation
Betroffenes System Funktionierendes System Unterschiede priorisieren
Fehlerhafte Konfiguration Bekannte funktionierende Konfiguration Konfigurationsunterschied prüfen
Benutzer A gestört Benutzer B funktioniert Konto oder Berechtigung prüfen
VLAN 30 gestört VLAN 40 funktioniert Netzwerkpfad oder ACL prüfen
Backend 1 funktioniert Backend 2 gestört Backend-spezifische Ursache
Anwendungsversion alt funktioniert neue Version gestört Versionsänderung priorisieren
Proxy verwendet direkter Test funktioniert Proxy oder Proxyrichtlinie prüfen
DNS-Auflösung verwendet festes Ziel funktioniert DNS oder Zielauswahl prüfen

Der Vergleich ist nur aussagekräftig, wenn alle nicht untersuchten Bedingungen möglichst gleich bleiben.

11. Betroffenes und funktionierendes System vergleichen

Zu vergleichende Eigenschaften

Bereich Beispiele
Betriebssystem Version, Build, Kernel
Updates Patchstand und Installationszeit
Anwendung Version, Module, Erweiterungen
Konfiguration Inhalt, Prüfsumme, Änderungszeit
Dienste Status, Starttyp, Dienstkonto
Netzwerk IP, VLAN, Gateway, DNS, Proxy
Sicherheit Firewallprofil, EDR, Zertifikate
Benutzer Gruppen, Rollen, Richtlinien
Dateien Version, Besitzer, Rechte, ACL
Abhängigkeiten Datenbank, API, Storage, DNS
Umgebung Variablen, Pfade, Laufzeitversion
Ressourcen CPU, RAM, Datenträger, Quota

12. Dateien und Konfigurationen unter Windows vergleichen

Dateiinhalte vergleichen

[RO] Compare-Object (Get-Content "<Funktionierende-Datei>") (Get-Content "<Betroffene-Datei>")

SHA-256-Prüfsumme bilden

[RO] Get-FileHash "<Datei>" -Algorithm SHA256

Dateiinformationen anzeigen

[RO] Get-Item "<Datei>" | Select-Object FullName, Length, CreationTime, LastWriteTime

Versionsinformationen einer ausführbaren Datei

[RO] (Get-Item "<Dateipfad>").VersionInfo

Berechtigungen anzeigen

[RO][SENSITIV] Get-Acl "<Pfad>" | Format-List

Installierte Hotfixes vergleichen

[RO] Get-HotFix | Sort-Object InstalledOn -Descending

13. Dateien und Konfigurationen unter Linux vergleichen

Dateien zeilenweise vergleichen

[RO] diff -u "<Funktionierende-Datei>" "<Betroffene-Datei>"

SHA-256-Prüfsumme bilden

[RO] sha256sum "<Datei>"

Dateiinformationen anzeigen

[RO] stat "<Datei>"

Dateityp bestimmen

[RO] file "<Datei>"

Berechtigungen und ACL anzeigen

[RO][SENSITIV] getfacl "<Datei>"

Debian- oder Ubuntu-Paketversion

[RO] dpkg-query -W "<Paketname>"

RHEL-, Rocky-, AlmaLinux- oder Fedora-Paketversion

[RO] rpm -q "<Paketname>"

14. Dateien und Konfigurationen unter macOS vergleichen

Dateien zeilenweise vergleichen

[RO] diff -u "<Funktionierende-Datei>" "<Betroffene-Datei>"

SHA-256-Prüfsumme bilden

[RO] shasum -a 256 "<Datei>"

Dateiinformationen anzeigen

[RO] stat -x "<Datei>"

Dateityp bestimmen

[RO] file "<Datei>"

Berechtigungen und ACL anzeigen

[RO][SENSITIV] ls -lde "<Datei>"

Anwendungsversion über Systeminformationen suchen

[RO] system_profiler SPApplicationsDataType

Bei umfangreichen Installationen kann system_profiler SPApplicationsDataType längere Zeit benötigen und eine große Ausgabe erzeugen.

15. Prüfsummen richtig interpretieren

Ergebnis Bedeutung
Prüfsummen identisch Dateien sind zum Prüfzeitpunkt binär identisch
Prüfsummen unterschiedlich Mindestens ein Byte unterscheidet sich
Dateiinhalt gleich, Metadaten anders Besitzer, Rechte oder Zeitstempel können abweichen
Anwendungsversion gleich, Prüfsumme anders anderer Build, beschädigte Datei oder Modifikation möglich
Prüfsumme gleich, Verhalten anders Ursache liegt wahrscheinlich außerhalb der Datei

Eine identische Prüfsumme beweist nicht, dass die gesamte Umgebung identisch ist.

16. Dienstabhängigkeiten unter Windows prüfen

Benötigte Dienste anzeigen

[RO] Get-Service -Name <Dienstname> -RequiredServices

Abhängige Dienste anzeigen

[RO] Get-Service -Name <Dienstname> -DependentServices

Dienstkonfiguration anzeigen

[RO] sc.exe qc <Dienstname>

Erweiterte Dienstinformationen

[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId

Dienstereignisse anzeigen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, Message

Listener eines Dienstes prüfen

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Prozess zum Listener bestimmen

[RO] Get-Process -Id <OwningProcess>

17. Dienstabhängigkeiten unter Linux prüfen

Abhängigkeiten eines Dienstes anzeigen

[RO] systemctl list-dependencies <Dienstname>.service --all

Dienste anzeigen, die vom untersuchten Dienst abhängen

[RO] systemctl list-dependencies <Dienstname>.service --reverse --all

Deklarierte Abhängigkeiten und Reihenfolge

[RO] systemctl show <Dienstname>.service -p Requires -p Wants -p After -p Before

Effektive Unit-Konfiguration anzeigen

[RO] systemctl cat <Dienstname>.service

Dienstzustand anzeigen

[RO] systemctl status <Dienstname>.service --no-pager

Dienstprotokoll anzeigen

[RO] journalctl -u <Dienstname>.service --since "1 hour ago" --no-pager

Listener prüfen

[RO][PRIV] ss -lntp | grep ":<Port>"

Prozess untersuchen

[RO] ps -p <PID> -o pid,ppid,user,lstart,stat,%cpu,%mem,command

18. Dienstzustand unter macOS prüfen

macOS verwendet launchd. Die richtige Dienst-Domain hängt davon ab, ob es sich um einen System-, Benutzer- oder GUI-Dienst handelt.

Geladene Dienste anzeigen

[RO] launchctl list

Systemdienst untersuchen

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienst untersuchen

[RO] launchctl print gui/<Benutzer-ID>/<Dienstlabel>

Die Benutzer-ID kann mit folgendem Befehl ermittelt werden:

[RO] id -u

Property-List anzeigen

[RO] plutil -p "<Pfad-zur-plist-Datei>"

Listener prüfen

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

Prozess untersuchen

[RO] ps -p <PID> -o pid,ppid,user,lstart,state,%cpu,%mem,command

launchd bildet Abhängigkeiten nicht in derselben Weise wie systemd ab. Deshalb müssen zusätzlich verwendete Sockets, Dateien, Netzwerkziele und Anwendungsprotokolle geprüft werden.

19. Technische Abhängigkeiten vollständig betrachten

Ein sichtbarer Dienst kann von vielen weiteren Komponenten abhängen.

Komponente Mögliche Abhängigkeit
Client DNS, Proxy, Zertifikat, Richtlinie
DNS Zone, Forwarder, Netzwerk, Root-Server
Webserver Zertifikat, Dateisystem, Backend
Reverse Proxy Upstream, Health Check, DNS
Anwendung Datenbank, Cache, Queue, API
Datenbank Storage, Speicher, Replikation
Authentifizierung Active Directory, LDAP, RADIUS, MFA
Zertifikat CA, Zwischenzertifikat, Uhrzeit, Sperrprüfung
Dateifreigabe DNS, Kerberos, Berechtigung, Storage
Container Netzwerk, Volume, Secret, Image
Virtuelle Maschine Hypervisor, Datastore, virtuelles Netzwerk
Cloud-Dienst IAM, Sicherheitsgruppe, Region, Provider
Backup Agent, Repository, Netzwerk, Dienstkonto
Monitoring Agent, Collector, Zeit, Datenbank

20. Abhängigkeitskette dokumentieren

Beispiel: Anmeldung an einer Webanwendung

Reihenfolge Komponente Erforderliche Funktion
1 Client Netzwerkverbindung vorhanden
2 DNS Hostname wird korrekt aufgelöst
3 Firewall TCP 443 wird erlaubt
4 Load Balancer funktionsfähiges Backend wird gewählt
5 Webserver TLS und HTTP funktionieren
6 Anwendung Anmeldeanfrage wird verarbeitet
7 Identitätsdienst Benutzer wird authentifiziert
8 Datenbank Benutzer- und Sitzungsdaten sind verfügbar
9 Anwendung Rolle wird geprüft
10 Browser Sitzungscookie wird gespeichert

Ein Fehler in einer späteren Abhängigkeit kann nach außen wie ein allgemeiner „Webserverfehler“ wirken.

21. Abhängigkeit gezielt umgehen oder isolieren

Eine Komponente kann für einen Test kontrolliert aus dem Pfad genommen werden. Dies darf keine dauerhafte oder unautorisierte Umgehung von Sicherheitskontrollen werden.

DNS für einen einzelnen curl-Test umgehen

[TEST] curl --resolve "server.example:443:<IP-Adresse>" -v https://server.example/

Dadurch bleiben Hostname, HTTP-Host-Header, SNI und Zertifikatsprüfung erhalten.

Proxy für einen einzelnen curl-Test umgehen

[TEST] curl --noproxy "*" -v https://server.example/

Das Umgehen eines Unternehmensproxys kann gegen Sicherheitsrichtlinien verstoßen. Der Test darf nur durchgeführt werden, wenn direkte Verbindungen erlaubt und ausdrücklich autorisiert sind.

Anwendungsebene gegen Transportebene

Windows:

[TEST] Test-NetConnection server.example -Port 443

Linux und macOS:

[TEST] nc -vz -w 3 server.example 443

Anschließend:

[TEST] curl -v https://server.example/

TCP-Test HTTP-Test Wahrscheinlicher Bereich
erfolgreich erfolgreich grundlegender Dienstpfad funktioniert
erfolgreich fehlgeschlagen TLS, HTTP, Anwendung oder Authentifizierung
fehlgeschlagen nicht möglich Netzwerk, Firewall oder Listener
wechselnd wechselnd Load Balancer, Backend oder instabiler Pfad

22. Alternative Erklärungen bei typischen Beobachtungen

Beobachtung Mögliche alternative Erklärungen
Neustart löst Fehler Cache, Speicherleck, Prozesszustand, Verbindung, Timing
Dienstneustart löst Fehler Abhängigkeit wurde neu verbunden, Port freigegeben, Konfiguration neu geladen
DNS-Cache-Leerung löst Fehler TTL wäre gleichzeitig abgelaufen, DNS-Eintrag wurde parallel geändert
Firewall-Änderung löst Fehler Stateful Session wurde erneuert, NAT oder Route änderte sich
Update-Rollback löst Fehler Rollback enthielt ebenfalls Neustart oder Konfigurationsrücksetzung
Kabelwechsel löst Fehler Port wurde neu ausgehandelt, Switchport oder DHCP-Lease änderte sich
Anmeldung mit Testkonto funktioniert Konto, Rolle, Profil, MFA oder Lizenz unterscheiden sich
Zugriff über IP funktioniert DNS möglich, aber HTTPS über IP wurde nicht vollständig geprüft
Port ist offen Anwendung kann intern trotzdem fehlerhaft sein
Dienststatus ist „Running“ Prozess kann hängen oder Abhängigkeit nicht erreichen
Ein Test ist erfolgreich sporadischer Fehler kann weiterhin bestehen
Fehler verschwindet von selbst Last, Lease, TTL, Token oder Providerzustand änderte sich

23. Warum „Nach Maßnahme funktioniert es“ nicht immer genügt

Zwischen Maßnahme und erfolgreichem Test können weitere Veränderungen stattgefunden haben:

Deshalb müssen Zeitpunkt, technische Wirkung und Kontrolltest zusammen betrachtet werden.

24. Gegenprobe durchführen

Eine Gegenprobe testet, ob das Ergebnis wirklich von der vermuteten Ursache abhängt.

Geeignete Gegenproben

Nicht geeignete Gegenprobe

Eine produktive Fehlkonfiguration wird absichtlich erneut aktiviert, obwohl dadurch ein weiterer Ausfall entstehen könnte.

Eine erneute Fehlererzeugung gehört normalerweise in:

25. Die Fünf-Warum-Methode vorsichtig einsetzen

Die Fünf-Warum-Methode fragt wiederholt nach dem technischen oder organisatorischen Grund eines Fehlers.

Beispiel

Frage Antwort
Warum war die Anwendung nicht erreichbar? Der Dienst konnte nicht starten
Warum konnte der Dienst nicht starten? Die Konfigurationsdatei war ungültig
Warum war die Konfigurationsdatei ungültig? Ein Deployment setzte einen falschen Portwert
Warum wurde der falsche Wert akzeptiert? Es gab keine Schema-Validierung
Warum fehlte die Validierung? Sie war im Deploymentprozess nicht vorgesehen

Mögliche Grundursache

Der Deploymentprozess validiert Konfigurationswerte nicht vor der produktiven Bereitstellung.

Mögliche Prävention

26. Grenzen der Fünf-Warum-Methode

Die Methode darf nicht dazu führen, dass eine komplexe Störung künstlich auf eine einzelne lineare Ursache reduziert wird.

Mögliche Probleme

Für komplexe Störungen ist eine Ursachenmatrix häufig besser.

27. Ursachenmatrix

Faktor Vorhanden Notwendig Allein ausreichend Belegt Bewertung
Falscher Datenbank-Hostname Ja Ja Nein Konfigurationsvergleich Direkte Ursache
Keine Konfigurationsvalidierung Ja Nein Nein Pipeline geprüft Grundursache
Gleichzeitiger Rollout Ja Nein Nein Deploymentprotokoll Verstärkte Auswirkung
Kein Ende-zu-Ende-Monitoring Ja Nein Nein Monitoringkonfiguration Erkennungslücke
Hohe Benutzerlast Nein Nein Nein Monitoring Widerlegt
Datenbankausfall Nein Nein Nein Datenbankmonitoring Widerlegt

28. Menschliche Handlung nicht automatisch als Grundursache verwenden

Ungeeignet

Der Administrator hat die falsche Adresse eingetragen.

Diese Aussage beendet die Untersuchung zu früh.

Weiterführende Fragen

Eine sachliche Ursachenanalyse untersucht, wie Systeme und Prozesse verbessert werden können, statt einzelne Personen zu beschuldigen.

29. Bestätigungsgrade verwenden

Grad Bedeutung
Bestätigt Direkter Mechanismus, mehrere Belege und Gegenprobe vorhanden
Sehr wahrscheinlich Mechanismus und mehrere Belege vorhanden, Gegenprobe nicht möglich
Wahrscheinlich Plausibel und teilweise belegt
Möglich Technisch denkbar, aber kaum belegt
Unklar Belege reichen nicht für eine Bewertung
Unwahrscheinlich Mehrere Fakten widersprechen
Widerlegt Definierte Vorhersage wurde durch Gegenbeleg widerlegt

Wenn eine Gegenprobe aus Sicherheits- oder Produktionsgründen nicht möglich ist, sollte die Ursache als „sehr wahrscheinlich“ und nicht automatisch als vollständig bestätigt dokumentiert werden.

30. Wann die Ursachensuche beendet werden kann

Die Untersuchung kann beendet oder in eine spätere Nachanalyse überführt werden, wenn:

Eine Untersuchung sollte nicht endlos fortgeführt werden. Der notwendige Beweisgrad hängt von Auswirkung und Risiko der Störung ab.

Störung Erforderlicher Beweisgrad
Einzelner unkritischer Arbeitsplatz technische Plausibilität und dokumentierter Funktionstest
Wiederkehrende Unternehmensstörung mehrere Belege und Gegenprobe
Kritischer Produktionsausfall ausführliche Ursachenanalyse
Datenverlust hohe Beweissicherheit und Managementbeteiligung
Sicherheitsvorfall Incident Response und möglicherweise Forensik
Rechtlich relevanter Vorfall dokumentierte Beweismittelkette und Fachstellen

31. Vollständiges Praxisbeispiel

Störung

Seit 14:31 Uhr liefert https://server.example abwechselnd HTTP 200 und HTTP 503.

Fehlerumfang

Hypothesen

Nr. Hypothese
H1 DNS liefert eine nicht vorgesehene IP-Adresse
H2 Eines der Backends ist fehlerhaft
H3 Load Balancer verteilt Anfragen falsch
H4 Datenbank ist vollständig ausgefallen
H5 Clientnetzwerk ist instabil

Prüfungen

Bewertung der Hypothesen

Hypothese Bewertung Begründung
H1 Widerlegt Beide DNS-Adressen sind vorgesehen
H2 Bestätigt Fehler ist reproduzierbar an Backend 2 gebunden
H3 Teilweise bestätigt Health Check erkennt den Backendfehler nicht
H4 Widerlegt Datenbank und Backend 1 funktionieren
H5 Widerlegt TCP- und TLS-Verbindungen sind stabil

Ursachenkette

Ebene Feststellung
Symptom ungefähr jede zweite Anfrage liefert HTTP 503
Direkte Ursache Backend 2 erreicht die Datenbank nicht
Technischer Fehler falscher Datenbank-Hostname
Auslöser Deployment um 14:31 Uhr
Grundursache fehlende Validierung der Konfiguration
Begünstigender Faktor fehlerhafter Health Check
Erkennungslücke Monitoring prüft keine Datenbankfunktion
Sofortmaßnahme Backend 2 aus Rotation nehmen oder Konfiguration zurücksetzen
Prävention Validierung und anwendungsnahen Health Check einführen

32. Dokumentationsvorlage für die Ursachenkette

Feld Eintrag
Ticketnummer
Symptom
Fehlerumfang
Beginn der Störung
Direkte technische Ursache
Technischer Mechanismus
Auslöser
Grundursache
Begünstigende Faktoren
Erkennungslücken
Wiederherstellungsfaktoren
Unterstützende Belege
Widersprechende Belege
Geprüfte Alternativen
Durchgeführte Gegenprobe
Bestätigungsgrad
Verbleibende Unsicherheiten
Sofortmaßnahme
Präventionsmaßnahme

33. Vorlage für alternative Erklärungen

Nr. Alternative Erklärung Erwartete Beobachtung Tatsächliche Beobachtung Beleg Status
A1 Offen
A2 Offen
A3 Offen
A4 Offen

34. Prüffragen zur Grundursache

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes liegt eine nachvollziehbare Ursachenkette vor. Sie unterscheidet:

Eine Ursache gilt nicht allein deshalb als bestätigt, weil der Fehler nach einer Änderung verschwunden ist. Sie muss zum Fehlerbild passen, durch technische Belege gestützt und gegen alternative Erklärungen geprüft worden sein.

Nächste Seite:
1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren

Offizielle Hersteller-, Standard- und Projektdokumentation

1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren

Nachdem die Ursache ausreichend bestätigt wurde, kann eine geeignete Lösung geplant und umgesetzt werden.

Dabei gilt:

Eine Störung gilt nicht als behoben, nur weil eine Fehlermeldung verschwunden ist. Die ursprüngliche Funktion, ihre Abhängigkeiten und mögliche Nebenwirkungen müssen anschließend geprüft werden.

Jede technische Korrektur ist selbst eine Änderung und kann neue Fehler verursachen. Deshalb benötigt auch eine scheinbar einfache Maßnahme einen definierten Ausgangszustand, Erfolgskriterien und einen Rückfallplan.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

2. Maßnahmenarten unterscheiden

Maßnahmenart Zweck Beispiel
Sofortmaßnahme Auswirkungen schnell begrenzen fehlerhaftes Backend aus dem Load Balancer nehmen
Workaround Fehler umgehen, ohne Ursache zu entfernen Benutzer verwendet vorübergehend anderen Server
Mitigation Auswirkung oder Wahrscheinlichkeit reduzieren Traffic auf funktionierende Instanzen begrenzen
Reparatur unmittelbaren technischen Fehler beseitigen fehlerhafte Konfiguration korrigieren
Dauerhafte Lösung bestätigte Grundursache beseitigen automatische Konfigurationsvalidierung einführen
Präventionsmaßnahme Wiederholung oder Auswirkung verhindern Canary-Rollout und Monitoring ergänzen
Rollback vorherigen bekannten Zustand wiederherstellen vorherige Anwendungsversion aktivieren
Roll-forward Fehler durch eine neue Korrektur beheben korrigierte Folgeversion bereitstellen

Ein Workaround kann den Betrieb wiederherstellen, ohne die eigentliche Ursache zu beseitigen. Er muss deshalb als temporär gekennzeichnet und nachverfolgt werden.

3. Wiederherstellung und Ursachenbehebung unterscheiden

Wiederherstellung

Ziel ist, die betroffene Funktion möglichst schnell wieder bereitzustellen.

Beispiele:

Ursachenbehebung

Ziel ist, das erneute Auftreten zu verhindern.

Beispiele:

Eine Störung kann bereits wiederhergestellt sein, während die dauerhafte Ursachenbehebung noch offen ist.

4. Vor jeder Änderung zu klärende Fragen

5. Änderungsumfang möglichst klein halten

Eine Korrektur sollte nur die Komponente verändern, die für die bestätigte Ursache relevant ist.

Ungeeignet

Besser

  1. eine klar definierte Änderung,
  2. definierter Funktionstest,
  3. Beobachtung,
  4. nächste Änderung nur bei Bedarf.

Kleine Änderungen lassen sich leichter:

6. Risiko der Änderung bewerten

Risikofaktor Niedriges Risiko Hohes Risiko
Umfang einzelner Testclient gesamte Produktion
Reversibilität einfache Konfigurationsrücknahme irreversible Datenmigration
Verfügbarkeit redundantes System einzelner kritischer Server
Erfahrung dokumentierte Standardänderung erstmalige unbekannte Änderung
Abhängigkeiten wenige bekannte Abhängigkeiten viele unbekannte Abhängigkeiten
Daten keine Datenänderung Schema- oder Datenänderung
Zugang lokaler Konsolenzugang nur entfernte Verbindung
Testbarkeit funktionierende Testumgebung nur Produktion verfügbar
Beobachtung vollständiges Monitoring kaum Messwerte vorhanden
Zeitdruck geplantes Wartungsfenster ungeplanter kritischer Ausfall

7. Änderungsplan erstellen

Feld Eintrag
Ticket- oder Change-Nummer
bestätigte Ursache
geplante Änderung
technisches Ziel
betroffene Systeme
betroffene Benutzer
Abhängigkeiten
erwartete Unterbrechung
Risiko Niedrig / Mittel / Hoch
ausführende Person
beobachtende Person
Wartungsfenster
Sicherung des Ausgangszustands
Erfolgskriterien
Abbruchkriterien
Rückfallplan
Rückfallentscheidung durch
Kommunikationsweg
Beobachtungsdauer

8. Backup und Rollback unterscheiden

Begriff Bedeutung
Backup Sicherung von Daten oder Konfiguration
Restore Wiederherstellung aus einem Backup
Rollback Rückkehr zum vorherigen bekannten Betriebszustand
Snapshot Momentaufnahme eines bestimmten Systems oder Datenträgers
Export Sicherung einer Konfiguration in einem unterstützten Format
Roll-forward Korrektur durch eine nachfolgende Version oder Änderung

Ein vorhandenes Backup ist noch kein vollständiger Rückfallplan.

Ein Rückfallplan beantwortet zusätzlich:

9. Grenzen von Snapshots beachten

Ein Snapshot ersetzt kein reguläres Backup und ist nicht für jede Anwendung als Rückfallmethode geeignet.

Besondere Vorsicht gilt unter anderem bei:

Vor der Nutzung eines Snapshots muss geprüft werden:

10. Ausgangskonfiguration sichern

Für produktive Systeme sollte möglichst die vom Hersteller vorgesehene Export-, Backup- oder Versionsverwaltungsfunktion verwendet werden.

Einfache Dateikopien sind nur für einzelne Konfigurationsdateien geeignet, wenn Berechtigungen, Besitzer, ACLs, erweiterte Attribute und Anwendungsanforderungen berücksichtigt werden.

Windows-Beispiel für eine einzelne Konfigurationsdatei

$backupFile = Join-Path "<Zielpfad>" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak"

Copy-Item "<Konfigurationsdatei>" $backupFile

Get-FileHash -Path "<Konfigurationsdatei>", $backupFile -Algorithm SHA256

Kennzeichnung:

Die Prüfsummen sollten bei einer unveränderten Kopie identisch sein.

Linux-Beispiel für eine einzelne Konfigurationsdatei

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"

cp --preserve=all -- "<Konfigurationsdatei>" "$backup_file"

sha256sum "<Konfigurationsdatei>" "$backup_file"

cp --preserve=all ist eine GNU-Option und steht nicht auf jedem Unix-System zur Verfügung.

macOS-Beispiel für eine einzelne Konfigurationsdatei

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"

cp -p "<Konfigurationsdatei>" "$backup_file"

shasum -a 256 "<Konfigurationsdatei>" "$backup_file"

cp -p erhält wichtige Dateiattribute, garantiert aber nicht für jede Anwendung die vollständige Sicherung aller Metadaten. Für komplexe Anwendungen muss die vorgesehene Backupfunktion verwendet werden.

11. Konfiguration vor der Aktivierung validieren

Eine Konfigurationsdatei sollte möglichst vor einem Reload oder Neustart geprüft werden.

JSON unter Windows PowerShell prüfen

[TEST] Get-Content "<Datei.json>" -Raw | ConvertFrom-Json | Out-Null

Bei ungültigem JSON erzeugt PowerShell eine Fehlermeldung.

JSON unter Linux oder macOS mit Python prüfen

[TEST] python3 -m json.tool "<Datei.json>" > /dev/null

JSON mit jq prüfen, sofern installiert

[TEST] jq empty "<Datei.json>"

macOS-Property-List prüfen

[TEST] plutil -lint "<Datei.plist>"

systemd-Unit-Datei prüfen

[TEST] systemd-analyze verify "<Datei.service>"

NGINX-Konfiguration prüfen

[TEST][PRIV] nginx -t

Apache-Konfiguration prüfen

[TEST][PRIV] apachectl configtest

OpenSSH-Serverkonfiguration prüfen

[TEST][PRIV] sshd -t

Die Werkzeuge prüfen unterschiedliche Aspekte. Ein erfolgreicher Syntax-Test bestätigt nicht automatisch, dass Netzwerkziele, Zugangsdaten, Zertifikate und abhängige Dienste funktionieren.

12. PowerShell-Änderung mit WhatIf vorprüfen

Einige PowerShell-Cmdlets unterstützen den allgemeinen Parameter -WhatIf.

Beispiel

[TEST] Restart-Service -Name <Dienstname> -WhatIf

PowerShell zeigt, welche Aktion vorgesehen ist, führt den Neustart aber nicht aus.

Wichtige Einschränkung

-WhatIf:

13. Dienständerungen unter Windows

Aktuellen Zustand prüfen

[RO] Get-Service -Name <Dienstname>

Abhängige Dienste prüfen

[RO] Get-Service -Name <Dienstname> -DependentServices

Benötigte Dienste prüfen

[RO] Get-Service -Name <Dienstname> -RequiredServices

Dienstkonfiguration prüfen

[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId

Neustart zunächst anzeigen

[TEST] Restart-Service -Name <Dienstname> -WhatIf

Dienst mit Bestätigungsabfrage neu starten

[CHANGE][DISRUPTIV][PRIV] Restart-Service -Name <Dienstname> -Confirm

Gestoppten Dienst starten

[CHANGE][PRIV] Start-Service -Name <Dienstname> -Confirm

Zustand danach prüfen

[RO] Get-Service -Name <Dienstname>

Restart-Service sendet eine Stopp- und anschließend eine Startanforderung. War der Dienst bereits gestoppt, versucht das Cmdlet ihn zu starten. Vorher müssen abhängige Dienste und Auswirkungen geprüft werden.

14. Dienständerungen unter Linux

Aktuellen Zustand prüfen

[RO] systemctl status <Dienstname>.service --no-pager

Zustand kompakt prüfen

[RO] systemctl is-active <Dienstname>.service

Reload-Fähigkeit prüfen

[RO] systemctl show <Dienstname>.service -p CanReload -p ActiveState -p SubState -p MainPID

Konfiguration neu laden

[CHANGE][PRIV] sudo systemctl reload <Dienstname>.service

Ein Reload funktioniert nur, wenn der Dienst diese Funktion unterstützt.

Dienst neu starten

[CHANGE][DISRUPTIV][PRIV] sudo systemctl restart <Dienstname>.service

Nur dann neu starten, wenn der Dienst bereits läuft

[CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart <Dienstname>.service

Zustand danach prüfen

[RO] systemctl status <Dienstname>.service --no-pager

Neue Protokolle anzeigen

[RO] journalctl -u <Dienstname>.service --since "5 minutes ago" --no-pager

15. Dienständerungen unter macOS

macOS verwendet launchd. Für die Befehle muss der richtige Dienstkontext bekannt sein.

Systemdienst prüfen

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienst prüfen

[RO] launchctl print gui/$(id -u)/<Dienstlabel>

Systemdienst beenden und neu starten

[CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/<Dienstlabel>

Benutzerdienst beenden und neu starten

[CHANGE][DISRUPTIV] launchctl kickstart -k gui/$(id -u)/<Dienstlabel>

Die Option -k beendet eine bereits laufende Instanz, bevor sie neu gestartet wird.

Protokolle danach prüfen

[RO] log show --last 5m --predicate 'process == "<Prozessname>"' --style compact

Vor dem Einsatz muss die lokale Dokumentation mit man launchctl geprüft werden. System-, Benutzer- und GUI-Dienste verwenden unterschiedliche Domains. Ein falscher Dienstkontext kann dazu führen, dass nicht der erwartete Dienst angesprochen wird.

16. Reload, Restart und Reboot unterscheiden

Maßnahme Wirkung Typisches Risiko
Reload Konfiguration wird im laufenden Prozess neu geladen Niedrig bis mittel
Restart Prozess wird beendet und neu gestartet Mittel bis hoch
Reboot gesamtes Betriebssystem wird neu gestartet Hoch
Failover Betrieb wechselt auf anderes System Mittel bis hoch
Rollback vorheriger Zustand wird wiederhergestellt Abhängig von Daten und Anwendung

Sinnvolle Reihenfolge

  1. anwendungseigene Konfigurationsprüfung,
  2. Reload, wenn unterstützt,
  3. gezielter Dienstneustart,
  4. Failover oder Rollback,
  5. vollständiger Systemneustart nur mit technischer Begründung.

Ein vollständiger Neustart sollte nicht als Standardlösung verwendet werden, wenn ein einzelner Dienst gezielt behandelt werden kann.

17. Änderungen schrittweise ausrollen

Verfahren Beschreibung
Einzelner Testclient Änderung zunächst auf einem ausgewählten Client
Einzelne Instanz Änderung auf einem Server innerhalb einer redundanten Gruppe
Canary kleiner Anteil produktiver Systeme oder Anfragen
Rolling Deployment Instanzen werden nacheinander geändert
Blue-Green neue und alte Umgebung existieren parallel
Staged Rollout Änderung wird in definierten Stufen erweitert
Wartungsgruppe ausgewählte Benutzer oder Systeme werden zuerst umgestellt

Beispiel für einen stufenweisen Rollout

  1. Testumgebung,
  2. einzelne produktionsnahe Instanz,
  3. ausgewählte Benutzer,
  4. kleiner Produktionsanteil,
  5. Monitoring auswerten,
  6. weitere Instanzen,
  7. vollständiger Rollout.

Nach jeder Stufe muss ein Entscheidungspunkt bestehen:

18. Canary und Kontrollgruppe vergleichen

Messwert Kontrollgruppe Canary Bewertung
Fehlerrate 0,5 % 0,6 % ähnlich
Antwortzeit 220 ms 225 ms ähnlich
CPU-Auslastung 42 % 44 % ähnlich
HTTP 500 2 3 beobachten
erfolgreiche Anmeldungen 99,5 % 99,4 % ähnlich
neue Protokollfehler 0 0 unauffällig

Die Bewertung darf nicht nur auf dem Gesamtsystem erfolgen. Ein kleiner Canary kann in aggregierten Messwerten unsichtbar bleiben. Canary und Kontrollgruppe müssen getrennt ausgewertet werden.

19. Abbruchkriterien vor dem Rollout festlegen

Mögliche Abbruchkriterien:

Schwellenwerte müssen aus SLA, SLO, Monitoring-Baseline oder dokumentierten Anforderungen stammen und dürfen nicht frei erfunden werden.

20. Technische Verifikation in mehreren Ebenen

Ebene Zu prüfende Frage
Prozess Läuft der erwartete Prozess?
Dienst Meldet der Dienst einen gesunden Zustand?
Listener Lauscht der erwartete Port?
Netzwerk Ist das Ziel vom vorgesehenen Client erreichbar?
TLS Funktionieren Zertifikat und Handshake?
Protokoll Liefert der Dienst eine gültige Antwort?
Authentifizierung Kann sich der Benutzer anmelden?
Autorisierung Darf der Benutzer die vorgesehene Funktion verwenden?
Anwendung Funktioniert die konkrete Aktion?
Daten Werden Daten korrekt gelesen und geschrieben?
Abhängigkeiten Funktionieren Datenbank, Storage, DNS und APIs?
Monitoring Wird das System korrekt als gesund erkannt?
Protokolle Entstehen keine neuen relevanten Fehler?
Redundanz Sind verbleibende Instanzen und Failover weiterhin verfügbar?

21. Windows-Verifikation

Dienststatus

[RO] Get-Service -Name <Dienstname>

Prozess-ID des Dienstes

[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, ProcessId

TCP-Listener

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Remote-Porttest

[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed

HTTP- oder HTTPS-Test

[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Neue Systemereignisse

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Neue Anwendungsereignisse

[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

22. Linux-Verifikation

Dienststatus

[RO] systemctl status <Dienstname>.service --no-pager

Nur aktiven Zustand abfragen

[RO] systemctl is-active <Dienstname>.service

Hauptprozess-ID

[RO] systemctl show <Dienstname>.service -p MainPID

TCP-Listener

[RO][PRIV] ss -lntp | grep ":<Port>"

Remote-Porttest

[TEST] nc -vz -w 3 <Servername> <Port>

HTTP- oder HTTPS-Test

[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Neue Dienstprotokolle

[RO] journalctl -u <Dienstname>.service --since "10 minutes ago" --no-pager

Neue Fehler des Systems

[RO] journalctl --since "10 minutes ago" -p err --no-pager

23. macOS-Verifikation

Systemdienststatus

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienststatus

[RO] launchctl print gui/$(id -u)/<Dienstlabel>

TCP-Listener

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

Remote-Porttest

[TEST] nc -vz -w 3 <Servername> <Port>

HTTP- oder HTTPS-Test

[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Neue Prozessprotokolle

[RO] log show --last 10m --predicate 'process == "<Prozessname>"' --style compact

Neue Fehler und Faults

[RO] log show --last 10m --predicate 'messageType == error OR messageType == fault' --style compact

24. Ursprüngliche Benutzerfunktion prüfen

Eine technische Verifikation reicht nicht aus. Abschließend muss die ursprünglich gestörte Funktion getestet werden.

Beispiele

Der Test sollte möglichst:

durchgeführt werden.

25. Positive und negative Tests durchführen

Positiver Test

Prüft, ob eine erlaubte Funktion erfolgreich ist.

Beispiel:

Ein berechtigter Benutzer kann eine Datei lesen.

Negativer Test

Prüft, ob eine nicht erlaubte Funktion weiterhin verhindert wird.

Beispiel:

Ein unberechtigter Benutzer kann die Datei weiterhin nicht lesen.

Weitere negative Tests

Eine Lösung ist fehlerhaft, wenn sie die Funktion wiederherstellt, dabei aber Sicherheitskontrollen unbeabsichtigt entfernt.

26. Regressionstests durchführen

Ein Regressionstest prüft, ob bisher funktionierende Bereiche nach der Änderung weiterhin funktionieren.

Geänderte Komponente Mögliche Regressionstests
Firewall andere erlaubte und gesperrte Verbindungen
DNS interne und externe Namensauflösung
DHCP neue und bestehende Clients
Webserver Anmeldung, Upload, Download, API
Datenbank Lesen, Schreiben, Replikation, Backup
Dateiserver Lesen, Schreiben, ACL, Freigaben
Active Directory Anmeldung, Gruppenrichtlinie, Replikation
Proxy erlaubte Seiten, Ausnahmen, Authentifizierung
Zertifikat Browser, API, mobile Clients, alte Clients
Load Balancer alle Backends, Health Checks, Sitzungen
Backup Sicherung und testweise Wiederherstellung

27. Persistenz der Lösung prüfen

Manche Korrekturen funktionieren nur bis zum nächsten:

Zu prüfen ist:

Ein Neustart zur Persistenzprüfung darf nur geplant durchgeführt werden, wenn er technisch erforderlich und freigegeben ist.

28. Monitoring nach der Änderung

Nach einer erfolgreichen Funktionsprüfung muss das System weiter beobachtet werden.

Zu beobachtende Werte

Die Beobachtungsdauer richtet sich nach dem Fehlerbild.

Fehlerart Geeignete Beobachtung
dauerhafter Startfehler unmittelbare Tests nach Start
sporadischer Fehler mehrere typische Nutzungszyklen
nächtlicher Job mindestens nächster geplanter Lauf
DHCP-Problem mindestens ein Lease-Erneuerungszyklus
Backupfehler vollständiger Sicherungs- und Prüfzyklus
Lastproblem typischer Lastzeitraum
Zertifikatserneuerung vollständige Kette und betroffene Clients
Replikationsproblem vorgesehener Replikationszyklus

29. Rollback-Auslöser

Ein Rollback sollte ausgelöst werden, wenn:

Die Entscheidung darf nicht erst improvisiert werden, nachdem ein Problem entstanden ist.

30. Kontrollierter Rollback-Ablauf

  1. weiteren Rollout stoppen,
  2. zuständige Personen informieren,
  3. aktuellen Fehlerzustand sichern,
  4. Rückfallentscheidung dokumentieren,
  5. freigegebenen Rückfallplan ausführen,
  6. Dienst- und Systemstatus prüfen,
  7. ursprüngliche Funktion testen,
  8. negative Tests durchführen,
  9. Protokolle und Monitoring kontrollieren,
  10. Ergebnis dokumentieren,
  11. weitere Untersuchung planen.

Auch ein Rollback ist eine Änderung und kann fehlschlagen.

31. Rollback oder Roll-forward wählen

Situation Rollback eher geeignet Roll-forward eher geeignet
vorherige Version bekannt funktionsfähig Ja Möglich
Konfiguration einfach reversibel Ja Möglich
Datenbankschema bereits verändert Riskant Häufig besser
neue Daten nicht rückwärtskompatibel Riskant Häufig besser
kritische Sicherheitslücke würde wieder geöffnet Eher ungeeignet Besser
Fehlerkorrektur ist klein und geprüft Möglich Häufig besser
vorheriger Zustand nicht eindeutig Riskant Möglicherweise besser
Rollback bereits getestet Ja Nicht zwingend
Zeit bis zur Folgekorrektur sehr lang Häufig besser Eher ungeeignet
Produktionsauswirkung steigt schnell schneller sicherer Weg entscheidend schneller sicherer Weg entscheidend

Ein Rollback darf keine bekannte Sicherheitslücke oder Dateninkonsistenz unbewertet wieder einführen.

32. Rollback einfacher Konfigurationsdateien

Eine Konfigurationsdatei darf nur dann direkt zurückkopiert werden, wenn:

Windows-Beispiel

[CHANGE][PRIV] Copy-Item "<Sicherungsdatei>" "<Konfigurationsdatei>" -Force

Linux-Beispiel

[CHANGE][PRIV] sudo cp --preserve=all -- "<Sicherungsdatei>" "<Konfigurationsdatei>"

macOS-Beispiel

[CHANGE][PRIV] sudo cp -p "<Sicherungsdatei>" "<Konfigurationsdatei>"

Diese Befehle sind keine universelle Rollbacklösung. Datenbanken, Verzeichnisdienste, Cluster, Containerplattformen und komplexe Anwendungen benötigen die vom Hersteller vorgesehene Wiederherstellungsmethode.

Nach dem Zurückkopieren müssen mindestens geprüft werden:

33. Kommunikation während der Umsetzung

Zeitpunkt Information
Vor Beginn Umfang, erwartete Auswirkung und Zeitraum
Zu Beginn Änderung wurde gestartet
Währenddessen relevante Abweichungen oder Verzögerungen
Bei Abbruch Grund und eingeleitete Rückfallmaßnahme
Nach Erfolg Funktion wiederhergestellt und Beobachtung läuft
Nach Rollback vorheriger Zustand wiederhergestellt
Nach Abschluss Ergebnis, offene Punkte und Präventionsmaßnahmen

Technische Kommunikation sollte sachlich sein und zwischen folgenden Zuständen unterscheiden:

34. Vollständiges Praxisbeispiel

Störung

Ein Backend liefert HTTP 503, weil die Anwendung einen falschen Datenbank-Hostnamen verwendet.

Bestätigte Ursache

Die neue Konfigurationsdatei enthält db-prdo.example statt db-prod.example.

Geplante Lösung

Rückfallplan

Erfolgskriterien

Abbruchkriterien

Ablauf

Schritt Maßnahme
1 Ausgangszustand und Protokolle sichern
2 aktuelle Konfiguration sichern und Prüfsumme bilden
3 korrigierte Datei in Testumgebung validieren
4 ein Backend aus der Rotation nehmen
5 Konfiguration auf diesem Backend ändern
6 Konfigurationsprüfung ausführen
7 Dienst kontrolliert neu laden oder starten
8 Listener und Protokolle prüfen
9 Datenbankfunktion prüfen
10 HTTP- und Anmeldetest durchführen
11 Backend mit Kontrollgruppe vergleichen
12 Backend wieder in Rotation nehmen
13 Monitoring beobachten
14 Änderung schrittweise auf weitere Instanzen ausrollen

35. Verifikationsprotokoll

Feld Vor Änderung Nach Änderung Nach Beobachtung
Zeitpunkt
Dienststatus
Prozess-ID
Listener
Ziel-IP
HTTP-Status
Antwortzeit
Authentifizierung
Benutzerfunktion
Datenbankverbindung
Fehler im Protokoll
Monitoringstatus
Fehlerrate
Nebenwirkungen

36. Änderungs- und Rollbackprotokoll

Feld Eintrag
Ticket- oder Change-Nummer
bestätigte Ursache
umgesetzte Änderung
Beginn
Ende
ausführende Person
betroffene Systeme
Sicherungsdatei oder Backup
Prüfsumme
Konfigurationsprüfung Bestanden / Nicht bestanden
Dienstneustart erforderlich Ja / Nein
Erfolgskriterien erreicht Ja / Nein / Teilweise
Abbruchkriterium erreicht Ja / Nein
Rollback durchgeführt Ja / Nein
Rollback-Ergebnis
Benutzerfunktion geprüft Ja / Nein
Regressionstests durchgeführt
Beobachtungsdauer
neue Fehler
verbleibende Risiken
offene Maßnahmen

37. Häufige Fehler bei der Lösungsumsetzung

Fehler Folge Besseres Vorgehen
Keine Sicherung Ausgangszustand kann nicht wiederhergestellt werden Konfiguration oder Backup vorher sichern
Backup mit Rollback verwechselt Wiederherstellung ist nicht geplant vollständigen Rückfallablauf dokumentieren
Mehrere Änderungen gleichzeitig Wirkung nicht zuordenbar kleine einzelne Änderungen
Sofortiger vollständiger Rollout großer möglicher Ausfall Canary oder stufenweiser Rollout
Nur Dienststatus geprüft Benutzerfunktion kann weiterhin gestört sein Ende-zu-Ende-Test durchführen
Nur positiver Test Sicherheitskontrolle kann unbemerkt fehlen negativen Test ergänzen
Keine Abbruchkriterien zu lange an fehlerhafter Änderung festgehalten Grenzwerte vorher definieren
Rollback erst im Fehlerfall geplant zusätzliche Ausfallzeit Rollback vor Beginn vorbereiten
Snapshot als einziges Backup Wiederherstellung möglicherweise ungeeignet anwendungsgerechtes Backup verwenden
Neustart als Standardlösung unnötige Unterbrechung und Informationsverlust kleinste geeignete Maßnahme wählen
Monitoring sofort beendet sporadischer Fehler bleibt unentdeckt angemessene Beobachtungsdauer
Workaround als dauerhafte Lösung behandelt Grundursache bleibt bestehen Folgeaufgabe mit Verantwortlichkeit
Sicherheitsupdate zurückgenommen bekannte Schwachstelle erneut aktiv Sicherheitsrisiko bewerten und Roll-forward prüfen
Dokumentation erst später erstellt genaue Schritte und Zeiten gehen verloren während der Änderung dokumentieren

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes ist die bestätigte Ursache durch eine kontrollierte und dokumentierte Änderung behandelt.

Die Lösung gilt erst als erfolgreich, wenn:

Nächste Seite:
1.9 Störung dokumentieren, abschließen und Wiederholung verhindern

Offizielle Hersteller-, Standard- und Projektdokumentation

1.9 Störung dokumentieren, abschließen und Wiederholung verhindern

Eine Störung ist nicht allein deshalb abgeschlossen, weil die betroffene Funktion wieder verfügbar ist.

Ein vollständiger Abschluss beantwortet zusätzlich:

Dabei gilt:

Eine gute Störungsdokumentation ermöglicht einer anderen Person, den Ablauf, die Ursache, die Prüfungen und die Lösung ohne mündliche Zusatzinformationen nachzuvollziehen.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

2. Wiederhergestellt, gelöst und abgeschlossen unterscheiden

Status Bedeutung
Erkannt Störung wurde registriert
In Analyse Ursache wird untersucht
Workaround aktiv Funktion ist über einen vorläufigen Umweg verfügbar
Wiederhergestellt ursprüngliche Funktion ist wieder verfügbar
Unter Beobachtung Funktion läuft, Stabilität wird überwacht
Technisch gelöst bestätigte technische Ursache wurde beseitigt
Dauerhaft gelöst zusätzlich wurden erforderliche Präventionsmaßnahmen umgesetzt
Abgeschlossen Dokumentation, Übergabe und offene Maßnahmen sind vollständig
Wiedereröffnet Fehler trat erneut auf oder Abschlusskriterien waren nicht erfüllt

Ein Ticket sollte nicht als „dauerhaft gelöst“ bezeichnet werden, wenn lediglich ein Workaround aktiv ist.

3. Incident, Problem und Änderung unterscheiden

Element Hauptziel Beispiel
Störung oder Incident Betrieb schnell wiederherstellen Webanwendung wieder erreichbar machen
Problem oder Ursachenanalyse Grundursache und Wiederholungsrisiko untersuchen Ursache des wiederkehrenden Ausfalls bestimmen
Änderung oder Change kontrollierte technische Anpassung durchführen Konfigurationsvalidierung einführen
Wissenseintrag Wiederverwendbare Lösung dokumentieren Fehlerbild und Diagnosebefehle dokumentieren
Präventionsaufgabe Wiederholung oder Auswirkung verhindern Monitoring um Ende-zu-Ende-Test ergänzen

Ein einzelner Vorfall kann mehrere verknüpfte Einträge benötigen.

4. Abschlusskriterien festlegen

Eine Störung kann abgeschlossen werden, wenn mindestens folgende Punkte geklärt sind:

5. Abschlussentscheidung

Frage Ja Nein
Funktioniert die ursprüngliche Benutzeraktion?
Ist der technische Systemzustand stabil?
Sind Abhängigkeiten geprüft?
Sind negative Sicherheitstests bestanden?
Sind relevante Regressionstests bestanden?
Ist das Monitoring unauffällig?
Sind Protokolle nach der Lösung geprüft?
Ist die Ursache ausreichend dokumentiert?
Ist klar, ob es sich um Workaround oder Lösung handelt?
Sind offene Aufgaben zugewiesen?
Sind verbleibende Risiken dokumentiert?
Sind betroffene Personen informiert?

Wenn wesentliche Punkte mit „Nein“ beantwortet werden, sollte das Ticket nicht ohne Begründung endgültig geschlossen werden.

6. Inhalt einer vollständigen Störungsdokumentation

Abschnitt Inhalt
Kurzbeschreibung Was war sichtbar gestört?
Auswirkung Wer oder was war betroffen?
Beginn Erster bekannter Fehlerzeitpunkt
Erkennung Wie und wann wurde die Störung erkannt?
Wiederherstellung Wann funktionierte der Dienst wieder?
Abschluss Wann wurde die dauerhafte Lösung bestätigt?
Systeme betroffene Clients, Server, Netze und Dienste
Symptom Fehlermeldung und beobachtetes Verhalten
Fehlerumfang betroffene und nicht betroffene Bereiche
Zeitachse wichtige Ereignisse und Maßnahmen
Ursache bestätigte technische Ursache
Auslöser Ereignis, das den Fehler aktivierte
Begünstigende Faktoren Bedingungen, die Auswirkung oder Dauer verstärkten
Erkennungslücken Warum wurde der Fehler nicht früher erkannt?
Diagnose wichtige Befehle, Ausgaben und Tests
Wiederherstellung Sofortmaßnahme oder Workaround
Dauerhafte Lösung Beseitigung der Grundursache
Verifikation technische und fachliche Funktionstests
Rollback vorbereitet, durchgeführt oder nicht erforderlich
Offene Risiken verbleibende technische oder organisatorische Risiken
Folgeaufgaben Präventions-, Monitoring- und Dokumentationsaufgaben
Verantwortliche Zuständigkeit für jede offene Aufgabe

7. Kurzbeschreibung richtig formulieren

Ungeeignet

Server war kaputt und wurde repariert.

Besser

Am 30.07.2026 konnten Clients aus VLAN 30 zwischen 14:35 und 15:42 Uhr keine HTTPS-Verbindung zu server.example aufbauen. Ursache war eine fehlerhafte Firewall-ACL, die TCP 443 aus VLAN 30 blockierte. Nach Korrektur der ACL waren Porttest, Anmeldung und Monitoring erfolgreich.

Eine gute Kurzbeschreibung enthält:

8. Auswirkung dokumentieren

Die Auswirkung sollte möglichst konkret beschrieben werden.

Bereich Zu dokumentierende Angaben
Benutzer Anzahl oder betroffene Gruppen
Standorte Gebäude, Niederlassungen oder Netze
Systeme Clients, Server, Anwendungen
Funktionen Anmeldung, Dateiablage, E-Mail, Produktion
Dauer Beginn bis Wiederherstellung
Daten Verlust, Verzögerung oder Inkonsistenz
Sicherheit mögliche unautorisierte Zugriffe oder Kontrollverlust
Geschäft ausgefallene Prozesse oder Verzögerungen
Externe Parteien Kunden, Lieferanten oder Provider
Workaround verfügbar, eingeschränkt oder nicht vorhanden

Wenn keine genaue Anzahl verfügbar ist, sollte dies ausdrücklich vermerkt und nicht frei geschätzt werden.

9. Wichtige Zeitpunkte dokumentieren

Zeitpunkt Bedeutung
Letzter funktionierender Zustand Funktion wurde zuletzt erfolgreich verwendet
Tatsächlicher Fehlerbeginn soweit technisch bestimmbar
Erste Beobachtung Fehler wurde erstmals bemerkt
Erkennung Monitoring oder Support erkannte die Störung
Meldung Ticket wurde erstellt
Bestätigung Störung wurde technisch nachvollzogen
Eskalation weitere Stelle wurde beteiligt
Eindämmung Auswirkung wurde begrenzt
Wiederherstellung Benutzerfunktion war wieder verfügbar
Dauerhafte Lösung Grundursache wurde behandelt
Ende der Beobachtung Stabilität wurde ausreichend bestätigt
Abschluss Ticket wurde geschlossen

Alle Uhrzeiten sollten dieselbe Zeitzone verwenden oder eindeutig als lokale Zeit beziehungsweise UTC gekennzeichnet sein.

10. Zeitkennzahlen berechnen

Kennzahl Berechnung Bedeutung
Erkennungszeit Erkennung minus Fehlerbeginn Wie lange blieb der Fehler unentdeckt?
Reaktionszeit Beginn der Bearbeitung minus Erkennung Wie schnell begann die Reaktion?
Eindämmungszeit Eindämmung minus Erkennung Wie schnell wurde die Auswirkung begrenzt?
Wiederherstellungszeit Wiederherstellung minus Fehlerbeginn Wie lange war die Funktion beeinträchtigt?
Lösungszeit dauerhafte Lösung minus Fehlerbeginn Wie lange bis zur vollständigen Korrektur?

Abkürzungen wie MTTR werden in verschiedenen Organisationen unterschiedlich verwendet, beispielsweise für „Mean Time to Repair“, „Restore“, „Resolve“ oder „Recovery“. Deshalb sollte die konkret gemeinte Kennzahl ausgeschrieben und definiert werden.

11. Zeitachse erstellen

Zeit Quelle Ereignis Auswirkung oder Erkenntnis
14:31 Deployment neue Konfiguration verteilt möglicher Auslöser
14:35 Monitoring HTTP-Fehlerrate steigt erster technischer Hinweis
14:38 Benutzer Anmeldung schlägt fehl Benutzerwirkung bestätigt
14:42 Support Ticket erstellt Bearbeitung beginnt
14:48 Diagnose Backend 2 liefert HTTP 503 Fehler eingegrenzt
14:55 Anwendung falscher Datenbank-Hostname gefunden unmittelbare Ursache
15:05 Change Backend 2 aus Rotation genommen Auswirkung eingedämmt
15:17 Change Konfiguration korrigiert technische Lösung
15:22 Test Anmeldung erfolgreich Funktion wiederhergestellt
15:52 Monitoring keine neuen Fehler Stabilität bestätigt
16:00 Abschluss Folgeaufgaben erstellt Incident beendet

Wichtig

Die Zeitachse sollte Fakten enthalten. Vermutungen werden als solche gekennzeichnet.

12. Fakten und Bewertungen trennen

Fakt

Um 14:31 Uhr wurde Deployment 2026.07.30-3 ausgeführt.

Bewertung

Das Deployment war der Auslöser der Störung.

Fakt

Backend 2 protokollierte um 14:35 Uhr einen Fehler bei der Namensauflösung des Datenbankservers.

Bewertung

Der falsche Datenbank-Hostname verursachte die HTTP-503-Antworten.

Beide Arten von Informationen sind wichtig, müssen aber voneinander unterscheidbar bleiben.

13. Technische Diagnose dokumentieren

Nicht jede vollständige Konsolenausgabe muss direkt in den Tickettext kopiert werden. Das Ticket sollte jedoch die relevanten Befehle, Ergebnisse und Verweise enthalten.

Feld Beispiel
Prüfzeitpunkt 2026-07-30 14:48 CEST
Quellsystem PC-030
Zielsystem server.example
Befehl Test-NetConnection server.example -Port 443
Ergebnis TcpTestSucceeded: False
Vergleich Test aus VLAN 40 erfolgreich
Interpretation Fehler ist vom Quellnetz abhängig
Ausgabedatei INC-2026-0042-TCP-Test-PC030.txt
Hypothese H1 – ACL blockiert VLAN 30
Bewertung stark gestützt

14. Befehle und Ausgaben nachvollziehbar zuordnen

Geeignete Dateinamen

INC-2026-0042-PC030-TCP-Test-20260730-144800.txt

INC-2026-0042-FW01-Auditlog-20260730-145000.txt

INC-2026-0042-SRVAPP02-Application.evtx

Ein sinnvoller Dateiname enthält:

15. Abschlusszustand unter Windows dokumentieren

Zeitpunkt

[RO] Get-Date -Format o

Dienststatus

[RO] Get-Service -Name <Dienstname>

Prozess-ID

[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, ProcessId

Listener

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Funktionstest

[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed

Neue Systemfehler

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message

Neue Anwendungsfehler

[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message

16. Abschlusszustand unter Linux dokumentieren

Zeitpunkt

[RO] date --iso-8601=seconds

Dienststatus

[RO] systemctl status <Dienstname>.service --no-pager

Fehlgeschlagene Dienste

[RO] systemctl --failed

Listener

[RO][PRIV] ss -lntp | grep ":<Port>"

Funktionstest

[TEST] nc -vz -w 3 <Servername> <Port>

Neue Dienstprotokolle

[RO] journalctl -u <Dienstname>.service --since "30 minutes ago" --no-pager

Neue Systemfehler

[RO] journalctl --since "30 minutes ago" -p err --no-pager

17. Abschlusszustand unter macOS dokumentieren

Zeitpunkt

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Systemdienst

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienst

[RO] launchctl print gui/$(id -u)/<Dienstlabel>

Listener

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

Funktionstest

[TEST] nc -vz -w 3 <Servername> <Port>

Neue Prozessfehler

[RO] log show --last 30m --predicate 'process == "<Prozessname>" AND (messageType == error OR messageType == fault)' --style compact

18. Plattformübergreifenden HTTP-Abschlusstest durchführen

Windows

[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Linux und macOS

[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Der Test dokumentiert unter anderem:

Die Werte müssen mit bekannten Normalwerten, Monitoring-Baselines oder vereinbarten Anforderungen verglichen werden.

19. Prüfsummen für Abschlussunterlagen erstellen

Die Prüfsummen sollten erst erstellt werden, nachdem keine weiteren Dateien mehr zur Sammlung hinzugefügt werden.

Windows

[FILE] Get-ChildItem "<Diagnoseordner>" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "<Diagnoseordner>-SHA256.csv" -NoTypeInformation -Encoding UTF8

Linux

[FILE] (cd "<Diagnoseordner>" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "<Diagnoseordner>-SHA256SUMS.txt"

macOS

[FILE] find "<Diagnoseordner>" -type f -exec shasum -a 256 {} \; > "<Diagnoseordner>-SHA256SUMS.txt"

Eine Prüfsumme dokumentiert die Integrität der Datei ab dem Zeitpunkt ihrer Berechnung. Sie beweist nicht automatisch Herkunft oder Authentizität.

20. Abschlussunterlagen schützen

Diagnose- und Abschlussunterlagen können enthalten:

Deshalb muss geklärt sein:

21. Wann eine ausführliche Nachanalyse sinnvoll ist

Eine ausführliche Nachanalyse oder ein Postmortem ist besonders sinnvoll bei:

Die Kriterien sollten möglichst bereits vor einer Störung organisatorisch festgelegt werden.

22. Sachliche und schuldfreie Nachanalyse

Eine Nachanalyse soll Systeme und Prozesse verbessern, nicht einzelne Personen beschuldigen.

Ungeeignet

Der Administrator war unvorsichtig und hat den falschen Wert eingetragen.

Besser

Die Verwaltungsoberfläche akzeptierte den ungültigen Wert ohne technische Validierung. Die Änderung wurde anschließend ohne Staging- oder Canary-Prüfung auf alle Instanzen verteilt.

Weiterführende Fragen

23. Regeln für eine sachliche Formulierung

Vermeiden Besser
Schuldzuweisung technischen Ablauf beschreiben
persönliche Bewertung beobachtbare Fakten verwenden
„offensichtlich“ konkrete Belege nennen
„immer“ oder „nie“ Zeitraum und Umfang nennen
„Server war kaputt“ betroffene Funktion beschreiben
„Netzwerkproblem“ Protokoll, Quelle und Ziel nennen
„Benutzerfehler“ konkrete Eingabe oder Prozesslücke nennen
„Problem gelöst“ getestete Funktion und Ergebnis nennen
„Monitoring versagte“ fehlende Prüfung oder Alarmbedingung nennen

24. Aufbau einer Nachanalyse

Abschnitt Inhalt
Titel eindeutiger Name und Ticketnummer
Datum Datum der Störung und Nachanalyse
Status Entwurf, geprüft oder abgeschlossen
Beteiligte Systeme technische Komponenten
Zusammenfassung kurze sachliche Beschreibung
Auswirkung Benutzer, Dienste, Dauer und Daten
Erkennung wie und wann die Störung erkannt wurde
Zeitachse wichtige Ereignisse
Ursache technische Ursache und Mechanismus
Auslöser aktivierendes Ereignis
Begünstigende Faktoren Bedingungen, die Wirkung verstärkten
Wiederherstellung Maßnahmen zur Betriebswiederherstellung
Lösung dauerhafte Korrektur
Was funktionierte gut? hilfreiche Abläufe und Werkzeuge
Was funktionierte nicht? technische oder organisatorische Lücken
Wo bestand Glück? Faktoren, die größeren Schaden zufällig verhinderten
Folgeaufgaben konkrete Verbesserungsmaßnahmen
Belege Protokolle, Tickets, Ausgaben und Changes

25. „Was funktionierte gut?“ dokumentieren

Beispiele:

Diese Punkte zeigen, welche bestehenden Prozesse beibehalten oder ausgebaut werden sollten.

26. „Was funktionierte nicht?“ dokumentieren

Beispiele:

Die Beschreibung sollte konkret genug sein, um daraus eine überprüfbare Aufgabe abzuleiten.

27. „Wo bestand Glück?“ dokumentieren

Dieser Abschnitt beschreibt Faktoren, die einen größeren Schaden verhindert haben, obwohl dafür keine verlässliche Schutzmaßnahme existierte.

Beispiele:

Glück ist keine dauerhafte Schutzmaßnahme. Daraus sollten Verbesserungsaufgaben entstehen.

28. Konkrete Folgeaufgaben erstellen

Eine Nachanalyse ohne konkrete und nachverfolgte Maßnahmen verbessert das System nicht.

Jede Folgeaufgabe benötigt:

Ungeeignet

Monitoring verbessern.

Besser

Bis zum 14.08.2026 wird für die Webanwendung ein Ende-zu-Ende-Check eingerichtet, der alle fünf Minuten eine Testanmeldung ausführt und bei drei aufeinanderfolgenden Fehlern alarmiert. Verantwortlich: Betriebsteam. Nachweis: erfolgreich ausgelöster Testalarm.

Die konkreten Zeitintervalle und Grenzwerte müssen aus den Anforderungen der jeweiligen Umgebung abgeleitet werden.

29. Folgeaufgaben kategorisieren

Kategorie Ziel Beispiel
Verhindern Fehlerentstehung verhindern Konfigurationsvalidierung
Begrenzen Auswirkung reduzieren Canary oder Rate Limit
Erkennen Fehler früher feststellen Ende-zu-Ende-Monitoring
Diagnostizieren Ursache schneller finden strukturierte Protokolle
Wiederherstellen Reparatur beschleunigen getesteter Rückfallplan
Dokumentieren Wissen verfügbar machen Runbook aktualisieren
Automatisieren manuelle Fehler reduzieren geprüfte Deployment-Pipeline
Schulen Verfahren bekannt machen Übung des Notfallablaufs
Entfernen unnötige Abhängigkeit beseitigen Single Point of Failure abbauen

30. Wirksamkeit von Maßnahmen priorisieren

Stärke Maßnahmenart Beispiel
1 Fehler technisch unmöglich machen ungültige Konfiguration wird abgelehnt
2 Änderung automatisch prüfen automatischer Syntax- und Funktionstest
3 Auswirkung begrenzen Canary, Redundanz, automatische Rücknahme
4 Fehler schnell erkennen Ende-zu-Ende-Monitoring
5 Wiederherstellung beschleunigen getestetes Runbook
6 Warnhinweis oder Checkliste manueller Prüfschritt
7 Erinnerung an mehr Aufmerksamkeit „Beim nächsten Mal besser aufpassen“

Technische Schutzmaßnahmen und automatisierte Prüfungen sind normalerweise zuverlässiger als eine reine Aufforderung zu größerer Aufmerksamkeit.

31. Folgeaufgaben richtig formulieren

Feld Beispiel
Aufgabe JSON-Konfiguration vor Deployment validieren
Begründung ungültiger Hostname verursachte Ausfall
Verantwortlich Plattformteam
Priorität Hoch
Zieltermin 14.08.2026
messbarer Endzustand Pipeline lehnt ungültiges Schema ab
Prüfmethode Testdeployment mit absichtlich ungültigem Wert
Ticket-ID TASK-2026-0182
Status Offen

32. Maßnahmenstatus verwenden

Status Bedeutung
Offen Aufgabe wurde erstellt
Geplant Umsetzung ist terminiert
In Bearbeitung Umsetzung läuft
Blockiert Abhängigkeit verhindert Umsetzung
Umgesetzt technische Änderung ist erfolgt
In Prüfung Wirksamkeit wird verifiziert
Abgeschlossen messbarer Endzustand ist bestätigt
Verworfen Aufgabe wurde begründet abgelehnt
Risiko akzeptiert Risiko wurde durch zuständige Stelle akzeptiert

„Umgesetzt“ und „wirksam bestätigt“ sollten unterschieden werden.

33. Monitoring aus der Störung verbessern

Nach einer Störung sollte geprüft werden:

Guter Alarm

Ein guter Alarm ist:

34. Benutzerwirkung statt nur Komponentenstatus überwachen

Komponentenprüfung Zusätzliche Ende-zu-Ende-Prüfung
Server antwortet auf Ping Benutzer kann Anwendung öffnen
TCP 443 ist erreichbar HTTPS-Anmeldung funktioniert
Dienststatus ist „Running“ konkrete API-Anfrage funktioniert
Datenbankprozess läuft Anwendung kann Daten lesen
Dateiserver ist erreichbar Testdatei kann gelesen werden
Drucker antwortet im Netz Testseite wird tatsächlich gedruckt
Backupjob startet Sicherung wird erfolgreich abgeschlossen und geprüft
DNS-Dienst läuft vorgesehener Name wird korrekt aufgelöst

35. Dokumentation und Runbooks aktualisieren

Nach der Störung sollten geprüft werden:

Ein guter Wissenseintrag enthält

36. Wiederkehrende Störungen erkennen

Einzelne Tickets sollten nach gemeinsamen Merkmalen ausgewertet werden.

Mögliche Suchmerkmale

Bei wiederkehrenden Störungen sollte ein übergeordneter Problem- oder Ursachenanalyse-Eintrag erstellt und mit den einzelnen Tickets verknüpft werden.

37. Verbleibende Risiken dokumentieren

Nicht jede Verbesserung kann sofort umgesetzt werden.

Risiko Wahrscheinlichkeit Auswirkung Zwischenmaßnahme Verantwortlich Termin
Fehler kann bis zur Pipeline-Anpassung erneut auftreten Mittel Hoch Änderungen manuell prüfen Plattformteam 14.08.2026
Monitoring erkennt Teilfehler nicht Mittel Mittel manuelle Kontrolle Betriebsteam 07.08.2026
Rollback noch nicht automatisiert Niedrig Hoch dokumentiertes manuelles Verfahren Entwicklung 21.08.2026

Ein Risiko darf nur durch die dafür zuständige Stelle akzeptiert werden.

38. Sicherheitsvorfälle gesondert behandeln

Bei einem möglichen oder bestätigten Sicherheitsvorfall darf der normale technische Ticketabschluss nicht allein entscheiden.

Zusätzlich können erforderlich sein:

Der technische Dienst kann bereits wiederhergestellt sein, während der Sicherheitsvorfall noch offen bleibt.

39. Abschlusskommunikation erstellen

Eine Abschlussmeldung sollte enthalten:

Beispiel

Die Störung beim Zugriff auf die Webanwendung ist seit 15:42 Uhr behoben. Betroffen waren Clients aus VLAN 30. Ursache war eine fehlerhafte Firewall-ACL für TCP 443. Die Regel wurde korrigiert und durch Port-, Anmelde- und Monitoringtests bestätigt. Weitere Einschränkungen sind derzeit nicht bekannt. Als Folgemaßnahme wird ein automatischer Verbindungstest aus jedem Client-VLAN eingerichtet. Referenz: INC-2026-0042.

40. Vollständiges Abschlussbeispiel

Zusammenfassung

Am 30.07.2026 konnten Clients aus VLAN 30 die Anwendung server.example über HTTPS nicht erreichen.

Auswirkung

Zeitraum

Ursache

Eine Firewall-ACL blockierte TCP 443 aus VLAN 30.

Auslöser

Die ACL wurde bei einer Netzwerkänderung um 14:31 Uhr unvollständig übernommen.

Begünstigender Faktor

Es existierte kein automatischer Verbindungstest aus jedem Client-VLAN.

Diagnose

Lösung

Die freigegebene ACL wurde korrigiert.

Verifikation

Folgeaufgaben

Aufgabe Verantwortlich Priorität Termin
Verbindungstest aus jedem Client-VLAN einrichten Monitoringteam Hoch 14.08.2026
ACL-Änderungsvorlage ergänzen Netzwerkteam Mittel 07.08.2026
Rückfallverfahren dokumentieren Netzwerkteam Mittel 07.08.2026
Netzplandokumentation aktualisieren Systemintegration Mittel 05.08.2026

41. Vorlage für eine vollständige Störungsdokumentation

Ticketnummer:
<Ticketnummer>

Titel:
<Kurze eindeutige Störungsbeschreibung>

Status:
Erkannt / In Analyse / Workaround / Wiederhergestellt / Beobachtung / Gelöst / Abgeschlossen

Zusammenfassung:
<Was ist passiert?>

Auswirkung:
<Benutzer, Systeme, Standorte, Funktionen und Daten>

Beginn der Störung:
<Datum, Uhrzeit und Zeitzone>

Erkennung:
<Datum, Uhrzeit, Quelle und Zeitzone>

Wiederherstellung:
<Datum, Uhrzeit und Zeitzone>

Ende der Beobachtung:
<Datum, Uhrzeit und Zeitzone>

Betroffene Systeme:
<Liste>

Nicht betroffene Vergleichssysteme:
<Liste>

Fehlermeldung:
<vollständiger Fehlertext>

Direkte technische Ursache:
<Ursache>

Technischer Mechanismus:
<Wie erzeugte die Ursache das Symptom?>

Auslöser:
<Ereignis oder Änderung>

Grundursache:
<systemischer Grund>

Begünstigende Faktoren:
<Liste>

Erkennungslücken:
<Liste>

Zeitachse:
<chronologische Ereignisse>

Diagnosebefehle und Ergebnisse:
<Befehle, Ausgaben und Verweise>

Sofortmaßnahme:
<Workaround oder Eindämmung>

Dauerhafte Lösung:
<umgesetzte Korrektur>

Rollback:
<vorbereitet, durchgeführt oder nicht erforderlich>

Verifikation:
<technische, fachliche, negative und Regressionstests>

Monitoring nach der Lösung:
<Messwerte und Beobachtungsdauer>

Verbleibende Risiken:
<Liste>

Folgeaufgaben:
<Ticket-ID, Verantwortliche, Priorität, Termin und Prüfmethode>

Abschlussfreigabe:
<zuständige Person oder Rolle>

42. Abschlusscheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes ist nicht nur die technische Funktion wiederhergestellt. Der gesamte Vorfall ist nachvollziehbar dokumentiert, offene Risiken sind bekannt und konkrete Verbesserungsmaßnahmen wurden zugewiesen.

Eine Störung sollte erst abgeschlossen werden, wenn:

Nächste Seite und Abschluss von Kapitel 1:
1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS

Offizielle Hersteller-, Behörden- und Projektdokumentation

1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS

1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS

Diese Seite fasst die wichtigsten Diagnosebefehle aus Kapitel 1 als plattformübergreifendes Nachschlagewerk zusammen.

Sie ist für die schnelle Fehlersuche gedacht. Die ausführliche Vorgehensweise, Einschränkungen und Interpretationen befinden sich auf den vorherigen Seiten.

Befehle nicht wahllos nacheinander ausführen. Zuerst Fehlerbild und Umfang bestimmen, flüchtige Informationen sichern und anschließend gezielt prüfen.

Die Bereiche ab Punkt 3 können über die jeweilige Überschrift auf- und zugeklappt werden.

1. Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

Auch [RO]-Befehle sind nicht vollständig spurlos. Sie starten Prozesse und können in Shell-Historien, Auditprotokollen oder Sicherheitslösungen erscheinen.

2. Platzhalter

Alle Angaben in spitzen Klammern müssen vor der Ausführung ersetzt werden.

Platzhalter Bedeutung
<Servername> Hostname oder FQDN des Zielservers
<IP-Adresse> IPv4- oder IPv6-Adresse
<Port> TCP- oder UDP-Port
<Dienstname> interner Dienstname
<Dienstlabel> launchd-Label unter macOS
<Prozessname> Name eines Prozesses
<PID> Prozess-ID
<Benutzername> Benutzerkonto
<Datei> vollständiger Dateipfad
<Pfad> Datei- oder Verzeichnispfad
<Zielpfad> freigegebener Speicherort
<Interface> Netzwerkschnittstelle
<DNS-Server-IP> Adresse des abzufragenden DNS-Servers
3. Plattformhinweise
Plattform Hinweise
Windows PowerShell möglichst mit normalen Benutzerrechten starten; erhöhte Rechte nur bei Bedarf
Linux Befehle unterscheiden sich nach Distribution, Init-System und installierten Paketen
macOS Viele Werkzeuge verwenden BSD-Syntax und unterscheiden sich von den Linux-Versionen
Alle Befehle mit Schreib-, Neustart- oder Aufzeichnungsfunktion vorher auf Auswirkungen prüfen

Lokale Hilfe anzeigen

Windows PowerShell Linux macOS
[RO] Get-Help <Befehl> -Full [RO] man <Befehl> [RO] man <Befehl>
[RO] Get-Command <Befehl> -Syntax [RO] <Befehl> --help [RO] <Befehl> -h oder man <Befehl>
4. Schneller Diagnoseablauf
Reihenfolge Prüfung Ziel
1 Uhrzeit und Zeitzone Protokolle korrekt vergleichen
2 Fehler exakt reproduzieren tatsächliches Symptom bestätigen
3 betroffene und funktionierende Systeme vergleichen Fehlerumfang eingrenzen
4 IP-Konfiguration prüfen lokale Netzwerkkonfiguration bestätigen
5 DNS prüfen Name und Zieladresse bestätigen
6 Routing und Gateway prüfen Netzwerkpfad bestätigen
7 Zielport prüfen Transportverbindung testen
8 Protokoll oder Anwendung prüfen HTTP, TLS oder Anwendungsebene
9 Dienst und Listener prüfen serverseitigen Zustand bestätigen
10 Protokolle prüfen technische Fehler und Zeitpunkt finden
11 Ressourcen prüfen CPU, RAM, Datenträger und I/O
12 letzte Änderungen prüfen Updates, Deployments und Konfiguration
13 Hypothesen mit Gegenprobe testen Ursache bestätigen oder widerlegen
14 Ausgangszustand sichern sichere Änderung und Rückfall ermöglichen
15 Lösung umsetzen und Ende-zu-Ende prüfen Funktion dauerhaft bestätigen
5. Datum, Uhrzeit und Zeitzone
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

Interpretation

Beobachtung Mögliche Bedeutung
Systemzeit weicht ab NTP-, Domänen-, Netzwerk- oder Konfigurationsproblem
Zeitzonen unterscheiden sich Ereignisse vor dem Vergleich umrechnen
Zeitquelle nicht erreichbar Firewall, DNS, Routing oder Zeitdienst prüfen
Kerberos- oder Zertifikatsfehler Systemzeit und Zeitzone zuerst prüfen
6. Hostname, Betriebssystem und Hardware
Aufgabe Windows Linux macOS
Hostname [RO] hostname [RO] hostname [RO] hostname
Systemübersicht [RO] Get-ComputerInfo [RO] hostnamectl [RO] system_profiler SPSoftwareDataType SPHardwareDataType
Betriebssystem [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber [RO] cat /etc/os-release [RO] sw_vers
Kernel und Architektur [RO] systeminfo [RO] uname -a [RO] uname -a
Prozessor [RO] Get-CimInstance Win32_Processor [RO] lscpu [RO] sysctl -n machdep.cpu.brand_string
Hardwaremodell [RO] Get-CimInstance Win32_ComputerSystem [RO][PRIV] dmidecode -t system [RO] system_profiler SPHardwareDataType
Seriennummer [RO] Get-CimInstance Win32_BIOS | Select-Object SerialNumber [RO][PRIV] dmidecode -s system-serial-number [RO] system_profiler SPHardwareDataType

dmidecode ist nicht auf jeder Linux-Installation vorhanden und benötigt üblicherweise Root-Rechte.

7. Systemstart und Betriebsdauer
Aufgabe Windows Linux macOS
Letzter Start [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime [RO] uptime -s [RO] sysctl -n kern.boottime
Alternative [RO] systeminfo [RO] who -b [RO] last reboot
Betriebsdauer [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Neustartverlauf Ereignisanzeige beziehungsweise Systemprotokoll [RO] last reboot [RO] last reboot
Aktueller Boot Ereignisanzeige [RO] journalctl -b Unified Log über Startzeit eingrenzen
Vorheriger Boot Ereignisanzeige [RO] journalctl -b -1 [RO] last reboot
8. Benutzeridentität und Sitzungen
Aufgabe Windows Linux macOS
Aktueller Benutzer [RO] whoami [RO] whoami [RO] whoami
Benutzer-ID und Gruppen [RO][SENSITIV] whoami /all [RO] id [RO] id
Bestimmter Benutzer lokale oder Domänenverwaltung verwenden [RO] id <Benutzername> [RO] id <Benutzername>
Angemeldete Benutzer [RO] quser [RO] who -a [RO] who
Sitzungen und Aktivität [RO] query user [RO] w [RO] w
Lokale Benutzer [RO] Get-LocalUser [RO] getent passwd [RO] dscl . -list /Users
Lokale Gruppen [RO] Get-LocalGroup [RO] getent group [RO] dscl . -list /Groups

Ausgaben können Benutzernamen, SIDs, Gruppen und sicherheitsrelevante Informationen enthalten.

9. Prozesse
Aufgabe Windows Linux macOS
Prozessübersicht [RO] Get-Process [RO][SENSITIV] ps auxww [RO][SENSITIV] ps auxww
PID, Elternprozess und Befehlszeile [RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine [RO][SENSITIV] ps -ef --forest [RO][SENSITIV] ps -axo pid,ppid,user,lstart,state,%cpu,%mem,command
Einzelnen Prozess prüfen [RO] Get-Process -Id <PID> | Format-List * [RO] ps -p <PID> -o pid,ppid,user,lstart,stat,%cpu,%mem,command [RO] ps -p <PID> -o pid,ppid,user,lstart,state,%cpu,%mem,command
Nach Namen suchen [RO] Get-Process -Name <Prozessname> [RO] pgrep -a <Prozessname> [RO] pgrep -fl <Prozessname>
Höchste CPU-Nutzung [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 20 [RO] ps aux --sort=-%cpu | head -n 20 [RO] top -l 1 -o cpu
Höchste Speichernutzung [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 20 [RO] ps aux --sort=-%mem | head -n 20 [RO] top -l 1 -o mem
Offene Dateien eines Prozesses kein einheitlicher integrierter PowerShell-Befehl [RO][PRIV][SENSITIV] lsof -p <PID> [RO][PRIV][SENSITIV] lsof -p <PID>
10. Dienste
Aufgabe Windows Linux mit systemd macOS
Alle Dienste [RO] Get-Service [RO] systemctl list-units --type=service --all [RO] launchctl list
Bestimmten Dienst prüfen [RO] Get-Service -Name <Dienstname> [RO] systemctl status <Dienstname>.service --no-pager [RO][PRIV] launchctl print system/<Dienstlabel>
Benutzerdienst prüfen [RO] Get-Service -Name <Dienstname> [RO] systemctl --user status <Dienstname>.service [RO] launchctl print gui/$(id -u)/<Dienstlabel>
Fehlgeschlagene Dienste Status und Ereignisprotokoll prüfen [RO] systemctl --failed Prozess und Unified Log prüfen
Laufende Dienste [RO] Get-Service | Where-Object Status -eq "Running" [RO] systemctl list-units --type=service --state=running [RO] launchctl list
Dienstkonfiguration [RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" [RO] systemctl cat <Dienstname>.service [RO] plutil -p "<Pfad-zur-plist>"
Prozess-ID [RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object ProcessId [RO] systemctl show <Dienstname>.service -p MainPID [RO] launchctl print system/<Dienstlabel>
Startmodus [RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object StartMode [RO] systemctl is-enabled <Dienstname>.service Property-List mit plutil -p prüfen
Dienstkonto [RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object StartName [RO] systemctl show <Dienstname>.service -p User -p Group [RO] plutil -p "<Pfad-zur-plist>"
11. Dienstabhängigkeiten
Aufgabe Windows Linux mit systemd macOS
Benötigte Dienste [RO] Get-Service -Name <Dienstname> -RequiredServices [RO] systemctl list-dependencies <Dienstname>.service --all keine allgemeine Abhängigkeitsdarstellung
Abhängige Dienste [RO] Get-Service -Name <Dienstname> -DependentServices [RO] systemctl list-dependencies <Dienstname>.service --reverse --all anwendungsspezifisch prüfen
Reihenfolge und Anforderungen [RO] sc.exe qc <Dienstname> [RO] systemctl show <Dienstname>.service -p Requires -p Wants -p After -p Before Property-List und Dokumentation prüfen
Effektive Konfiguration [RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" [RO] systemctl cat <Dienstname>.service [RO] plutil -p "<Pfad-zur-plist>"
12. Arbeitsspeicher
Aufgabe Windows Linux macOS
Arbeitsspeicherübersicht [RO] Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize,FreePhysicalMemory [RO] free -h [RO] vm_stat
Prozessspeicher [RO] Get-Process | Sort-Object WorkingSet64 -Descending [RO] ps aux --sort=-%mem [RO] top -l 1 -o mem
Laufende Übersicht [RO] Get-Process oder Task-Manager [RO] top [RO] top

Bei Windows werden TotalVisibleMemorySize und FreePhysicalMemory in KiB ausgegeben.

13. Datenträger und Dateisysteme
Aufgabe Windows Linux macOS
Volumes [RO] Get-Volume [RO] lsblk -f [RO] diskutil list
Freier Speicher [RO] Get-PSDrive -PSProvider FileSystem [RO] df -hT [RO] df -h
Inode-Belegung nicht in dieser Unix-Form anwendbar [RO] df -ih [RO] df -ih
Mounts [RO] Get-Volume [RO] findmnt [RO] mount
Physische Datenträger [RO] Get-PhysicalDisk [RO] lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS [RO] diskutil list
Datenträgerinformationen [RO] Get-Disk [RO] lsblk -f [RO] diskutil info <Datenträger>
I/O-Messung Performance Monitor oder passende Counter [RO][TEST] iostat -xz 1 5 [RO][TEST] iostat -w 1 -c 5

iostat gehört unter Linux häufig zum Paket sysstat.

14. IP-Konfiguration
Aufgabe Windows Linux macOS
Vollständige IP-Konfiguration [RO] ipconfig /all [RO] ip -details address show [RO] ifconfig -a
PowerShell-Netzwerkübersicht [RO] Get-NetIPConfiguration Nicht zutreffend Nicht zutreffend
Interfacezustand [RO] Get-NetAdapter [RO] ip -details link show [RO] ifconfig -a
NetworkManager-Geräte Nicht zutreffend [RO] nmcli device status Nicht zutreffend
NetworkManager-Verbindungen Nicht zutreffend [RO][SENSITIV] nmcli connection show Nicht zutreffend
Hardwareports [RO] Get-NetAdapter [RO] ip link show [RO] networksetup -listallhardwareports
Netzwerkdienste Adapter über PowerShell NetworkManager oder systemd-networkd [RO] networksetup -listallnetworkservices
15. DHCP-Informationen am Client
Aufgabe Windows Linux macOS
DHCP-Server und Lease [RO] ipconfig /all abhängig vom Netzwerkmanager und DHCP-Client [RO] ipconfig getpacket <Interface>
NetworkManager-DHCP Nicht zutreffend [RO] nmcli device show <Interface> Nicht zutreffend
systemd-networkd Nicht zutreffend [RO] networkctl status <Interface> Nicht zutreffend
Interface-IP [RO] Get-NetIPAddress [RO] ip address show <Interface> [RO] ipconfig getifaddr <Interface>

DHCP-Lease-Dateien und Speicherorte unterscheiden sich nach Distribution und verwendetem Netzwerkdienst.

16. DNS-Konfiguration
Aufgabe Windows Linux macOS
DNS-Server [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO][SENSITIV] scutil --dns
Resolverdatei ipconfig /all verwenden [RO] cat /etc/resolv.conf [RO] cat /etc/resolv.conf
Suchdomänen [RO] ipconfig /all [RO] resolvectl status [RO][SENSITIV] scutil --dns
DNS-Cache [RO][SENSITIV] Get-DnsClientCache kein einheitlicher systemweiter Cache-Dump kein einheitlicher systemweiter Cache-Dump
Alternative Cacheanzeige [RO][SENSITIV] ipconfig /displaydns abhängig vom Resolver abhängig vom Resolver
17. DNS-Auflösung
Aufgabe Windows Linux macOS
Standardabfrage [TEST] Resolve-DnsName <Servername> [TEST] getent ahosts <Servername> [TEST] dscacheutil -q host -a name <Servername>
Abfrage mit dig dig nur wenn installiert [TEST] dig <Servername> [TEST] dig <Servername>
Kurze Ausgabe [TEST] Resolve-DnsName <Servername> | Select-Object Name,Type,IPAddress [TEST] dig +short <Servername> [TEST] dig +short <Servername>
Bestimmten DNS-Server abfragen [TEST] Resolve-DnsName <Servername> -Server <DNS-Server-IP> [TEST] dig @<DNS-Server-IP> <Servername> [TEST] dig @<DNS-Server-IP> <Servername>
nslookup [TEST] nslookup <Servername> [TEST] nslookup <Servername> [TEST] nslookup <Servername>
Reverse Lookup [TEST] Resolve-DnsName <IP-Adresse> [TEST] dig -x <IP-Adresse> [TEST] dig -x <IP-Adresse>

Interpretation

Ergebnis Mögliche Bedeutung
Name wird nicht aufgelöst DNS-Server, Clientkonfiguration, Zone oder Netzwerk
Falsche IP-Adresse falscher Eintrag, Cache, Hosts-Datei oder Split-DNS
Verschiedene IP-Adressen Load Balancing, DNS-Rotation oder unterschiedliche Resolver
Bestimmter DNS-Server antwortet korrekt Standardresolver oder Clientkonfiguration prüfen
IP funktioniert, Name nicht DNS priorisieren
18. Hosts-Datei anzeigen
Windows Linux macOS
[RO] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" [RO] cat /etc/hosts [RO] cat /etc/hosts

Die Hosts-Datei kann DNS-Ergebnisse lokal überschreiben.

19. Routing
Aufgabe Windows Linux macOS
Routingtabelle [RO] route print [RO] ip route show table all [RO] netstat -rn
PowerShell-Routen [RO] Get-NetRoute Nicht zutreffend Nicht zutreffend
IPv4-Routen [RO] Get-NetRoute -AddressFamily IPv4 [RO] ip -4 route show table all [RO] netstat -rn -f inet
IPv6-Routen [RO] Get-NetRoute -AddressFamily IPv6 [RO] ip -6 route show table all [RO] netstat -rn -f inet6
Route zu einem Ziel [RO] Test-NetConnection <IP-Adresse> -DiagnoseRouting -InformationLevel Detailed [RO] ip route get <IP-Adresse> [RO] route -n get <IP-Adresse>
Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
20. ARP- und Neighbor-Tabelle
Aufgabe Windows Linux macOS
ARP-Tabelle [RO] arp -a [RO] ip neigh show [RO] arp -an
PowerShell-Neighbor [RO] Get-NetNeighbor Nicht zutreffend Nicht zutreffend
Bestimmtes Interface [RO] Get-NetNeighbor -InterfaceAlias "<Interface>" [RO] ip neigh show dev <Interface> [RO] arp -an

Interpretation

Zustand Bedeutung
Reachable Nachbar wurde kürzlich bestätigt
Stale Eintrag vorhanden, aber nicht aktuell bestätigt
Incomplete oder Failed Adressauflösung fehlgeschlagen
unterschiedliche MAC-Adressen Redundanz, Proxy ARP, IP-Konflikt oder Änderung prüfen
21. Proxykonfiguration
Aufgabe Windows Linux macOS
WinHTTP-Proxy [RO] netsh winhttp show proxy Nicht zutreffend Nicht zutreffend
Umgebungsvariablen [RO][SENSITIV] Get-ChildItem Env: | Where-Object Name -Match "proxy" [RO][SENSITIV] env | grep -i proxy [RO][SENSITIV] env | grep -i proxy
Systemproxy Internetoptionen und Richtlinien prüfen Desktop- oder Netzwerkmanager abhängig [RO] scutil --proxy
curl ohne Proxy [TEST] curl.exe --noproxy "*" -v https://<Servername>/ [TEST] curl --noproxy "*" -v https://<Servername>/ [TEST] curl --noproxy "*" -v https://<Servername>/

Das Umgehen eines Unternehmensproxys darf nur erfolgen, wenn direkte Verbindungen erlaubt und der Test autorisiert ist.

22. Aktive TCP-Verbindungen
Aufgabe Windows Linux macOS
TCP-Verbindungen [RO][PRIV] Get-NetTCPConnection [RO][PRIV] ss -tanp [RO] netstat -anv -p tcp
Verbindungen mit PID [RO][PRIV] Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess [RO][PRIV] ss -tanp [RO][PRIV] lsof -nP -iTCP
Klassische Übersicht [RO][PRIV] netstat -ano [RO] netstat -antp sofern installiert [RO] netstat -anv -p tcp
Bestehende Verbindungen [RO] Get-NetTCPConnection -State Established [RO][PRIV] ss -tanp state established [RO][PRIV] lsof -nP -iTCP -sTCP:ESTABLISHED
23. UDP-Endpunkte
Windows Linux macOS
[RO][PRIV] Get-NetUDPEndpoint [RO][PRIV] ss -uanp [RO] netstat -anv -p udp
[RO][PRIV] netstat -ano -p udp [RO][PRIV] lsof -nP -iUDP [RO][PRIV] lsof -nP -iUDP

UDP besitzt keinen TCP-Verbindungszustand wie Established. Ein offener UDP-Endpunkt bestätigt nicht, dass eine Anwendung antwortet.

24. TCP-Listener
Aufgabe Windows Linux macOS
Alle Listener [RO][PRIV] Get-NetTCPConnection -State Listen [RO][PRIV] ss -lntp [RO][PRIV] lsof -nP -iTCP -sTCP:LISTEN
Bestimmter Port [RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port> [RO][PRIV] ss -lntp | grep ":<Port>" [RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN
PID zu Listener Eigenschaft OwningProcess verwenden Ausgabe von ss -lntp Ausgabe von lsof
Prozess zur PID [RO] Get-Process -Id <PID> [RO] ps -p <PID> -o pid,user,command [RO] ps -p <PID> -o pid,user,command

Ein Listener bestätigt nur, dass ein Prozess den Port gebunden hat. Die Anwendung kann intern trotzdem fehlerhaft sein.

25. ICMP-Erreichbarkeit
Aufgabe Windows Linux macOS
Vier Ping-Versuche [TEST] ping -n 4 <IP-Adresse> [TEST] ping -c 4 <IP-Adresse> [TEST] ping -c 4 <IP-Adresse>
Zehn Versuche [TEST] ping -n 10 <IP-Adresse> [TEST] ping -c 10 <IP-Adresse> [TEST] ping -c 10 <IP-Adresse>
PowerShell-Test [TEST] Test-Connection -ComputerName <Servername> -Count 4 PowerShell nur wenn installiert PowerShell nur wenn installiert

Ein fehlgeschlagener Ping beweist keinen Serverausfall. ICMP kann blockiert sein, während TCP- oder UDP-Dienste funktionieren.

26. TCP-Port testen
Windows Linux macOS
[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed [TEST] nc -vz -w 3 <Servername> <Port> [TEST] nc -vz -w 3 <Servername> <Port>
[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Quiet nc verwenden nc verwenden

Windows-Auswertung

Besonders relevantes Feld:

TcpTestSucceeded

Interpretation

Ergebnis Mögliche Bedeutung
Verbindung erfolgreich Netzwerkpfad und TCP-Listener grundsätzlich erreichbar
Connection refused Ziel erreichbar, aber kein Listener oder aktive Ablehnung
Timeout Filterung, Routing, Überlastung oder nicht antwortendes Ziel
Name nicht auflösbar DNS zuerst prüfen
Nur ein Client betroffen lokales System, lokales Netz oder lokale Sicherheitssoftware
Nur ein VLAN betroffen ACL, Routing, Firewall oder VLAN-Konfiguration
27. Netzwerkpfad verfolgen
Windows Linux macOS
[TEST] tracert <Servername> [TEST] tracepath <Servername> [TEST] traceroute <Servername>
[TEST] Test-NetConnection <Servername> -TraceRoute [TEST] traceroute <Servername> sofern installiert [TEST] traceroute <Servername>

Sternchen bedeuten nicht automatisch einen Fehler. Router können Traceroute-Anfragen ignorieren und Nutzverkehr trotzdem weiterleiten.

28. Lokalen und entfernten Dienst vergleichen
Testpunkt Windows Linux macOS
localhost [TEST] Test-NetConnection localhost -Port <Port> [TEST] nc -vz -w 3 localhost <Port> [TEST] nc -vz -w 3 localhost <Port>
eigene IP [TEST] Test-NetConnection <Eigene-IP> -Port <Port> [TEST] nc -vz -w 3 <Eigene-IP> <Port> [TEST] nc -vz -w 3 <Eigene-IP> <Port>
Servername [TEST] Test-NetConnection <Servername> -Port <Port> [TEST] nc -vz -w 3 <Servername> <Port> [TEST] nc -vz -w 3 <Servername> <Port>

Interpretation

localhost Eigene IP Remote Möglicher Fehlerbereich
erfolgreich erfolgreich fehlgeschlagen Netzwerkpfad oder Firewall
erfolgreich fehlgeschlagen fehlgeschlagen Bindung oder lokale Firewall
fehlgeschlagen fehlgeschlagen fehlgeschlagen Dienst oder Anwendung
erfolgreich erfolgreich erfolgreich Transportebene funktioniert
29. HTTP- und HTTPS-Test
Aufgabe Windows Linux macOS
Ausführlicher Test [TEST] curl.exe -v -o NUL https://<Servername>/ [TEST] curl -v -o /dev/null https://<Servername>/ [TEST] curl -v -o /dev/null https://<Servername>/
Nur Header [TEST] curl.exe -vI https://<Servername>/ [TEST] curl -vI https://<Servername>/ [TEST] curl -vI https://<Servername>/
Zeitbegrenzung [TEST] curl.exe --connect-timeout 5 --max-time 15 https://<Servername>/ [TEST] curl --connect-timeout 5 --max-time 15 https://<Servername>/ [TEST] curl --connect-timeout 5 --max-time 15 https://<Servername>/
HTTP-Fehler als curl-Fehler [TEST] curl.exe --fail https://<Servername>/ [TEST] curl --fail https://<Servername>/ [TEST] curl --fail https://<Servername>/

Einige Server unterstützen die HTTP-Methode HEAD nicht korrekt. Ein fehlgeschlagener curl -I-Test sollte daher mit einem normalen GET-Test verglichen werden.

30. HTTP-Zeiten messen

Windows PowerShell

[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https://<Servername>/

Linux und macOS

[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Wert Bedeutung
http_code HTTP-Status
remote_ip verwendete Ziel-IP
time_namelookup Dauer der Namensauflösung
time_connect Dauer bis TCP-Verbindungsaufbau
time_appconnect Dauer bis TLS-Verbindungsaufbau
time_starttransfer Dauer bis zum ersten Byte
time_total Gesamtzeit
31. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen
Windows Linux macOS
[TEST] curl.exe --resolve "<Servername>:443:<IP-Adresse>" -v -o NUL https://<Servername>/ [TEST] curl --resolve "<Servername>:443:<IP-Adresse>" -v -o /dev/null https://<Servername>/ [TEST] curl --resolve "<Servername>:443:<IP-Adresse>" -v -o /dev/null https://<Servername>/

--resolve behält für diesen curl-Aufruf:

Nur die Ziel-IP wird vorgegeben.

32. TLS prüfen
Aufgabe Windows Linux macOS
TLS-Verbindung [TEST] openssl s_client -connect <Servername>:443 -servername <Servername> -showcerts sofern OpenSSL installiert [TEST] openssl s_client -connect <Servername>:443 -servername <Servername> -showcerts </dev/null [TEST] openssl s_client -connect <Servername>:443 -servername <Servername> -showcerts </dev/null
OpenSSL-Version [RO] openssl version -a [RO] openssl version -a [RO] openssl version -a
Zertifikatdatei [RO] openssl x509 -in "<Datei.pem>" -noout -text [RO] openssl x509 -in "<Datei.pem>" -noout -text [RO] openssl x509 -in "<Datei.pem>" -noout -text

Zu prüfen

33. HTTP-Status schnell interpretieren
Status Typische Bedeutung
200 Anfrage erfolgreich
301 oder 302 Weiterleitung
400 ungültige Anfrage
401 Authentifizierung erforderlich oder fehlgeschlagen
403 Zugriff verweigert
404 Ressource oder Pfad nicht gefunden
408 Anfrage-Timeout
429 zu viele Anfragen oder Rate Limit
500 interner Anwendungsfehler
502 Proxy oder Gateway erhält ungültige Backend-Antwort
503 Dienst oder Backend nicht verfügbar
504 Proxy oder Gateway wartet vergeblich auf Backend
000 bei curl keine gültige HTTP-Antwort empfangen

Die genaue Bedeutung kann durch die Anwendung erweitert oder verändert werden.

34. Windows-Ereignisprotokolle
Aufgabe Befehl
Systemprotokoll [RO] Get-WinEvent -LogName "System" -MaxEvents 100
Anwendungsprotokoll [RO] Get-WinEvent -LogName "Application" -MaxEvents 100
Warnungen und Fehler [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=(Get-Date).AddHours(-1)}
Kritische Fehler und Fehler [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddHours(-1)}
Zeitfenster [RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}
Ereignis-ID [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Id=<Ereignis-ID>; StartTime=(Get-Date).AddHours(-1)}
Anbieter [RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="<Anbieter>"; StartTime=(Get-Date).AddHours(-1)}
Übersicht [RO] Get-WinEvent -LogName "System" -MaxEvents 100 | Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message

Windows-Ereignisstufen

Level Bedeutung
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich
35. Windows-Dienstereignisse
Ereignis-ID Typische Bedeutung
7031 Dienst wurde unerwartet beendet
7034 Dienst wurde unerwartet beendet
7036 Dienstzustand wurde geändert
7040 Starttyp wurde geändert
7045 neuer Dienst wurde installiert

Abfrage

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated,Id,Message

36. Windows-Ereignisprotokolle exportieren
Protokoll Befehl
System [FILE][PRIV] wevtutil epl System "<Zielpfad>\System.evtx"
Application [FILE][PRIV] wevtutil epl Application "<Zielpfad>\Application.evtx"
Security [FILE][PRIV][SENSITIV] wevtutil epl Security "<Zielpfad>\Security.evtx"
PowerShell Operational [FILE][PRIV][SENSITIV] wevtutil epl "Microsoft-Windows-PowerShell/Operational" "<Zielpfad>\PowerShell-Operational.evtx"

Vor dem Export sollte ein neuer Zielordner verwendet werden. Vorhandene Dateien dürfen nicht unkontrolliert überschrieben werden.

37. Linux-Journal
Aufgabe Befehl
Aktueller Boot [RO] journalctl -b
Vorheriger Boot [RO] journalctl -b -1
Letzte Stunde [RO] journalctl --since "1 hour ago"
Zeitfenster [RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"
Bestimmter Dienst [RO] journalctl -u <Dienstname>.service --since "1 hour ago"
Kernelmeldungen [RO] journalctl -k -b
Warnungen und schwerer [RO] journalctl -p warning --since "1 hour ago"
Nur Fehler [RO] journalctl -p err --since "1 hour ago"
ISO-Zeitstempel [RO] journalctl -o short-iso-precise --since "1 hour ago"
Ohne Pager [RO] journalctl --since "1 hour ago" --no-pager
Klassische Kernelmeldungen [RO][PRIV] dmesg --ctime
38. Linux-Journal exportieren
Aufgabe Befehl
Aktueller Boot [FILE] journalctl -b --no-pager --output=short-iso-precise > "<Zielpfad>/journal-current-boot.log"
Vorheriger Boot [FILE] journalctl -b -1 --no-pager --output=short-iso-precise > "<Zielpfad>/journal-previous-boot.log"
Zeitfenster [FILE] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "<Zielpfad>/journal-time-window.log"
Dienst [FILE] journalctl -u <Dienstname>.service --since "1 hour ago" --no-pager --output=short-iso-precise > "<Zielpfad>/<Dienstname>.log"
Kernelmeldungen [FILE][PRIV] dmesg --ctime > "<Zielpfad>/dmesg.log"

Die Umleitung mit > überschreibt eine vorhandene Datei. Deshalb sollte ein neuer Zielordner verwendet werden.

39. macOS Unified Log
Aufgabe Befehl
Letzte Stunde [RO][SENSITIV] log show --last 1h --style compact
Zeitfenster [RO][SENSITIV] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact
Fehler und Faults [RO][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact
Bestimmter Prozess [RO][SENSITIV] log show --last 1h --predicate 'process == "<Prozessname>"' --style compact
Prozessfehler [RO][SENSITIV] log show --last 1h --predicate 'process == "<Prozessname>" AND (messageType == error OR messageType == fault)' --style compact
Live-Ansicht [RO][SENSITIV] log stream --style compact

Export

[FILE][SENSITIV] log show --last 1h --style compact > "<Zielpfad>/macOS-unified-log.txt"

Grafische Werkzeuge

40. Windows-Updates und Installationsverlauf
Aufgabe Befehl
Installierte Hotfixes [RO] Get-HotFix | Sort-Object InstalledOn -Descending
Hotfixdetails [RO] Get-HotFix | Select-Object InstalledOn,HotFixID,Description,InstalledBy
Updateereignisse [RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100
Updateereignisse im Zeitfenster [RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}
Lesbare Updateprotokolldatei [FILE] Get-WindowsUpdateLog -LogPath "<Zielpfad>\WindowsUpdate.log"

Get-HotFix zeigt nicht zwingend jede Aktualisierung. Zusätzlich sollten Windows-Updateverlauf und Patchmanagement geprüft werden.

41. Linux-Paketverlauf
Distribution Aufgabe Befehl
Debian/Ubuntu APT-Verlauf [RO] less /var/log/apt/history.log
Debian/Ubuntu DPKG-Verlauf [RO] less /var/log/dpkg.log
Debian/Ubuntu Paketänderungen [RO] grep -E " install | upgrade | remove " /var/log/dpkg.log
Debian/Ubuntu rotierte Logs [RO] zgrep -hE " install | upgrade | remove " /var/log/dpkg.log*
RHEL/Rocky/Alma/Fedora DNF-Verlauf [RO] dnf history list
RHEL/Rocky/Alma/Fedora Transaktionsdetails [RO] dnf history info <Transaktions-ID>
RHEL/Rocky/Alma/Fedora letzte Transaktion [RO] dnf history info last
RPM-basiert Pakete nach Installationszeit [RO] rpm -qa --last
SUSE/openSUSE Zypper-Verlauf [RO] less /var/log/zypp/history
Arch Linux Pacman-Verlauf [RO] less /var/log/pacman.log
Arch Linux Änderungen filtern [RO] grep -E "\[ALPM\] (installed|upgraded|removed)" /var/log/pacman.log
42. macOS-Installationsverlauf
Aufgabe Befehl
Softwareupdateverlauf [RO] softwareupdate --history
Installationsverlauf [RO] system_profiler SPInstallHistoryDataType
Installierte Anwendungen [RO] system_profiler SPApplicationsDataType

Grafischer Weg:

Systeminformationen → Software → Installationen

43. Geplante Aufgaben und Automatisierung
Aufgabe Windows Linux macOS
Geplante Aufgaben [RO] Get-ScheduledTask [RO] crontab -l [RO] launchctl list
Laufzeitinformationen [RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending [RO] systemctl list-timers --all [RO] launchctl list
Auffällige Ergebnisse [RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object LastTaskResult -ne 0 Cron- und Dienstprotokolle prüfen Unified Log prüfen
Task-Scheduler-Protokoll [RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100 Nicht zutreffend Nicht zutreffend
Systemweite Cronjobs Nicht zutreffend [RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly Nicht zutreffend
Debian/Ubuntu-Cronlog Nicht zutreffend [RO] journalctl -u cron --since "1 hour ago" Nicht zutreffend
RHEL-Cronlog Nicht zutreffend [RO] journalctl -u crond --since "1 hour ago" Nicht zutreffend
LaunchDaemons Nicht zutreffend Nicht zutreffend [RO] ls -la /Library/LaunchDaemons
Systemweite LaunchAgents Nicht zutreffend Nicht zutreffend [RO] ls -la /Library/LaunchAgents
Benutzer-LaunchAgents Nicht zutreffend Nicht zutreffend [RO] ls -la ~/Library/LaunchAgents

Ein von 0 abweichendes Task-Ergebnis muss anhand der jeweiligen Aufgabe interpretiert werden.

44. Dateiinformationen
Aufgabe Windows Linux macOS
Dateiinformationen [RO] Get-Item "<Datei>" | Select-Object FullName,Length,CreationTime,LastWriteTime [RO] stat "<Datei>" [RO] stat -x "<Datei>"
Dateityp Erweiterung und Anwendung prüfen [RO] file "<Datei>" [RO] file "<Datei>"
Programmversion [RO] (Get-Item "<Datei>").VersionInfo Paketmanager oder --version --version oder Systeminformationen
Dateiinhalt [RO] Get-Content "<Datei>" [RO] less "<Datei>" [RO] less "<Datei>"
Rohinhalt [RO] Get-Content "<Datei>" -Raw [RO] cat "<Datei>" [RO] cat "<Datei>"

Bei großen oder binären Dateien sollte nicht der gesamte Inhalt unkontrolliert ausgegeben werden.

45. Dateien und Konfigurationen vergleichen
Aufgabe Windows Linux macOS
Textdateien vergleichen [RO] Compare-Object (Get-Content "<Datei-A>") (Get-Content "<Datei-B>") [RO] diff -u "<Datei-A>" "<Datei-B>" [RO] diff -u "<Datei-A>" "<Datei-B>"
Binäre Gleichheit [RO] Get-FileHash "<Datei>" -Algorithm SHA256 [RO] sha256sum "<Datei>" [RO] shasum -a 256 "<Datei>"
Git-Arbeitszustand [RO] git status [RO] git status [RO] git status
Git-Änderungen [RO] git diff [RO] git diff [RO] git diff
Letzte Commits [RO] git log --oneline --decorate -n 20 [RO] git log --oneline --decorate -n 20 [RO] git log --oneline --decorate -n 20
Verlauf einer Datei [RO] git log -p -- "<Datei>" [RO] git log -p -- "<Datei>" [RO] git log -p -- "<Datei>"
46. Prüfsummen
Aufgabe Windows Linux macOS
SHA-256 einer Datei [RO] Get-FileHash "<Datei>" -Algorithm SHA256 [RO] sha256sum "<Datei>" [RO] shasum -a 256 "<Datei>"
Prüfsumme prüfen neu berechnen und vergleichen [RO] sha256sum -c "<SHA256SUMS-Datei>" [RO] shasum -a 256 -c "<SHA256SUMS-Datei>"
Ordner-Manifest [FILE] Get-ChildItem "<Diagnoseordner>" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "<Diagnoseordner>-SHA256.csv" -NoTypeInformation -Encoding UTF8 [FILE] (cd "<Diagnoseordner>" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "<Diagnoseordner>-SHA256SUMS.txt" [FILE] find "<Diagnoseordner>" -type f -exec shasum -a 256 {} \; > "<Diagnoseordner>-SHA256SUMS.txt"

Eine Prüfsumme dokumentiert die Dateiintegrität ab dem Zeitpunkt ihrer Berechnung, aber nicht automatisch Herkunft oder Authentizität.

47. Dateiberechtigungen
Aufgabe Windows Linux macOS
ACL anzeigen [RO][SENSITIV] Get-Acl "<Pfad>" | Format-List [RO][SENSITIV] getfacl "<Pfad>" [RO][SENSITIV] ls -lde "<Pfad>"
Klassische Ansicht [RO][SENSITIV] icacls "<Pfad>" [RO] ls -ld "<Pfad>" [RO] ls -lde "<Pfad>"
Benutzergruppen [RO][SENSITIV] whoami /all [RO] id <Benutzername> [RO] id <Benutzername>
Vollständigen Pfad prüfen Pfadabschnitte mit Get-Acl prüfen [RO] namei -l "<Pfad>" Pfadabschnitte mit ls -lde prüfen
Besitzer und Gruppe [RO] Get-Acl "<Pfad>" | Select-Object Owner [RO] stat "<Pfad>" [RO] stat -x "<Pfad>"
48. Active Directory und Gruppenrichtlinien
Aufgabe Windows
Benutzer- und Gruppeninformationen [RO][SENSITIV] whoami /all
Resultierende Richtlinien kompakt [RO] gpresult /r
HTML-Bericht [FILE] gpresult /h "<Zielpfad>\gpresult.html"
Gruppenrichtlinienprotokoll [RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100
Sicheren Domänenkanal prüfen [TEST] Test-ComputerSecureChannel -Verbose
Bestimmten Domänencontroller prüfen [TEST] Test-ComputerSecureChannel -Server "<Domänencontroller>" -Verbose
Sicherheitsereignisse [RO][PRIV][SENSITIV] Get-WinEvent -LogName "Security" -MaxEvents 100

Test-ComputerSecureChannel ist für Domänenmitgliedscomputer vorgesehen. Der Parameter -Repair wäre eine Änderung und ist kein reiner Test.

49. Konfigurationssyntax prüfen
Format oder Dienst Windows Linux macOS
JSON mit PowerShell [TEST] Get-Content "<Datei.json>" -Raw | ConvertFrom-Json | Out-Null PowerShell nur wenn installiert PowerShell nur wenn installiert
JSON mit Python [TEST] python3 -m json.tool "<Datei.json>" > NUL [TEST] python3 -m json.tool "<Datei.json>" > /dev/null [TEST] python3 -m json.tool "<Datei.json>" > /dev/null
JSON mit jq [TEST] jq empty "<Datei.json>" [TEST] jq empty "<Datei.json>" [TEST] jq empty "<Datei.json>"
Property List Nicht zutreffend Nicht zutreffend [TEST] plutil -lint "<Datei.plist>"
systemd-Unit Nicht zutreffend [TEST] systemd-analyze verify "<Datei.service>" Nicht zutreffend
NGINX [TEST][PRIV] nginx -t sofern installiert [TEST][PRIV] nginx -t [TEST][PRIV] nginx -t sofern installiert
Apache installationsabhängig [TEST][PRIV] apachectl configtest [TEST][PRIV] apachectl configtest
OpenSSH-Server [TEST][PRIV] sshd -t sofern installiert [TEST][PRIV] sshd -t [TEST][PRIV] sshd -t

Ein erfolgreicher Syntax-Test bestätigt nicht, dass Netzwerkziele, Zertifikate, Berechtigungen und Abhängigkeiten funktionieren.

50. Terminal- und Diagnosesitzung protokollieren
Aufgabe Windows PowerShell Linux macOS
Aufzeichnung starten [FILE][SENSITIV] Start-Transcript -Path "<Zielpfad>\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber [FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt" [FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt"
Aufzeichnung beenden [FILE] Stop-Transcript exit oder Strg + D exit oder Strg + D
Anzeigen und speichern [FILE] <Befehl> | Tee-Object -FilePath "<Zielpfad>\Ausgabe.txt" [FILE] <Befehl> 2>&1 | tee "<Zielpfad>/Ausgabe.txt" [FILE] <Befehl> 2>&1 | tee "<Zielpfad>/Ausgabe.txt"
Ausgabe und Fehler speichern [FILE] <Befehl> *> "<Zielpfad>\Ausgabe.txt" [FILE] <Befehl> > "<Zielpfad>/Ausgabe.txt" 2>&1 [FILE] <Befehl> > "<Zielpfad>/Ausgabe.txt" 2>&1

Transkripte können Benutzernamen, Pfade und andere sensible Informationen enthalten.

51. Rückgabewerte prüfen
Plattform Befehl Bedeutung
PowerShell-Cmdlet [RO] $? Erfolg der vorherigen PowerShell-Operation
PowerShell mit externem Programm [RO] $LASTEXITCODE Exit-Code des letzten nativen Programms
Windows CMD [RO] echo %ERRORLEVEL% Exit-Code des letzten Programms
Linux [RO] echo $? Exit-Code des letzten Befehls
macOS [RO] echo $? Exit-Code des letzten Befehls

Der Wert muss unmittelbar nach dem betreffenden Befehl gesichert werden.

Ein Exit-Code 0 bedeutet nur, dass das Werkzeug Erfolg meldet. Die Benutzer- oder Anwendungsfunktion kann trotzdem fehlschlagen.

52. Werkzeugversionen
Aufgabe Windows Linux macOS
PowerShell-Version [RO] $PSVersionTable [RO] pwsh -Version sofern installiert [RO] pwsh -Version sofern installiert
curl-Version [RO] curl.exe --version [RO] curl --version [RO] curl --version
OpenSSL-Version [RO] openssl version -a [RO] openssl version -a [RO] openssl version -a
Git-Version [RO] git --version [RO] git --version [RO] git --version
Python-Version [RO] python --version oder python3 --version [RO] python3 --version [RO] python3 --version

Unterschiedliche Versionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden.

53. Paketaufzeichnung

Paketaufzeichnungen können vertrauliche Nutzdaten, Hostnamen, IP-Adressen und Sitzungsinformationen enthalten. Berechtigung, Speicherort, Zeitraum und Datenschutz müssen vorher geklärt sein.

Windows mit pktmon

Aufgabe Befehl
Aufzeichnung starten [FILE][TEST][PRIV][SENSITIV] pktmon start --capture --pkt-size 0 --file-name "<Zielpfad>\capture.etl"
Aufzeichnung beenden [TEST][PRIV] pktmon stop
In PCAPNG umwandeln [FILE][SENSITIV] pktmon etl2pcap "<Zielpfad>\capture.etl" --out "<Zielpfad>\capture.pcapng"

Linux mit tcpdump

[FILE][TEST][PRIV][SENSITIV] sudo tcpdump -i any -nn -s 0 -w "<Zielpfad>/capture.pcap"

macOS mit tcpdump

[FILE][TEST][PRIV][SENSITIV] sudo tcpdump -i <Interface> -nn -s 0 -w "<Zielpfad>/capture.pcap"

Beenden mit Strg + C.

54. Dienständerungen – nur nach Sicherung und Freigabe

Die folgenden Befehle verändern den Betriebszustand und gehören nicht an den Anfang der Diagnose.

Aufgabe Windows Linux macOS
Neustart nur anzeigen [TEST] Restart-Service -Name <Dienstname> -WhatIf keine vollständige systemctl-Simulation keine vollständige launchctl-Simulation
Dienst starten [CHANGE][PRIV] Start-Service -Name <Dienstname> -Confirm [CHANGE][PRIV] sudo systemctl start <Dienstname>.service [CHANGE][PRIV] sudo launchctl kickstart system/<Dienstlabel>
Konfiguration neu laden anwendungsspezifisch [CHANGE][PRIV] sudo systemctl reload <Dienstname>.service anwendungsspezifisch
Dienst neu starten [CHANGE][DISRUPTIV][PRIV] Restart-Service -Name <Dienstname> -Confirm [CHANGE][DISRUPTIV][PRIV] sudo systemctl restart <Dienstname>.service [CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/<Dienstlabel>
Nur laufenden Dienst neu starten Status vorher prüfen [CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart <Dienstname>.service Status vorher prüfen
Zustand danach [RO] Get-Service -Name <Dienstname> [RO] systemctl status <Dienstname>.service --no-pager [RO][PRIV] launchctl print system/<Dienstlabel>

Ein Reload funktioniert nur, wenn der jeweilige Dienst diese Funktion unterstützt.

55. Konfigurationsdatei sichern

Windows

$backupFile = Join-Path "<Zielpfad>" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak"
Copy-Item "<Konfigurationsdatei>" $backupFile
Get-FileHash -Path "<Konfigurationsdatei>", $backupFile -Algorithm SHA256

Linux

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"
cp --preserve=all -- "<Konfigurationsdatei>" "$backup_file"
sha256sum "<Konfigurationsdatei>" "$backup_file"

macOS

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"
cp -p "<Konfigurationsdatei>" "$backup_file"
shasum -a 256 "<Konfigurationsdatei>" "$backup_file"

Für komplexe Anwendungen, Datenbanken, Verzeichnisdienste und Cluster muss die vorgesehene Backup- oder Exportfunktion verwendet werden.

56. Einfache Konfigurationsdatei zurückspielen

Nur verwenden, wenn Sicherung, Dateirechte, Besitzer, Metadaten und Anwendungsvorgaben geprüft wurden.

Windows Linux macOS
[CHANGE][PRIV] Copy-Item "<Sicherungsdatei>" "<Konfigurationsdatei>" -Force [CHANGE][PRIV] sudo cp --preserve=all -- "<Sicherungsdatei>" "<Konfigurationsdatei>" [CHANGE][PRIV] sudo cp -p "<Sicherungsdatei>" "<Konfigurationsdatei>"

Danach prüfen:

57. Häufige Ergebniskombinationen
Beobachtung Wahrscheinlicher Prüfbereich
Zugriff per IP funktioniert, per Name nicht DNS, Hosts-Datei oder Suchdomäne
DNS liefert unterschiedliche IPs Split-DNS, Load Balancing oder Cache
Ping scheitert, TCP funktioniert ICMP wahrscheinlich blockiert
Ping funktioniert, TCP scheitert Port, Listener oder Firewall
TCP erfolgreich, TLS scheitert Zertifikat, TLS-Version, Cipher oder SNI
TLS erfolgreich, HTTP 500 Anwendung oder Backend
HTTP 401 Authentifizierung
HTTP 403 Autorisierung oder Sicherheitsrichtlinie
HTTP 502 oder 504 Proxy, Load Balancer oder Backend
localhost funktioniert, Remotezugriff nicht Listener-Bindung, Firewall oder Netzwerkpfad
localhost funktioniert nicht Dienst oder Anwendung
nur ein Benutzer betroffen Konto, Rolle, Berechtigung oder Profil
nur ein Client betroffen Clientkonfiguration, lokaler Dienst oder Sicherheitssoftware
nur ein VLAN betroffen VLAN, ACL, Routing, DHCP oder Gateway
alle Clients betroffen Server, Dienst oder gemeinsame Abhängigkeit
Dienststatus „Running“, aber Port fehlt Bindungs-, Konfigurations- oder Prozessproblem
Port vorhanden, Anwendung antwortet nicht Anwendung hängt oder Abhängigkeit fehlt
Neustart behebt Fehler vorübergehend Cache, Speicherleck, Prozesszustand oder Verbindung
Datenträger frei, Schreiben scheitert Inodes, Quota, Berechtigung oder Read-only-Mount
58. Häufige Fehlermeldungen bei Netzwerkverbindungen
Meldung Mögliche Bedeutung
Connection refused Ziel erreichbar, aber kein Listener oder aktive Ablehnung
Connection timed out Paketverlust, Filterung, Routing oder nicht antwortendes Ziel
No route to host Route, Gateway, Interface oder Netz nicht erreichbar
Network is unreachable keine geeignete Route oder Schnittstelle
Name or service not known Namensauflösung fehlgeschlagen
Temporary failure in name resolution DNS-Server oder Resolver vorübergehend nicht verfügbar
Hostname mismatch Zertifikat passt nicht zum aufgerufenen Hostnamen
Certificate expired Zertifikat ist abgelaufen
Permission denied Dateirechte, ACL, Rolle oder Sicherheitsrichtlinie
Address already in use Port oder Socket bereits gebunden
No space left on device Speicherplatz oder Inodes erschöpft
Too many open files Datei- oder Prozesslimit erreicht
59. Was vor einem Neustart gesichert werden sollte
Priorität Information
1 Fehlermeldung und Screenshot
2 Uhrzeit und Zeitzone
3 laufende Prozesse
4 Dienstzustand
5 aktive Netzwerkverbindungen
6 Listener
7 IP-Konfiguration und Routing
8 ARP-, Neighbor- und DNS-Cache
9 angemeldete Benutzer
10 CPU-, RAM- und Datenträgerzustand
11 aktuelle Protokolle
12 letzte Änderungen
13 Konfiguration und Prüfsummen
60. Was nicht unüberlegt ausgeführt werden sollte
Maßnahme Grund
Computer neu starten flüchtige Informationen gehen verloren
Dienst sofort neu starten ursprünglicher Prozesszustand geht verloren
Prozess beenden Verbindungen, Speicher und offene Dateien verschwinden
DNS-Cache leeren diagnostisch relevante Cacheeinträge gehen verloren
ARP-Tabelle leeren Zuordnungen zwischen IP und MAC gehen verloren
Protokolle löschen Belege gehen verloren
Firewall vollständig deaktivieren Sicherheitsrisiko und unklarer Test
Update installieren Ausgangszustand wird verändert
Konfiguration zurücksetzen Fehlerursache ist schwerer nachvollziehbar
Snapshot unkontrolliert zurückspielen Daten- und Konsistenzrisiko
mehrere Änderungen gleichzeitig Wirkung kann nicht zugeordnet werden
61. Minimaler Erstsnapshot – Windows
Aufgabe Befehl
Zeit [RO] Get-Date -Format o
Betriebssystem [RO] Get-CimInstance Win32_OperatingSystem
letzter Start [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Benutzer [RO][SENSITIV] whoami /all
Prozesse [RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,CommandLine
Dienste [RO] Get-Service
IP-Konfiguration [RO] ipconfig /all
Routing [RO] route print
ARP [RO] arp -a
DNS-Cache [RO][SENSITIV] ipconfig /displaydns
TCP-Verbindungen [RO][PRIV] netstat -ano
Volumes [RO] Get-Volume
Fehlerprotokoll [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddHours(-1)}
62. Minimaler Erstsnapshot – Linux
Aufgabe Befehl
Zeit [RO] date --iso-8601=seconds
Betriebssystem [RO] cat /etc/os-release
Kernel [RO] uname -a
Betriebsdauer [RO] uptime
Benutzer [RO] who -a
Prozesse [RO][SENSITIV] ps auxww
Dienste [RO] systemctl --failed
IP-Konfiguration [RO] ip -details address show
Routing [RO] ip route show table all
Neighbor [RO] ip neigh show
DNS [RO] resolvectl status
Sockets [RO][PRIV] ss -tulpn
Speicher [RO] free -h
Dateisysteme [RO] df -hT
Journal [RO] journalctl -b -p warning --no-pager
Kernelmeldungen [RO][PRIV] dmesg --ctime
63. Minimaler Erstsnapshot – macOS
Aufgabe Befehl
Zeit [RO] date "+%Y-%m-%dT%H:%M:%S%z"
Betriebssystem [RO] sw_vers
Kernel [RO] uname -a
Betriebsdauer [RO] uptime
Benutzer [RO] who
Prozesse [RO][SENSITIV] ps auxww
Dienste [RO] launchctl list
IP-Konfiguration [RO] ifconfig -a
Routing [RO] netstat -rn
ARP [RO] arp -an
DNS [RO][SENSITIV] scutil --dns
TCP-Verbindungen [RO] netstat -anv -p tcp
Speicher [RO] vm_stat
Dateisysteme [RO] df -h
Protokollfehler [RO][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact
64. Abschlussprüfung nach einer Lösung
Ebene Windows Linux macOS
Zeitpunkt Get-Date -Format o date --iso-8601=seconds date "+%Y-%m-%dT%H:%M:%S%z"
Dienststatus Get-Service -Name <Dienstname> systemctl status <Dienstname>.service launchctl print system/<Dienstlabel>
Listener Get-NetTCPConnection -State Listen -LocalPort <Port> ss -lntp | grep ":<Port>" lsof -nP -iTCP:<Port> -sTCP:LISTEN
TCP-Test Test-NetConnection <Servername> -Port <Port> nc -vz -w 3 <Servername> <Port> nc -vz -w 3 <Servername> <Port>
HTTP-Test curl.exe https://<Servername>/ curl https://<Servername>/ curl https://<Servername>/
neue Fehler Get-WinEvent journalctl log show
Benutzerfunktion ursprünglichen Ablauf wiederholen ursprünglichen Ablauf wiederholen ursprünglichen Ablauf wiederholen
Sicherheit unerlaubten Zugriff negativ testen unerlaubten Zugriff negativ testen unerlaubten Zugriff negativ testen
Monitoring zentrale Überwachung prüfen zentrale Überwachung prüfen zentrale Überwachung prüfen
65. Wichtigste Regeln

Ergebnis dieser Seite

Diese Seite bildet die Schnellreferenz für Kapitel 1. Sie enthält die wichtigsten Befehle für:

Damit ist Kapitel 1 – Grundlagen der systematischen Fehleranalyse abgeschlossen.

Offizielle Hersteller-, Standard- und Projektdokumentation