zurück zur Übersicht

Windows die Plaudertasche: Eventlogs vorfiltern


Eventlogs sind oft wie ein Heuhaufen in dem eine Nadel gesucht wird oder ein Schwarm Insekten. Vorfiltern hilft!Wenn es um Event Logging aufgrund von Compliance Vorgaben oder im Rahmen eines IT-Security-Monitorings geht, kommt man an Microsoft nicht vorbei. Applikationsserver, Domain-Controller, Sharepoint, MSSQL-Server – Gerade im Bereich Nutzerverwaltung und Authentisierung stellt man dann fest, dass Microsoft-Produkte extrem mitteilungsbedürftig sind. Das ist auf der einen Seite gut, denn je mehr Informationen vorliegen, desto besser lässt sich bei Auffälligkeiten eine Situation beurteilen. Andererseits schafft es allerdings auch Probleme.

Die Hersteller von Logmanagement-Systemen, ob mit oder ohne SIEM-Funktionen, ringen ihren Plattformen immer größeren Datenumsatz ab; mittels eigenentwickelten, schnellen Datenbank-modellen oder dem Nachrüsten mit Hardware. Aber was, wenn der Engpass in der Verarbeitungskette nicht beim Logmanagement-System liegt und auch nicht bei der Datenquelle? Zwischen beidem gibt es nämlich noch ein Bindeglied, das die Verbindung einerseits zum loggenden System und andererseits zum Logmanagement oder SIEM herstellt. Dies sind kleine Programme, oder Agents, die die Logdaten entgegennehmen, verarbeiten und weiterleiten. Diese Agents bedienen meist mehrere Logquellen gleichzeitig oder verarbeiten ein konsolidiertes Eventlog mehrerer Systeme. Das kann zu Problemen führen. Denn wenn die Logquelle eine zu große Datenmenge erzeugt, ist die Logdatei unter Umständen bereits archiviert worden oder rotiert, während der Agent noch nicht alle Daten auslesen und verarbeiten konnte. Für ein nachgelagertes SIEM bedeutet das: Eventverlust.

Im Folgenden werden verschiedene Möglichkeiten aufgezeigt, das Eventaufkommen grundsätzlich zu begrenzen beziehungsweise die Weiterleitung von Windows Eventlogs auf ein sinnvolles Maß zu begrenzen, ohne wichtige Informationen zu verlieren. Letzteres setzt allerdings voraus, dass eine eventuell existierende Logging-Policy im Unternehmen die Filterung von Eventlogs grundsätzlich erlaubt.

Auditpol

Die Windows Auditpolicy beschreibt, welche Ereignisse mit welchem Ergebnis im Eventlog protokolliert werden. Die Abstufung erfolgt in neun Kategorien wie Benutzeranmeldungen, Zugriffe (z.B. auf Dateien und Drucker) oder Systemereignisse (z.B. Neustart und Herunterfahren). Weiterhin kann die Protokollierung auf erfolgreiche und/oder fehlgeschlagene Ereignisse eingeschränkt oder für bestimmte Ereignisse komplett deaktiviert werden.
Führen Sie auf der Kommandozeile folgendes Kommando mit entsprechenden Rechten aus, um sich die für ihren Nutzer aktuell gültige Auditpolicy anzeigen zu lassen.

auditpol /get /category:*

Built-in Filtering

Einige der bereits angesprochenen Agenten, die Eventlogs an Logmanagement-Systeme oder SIEM-Plattformen weiterleiten, verfügen über die Möglichkeit, Windows-Events anhand spezifischer Merkmale von der weiteren Verarbeitung auszuschließen.

Der WinCollect Agent von IBMs QRadar SIEM-Plattform kann mittels XPath Queries Events an der Quelle filtern, z.B. anhand der Event-IDs.

Für Splunk gibt es die Möglichkeit, über die Datei inputs.conf und die Parameter whitelist oder blacklist ebenfalls Windows-Events anhand ihrer Event ID von der Weiterleitung auszuschließen.

Dasselbe ist auch beim OSSEC-Agent für AlienVaults OSSIM über einen speziellen Parameter in der Konfigurationsdatei des Agents möglich. Allerdings kann man hier nur eine Whitelist pflegen und muss folglich alle Event-IDs kennen, die verarbeitet werden sollen. Da man eher die Ereignisse identifiziert hat, die man definitiv nicht loggen möchte, ist das Erstellen einer Whitelist sicherlich zeitintensiver.

Eine andere Variante ist die nachgelagerte Filterung von Events. Das bedeutet, dass der Agent erst einmal alle Daten einliest und verarbeitet und im Nachhinein, beispielsweise anhand eines normalisierten Event-Schemas, einzelne Events herausgefiltert werden.

Dies ist beispielsweise beim HPE ArcSight SmartConnector über eine Filter-Out Definition möglich. Und auch der WinCollect Agent von IBM QRadar bietet diese Funktion mittels Exclusion Filter und Angabe der entsprechenden Event-IDs.

Allerdings hilft einem diese Variante bei dem geschilderten Problem nicht, wenn der Agent grundsätzlich nicht in der Lage wäre, das Logvolumen in annähernder Echtzeit zu bewältigen.

Vorverarbeitung durch Weiterleitung per Syslog

Eine weitere Möglichkeit besteht darin, Windows Eventlogs über ein Syslog-Forwarding auszuleiten. Tools für das Auslesen und Weiterleiten des Eventlogs per Syslog gibt es viele: Snare, Solarwinds, Balabit Syslog-NG, NXLog, RSyslog Windows Agent, Datagram SyslogAgent und noch einige mehr.

Diese Tools arbeiten unbemerkt im Hintergrund auf jedem einzelnen Host und haben es daher mit weit weniger Daten zu tun als die eingangs genannten SIEM-Agents. Einige bieten bereits Möglichkeiten, Windows-Events vorzuselektieren. Ist das nicht der Fall, kann man den Empfänger so konfigurieren, dass er Syslog-Meldungen mit bestimmtem Inhalt filtert (Event-IDs, Benutzer, IP-Adressen oder Hostnamen), und den Rest beispielsweise in eine Datei schreibt oder an das Logmanagement-System weiterleitet, z.B. mittels Syslog-NG.

Der Snare Agent von InterSect Alliance z.B. kann einerseits bestimmt Windows-Events anhand ihrer Event-ID filtern. Andererseits kann er Events auch kürzen. Mit Windows Server 2008 wird mit einigen Events eine teilweise sehr lange Beschreibung geloggt, die inhaltlich keinen Mehrwert hat. So umfasst die Beschreibung für eine erfolgreiche Benutzeranmeldung (Event-ID 4624) genau 1200 Zeichen. Wenn man pro Zeichen 1 Byte an Speicherplatz annimmt und sich vor Augen hält, wie viele Mitarbeiter in der eigenen Firma an einem Computer arbeiten, kann man sich ausmalen, wieviel mehr an Speicherbedarf dies bedeutet. Und Benutzeranmeldungen sind immer Bestandteil eines IT-Security Monitorings.

Fazit: Eventlogs vorzufiltern steigert die Effizienz eines SIEMS Logmanagements beträchtlich

Egal für welche Variante man sich entscheidet – hilfreich ist in jeder Hinsicht ein guter Draht zum Windows Team im eigenen Haus, wenn es um inhaltliche Klärung einzelner Events oder die Zusammenhänge mehrerer Event-IDs geht. Hinsichtlich IT-Security oder Compliance-Vorgaben muss sichergestellt sein, dass keine Ereignisse mit wichtigen Informationen herausgefiltert werden. Hilfreich bei der Entscheidungsfindung kann dabei das Dokument Security Monitoring and Attack Detection sein. Darin werden im Appendix A (Excluding Unnecessary Events) jene Event-IDs aufgeführt, die entweder keine verwertbaren Informationen für ein Security Monitoring liefern oder lediglich erwartetes Verhalten belegen. Aufgeführt sind hier Event-IDs für Windows Server 2003. Die entsprechenden Event-IDs für Windows Server 2008 und andere finden sich im Dokument Windows security audit events.

Diejenigen, die nicht für den Betrieb eines Logmanagement Systems oder SIEM verantwortlich sind, tun sich oft allzu leicht mit der Forderung nach einem allumfassenden Logging ohne jegliche Filterung. Dies spiegelt dann auch oft die Audit-Policy in vielen Unternehmen wider. Jedoch müssen Lizenz- und Plattformkosten in die Betrachtung des Eventaufkommens einbezogen werden, denn die Erfassung von nutzlosen Events verteuert Log-Management und SIEM-Lösungen unnötig und verzögert schlimmstenfalls die Implementierung oder verhindert deren Einführung ganz. Hier ist Erfahrung bei der Konzeption und Dimensionierung der Lösungen besonders wichtig. Auditoren haben erfahrungsgemäß kein Problem mit der Filterung von Events, wenn diese nachvollziehbar umgesetzt und dokumentiert ist. Denn auch mit technischen Hilfsmitteln wie Log-Management und SIEM findet man die Nadel eher, wenn der Heuhaufen kleiner ist.


 

Bild: ©Photocase/Markus Gann

Schreibe einen Kommentar