Windows Eventlog Forwarding einrichten

Hintergrund

Eine forensische Analyse nach einem Angriff kann nur gelingen, wenn es verwertbare Ereignisprotokolle von allen Systemen gibt. Aber auch bei der Erkennung eines Angriffs können solche Informationen enorm hilfreich sein. Werden diese Daten lokal auf den Systemen erhoben, dann hat das aber mehrere Nachteile:

• Das Quellsystem steht ggf. nicht mehr zur Verfügung (z.B. nach einer erfolgreichen Ransomware-Attacke)
• Man müsste sich ggf. mit einem privilegierten Konto an einem möglicherweise kompromittierten Endgerät anmelden, um die Logs auswerten zu können. Das ist definitiv keine gute Idee!
• Werden Logs von mehreren Systemen benötigt, dann ist der zeitliche Aufbau bei mehreren Einzelquellen zeitaufwändig. Und Zeit haben wir in solchen Situationen nicht!

Daher ist es besser, Ereignisdaten an einem zentralen Ort zu sammeln. Die „kleine Leute“-Lösung mit Windows Eventlog Forwarding möchte ich hier vorstellen. Da ich die Implementierung in meiner Produktionsumgebung bereits vor langer Zeit vorgenommen habe, nutze ich hier zur Demonstration meine Demo-Umgebung.

Basiskonfiguration

Im ersten Schritt bereite ich den Zielserver vor. Hier müssen wir über die Ereigniskonsole einen Service starten und konfigurieren. Das gelingt mit einem Klick auf die Subscriptions:

Kommen wir zum zweiten Schritt. Die Quellserver müssen wissen, dass sie die Eventlogs zu einem zentralen Server senden sollen. Diese Konfiguration übernimmt eine Gruppenrichtlinie. In dieser wird in einer Anweisungszeile die Definition angegeben:

Die Zeile enthält mindestens zwei Bausteine:

• Server=http://s-svr4.crashwork.global:5985/wsman/SubscriptionManager/WEC … damit wird der Zielserver und das Kommunikationsprotokoll definiert. Editiert einfach den FQDN des Servers.
• Refresh=60 … Mit dem Refresh-Intervall wird angegeben, wie oft der Quellserver beim SubscriptionServer nach neuen Definitionen für Abonnements nachfragen soll. Die 60 Sekunden haben sich bei mir bewährt.

Die neue GPO mappe ich auf meine Demo-Domain:

Ein gpupdate später weiß der erste Quellserver Bescheid und wird den Zielserver kontaktieren:

Anlegen von Abonnements

Bei jedem Refresh-Intervall fragen die Quellsysteme den Zielserver, welche Ereignisse sie übermitteln sollen. Die Definition nehme ich zentral am Zielserver vor, indem ich in der Ereignisanzeige eine neue Subscription anlege:

Jede Sammlung benötigt einen Namen und ein Ziel-Eventlog. Es gibt bereits ein vorbereitetes Logfile, das dafür genutzt werden kann. Es gibt 2 Arten für die Sammlung: Kollektor-basiert und Quellcomputer-basiert. Ich fahre mit der 2. Option ganz gut. Hier kann ich die Quellsysteme aus dem Active Directory auswählen. Es sind Einzelsysteme und Gruppen möglich:

Und natürlich dürfen die Eventfilter nicht fehlen. Diese sind ebenso gebaut, wie die lokal verfügbaren Filter:

Unter Advanced kann die Bandbreite optimiert und das Protokoll konfiguriert werden. Da für den Versand das Windows Remote Management genutzt wird und hierbei innerhalb der Domäne mit Kerberos authentifiziert und verschlüsselt wird, genügt mir der Standard:

Nach diesem Schritt ist das Abonnement einsatzbereit. Der erste Quellserver (mit dem gpupdate) und mein DC haben sich bereits innerhalb seiner 60 Sekunden Refresh-Intervall gemeldet. Das lässt sich im Status des Abos im Kontextmenü der neuen Subscription anzeigen:

Kontrollieren wir das einmal. Ich erzeuge einen Ereigniseintrag mit der ID 4625, indem ich mit falschen Anmeldedaten versuche, auf dem Server S-SVR1 eine cmd zu starten:

Lokal auf meinem Testserver wird dieser Eintrag direkt angezeigt:

Aber auf dem Zielserver kommt das Ereignis nicht an:

Woran liegt das? Auf zum Troubleshooting. 🙂 Auf jedem Quellsystem kann der Status der Übertragung geprüft werden. Dafür gibt es lokal ein eigenes Eventlog Microsoft-Windows-Eventlog-ForwardingPlugin/Operational. Hier suche ich erst einmal das Event mit der ID 104. Das zeigt, dass sich mein Server korrekt mit dem Zielserver verbunden hat. Das konnte ich auf dem Zielserver im Status auch schon sehen:

Das neuste Event zeigt aber einen Fehler beim Versuch der Übertragung an:

Der ErrorCode 5004 kommt bei geschützten Eventlogs wie dem SecurityLog oder auch dem SysmonLog auf, wenn der Netzwerkdienst dafür keine Leserechte hat. Diese können über die gleiche Gruppenrichtlinie wie zu Beginn konfiguriert werden. Tragt einfach die Gruppe Event Log Readers in die Liste ein und nehmt den Network Service als Member auf:

Diese Veränderung braucht auf dem Quellsystem ein gpupdate und einen Neustart, damit die neue Gruppenmitgliedschaft für die Identity Network Service greift. Danach sollte ein gewünschtes Event übertragen werden. Habt nach dem Neustart des Quellsystems einige Minuten Geduld:

Mein Demo-Zielsystem hat wohl beim Parsen der Ereignisse noch einige Schwierigkeiten. Da hilft bestimmt ein Windows Update 😉

Archivierung der Eventlogs

Wenn viele Systeme Eventlogs zu einem Zielsystem senden, dann wird das Ziel-Logfile schnell überlaufen. Hier solltet ihr unbedingt Vorkehrungen treffen! Zum einen sollte die Logfilegröße auf ein sinnvolles Maß erweitert werden. Und dazu solltet ihr das Eventlog archivieren, wenn es voll wird. Beide Optionen findet ihr in den Properties:

Die Archivlogs landen unter C:\Windows\System32\WinEvt\Logs und belegen in meinem Fall je Datei 2GB. Auf Laufwerk C: eines Windows Servers ist das keine gute Idee. Daher habe ich bei meinem Produktivsystem noch eine geplante Aufgabe erstellt, welche die Dateien in eine andere Partition verschiebt:

Im Zielverzeichnis schaut es dann so aus:

Einmal im Halbjahr zippe ich dann die Dateien in einem einzigen ZIP-Archiv. Die Kompressionsrate ist enorm. So kann ich alle meine Events dauerhaft aufbewahren. 🙂

Tipps

An dieser Stelle sind einige Tipps angebracht:

• Achtet darauf, dass ihr das Zielsystem nicht mit Schrott-Logs überlastet. Überlegt euch gut, welche Events ihr sehen wollt.
• Aber auch das Gegenteil ist der Fall: protokolliert ihr zu wenig, dann ist eine forensische Analyse schnell erledigt.
• Nehmt auf jeden Fall die sysmon-Logs mit auf. Eine Anleitung für die Subscription und die erforderlichen Hintergrundinformationen findet ihr hier: https://www.ws-its.de/implementierung-von-sysmon/
• Sichert das Zielsystem gut ab. Das ist in jedem Fall ein Tier-0-System, auf das nur die höchstberechtigten Admins zugriff haben dürfen. Fällt euer Active Directory, dann ist auch euer WEF-Server erledigt. Mit mehr Aufwand und einer PKI könnt ihr das System außerhalb des AD aufbauen.
• Isoliert den Zielserver mit einer guten Netzwerk-Segmentierung. Eingehend wird nur der TCP-Port 5985 benötigt.

Zusammenfassung

Wie ihr sehen könnt, ist der Aufbau eines Windows Eventlog Forwardings keine Raketenwissenschaft – wenn man weiß, wie es geht. Die GPO habe ich euch mal exportiert. Ebenso die geplante Aufgabe. Beides könnt ihr nach euren Wünschen anpassen: Dateien

Ein Windows Eventlog Forwarding ersetzt kein richtiges Log-Management oder gar ein SIEM, aber es ist besser als keine Lösung.

Stay tuned!