Grundlagen der zentralen Protokollerfassung mit WEF und WEC

Letzte Woche haben wir die Grundlagen des Ereignisprotokolls behandelt: Sicherzustellen, dass alle Ihre Systeme Protokolle über die wichtigen Ereignisse oder Aktivitäten auf ihnen schreiben. Diese Woche behandeln wir die Grundlagen der zentralen Sammlung dieser Ereignisprotokolle auf einem Windows Event Collector (WEC)-Server, der dann alle Protokolle an Elastic Security weiterleitet.

WEF und WEC

Moderne Windows-Versionen beinhalten die Windows-Remoteverwaltungsdienste (WinRM), die das WS-Management-Protokoll (WSman) implementieren. Um die Komplexität der Akronyme noch zu erhöhen: All dies ist Teil der Windows-Verwaltungsinstrumentation (WMI). Eine Komponente von WinRM ist der Windows-Ereignisweiterleitungsdienst (WEF). Daher müssen WinRM und die zugehörigen Dienste aktiviert sein. WEF kann Windows-Ereignisprotokolle an einen Windows-Server weiterleiten, auf dem der Windows-Ereignissammler (WEC) ausgeführt wird.

Es gibt zwei Weiterleitungsmodi:

1. Quelleinitiiert: Der WEF-Dienst verbindet sich mit dem WEC-Server.
2. Vom Collector initiiert: Der WEC-Dienst stellt eine Verbindung zum WEF-Dienst her.

Beide verwenden WSman zum Weiterleiten der Protokolle und setzen voraus, dass WinRM ausgeführt wird.

Bei der Einrichtung von WEF und WEC gibt es einige Fallstricke und Hürden. Mit unserem WEC-Kochbuch lassen sich diese vermeiden. Um jedoch einen umfassenderen Überblick und einen tieferen Kontext zu erhalten, werden wir sie hier sowie die im Kochbuch vorgestellte Lösung erläutern.

Ereignisprotokolldatei „Weitergeleitete Ereignisse“

Im Windows-Ereignisprotokollsystem gibt es Kanäle. Diese Kanäle basieren auf einer Ereignisprotokolldatei, die alle in diesem Kanal gespeicherten Ereignisse enthält. Ein Windows-System verfügt über eine Reihe vordefinierter Kanäle, und Anwendungen können eigene Kanäle hinzufügen, indem sie neue „Anbieter“ registrieren.

Das bedeutet, dass ein WEC-Server standardmäßig nur die gleichen Kanäle für seine eigenen Protokolle besitzt wie ein normaler Windows-Server. Wo sollen dann all die Protokolle gespeichert werden, die an den WEC-Server weitergeleitet werden? Es gibt drei Möglichkeiten; sehen wir sie uns an:

1. Speichern im lokalen Kanal, der dem Remote-Kanal entspricht (d. h. die Ereignisse des Remote-„Security“-Kanals werden im lokalen „Security“-Kanal des WEC gespeichert). 

Fallstricke:

• Alle deine entfernten Logs sind mit deinen lokalen Logs vermischt 
• Der WEC-Server kann seine eigenen Ereignisprotokolle an diesen Kanal schleifen.
• Logbuchverwaltung und Zugriffskontrolle sind sehr schwierig

2. Speichere alle entfernten Logs im lokalen Kanal „Weitergeleitete Events“.

Fallstricke:

• Schlechte Schreibleistung, da alle Schreibvorgänge in eine einzige Datei erfolgen.
• Schlechte Such-/Leseleistung, da Ereignisse nicht in separaten Dateien partitioniert werden.
• Mangelhaftes Datenlebenszyklusmanagement, da dies pro Protokolldatei erfolgt, werden daher alle weitergeleiteten Ereignisse gleich behandelt.
• Schlechte Ressourcennutzung des WEC-Servers, da die gesamte Arbeit auf eine einzige Datei beschränkt ist.
• Bei mangelhafter Zugriffsverwaltung würden separate Dateien differenzierte Dateizugriffskontrollen ermöglichen.
• Mangelhafte Abdeckung/Transparenz – aufgrund der oben genannten Probleme schränken viele Anbieter die Weiterleitung von Ereignisprotokollen stark ein, wodurch Lücken in ihrer Transparenz entstehen.

3. Erstellen Sie neue Kanäle für den WEC-Server. 

Das ist nicht so offensichtlich, wie es scheinen mag, und man kann es den meisten nicht verzeihen, wenn sie nicht wüssten, dass es diese Möglichkeit gibt. 

Viele WEC-Server wurden mit den Optionen 1 oder 2 (siehe oben) eingerichtet, bis das interne Sicherheitsteam von Microsoft vor etwa 15 Jahren einen Blogbeitrag darüber veröffentlichte, wie es das Windows SDK zur Implementierung von Option 3 nutzte. Hier ist eine ähnliche Überarbeitung aus dem Jahr 2016.

Neue WEC-Veranstaltungskanäle

Da wir nun beliebige Ereigniskanäle erstellen können, stellt sich die Frage: Was sollten wir erstellen? Wie sollten wir unseren WEC-Server organisieren und architekturieren? Es gibt viele Ansätze – das WEC Cookbook gruppiert Unternehmensressourcen, sodass Sie die Zugriffskontrolle Ihrer Protokolle und den Datenlebenszyklus entsprechend verwalten können.

Bevor wir tiefer in die Materie einsteigen, betrachten wir einen anderen Ansatz. Einige von Ihnen kennen vielleicht die WEC-Architektur und -Richtlinien von Palantir. Hier wird für jeden Ereignisprotokolltyp ein eigener Kanal erstellt: PowerShell, WMI, DNS, Firewall usw. Diese Kanäle enthalten Protokolle aller Asset-Typen (Domänencontroller, Domänenserver, Domänenarbeitsstationen) und Abteilungen/Geschäftseinheiten/Organisationseinheiten. Sie sind nicht hierarchisch organisiert und würden daher in der Ereignisanzeige als lange Liste angezeigt. Die Kanäle verfügen daher auch über eigene WEC-Abonnements. Palantir bietet außerdem eine empfohlene Überwachungsrichtlinie an. 

Ich möchte gerne auf andere Ansätze hinweisen, wie zum Beispiel diesen von Palantir, da es keine Einheitslösung gibt und deren Ansatz möglicherweise besser zu Ihrer Organisation passt als der in unserem Kochbuch beschriebene.

Wer sich die Kanalliste von Palantir angesehen hat, dem ist sicherlich das Format „WEC#-Irgendwas“ aufgefallen, bei dem die Zahl „#“ alle sieben Kanäle erhöht wird. Das liegt daran, dass im Windows-Ereignisprotokollsystem Kanäle von einem sogenannten „Anbieter“ definiert werden und maximal acht Kanäle definiert werden können.

Ein kleiner Fehler im Tool „ecmangen“, das wir alle, die wir keine Windows-SDK-Entwickler sind und uns mit Sicherheitsthemen auskennen, nutzten, machte es jedoch frustrierend, mehr als sieben Kanäle pro Anbieter darin zu haben.

Statt die zahlreichen Fehler zu beheben, hat Microsoft ecmangen offenbar aus dem Windows SDK entfernt. Das bedeutet, dass Sie entweder ein älteres SDK verwenden oder die Manifest-XML-Datei selbst erstellen müssen – beispielsweise mit Ihrem bevorzugten XML-Editor.

Wie alle anderen habe auch ich ursprünglich ecmangen verwendet und mich zur Vereinfachung auf sieben Kanäle beschränkt. Das aktuelle Kochbuch basiert auf PowerShell-Skripten, die das XML generieren. Ecmangen wird nicht mehr benötigt, daher können Sie bei Bedarf acht Kanäle verwenden, obwohl das Kochbuch weiterhin nur die sieben empfohlenen Kanäle nutzt.

Hinweis: Stellen Sie sich einen Anbieter als eine Box mit acht Kanälen vor, wobei jeder Kanal letztlich eine separate Protokolldatei ist.

Nach Vermögenswerten organisieren

Da Sie beliebig viele Provider verwenden können, lässt sich dies zur Organisation nach Assets nutzen. In Ihrer AD-Umgebung haben Sie Domänenmitglieder wahrscheinlich bereits nach Asset-Typ (z. B. Domänenserver, Domänencontroller, Workstations usw.) und/oder nach der Abteilung (oder besser: Organisationseinheit) gruppiert, in der sich diese Assets befinden.

Im Kochbuch können Sie also ganz einfach Anbieter erstellen, die zur Organisation Ihres AD passen, ähnlich wie Anbieter pro Abteilung (Business-Unit oder OU) und/oder pro Asset-Typ und/oder pro Asset-Kritikalität (Labor/Test/Produktion).

Durch die Trennung nach Anlagentyp ergibt sich der zusätzliche Vorteil einer besseren Verwaltung der Zugriffskontrolle und des Log-Lebenszyklus. Wenn Sie die Logs eines bestimmten Anlagentyps einsehen müssen, wissen Sie genau, wo sie sich befinden.

Um es einfach zu machen, erhalten dann alle Anbieter denselben Satz von (bis zu acht Kanälen). Dann werden Systeme einem Anbieter (über OU) zugeordnet und die Ereignisprotokolle auf diesem System werden den Kanälen dieses Anbieters zugeordnet.

Das Skript „wec_config.ps1“, das zur Konfiguration des WEC-Servers entsprechend Ihrer AD-Architektur verwendet wird, enthält standardmäßig einige definierte Provider und Asset-Zuordnungen:

• Domänencontroller: Ich denke, die Mitgliederzuordnung ist hier klar.
• Domänenserver: Die Server in Ihrer Domäne
• Domänenclients: Benutzerarbeitsplätze (Desktop-PCs/Laptops)
• Domänenprivilegiert: Systeme mit höheren Privilegien (z. B. Jumphosts oder WEC-Server)
• Domänenmitglieder: Sammelkategorie für normale Domänenmitglieder; nicht in den anderen Gruppen
• Domain Sonstiges: Verschiedenes, für Hosts, die nicht passen

Sie werden ermutigt, die Liste zu verfeinern und zu bearbeiten, um sie an Ihre AD-Umgebung anzupassen.

Dann lautet die Standard-Channel-Liste:

• Anwendung: "Anwendung" und ähnliche Protokolle
• Sicherheit: "Security" und ähnliche Protokolle
• Sysmon: "Microsoft-Windows-Sysmon/Operational"
• System: "System", "HardwareEvents", DNS-Client, DHCP-Client, "Setup" und ähnliche Protokolle
• Skript: "Windows PowerShell" und ähnliche Protokolle
• Dienst: DNS-Server, DHCP-Server und andere Serviceprotokolle
• Verschiedenes: Weitere sonstige Protokolle

Auch hier können Sie dies nach Ihren Bedürfnissen anpassen.

WEC-Abonnements

Ein WEC-Abonnement definiert Folgendes:

• Ein Ereignisprotokollfilter (XPath), der auswählt, welche Ereignisse weitergeleitet werden sollen.
• Ein Zielkanal, der angibt, wo die empfangenen Ereignisse auf dem WEC-Server gespeichert werden sollen.
• Typ:
  • Vom Collector initiiert, verbindet sich der WEC mit dem WEF-Dienst.
    • Zielcomputer, eine Liste der Computer, mit denen eine Verbindung hergestellt werden soll
  • Die WEF-Verbindung zum WEC-Server wird von der Quelle initiiert.
    • Computergruppen, die AD-Gruppen, deren (Computer-)Mitglieder auf dieses Abonnement zugreifen können.
• Optionen zur Ereignisübermittlung zur Steuerung von Bandbreite/Latenz und/oder HTTP/HTTPS
• Formattyp: RenderedText oder nur das Event-XML

Die Cookbook-Skripte (insbesondere setup_subscriptions.ps1) konfigurieren das Ereignis-XML-Format. Da diese Dateien deutlich kleiner sind, ergibt sich ein höherer Durchsatz, mehr gespeicherte Protokolle, geringere Last und ein geringerer Bandbreitenbedarf. Der Nachteil besteht jedoch darin, dass die Ereignisanzeige keine Textbeschreibung der Nachricht in Ihrer Sprache anzeigen kann, wenn der Quellanbieter (auf dem Remote-System) nicht lokal im Ereignisprotokollsystem des WEC-Servers registriert ist. Das Senden von gerenderten Textereignissen ist jedoch so ressourcenintensiv, dass es sich kaum lohnt.

Ich habe zu Beginn erwähnt, dass WEF eine Funktion von WinRM ist. Nun, diese WinRM-Komponente läuft als der lokale "Network Service"-Nutzer des lokalen Systems. Das bedeutet, dass WEF die meisten Ihrer Systemprotokolle nicht lesen kann und Ihr WEC-Server eine sehr unbestimmte Event-ID 111-Nachricht und keine weiteren Logs erhält. Aus diesem Grund führt das Kochbuch Sie durch die Erstellung eines GPO, um "Network Service" zur lokalen Gruppe "Event Log Readers" hinzuzufügen.

Wie bekommt WinRM die Konfiguration für WEF? Im gleichen GPO wie oben veröffentlicht, veröffentlichen wir auch eine WSman-URL, die alle WEC-Abonnements auf diesem Server auflistet. Tatsächlich können wir mehrere WSman-Abonnement-URLs von mehreren WEC-Servern auflisten, und der WEF-Dienst versucht, sie alle abzurufen und auszuführen – so werden redundante WEC-Server ermöglicht.

Alle Abonnements? Ich möchte nicht, dass meine Arbeitsstation Ereignisprotokolle an die Protokolldateien meines Domain Controllers sendet! Die WSman-Einträge, die ein Abonnement repräsentieren, erhalten AD-Gruppenberechtigungen, wie sie in der Abonnement-Konfiguration eingerichtet sind. Das bedeutet, dass, wenn der Computer, auf dem WEF läuft, kein Mitglied einer AD-Gruppe ist, die die Berechtigung zum Lesen des Abonnements hat, er das Abonnement nicht ausführen kann. Es bedeutet auch, dass Sie, wenn Sie nicht vorsichtig sind und ein Computer Mitglied von mehr als einer WEC-Abonnement-AD-Gruppe ist, mehrere Kopien desselben Ereignisprotokolls von diesem WEF-Host auf Ihrem WEC erhalten!

Computergruppen? Aber ich möchte Computer basierend auf der OU mappen, in der sie platziert sind! Leider funktionieren WEF/WEC/WinRM/WSman nicht so. Das Kochbuch bietet jedoch einen Mechanismus, um die Mitgliedschaft einer bestimmten Gruppe mit den angegebenen OU-Standorten synchron zu halten. So können Sie so tun, als würde alles über OU erledigt!

Alles zusammenführen

Es gibt viel Komplexität und viele bewegliche Teile, die beim Einrichten von WEF und WEC für gute Beobachtbarkeits- oder Sicherheits-Anwendungsfälle richtig umgesetzt werden müssen.

Keine Sorge, denn unser Kochbuch ist hier, begleitet von einer Reihe von Powershell-Skripten , die die meisten Schritte automatisieren. Das bedeutet, dass weniger Spielraum für Fehler bleibt, Handlungen reproduzierbar sind und Fehler daher leichter zu beheben sind.

Alles beginnt mit dem Skript wec_config.ps1, das Sie nach Belieben bearbeiten können. Alle nachfolgenden Skripte bauen darauf auf. So können Sie beispielsweise in wec_config.ps1 den Ereignisprotokollfilter ändern, der festlegt, welche Ereignisprotokolle weitergeleitet werden, und anschließend setup_subscriptions.ps1 erneut ausführen, um die Änderung anzuwenden.

Schauen wir uns an, was die Skripte bewirken (das Kochbuch geht viel ausführlicher darauf ein, wie man sie verwendet):

• wec_config.ps1 – Die Konfiguration deines WEC-Servers, die von den anderen Skripten stammt
• gen_manifest.ps1 – Dies erstellt das Manifest-XML, das alle Ihre Anbieter und deren Kanäle für das Windows-SDK beschreibt (ecmangen ist nicht mehr nötig!).
• build_man2dll.ps1 – Mit deinem Manifest erstellt das Windows Event Subsystem Module DLL, das alle deine neuen Provider und Kanäle auf jedem System implementiert, das du installierst (meist dem WEC-Server). install_channels.ps1
• – Nimmt die DLL und das Manifest und installiert sie im lokalen System
• configure_channels.ps1 – Wird die Log-Pfad- und Log-Größenkonfiguration (von wec_config.ps1) auf alle neu installierten
• Kanäle angewendet setup_subscriptions.ps1 – Wird alle Abonnements für deinen Anbieter/Kanäle auf dem WEC-Server einrichten (erstellen oder neu
• konfigurieren) map_ou2group.ps1 – Du möchtest wahrscheinlich die OUs deines ADs nutzen, aber WEC-Abonnements wählen Computer über AD Groups aus. Dieses Skript synchronisiert die Zugehörigkeit der gegebenen Gruppen zu den Computern unter den angegebenen OUs, wiederum unter Verwendung der Konfiguration in wec_config.ps1
• gen_winlogbeat_config.ps1 – Die Konfiguration, die mit Winlogbeat versendet wird, kennt nicht alle deine zusätzlichen WEC-Abonnementkanäle, daher wird diese Konfiguration für dich aktualisiert.
• beat_cmd.ps1 – Ein Hilfsskript zur Interaktion mit Beat-Befehlen in PowerShell

Leider müssen alle Konfigurationen auf der AD-Seite, wie Gruppenrichtlinien, weiterhin manuell erfolgen – aber das Kochbuch enthält Schritt-für-Schritt-Anleitungen mit Screenshots. Vielleicht schreibe ich dafür eines Tages auch Skripte, bleibt dran.

Schließlich muss Winlogbeat so konfiguriert werden, dass alle WEC-Logs an Elastic Security gesendet werden. Das Kochbuch wird dich auch dabei führen.

Fazit

Ich hoffe, dass Sie nach dem Lesen dieses Blogbeitrags und möglicherweise des Kochbuchs selbst eine gute Vorstellung davon haben, welche Entscheidungen Sie treffen müssen, bevor Sie anfangen, und nun alle Ratschläge und Werkzeuge haben, die Sie benötigen, um den perfekten WEC-Server für Ihr Unternehmen zu erstellen.

Nachdem Sie nun die entsprechenden Überwachungsrichtlinien eingerichtet, WEF konfiguriert und einen WEC-Server zur Weiterleitung der Ereignisprotokolle Ihrer AD-Domäne an Elastic Security konfiguriert haben, werden wir in unserem nächsten Blogbeitrag untersuchen, was Sie mit diesen äußerst wichtigen und nützlichen Protokolldaten in Elastic Security anfangen können.

Wenn Sie Elastic Security noch nicht kennen, können Sie unsere neueste Version des Elasticsearch-Dienstes auf Elastic Cloud testen. Nutzen Sie außerdem unser Schnellstarttraining, um optimal vorbereitet zu sein.

Siehe andere Kochbuchführer, die ich geschrieben habe: https://ela.st/tjs-cookbook-lib