Wie man Filebeat mit Kafka und Redis konfiguriert: Ein detaillierter Leitfaden für Zeek-Logs

Filebeat spielt eine entscheidende Rolle bei der Erfassung und Weiterleitung von Log-Daten in modernen Netzwerküberwachungs- und Sicherheitslösungen. Besonders im Zusammenspiel mit komplexen Systemen wie Zeek (ehemals bekannt als Bro) und Kafka oder Redis als Zwischenablage kann es Herausforderungen geben, die eine tiefere Konfiguration erfordern. Diese Konfiguration ist besonders relevant, wenn Filebeat auf einem Server in einer Mittelschicht- oder Landeposition ausgeführt wird und auf mehrere Quellen für denselben Logtyp zugreifen muss.

Sobald die Berechtigungen korrekt gesetzt sind, kann Filebeat konfiguriert werden, um mit den Zeek-Logs zu arbeiten. Eine typische Konfiguration führt dazu, dass die Logs in das JSON-Format umgewandelt werden, wobei die meisten wichtigen Felder gemäß dem Elastic Common Schema (ECS) konvertiert werden. Diese Umwandlung bietet strukturierte Daten, die die spätere Analyse und Verarbeitung vereinfachen. Ein Beispiel dafür könnte wie folgt aussehen:

json
Copy code
"source" => {
    "mac" => "11:50:56:c4:00:a2",
    "bytes" => 812,
    "packets" => 4,
    "port" => 62299,
    "address" => "192.168.28.32",
    "ip" => "192.168.28.32"
},
"@timestamp" => "2040-07-10T02:20:22.191Z"

Es gibt jedoch Situationen, in denen Filebeat-Modulkonvertierungen nicht ausreichen und komplexere Umwandlungen erfordern, die an eine Elasticsearch-Ingest-Pipeline weitergeleitet werden müssen, wie es bei Cisco- oder Palo-Alto-Logs der Fall sein könnte. In solchen Fällen können zusätzliche Prozessoren innerhalb eines Filesets hinzugefügt werden, um die Konfiguration kompakt zu halten, ohne dass das Hauptkonfigurationsfile unnötig aufgebläht wird.

Ein Beispiel für die Verwendung eines add_tags-Prozessors in einem Zeek-Modul sieht folgendermaßen aus:

yaml
Copy code
modules.d/zeek.yml

1 connection:
    enabled: true
    var.paths: ["/opt/zeek/spool/zeek/conn.log"]
2 input:
    processors:
        - add_tags:
            tags: ["tag-in-connection-log"]

Durch diese Konfiguration wird jedem Verbindungsereignis ein Tag hinzugefügt, was bei der späteren Verarbeitung und Identifikation der Daten von großem Nutzen sein kann.

Eine der Stärken von Filebeat ist seine Flexibilität bei der Ausgabe von Daten an verschiedene Ziele. In den meisten Fällen wird Filebeat verwendet, um Logs entweder direkt an Elasticsearch oder an Logstash weiterzuleiten. Die Ausgabe an Kafka oder Redis, zwei populäre Message Broker, ist jedoch ebenfalls weit verbreitet.

yaml
Copy code
output.kafka:
  enabled: true
  hosts: ["kafka01:9092", "kafka02:9092"]
  topic: "filebeat"
  client_id: "my-awesome-server-running-filebeat"
  headers:
    - key: "category"
      value: "remoteaccess"
      when:
        equals:
          event.dataset: "zeek.ssh"
    - key: "category"
      value: "web"
      when:
        equals:
          event.dataset: "zeek.tls"

Dabei ist es wichtig, dass die korrekten Kafka-Broker-Hosts und das Thema angegeben werden. Zudem ist es von Vorteil, wenn das client_id eine eindeutige Kennung für den Filebeat-Client enthält, um die Fehlerbehebung zu erleichtern. Auch das Hinzufügen von Kafka-Headern zur Nachricht, die zusätzliche Metadaten enthalten, ist eine gängige Praxis. Diese Header können mithilfe von Bedingungen angepasst werden, um beispielsweise spezifische Daten nach ihrem Typ oder ihrer Quelle zu kennzeichnen.

plaintext
Copy code
input {
    kafka {
        bootstrap_servers => "kafka01:9092,kafka02:9092"
        group_id => "logstash"
        topics => ["filebeat"]
    }
}
filter {
    json {
        source => "[event][original]"
    }
}
output {
    stdout { codec => rubydebug { metadata => true } }
}

Ein weiterer wichtiger Aspekt ist die Integration von Redis, einem In-Memory-Messaging-Broker, der in vielen Szenarien als Zwischenablage verwendet wird. Wie Kafka auch, speichert Redis die Daten in einer Warteschlange, die später von anderen Systemen verarbeitet werden kann. Die Konfiguration von Redis als Ausgabeziel funktioniert ähnlich wie die von Kafka, erfordert jedoch die Angabe eines Schlüssels, der für das Speichern von Daten in Redis verantwortlich ist. Eine mögliche Redis-Ausgabekonfiguration könnte wie folgt aussehen:

yaml
Copy code
output.redis:

  enabled: true
  hosts: ["localhost"]
  password: "YOUR-REDIS-PASSWORD"
  key: "filebeat"
  keys:
    - key: "remoteaccess"
      when:
        or:
          - contains:
              event.dataset: "zeek.ssh"

Für beide Szenarien – Kafka und Redis – ist es ratsam, Tags zu verwenden, um die Datenflüsse zu kennzeichnen und eine präzisere Nachverfolgung und Fehlerbehebung zu ermöglichen. Diese Tags können direkt in filebeat.yml definiert werden, wenn sie für das Routing und die Analyse der Daten hilfreich sind.

Wie man Winlogbeat mit TLS und Logstash konfiguriert

Um Winlogbeat mit Logstash zu verbinden und TLS (Transport Layer Security) zu nutzen, müssen verschiedene Konfigurationsschritte beachtet werden, um eine sichere und zuverlässige Übertragung der Ereignisprotokolle zu gewährleisten. Zunächst muss überprüft werden, dass das Zertifikat mit der CA-Ketten-Datei authentifiziert werden kann. Dies kann durch den Befehl openssl verify -CAfile tls/certs/ca-chain.cert.pem tls/certs/winlogbeat.local.client.cert.pem erfolgen, wobei "OK" als Bestätigung angezeigt wird, dass das Zertifikat korrekt validiert wurde. Damit ist der neue Schlüssel für Winlogbeat bereit zur Verwendung. Es ist ratsam, die ausgeführten OpenSSL-Befehle zu speichern, damit sie später gesichert und versioniert werden können.

Ein weiterer Schritt ist die Aktualisierung der Hosts-Datei auf dem Windows-System, damit Winlogbeat die IP-Adresse von Logstash erkennen kann. Dies ermöglicht eine Verbindung mit Logstash unter Verwendung des Hostnamens anstelle einer IP-Adresse, was die Verwaltung und Wartung vereinfacht. Wenn kein DNS-Server in der Umgebung vorhanden ist, muss der Administrator Notepad als Administrator ausführen und die IP-Adresse von Logstash zusammen mit dem zugehörigen Hostnamen in die Datei C:\Windows\System32\drivers\etc\hosts eintragen. Beispiel: 192.168.65.131 logstash.

bash
Copy code
$ python3 -m http.server 8080

Anschließend kann auf Windows mit curl.exe das Zertifikat heruntergeladen werden:

powershell
Copy code
PS> curl.exe -O http://192.168.8.133:8080/tls/certs/ca-chain.cert.pem

PS> curl.exe -O http://192.168.8.133:8080/tls/certs/winlogbeat.local.client.cert.pem
PS> curl.exe -O http://192.168.8.133:8080/tls/keys/winlogbeat.local.client.key.pem

Nach der erfolgreichen Übertragung der Zertifikate muss Winlogbeat konfiguriert werden. Eine Sicherungskopie der Konfigurationsdatei winlogbeat.yml sollte erstellt werden, bevor Änderungen vorgenommen werden. In der Konfigurationsdatei werden unter winlogbeat.event_logs verschiedene Ereignisprotokolle definiert, wie etwa die Anwendung, System, Sicherheit und Microsoft-Windows-Sysmon/Operational Logs. Es ist entscheidend, dass auch nur die relevanten Ereigniscodes überwacht werden, wie sie in der Standardkonfiguration von Elastic empfohlen werden.

Um die Ausgabe von Winlogbeat an Logstash zu richten, muss der Logstash-Hostname und der Port angegeben werden, anstelle einer IP-Adresse, da in den SAN (Subject Alternative Name)-Feld des Logstash-Zertifikats der Hostname und nicht die IP-Adresse eingetragen ist. SSL/TLS muss aktiviert werden, und es muss der vollständige Verifizierungsmodus eingestellt werden, damit Winlogbeat nur dann eine Verbindung zu Logstash aufnimmt, wenn das Logstash-Zertifikat von einer vertrauenswürdigen CA signiert ist und der Hostname im Zertifikat übereinstimmt.

Die Pfade zu den TLS-Dateien müssen korrekt angegeben werden. Achten Sie darauf, dass der Pfad auf den Windows-Host korrekt ist, wobei Backslashes (\\) oder einfache Vorwärtsschläge (/) verwendet werden, um den Pfad darzustellen. Nachdem die Konfiguration abgeschlossen ist, kann die Datei gespeichert und das Format überprüft werden:

powershell
Copy code
PS> .\winlogbeat.exe test config

Config OK

Anschließend wird auch die Netzwerkverbindung zwischen Winlogbeat und Logstash getestet:

powershell
Copy code
PS> .\winlogbeat.exe test output

Nachdem die Konfiguration erfolgreich getestet wurde, sollten die TLS-Dateien aus dem Downloads-Verzeichnis in das endgültige Verzeichnis C:\Program Files\Winlogbeat verschoben werden, um sicherzustellen, dass sie sich an einem sicheren Speicherort befinden. Hierzu kann der folgende Befehl genutzt werden:

powershell
Copy code
PS> copy -recurse "C:\Users\j\Downloads\Winlogbeat" "C:\Program Files\"

Danach erfolgt die Installation des Winlogbeat-Dienstes. Zunächst muss überprüft werden, ob die PowerShell-Ausführungsrichtlinie auf "Restricted" gesetzt ist, da das Standardverhalten keine Ausführung von Skripten zulässt. Um dies zu ändern, wird die Richtlinie auf "bypass" gesetzt, um das Ausführen des Installationsskripts zu ermöglichen:

powershell
Copy code
PS> Set-ExecutionPolicy bypass

Nach der Installation des Winlogbeat-Dienstes kann dieser gestartet werden:

powershell
Copy code
PS> Start-Service -name Winlogbeat
PS> Get-Service -name Winlogbeat

Auf dem Linux-Host, der Logstash ausführt, kann überprüft werden, ob die Windows-Protokolle korrekt gestreamt werden, indem man die eingehenden Ereignisse analysiert.

Wie funktionieren Syslog-Facilities und wie sichert man Rsyslog-Kommunikation mit TLS?

Die Syslog-Protokolle RFC 3164 und das modernere RFC 5424 definieren die Standards für das Format von Syslog-Nachrichten, welche grundlegend für das Logging und Monitoring von Systemen sind. Dabei werden verschiedene sogenannte „Facilities“ verwendet, die die Herkunft der Nachrichten kennzeichnen und je nach Betriebssystem leicht variieren können. Zu den wichtigsten Facilities zählen unter anderem kern (0) für Kernel-Nachrichten, user (1) für Benutzerprozesse, mail (2) für Mail-Systemmeldungen, daemon (3) für Systemdienste und auth (4) für Sicherheitsmeldungen. Diese Kategorien helfen dabei, die Vielzahl an Logdaten strukturiert zu organisieren und die Quelle der Ereignisse eindeutig zu identifizieren. Manche Facilities, wie local0 bis local7, sind für spezifische, benutzerdefinierte Anwendungen reserviert, was Flexibilität im Logging ermöglicht.

Rsyslog ist ein leistungsfähiges, quelloffenes Werkzeug zur Verarbeitung und Weiterleitung von Syslog-Daten, das den RFC-Standards folgt. Es unterstützt eine Vielzahl von Eingabe- und Ausgabemethoden, einschließlich der Möglichkeit, Logs über das Netzwerk zu empfangen oder an entfernte Systeme zu senden, ohne dabei zwingend lokale Dateien zu verwenden. Die modulare Architektur von Rsyslog ermöglicht eine flexible Konfiguration, bei der einzelne Funktionalitäten als eigenständige Module aktiviert oder deaktiviert werden können. So lassen sich beispielsweise neue Zielsysteme wie Kafka-Cluster einfach durch das Hinzufügen einer kurzen Konfigurationsdatei integrieren. Durch bedingte Regeln kann der Datenfluss zielgerichtet gesteuert und vor dem Versand oder der Speicherung angepasst werden.

Nach der erfolgreichen Zertifikatsgenerierung werden die TLS-Dateien an einem systemweiten Speicherort (/etc/ssl/rsyslog) abgelegt. Die Dateiberechtigungen werden so gesetzt, dass der Rsyslog-Dienst, der unter dem Benutzer „syslog“ läuft, auf die Zertifikate zugreifen kann, ohne die Sicherheit des Systems zu kompromittieren. Diese Absicherung der Syslog-Kommunikation schützt die sensiblen Logdaten vor Abhörversuchen und Manipulationen im Netzwerk und ist damit eine essenzielle Maßnahme in sicherheitsbewussten Umgebungen.

Neben der hier dargestellten technischen Umsetzung von Facilities, Prioritäten und TLS-Absicherung ist es für den Leser von zentraler Bedeutung, auch das Zusammenspiel dieser Konzepte im Gesamtkontext der IT-Sicherheitsarchitektur zu verstehen. Die präzise Kategorisierung von Lognachrichten erleichtert nicht nur das Auffinden relevanter Ereignisse, sondern bildet die Grundlage für automatisierte Alarmierungssysteme und forensische Analysen. Die sichere Übertragung von Logs via TLS verhindert, dass sensible Informationen kompromittiert werden, bevor sie im zentralen Logmanagementsystem ankommen. Darüber hinaus erfordert eine effektive Logverwaltung ein Bewusstsein für die möglichen Angriffsvektoren, die durch ungesicherte Log-Daten entstehen können, sowie die Implementierung von Zugriffs- und Speichermechanismen, die Manipulationen erkennen und verhindern. Nur durch die Kombination dieser technischen und organisatorischen Maßnahmen lässt sich ein zuverlässiges und vertrauenswürdiges Logging-System gestalten, das als Rückgrat moderner IT-Sicherheitsstrategien dient.