Wie man Filebeat und Winlogbeat in Windows-Umgebungen für die Ereignisprotokollanalyse und Sicherheitsüberwachung konfiguriert

In modernen IT-Infrastrukturen sind Protokolldaten von entscheidender Bedeutung für die Überwachung der Systemintegrität und das Erkennen von Sicherheitsvorfällen. Insbesondere die Nutzung von Filebeat und Winlogbeat, zwei leistungsstarken Tools der Elastic Stack Familie, erleichtert die Erfassung und Weiterleitung von Logdaten auf eine effiziente Weise. In diesem Kapitel wird erklärt, wie man diese Tools auf Windows-Systemen installiert und konfiguriert, um wertvolle Logdaten zu extrahieren und für die Analyse bereitzustellen.

Zunächst muss auf einem Windows-System Filebeat installiert werden, um eine Vielzahl von Protokolldaten zu sammeln. Dabei sollte das Installationsskript ausgeführt werden, um Filebeat als Windows-Dienst zu installieren. Falls beim Ausführen des Skripts eine Fehlermeldung auftritt, die besagt, dass das Ausführen von Skripten auf dem System deaktiviert ist, muss vorübergehend die PowerShell-Ausführungsrichtlinie geändert werden. Dies erfolgt mit den folgenden Befehlen:

shell
Copy code
PS> Get-ExecutionPolicy

PS> Set-ExecutionPolicy Bypass

Nachdem das Installationsskript ausgeführt wurde, sollte die Ausführungsrichtlinie wieder auf den vorherigen Zustand zurückgesetzt werden. Der Windows-Dienst wird mit dem Starttyp „Automatisch (Verzögerter Start)“ eingerichtet, was bedeutet, dass Filebeat nach einem Neustart des Systems etwa eine Minute wartet, bis andere, ebenfalls automatisch startende Dienste vollständig geladen sind.

yaml
Copy code
filebeat.inputs:
  - type: filestream
    enabled: true
    id: edgeupdate-logs
    paths:
      - C:/ProgramData/Microsoft/EdgeUpdate/Log/*.log
    encoding: utf-16le-bom

Für eine ordnungsgemäße Versionierung und Verwaltung der Konfigurationsdateien ist es ratsam, diese in einem Git-Repository zu speichern. So können Änderungen an den Konfigurationen nachverfolgt und sichergestellt werden, dass sie in einer sicheren Umgebung gespeichert sind.

Nach der Konfiguration von Filebeat stellt sich die Frage, wie die Windows-Ereignisprotokolle effizient gesammelt werden können. Dies wird durch den Einsatz von Winlogbeat erreicht, einem weiteren Tool aus der Elastic Stack Familie, das speziell für die Arbeit mit Windows-Ereignisprotokollen entwickelt wurde. Winlogbeat liest die binären Windows-Ereignisprotokolle, formatiert die Ereignisse in JSON und leitet sie an das angegebene Ziel weiter. Im Unterschied zu Filebeat konzentriert sich Winlogbeat ausschließlich auf das Ereignisprotokoll von Windows und unterstützt daher keine benutzerspezifischen Module oder Netzwerk-Listener.

Das Anwendungseignisprotokoll enthält Details zu Anwendungsfehlern, Ressourcennutzung und Update-Ereignissen. Es ist hilfreich bei der Fehlerbehebung, insbesondere wenn es darum geht, Probleme mit Anwendungen zu identifizieren. Das Systemprotokoll hingegen enthält Kernereignisse, Dienststarts, Netzwerkprobleme und Systemabstürze. Diese Informationen sind entscheidend, um das Verhalten eines Systems während oder nach einem Sicherheitsvorfall zu verstehen. Da das Systemprotokoll jedoch eine große Anzahl von Ereignissen erzeugen kann, sollte es sorgfältig konfiguriert werden, um Speicherprobleme zu vermeiden.

Das Sicherheitsprotokoll ist besonders wertvoll, da es Ereignisse wie fehlgeschlagene und erfolgreiche Anmeldungen, Prozessausführungen und Berechtigungsänderungen verfolgt. Diese Telemetrie ist unerlässlich für die Überwachung der Sicherheit in einer Unternehmensumgebung. Die Sysmon-Logs erweitern diese Funktionalität, indem sie detailliertere Sicherheitsereignisse liefern, die für die Analyse von Angriffen und böswilligen Aktivitäten nützlich sind.

Winlogbeat, das auf den Windows-Systemen als Dienst läuft, kann entweder direkt auf jedem Windows-Server oder auf einem sogenannten Windows Event Collector (WEC) installiert werden. Ein WEC empfängt Logs von anderen Hosts und reduziert so die Anzahl der zu verwaltenden Agenten. Dies ist besonders in großen Umgebungen von Vorteil, wo es wichtig ist, die Verwaltung der Log-Datenquellen zu zentralisieren.

Es ist zu beachten, dass das Speichern und Verwalten von Ereignisprotokollen aus Sicherheits- und Betriebsgründen eine gewisse Herausforderung darstellt, insbesondere hinsichtlich der Effizienz und Skalierbarkeit. Das Verständnis der unterschiedlichen Protokollarten und ihrer praktischen Anwendung ist daher unerlässlich für die korrekte Nutzung dieser Tools in der Systemüberwachung und Sicherheitsanalyse.

Wie kann man Netzwerkanalysen mit Logstash effizient gestalten?

Ein weiterer wichtiger Aspekt bei der Verwendung von Logstash ist die Implementierung von Logiksteuerung in Filtern, um den Verlauf von Netzwerkereignissen zu bestimmen, wie beispielsweise, ob ein Ereignis ins Netzwerk eintritt, es verlässt oder sich innerhalb des Netzwerks befindet. In diesem Zusammenhang kann die Hinzufügung von „Directional Tags“ (Richtungstags) eine wesentliche Verbesserung der Benutzerfreundlichkeit darstellen. Ein einfaches Beispiel ist die Kennzeichnung von Netzwerkereignissen als „inbound“ oder „outbound“, um die Suchanfragen in Kibana zu optimieren.

Die Verwendung von Tags zur Kennzeichnung von Verkehrsrichtungen hat den Vorteil, dass die Suchabfragen für Analysten intuitiver werden. Ohne solche Tags müsste eine Anfrage möglicherweise so aussehen: tags:source_homenet AND NOT tags:destination_homenet. Diese Abfrage ist zwar effektiv, jedoch unübersichtlich und setzt voraus, dass der Analyst die genauen Namen der Tags kennt. Eine bessere Alternative wäre die Erstellung eines neuen Feldes wie network.direction, welches auf den Tags basiert und es den Analysten ermöglicht, Abfragen wie network.direction:outbound zu erstellen. Dies sorgt für eine klarere und einfachere Benutzererfahrung.

Das Hinzufügen von Richtungsfeldern ist relativ einfach zu bewerkstelligen, indem man einen Filter wie folgt anlegt:

javascript
Copy code
filter {

  if [source][ip] and [destination][ip] {
    if "source_homenet" in [tags] and "destination_homenet" in [tags] {

      mutate { add_field => { "[network][direction]" => "internal" } }

    }
    else if "source_homenet" in [tags] and "destination_homenet" not in [tags] {
      mutate { add_field => { "[network][direction]" => "outbound" } }
    }
    else if "source_homenet" not in [tags] and "destination_homenet" in [tags] {

      mutate { add_field => { "[network][direction]" => "inbound" } }

    }
    else {
      mutate { add_field => { "[network][direction]" => "unknown" } }
    }
  }
}

Dieser Filter überprüft, ob sowohl eine Quell- als auch eine Ziel-IP-Adresse vorhanden sind und fügt daraufhin das neue network.direction-Feld hinzu, um die Richtung des Netzwerkverkehrs anzugeben. Wenn beide Tags vorhanden sind, wird der Wert „internal“ zugewiesen, bei nur einer Tag-Passung „outbound“ oder „inbound“. Ist kein passendes Tag vorhanden, wird der Wert als „unknown“ markiert, was eine Warnung auslöst, dass möglicherweise ein Problem mit Netzwerkgeräten vorliegt oder eine CIDR-Datei unvollständig ist.

Ein weiteres nützliches Konzept sind Feldvergleiche, die es ermöglichen, spezifische Bedingungen in Logstash zu definieren. Diese Vergleiche sind für die präzise Analyse von Feldern und deren Werten unerlässlich. Sie ermöglichen unter anderem das Prüfen auf Gleichheit oder Ungleichheit, das Vergleichen von Feldern untereinander oder das Suchen nach bestimmten Mustern mittels regulärer Ausdrücke.

Beispiel:

csharp
Copy code
if [event][code] == 11 and [http][response][status_code] == 200 { --snip-- }

Ein weiteres wichtiges Konzept ist die Überprüfung auf die Existenz eines Feldes. Man kann prüfen, ob ein Feld existiert, bevor man mit seiner Nutzung fortfährt, um unerwünschte Überschreibungen oder Fehler zu vermeiden. Dies ist besonders nützlich, wenn mehrere Datenquellen integriert sind, die sich möglicherweise überschneiden oder unvollständige Daten liefern.

Mit Logstash ist es ebenfalls möglich, zu überprüfen, ob ein bestimmter Wert in einem Array von Werten oder in einem anderen Feld enthalten ist. Dies wird durch den Operator „in“ erreicht, der eine einfachere Handhabung mehrerer Vergleichswerte ermöglicht.

Wie man Daten für Sicherheitsanalyse effizient über Pipelines standardisiert und an das SIEM überträgt

In vielen Organisationen ist das SIEM (Security Information and Event Management) von zentraler Bedeutung für die Reaktion auf Sicherheitsvorfälle, da es es Analysten ermöglicht, beispielsweise Ransomware-Indikatoren zu identifizieren, Hosts zu isolieren oder bösartige E-Mail-Absender zu blockieren. Eine der größten Herausforderungen besteht jedoch darin, die benötigten Daten in das SIEM zu integrieren. Nützliche Informationen für die Sicherheitsanalyse, wie Anmeldeereignisse, gestartete Prozesse oder heruntergeladene Dateien, stammen aus unterschiedlichen Quellen, wie Windows, Linux und Unix Betriebssystemen, verschiedenen Netzwerkgeräten und sogar benutzerdefinierten Anwendungen – und all diese Quellen unterscheiden sich sowohl in der Art der erfassten Daten als auch in deren Format.

Ein weiteres Thema, das von Bedeutung ist, ist die Verwaltung der Latenz und des Durchsatzes. Bei der Konstruktion von Datenpipelines arbeiten Dateningenieure stets daran, die Latenz zu minimieren, also die Verzögerung zwischen dem Zeitpunkt, an dem ein Ereignis in die Pipeline eintritt, und dem Moment, an dem es die Pipeline verlässt. Latenz kann in verschiedenen Kontexten auftreten. Beispielsweise kann es sein, dass ein Benutzer eine Anfrage an eine Datenbank stellt und auf eine Antwort warten muss, oder dass ein Log in eine rechenintensive Pipeline gelangt, bevor es im SIEM landet. Diese Verzögerungen stellen ein ernstes Problem für Sicherheitsdatenpipelines dar. Wenn zu viele Ereignisse durch die Pipeline geleitet werden oder Serverausfälle die Anzahl der verfügbaren Datenverarbeitungsnoden reduzieren, können wichtige Alarme, wie beispielsweise Anzeichen für Datendiebstahl oder Ransomware, nicht in Echtzeit an die Analysten weitergeleitet werden.

Um Latenz zu verringern, empfiehlt es sich, unnötige Verarbeitung zu vermeiden und den Code so einfach wie möglich zu halten. Verzögerungen können auch durch hohe Verarbeitungsanforderungen, das Kodieren und Dekodieren von Zeichenketten, die Schreibgeschwindigkeit von Festplatten oder Netzwerkengpässe verursacht werden. In den folgenden Kapiteln wird aufgezeigt, wie man unnötige Verarbeitung durch den Einsatz bedingter Logik, wie etwa if-else-Anweisungen, vermeidet. Darüber hinaus ist es als Dateningenieur hilfreich, ein Verständnis für Lastenausgleich und Durchsatz zu entwickeln.

Ein wichtiger Aspekt bei der Übertragung von Daten an ein SIEM ist die Bereicherung und Standardisierung der Ereignisse. Die Bereicherung von Daten bedeutet, zusätzliche nützliche Informationen hinzuzufügen. Beispielsweise könnte man zu Netzwerk-IP-Adressen in Sensor-Alerts Hostnamen hinzufügen oder einem besuchten Webauftritt einen Reputationsscore zuweisen. Auch das Taggen von häufig verwendeten Angriffskommandos, die von Angreifern in sogenannten „Living-off-the-Land“-Techniken eingesetzt werden, ist eine gängige Praxis. Solche Bereicherungen können den Analysten helfen, schneller und gezielter zu arbeiten, da sie nicht mehr jedes Mal nach bestimmten Attributen suchen müssen.

Die Standardisierung der Daten reduziert den Aufwand der Analysten erheblich. Wenn beispielsweise zwei Netzwerkgeräte Logs in unterschiedlichen Formaten senden, müssen Analysten diese Unterschiede manuell berücksichtigen, was zusätzliche Arbeit verursacht. Eine gut gestaltete Pipeline hingegen sorgt dafür, dass die Daten in einem einheitlichen Format ankommen, sodass die Analysten sich nicht mit den unterschiedlichen Formaten auseinandersetzen müssen.

In diesem Buch werden wir uns vor allem mit Zeitstempel-basierten Daten befassen, also mit Daten, die eine zeitliche Abfolge von Ereignissen darstellen. Diese werden aus unstrukturierten und semistrukturierten Log-Dateien extrahiert und weiterverarbeitet. Es wird jedoch auch auf nicht-zeitbasierte Daten, wie etwa Nmap-Scan-Ergebnisse, eingegangen.

Ein Beispiel für eine grundlegende Datenpipeline könnte wie folgt aussehen: Netzwerkgeräte senden Log-Ereignisse an ein Transformationssystem wie Logstash, welches die Ereignisse in JSON umwandelt. Diese JSON-Daten werden anschließend in einem SIEM oder einer Datenbank gespeichert. In den kommenden Kapiteln werden wir auch sehen, wie Tools wie Filebeat, Winlogbeat oder Rsyslog verwendet werden können, um Logs von Hosts zu extrahieren und sie in diese Pipelines zu integrieren.