Ereignisprotokolle, Zeit und Beweissicherung

Im Vorfall stellt sich regelmäßig heraus, dass der interessante Zeitraum nicht mehr im Protokoll steht, dass die Uhr des Servers nicht stimmte oder dass die entscheidende Kategorie nie aufgezeichnet wurde. Alle drei Befunde entstehen lange vorher und lassen sich im Vorfall nicht beheben. Dieses Modul zeigt, was ein Windows-Server über sich erzählen kann — und die Einstellung, die nach „nichts geht verloren“ klingt und in Wahrheit dafür sorgt, dass ein voller Kanal jedes neue Ereignis verwirft.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Ein Protokoll ist eine Produktionsabhängigkeit

Ereignisprotokolle werden wie eine Nebenleistung behandelt — sie laufen mit, man sieht hinein, wenn etwas passiert ist. Im Vorfall stellt sich dann heraus, dass der interessante Zeitraum nicht mehr da ist, dass die Uhr des Servers nicht stimmte oder dass die entscheidende Kategorie nie aufgezeichnet wurde.

Alle drei Befunde haben dasselbe Muster: Sie entstehen lange vor dem Vorfall und lassen sich in ihm nicht mehr beheben. Beobachtbarkeit gehört deshalb in die Übernahme eines Servers, nicht in seine Störung — und das ist der Grund, warum dieses Modul mit Konfiguration anfängt und nicht mit Diagnose.

AbgrenzungDer Nachbartrack monitoring-incident-operations behandelt die Disziplin — Signalentwurf, Alarmierung, Incident-Koordination. Hier geht es um die Windows-Seite: welche Kanäle es gibt, wie groß sie sind, was in ihnen steht und wie man eine Zeitlinie daraus baut, der man trauen kann.

Kanäle, nicht ein Protokoll

Windows führt nicht ein Protokoll, sondern viele. Die drei klassischen — System, Anwendung, Sicherheit — sind nur der Anfang; darunter liegen hunderte anwendungs- und komponentenspezifische Kanäle, die einzeln aktiviert und dimensioniert sind.

wevtutil el: Listet alle Kanäle. Auf einem Server sind es mehrere hundert.
wevtutil gl <Kanal>: Zeigt Konfiguration eines Kanals: aktiviert, Pfad, Maximalgröße, Aufbewahrungsmodus.
Get-WinEvent -ListLog *: Dasselbe als Objekte, mit Datensatzzahl und aktueller Dateigröße.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41}: Der gezielte Zugriff — Filter auf Serverseite statt Where-Object danach.

Warum der Filter am Anfang stehen mussGet-WinEvent -LogName Security | Where-Object … liest erst das gesamte Protokoll und filtert dann. Auf einem Sicherheitsprotokoll mit Millionen Einträgen dauert das Minuten und belastet den Server im Vorfall zusätzlich. -FilterHashtable gibt den Filter an den Dienst weiter und liefert in Sekunden. Der Unterschied ist im Alltag Bequemlichkeit und im Vorfall der Unterschied zwischen Antwort und Warten.

Die drei klassischen Protokolle tragen dabei unterschiedliche Arten von Aussagen. Im Systemprotokoll melden Treiber, Dienste und Betriebssystemkomponenten — dort steht, was der Server selbst über sich sagt. Im Anwendungsprotokoll melden installierte Programme, in einer Qualität, die vom Hersteller abhängt und stark schwankt. Das Sicherheitsprotokoll ist das einzige, dessen Inhalt vollständig von der Überwachungsrichtlinie bestimmt wird: Es enthält genau das, was jemand einzuschalten entschieden hat, und nichts sonst.

Die Größe bestimmt den Zeithorizont

Jeder Kanal hat eine maximale Dateigröße. Ist sie erreicht, entscheidet der Aufbewahrungsmodus, was passiert. Die Größe ist damit keine Speicherfrage, sondern die Antwort auf die Frage: Wie weit zurück kann dieser Server Auskunft geben?

Die Rechnung ist einfach und wird selten gemacht: Ereignisse pro Tag mal durchschnittliche Größe ergibt den Bedarf pro Tag. Wer 30 Tage rückblicken will, braucht das Dreißigfache. Auf einem Server mit aktivierter Anmeldeüberwachung sind mehrere hundert Megabyte für das Sicherheitsprotokoll keine Übertreibung, sondern die Untergrenze — und die Voreinstellung liegt weit darunter.

Wie weit zurück kann dieser Server Auskunft geben

Szenario

Nach einem Vorfall soll geklärt werden, wer sich in den letzten drei Wochen an einem Anwendungsserver angemeldet hat. Das Sicherheitsprotokoll steht auf der Voreinstellung und ist voll.

Anforderungen

Die Frage soll ohne Zusatzwerkzeug beantwortet werden.
Für die übrigen Server soll daraus eine Vorgabe entstehen.

Schritte

Get-WinEvent -ListLog Security — Maximalgröße und aktuelle Datensatzzahl ablesen.
Das älteste noch vorhandene Ereignis abfragen und seinen Zeitstempel notieren.
Ergebnis: Der Rückblick reicht knapp vier Tage. Die Frage nach drei Wochen ist auf diesem Server nicht beantwortbar.
Ereignisse pro Tag mal durchschnittliche Größe rechnen und mit dem gewünschten Zeitraum multiplizieren.
Die errechnete Größe setzen — und den Aufbewahrungsmodus dabei ausdrücklich auf Überschreiben prüfen.

Merksatz: Der Rückblickzeitraum ist keine Eigenschaft von Windows, sondern eine Einstellung, die jemand getroffen hat — meistens niemand. Er lässt sich in einer Minute messen und danach begründet festlegen; nach dem Vorfall lässt er sich nicht mehr verlängern.

Der Aufbewahrungsmodus, der neue Ereignisse verwirft

Beim Dimensionieren eines Kanals stellt man zwei Dinge ein: die Maximalgröße und den Aufbewahrungsmodus. Der zweite ist die Falle.

wevtutil sl <Kanal> /ms:<Bytes>: Setzt die Maximalgröße.
/rt:false: Voreinstellung. Ist der Kanal voll, überschreiben neue Ereignisse die ältesten.
/rt:true: Vorhandene Ereignisse bleiben erhalten — und eingehende werden verworfen.

Was `/rt:true` wirklich tutDie Dokumentation formuliert es unmissverständlich: Erreicht ein Protokoll seine maximale Größe und steht der Aufbewahrungsmodus auf true, bleiben vorhandene Ereignisse erhalten und eingehende Ereignisse werden verworfen. Wer diese Einstellung wählt, weil sie nach „nichts geht verloren“ klingt, bekommt das Gegenteil: Der Server hört auf zu protokollieren, und zwar still. Ab diesem Moment gibt es über alles Neue keine Aufzeichnung mehr — die interessanteste Zeit ist immer die, die gerade läuft.

Wer Ereignisse wirklich aufheben will, exportiert sie: wevtutil epl schreibt ein Protokoll in eine Datei, wevtutil al archiviert es in einer Form, die sich auch ohne den erzeugenden Herausgeber lesen lässt. Das ist der belastbare Weg — nicht ein Schalter, der die Aufzeichnung anhält.

Anmeldetypen lesen

Die Kennung 4624 meldet eine erfolgreiche Anmeldung. Ihr Aussagewert steckt in einem Feld: dem Anmeldetyp. Er unterscheidet Vorgänge, die von außen betrachtet identisch aussehen.

2 — Interactive: Anmeldung an der Konsole des Rechners.
3 — Network: Zugriff über das Netz, etwa auf eine Freigabe.
4 — Batch: Von einem Stapelverarbeitungsdienst gestartet, typischerweise die Aufgabenplanung.
5 — Service: Der Dienststeuerungs-Manager hat einen Dienst gestartet.
10 — RemoteInteractive: Remotedesktop.

Warum das im Alltag zähltEin Dienstkonto sollte Typ 5 zeigen, ein geplanter Task Typ 4. Erscheint dasselbe Konto plötzlich mit Typ 10, hat sich jemand damit per Remotedesktop angemeldet — das ist keine Fehlkonfiguration, sondern eine Verhaltensänderung. Die Frage „welcher Anmeldetyp ist für dieses Konto normal“ ist deshalb eine der wenigen, die man ohne Zusatzwerkzeug beantworten kann und die eine echte Aussage trägt.

Zwei weitere Typen sind erwähnenswert, weil sie leicht falsch gelesen werden. Typ 8 heißt NetworkCleartext und klingt nach einem Klartextkennwort im Netz — die Dokumentation stellt ausdrücklich klar, dass die eingebauten Authentifizierungspakete Anmeldeinformationen vor dem Versand hashen und die Anmeldeinformationen das Netz nicht im Klartext durchqueren. Typ 9 heißt NewCredentials und entsteht, wenn ein Prozess mit anderen Anmeldeinformationen gestartet wird. Beide sind für sich unauffällig und werden regelmäßig als Fund gemeldet, der keiner ist.

Ohne Zeit keine Korrelation

Eine Zeitlinie über mehrere Server ist nur so gut wie die Uhren, aus denen sie stammt. Weichen zwei Server um Minuten ab, entstehen kausale Aussagen, die falsch herum sind — und niemand sieht es, weil beide Protokolle in sich stimmig aussehen.

w32tm /query /status — Zustand des Zeitdienstes, Abweichung, letzter Abgleich.
w32tm /query /source — von wem holt dieser Server seine Zeit?
w32tm /query /configuration — die Laufzeitkonfiguration samt Herkunft der Einstellungen.
w32tm /monitor — vergleicht mehrere Rechner einer Domäne gegeneinander.
w32tm /resync — erzwingt einen Abgleich.

Der Zusammenhang zu KerberosZeit ist nicht nur eine Frage der Auswertbarkeit. Die Richtlinieneinstellung für die maximale Toleranz des Computertakts steht standardmäßig auf fünf Minuten; darüber verwirft Kerberos die Zeitstempel, und die Anmeldung scheitert mit einer Meldung, die nach falschem Kennwort aussieht. Ein Zeitproblem zeigt sich deshalb oft zuerst als Anmeldeproblem — und wird dann an der falschen Stelle gesucht.

Ein zweiter Fallstrick betrifft die Anzeige. Ereignisse werden intern in koordinierter Weltzeit gespeichert und in der Ortszeit des betrachtenden Rechners dargestellt. Wer Protokolle von Servern in verschiedenen Zeitzonen nebeneinanderlegt oder eine exportierte Datei auf einem anderen Rechner öffnet, vergleicht dann Zeitstempel, die sich um Stunden unterscheiden, obwohl die Uhren stimmen. In einer Zeitlinie über mehrere Standorte gehört deshalb eine ausdrückliche Festlegung dazu, in welcher Zeitzone sie geführt wird.

Die Domänenzeithierarchie

In einer Domäne holt sich ein Mitgliedsserver die Zeit nicht aus dem Internet, sondern aus der Domänenhierarchie. Der Zeitclienttyp heißt dafür NT5DS. Ein Domänencontroller holt sie von einem übergeordneten, und ganz oben steht der Betriebsmaster für die PDC-Emulation der Stammdomäne — der ist als einziger auf eine externe Zeitquelle konfiguriert.

Der Server, der nie zurückkehrtDie häufigste Abweichung entsteht bei Servern, die einmal nicht in der Domäne waren. Bei der Einrichtung wurde eine feste Zeitquelle eingetragen, und diese manuelle Konfiguration bleibt nach dem Domänenbeitritt bestehen — der Server synchronisiert weiter gegen seinen alten Peer statt gegen die Hierarchie. w32tm /query /source zeigt es in einer Zeile. Zurückgeholt wird er mit w32tm /config /syncfromflags:DOMHIER /update.

Ein Detail für die Firewall: Der eingebaute Zeitclient kann laut Dokumentation nur UDP 123 als Quellport benutzen. Eine Regel, die ausgehend nur bestimmte Quellports zulässt, bricht den Zeitabgleich — mit allen Folgen, die zwei Abschnitte weiter oben stehen.

Weiterleitung: was sie nachholt

Ereignisse an eine zentrale Stelle weiterzuleiten löst mehrere Probleme auf einmal: Man sucht an einem Ort, die Aufbewahrung ist unabhängig vom Server, und ein Angreifer, der lokal Spuren beseitigt, erwischt die weitergeleitete Kopie nicht mehr.

Was sie nicht nachholtSie holt nicht nach, was nie aufgezeichnet wurde. Eine Kategorie, deren Überwachung auf dem Server nicht aktiviert ist, erzeugt kein Ereignis — und damit auch keines zum Weiterleiten. Und sie holt nicht rückwirkend: War die Weiterleitung unterbrochen, entsteht eine Lücke, deren Größe davon abhängt, ob das lokale Protokoll in der Zwischenzeit übergelaufen ist. Genau hier greift die Dimensionierung aus Abschnitt drei — das lokale Protokoll ist der Puffer der Weiterleitung.

Zwei Betriebsmodi gibt es: Beim Abholen fragt der Sammler die Quellen, beim Zusenden melden sich die Quellen beim Sammler. Für viele Server über Netzgrenzen hinweg ist das Zusenden der praktikablere Weg, weil der Sammler die Quellen nicht erreichen muss. Die Entscheidung ist Betriebsarchitektur, nicht Geschmack — sie bestimmt, wer wen erreichen können muss.

Für die Praxis ergibt sich daraus eine Reihenfolge beim Aufbau: zuerst die Überwachungsrichtlinie, damit überhaupt entsteht, was gebraucht wird; dann die lokale Kanalgröße, damit ein Ausfall der Weiterleitung nicht sofort eine Lücke erzeugt; und erst dann die Weiterleitung selbst. Wer umgekehrt anfängt, hat einen Sammler, der zuverlässig überträgt — und ein Ergebnis, dessen Vollständigkeit von Bedingungen abhängt, die niemand geprüft hat.

Beweise vor Eingriff

Bei einem Verdacht auf einen Sicherheitsvorfall stehen zwei Ziele gegeneinander: die Ausbreitung stoppen und den Zustand erhalten. Beides gleichzeitig geht nur, wenn die Reihenfolge stimmt — und der Neustart, der beides zunichtemacht, ist der häufigste erste Reflex.

Flüchtig zuerst: Was ein Neustart mitnimmt, ist nach dem Neustart nicht mehr beschaffbar.

Flüchtig: Arbeitsspeicher, laufende Prozesse, offene Verbindungen, angemeldete Sitzungen. Verschwindet mit dem Neustart.
Kurzlebig: Ereignisprotokolle, temporäre Dateien, Zwischenspeicher. Überlebt den Neustart, aber nicht unbegrenzt.
Dauerhaft: Dateien auf der Platte, Registry, Sicherungen. Bleibt, solange niemand aufräumt.

Eingrenzen ohne zu löschenDie Netzverbindung eines Servers zu trennen oder ein Konto zu sperren stoppt die Ausbreitung und lässt den flüchtigen Zustand intakt. Ein Neustart, ein Zurücksetzen aus der Sicherung oder das Löschen einer verdächtigen Datei tun das Gegenteil. Die Frage vor jeder Erstmaßnahme lautet deshalb: Nimmt sie mir Beweise weg, die ich in einer Stunde brauche?

Was konkret gesichert wird, hängt vom Verdacht ab, aber vier Dinge lohnen fast immer: die Liste der laufenden Prozesse mit ihren Befehlszeilen, die offenen Netzverbindungen mit dem zugehörigen Prozess, die angemeldeten Sitzungen und ein Export der relevanten Ereigniskanäle. Alle vier sind mit Bordmitteln in wenigen Minuten erzeugt — Get-CimInstance Win32_Process, Get-NetTCPConnection, query user und wevtutil epl — und alle vier sind nach einem Neustart entweder weg oder deutlich weniger wert.

Eine Zeitlinie bauen

Eine Zeitlinie ist mehr als eine sortierte Ereignisliste. Sie ordnet Ereignisse aus mehreren Quellen einer gemeinsamen Uhr zu und trennt dabei drei Dinge, die leicht durcheinandergeraten.

Wann ist etwas passiert — der Zeitpunkt des Ereignisses selbst.
Wann wurde es aufgezeichnet — bei weitergeleiteten Ereignissen ein anderer Zeitpunkt.
Wann wurde es bemerkt — der Alarm, das Ticket, der Anruf. Fast immer der späteste.

Das Ereignis, das nach hinten datiertEin Beispiel aus dem Modul über Start und Wiederherstellung: Die Kennung 41 für einen unerwarteten Neustart wird beim nächsten Start geschrieben. Ihr Zeitstempel liegt also nach dem Ausfall, nicht während. Wer sie in eine Zeitlinie einsortiert, ohne das zu wissen, verschiebt den Ausfall um die Dauer der Downtime nach hinten — und sucht die Ursache im falschen Fenster.

Praktisch beginnt eine Zeitlinie nicht mit dem ersten Ereignis, sondern mit dem letzten bekannten guten Zustand. Von dort vorwärts zu arbeiten ist mühsamer als vom Symptom rückwärts, hat aber einen Vorteil: Man findet die Ereignisse, nach denen man nicht gesucht hätte. Rückwärts vom Symptom findet man das, was zur eigenen Hypothese passt — und hört auf, sobald etwas dazu passt. Beide Richtungen haben ihren Platz; die Rückwärtssuche ist schneller, die Vorwärtssuche ist gründlicher.

Zwei Kennungen, die man kennt

Zwei Ereignisse verdienen es, auswendig gewusst zu werden, weil sie eine Aussage tragen, die keine Interpretation braucht.

1102: Das Sicherheitsprotokoll wurde geleert. Es gibt keinen betrieblichen Grund, aus dem das im Normalbetrieb passiert.
4624 mit unerwartetem Anmeldetyp: Ein bekanntes Konto meldet sich auf eine Art an, die für dieses Konto nicht vorgesehen ist.

Warum 1102 anders ist als andere EreignisseDie meisten Kennungen sagen etwas über einen Vorgang. Diese sagt etwas über die Aufzeichnung selbst — und zwar, dass jemand sie unterbrochen hat. Sie ist damit eine der wenigen, die ohne weiteren Kontext eine Untersuchung rechtfertigt. Und sie ist der Grund, warum die Weiterleitung an eine zentrale Stelle mehr ist als Bequemlichkeit: Das geleerte lokale Protokoll ist weg, die weitergeleitete Kopie nicht.

Für beide gilt dieselbe Einschränkung: Sie entstehen nur, wenn die zugehörige Überwachung aktiviert ist. Das Leeren des Sicherheitsprotokolls wird protokolliert, weil es zur Grundausstattung gehört — viele der Kennungen, die in Runbooks stehen, tun das nicht. Bevor ein Runbook eine Kennung nennt, gehört auf den betroffenen Servern geprüft, ob sie dort überhaupt erzeugt wird. Ein Runbook, das auf ein nie erzeugtes Ereignis wartet, wartet stillschweigend für immer.

Was in die Übernahme gehört

Alles an diesem Modul lässt sich im Vorfall nicht mehr herstellen. Die folgende Liste ist deshalb Teil der Übernahme eines Servers und kostet einmalig ein paar Minuten.

Kanalgrößen prüfen und am gewünschten Rückblickzeitraum ausrichten, nicht an der Voreinstellung.→Aufbewahrungsmodus prüfen — /rt:true ist fast nie gewollt.→Überwachungsrichtlinie prüfen: Wird aufgezeichnet, was später gebraucht wird?→w32tm /query /source — synchronisiert der Server gegen die Domänenhierarchie?→Weiterleitung prüfen: Kommt an, was ankommen soll, und wie groß ist der lokale Puffer?→Den Weg zu einer Konsole ohne Betriebssystem festhalten — für den Fall, dass der Server nicht mehr antwortet.

Schritt 2 ist der, der still fehlschlägt: Ein Kanal mit /rt:true sieht in jeder Übersicht gesund aus und zeichnet seit Wochen nichts mehr auf.

Der PreisGrößere Protokolle kosten Plattenplatz, eine schärfere Überwachungsrichtlinie kostet Ereignisvolumen, und beides zusammen kostet in der Weiterleitung Bandbreite und Speicher am Sammler. Wer alles überall scharf stellt, erzeugt eine Datenmenge, die niemand mehr auswertet — und bezahlt sie trotzdem. Der tragfähige Zuschnitt ist ungleich: viel auf den Servern, deren Kompromittierung teuer wäre, wenig auf den übrigen.

Diese Liste gehört in dieselbe Übergabeprüfung wie die Punkte aus dem Modul über Start und Wiederherstellung — Wiederherstellungsumgebung, Startspeichersicherung, Auslagerungsdatei, Konsolenzugang. Beide Listen beantworten dieselbe übergeordnete Frage: Was kann dieser Server im Ernstfall über sich sagen, und wie komme ich an ihn heran? Sie zusammen abzuarbeiten kostet je Server eine Viertelstunde und ist der Unterschied zwischen einer Untersuchung und einer Vermutung.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität13 Primärquellen · zuletzt geprüft: 2026-09-04