Grundregel

1. Symptom und Zeitpunkt festhalten.
2. Umfang der Störung bestimmen.
3. Ereignisprotokolle zum betreffenden Zeitraum prüfen.
4. Ressourcen und betroffene Komponenten untersuchen.
5. Abhängigkeiten kontrollieren.
6. Erst danach Änderungen durchführen.
7. Ergebnis und Rückfallmöglichkeit dokumentieren.

Windows-Versionsdialog öffnen

[RO] winver

Systeminformationen anzeigen

[RO][SENS] systeminfo

Die Ausgabe kann unter anderem Computername, Betriebssystemversion, Installationsdatum, Arbeitsspeicher, Domänenzugehörigkeit und installierte Hotfixes enthalten.

Windows-Version mit PowerShell

[RO] Get-ComputerInfo |
    Select-Object WindowsProductName,
                  WindowsVersion,
                  OsBuildNumber,
                  OsArchitecture

Betriebssystem über CIM abfragen

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption,
                  Version,
                  BuildNumber,
                  OSArchitecture,
                  LastBootUpTime

Computer- und Hardwareinformationen

[RO][SENS] Get-ComputerInfo

Systeminformationen grafisch öffnen

[RO] msinfo32

msinfo32 enthält eine umfassende Übersicht über Hardware, Komponenten, Treiber, Ressourcen und die Softwareumgebung.

Systeminformationen können Computername, Benutzerbezug, Netzwerkdaten und installierte Software offenlegen. Exporte müssen vor einer Weitergabe geprüft werden.

Ereignisanzeige öffnen

[RO] eventvwr.msc

Wichtige Windows-Protokolle

Unter Anwendungs- und Dienstprotokolle befinden sich zusätzliche komponentenspezifische Protokolle, beispielsweise für PowerShell, Windows Defender, DNS, Gruppenrichtlinien oder Remotedesktopdienste.

Ereignisstufen

Wichtige Bewertungsregeln

• Nicht jeder Fehler im Protokoll verursacht die untersuchte Störung.
• Eine hohe Zahl von Warnungen bedeutet nicht automatisch ein schwerwiegendes Problem.
• Ereignis-ID und Quelle müssen gemeinsam betrachtet werden.
• Derselbe Ereigniscode kann bei unterschiedlichen Quellen etwas anderes bedeuten.
• Der Zeitstempel muss zur tatsächlichen Störung passen.
• Folgefehler dürfen nicht mit der ursprünglichen Ursache verwechselt werden.
• Ereignisse vor dem sichtbaren Fehler sind häufig besonders wichtig.
• Ein unerwarteter Neustart kann ältere Protokolle oder flüchtige Zustände verändern.

Benutzerdefinierte Ansicht erstellen

1. Ereignisanzeige öffnen.
2. Benutzerdefinierte Ansichten auswählen.
3. Benutzerdefinierte Ansicht erstellen öffnen.
4. Zeitraum und Ereignisstufen festlegen.
5. Benötigte Protokolle oder Quellen auswählen.
6. Filter speichern und Ergebnisse chronologisch untersuchen.

Das bloße Löschen eines Ereignisprotokolls behebt keine Ursache und vernichtet möglicherweise wichtige Diagnoseinformationen.

Verfügbare klassische Protokolle anzeigen

[RO] Get-WinEvent -ListLog * |
    Select-Object LogName, RecordCount, IsEnabled

Letzte 50 Systemereignisse

[RO][SENS] Get-WinEvent -LogName System -MaxEvents 50

Fehler und kritische Ereignisse der letzten 24 Stunden

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

Ereignisse einer bestimmten Quelle

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

Bestimmte Ereignis-ID suchen

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 6008
    StartTime = (Get-Date).AddDays(-7)
}

Ergebnisse exportieren

[RO][SENS] Get-WinEvent -LogName System -MaxEvents 500 |
    Export-Csv -Path ".\systemereignisse.csv" -NoTypeInformation -Encoding UTF8

Exportierte Ereignisse können Benutzernamen, Computerbezeichnungen, Pfade, IP-Adressen und Anwendungsdaten enthalten.

Vorteil von FilterHashtable

Die Filterung erfolgt bereits beim Abruf. Das ist bei großen Ereignisprotokollen meist effizienter, als zunächst alle Ereignisse einzulesen und sie anschließend mit Where-Object zu filtern.

Die Ereignis-ID allein ist kein vollständiger Befund. Quelle, Meldung, Zeitpunkt, betroffene Komponente und benachbarte Ereignisse müssen zusätzlich ausgewertet werden.

Ein Ereignis Kernel-Power 41 bestätigt beispielsweise, dass Windows zuvor nicht ordnungsgemäß heruntergefahren wurde. Es beweist jedoch nicht, ob Stromverlust, Hardwarefehler, Absturz, erzwungenes Ausschalten oder eine andere Ursache verantwortlich war.

Zuverlässigkeitsüberwachung öffnen

[RO] perfmon /rel

Der Zuverlässigkeitsverlauf stellt wichtige Ereignisse nach Tagen geordnet dar. Dazu können gehören:

• Anwendungsabstürze
• Windows-Fehler
• fehlgeschlagene Updates
• Treiberinstallationen
• Softwareinstallationen
• erfolgreiche Updates
• Hardwarefehler

Sinnvolle Vorgehensweise

1. Tag und Uhrzeit der Störung auswählen.
2. Kritische Ereignisse untersuchen.
3. Gleichzeitig installierte Updates oder Anwendungen beachten.
4. Technische Details öffnen.
5. Befund mit Ereignisanzeige und Anwendungsprotokollen vergleichen.

Der Stabilitätsindex ist eine verdichtete Kennzahl. Er beweist nicht, welche Komponente die Ursache einer Störung ist.

Task-Manager öffnen

[RO] taskmgr

Wichtige Bereiche

Bei hoher Auslastung prüfen

• Ist die Auslastung dauerhaft oder nur kurzfristig?
• Welcher Prozess verursacht sie?
• Gehört der Prozess zu einer Anwendung oder einem Windows-Dienst?
• Steigt der Speicherverbrauch fortlaufend?
• Liegt die Datenträgeraktivität bei hoher Antwortzeit?
• Wird ein Prozess mehrfach ausgeführt?
• Ist die Auslastung Folge eines Updates, Scans oder Backups?
• Stimmt der Fehlerzeitpunkt mit der Auslastung überein?

Das sofortige Beenden eines unbekannten Prozesses kann Datenverlust verursachen oder Systemfunktionen unterbrechen.

Prozesse anzeigen

[RO][SENS] Get-Process

Prozesse nach CPU-Zeit sortieren

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

CPU enthält die bisher verbrauchte Prozessorzeit und nicht unmittelbar die aktuelle prozentuale CPU-Auslastung.

Prozesse nach Arbeitsspeicher sortieren

[RO][SENS] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Name,
        Id,
        @{Name='RAM_MiB';Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}

Bestimmten Prozess anzeigen

[RO][SENS] Get-Process -Id <PID>

Prozessdetails über CIM

[RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=<PID>" |
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine

Die Befehlszeile kann Pfade, Benutzerdaten, Servernamen oder sogar ungeschützt übergebene Zugangsdaten enthalten.

Prozess kontrolliert beenden

[CHANGE] Stop-Process -Id <PID>

Erzwungenes Beenden

[CHANGE] Stop-Process -Id <PID> -Force

-Force darf nicht als allgemeine Fehlerbehebung verwendet werden. Nicht gespeicherte Daten können verloren gehen und abhängige Komponenten können ausfallen.

Ressourcenmonitor öffnen

[RO] resmon

Der Ressourcenmonitor zeigt detaillierte Informationen zu:

• CPU
• Arbeitsspeicher
• Datenträgeraktivität
• Netzwerkaktivität
• TCP-Verbindungen
• lauschenden Ports
• Prozessen und zugehörigen Dateien

Typische Anwendungsfälle

• Prozess mit hoher Datenträgeraktivität bestimmen
• Datei mit vielen Zugriffen ermitteln
• Prozess hinter einer TCP-Verbindung identifizieren
• lauschenden Port einer Anwendung feststellen
• Hard Faults und Speichernutzung untersuchen
• Abhängigkeiten eines angehaltenen Prozesses betrachten

Ein Hard Fault ist nicht automatisch ein Hardwarefehler. Er bezeichnet in diesem Zusammenhang einen Speicherzugriff, bei dem benötigte Daten nicht im physischen Arbeitsspeicher vorlagen und aus einer anderen Speicherquelle geladen werden mussten.

Leistungsüberwachung öffnen

[RO] perfmon

Die Leistungsüberwachung kann Messwerte in Echtzeit anzeigen oder über Datenkollektorsätze längerfristig erfassen.

Verfügbare Leistungsindikatoren mit PowerShell anzeigen

[RO] Get-Counter -ListSet *

Einzelne Messung durchführen

[TEST] Get-Counter '\Processor(_Total)\% Processor Time'

Mehrere Messwerte erfassen

[TEST] Get-Counter `
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' `
    -SampleInterval 2 `
    -MaxSamples 10

Wichtige Kategorien

Bewertungsregeln

• Einzelmessungen bilden nur einen kurzen Zeitpunkt ab.
• Grenzwerte hängen von Arbeitslast, Hardware und Anwendung ab.
• Durchschnittswerte können kurze Lastspitzen verdecken.
• Eine hohe Warteschlange beweist ohne Latenz- und Durchsatzwerte noch keinen Datenträgerdefekt.
• Prozessinstanzen können sich bei einem Neustart oder mehreren gleichnamigen Prozessen ändern.
• Messung und Fehler müssen zeitlich zusammenpassen.

Diensteverwaltung öffnen

[RO] services.msc

Alle Dienste mit PowerShell anzeigen

[RO] Get-Service

Beendete Dienste anzeigen

[RO] Get-Service |
    Where-Object Status -eq 'Stopped'

Ein beendeter Dienst ist nicht automatisch fehlerhaft. Viele Dienste werden nur bei Bedarf gestartet.

Bestimmten Dienst prüfen

[RO] Get-Service -Name "<DIENSTNAME>"

Ausführlichere Dienstinformationen

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

Dienstkonfiguration mit sc.exe

[RO] sc.exe qc "<DIENSTNAME>"

Dienstabhängigkeiten

[RO] Get-Service -Name "<DIENSTNAME>" -RequiredServices

Abhängige Dienste

[RO] Get-Service -Name "<DIENSTNAME>" -DependentServices

Dienst starten

[CHANGE][PRIV] Start-Service -Name "<DIENSTNAME>"

Dienst neu starten

[CHANGE][PRIV][RESTART] Restart-Service -Name "<DIENSTNAME>"

Vor einem Dienstneustart müssen abhängige Anwendungen, aktive Benutzer, Transaktionen und Auswirkungen auf andere Systeme geprüft werden.

Vollständige IP-Konfiguration

[RO][SENS] ipconfig /all

PowerShell-Netzwerkkonfiguration

[RO][SENS] Get-NetIPConfiguration

IP-Adressen anzeigen

[RO][SENS] Get-NetIPAddress

Netzwerkadapter anzeigen

[RO] Get-NetAdapter |
    Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress

Routingtabelle anzeigen

[RO][SENS] route print

Alternativ:

[RO][SENS] Get-NetRoute |
    Sort-Object InterfaceIndex, DestinationPrefix

DNS-Server anzeigen

[RO][SENS] Get-DnsClientServerAddress

Wichtige Prüfwerte

• erwartete IPv4- oder IPv6-Adresse
• Präfix beziehungsweise Subnetzmaske
• Standardgateway
• DNS-Server
• DHCP-Status
• Adapterstatus
• Verbindungsgeschwindigkeit
• unerwartete virtuelle Adapter
• VPN- oder Hypervisor-Routen
• APIPA-Adresse aus 169.254.0.0/16

Eine APIPA-Adresse kann darauf hinweisen, dass keine erwartete IPv4-Konfiguration per DHCP bezogen wurde. Sie beweist jedoch nicht allein, warum der DHCP-Vorgang scheiterte.

Lokalen TCP/IP-Stack testen

[TEST] ping 127.0.0.1

Standardgateway testen

[TEST] ping <GATEWAY-IP>

Ziel testen

[TEST] ping <ZIEL>

Route zum Ziel verfolgen

[TEST][SENS] tracert <ZIEL>

Verlust und Laufzeit entlang des Pfades untersuchen

[TEST][SENS] pathping <ZIEL>

TCP-Port mit PowerShell testen

[TEST][SENS] Test-NetConnection -ComputerName "<ZIEL>" -Port <PORT>

Beispiel:

[TEST][SENS] Test-NetConnection -ComputerName "server.example" -Port 443

Erweiterte Verbindungsinformationen

[TEST][SENS] Test-NetConnection -ComputerName "<ZIEL>" -DiagnoseRouting -InformationLevel Detailed

Bewertungsregeln

• Ein fehlgeschlagener Ping beweist nicht, dass das Ziel ausgefallen ist.
• ICMP kann gefiltert werden, während ein Anwendungsport erreichbar bleibt.
• Ein erfolgreicher Ping beweist nicht, dass die Anwendung funktioniert.
• Ein erfolgreicher TCP-Test bestätigt die Verbindung zum getesteten Port, aber nicht automatisch eine korrekte Anwendungssitzung.
• Zeitüberschreitungen bei tracert können durch gefilterte Antworten entstehen.
• Paketverlust an einem Zwischenknoten ist nur dann aussagekräftig, wenn er sich bis zum Ziel fortsetzt.

DNS-Abfrage mit PowerShell

[TEST][SENS] Resolve-DnsName "<HOSTNAME>"

Bestimmten DNS-Server abfragen

[TEST][SENS] Resolve-DnsName "<HOSTNAME>" -Server "<DNS-SERVER>"

Klassische DNS-Abfrage

[TEST][SENS] nslookup <HOSTNAME>

DNS-Clientcache anzeigen

[RO][SENS] Get-DnsClientCache

Alternativ:

[RO][SENS] ipconfig /displaydns

DNS-Clientcache leeren

[CHANGE][PRIV] Clear-DnsClientCache

Alternativ:

[CHANGE][PRIV] ipconfig /flushdns

Typische Fehlerquellen

• falscher DNS-Server
• falscher oder abgelaufener DNS-Eintrag
• Suchsuffix fehlt
• Split-DNS liefert abhängig vom Standort andere Antworten
• VPN überschreibt DNS-Einstellungen
• lokaler Cache enthält einen alten Eintrag
• Hosts-Datei überschreibt DNS
• Firewall blockiert DNS-Abfragen
• IPv4- und IPv6-Antworten führen zu unterschiedlichen Pfaden

Das Leeren des DNS-Caches sollte nur erfolgen, wenn ein veralteter lokaler Cache als Ursache infrage kommt. Es behebt keine falschen Einträge auf dem DNS-Server.

TCP-Verbindungen anzeigen

[RO][SENS] Get-NetTCPConnection

Lauschende TCP-Ports

[RO][SENS] Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess

Zugehörigen Prozess bestimmen

[RO][SENS] Get-Process -Id <PID>

Klassische Portübersicht

[RO][SENS] netstat -ano

Lauschende Ports

[RO][SENS] netstat -ano | findstr LISTENING

Ausführbare Programme einbeziehen

[RO][PRIV][SENS] netstat -abno

UDP-Endpunkte

[RO][SENS] Get-NetUDPEndpoint |
    Sort-Object LocalPort

Wichtige Zustände

Ein offener Hostport beweist noch nicht, dass die Anwendung fachlich korrekt arbeitet. Zusätzlich müssen Protokoll, Antwort und gegebenenfalls Authentifizierung getestet werden.

Firewallprofile anzeigen

[RO] Get-NetFirewallProfile |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Aktivierte Firewallregeln anzeigen

[RO][SENS] Get-NetFirewallRule -Enabled True |
    Select-Object DisplayName, Direction, Action, Profile

Regeln anhand eines Namens suchen

[RO][SENS] Get-NetFirewallRule |
    Where-Object DisplayName -Like '*<SUCHBEGRIFF>*'

Firewallverwaltung öffnen

[RO] wf.msc

Typische Prüfpunkte

• aktives Netzwerkprofil
• Eingangs- oder Ausgangsrichtung
• erlaubende und blockierende Regeln
• lokaler Port und Remoteport
• lokales und entferntes Adressnetz
• zugeordnetes Programm oder Dienst
• Domänen-, privates oder öffentliches Profil
• zentral durch Gruppenrichtlinie verwaltete Regeln

Die Firewall darf nicht pauschal deaktiviert werden, um ein Verbindungsproblem zu testen. Stattdessen muss die konkrete Verbindung mit passender Protokollierung und eng begrenzten Regeln untersucht werden.

Volumes anzeigen

[RO] Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  FileSystem,
                  HealthStatus,
                  SizeRemaining,
                  Size

Datenträger anzeigen

[RO] Get-Disk

Partitionen anzeigen

[RO] Get-Partition

Freien Speicher übersichtlich berechnen

[RO] Get-Volume |
    Where-Object DriveLetter |
    Select-Object DriveLetter,
        FileSystemLabel,
        @{Name='Frei_GiB';Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}},
        @{Name='Gesamt_GiB';Expression={[math]::Round($_.Size / 1GB, 2)}}

Datenträgerverwaltung öffnen

[RO] diskmgmt.msc

Dateisystem online prüfen

[TEST][PRIV] chkdsk C: /scan

Wichtige Unterscheidungen

• Freier Speicherplatz ist nicht dasselbe wie Datenträgerzustand.
• Ein Zustand Healthy schließt nicht jede Hardwarestörung aus.
• Ein voller Datenträger kann Updates, Protokollierung, Datenbanken und Benutzeranmeldungen beeinträchtigen.
• Eine hohe Datenträgerauslastung bedeutet nicht automatisch, dass das Laufwerk defekt ist.
• Dateisystemfehler, Hardwarefehler, Controllerprobleme und Anwendungs-I/O müssen getrennt untersucht werden.

Reparaturoptionen wie chkdsk /f oder /r können lange Laufzeiten, exklusive Datenträgerzugriffe oder einen Neustart erfordern. Sie dürfen nicht ohne Sicherung und Wartungsplanung eingesetzt werden.

Grundlegende Speicherinformationen

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object @{
        Name='Gesamt_GiB'
        Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)}
    }, @{
        Name='Frei_GiB'
        Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)}
    }

Installierte Speichermodule

[RO][SENS] Get-CimInstance Win32_PhysicalMemory |
    Select-Object BankLabel,
                  DeviceLocator,
                  Capacity,
                  Speed,
                  Manufacturer,
                  PartNumber

Windows-Speicherdiagnose öffnen

[TEST][RESTART] mdsched.exe

Die Speicherdiagnose bietet normalerweise einen Test beim nächsten Neustart oder einen sofortigen Neustart mit anschließender Prüfung an.

Ein Speicherdiagnosetest unter Last oder ein einzelner erfolgreicher Durchlauf schließt sporadische Hardwarefehler nicht zwingend aus.

Geräte-Manager öffnen

[RO] devmgmt.msc

Vorhandene Plug-and-Play-Geräte

[RO][SENS] Get-PnpDevice

Geräte mit Fehlerstatus

[RO][SENS] Get-PnpDevice |
    Where-Object Status -ne 'OK'

Installierte Treiber

[RO][SENS] driverquery /v

Signierte Treiber mit PowerShell

[RO][SENS] Get-CimInstance Win32_PnPSignedDriver |
    Select-Object DeviceName,
                  DriverVersion,
                  DriverDate,
                  Manufacturer,
                  InfName

Typische Prüfpunkte

• Gerätestatus und Fehlercode
• Treiberversion und Treiberdatum
• kürzlich erfolgte Treiberänderung
• unbekannte oder deaktivierte Geräte
• Hardware-ID
• Herstellerfreigabe für die Windows-Version
• Zusammenhang zwischen Treiberinstallation und Fehlerzeitpunkt

Ein neuerer Treiber ist nicht automatisch geeigneter. Entscheidend sind Hardwaremodell, Betriebssystemversion und Freigabe durch Hersteller oder Geräteanbieter.

Autostartprogramme über CIM anzeigen

[RO][SENS] Get-CimInstance Win32_StartupCommand |
    Select-Object Name, Command, Location, User

Aufgabenplanung öffnen

[RO] taskschd.msc

Geplante Aufgaben anzeigen

[RO][SENS] Get-ScheduledTask |
    Select-Object TaskPath, TaskName, State

Aufgaben mit letztem Ergebnis

[RO][SENS] Get-ScheduledTask | ForEach-Object {
    $info = $_ | Get-ScheduledTaskInfo
    [PSCustomObject]@{
        TaskPath       = $_.TaskPath
        TaskName       = $_.TaskName
        State          = $_.State
        LastRunTime    = $info.LastRunTime
        LastTaskResult = $info.LastTaskResult
        NextRunTime    = $info.NextRunTime
    }
}

Systemkonfiguration öffnen

[RO] msconfig

Autostarteinträge und geplante Aufgaben dürfen nicht wahllos deaktiviert werden. Sie können zu Sicherheitssoftware, Backups, Updates, Treibern oder geschäftskritischen Anwendungen gehören.

Installierte Hotfixes anzeigen

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

Updateverlauf in den Einstellungen

Einstellungen
→ Windows Update
→ Updateverlauf

Windows-Update-Ereignisse abrufen

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

Typische Prüfpunkte

• Zeitpunkt der Installation
• KB-Nummer
• erfolgreicher oder fehlgeschlagener Abschluss
• erforderlicher Neustart
• Treiberupdate
• bekannte Abhängigkeit zur betroffenen Anwendung
• wiederholt fehlgeschlagene Installation
• ausreichend freier Speicher
• Richtlinien oder Updateverwaltung im Unternehmen

Ein zeitlicher Zusammenhang zwischen Update und Fehler ist ein wichtiger Hinweis, aber noch kein Ursachennachweis. Vor einer Deinstallation müssen bekannte Probleme, Sicherheitsfolgen und Herstellerangaben geprüft werden.

Der System File Checker überprüft geschützte Windows-Systemdateien und kann beschädigte Dateien ersetzen.

Systemdateien prüfen und reparieren

[CHANGE][PRIV] sfc /scannow

Nur eine bestimmte Datei prüfen

[TEST][PRIV] sfc /verifyfile="<VOLLSTÄNDIGER_PFAD>"

Nur prüfen, ohne Reparatur

[TEST][PRIV] sfc /verifyonly

Mögliche Ergebnisse

• Keine Integritätsverletzungen gefunden
• Beschädigte Dateien gefunden und erfolgreich repariert
• Beschädigte Dateien gefunden, aber nicht alle repariert
• Prüfung konnte nicht ausgeführt werden

SFC-Einträge aus dem CBS-Protokoll filtern

[RO][PRIV][SENS] findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log

SFC ist kein universelles Reparaturprogramm. Es untersucht geschützte Windows-Systemdateien, nicht automatisch Anwendungsdateien, Benutzerdaten, Hardware oder sämtliche Konfigurationen.

DISM kann den Zustand des Windows-Abbilds beziehungsweise Komponentenspeichers untersuchen und reparieren.

Schnelle Statusprüfung

[RO][PRIV] DISM /Online /Cleanup-Image /CheckHealth

Ausführliche Prüfung

[TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth

Windows-Abbild reparieren

[CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth

Bedeutung der Parameter

Wichtige Hinweise

• /RestoreHealth verändert den Systemzustand.
• Der Vorgang kann längere Zeit dauern.
• Eine Reparaturquelle kann erforderlich sein.
• Die Quelle muss zum installierten Windows passen.
• Fehler müssen anhand des DISM-Protokolls ausgewertet werden.
• Nach erfolgreicher Reparatur kann eine erneute SFC-Prüfung sinnvoll sein.

DISM-Protokoll

C:\Windows\Logs\DISM\dism.log

CBS-Protokoll

C:\Windows\Logs\CBS\CBS.log

DISM und SFC dürfen nicht reflexartig bei jedem Windows-Problem ausgeführt werden. Zuerst sollte ein Zusammenhang mit beschädigten Windows-Komponenten oder Systemdateien begründet werden.

Angewendete Richtlinien anzeigen

[RO][SENS] gpresult /r

Ausführlichen HTML-Bericht erzeugen

[RO][SENS] gpresult /h ".\gpresult.html"

Resultant Set of Policy öffnen

[RO][SENS] rsop.msc

Gruppenrichtlinien-Ereignisse

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-GroupPolicy/Operational' `
    -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Gruppenrichtlinien aktualisieren

[CHANGE][PRIV] gpupdate /force

gpupdate /force kann Richtlinien erneut anwenden, Anmelde- oder Neustartanforderungen auslösen und den Arbeitszustand beeinflussen. Der Befehl ist kein Ersatz für die Analyse einer fehlerhaften Richtlinie.

Aktuellen Benutzer anzeigen

[RO] whoami

Gruppen und Sicherheitskennungen anzeigen

[RO][SENS] whoami /groups

Aktuelle Berechtigungen anzeigen

[RO][SENS] whoami /priv

Angemeldete Sitzungen

[RO][SENS] query user

Lokale Benutzer anzeigen

[RO][SENS] Get-LocalUser

Lokale Gruppenmitgliedschaften

[RO][SENS] Get-LocalGroupMember -Group "<GRUPPENNAME>"

Kerberos-Tickets anzeigen

[RO][SENS] klist

Typische Ursachen kontextabhängiger Fehler

• anderer Benutzer
• fehlende Gruppenmitgliedschaft
• nicht aktualisiertes Zugriffstoken
• lokale statt Domänenanmeldung
• abgelaufenes oder fehlendes Kerberos-Ticket
• Dienst läuft unter anderem Konto
• unterschiedliche Umgebungsvariablen
• abweichendes Benutzerprofil
• erhöhte und nicht erhöhte Sitzung besitzen unterschiedliche Rechte

Ein erfolgreicher Test als Administrator beweist nicht, dass die Funktion für den vorgesehenen Benutzer korrekt berechtigt ist.

SMB-Freigaben anzeigen

[RO][SENS] Get-SmbShare

Bestehende SMB-Verbindungen

[RO][SENS] Get-SmbConnection

Erreichbarkeit von SMB testen

[TEST][SENS] Test-NetConnection -ComputerName "<SERVER>" -Port 445

Remotedesktopport testen

[TEST][SENS] Test-NetConnection -ComputerName "<SERVER>" -Port 3389

WinRM-Konfiguration anzeigen

[RO][SENS] winrm get winrm/config

WinRM-Verbindung testen

[TEST][SENS] Test-WSMan -ComputerName "<SERVER>"

Wichtige Unterscheidung

Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der getestete Port erreichbar ist. Sie bestätigt nicht automatisch:

• erfolgreiche Authentifizierung
• korrekte Freigabeberechtigung
• NTFS-Berechtigung
• funktionierende Remotedesktopsitzung
• gültiges Zertifikat
• erfolgreiche Anwendungskommunikation

Windows kann bei System- oder Anwendungsabstürzen Speicherabbilder erzeugen.

Typische Speicherorte

C:\Windows\MEMORY.DMP
C:\Windows\Minidump\
%LOCALAPPDATA%\CrashDumps\

Die tatsächliche Konfiguration und der Speicherort können abweichen.

Start- und Wiederherstellungseinstellungen öffnen

[RO] sysdm.cpl

Danach:

Erweitert
→ Starten und Wiederherstellen
→ Einstellungen

Typische Abbildarten

Wichtige Sicherheitsregel

Speicherabbilder können enthalten:

• Benutzerdaten
• Dateiinhalte
• Prozessspeicher
• Schlüsselmaterial
• Tokens
• Passwörter oder andere Geheimnisse
• Netzwerk- und Sitzungsinformationen

Speicherabbilder müssen wie sensible Diagnosedaten behandelt und dürfen nicht ungeprüft weitergegeben werden.

Zur detaillierten Analyse kann Microsoft WinDbg eingesetzt werden. WinDbg wird auf einer späteren Seite zusammen mit weiteren spezialisierten Werkzeugen behandelt.

Der abgesicherte Modus startet Windows mit einer eingeschränkten Auswahl von Treibern und Diensten. Damit kann geprüft werden, ob ein Fehler durch zusätzliche Software, Treiber oder Autostartkomponenten beeinflusst wird.

Ein sauberer Systemstart deaktiviert gezielt nicht benötigte Dienste und Autostartprogramme, um Konflikte einzugrenzen.

Systemkonfiguration öffnen

[CHANGE][RESTART] msconfig

Wichtige Risiken

• Sicherheits- oder Verwaltungssoftware kann vorübergehend deaktiviert werden.
• Geschäftsanwendungen oder Hintergrunddienste können ausfallen.
• Änderungen müssen dokumentiert und anschließend zurückgenommen werden.
• Abgesicherter Modus und sauberer Start sind Diagnosezustände, keine dauerhafte Lösung.
• In verwalteten Umgebungen kann eine Freigabe erforderlich sein.

Geeignete Fragestellung

Tritt der Fehler auch mit einer minimalen Auswahl von Treibern,
Diensten und Autostartprogrammen auf?

Ein ausbleibender Fehler grenzt die Ursache ein, identifiziert aber noch nicht automatisch die verantwortliche Komponente.

Vor einer Ferndiagnose müssen geklärt werden:

• korrekter Zielcomputer
• berechtigte Person
• Wartungs- oder Diagnosefenster
• Auswirkungen auf aktive Benutzer
• erlaubte Werkzeuge
• Speicherort der Diagnosedaten
• Schutz sensibler Informationen
• Rückfallplan für Änderungen

Computername prüfen

[RO] $env:COMPUTERNAME

Benutzerkontext prüfen

[RO] whoami

PowerShell-Remotesitzung testen

[TEST][SENS] Test-WSMan -ComputerName "<COMPUTER>"

Befehl remote ausführen

[RO][SENS] Invoke-Command -ComputerName "<COMPUTER>" -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem |
        Select-Object Caption, Version, LastBootUpTime
}

Remoteausgaben, Transkripte und Diagnosearchive können sensible Daten enthalten. Sie müssen zweckgebunden gespeichert, geschützt und nach den geltenden Vorgaben gelöscht werden.

Vor einer Änderung prüfen

1. Ist die Ursache ausreichend eingegrenzt?
2. Welche Systeme und Benutzer sind betroffen?
3. Existiert eine aktuelle Sicherung?
4. Ist die Maßnahme reversibel?
5. Welche Abhängigkeiten bestehen?
6. Ist ein Neustart erforderlich?
7. Gibt es ein Wartungsfenster?
8. Wie wird die Funktion anschließend getestet?
9. Wie wird die Änderung dokumentiert?

1. Betroffenen Computer und Benutzer eindeutig bestimmen.
2. Originale Fehlermeldung und Fehlerzeitpunkt erfassen.
3. Umfang und Reproduzierbarkeit prüfen.
4. Windows-Version, Build und letzte Startzeit erfassen.
5. Änderungen, Updates und Installationen vor dem Fehler feststellen.
6. Ereignisanzeige und Zuverlässigkeitsverlauf zum Fehlerzeitpunkt prüfen.
7. Prozesse, Dienste und aktuelle Ressourcenbelastung untersuchen.
8. Freien Speicherplatz und Datenträgerzustand kontrollieren.
9. Netzwerk, DNS, Route und benötigte Ports getrennt testen.
10. Benutzerkontext, Berechtigungen und Richtlinien berücksichtigen.
11. Treiber, Geräte und Abhängigkeiten prüfen.
12. Erkenntnisse aus mehreren Datenquellen abgleichen.
13. Sicherung und Rückfallplan kontrollieren.
14. Kleinste geeignete Änderung durchführen.
15. Interne und externe Funktionsprüfung ausführen.
16. Ereignisse und Ressourcen nach der Maßnahme erneut prüfen.
17. Ursache, Maßnahme und Ergebnis dokumentieren.

Ticket:
Datum und Uhrzeit:
Bearbeiter:

Computername:
Windows-Edition:
Windows-Version:
Build:
Architektur:
Letzter Systemstart:
Benutzerkontext:
Domäne oder Arbeitsgruppe:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Erstmals aufgetreten:
Reproduzierbar:
Betroffene Benutzer:
Betroffene Anwendung oder Funktion:
Umfang der Störung:
Letzte funktionierende Nutzung:

Letzte Änderung:
Installierte Updates:
Treiberänderung:
Softwareinstallation:
Richtlinienänderung:

Relevante Ereignisquellen:
Ereignis-IDs:
Zuverlässigkeitsverlauf:
Betroffene Prozesse:
Betroffene Dienste:
CPU:
Arbeitsspeicher:
Datenträger:
Freier Speicher:

IP-Konfiguration:
DNS:
Standardgateway:
Getestetes Ziel:
Getesteter Port:
Testergebnis:
Firewallprofil:
Firewallregel:

Gerätestatus:
Treiberversion:
Systemdateiprüfung:
DISM-Status:
Absturzabbild:
Sensible Daten redigiert:

Vermutete Ursache:
Durchgeführte Tests:
Sicherung geprüft:
Geplante Änderung:
Erwartete Auswirkung:
Rückfallplan:
Neustart erforderlich:

Ergebnis nach der Maßnahme:
Interne Funktionsprüfung:
Externe Funktionsprüfung:
Monitoring:
Weiterführende Maßnahmen:

Die Sysinternals-Werkzeuge wurden ursprünglich von Mark Russinovich und Bryce Cogswell entwickelt. Microsoft übernahm Sysinternals im Jahr 2006 und stellt die Werkzeuge weiterhin bereit.

Die Sammlung besteht überwiegend aus kleinen, spezialisierten Programmen. Viele davon müssen nicht klassisch installiert werden und können nach dem Entpacken direkt gestartet werden.

Wichtige Werkzeuggruppen

Abgrenzung

Sysinternals ist:

• keine automatische Reparatursuite
• kein Ersatz für ein Antiviren- oder EDR-System
• kein Ersatz für ein zentrales Monitoring
• kein vollständiger Debugger
• kein Beweiswerkzeug, das aus einer einzelnen Auffälligkeit automatisch die Ursache bestimmt

Die Werkzeuge ergänzen Ereignisanzeige, Task-Manager, Ressourcenmonitor, Leistungsüberwachung, PowerShell und spezialisierte Debuggingprogramme.

Sysinternals-Werkzeuge sollten ausschließlich aus vertrauenswürdigen Microsoft-Quellen bezogen werden.

Offizielle Möglichkeiten

1. Einzelwerkzeuge über Microsoft Learn herunterladen
2. vollständige Sysinternals Suite herunterladen
3. Sysinternals Suite aus dem Microsoft Store installieren
4. Werkzeuge über Sysinternals Live ausführen

Sysinternals Suite

Die Suite enthält einen großen Teil der Diagnosewerkzeuge in einem gemeinsamen Archiv. Für bestimmte Plattformen stellt Microsoft unterschiedliche Pakete bereit, darunter x64 und ARM64.

Microsoft Store

Bei der Store-Version werden grafische Programme im Startmenü eingetragen. Die Befehlszeilenprogramme können über App-Ausführungsaliase aufgerufen werden.

Sysinternals Live

Ein Werkzeug kann direkt von Sysinternals Live gestartet werden:

[TEST][SENS] \\live.sysinternals.com\tools\procexp.exe

Beispiel für Process Monitor:

[TEST][SENS] \\live.sysinternals.com\tools\procmon.exe

Dabei müssen Netzwerkzugriff, Proxy, Firewall, Namensauflösung und die Sicherheitsrichtlinien der Organisation berücksichtigt werden.

In kontrollierten Unternehmensumgebungen sollte nicht ungeprüft eine ausführbare Datei direkt aus dem Internet gestartet werden. Besser ist häufig ein freigegebenes, geprüftes und versioniertes internes Werkzeugverzeichnis.

Vor dem Einsatz sollte geprüft werden:

• stammt die Datei von Microsoft?
• ist die digitale Signatur gültig?
• stimmt die erwartete Architektur?
• wurde die Datei aus einem freigegebenen Speicherort bezogen?
• ist die Werkzeugversion dokumentiert?
• wurde die Datei durch die Sicherheitssoftware geprüft?

Digitale Signatur mit PowerShell kontrollieren

[RO] Get-AuthenticodeSignature ".\procexp.exe" |
    Select-Object Status, StatusMessage, SignerCertificate

Dateihash berechnen

[RO] Get-FileHash ".\procexp.exe" -Algorithm SHA256

Der Hash kann zur internen Dokumentation und zum Vergleich identischer Werkzeugstände verwendet werden. Ein Hash beweist allein jedoch nicht, dass eine Datei vertrauenswürdig ist.

Sysinternals Sigcheck verwenden

[RO] sigcheck.exe -a -h -i ".\procexp.exe"

Typische Informationen können sein:

• Dateiversion
• Herausgeber
• digitale Signatur
• Zertifikatskette
• Zeitstempel
• kryptografischer Hash
• Dateibeschreibung
• Produktname

Eine gültige Signatur bestätigt die signierte Herkunft und Dateiintegrität innerhalb der Signaturprüfung. Sie beweist nicht automatisch, dass jede ausgeführte Funktion im konkreten Einsatz sicher oder erwünscht ist.

Vor dem Start eines Sysinternals-Werkzeugs sollte feststehen:

1. Welcher Fehler wird untersucht?
2. Welcher Computer ist betroffen?
3. Welcher Benutzerkontext ist betroffen?
4. Wann tritt der Fehler auf?
5. Welches Werkzeug kann die benötigte Beobachtung liefern?
6. Welche Daten können bei der Aufzeichnung entstehen?
7. Ist eine erhöhte Ausführung erforderlich?
8. Wie groß kann die Protokolldatei werden?
9. Wo wird sie geschützt gespeichert?
10. Wann wird die Aufzeichnung beendet?
11. Wie werden sensible Daten redigiert?
12. Welche Änderung muss anschließend zurückgenommen werden?

Grundregeln

• zuerst beobachten, dann verändern
• Filter vor längeren Aufzeichnungen vorbereiten
• Zeitpunkt und Reproduktionsschritte dokumentieren
• keine Prozesse oder Handles auf Verdacht beenden
• keine unbekannten Autostarts ungeprüft löschen
• keine Diagnosedateien öffentlich hochladen
• keine Remoteausführung ohne Freigabe
• nur den erforderlichen Berechtigungskontext verwenden
• Werkzeugversion und Befehlszeile dokumentieren
• nach jeder Änderung die betroffene Funktion erneut prüfen

Process Explorer zeigt Prozesse hierarchisch an und liefert detaillierte Informationen zu:

• Prozessname und PID
• übergeordnetem Prozess
• Benutzerkonto
• CPU- und Speicherauslastung
• Handles
• geladenen DLLs
• Speicherabbildern
• Threads
• TCP/IP-Aktivität
• Dateipfad
• Befehlszeile
• digitaler Signatur
• Integritätsstufe
• Sicherheitskontext
• Prozessstartzeit

Starten

[RO][SENS] procexp.exe

Für vollständige Informationen über Systemprozesse können erhöhte Rechte erforderlich sein:

[RO][PRIV][SENS] procexp.exe

Wichtige Funktionen

Typische Anwendungsfälle

• Welcher Prozess hält eine Datei geöffnet?
• Welche Anwendung hat einen Unterprozess gestartet?
• Unter welchem Konto läuft ein Prozess?
• Welche DLL wurde aus einem unerwarteten Pfad geladen?
• Welcher Thread erzeugt hohe CPU-Last?
• Stimmen Dateiname, Pfad und Herausgeber zusammen?
• Ist ein Prozess mehrfach vorhanden?
• Läuft ein Prozess mit erhöhten Rechten?

Prozessfarben

Process Explorer kann unterschiedliche Prozesstypen farblich kennzeichnen. Die genaue Bedeutung hängt von der konfigurierten Farbauswahl ab und sollte über die Programmeinstellungen kontrolliert werden.

Eine Farbe oder ein nicht verifizierter Signaturstatus ist kein automatischer Malware-Nachweis.

Wenn eine Datei nicht gelöscht, verschoben oder ersetzt werden kann, kann ein geöffneter Handle dafür verantwortlich sein.

Vorgehensweise

1. Process Explorer starten.
2. Find öffnen.
3. Find Handle or DLL auswählen.
4. eindeutigen Teil des Datei- oder Verzeichnisnamens eingeben.
5. Treffer und zugehörigen Prozess prüfen.
6. Anwendung möglichst regulär schließen.
7. Dateioperation erneut testen.

Nicht als erste Maßnahme verwenden

• Prozess sofort beenden
• Handle direkt schließen
• Dienst ungeprüft stoppen
• Systemprozess beenden
• Datei mit Gewalt löschen

Das direkte Schließen eines Handles kann den Zustand der Anwendung beschädigen, Datenverlust verursachen oder zu einem späteren Absturz führen.

Die sichere Lösung besteht normalerweise darin, die verursachende Anwendung oder den zugehörigen Dienst kontrolliert zu beenden.

Handle zeigt offene Handles von Prozessen an. Damit kann unter anderem ermittelt werden, welcher Prozess eine bestimmte Datei oder ein Verzeichnis verwendet.

Nach einem Dateinamen suchen

[RO][PRIV][SENS] handle.exe "<DATEINAME>"

Beispiel

[RO][PRIV][SENS] handle.exe "datenbank.db"

Handles eines bestimmten Prozesses anzeigen

[RO][PRIV][SENS] handle.exe -p <PID>

Ausgabe ohne Banner

[RO][PRIV][SENS] handle.exe -nobanner "<SUCHBEGRIFF>"

Handle schließen

[CHANGE][PRIV][DANGER] handle.exe -c <HANDLE-ID> -p <PID>

Das erzwungene Schließen eines Handles kann Daten beschädigen oder einen Prozess destabilisieren. Diese Funktion darf nur verwendet werden, wenn Objekt, Prozess, Abhängigkeiten und Auswirkungen eindeutig bekannt sind.

Process Monitor, kurz Procmon, zeichnet in Echtzeit unter anderem folgende Aktivitäten auf:

• Dateisystemzugriffe
• Registryzugriffe
• Prozessstarts und Prozessbeendigungen
• Threadaktivitäten
• Laden von DLLs und Images
• Profilierungsereignisse
• Prozess-, Benutzer- und Sitzungsinformationen
• zugehörige Aufrufstapel

Starten

[TEST][PRIV][SENS] procmon.exe

Process Monitor beginnt normalerweise unmittelbar mit der Aufzeichnung. Deshalb sollte die Aufzeichnung zunächst angehalten und gezielt vorbereitet werden.

Empfohlene Grundreihenfolge

1. Process Monitor starten.
2. Aufzeichnung anhalten.
3. bestehende Ereignisse leeren.
4. passende Filter festlegen.
5. Aufzeichnung starten.
6. Fehler möglichst genau reproduzieren.
7. Aufzeichnung sofort wieder anhalten.
8. relevante Ereignisse untersuchen.
9. Aufzeichnung im nativen PML-Format sichern.
10. sensible Inhalte vor einer Weitergabe prüfen.

Typische Filter

Process Monitor zeichnet sehr viele normale und erwartete Vorgänge auf. Einzelne Meldungen wie NAME NOT FOUND, PATH NOT FOUND oder ACCESS DENIED sind nicht automatisch Fehlerursachen.

Häufige Ergebnisse

Bewertungsfragen

• Gehört das Ereignis zum betroffenen Prozess?
• Liegt es unmittelbar vor dem sichtbaren Fehler?
• Wird nach einem fehlgeschlagenen Zugriff ein anderer Pfad erfolgreich verwendet?
• Wiederholt sich das Ereignis ungewöhnlich häufig?
• Ist der Pfad laut Anwendung tatsächlich erforderlich?
• Welcher Benutzer führt den Zugriff aus?
• Welche Berechtigungen gelten für das Objekt?
• Handelt es sich um eine optionale Suche der Anwendung?
• Gibt es einen zugehörigen Stack oder Folgefehler?
• Tritt das Verhalten auf einem funktionierenden Vergleichssystem ebenfalls auf?

Wichtiger Grundsatz

Viele Programme suchen nacheinander an mehreren Stellen nach Dateien oder Registrywerten. Mehrere fehlgeschlagene Suchvorgänge können deshalb völlig normal sein, wenn anschließend ein erfolgreicher Treffer erfolgt.

Process Monitor unterstützt Befehlszeilenoptionen für reproduzierbare Aufzeichnungen.

Lizenzdialog vorab akzeptieren

[CHANGE] procmon.exe /AcceptEula

Aufzeichnung mit Sicherungsdatei starten

[TEST][PRIV][SENS] procmon.exe /AcceptEula /Quiet /BackingFile "C:\Diagnose\trace.pml"

Laufende Process-Monitor-Instanz beenden

[CHANGE][PRIV] procmon.exe /Terminate

Gespeicherte PML-Datei als CSV exportieren

[RO][SENS] procmon.exe /OpenLog "C:\Diagnose\trace.pml" /SaveAs "C:\Diagnose\trace.csv"

Bootaufzeichnung

Process Monitor besitzt eine Boot-Logging-Funktion, mit der Aktivitäten während des Systemstarts erfasst werden können. Diese muss über die Programmoberfläche oder passend geplante Optionen kontrolliert aktiviert und anschließend wieder beendet werden.

Bootaufzeichnungen können sehr groß werden und sensible Systeminformationen enthalten. Sie dürfen nicht unbegrenzt aktiviert bleiben.

Autoruns zeigt deutlich mehr Autostartorte als die einfache Autostartansicht des Task-Managers.

Dazu können gehören:

• Anmeldeautostarts
• Dienste
• Treiber
• geplante Aufgaben
• Explorer-Erweiterungen
• Winlogon-Komponenten
• Boot-Execute-Einträge
• Codecs
• AppInit-DLLs
• Image Hijacks
• Office-Erweiterungen
• Winsock-Komponenten
• bekannte Registry-Autostartorte
• Startordner verschiedener Benutzer

Starten

[RO][PRIV][SENS] autoruns.exe

Wichtige Funktionen

Sicheres Deaktivieren

Ein Kontrollkästchen kann deaktiviert werden, um einen Autostart vorübergehend abzuschalten. Das ist in der Regel besser reversibel als das sofortige Löschen des Eintrags.

Eintrag deaktivieren
→ System oder Anwendung kontrolliert testen
→ Ergebnis dokumentieren
→ Eintrag bei ausbleibender Wirkung wieder aktivieren

Ein unbekannter oder nicht signierter Autostarteintrag ist nicht automatisch schädlich. Vor einer Änderung müssen Pfad, Herausgeber, Signatur, Zweck, Abhängigkeiten und betroffene Anwendung geprüft werden.

Autorunsc ist die Befehlszeilenversion von Autoruns und eignet sich für dokumentierbare Bestandsaufnahmen.

Grundlegende Ausgabe

[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s

Dabei können abhängig von der Werkzeugversion und den gewählten Optionen unter anderem Autostartkategorie, Pfad, Signatur und Hash ausgegeben werden.

CSV-Datei erzeugen

[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s > "C:\Diagnose\autoruns.csv"

Nur Microsoft-Einträge ausblenden

[RO][PRIV][SENS] autorunsc.exe -a * -m -c -h -s

Vor einer produktiven Erfassung prüfen

[RO] autorunsc.exe /?

Die verfügbaren Parameter können sich mit Werkzeugversionen verändern. Vor automatisierter Verwendung muss die Hilfe der tatsächlich eingesetzten Version geprüft werden.

Mehrere Sysinternals-Werkzeuge können Hashwerte oder Dateien mit VirusTotal abgleichen.

Dabei muss unterschieden werden zwischen:

• Übermittlung eines Hashwertes
• Abfrage eines bereits bekannten Ergebnisses
• Hochladen einer unbekannten Datei
• automatischer Übermittlung unbekannter Dateien

Mögliche Risiken

• interne Dateinamen werden offengelegt
• proprietäre Anwendungen werden hochgeladen
• Konfigurationsdateien enthalten Geschäftsgeheimnisse
• Dateien enthalten personenbezogene Daten
• Skripte enthalten Servernamen oder Zugangsdaten
• Upload verstößt gegen Unternehmensrichtlinien

Die Übermittlung einer internen Datei an einen externen Analysedienst darf nicht automatisch erfolgen. Vorher müssen Datenschutz, Geheimhaltung, Eigentumsrechte und Sicherheitsvorgaben geprüft werden.

Ein VirusTotal-Ergebnis ist außerdem kein alleiniger Beweis:

• einzelne Erkennung kann ein Fehlalarm sein
• keine Erkennung schließt Schadsoftware nicht aus
• Bewertung kann sich später ändern
• signierte Dateien können trotzdem missbraucht werden

TCPView zeigt aktive TCP- und UDP-Endpunkte mit den zugehörigen Prozessen an.

Starten

[RO][PRIV][SENS] tcpview.exe

Typische Informationen

• Prozessname
• PID
• Protokoll
• lokale Adresse
• lokaler Port
• entfernte Adresse
• Remoteport
• TCP-Zustand
• gesendete und empfangene Daten
• Erstellungszeitpunkt einer Verbindung

Typische Anwendungsfälle

• Welcher Prozess verbindet sich mit einem Server?
• Welcher Prozess lauscht auf einem Port?
• Warum existieren unerwartet viele Verbindungen?
• Welche Remoteadresse verwendet eine Anwendung?
• Ist der erwartete Dienstport geöffnet?
• Welche Verbindung wird beim Start einer Anwendung aufgebaut?

Befehlszeilenversion

[RO][PRIV][SENS] tcpvcon.exe -a -c

Vor der Verwendung sollte die lokale Hilfe geprüft werden:

[RO] tcpvcon.exe /?

Eine Verbindung zu einer unbekannten IP-Adresse ist kein automatischer Sicherheitsvorfall. Content-Delivery-Netzwerke, Cloudplattformen, Telemetrie, Updates, Proxys und gemeinsam genutzte Infrastrukturen können die Zuordnung erschweren.

RAMMap zeigt, wie Windows den physischen Arbeitsspeicher verwendet.

Starten

[RO][PRIV][SENS] rammap.exe

Wichtige Ansichten

Wichtige Speicherbegriffe

Bewertungsregeln

• Wenig vollständig freier RAM ist nicht automatisch problematisch.
• Windows nutzt freien Speicher gezielt als Cache.
• Ein großer Standby-Bereich kann normal sein.
• Hohe Commit-Nutzung muss zusammen mit Commit-Limit und Auslagerungsdatei bewertet werden.
• Ein ungewöhnlich großer nicht ausgelagerter Pool kann auf einen Treiberfehler hindeuten.
• Ein einzelner Snapshot beweist noch kein Speicherleck.

RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Speicherzustand und können die Leistung vorübergehend verschlechtern.

Speicherlisten dürfen nicht routinemäßig geleert werden, nur um eine niedrigere RAM-Anzeige zu erzeugen. Dadurch wird die Ursache eines Speicherproblems nicht behoben.

VMMap analysiert den virtuellen und physischen Speicher eines einzelnen Prozesses.

Starten

[RO][PRIV][SENS] vmmap.exe

Anschließend wird ein laufender Prozess ausgewählt oder eine Anwendung durch VMMap gestartet.

Untersuchte Speicherarten

• Image
• Heap
• Stack
• Private Data
• Shareable
• Mapped File
• Page Table
• Managed Heap
• reservierter Adressraum
• zugesicherter Speicher
• Working Set

Typische Anwendungsfälle

• wächst der private Speicher fortlaufend?
• welcher Heap wächst?
• besitzt der Prozess ungewöhnlich viele Speicherabbildungen?
• wird viel Adressraum nur reserviert?
• wie unterscheiden sich zwei Zustände desselben Prozesses?
• entsteht der Speicherverbrauch im nativen oder verwalteten Bereich?

Sinnvolle Vorgehensweise bei vermutetem Speicherleck

1. Anwendung in einem definierten Ausgangszustand starten.
2. ersten VMMap-Snapshot erfassen.
3. reproduzierbare Aktion mehrfach ausführen.
4. zweiten Snapshot erfassen.
5. Snapshots vergleichen.
6. wachsende Speichertypen identifizieren.
7. Ergebnis mit Prozessmetriken, Dumps und Anwendungsprotokollen abgleichen.

Ein wachsender Working Set allein beweist kein Speicherleck. Caches und noch erreichbare, später freigegebene Daten können ebenfalls wachsen.

ProcDump kann Speicherabbilder eines Prozesses erzeugen, wenn festgelegte Bedingungen eintreten.

Mögliche Auslöser sind unter anderem:

• unbehandelte Ausnahme
• Prozessabsturz
• hohe CPU-Auslastung
• niedrige CPU-Auslastung
• nicht reagierendes Fenster
• bestimmter Leistungsindikator
• manuell angeforderter Dump
• Prozessstart

Hilfe der installierten Version anzeigen

[RO] procdump.exe -?

Manuelles vollständiges Speicherabbild eines Prozesses

[TEST][PRIV][SENS] procdump.exe -ma <PID> "C:\Diagnose"

Auf Prozessnamen warten und vollständigen Dump bei Ausnahme erzeugen

[TEST][PRIV][SENS] procdump.exe -ma -e -w "<PROZESSNAME.exe>" "C:\Diagnose"

Dump bei nicht reagierendem Fenster

[TEST][PRIV][SENS] procdump.exe -ma -h "<PROZESSNAME.exe>" "C:\Diagnose"

Überwachung beenden

Die betreffende ProcDump-Instanz muss kontrolliert beendet werden, wenn die Diagnose abgeschlossen ist.

Wichtige Planungsfragen

• Wie viele Dumps dürfen entstehen?
• Wie groß kann jeder Dump werden?
• Ist ausreichend Speicherplatz vorhanden?
• Tritt der Fehler in einem sensiblen Prozess auf?
• Wer darf die Dumps lesen?
• Wie lange werden sie gespeichert?
• Welcher Debugger wird zur Analyse verwendet?

Vollständige Prozessabbilder können Passwörter, Tokens, Schlüssel, Dokumentinhalte, Datenbanksätze und andere Geheimnisse enthalten. Sie müssen wie hochsensible Daten geschützt werden.

System Monitor, kurz Sysmon, ist ein Windows-Systemdienst mit Gerätetreiber. Nach der Installation protokolliert er ausgewählte Systemaktivitäten in das Windows-Ereignisprotokoll.

Sysmon kann abhängig von Version und Konfiguration unter anderem erfassen:

• Prozessstarts
• Prozessbeendigungen
• Netzwerkverbindungen
• Erstellung von Dateien
• Änderung von Dateierstellungszeiten
• Laden von Treibern
• Laden von Images und DLLs
• Zugriffe auf Prozesse
• Registryereignisse
• Named Pipes
• DNS-Abfragen
• WMI-Aktivitäten
• Zwischenablageänderungen
• Dateilöschungen
• ausführbare Dateien in bestimmten Ereignissen
• Änderungen an Sysmon selbst

Wichtiger Speicherort

Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ Sysmon
→ Operational

Sysmon mit Konfiguration installieren

[CHANGE][PRIV] sysmon.exe -accepteula -i "C:\Konfiguration\sysmon-config.xml"

Konfiguration aktualisieren

[CHANGE][PRIV] sysmon.exe -c "C:\Konfiguration\sysmon-config.xml"

Aktuelle Konfiguration anzeigen

[RO][PRIV][SENS] sysmon.exe -c

Sysmon deinstallieren

[CHANGE][PRIV] sysmon.exe -u

Sysmon besitzt keine automatische Alarmierungs- oder Bewertungslogik. Die Ereignisse müssen durch geeignete Regeln, ein SIEM, ein EDR-System oder eine kontrollierte manuelle Analyse ausgewertet werden.

Eine Sysmon-Konfiguration bestimmt, welche Ereignisse einbezogen oder ausgeschlossen werden.

Ziele einer guten Konfiguration

• relevante Sicherheitsereignisse erfassen
• unnötige Ereignismengen begrenzen
• wichtige Systemprogramme nicht pauschal ausblenden
• Regeln dokumentieren
• Konfigurationsänderungen versionieren
• Speicherbedarf und Ereignisrate überwachen
• Auswertung durch SIEM oder Monitoring berücksichtigen

Risiken einer ungeprüften Konfiguration

• zu viele Ereignisse überlasten Sammlung und Auswertung
• zu breite Ausschlüsse erzeugen blinde Flecken
• sensible Befehlszeilen werden zentral gespeichert
• DNS-Abfragen offenbaren Benutzeraktivitäten
• Dateipfade enthalten personenbezogene Daten
• Regeländerungen beeinflussen Erkennungsmechanismen
• unterschiedliche Systeme benötigen unterschiedliche Filter

Beispiel einer minimalen XML-Grundstruktur

<Sysmon schemaversion="<SCHEMA-VERSION>">
  <EventFiltering>
    <ProcessCreate onmatch="include">
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

Die erforderliche Schemaversion und die unterstützten Ereignisse müssen mit der tatsächlich verwendeten Sysmon-Version geprüft werden.

Konfigurationsschema anzeigen

[RO] sysmon.exe -s

Eine fremde Sysmon-Konfiguration sollte nicht ungeprüft in einer produktiven Umgebung übernommen werden. Sie muss an Systeme, Anwendungen, Datenschutz, Ereignissammlung und Erkennungsziele angepasst werden.

Sigcheck zeigt Datei- und Signaturinformationen an.

Einzelne Datei untersuchen

[RO][SENS] sigcheck.exe -a -h -i "<DATEI>"

Verzeichnis rekursiv untersuchen

[RO][SENS] sigcheck.exe -s -a -h "<VERZEICHNIS>"

Nicht signierte Dateien suchen

[RO][SENS] sigcheck.exe -u -e "<VERZEICHNIS>"

CSV-Ausgabe

[RO][SENS] sigcheck.exe -c -h "<DATEI>"

Typische Prüfungen

• Herausgeber stimmt mit erwarteter Software überein
• Signaturstatus ist gültig
• Dateipfad ist plausibel
• Produkt- und Dateiversion passen zusammen
• Hash stimmt mit einer bekannten Referenz überein
• Datei wurde nicht aus einem temporären oder Benutzerverzeichnis nachgeladen

Auch legitime Programme können unsignierte Komponenten besitzen. Umgekehrt kann eine gültig signierte Datei für unerwünschte Zwecke missbraucht oder mit einem kompromittierten Zertifikat signiert worden sein.

ListDLLs zeigt geladene DLLs und deren Pfade an.

Alle geladenen DLLs anzeigen

[RO][PRIV][SENS] listdlls.exe

DLLs eines bestimmten Prozesses

[RO][PRIV][SENS] listdlls.exe <PID>

Alternativ kann nach einem Prozessnamen gefiltert werden:

[RO][PRIV][SENS] listdlls.exe "<PROZESSNAME>"

Nach einer bestimmten DLL suchen

[RO][PRIV][SENS] listdlls.exe -d "<DLL-NAME>"

Typische Auffälligkeiten

• DLL aus einem unerwarteten Benutzerverzeichnis
• mehrere Versionen derselben Komponente
• DLL aus einem temporären Verzeichnis
• fehlende oder ungültige Signatur
• Prozess lädt nicht die erwartete Bibliothek
• unerwartete Drittanbieter-Erweiterung

Der Dateiname allein ist nicht ausreichend. Pfad, Version, Signatur, Hash, Ladegrund und Anwendungskontext müssen gemeinsam bewertet werden.

Strings extrahiert lesbare ANSI- und Unicode-Zeichenfolgen aus Binärdateien.

Datei untersuchen

[RO][SENS] strings.exe "<DATEI>"

Mindestlänge festlegen

[RO][SENS] strings.exe -n 8 "<DATEI>"

Ausgabe nach einem Begriff filtern

[RO][SENS] strings.exe -n 8 "<DATEI>" | findstr /i "<SUCHBEGRIFF>"

Mögliche Anwendungsfälle

• eingebettete URLs finden
• Fehlermeldungen erkennen
• Dateipfade finden
• Produkt- oder Debuginformationen erkennen
• verdächtige Befehlszeilen entdecken
• Hinweise auf eingebettete Konfigurationen erhalten

Einschränkungen

• komprimierte oder verschlüsselte Inhalte werden nicht automatisch verständlich
• gefundene Zeichenfolge muss nicht ausgeführt oder verwendet werden
• zufällige Bytefolgen können wie Text aussehen
• Ausgabe kann Zugangsdaten oder andere Geheimnisse enthalten

Strings ist ein Hinweiswerkzeug und kein vollständiges Verfahren zur Malwareanalyse oder zum Reverse Engineering.

NTFS-Dateien können neben dem normalen Dateiinhalt alternative Datenströme besitzen. Windows verwendet solche Datenströme unter anderem für Herkunftsinformationen heruntergeladener Dateien.

Datenströme anzeigen

[RO][SENS] streams.exe "<DATEI>"

Verzeichnis rekursiv untersuchen

[RO][SENS] streams.exe -s "<VERZEICHNIS>"

Alternative Datenströme löschen

[CHANGE][DANGER] streams.exe -d "<DATEI-ODER-VERZEICHNIS>"

Das pauschale Löschen alternativer Datenströme kann Sicherheitskennzeichnungen wie Herkunftsinformationen entfernen und dadurch Schutzfunktionen beeinflussen. Vorher müssen Inhalt, Zweck und Auswirkungen geprüft werden.

PowerShell kann Datenströme ebenfalls anzeigen:

[RO][SENS] Get-Item "<DATEI>" -Stream *

AccessChk zeigt Zugriffsrechte auf verschiedene Windows-Objekte an.

Dazu gehören unter anderem:

• Dateien
• Verzeichnisse
• Registryschlüssel
• Dienste
• Prozesse
• Kernelobjekte
• Freigaben
• benannte Pipes

Hilfe anzeigen

[RO] accesschk.exe /?

Verzeichnisrechte untersuchen

[RO][PRIV][SENS] accesschk.exe -d "<VERZEICHNIS>"

Rechte eines bestimmten Kontos prüfen

[RO][PRIV][SENS] accesschk.exe -d "<BENUTZER-ODER-GRUPPE>" "<VERZEICHNIS>"

Dienstrechte untersuchen

[RO][PRIV][SENS] accesschk.exe -c "<DIENSTNAME>"

Typische Anwendungsfälle

• besitzt ein Benutzer tatsächlich Schreibzugriff?
• darf eine Gruppe einen Dienst konfigurieren?
• existieren übermäßig weitreichende Rechte?
• unterscheidet sich der Benutzerkontext vom Administratorkontext?
• ist ein sensibles Verzeichnis für normale Benutzer beschreibbar?

AccessChk-Ausgaben müssen zusammen mit Vererbung, Gruppenmitgliedschaften, Integritätsstufe, Privilegien, Freigaberechten und dem tatsächlichen Benutzerkontext bewertet werden.

AccessEnum

AccessEnum stellt Berechtigungen für Dateien, Verzeichnisse und Registrybereiche übersichtlich dar. Es kann helfen, Abweichungen innerhalb größerer Strukturen zu finden.

[RO][PRIV][SENS] accessenum.exe

Typische Verwendung:

• Verzeichnis oder Registrybereich auswählen
• Berechtigungen erfassen
• auffällige Abweichungen untersuchen
• Zustand speichern
• späteren Zustand vergleichen

ShareEnum

ShareEnum untersucht SMB-Freigaben und deren Sicherheitseinstellungen innerhalb erreichbarer Netzwerkbereiche.

[RO][PRIV][REMOTE][SENS] shareenum.exe

Zu prüfen sind unter anderem

• unerwartete Freigaben
• zu breite Freigabeberechtigungen
• administrative Freigaben
• erreichbare Systeme
• Kombination aus Freigabe- und NTFS-Rechten
• nicht mehr benötigte Freigaben

ShareEnum darf nur in ausdrücklich freigegebenen Netzwerkbereichen verwendet werden. Eine technische Erreichbarkeit ist keine Berechtigung zum Scannen.

PsTools ist eine Sammlung von Befehlszeilenwerkzeugen für lokale und entfernte Windows-Systeme.

Wichtige Werkzeuge

Systeminformationen lokal abrufen

[RO][SENS] psinfo.exe

Systeminformationen remote abrufen

[RO][REMOTE][SENS] psinfo.exe \\<COMPUTER>

Prozesse remote anzeigen

[RO][REMOTE][SENS] pslist.exe \\<COMPUTER>

Angemeldete Benutzer untersuchen

[RO][REMOTE][SENS] psloggedon.exe \\<COMPUTER>

PsTools können administrative Remoteaktionen ausführen. Authentifizierung, Firewall, administrative Freigaben, Sicherheitsrichtlinien, Protokollierung und Auswirkungen auf das Zielsystem müssen vorher geklärt werden.

PsExec kann Prozesse lokal oder auf entfernten Windows-Systemen starten.

Remote-Befehlszeile starten

[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\<COMPUTER> cmd.exe

Befehl remote ausführen

[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\<COMPUTER> ipconfig /all

Prozess als lokales Systemkonto starten

[CHANGE][PRIV][DANGER] psexec.exe -s -i cmd.exe

Der letzte Befehl erzeugt einen besonders privilegierten Kontext und darf nur für klar begründete administrative Diagnosen verwendet werden.

Sicherheitsregeln

• keine Passwörter offen in der Befehlszeile übergeben
• nur eindeutig bestimmten Zielcomputer verwenden
• aktiven Benutzer und Auswirkungen prüfen
• keine interaktive Sitzung unbeaufsichtigt lassen
• erzeugte Dienste und Prozesse kontrollieren
• Remotezugriff protokollieren
• keine dauerhafte Umgehung regulärer Verwaltungswege
• Befehle zunächst lokal oder in einer Testumgebung prüfen

Anmeldeinformationen in einer Befehlszeile können in Prozesslisten, Protokollen, Shellverläufen oder Diagnoseaufzeichnungen sichtbar werden.

PsPing erweitert einfache Ping-Tests um TCP-Verbindungs-, Latenz- und Durchsatzmessungen.

ICMP-Test

[TEST][SENS] psping.exe <ZIEL>

TCP-Port testen

[TEST][SENS] psping.exe <ZIEL>:<PORT>

Beispiel:

[TEST][SENS] psping.exe server.example:443

Längere Messung

[TEST][SENS] psping.exe -n 20 server.example:443

Für Bandbreitenmessungen ist eine passende PsPing-Instanz als Empfänger erforderlich. Die genauen Parameter müssen anhand der Hilfe der eingesetzten Version gewählt werden:

[RO] psping.exe /?

Bewertungsregeln

• TCP-Erreichbarkeit bestätigt nicht die korrekte Anwendung.
• Durchsatztests erzeugen zusätzliche Netzlast.
• Messergebnisse hängen von Gegenstelle, Route und Systemlast ab.
• kurze Tests können sporadische Störungen übersehen.
• Sicherheitssoftware kann Testverbindungen blockieren.
• Tests gegen fremde Systeme benötigen eine Freigabe.

AD Explorer ist ein grafischer Viewer und Editor für Active Directory.

Das Werkzeug kann:

• AD-Objekte durchsuchen
• Attribute anzeigen
• Objekteigenschaften untersuchen
• Suchabfragen speichern
• Snapshots einer AD-Datenbank erstellen
• zwei Snapshots vergleichen
• zugehörige Sicherheitsinformationen anzeigen

Starten

[RO][PRIV][REMOTE][SENS] adexplorer.exe

Typische Anwendungsfälle

• Attribut eines Benutzers oder Computers prüfen
• Gruppenmitgliedschaften nachvollziehen
• Distinguished Name kontrollieren
• Replikations- oder Änderungsstände vergleichen
• Objekte anhand bestimmter Attribute suchen
• Zustand vor und nach einer administrativen Änderung vergleichen

Risiken

AD Explorer kann nicht nur lesen, sondern bei ausreichenden Rechten auch Objekte verändern. Ein versehentliches Ändern oder Löschen kann Domänendienste und Anwendungen beeinträchtigen.

Für reine Diagnosezwecke sollte nach Möglichkeit ein Konto mit nur den notwendigen Leserechten verwendet werden.

Snapshots können enthalten:

• Benutzernamen
• Gruppenstrukturen
• Computernamen
• E-Mail-Adressen
• organisatorische Strukturen
• sicherheitsrelevante Attribute
• interne Server- und Domäneninformationen

Sie müssen entsprechend geschützt werden.

AD Insight

AD Insight überwacht LDAP-Clientaufrufe eines Prozesses und kann helfen, Active-Directory-Kommunikation einer Anwendung zu untersuchen.

Typische Fragen:

• Welche LDAP-Abfrage führt die Anwendung aus?
• Welcher Domänencontroller wird angesprochen?
• Welche Attribute werden angefordert?
• Welche LDAP-Fehler treten auf?
• Wiederholt eine Anwendung unnötig viele Abfragen?

[TEST][PRIV][SENS] adinsight.exe

Die Aufzeichnung kann sehr viele interne Verzeichnisinformationen enthalten.

AD Restore

AD Restore kann gelöschte Active-Directory-Objekte untersuchen und in unterstützten Fällen wiederherstellen.

[RO][PRIV][SENS] adrestore.exe

Eine tatsächliche Wiederherstellung verändert Active Directory:

[CHANGE][PRIV][DANGER]

AD Restore darf nicht ohne Kenntnis von AD-Papierkorb, Tombstone-Zustand, Replikation, Objektabhängigkeiten, Wiederherstellungsziel und organisatorischer Freigabe eingesetzt werden.

Coreinfo zeigt die Zuordnung logischer Prozessoren sowie unterstützte Prozessor- und Virtualisierungsfunktionen an.

Starten

[RO] coreinfo.exe

Virtualisierungsbezogene Informationen

[RO] coreinfo.exe -v

Typische Anwendungsfälle

• unterstützt die CPU benötigte Virtualisierungsfunktionen?
• sind Funktionen durch Firmware oder Hypervisor beeinflusst?
• wie sind logische Prozessoren, Kerne und NUMA-Knoten zugeordnet?
• stehen benötigte Befehlssatzerweiterungen zur Verfügung?
• unterscheidet sich ein System von einem funktionierenden Vergleichssystem?

Die Anzeige einer CPU-Funktion beweist nicht automatisch, dass sie von Firmware, Betriebssystem, Hypervisor und Anwendung vollständig nutzbar ist.

BgInfo kann technische Systeminformationen in den Desktophintergrund einblenden.

Mögliche Angaben:

• Computername
• IP-Adresse
• Betriebssystemversion
• Domäne
• Benutzer
• letzter Startzeitpunkt
• Prozessor
• Arbeitsspeicher
• freier Speicherplatz
• benutzerdefinierte Werte

Starten

[RO][SENS] bginfo.exe

BgInfo eignet sich beispielsweise für:

• Schulungs- und Testsysteme
• Serverkonsolen
• virtuelle Maschinen
• schnelle Identifikation eines Zielsystems
• kontrollierte Supportumgebungen

Datenschutz beachten

Auf gemeinsam betrachteten Desktops dürfen keine unnötigen sensiblen Angaben angezeigt werden. Dazu gehören beispielsweise:

• öffentliche IP-Adressen
• interne Domänenstrukturen
• personenbezogene Benutzerdaten
• geheime Systemkennungen
• vertrauliche Inventarnummern

BgInfo ist eine Anzeigehilfe und kein Werkzeug zur laufenden Zustandsüberwachung.

Disk2vhd erstellt virtuelle Festplattendateien aus Volumes eines laufenden Windows-Systems. Dafür kann der Volumeschattenkopie-Dienst verwendet werden, um einen konsistenteren Zeitpunkt abzubilden.

Starten

[TEST][PRIV][SENS] disk2vhd.exe

Mögliche Anwendungsfälle

• Testkopie eines Systems erstellen
• System für eine kontrollierte Analyse virtualisieren
• physisches System in eine virtuelle Testumgebung überführen
• Zustand eines Systems vor umfangreicher Analyse sichern

Wichtige Grenzen

• eine VHD- oder VHDX-Datei ist nicht automatisch ein vollständiges Backupkonzept
• laufende Anwendungen können zusätzliche Konsistenzanforderungen besitzen
• Datenbanken benötigen möglicherweise anwendungsspezifische Sicherung
• verschlüsselte Volumes müssen gesondert berücksichtigt werden
• Aktivierung und Lizenzierung können sich in einer VM verändern
• virtuelle Kopie darf nicht unkontrolliert parallel im produktiven Netzwerk starten
• gespeicherte Anmeldeinformationen bleiben möglicherweise enthalten
• die Datei kann nahezu alle Daten des Quellsystems enthalten

Eine virtualisierte Kopie eines Produktivsystems muss isoliert gestartet werden, damit keine doppelten Computerkonten, IP-Adressen, Dienste oder automatischen Aufgaben das Produktivnetz beeinflussen.

LiveKd ermöglicht die Untersuchung eines laufenden Windows-Systems mit Microsoft-Kerneldebuggern, ohne die klassische Remote-Debuggingverbindung zu einem zweiten Computer aufzubauen.

Starten

[TEST][PRIV][SENS] livekd.exe

Je nach Konfiguration wird ein kompatibler Microsoft-Debugger benötigt.

Mögliche Anwendungsfälle

• Kernelstrukturen untersuchen
• Treiberzustände betrachten
• Kernelstacks analysieren
• Speicher- und Objektinformationen prüfen
• Livezustand mit Debuggerbefehlen untersuchen

Grenzen

• das System verändert sich während der Untersuchung weiter
• Daten können zwischen Abfragen inkonsistent werden
• falsche Interpretation von Kernelstrukturen ist möglich
• Symbole müssen zur Systemversion passen
• Debuggerzugriff kann hochsensible Informationen offenlegen

LiveKd ist ein spezialisiertes Werkzeug für fortgeschrittene Windows- und Treiberanalyse. Es sollte nicht ohne Debuggingkenntnisse auf produktiven Systemen eingesetzt werden.

WinObj zeigt den Namensraum des Windows-Objektmanagers.

Darin können unter anderem sichtbar sein:

• Geräteobjekte
• symbolische Links
• Sessions
• Treiberobjekte
• Named Pipes
• BaseNamedObjects
• Dateisystemobjekte
• Kernelobjekte

Starten

[RO][PRIV][SENS] winobj.exe

Typische Anwendungsfälle

• symbolische Objektverknüpfungen untersuchen
• Gerätedateien und Treiberobjekte nachvollziehen
• benannte Synchronisationsobjekte finden
• Unterschiede zwischen Sitzungen erkennen
• interne Objektpfade einer Anwendung prüfen

WinObj zeigt interne Windows-Objekte. Die bloße Existenz eines unbekannten Objekts ist kein Beweis für einen Fehler oder eine Kompromittierung.

Wenn Dateien während des laufenden Betriebs nicht ersetzt oder gelöscht werden können, kann Windows Operationen für den nächsten Systemstart vormerken.

Ausstehende Operationen anzeigen

[RO][PRIV][SENS] pendmoves.exe

Datei beim nächsten Neustart verschieben

[CHANGE][PRIV][RESTART] movefile.exe "<QUELLE>" "<ZIEL>"

Datei beim nächsten Neustart löschen

[CHANGE][PRIV][RESTART][DANGER] movefile.exe "<DATEI>" ""

Risiken

• falsche Systemdatei wird entfernt
• Anwendung startet nach Neustart nicht mehr
• Treiber oder Dienst fällt aus
• Abhängigkeiten werden erst nach Neustart sichtbar
• Rücknahme ist nach dem Start möglicherweise schwierig

Vor dem Vormerken einer Löschung müssen Datei, Hersteller, Signatur, Anwendung, Wiederherstellungsweg und Auswirkungen eindeutig geklärt sein.

SDelete kann Dateien oder freien Speicherplatz überschreiben, um die Wiederherstellung gelöschter Daten zu erschweren.

Hilfe anzeigen

[RO] sdelete.exe /?

Datei sicher löschen

[CHANGE][PRIV][DANGER] sdelete.exe "<DATEI>"

Freien Speicherplatz bearbeiten

[CHANGE][PRIV][DANGER] sdelete.exe -c <LAUFWERK>

Wichtige Einschränkungen

• SSDs besitzen Wear-Leveling und interne Speicherverwaltung
• Speichercontroller können Daten umorganisieren
• virtuelle Datenträger besitzen zusätzliche Speicherschichten
• Snapshots und Backups bleiben unberührt
• Cloud- und SAN-Speicher abstrahieren die physische Ablage
• falscher Zielpfad kann nicht einfach rückgängig gemacht werden

SDelete ist keine allgemeine Fehlerbehebungsmaßnahme. Vor dem Einsatz müssen Datenträgertyp, Sicherungen, Snapshots, Aufbewahrungspflichten und Löschkonzept geprüft werden.

NotMyFault kann absichtlich:

• Systemabstürze auslösen
• Systeme aufhängen
• Kernel-Speicherlecks erzeugen
• Treiberfehler simulieren
• hohe Last erzeugen

Das Werkzeug dient beispielsweise zum Testen von:

• Speicherabbildkonfiguration
• Überwachungssystemen
• Wiederanlaufverhalten
• Absturzanalysen
• Laborübungen

[DANGER][PRIV][RESTART] notmyfault.exe

NotMyFault darf niemals auf einem produktiven System, einem gemeinsam genutzten Schulungssystem oder einem nicht vollständig isolierten Testsystem ausprobiert werden. Es verursacht absichtlich schwerwiegende Störungen.

Vor einem Test müssen mindestens vorhanden sein:

• isolierte virtuelle Maschine
• aktueller Snapshot oder definierter Wiederherstellungsweg
• keine produktiven Daten
• kein Zugang zum Produktivnetz
• dokumentiertes Testszenario
• Kontrolle über Neustart und Speicherabbilder
• ausreichend Speicherplatz
• ausdrückliche Freigabe

1. Originale Fehlermeldung erfassen.
2. Fehlerzeitpunkt dokumentieren.
3. betroffenen Computer und Benutzer bestätigen.
4. Reproduzierbarkeit prüfen.
5. integrierte Windows-Protokolle untersuchen.
6. kleinstes passende Sysinternals-Werkzeug auswählen.
7. Werkzeugquelle, Version und Signatur kontrollieren.
8. Berechtigungsbedarf prüfen.
9. mögliche sensible Daten berücksichtigen.
10. Aufzeichnung vorbereiten.
11. Filter möglichst eng festlegen.
12. Ausgangszustand dokumentieren.
13. Aufzeichnung starten.
14. Fehler einmal reproduzieren.
15. Aufzeichnung unmittelbar beenden.
16. Ereignisse zeitlich eingrenzen.
17. Prozess, Pfad, Benutzer, Operation und Ergebnis vergleichen.
18. normale Such- und Fehlversuche von relevanten Fehlern unterscheiden.
19. Befund mit Ereignisanzeige und Anwendungsprotokollen abgleichen.
20. Hypothese formulieren.
21. möglichst kleinen und reversiblen Test planen.
22. Sicherung und Rückfallplan prüfen.
23. Änderung durchführen.
24. Funktion erneut testen.
25. Diagnosewerkzeuge und temporäre Überwachung beenden.
26. Daten geschützt speichern oder ordnungsgemäß löschen.
27. Ursache, Maßnahme und Ergebnis dokumentieren.

Ausgangslage

Eine Anwendung meldet beim Start, eine Konfigurationsdatei sei nicht vorhanden. Die Datei ist im erwarteten Verzeichnis sichtbar.

Vorgehensweise

1. tatsächlichen Anwendungsprozess bestimmen.
2. Process Monitor starten.
3. Aufzeichnung anhalten und leeren.
4. Filter auf den Prozessnamen setzen.
5. optional nach einem Teil des Dateinamens filtern.
6. Aufzeichnung starten.
7. Fehler reproduzieren.
8. Aufzeichnung beenden.
9. Operationen wie CreateFile untersuchen.
10. tatsächlich abgefragten Pfad prüfen.
11. Benutzerkontext kontrollieren.
12. Ergebnisse vor und nach dem Fehler vergleichen.

Mögliche Befunde

• Anwendung sucht in einem anderen Verzeichnis.
• Umgebungsvariable führt zu einem falschen Pfad.
• Dateiname oder Erweiterung weicht ab.
• Zugriff wird verweigert und als „nicht gefunden“ dargestellt.
• Anwendung läuft unter einem Dienstkonto.
• Datei wird zuerst gefunden, aber eine abhängige Datei fehlt.
• Registrywert enthält einen veralteten Pfad.
• 32-Bit- und 64-Bit-Dateisystemumleitung beeinflusst den Zugriff.

Geeignete Ergänzungen

• Process Explorer für Benutzer und Befehlszeile
• AccessChk für Berechtigungen
• Sigcheck für die Anwendungsdatei
• Ereignisanzeige für Folgefehler

Vorgehensweise

1. Ausgangswert im Task-Manager oder mit PowerShell erfassen.
2. Process Explorer zur Beobachtung verwenden.
3. Private Bytes, Working Set und Commit unterscheiden.
4. VMMap-Snapshot im Ausgangszustand speichern.
5. reproduzierbare Benutzeraktion mehrfach ausführen.
6. zweiten VMMap-Snapshot erstellen.
7. wachsende Speicherart bestimmen.
8. bei Bedarf ProcDump kontrolliert konfigurieren.
9. Speicherabbild mit geeignetem Debugger untersuchen.
10. Anwendungsversion und bekannte Fehler des Herstellers prüfen.

Nicht ausreichend als Beweis

• RAM-Anzeige steigt einmalig
• Working Set sinkt nicht sofort
• freier Speicher wird kleiner
• RAMMap zeigt großen Standby-Cache
• Prozess besitzt viele Speicherabbildungen

Stärkerer Hinweis auf ein Leck

Ein bestimmter Speicherbereich wächst bei wiederholbarer identischer Aktion fortlaufend, wird nicht wieder freigegeben und korreliert mit der Störung.

Geeignete Werkzeuge

• Process Monitor
• Process Explorer
• Autoruns
• Ereignisanzeige
• Leistungsüberwachung
• ProcDump bei Hängern

Vorgehensweise

1. Startzeit reproduzierbar messen.
2. Process Monitor vorbereiten.
3. nur den Startvorgang aufzeichnen.
4. Ereignisse nach Dauer untersuchen.
5. wiederholte Datei- oder Registryzugriffe identifizieren.
6. Netzwerkpfade und Namensauflösung beachten.
7. untergeordnete Prozesse im Process Tree prüfen.
8. Signaturen und Pfade geladener Komponenten kontrollieren.
9. Ergebnis mit einem funktionierenden System vergleichen.

Mögliche Ursachen

• nicht erreichbarer Netzwerkpfad
• langsame DNS-Auflösung
• wiederholte Zertifikatsprüfung
• blockierende Sicherheitssoftware
• fehlende Datei mit wiederholten Suchversuchen
• langsame Benutzerprofilkomponente
• fehlerhafte Shell-Erweiterung
• veraltete Autostartkomponente
• stark ausgelasteter Datenträger
• Drittanbieter-DLL
• nicht erreichbarer Lizenzserver

Sysinternals-Ausgaben können enthalten:

• Benutzernamen
• Computer- und Domänennamen
• IP-Adressen
• Dateipfade
• Befehlszeilen
• Prozessumgebungen
• Registrywerte
• geöffnete Dokumente
• Netzwerkziele
• Sicherheitskennungen
• Anmeldesitzungen
• E-Mail-Adressen
• Tokens und Zugangsdaten
• Datei- und Speicherinhalte
• Active-Directory-Strukturen

Vor der Weitergabe

1. Empfänger und Zweck bestimmen.
2. erforderlichen Datenumfang begrenzen.
3. Datei auf Geheimnisse prüfen.
4. personenbezogene Daten redigieren.
5. verschlüsselten Übertragungsweg verwenden.
6. Zugriffsrechte beschränken.
7. Aufbewahrungsdauer festlegen.
8. Löschung dokumentieren.
9. öffentliche Uploadplattformen vermeiden.
10. Speicherabbilder besonders schützen.

Besonders sensible Dateitypen

Ticket:
Datum und Uhrzeit:
Bearbeiter:

Computername:
Windows-Version:
Build:
Architektur:
Benutzerkontext:
Betroffener Prozess:
PID:
Prozesspfad:
Befehlszeile:
Prozessherausgeber:
Signaturstatus:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Reproduktionsschritte:
Letzte funktionierende Nutzung:
Letzte Änderung:

Verwendetes Sysinternals-Werkzeug:
Werkzeugversion:
Bezugsquelle:
Hash des Werkzeugs:
Erhöht ausgeführt:
Startzeit der Aufzeichnung:
Endzeit der Aufzeichnung:
Verwendete Filter:
Verwendete Befehlszeile:
Speicherort der Diagnosedaten:

Relevanter Prozess:
Übergeordneter Prozess:
Benutzer:
Operation:
Objekt oder Pfad:
Ergebnis:
Zeitlicher Zusammenhang:
Vergleichssystem geprüft:
Normales Verhalten ausgeschlossen:

Autostarteintrag:
Signatur:
Hash:
VirusTotal verwendet:
Datei hochgeladen:
Freigabe für externen Dienst vorhanden:

Lokale Adresse:
Lokaler Port:
Remoteadresse:
Remoteport:
Verbindungsstatus:
Zugehöriger Prozess:

RAM-Ausgangswert:
RAM-Endwert:
Working Set:
Private Bytes:
Commit:
Wachsende Speicherart:
Dump erzeugt:
Dump-Typ:
Dump-Größe:
Dump geschützt gespeichert:

Sysmon-Konfiguration:
Sysmon-Ereignis-ID:
Ereignisquelle:
SIEM-Abfrage:

Vermutete Ursache:
Zusätzliche Datenquelle:
Geplante Änderung:
Sicherung geprüft:
Rückfallplan:
Änderung durchgeführt:
Neustart erforderlich:

Ergebnis nach Änderung:
Fehler erneut getestet:
Monitoring kontrolliert:
Temporäre Aufzeichnung beendet:
Diagnosedaten redigiert:
Aufbewahrungsfrist:
Abschluss:

Eine typische Domänenanmeldung umfasst mehrere Schritte:

1. Der Client ermittelt über DNS einen geeigneten Domain Controller.
2. Der DC-Locator berücksichtigt Domäne, Standort und verfügbare Dienste.
3. Client und Domain Controller prüfen ihre Vertrauensbeziehung.
4. Kerberos oder NTLM authentifiziert den Benutzer.
5. Active Directory liefert Benutzer-, Computer- und Gruppeninformationen.
6. SYSVOL stellt Gruppenrichtliniendateien und Anmeldeskripte bereit.
7. Der Gruppenrichtliniendienst ermittelt und verarbeitet passende GPOs.
8. Weitere Dienste stellen Profile, Laufwerke, Drucker oder Anwendungen bereit.

Daraus ergibt sich eine wichtige Diagnose-Reihenfolge:

1. lokaler Netzwerkzustand
2. IP-Konfiguration
3. DNS-Clientkonfiguration
4. DNS-Auflösung der Domänendienste
5. Erreichbarkeit eines geeigneten Domain Controllers
6. Uhrzeit und Zeitzone
7. Secure Channel
8. Kerberos-Tickets und SPNs
9. AD-Replikation
10. SYSVOL und DFS-Replikation
11. Gruppenrichtlinienverarbeitung
12. abhängige Serverrollen

In Active Directory ist DNS Bestandteil der Dienstermittlung. Ein Client, der ausschließlich einen öffentlichen DNS-Server verwendet, kann zwar Internetnamen auflösen, aber normalerweise die internen Domänendienste nicht korrekt ermitteln.

Vor der ersten Änderung müssen mindestens folgende Angaben erfasst werden:

• betroffener Benutzer
• betroffener Computer
• Domänenname
• Active-Directory-Standort
• verwendeter Domain Controller
• Zeitpunkt des Fehlers
• originale Fehlermeldung
• betroffene Anwendung oder Ressource
• einmalige oder wiederkehrende Störung
• Anzahl betroffener Systeme
• letzte bekannte funktionierende Nutzung
• letzte administrative Änderung
• kürzlich installierte Updates
• Netzwerksegment und VPN-Zustand
• Anmeldung lokal, zwischengespeichert oder gegen einen Domain Controller
• administrative oder normale Benutzersitzung

Grundinformationen auf einem Client

[RO][SENS] hostname
[RO][SENS] whoami
[RO][SENS] whoami /upn
[RO][SENS] whoami /user
[RO][SENS] whoami /groups
[RO][SENS] systeminfo
[RO][SENS] ipconfig /all

Domäneninformationen mit PowerShell

[RO][SENS] Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain

Anmelde- und Logonserver-Variablen

[RO][SENS] set LOGONSERVER
[RO][SENS] set USERDNSDOMAIN
[RO][SENS] set USERDOMAIN

Die Variable LOGONSERVER ist ein nützlicher Hinweis, aber keine vollständige Aussage darüber, welcher Domain Controller bei allen späteren LDAP-, Kerberos-, DNS- oder GPO-Vorgängen verwendet wird.

Wichtige Protokolle befinden sich in der Ereignisanzeige unter:

Ereignisanzeige
├── Windows-Protokolle
│   ├── Anwendung
│   ├── Sicherheit
│   └── System
└── Anwendungs- und Dienstprotokolle
    └── Microsoft
        └── Windows

Relevante Protokollbereiche können sein:

• ActiveDirectory_DomainService
• DNS-Server
• Directory Service
• DFS Replication
• GroupPolicy
• Kerberos
• KDC
• Netlogon
• Time-Service
• DHCP-Server
• FailoverClustering
• ServerManager
• CertificateServicesClient
• TerminalServices
• SMBClient und SMBServer

GroupPolicy-Betriebsprotokoll

Anwendungs- und Dienstprotokolle
└── Microsoft
    └── Windows
        └── GroupPolicy
            └── Operational

Ereignisse per PowerShell abrufen

[RO][PRIV][SENS] Get-WinEvent -LogName System -MaxEvents 100

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

Nach Zeitraum und Ebene filtern

[RO][PRIV][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = (Get-Date).AddHours(-2)
    Level     = 2,3
}

Verfügbare Protokolle suchen

[RO][SENS] Get-WinEvent -ListLog * |
    Where-Object LogName -match "GroupPolicy|DNS|DFS|Kerberos|Netlogon|Failover"

Ereignis-IDs dürfen nicht isoliert interpretiert werden. Quelle, Windows-Version, Ereignistext, Fehlercode, Zeitpunkt und begleitende Ereignisse müssen gemeinsam ausgewertet werden.

dcdiag führt verschiedene Tests für Domain Controller aus. Abhängig von den Parametern werden unter anderem Erreichbarkeit, DNS, Replikation, Dienste, Rolleninhaber und Verzeichnispartitionen geprüft.

Grundprüfung des lokalen Domain Controllers

[TEST][PRIV][SENS] dcdiag

Ausführliche Ausgabe

[TEST][PRIV][SENS] dcdiag /v

Bestimmten Domain Controller prüfen

[TEST][PRIV][REMOTE][SENS] dcdiag /s:<DC-NAME>

Alle Domain Controller des Unternehmensbereichs prüfen

[TEST][PRIV][REMOTE][SENS] dcdiag /e

DNS-Tests ausführen

[TEST][PRIV][REMOTE][SENS] dcdiag /test:DNS /e /v

Bestimmten Test ausführen

[TEST][PRIV][SENS] dcdiag /test:<TESTNAME>

Ausgabe in Dateien schreiben

[TEST][PRIV][SENS] dcdiag /v /f:"<AUSGABEDATEI>"

Wichtige Bewertungsfragen

• Welcher konkrete Test ist fehlgeschlagen?
• Welcher Domain Controller wurde geprüft?
• Welcher Partner oder Dienst war beteiligt?
• Handelt es sich um einen aktuellen oder historischen Fehler?
• Ist DNS korrekt konfiguriert?
• Sind notwendige Dienste gestartet?
• Funktioniert die Replikation aller Verzeichnispartitionen?
• Sind die FSMO-Rolleninhaber erreichbar?
• Ist SYSVOL freigegeben?
• Tritt der Fehler auf allen DCs oder nur auf einem DC auf?

dcdiag liefert mehrere unabhängige Testergebnisse. Eine einzelne Warnung beweist nicht automatisch einen Gesamtausfall des Domain Controllers.

Active Directory ist ein Multi-Master-Verzeichnis. Änderungen werden zwischen Domain Controllern repliziert. Fehler können dazu führen, dass Benutzer, Gruppen, Kennwörter, Computerobjekte oder DNS-Daten auf verschiedenen DCs unterschiedliche Stände besitzen.

Gesamtübersicht

[RO][PRIV][REMOTE][SENS] repadmin /replsummary

Die Ausgabe zeigt unter anderem:

• Quell- und Ziel-DCs
• Anzahl fehlgeschlagener Replikationen
• Fehlerquote
• größte Replikationsverzögerung
• Fehlercode

Eingehende Replikationspartner anzeigen

[RO][PRIV][REMOTE][SENS] repadmin /showrepl

Bestimmten Domain Controller untersuchen

[RO][PRIV][REMOTE][SENS] repadmin /showrepl <DC-NAME>

Alle Domain Controller ausführlich untersuchen

[RO][PRIV][REMOTE][SENS] repadmin /showrepl * /csv

Replikationswarteschlange anzeigen

[RO][PRIV][SENS] repadmin /queue

Replikationsmetadaten eines Objekts untersuchen

[RO][PRIV][REMOTE][SENS] repadmin /showobjmeta <DC-NAME> "<DISTINGUISHED-NAME>"

Replikation anstoßen

[CHANGE][PRIV][REMOTE] repadmin /syncall <DC-NAME> /AdeP

Dieser Befehl darf nicht als erster Diagnoseschritt verwendet werden. Er verändert zwar keine AD-Objektinhalte direkt, löst aber Replikationsvorgänge aus und kann Netzwerk- sowie Systemlast erzeugen.

Typische Fehlerbereiche

Eine manuell erfolgreich ausgelöste Replikation beweist nicht, dass Topologie, Zeitplan und automatische Replikation dauerhaft funktionieren.

Der DC-Locator ermittelt anhand von DNS-Daten, Domäne, Standort und Anforderungen einen geeigneten Domain Controller.

Domain Controller ermitteln

[TEST][SENS] nltest /dsgetdc:<DOMÄNE>

Beispiel:

[TEST][SENS] nltest /dsgetdc:example.internal

Ermittlung neu durchführen

[CHANGE][SENS] nltest /dsgetdc:<DOMÄNE> /force

Domain Controller auflisten

[RO][SENS] nltest /dclist:<DOMÄNE>

Standort des Computers anzeigen

[RO][SENS] nltest /dsgetsite

Standortabdeckung eines DCs untersuchen

[RO][SENS] nltest /dsgetsite

DNS-SRV-Einträge prüfen

[TEST][SENS] nslookup -type=SRV _ldap._tcp.dc._msdcs.<DOMÄNE>

[TEST][SENS] nslookup -type=SRV _kerberos._tcp.<DOMÄNE>

Zu prüfen sind:

• werden mehrere erwartete Domain Controller geliefert?
• stimmen Namen und IP-Adressen?
• wird ein DC des erwarteten Standorts bevorzugt?
• existieren veraltete Einträge?
• sind LDAP- und Kerberos-SRV-Records vorhanden?
• verwendet der Client ausschließlich interne DNS-Server?
• erreicht der Client die ausgegebenen Server?

Das direkte Eintragen eines Domain Controllers in die Hosts-Datei ersetzt die DNS-basierte Dienstermittlung nicht und kann die eigentliche Ursache verdecken.

Domänenmitglieder besitzen ein Computerkonto mit einem Kennwort. Der Secure Channel verwendet diese Vertrauensbeziehung für die Kommunikation mit der Domäne.

Secure Channel mit NLTest prüfen

[TEST][PRIV][REMOTE][SENS] nltest /sc_verify:<DOMÄNE>

Vertraute Domäne abfragen

[RO][PRIV][SENS] nltest /sc_query:<DOMÄNE>

PowerShell-Prüfung auf einem Domänenmitglied

[TEST][PRIV][REMOTE] Test-ComputerSecureChannel -Verbose

Test-ComputerSecureChannel ist für Domänenmitglieder vorgesehen. Die Interpretation auf Domain Controllern unterscheidet sich, weil DCs eigene Replikations- und Vertrauensmechanismen verwenden.

Reparatur mit PowerShell

[CHANGE][PRIV][REMOTE][DANGER] Test-ComputerSecureChannel -Repair -Credential "<DOMÄNE>\<ADMIN-KONTO>"

Vor einer Reparatur müssen geprüft werden:

• DNS-Konfiguration
• Erreichbarkeit eines Domain Controllers
• Uhrzeit
• Computerkonto im Active Directory
• mögliche doppelte Computernamen
• Wiederherstellung eines alten VM-Snapshots
• kürzlich erfolgte Domänenwiederaufnahme
• verwendete administrative Anmeldeinformationen
• Auswirkungen auf Dienste und geplante Aufgaben

Ein Computer sollte nicht vorschnell aus der Domäne entfernt und wieder aufgenommen werden. Dadurch können Computerkonto, Zertifikate, lokale Profile, verschlüsselte Daten, Dienstkonten und Verwaltungszuordnungen beeinflusst werden.

Vollständige IP-Konfiguration

[RO][SENS] ipconfig /all

PowerShell-Übersicht

[RO][SENS] Get-DnsClientServerAddress

[RO][SENS] Get-NetIPConfiguration

Zu prüfen sind:

• verwendete DNS-Server
• Reihenfolge der DNS-Server
• DNS-Suffix
• verbindungsspezifisches DNS-Suffix
• Registrierung der Adresse
• mehrere aktive Netzwerkadapter
• VPN-Adapter
• virtuelle Adapter
• fehlerhafte statische Einstellungen
• DHCP-Optionen
• Erreichbarkeit der eingetragenen DNS-Server

DNS-Clientcache anzeigen

[RO][SENS] ipconfig /displaydns

DNS-Clientcache leeren

[CHANGE] ipconfig /flushdns

Das Leeren des Caches kann einen neuen Auflösungsversuch erzwingen, beseitigt aber keine fehlerhafte Zone, falsche Delegierung oder falsche DNS-Clientkonfiguration.

DNS-Namen prüfen

[TEST][SENS] Resolve-DnsName "<HOSTNAME>"

[TEST][SENS] Resolve-DnsName "<FQDN>" -Type A

[TEST][SENS] Resolve-DnsName "_ldap._tcp.dc._msdcs.<DOMÄNE>" -Type SRV

Ein Domänenclient sollte nicht ohne geplante interne DNS-Weiterleitung öffentliche DNS-Resolver zusätzlich zu internen AD-DNS-Servern verwenden. Windows behandelt mehrere eingetragene DNS-Server nicht als einfache interne-und-externe Suchreihenfolge.

Wichtige Prüfbereiche im DNS-Manager:

• Forward-Lookupzonen
• Reverse-Lookupzonen
• AD-integrierte Zonen
• Replikationsbereich der Zone
• dynamische Updates
• sichere dynamische Updates
• Weiterleitungen
• bedingte Weiterleitungen
• Stammhinweise
• veraltete Hosteinträge
• SRV-Einträge
• Delegierungen
• Alterung und Aufräumvorgänge
• DNSSEC, falls verwendet

DNS-Serverzonen mit PowerShell anzeigen

[RO][PRIV][SENS] Get-DnsServerZone

Ressourceneinträge einer Zone anzeigen

[RO][PRIV][SENS] Get-DnsServerResourceRecord -ZoneName "<ZONE>"

DNS-Servereinstellungen anzeigen

[RO][PRIV][SENS] Get-DnsServer

Weiterleitungen anzeigen

[RO][PRIV][SENS] Get-DnsServerForwarder

DNS-Diagnose mit DCDiag

[TEST][PRIV][SENS] dcdiag /test:DNS /v

DNS-Registrierung eines Domänenmitglieds anfordern

[CHANGE] ipconfig /registerdns

Auf einem Domain Controller kann außerdem eine erneute Registrierung domänenbezogener Einträge erforderlich sein. Dienstneustarts dürfen jedoch erst nach Prüfung der Auswirkungen erfolgen.

DNS-Debugprotokollierung

Die DNS-Debugprotokollierung kann sehr viele Daten und interne Abfragen erfassen. Sie sollte:

1. nur mit einem konkreten Fehlerbild aktiviert werden,
2. nach Client, Protokoll oder Pakettyp begrenzt werden,
3. nur so lange wie erforderlich laufen,
4. hinsichtlich Speicherplatz überwacht werden,
5. anschließend wieder deaktiviert werden.

[CHANGE][PRIV][LOG][SENS]

DNS-Debuglogs können interne Hostnamen, abgefragte Dienste, Clientadressen und Benutzeraktivitäten offenlegen.

Netlogon ist unter anderem an Domänenanmeldung, DC-Locator und Secure-Channel-Vorgängen beteiligt.

Eine erweiterte Netlogon-Protokollierung darf nur zeitlich begrenzt aktiviert werden.

Aktuellen Netlogon-Zustand prüfen

[RO][PRIV] sc query netlogon

Netlogon-Diagnoseprotokollierung aktivieren

[CHANGE][PRIV][LOG][SENS] nltest /dbflag:0x2080ffff

Protokollierung wieder auf den Standardzustand zurücksetzen

[CHANGE][PRIV] nltest /dbflag:0x0

Das Protokoll befindet sich typischerweise unter:

%windir%\debug\netlogon.log

Vor und während der Aufzeichnung müssen geprüft werden:

• freier Speicherplatz
• Aufzeichnungsdauer
• konkreter Fehlerzeitpunkt
• betroffener Benutzer und Computer
• Schutz der Protokolldatei
• anschließende Deaktivierung

Der Debug-Schalter darf nicht unkontrolliert dauerhaft aktiviert bleiben. Die Datei kann umfangreich werden und interne Domäneninformationen enthalten.

Kerberos verwendet Tickets zur Authentifizierung. Dabei sind unter anderem Client, Key Distribution Center, Zielservice, SPN, Uhrzeit und DNS beteiligt.

Tickets des aktuellen Anmeldekontexts anzeigen

[RO][SENS] klist

Ticket Granting Tickets anzeigen

[RO][SENS] klist tgt

Kerberos-Sitzungen anzeigen

[RO][SENS] klist sessions

Tickets löschen

[CHANGE][SENS] klist purge

Das Löschen der Tickets beeinflusst den aktuellen Authentifizierungskontext. Anwendungen müssen danach möglicherweise neue Tickets anfordern.

Ticket für einen Dienst anfordern

[TEST][REMOTE][SENS] klist get <SPN>

Typische Prüfungen

• wurde ein TGT ausgestellt?
• welcher KDC hat das Ticket ausgestellt?
• für welchen SPN wurde ein Serviceticket ausgestellt?
• ist das Ticket abgelaufen?
• stimmen Client- und Servernamen?
• wurde auf NTLM zurückgefallen?
• tritt der Fehler nur mit Aliasnamen auf?
• funktioniert der Zugriff mit FQDN, aber nicht mit Kurzname?
• befindet sich ein altes Ticket im Cache?
• stimmt die Uhrzeit?

klist purge ist keine Ursachenbehebung. Wenn DNS, SPN, Zeit oder Kontokonfiguration fehlerhaft sind, tritt das Problem nach Ausstellung neuer Tickets erneut auf.

Ein SPN identifiziert eine Dienstinstanz für Kerberos. Er muss dem richtigen AD-Konto eindeutig zugeordnet sein.

SPNs eines Kontos anzeigen

[RO][PRIV][SENS] setspn -L "<KONTO>"

Bestimmten SPN suchen

[RO][PRIV][SENS] setspn -Q "<SPN>"

Forestweit nach doppelten SPNs suchen

[RO][PRIV][REMOTE][SENS] setspn -X

SPN mit Duplikatprüfung registrieren

[CHANGE][PRIV][DANGER] setspn -S "<SPN>" "<KONTO>"

SPN entfernen

[CHANGE][PRIV][DANGER] setspn -D "<SPN>" "<KONTO>"

Vor jeder Änderung müssen geprüft werden:

• vollständiger SPN
• Dienstklasse
• Hostname und FQDN
• Port, falls Teil des SPN
• tatsächlich verwendetes Dienstkonto
• bestehende Zuordnung
• Cluster-, Alias- oder Load-Balancer-Namen
• Auswirkungen auf andere Dienstinstanzen
• Replikationsstatus

Typische Kerberos-Probleme entstehen durch:

• fehlenden SPN
• doppelten SPN
• SPN auf falschem Konto
• Dienst läuft unter anderem Konto als erwartet
• DNS-Alias ohne passende SPN-Konfiguration
• altes Computerkonto
• nicht replizierte SPN-Änderung
• falschen Zielnamen der Anwendung

SPNs dürfen nicht durch Ausprobieren auf verschiedene Konten geschrieben werden. Eine falsche Zuordnung kann die Kerberos-Authentifizierung mehrerer Systeme beeinträchtigen.

Kerberos benötigt ausreichend übereinstimmende Zeitangaben. In einer AD-Domäne folgt die Zeithierarchie grundsätzlich der Domänenhierarchie. Der PDC-Emulator der Gesamtstruktur-Stammdomäne besitzt dabei eine besondere Rolle.

Status anzeigen

[RO][SENS] w32tm /query /status

Zeitquelle anzeigen

[RO][SENS] w32tm /query /source

Konfiguration anzeigen

[RO][SENS] w32tm /query /configuration

Peers anzeigen

[RO][SENS] w32tm /query /peers

Domänenhierarchie überwachen

[TEST][REMOTE][SENS] w32tm /monitor

Abweichung zu einem Computer messen

[TEST][REMOTE][SENS] w32tm /stripchart /computer:<COMPUTER> /dataonly /samples:10

Neue Synchronisation anfordern

[CHANGE][PRIV][REMOTE] w32tm /resync

Zu prüfen sind:

• verwendete Zeitquelle
• letzte erfolgreiche Synchronisation
• aktuelle Zeitabweichung
• Zeitzone
• PDC-Emulator
• Virtualisierung und Hypervisor-Zeitquelle
• NTP-Erreichbarkeit
• Firewall
• kürzlich wiederhergestellte VM
• manuelle Zeitkonfiguration
• Dienstzustand

FSMO-Rollen anzeigen

[RO][PRIV][SENS] netdom query fsmo

Die manuelle Konfiguration externer Zeitserver auf allen Domänenmitgliedern kann die vorgesehene AD-Zeithierarchie umgehen. Änderungen müssen passend zur Rolle des Systems geplant werden.

gpresult zeigt die Resultant Set of Policy, also die ermittelten Gruppenrichtlinienergebnisse für Computer und Benutzer.

Zusammenfassung

[RO][SENS] gpresult /r

Ausführliche Ausgabe

[RO][SENS] gpresult /v

Maximal ausführliche Textausgabe

[RO][SENS] gpresult /z

HTML-Bericht erzeugen

[RO][SENS] gpresult /h "<BERICHT>.html"

Nur Computerrichtlinien anzeigen

[RO][PRIV][SENS] gpresult /scope computer /r

Nur Benutzerrichtlinien anzeigen

[RO][SENS] gpresult /scope user /r

Bericht für einen anderen Benutzer

[RO][PRIV][SENS] gpresult /user "<DOMÄNE>\<BENUTZER>" /h "<BERICHT>.html"

Wichtige Auswertungsbereiche:

• angewendete GPOs
• abgelehnte GPOs
• Ablehnungsgrund
• Sicherheitsgruppen
• Benutzer- und Computer-OU
• langsame oder schnelle Netzwerkverbindung
• WMI-Filter
• Vererbungsinformationen
• Loopback-Verarbeitung
• Richtlinienrevision
• letzter Verarbeitungszeitpunkt
• verwendeter Domain Controller

Eine GPO kann in der Gruppenrichtlinienverwaltung vorhanden und mit einer OU verknüpft sein, ohne auf das untersuchte Objekt angewendet zu werden.

Normale Aktualisierung

[CHANGE][REMOTE] gpupdate

Alle Richtlinieneinstellungen erneut verarbeiten

[CHANGE][REMOTE] gpupdate /force

Zeitlimit festlegen

[CHANGE][REMOTE] gpupdate /wait:<SEKUNDEN>

Abmeldung zulassen, falls erforderlich

[CHANGE][REMOTE] gpupdate /logoff

Neustart zulassen, falls erforderlich

[CHANGE][REMOTE][RESTART] gpupdate /boot

gpupdate /force sollte nicht reflexartig auf vielen Systemen gleichzeitig ausgeführt werden. Es kann:

• zusätzliche DC- und Netzwerkbelastung erzeugen
• Skripte erneut ausführen
• Softwareinstallation anstoßen
• Abmeldung oder Neustart erforderlich machen
• bestehende Sitzungen beeinflussen
• Drucker- und Laufwerkszuordnungen erneut verarbeiten

Empfohlener Testablauf

1. gpresult vor der Aktualisierung speichern.
2. Fehlerzeitpunkt dokumentieren.
3. Ereignisprotokoll prüfen.
4. gpupdate auf einem kontrollierten Testsystem ausführen.
5. Meldungen vollständig dokumentieren.
6. erforderliche Abmeldung oder Neustart berücksichtigen.
7. gpresult erneut erzeugen.
8. vorherigen und nachfolgenden Zustand vergleichen.

Mögliche Ursachen:

• Benutzer oder Computer befindet sich in der falschen OU.
• GPO ist mit einer anderen OU verknüpft.
• Verknüpfung ist deaktiviert.
• Benutzer- oder Computerteil der GPO ist deaktiviert.
• Sicherheitsfilter schließt das Objekt aus.
• notwendige Rechte Lesen oder Gruppenrichtlinie übernehmen fehlen.
• WMI-Filter liefert False oder kann nicht ausgewertet werden.
• Vererbung wurde blockiert.
• eine erzwungene GPO beeinflusst die Vererbungsreihenfolge.
• eine Richtlinie mit höherer Priorität überschreibt die Einstellung.
• Loopback-Verarbeitung verändert die Benutzerrichtlinien.
• Client erreicht keinen Domain Controller.
• DNS oder Secure Channel ist fehlerhaft.
• SYSVOL ist nicht erreichbar.
• AD- und SYSVOL-Replikation besitzen unterschiedliche Stände.
• Client Side Extension benötigt synchrone Verarbeitung.
• Richtlinie wird erst nach Abmeldung oder Neustart wirksam.
• Fast Startup beeinflusst den erwarteten Startvorgang.
• Anwendung liest die Einstellung nur beim Start.
• Einstellung gilt nicht für die verwendete Windows-Version oder Edition.
• ADMX-Vorlage und tatsächlich unterstützte Einstellung passen nicht zusammen.

Prüfreihenfolge

1. Objekt und OU bestätigen.
2. GPO-Verknüpfung bestätigen.
3. GPO-Status prüfen.
4. Sicherheitsfilter prüfen.
5. Delegierung prüfen.
6. WMI-Filter prüfen.
7. Vererbung und Reihenfolge prüfen.
8. gpresult auswerten.
9. GroupPolicy-Betriebsprotokoll auswerten.
10. DNS, DC-Locator und SYSVOL testen.
11. AD- und DFS-R-Replikation prüfen.
12. erforderliche Abmeldung oder Neustart testen.

Für jede untersuchte Gruppenrichtlinie sollten folgende Angaben erfasst werden:

Aufgabe:
Betroffener Benutzer:
Betroffener Computer:
Domäne:
Standort:
Verwendeter Domain Controller:

Name der GPO:
GPO-ID:
GPO-Status:
Benutzer- oder Computerkonfiguration:
Verknüpfte OU:
Verknüpfungsreihenfolge:
Verknüpfung aktiviert:
Erzwungen:
Vererbung blockiert:
Sicherheitsfilter:
Delegierung:
WMI-Filter:
Loopback-Modus:

Pfad der Richtlinieneinstellung:
Konfigurierte Einstellung:
Erwarteter Wert:
Tatsächlicher Wert:

GPResult vor dem Test:
GPUpdate-Ergebnis:
Abmeldung erforderlich:
Neustart erforderlich:
GPResult nach dem Test:
GroupPolicy-Ereignisse:
SYSVOL erreichbar:
AD-Replikation geprüft:
DFS-R-Replikation geprüft:

Ursache:
Änderung:
Rückfallplan:
Testergebnis:

SYSVOL enthält unter anderem Gruppenrichtliniendateien und Skripte. Active Directory speichert den Verzeichnisanteil einer GPO, während SYSVOL den Dateianteil enthält. Beide Teile müssen konsistent und repliziert sein.

Freigaben eines Domain Controllers anzeigen

[RO][REMOTE][SENS] net view \\<DC-NAME>

Erwartete Domänencontroller-Freigaben sind normalerweise:

• SYSVOL
• NETLOGON

SYSVOL öffnen

[TEST][REMOTE][SENS] dir \\<DC-NAME>\SYSVOL

NETLOGON öffnen

[TEST][REMOTE][SENS] dir \\<DC-NAME>\NETLOGON

Bestimmte Richtlinie prüfen

[RO][REMOTE][SENS] dir "\\<DC-NAME>\SYSVOL\<DOMÄNE>\Policies\{<GPO-GUID>}"

Zu vergleichen sind:

• Existenz des GPO-Verzeichnisses
• GPO-GUID
• Inhalt auf mehreren Domain Controllern
• Zeitstempel
• GPT.INI
• Skripte
• Registry-Policy-Dateien
• Zugriffsrechte
• DFS-R-Ereignisse

Dateien in SYSVOL dürfen nicht als normale Konfigurationsmethode manuell auf mehreren Domain Controllern bearbeitet oder kopiert werden. Dadurch können AD- und Dateianteil einer GPO inkonsistent werden.

Moderne Windows-Domänen verwenden DFS Replication für SYSVOL. Wichtige Datenquellen sind:

• Ereignisprotokoll DFS Replication
• DFS-Verwaltung
• dfsrdiag
• PowerShell
• AD-Replikationszustand
• Zustand der SYSVOL- und NETLOGON-Freigaben

DFS-R-Zustand abfragen

[RO][PRIV][SENS] dfsrdiag ReplicationState

Konfiguration neu aus Active Directory einlesen

[CHANGE][PRIV] dfsrdiag PollAD

DFS-R-Ereignisse abrufen

[RO][PRIV][SENS] Get-WinEvent -LogName "DFS Replication" -MaxEvents 200

Typische Prüfbereiche:

• Replikationsgruppe
• replizierter Ordner
• eingehender und ausgehender Partner
• Rückstand
• pausierte Replikation
• Datenbankzustand
• nicht ordnungsgemäß heruntergefahrener Server
• Kommunikationsfehler
• AD-Konfiguration noch nicht eingelesen
• Speicherplatz
• USN- oder Datenbankprobleme

Eine DFS-R-Wiederherstellung oder autoritative SYSVOL-Synchronisierung ist eine eingriffsintensive Maßnahme. Sie darf erst nach gesicherter Diagnose, aktueller Sicherung und dokumentiertem Wiederherstellungsplan durchgeführt werden.

DHCP-Probleme können dazu führen, dass Clients:

• keine Adresse erhalten
• eine APIPA-Adresse verwenden
• falsches Gateway erhalten
• falsche DNS-Server verwenden
• falsches DNS-Suffix erhalten
• ihre Lease nicht verlängern können
• aus einem falschen Bereich versorgt werden
• aufgrund ausgeschöpfter Bereiche keine Adresse erhalten

DHCP-Konfiguration auf dem Client

[RO][SENS] ipconfig /all

Lease freigeben

[CHANGE] ipconfig /release

Lease erneuern

[CHANGE][REMOTE] ipconfig /renew

Diese Befehle unterbrechen die aktuelle IP-Konnektivität und sollten nicht unüberlegt über eine entfernte Verwaltungssitzung ausgeführt werden.

DHCP-Server anzeigen

[RO][PRIV][SENS] Get-DhcpServerInDC

IPv4-Bereiche anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Scope -ComputerName "<DHCP-SERVER>"

Leases anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Lease -ComputerName "<DHCP-SERVER>" -ScopeId "<NETZ-ID>"

Bereichsstatistik anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4ScopeStatistics -ComputerName "<DHCP-SERVER>"

Serveroptionen anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4OptionValue -ComputerName "<DHCP-SERVER>"

Zu prüfen sind:

• DHCP-Autorisierung in Active Directory
• Dienstzustand
• Bereich aktiviert
• verfügbarer Adressvorrat
• Ausschlussbereiche
• Reservierungen
• Lease-Dauer
• Option 003 – Router
• Option 006 – DNS-Server
• Option 015 – DNS-Domänenname
• Relay-Agent oder IP Helper
• DHCP-Failover
• Konflikterkennung
• mehrere unerwartete DHCP-Server
• Auditprotokolle

DHCP-Debug- und Auditlogs können MAC-Adressen, Hostnamen, IP-Adressen und zeitliche Gerätenutzung enthalten und müssen entsprechend geschützt werden.

DFS besteht aus unterschiedlichen Funktionen:

Ein erreichbarer Namespace beweist nicht, dass alle Replikationspartner denselben Datenstand besitzen. Umgekehrt beweist ein gesunder DFS-R-Status nicht, dass Namespace-Ziele, Berechtigungen und Verweise korrekt funktionieren.

Namespacepfad testen

[TEST][REMOTE][SENS] dir "\\<DOMÄNE>\<NAMESPACE>"

DFS-Ziele und Verweise untersuchen

[RO][SENS] dfsutil /pktinfo

Zwischengespeicherte Verweise leeren

[CHANGE] dfsutil /pktflush

Typische Prüfbereiche

• DNS-Auflösung
• Namespace-Server
• Ordnerziele
• Zielstatus
• Standortkosten
• Referral-Reihenfolge
• SMB-Erreichbarkeit
• Freigabeberechtigungen
• NTFS-Berechtigungen
• DFS-R-Rückstand
• Dateisperren
• Konflikt- und gelöschte Ordner
• Staging-Speicher

Ein Failovercluster besteht aus mehreren voneinander abhängigen Komponenten:

• Clusterknoten
• Clusterdienst
• Quorum
• Witness
• Cluster-Netzwerke
• Speicher
• Cluster Shared Volumes
• Ressourcen
• Rollen
• Abhängigkeiten
• DNS
• Active-Directory-Computerobjekte
• Anwendungen

Cluster anzeigen

[RO][PRIV][REMOTE][SENS] Get-Cluster

Knoten anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterNode

Clustergruppen anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterGroup

Ressourcen anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterResource

Quorum anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterQuorum

Clusterprotokoll erzeugen

[TEST][PRIV][REMOTE][LOG][SENS] Get-ClusterLog -UseLocalTime -Destination "<VERZEICHNIS>"

Cluster validieren

[TEST][PRIV][REMOTE][LOG][SENS] Test-Cluster

Die vollständige Validierung kann Netzwerk-, Speicher- und Systemtests durchführen. Umfang und Auswirkungen müssen vor dem Start geprüft werden.

Typische Diagnosefragen

• Welche Ressource ist zuerst ausgefallen?
• Welche abhängigen Ressourcen folgten?
• Welcher Knoten war Besitzer?
• War Quorum vorhanden?
• War der Witness erreichbar?
• trat ein Netzwerk- oder Speicherfehler auf?
• konnte das Clustercomputerobjekt DNS-Daten aktualisieren?
• stimmen Ereigniszeit und Clusterlog überein?
• war der Failover geplant oder ungeplant?
• funktioniert die Anwendung nach dem Ressourcenstart tatsächlich?

Das manuelle Verschieben oder Neustarten einer Clusterrolle ist eine Änderung am produktiven Dienst und keine rein lesende Diagnose.

Server Manager

Server Manager kann unter anderem anzeigen:

• Serverrollen
• Features
• verwaltete Server
• Dienstzustände
• Ereignisse
• Leistungswarnungen
• Best-Practices-Ergebnisse
• Rolleninstallationen

Windows Admin Center

Windows Admin Center kann abhängig von Version und Erweiterungen unter anderem verwalten:

• Server
• Cluster
• virtuelle Maschinen
• Zertifikate
• Ereignisse
• Dienste
• Speicher
• Netzwerke
• Updates
• Firewall
• Registry
• PowerShell

Grenzen

• eine grüne Übersicht ersetzt keine Detailprüfung
• Daten können verzögert aktualisiert werden
• Remoteverwaltung hängt von WinRM, Berechtigungen und Firewall ab
• eine fehlgeschlagene Verwaltungsverbindung beweist keinen Ausfall des Zielservers
• Aktionen können produktive Änderungen auslösen
• Erweiterungen können zusätzliche Berechtigungen benötigen

Verwaltungsoberflächen fassen Zustände zusammen. Für belastbare Diagnosen müssen häufig Ereignisprotokolle, PowerShell-Ausgaben, Dienstprotokolle und Netzwerkdaten ergänzt werden.

Leistungsprobleme dürfen nicht allein anhand einer einzelnen CPU- oder RAM-Anzeige bewertet werden.

Wichtige Bereiche:

• Prozessor
• Arbeitsspeicher
• Datenträger
• Netzwerk
• Prozess
• System
• Serverdienst
• DNS
• AD DS
• DFS-R
• Hyper-V
• SQL Server oder weitere Anwendungsrollen

Leistungsindikatoren anzeigen

[RO][SENS] Get-Counter -ListSet *

Beispielhafte Systemindikatoren

[TEST][SENS] Get-Counter `
    "\Processor(_Total)\% Processor Time",
    "\Memory\Available MBytes",
    "\PhysicalDisk(_Total)\Avg. Disk sec/Transfer",
    "\System\Processor Queue Length"

Wichtige Regeln

• über einen repräsentativen Zeitraum messen
• Normalzustand als Vergleichswert besitzen
• Durchschnitt, Maximum und Verteilung unterscheiden
• Rolle des Servers berücksichtigen
• virtuelle und physische Ebene unterscheiden
• Wartungsfenster und Sicherungen berücksichtigen
• Ursache und Folge nicht verwechseln
• Zeitstempel mit Benutzerfehlern korrelieren

Ein einzelner hoher Messwert beweist noch keinen Engpass. Entscheidend sind Dauer, Wiederholbarkeit, Warteschlangen, Antwortzeiten und Auswirkungen auf den Dienst.

1. originale Fehlermeldung erfassen.
2. Benutzer, Computer und Zeitpunkt bestätigen.
3. Umfang der Störung bestimmen.
4. letzte Änderung dokumentieren.
5. lokale Netzwerkverbindung prüfen.
6. ipconfig /all erfassen.
7. konfigurierte DNS-Server prüfen.
8. Domänennamen und SRV-Einträge auflösen.
9. Domain Controller mit nltest /dsgetdc ermitteln.
10. verwendeten Standort prüfen.
11. Domain Controller gezielt erreichen.
12. Uhrzeit und Zeitquelle vergleichen.
13. Secure Channel prüfen.
14. Kerberos-Tickets untersuchen.
15. bei Dienstproblemen SPNs prüfen.
16. System- und Anwendungsprotokolle auswerten.
17. auf Domain Controllern dcdiag ausführen.
18. AD-Replikation mit repadmin prüfen.
19. bei GPO-Problemen gpresult sichern.
20. GroupPolicy-Betriebsprotokoll untersuchen.
21. SYSVOL auf mehreren DCs vergleichen.
22. DFS-R-Ereignisse prüfen.
23. Hypothese aus mehreren Befunden formulieren.
24. kleinste reversible Maßnahme planen.
25. Sicherung und Rückfallplan prüfen.
26. Änderung kontrolliert durchführen.
27. Funktion mit demselben Testszenario erneut prüfen.
28. Replikation und Monitoring nachkontrollieren.
29. temporäre Debugprotokollierung deaktivieren.
30. Ursache, Maßnahme und Ergebnis dokumentieren.

Ausgangslage

Eine auf DC1 erstellte und mit einer OU verknüpfte GPO soll auf CLIENT1 angewendet werden. Die konfigurierte Einstellung ist auf dem Client nicht wirksam.

Vorgehensweise

1. Benutzer- und Computername auf CLIENT1 bestätigen.
2. prüfen, ob die Einstellung eine Benutzer- oder Computerrichtlinie ist.
3. tatsächliche OU des Zielobjekts kontrollieren.
4. GPO-Verknüpfung in der Gruppenrichtlinienverwaltung prüfen.
5. GPO-Status und Verknüpfungsstatus prüfen.
6. Sicherheitsfilter und Delegierung kontrollieren.
7. WMI-Filter prüfen.
8. gpresult vor einer Änderung erzeugen:

[RO][SENS] gpresult /h "%TEMP%\gpresult-vorher.html"

9. verwendeten Domain Controller und DNS-Zustand prüfen:

[RO][SENS] set LOGONSERVER
[TEST][SENS] nltest /dsgetdc:<DOMÄNE>
[RO][SENS] ipconfig /all

10. GroupPolicy-Betriebsprotokoll untersuchen.
11. SYSVOL auf dem verwendeten DC prüfen.
12. AD- und DFS-R-Replikation zwischen DC1 und weiteren DCs prüfen.
13. kontrollierte Aktualisierung durchführen:

[CHANGE][REMOTE] gpupdate /force

14. erforderliche Abmeldung oder Neustart durchführen.
15. neuen Bericht erzeugen:

[RO][SENS] gpresult /h "%TEMP%\gpresult-nachher.html"

16. beide Berichte vergleichen.

Mögliche Befunde

• CLIENT1 befindet sich in der falschen OU.
• GPO enthält eine Benutzereinstellung, wurde aber nur für das Computerkonto erwartet.
• Sicherheitsfilter schließt den Benutzer oder Computer aus.
• GPO wird durch eine höher priorisierte Einstellung überschrieben.
• WMI-Filter trifft nicht zu.
• Client verwendet einen anderen DC mit älterem Replikationsstand.
• SYSVOL enthält auf einem DC nicht den aktuellen Dateianteil.
• Richtlinie benötigt Neustart oder Abmeldung.
• Einstellung wird von der Clientedition nicht unterstützt.
• Loopback-Verarbeitung verändert das Ergebnis.

Mögliche Ursachen

• unterschiedliche Domain Controller liefern unterschiedliche AD-Stände
• Kennwortänderung ist noch nicht vollständig repliziert
• ein Standort verweist auf einen gestörten DC
• DNS liefert veraltete oder falsche Einträge
• ein Computer besitzt einen fehlerhaften Secure Channel
• Zeitabweichung verhindert Kerberos
• lokale Benutzerrechte unterscheiden sich
• GPO verweigert eine Anmeldeart
• Benutzerprofil oder Anmeldeskript schlägt fehl
• Netzwerk ist beim Start noch nicht verfügbar

Prüfungen auf funktionierendem und betroffenem Computer

[RO][SENS] ipconfig /all
[TEST][SENS] nltest /dsgetdc:<DOMÄNE>
[RO][SENS] nltest /dsgetsite
[TEST][PRIV][SENS] nltest /sc_verify:<DOMÄNE>
[RO][SENS] w32tm /query /status
[RO][SENS] w32tm /query /source
[RO][SENS] klist
[RO][SENS] gpresult /r

Anschließend müssen die Ergebnisse miteinander verglichen werden:

• DNS-Server
• Domain Controller
• Standort
• Uhrzeit
• Ticketstatus
• GPOs
• Gruppenmitgliedschaften
• Ereignisprotokolle
• Secure Channel

Ausgangslage

Ein auf DC1 angelegtes oder geändertes Objekt ist auf DC2 nicht sichtbar.

Vorgehensweise

1. Objekt und Änderungszeitpunkt dokumentieren.
2. sicherstellen, dass tatsächlich unterschiedliche DCs abgefragt werden.
3. AD-Replikationsübersicht erstellen:

[RO][PRIV][SENS] repadmin /replsummary

4. eingehende Partner von DC2 untersuchen:

[RO][PRIV][SENS] repadmin /showrepl DC2

5. betroffenen Namenskontext bestimmen.
6. DNS-Auflösung zwischen DC1 und DC2 prüfen.
7. RPC- und Firewall-Erreichbarkeit berücksichtigen.
8. Uhrzeit vergleichen.
9. Ereignisprotokoll Directory Service untersuchen.
10. Replikationsmetadaten des Objekts vergleichen:

[RO][PRIV][SENS] repadmin /showobjmeta DC1 "<DISTINGUISHED-NAME>"

[RO][PRIV][SENS] repadmin /showobjmeta DC2 "<DISTINGUISHED-NAME>"

11. erst nach Ursachenprüfung eine kontrollierte Replikation auslösen.
12. anschließend automatische Replikation weiter beobachten.

Das manuelle Kopieren, erneute Anlegen oder Löschen des Objekts kann Konflikte erzeugen und die ursprüngliche Replikationsursache verdecken.

Diagnosedaten können enthalten:

• Benutzernamen
• Gruppenmitgliedschaften
• Computernamen
• Domänennamen
• interne DNS-Zonen
• IP- und MAC-Adressen
• Distinguished Names
• Gruppenrichtlinien
• Anmeldeserver
• Sicherheitskennungen
• Kerberos-Ticketinformationen
• Dienstkonten
• SPNs
• Freigaben
• interne Dateipfade
• Cluster- und Servernamen
• DHCP-Leases
• Ereignisprotokolle
• Netzwerkstruktur
• administrative Konten

Vor der Weitergabe müssen:

1. Zweck und Empfänger bestimmt werden.
2. benötigte Daten begrenzt werden.
3. Kennwörter, Schlüssel und Tokens ausgeschlossen werden.
4. personenbezogene Angaben redigiert werden.
5. Dateien verschlüsselt übertragen werden.
6. Zugriffsrechte beschränkt werden.
7. Aufbewahrungsfristen festgelegt werden.
8. temporäre Debuglogs wieder deaktiviert werden.
9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden.
10. externe Analysedienste organisatorisch freigegeben sein.

Kennwörter dürfen nicht in Befehlszeilen, Dokumentationen, Screenshots oder Protokolldateien eingetragen werden.

Ticket:
Datum und Uhrzeit:
Bearbeiter:

Betroffener Benutzer:
Betroffener Computer:
Windows-Version:
Serverrolle:
Domäne:
Active-Directory-Standort:
IP-Adresse:
DNS-Server:
Gateway:
VPN:
Verwendeter Domain Controller:
LOGONSERVER:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Betroffene Systeme:
Letzte funktionierende Nutzung:
Letzte Änderung:

DC-Locator-Ergebnis:
Secure-Channel-Ergebnis:
Zeitquelle:
Zeitabweichung:
Kerberos-Tickets:
Verwendeter KDC:
Untersuchter SPN:
SPN-Zuordnung:
Doppelte SPNs:

DCDiag-Ergebnis:
Fehlgeschlagener Test:
Repadmin-Replikationsübersicht:
Betroffener Quell-DC:
Betroffener Ziel-DC:
Betroffener Namenskontext:
Letzte erfolgreiche Replikation:
Replikationsfehlercode:
Replikationsmetadaten geprüft:

DNS-Zone:
DNS-Record:
SRV-Records:
Dynamische Registrierung:
DNS-Ereignisse:
DNS-Debuglog verwendet:
Netlogon-Debuglog verwendet:
Debuglogging wieder deaktiviert:

GPO:
GPO-ID:
Benutzer- oder Computerrichtlinie:
Verknüpfte OU:
Sicherheitsfilter:
Delegierung:
WMI-Filter:
Vererbungsreihenfolge:
Loopback-Modus:
GPResult vorher:
GPUpdate-Ergebnis:
GPResult nachher:
GroupPolicy-Ereignisse:
Abmeldung erforderlich:
Neustart erforderlich:

SYSVOL erreichbar:
NETLOGON erreichbar:
GPO-Dateianteil vorhanden:
DFS-R-Status:
DFS-R-Ereignisse:
Replikationsrückstand:

DHCP-Server:
DHCP-Bereich:
Lease:
Bereichsauslastung:
Router-Option:
DNS-Option:
DNS-Suffix:
DHCP-Relay:
DHCP-Failover:

Cluster:
Clusterknoten:
Clusterrolle:
Fehlgeschlagene Ressource:
Abhängige Ressourcen:
Quorum:
Witness:
Clusterlog:
Failover-Zeitpunkt:

Vermutete Ursache:
Belege:
Geplante Maßnahme:
Sicherung:
Rückfallplan:
Änderung:
Ergebnis:
Wiederholungstest:
Monitoring:
Abschluss:

Eine Linux-Fehleranalyse sollte nicht mit einem Neustart, einer Paketaktualisierung oder dem Löschen von Dateien beginnen. Zuerst muss der fehlerhafte Zustand gesichert werden.

Grundfragen

• Was funktioniert nicht?
• Wie lautet die vollständige Fehlermeldung?
• Seit wann besteht der Fehler?
• Ist er reproduzierbar?
• Welche Benutzer, Dienste oder Systeme sind betroffen?
• Was wurde zuletzt geändert?
• Ist nur eine Anwendung oder das gesamte System betroffen?
• Tritt der Fehler lokal und remote auf?
• Besteht ein zeitlicher Zusammenhang mit Updates, Neustarts oder Sicherungen?
• Gibt es ausreichend Speicherplatz, Inodes und Arbeitsspeicher?
• Läuft das System auf Hardware, in einer VM oder in einem Container?

Grundlegende Systeminformationen

[RO][SENS] hostnamectl
[RO] uname -a
[RO] cat /etc/os-release
[RO] uptime
[RO][SENS] who
[RO][SENS] last -x

last -x kann unter anderem Anmeldungen, Neustarts und Herunterfahrvorgänge anzeigen. Die verfügbaren Daten hängen von der Protokollierung und Rotation der zugrunde liegenden Dateien ab.

Vor der Verwendung unbekannter Optionen sollte die lokal installierte Dokumentation geprüft werden.

[RO] man <BEFEHL>
[RO] info <BEFEHL>
[RO] <BEFEHL> --help
[RO] apropos "<SUCHBEGRIFF>"
[RO] man -k "<SUCHBEGRIFF>"
[RO] type <BEFEHL>
[RO] command -V <BEFEHL>

Warum die lokale Dokumentation wichtig ist

• Sie passt normalerweise zur installierten Programmversion.
• Optionen können sich zwischen Versionen unterscheiden.
• Distributionen können Programme anders konfigurieren.
• Nicht jeder im Internet gefundene Befehl ist auf dem Zielsystem vorhanden.
• Gleichnamige Programme können aus unterschiedlichen Paketen stammen.

Befehle aus fremden Anleitungen dürfen nicht ungeprüft mit Root-Rechten ausgeführt werden.

[RO] uptime
[RO] top
[RO] free -h
[RO] vmstat 1 10
[RO] cat /proc/loadavg
[RO] nproc
[RO] lscpu

Falls installiert:

[RO] htop
[RO] mpstat -P ALL 1 10
[RO] pidstat 1 10

Load Average richtig einordnen

Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr 1, 5 und 15 Minuten. Sie erfassen nicht ausschließlich CPU-Auslastung, sondern unter Linux auch Tasks, die nicht unterbrechbar warten, beispielsweise auf bestimmte I/O-Vorgänge.

Die Bewertung muss deshalb berücksichtigen:

• Anzahl der logischen CPUs
• CPU-Auslastung
• I/O-Wartezeiten
• Prozesszustände
• Dauer der Belastung
• Normalzustand des Systems
• virtuelle CPU-Zuteilung
• mögliche Drosselung

Ein hoher Load-Wert beweist allein weder eine CPU-Überlastung noch einen bestimmten Hardwarefehler.

[RO][SENS] ps aux
[RO][SENS] ps -ef
[RO][SENS] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd
[RO][SENS] pstree -ap
[RO] pgrep -a "<NAME>"
[RO][PRIV][SENS] lsof -p <PID>

Prozesszustände

Ein Zombieprozess hat seine Ausführung beendet, wurde aber vom Elternprozess noch nicht vollständig abgeholt. Das Beenden des Zombies selbst löst die Ursache normalerweise nicht; der Elternprozess muss untersucht werden.

Signale kontrolliert verwenden

[CHANGE] kill -TERM <PID>
[CHANGE] kill -HUP <PID>
[CHANGE][DANGER] kill -KILL <PID>

• SIGTERM fordert einen kontrollierten Abbruch an.
• SIGHUP kann abhängig vom Programm eine Konfiguration neu einlesen oder eine andere Bedeutung besitzen.
• SIGKILL beendet einen Prozess ohne eigene Aufräumlogik des Prozesses.

kill -9 sollte nicht als Standardmaßnahme verwendet werden. Offene Transaktionen, temporäre Dateien oder gemeinsam genutzte Ressourcen können in einem problematischen Zustand verbleiben.

[RO] systemctl status <DIENST>
[RO] systemctl is-active <DIENST>
[RO] systemctl is-enabled <DIENST>
[RO] systemctl is-failed <DIENST>
[RO] systemctl list-units --type=service --state=failed
[RO] systemctl list-dependencies <DIENST>
[RO] systemctl show <DIENST>
[RO] systemctl cat <DIENST>

Wichtige Unterscheidung

active beweist nicht automatisch, dass die Anwendung fachlich funktioniert. Ein Webserver kann beispielsweise laufen, während eine abhängige Datenbank oder eine bestimmte Website nicht erreichbar ist.

Ändernde Aktionen

[CHANGE][PRIV] sudo systemctl start <DIENST>
[CHANGE][PRIV] sudo systemctl stop <DIENST>
[CHANGE][PRIV][RESTART] sudo systemctl restart <DIENST>
[CHANGE][PRIV] sudo systemctl reload <DIENST>
[CHANGE][PRIV] sudo systemctl reset-failed <DIENST>

reload funktioniert nur, wenn die Unit beziehungsweise das Programm dies unterstützt. reset-failed löscht den registrierten Fehlerzustand, behebt aber nicht dessen Ursache.

Effektive Unit-Konfiguration anzeigen

[RO] systemctl cat <DIENST>

Abhängigkeiten untersuchen

[RO] systemctl list-dependencies <DIENST>
[RO] systemctl list-dependencies --reverse <DIENST>

Lokale Überschreibung bearbeiten

[CHANGE][PRIV] sudo systemctl edit <DIENST>

Unit-Dateien neu einlesen

[CHANGE][PRIV] sudo systemctl daemon-reload

daemon-reload liest Unit-Dateien und die systemd-Abhängigkeitsstruktur neu ein. Es startet den betroffenen Dienst nicht automatisch neu.

Vor einer Änderung müssen gesichert werden:

• Originalkonfiguration
• Inhalt bestehender Drop-ins
• Paketzugehörigkeit
• Abhängigkeiten
• Startbenutzer
• Umgebungsvariablen
• benötigte Dateien und Verzeichnisse
• Rückfallplan
• erwartete Auswirkungen eines Neustarts

Paketverwaltete Unit-Dateien unter /usr/lib/systemd/system oder /lib/systemd/system sollten nicht direkt als dauerhafte Anpassungsmethode bearbeitet werden. Lokale Drop-ins verhindern, dass Paketaktualisierungen die Anpassung einfach überschreiben.

[RO][SENS] journalctl
[RO][SENS] journalctl -b
[RO][SENS] journalctl -b -1
[RO][SENS] journalctl -p warning
[RO][SENS] journalctl -u <DIENST>
[RO][SENS] journalctl -u <DIENST> -b
[RO][SENS] journalctl --since "2026-08-01 14:00:00"
[RO][SENS] journalctl --since "30 minutes ago"
[RO][SENS] journalctl -k
[RO][SENS] journalctl -f

Zusätzliche Filter

[RO][SENS] journalctl _PID=<PID>
[RO][SENS] journalctl _UID=<UID>
[RO][SENS] journalctl _COMM=<PROGRAMM>
[RO][SENS] journalctl -o verbose

Speicherbelegung des Journals

[RO] journalctl --disk-usage

Zu beachten sind:

• richtiger Bootvorgang
• Zeitzone und Zeitstempel
• erste Fehlermeldung statt nur Folgefehler
• Dienstname und Prozess-ID
• Logrotation
• persistente oder flüchtige Speicherung
• Berechtigungen
• mögliche Geheimnisse oder personenbezogene Daten

journalctl -f zeigt neu eintreffende Einträge. Es ersetzt nicht die Untersuchung älterer Ereignisse vor dem sichtbaren Fehler.

Abhängig von der Distribution und Konfiguration können relevante Dateien beispielsweise unter /var/log liegen.

[RO][PRIV][SENS] sudo ls -lah /var/log
[RO][PRIV][SENS] sudo tail -n 200 <LOGDATEI>
[RO][PRIV][SENS] sudo tail -f <LOGDATEI>
[RO][PRIV][SENS] sudo less <LOGDATEI>
[RO][PRIV][SENS] sudo grep -iE "error|fail|warning" <LOGDATEI>

Mögliche Protokolle sind unter anderem:

• /var/log/syslog
• /var/log/messages
• /var/log/auth.log
• /var/log/secure
• /var/log/kern.log
• anwendungsspezifische Unterverzeichnisse

Diese Pfade sind nicht auf jeder Distribution vorhanden. Ein System kann Ereignisse ausschließlich oder zusätzlich im systemd-Journal speichern.

Rotierte Protokolle

[RO][PRIV][SENS] sudo zless <LOGDATEI>.gz
[RO][PRIV][SENS] sudo zgrep -i "<SUCHTEXT>" <LOGDATEI>.gz

Protokolldateien dürfen nicht gelöscht oder geleert werden, bevor Ursache, Aufbewahrungspflichten und Auswirkungen auf laufende Prozesse geklärt sind.

[RO][PRIV][SENS] sudo dmesg
[RO][PRIV][SENS] sudo dmesg --ctime
[RO][PRIV][SENS] sudo dmesg --level=err,warn
[RO][PRIV][SENS] sudo journalctl -k -b
[RO][PRIV][SENS] sudo journalctl -k -b -1

Typische Suchbegriffe:

[RO][PRIV][SENS] sudo dmesg --ctime | grep -iE "error|fail|timeout|reset|oom|I/O"

Zu untersuchen sind beispielsweise:

• I/O-Fehler
• Geräte-Resets
• Dateisystemfehler
• Treiberprobleme
• Link-Änderungen
• Out-of-Memory-Ereignisse
• Kernel-Warnungen
• Machine-Check-Ereignisse
• USB-Verbindungsabbrüche
• blockierte Tasks

Der Kernel-Ringpuffer ist begrenzt. Ältere Meldungen können überschrieben worden sein. Außerdem dürfen Zeitangaben aus dmesg nicht ungeprüft mit Zeitstempeln anderer Protokolle gleichgesetzt werden.

[RO] free -h
[RO] cat /proc/meminfo
[RO][SENS] ps -eo pid,user,%mem,rss,vsz,cmd --sort=-rss
[RO] vmstat 1 10
[RO][PRIV][SENS] sudo journalctl -k | grep -iE "out of memory|oom|killed process"

Wichtige Bereiche:

• verfügbarer Speicher
• Page Cache
• Swap-Nutzung
• Major Page Faults
• Prozess-RSS
• cgroup- oder Containergrenzen
• Speicherwachstum über die Zeit
• OOM-Auswahl des Kernels
• NUMA-Zuordnung
• reservierter Speicher einer VM

Linux verwendet freien Arbeitsspeicher sinnvoll als Cache. Ein geringer Wert in der Spalte free bedeutet daher nicht automatisch Speichermangel. Für die erste Bewertung ist bei free insbesondere available relevant.

Swap-Nutzung anzeigen

[RO] swapon --show
[RO] cat /proc/swaps

Das Leeren von Caches oder Deaktivieren von Swap ist keine allgemeine Speicherreparatur und kann zusätzliche Last oder einen Systemausfall verursachen.

[RO][SENS] lsblk -f
[RO][SENS] findmnt
[RO] df -hT
[RO] df -i
[RO][PRIV][SENS] sudo fdisk -l
[RO][PRIV][SENS] sudo blkid

Warum df -h und df -i benötigt werden

Ein Dateisystem kann trotz freier Datenblöcke keine neuen Dateien mehr anlegen, wenn keine freien Inodes verfügbar sind.

Große Verzeichnisse ermitteln

[RO][PRIV][SENS] sudo du -xhd1 <VERZEICHNIS> | sort -h

Gelöschte, aber noch geöffnete Dateien suchen

[RO][PRIV][SENS] sudo lsof +L1

Wenn ein Prozess eine gelöschte Datei noch geöffnet hält, kann der belegte Speicherplatz bis zum Schließen des Dateideskriptors weiterhin belegt bleiben.

du und df messen unterschiedliche Sachverhalte. Abweichungen beweisen nicht automatisch einen Dateisystemfehler.

Falls die erforderlichen Werkzeuge installiert sind:

[RO] iostat -xz 1 10
[RO][PRIV] sudo smartctl -a /dev/<GERÄT>
[RO][PRIV] sudo nvme smart-log /dev/<NVME-GERÄT>

Zu prüfen sind:

• Latenz
• Warteschlangen
• Auslastung
• Durchsatz
• I/O-Fehler
• Geräte-Resets
• Medienfehler
• Temperatur
• verbleibende Reserve
• RAID- oder Storage-Layer
• virtuelle Datenträger
• parallele Sicherungen

SMART-Werte müssen geräte- und herstellerspezifisch interpretiert werden. Ein bestandener allgemeiner SMART-Status schließt einen Defekt nicht sicher aus.

Selbsttests, Reparaturbefehle und Schreibtests können Last erzeugen oder ein vorgeschädigtes Medium zusätzlich beanspruchen. Vorher müssen Sicherungsstand und Auswirkungen geklärt werden.

Dateisystemtyp und Einhängezustand prüfen

[RO][SENS] findmnt
[RO][SENS] lsblk -f
[RO] mount
[RO][PRIV][SENS] sudo journalctl -k | grep -iE "filesystem|ext4|xfs|btrfs|I/O error"

Eine Dateisystemprüfung muss zum tatsächlichen Dateisystem passen. Werkzeuge für ext-Dateisysteme, XFS und Btrfs sind nicht beliebig austauschbar.

[TEST][PRIV][DANGER] sudo fsck <BLOCKGERÄT>

fsck darf nicht unüberlegt auf einem schreibend eingehängten Dateisystem ausgeführt werden. Vor einer Reparatur müssen Dateisystemtyp, Geräteziel, Einhängezustand, Sicherung und Wiederherstellungsplan eindeutig geklärt sein.

Bei Root-Dateisystemen kann eine Prüfung im Rettungsmodus, über ein Wartungssystem oder beim Start erforderlich sein.

[RO][SENS] ip -br link
[RO][SENS] ip -br address
[RO][SENS] ip address show
[RO][SENS] ip -s link
[RO][SENS] ip route show
[RO][SENS] ip rule show
[RO][SENS] ip neigh show

Zu prüfen sind:

• administrativer und physischer Link-Zustand
• MAC-Adresse
• IPv4- und IPv6-Adressen
• Präfixlängen
• Standardroute
• Routingtabellen
• Policy Routing
• Interfacefehler und Drops
• Nachbartabelle
• VLANs, Bonds und Bridges
• virtuelle Interfaces
• Network Namespace

Die früher verbreiteten Werkzeuge ifconfig, route und netstat werden auf vielen modernen Linux-Systemen durch Werkzeuge aus iproute2, insbesondere ip und ss, ersetzt.

[TEST][REMOTE] ping -c 4 <IP-ODER-HOSTNAME>
[TEST][REMOTE] ping -6 -c 4 <IPv6-ODER-HOSTNAME>
[TEST][REMOTE][SENS] tracepath <ZIEL>
[TEST][REMOTE][SENS] traceroute <ZIEL>
[TEST][REMOTE][SENS] mtr <ZIEL>

Ein erfolgreicher Ping beweist nur, dass die verwendete ICMP-Kommunikation in dieser Richtung und zu diesem Zeitpunkt funktioniert hat. Er beweist nicht, dass:

• ein bestimmter TCP- oder UDP-Port erreichbar ist
• DNS korrekt arbeitet
• die Anwendung antwortet
• TLS funktioniert
• Authentifizierung erfolgreich ist
• der Rückweg für alle Verbindungen identisch ist

Ein fehlgeschlagener Ping beweist umgekehrt keinen vollständigen Ausfall, da ICMP gefiltert oder begrenzt werden kann.

[RO][SENS] cat /etc/resolv.conf
[RO][SENS] getent hosts <HOSTNAME>
[TEST][REMOTE][SENS] dig <HOSTNAME>
[TEST][REMOTE][SENS] dig <HOSTNAME> A
[TEST][REMOTE][SENS] dig <HOSTNAME> AAAA
[TEST][REMOTE][SENS] dig -x <IP-ADRESSE>
[TEST][REMOTE][SENS] dig @<DNS-SERVER> <HOSTNAME>
[TEST][REMOTE][SENS] resolvectl query <HOSTNAME>
[RO][SENS] resolvectl status

getent hosts berücksichtigt die konfigurierte Namensdienstauflösung des Systems und kann daher für die tatsächliche Anwendungssicht aussagekräftiger sein als eine isolierte DNS-Abfrage.

Zu prüfen sind:

• Inhalt von /etc/nsswitch.conf
• konfigurierte Resolver
• Suchdomänen
• Split DNS
• lokale Hosts-Datei
• Cache
• VPN-Konfiguration
• systemd-resolved
• NetworkManager
• A- und AAAA-Einträge
• Reverse Lookup
• DNSSEC-Fehler
• unterschiedliche Antworten verschiedener Server

/etc/resolv.conf kann eine automatisch erzeugte Datei oder ein symbolischer Link sein. Manuelle Änderungen können überschrieben werden und sind nicht zwingend die richtige dauerhafte Konfigurationsmethode.

[RO][PRIV][SENS] sudo ss -lntup
[RO][SENS] ss -tan
[RO][SENS] ss -s
[RO][PRIV][SENS] sudo lsof -i
[TEST][REMOTE] nc -vz <HOST> <PORT>
[TEST][REMOTE][SENS] curl -v <URL>

Zu prüfen sind:

• lauscht der Dienst überhaupt?
• an welcher Adresse lauscht er?
• IPv4, IPv6 oder beides?
• stimmt der Port?
• welcher Prozess besitzt den Socket?
• ist nur 127.0.0.1 beziehungsweise ::1 gebunden?
• erreicht der Client den Port?
• kommt eine Anwendungsantwort zurück?
• scheitert TLS oder Authentifizierung?
• existieren viele halboffene oder wartende Verbindungen?

Ein offener TCP-Port beweist nur, dass eine Verbindung angenommen werden kann. Die fachliche Funktion der Anwendung muss separat getestet werden.

[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE>
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE> host <IP-ADRESSE>
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE> port <PORT>
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE> -nn -s 0 -w <DATEI>.pcap

Vor einer Aufzeichnung müssen festgelegt werden:

• richtiges Interface
• geeigneter Filter
• Aufzeichnungsdauer
• Speicherort
• maximaler Speicherbedarf
• Zeitpunkt des Fehlers
• Datenschutz
• sichere Übertragung
• Löschfrist

Eine Paketaufzeichnung kann enthalten:

• IP-Adressen
• DNS-Anfragen
• Hostnamen
• unverschlüsselte Anwendungsdaten
• Sitzungsinformationen
• interne Netzwerkstrukturen
• Kommunikationsbeziehungen

Ohne Begrenzung kann eine Aufzeichnung sehr groß werden. Bei produktiven Systemen sollten rotierende Dateien, zeitliche Begrenzung und möglichst enge Capture-Filter verwendet werden.

Je nach System können unterschiedliche Frameworks oder Verwaltungswerkzeuge eingesetzt werden.

[RO][PRIV][SENS] sudo nft list ruleset
[RO][PRIV][SENS] sudo iptables -S
[RO][PRIV][SENS] sudo iptables -t nat -S
[RO][PRIV][SENS] sudo firewall-cmd --list-all
[RO][PRIV][SENS] sudo ufw status verbose

Zu prüfen sind:

• tatsächlich aktives Firewall-Backend
• Eingangs-, Ausgangs- und Weiterleitungsregeln
• Standardrichtlinien
• Regelreihenfolge
• Interfaces und Zonen
• Quell- und Zielnetze
• Ports und Protokolle
• NAT
• Connection Tracking
• IPv4 und IPv6
• Container- oder Virtualisierungsregeln
• persistente gegenüber aktuell geladenen Regeln

Mehrere Werkzeuge können auf dasselbe oder auf unterschiedliche Backends zugreifen. Eine leere iptables-Ausgabe beweist daher nicht automatisch, dass keine Filterregeln aktiv sind.

[RO][SENS] nmcli general status
[RO][SENS] nmcli device status
[RO][SENS] nmcli connection show
[RO][SENS] nmcli device show <INTERFACE>
[RO][SENS] nmcli connection show "<VERBINDUNG>"
[RO][PRIV][SENS] journalctl -u NetworkManager -b

Zu prüfen sind:

• verwaltete und nicht verwaltete Interfaces
• aktive Verbindung
• Verbindungsprofil
• DHCP-Daten
• DNS-Konfiguration
• Route und Metrik
• Autoconnect
• VLAN, Bond oder Bridge
• Zeitpunkt eines Linkwechsels
• Konflikte mit anderen Netzwerkverwaltungen

Änderungen mit nmcli können eine SSH-Verbindung sofort unterbrechen. Vor Remoteänderungen sind Konsolenzugang und Rückfallplan erforderlich.

[RO][SENS] id <BENUTZER>
[RO][SENS] groups <BENUTZER>
[RO][SENS] getent passwd <BENUTZER>
[RO][SENS] getent group <GRUPPE>
[RO][SENS] namei -l <PFAD>
[RO][SENS] stat <PFAD>
[RO][SENS] ls -ld <PFAD>
[RO][SENS] getfacl <PFAD>

Bei einem Pfadproblem müssen alle übergeordneten Verzeichnisse berücksichtigt werden. Für das Durchlaufen eines Verzeichnisses ist das Ausführungsrecht am Verzeichnis entscheidend.

Zu unterscheiden sind:

• Eigentümer
• Gruppe
• klassische Modusbits
• ACLs
• umask
• effektive Benutzer- und Gruppen-ID
• ergänzende Gruppen
• Mount-Optionen
• SELinux oder AppArmor
• Container- und Namespace-Zuordnung
• NFS- oder SMB-Berechtigungen

chmod 777 ist keine fachgerechte Standardlösung. Es kann Daten ungewollt für alle lokalen Benutzer veränderbar machen und verdeckt die eigentliche Ursache.

SELinux

[RO] getenforce
[RO] sestatus
[RO][PRIV][SENS] sudo ausearch -m AVC,USER_AVC -ts recent
[RO][PRIV][SENS] sudo journalctl | grep -i "avc:"

AppArmor

[RO] aa-status
[RO][PRIV][SENS] sudo journalctl -k | grep -i apparmor

Ein Unix-Dateirecht kann korrekt erscheinen, während eine Mandatory-Access-Control-Richtlinie den Zugriff trotzdem verhindert.

SELinux dauerhaft zu deaktivieren oder ein AppArmor-Profil ungeprüft abzuschalten ist keine geeignete Ursachenanalyse. Zuerst müssen die konkrete Ablehnung, der betroffene Kontext und die erwartete Richtlinie festgestellt werden.

[RO][PRIV][SENS] sudo lsof -p <PID>
[RO][PRIV][SENS] sudo lsof <PFAD>
[RO][PRIV][SENS] sudo lsof -i :<PORT>
[TEST][PRIV][LOG][SENS] sudo strace -p <PID>
[TEST][PRIV][LOG][SENS] sudo strace -f -o <DATEI> <BEFEHL>

strace kann sichtbar machen, ob ein Prozess beispielsweise an folgenden Vorgängen scheitert:

• Datei öffnen
• Namensauflösung
• Socket-Verbindung
• Berechtigungsprüfung
• Lesen oder Schreiben
• Warten auf ein Ereignis
• Start eines Kindprozesses

Die Ausgabe kann sehr umfangreich sein und sensible Daten enthalten. Außerdem kann Tracing das Zeitverhalten eines Prozesses beeinflussen.

Ein produktiver Prozess sollte nur mit geklärter Auswirkung verfolgt werden. Geheimnisse, Pfade und Nutzdaten können in der Ausgabe erscheinen.

Debian- und Ubuntu-basierte Systeme

[RO][SENS] dpkg -l
[RO] dpkg -S <PFAD>
[RO] apt-cache policy <PAKET>
[RO][PRIV] sudo dpkg --verify

RPM-basierte Systeme

[RO][SENS] rpm -qa
[RO] rpm -qf <PFAD>
[RO] rpm -V <PAKET>
[RO] dnf info <PAKET>

Zu prüfen sind:

• installierte Version
• Paketquelle
• Abhängigkeiten
• geänderte Paketdateien
• unvollständige Transaktion
• zurückgehaltene Pakete
• gemischte Repositorys
• Architektur
• Zeitpunkt des Updates
• erforderlicher Dienst- oder Systemneustart

Eine Paketverifikation zeigt Abweichungen, bewertet aber nicht automatisch, ob diese absichtlich, harmlos oder fehlerursächlich sind.

[RO] systemd-analyze
[RO] systemd-analyze blame
[RO] systemd-analyze critical-chain
[RO][SENS] journalctl -b
[RO][SENS] journalctl -b -1
[RO] systemctl --failed
[RO][PRIV][SENS] sudo dmesg --ctime

Bei Startproblemen sind zu prüfen:

• Bootloader
• Kernelparameter
• initramfs
• Root-Dateisystem
• /etc/fstab
• Geräte-UUIDs
• Mount-Zeitlimits
• systemd-Abhängigkeiten
• Netzwerkabhängigkeiten
• verschlüsselte Datenträger
• ausgefallene Dienste
• vorheriger Bootvorgang

systemd-analyze blame zeigt die Initialisierungszeit einzelner Units, beweist aber nicht allein, dass die oben angezeigte Unit den gesamten Start entsprechend verzögert hat. Parallelisierung und Abhängigkeiten müssen berücksichtigt werden.

[RO] date
[RO] timedatectl
[RO] timedatectl timesync-status
[RO][SENS] chronyc tracking
[RO][SENS] chronyc sources -v

Die verfügbaren Befehle hängen vom eingesetzten Zeitdienst ab.

Zu prüfen sind:

• Systemzeit
• Zeitzone
• Hardwareuhr
• aktive Synchronisation
• verwendete Zeitquelle
• Offset
• Erreichbarkeit der Zeitserver
• Virtualisierungszeitquelle
• Zeitänderungen in den Protokollen
• Zertifikatsgültigkeit
• Kerberos- oder Verzeichnisdienstabhängigkeiten

Eine falsche Systemzeit kann Protokollkorrelation, TLS, Authentifizierung, Datenbanken und geplante Aufgaben beeinträchtigen.

[RO][SENS] crontab -l
[RO][PRIV][SENS] sudo crontab -l
[RO][PRIV][SENS] sudo ls -la /etc/cron.*
[RO] systemctl list-timers --all
[RO] systemctl status <TIMER>.timer
[RO][SENS] journalctl -u <TIMER>.timer
[RO][SENS] journalctl -u <DIENST>.service

Typische Fehlerursachen:

• anderer Benutzerkontext
• eingeschränkte Umgebungsvariablen
• anderer PATH
• relative Pfade
• fehlende Ausführungsrechte
• nicht vorhandenes Arbeitsverzeichnis
• gesperrte Dateien
• Zeitzone
• überlappende Ausführungen
• fehlgeschlagene Weiterleitung der Ausgabe
• Timer oder Dienst deaktiviert

Ein Skript, das in einer interaktiven Shell funktioniert, muss unter Cron oder einem systemd-Timer nicht mit derselben Umgebung ausgeführt werden.

[RO] systemd-detect-virt
[RO][SENS] cat /proc/1/cgroup
[RO][SENS] lsns
[RO][SENS] docker ps
[RO][SENS] podman ps
[RO][SENS] docker inspect <CONTAINER>
[RO][SENS] docker logs <CONTAINER>

Bei Containerproblemen müssen Host und Container getrennt untersucht werden:

• Prozess im Container
• Containerzustand
• Restart Policy
• Exit-Code
• Healthcheck
• Logs
• Portveröffentlichung
• Container-Netzwerk
• DNS
• Volumes und Bind Mounts
• Benutzer-ID
• cgroup-Grenzen
• Host-Firewall
• Host-Speicherplatz
• Host-Kernel

Ein laufender Container beweist nicht, dass der darin betriebene Dienst erreichbar oder funktionsfähig ist. Ein Container verwendet grundsätzlich den Kernel des Hosts und ist keine vollständige virtuelle Maschine.

Syntax prüfen

[RO] bash -n <SKRIPT>

Ablauf mit Trace ausführen

[TEST][LOG][SENS] bash -x <SKRIPT>

In einem Skript kann die Trace-Ausgabe abschnittsweise aktiviert werden:

set -x
<ZU_UNTERSUCHENDE_BEFEHLE>
set +x

Zu prüfen sind:

• Shebang
• Shell-Kompatibilität
• Variablen
• Quoting
• Leerzeichen in Pfaden
• Rückgabecodes
• Pipelines
• relative Pfade
• Benutzerkontext
• Umgebungsvariablen
• Dateirechte
• parallele Ausführung

set -x kann Kennwörter, Tokens, Argumente und andere Geheimnisse in Protokolle schreiben. Es darf nicht unkontrolliert in produktiven Skripten aktiviert werden.

1. vollständige Fehlermeldung erfassen.
2. Benutzer, Host, Dienst und Zeitpunkt dokumentieren.
3. Umfang und Reproduzierbarkeit bestimmen.
4. letzte Änderung feststellen.
5. Distribution, Version, Kernel und Laufzeitumgebung erfassen.
6. Systemzeit und Uptime prüfen.
7. CPU, Load, Arbeitsspeicher und I/O überblicken.
8. Speicherplatz und Inodes prüfen.
9. betroffenen Prozess oder Dienst bestimmen.
10. Dienststatus und Abhängigkeiten prüfen.
11. Journal im passenden Zeitfenster auswerten.
12. Kernelmeldungen kontrollieren.
13. Konfiguration und Berechtigungen prüfen.
14. SELinux oder AppArmor berücksichtigen.
15. bei Netzwerkproblemen Adapter, Adressen und Routen prüfen.
16. DNS-Auflösung über den tatsächlich verwendeten Resolver testen.
17. Ports und Bind-Adressen prüfen.
18. Firewall und Paketpfad untersuchen.
19. bei Bedarf eng gefilterte Paketaufzeichnung erstellen.
20. Hypothese aus mehreren Befunden formulieren.
21. kleinste reversible Maßnahme planen.
22. Sicherung und Rückfallplan prüfen.
23. Änderung kontrolliert durchführen.
24. denselben Fehlerfall erneut testen.
25. Dienste, Logs und Monitoring nachkontrollieren.
26. temporäres Debugging deaktivieren.
27. Ursache, Maßnahme und Ergebnis dokumentieren.

Linux-Diagnosedaten können enthalten:

• Benutzernamen und Gruppen
• Hostnamen
• interne IP-Adressen
• MAC-Adressen
• DNS-Namen
• Prozessargumente
• Dateipfade
• Umgebungsvariablen
• Netzwerkverbindungen
• Paketmitschnitte
• SSH-Zugriffe
• Authentifizierungsereignisse
• Containerkonfigurationen
• Volume-Pfade
• Tokens und Zugangsdaten
• interne Anwendungsdaten

Vor einer Weitergabe müssen:

1. Zweck und Empfänger bestimmt werden.
2. nur erforderliche Daten erfasst werden.
3. Kennwörter, Schlüssel, Cookies und Tokens entfernt werden.
4. personenbezogene Angaben redigiert werden.
5. Paketmitschnitte besonders geschützt werden.
6. Dateien verschlüsselt übertragen werden.
7. Zugriffsrechte und Aufbewahrungsdauer festgelegt werden.
8. temporäres Debugging deaktiviert werden.
9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden.
10. externe Analysedienste organisatorisch freigegeben sein.

Shell-History, Prozesslisten und Trace-Ausgaben können Geheimnisse enthalten, wenn diese als Befehlsargumente übergeben wurden.

Ticket:
Datum und Uhrzeit:
Bearbeiter:

Hostname:
Distribution:
Version:
Kernel:
Architektur:
Physisch, VM oder Container:
Zeitzone:
Uptime:

Betroffener Benutzer:
Betroffener Dienst:
Betroffener Prozess:
PID:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Betroffene Systeme:
Letzte funktionierende Nutzung:
Letzte Änderung:

CPU-Auslastung:
Load Average:
Arbeitsspeicher:
Swap:
OOM-Ereignis:
Datenträgerauslastung:
Freier Speicher:
Freie Inodes:
I/O-Wartezeit:
Dateisystem:
Mount-Optionen:
Kernelmeldungen:

Dienststatus:
Unit-Datei:
Drop-ins:
Abhängigkeiten:
Startbenutzer:
Exit-Code:
Journal-Zeitraum:
Erste relevante Fehlermeldung:

Interface:
IP-Adresse:
Präfix:
Gateway:
Route:
DNS-Server:
DNS-Ergebnis:
Lauschadresse:
Port:
Firewall:
Paketaufzeichnung:

Dateipfad:
Eigentümer:
Gruppe:
Modus:
ACL:
SELinux:
AppArmor:
Geöffnete Dateien:
Strace verwendet:

Paket:
Installierte Version:
Paketquelle:
Verifikation:
Letztes Update:

Vermutete Ursache:
Belege:
Geplante Maßnahme:
Sicherung:
Rückfallplan:
Durchgeführte Änderung:
Testergebnis:
Monitoring:
Abschluss: