Historische FortiGate-Logs in Wazuh analysieren: Grenzen des Logcollectors, Timestamp-Problematik und skalierbare Replay-Strategien

von

Einleitung

Wazuh ist primär für die Echtzeitüberwachung von Logquellen konzipiert. Dennoch entsteht in der Praxis häufig der Bedarf, historische Logdateien – etwa aus Firewalls – nachträglich zu analysieren, um:

  • vergangene Sicherheitsvorfälle zu untersuchen
  • Detection-Logik zu testen
  • Dashboards und Reports retrospektiv zu erstellen
  • Compliance-Anforderungen zu erfüllen

Ein typisches Szenario: Eine statische FortiGate-Logdatei mit Millionen Einträgen soll in Wazuh ingestiert und automatisiert ausgewertet werden. Dieser Beitrag erklärt, warum das direkte Einlesen nicht funktioniert, welche systembedingten Einschränkungen existieren und wie sich große historische Logmengen kontrolliert und sauber verarbeiten lassen.

Ausgangslage / Problemstellung

Gegeben ist:

  • FortiGate-Logdatei: /var/log/firewall.log
  • Agent-Konfiguration: <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/firewall.log</location>
    </localfile>
  • Log-Archivierung auf dem Manager aktiviert: <global>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
    </global>

Symptome:

  1. Die Datei wird vom Agent erkannt („Analyzing file“).
  2. Die Logs erscheinen weder in archives.json noch im Dashboard.
  3. Die Datei enthält ausschließlich historische Daten (statisch, keine neuen Einträge).
  4. Beim manuellen Replay großer Datenmengen:
    • extrem lange Laufzeit
    • Brute-Force-Regeln schlagen an
    • Alerts erhalten aktuelle Zeitstempel statt Originalzeit

Technische Analyse

1. Warum statische Dateien nicht ingestiert werden

Der Wazuh Agent verwendet das logcollector-Modul, das Dateien ähnlich wie tail -f überwacht.

Wichtige Eigenschaften:

  • Es werden nur neu geschriebene Logzeilen verarbeitet.
  • Bereits vorhandene Inhalte werden ignoriert.
  • Es gibt keinen nativen „Batch-Import“-Mechanismus für Altbestände.

Das Verhalten ist bewusst so implementiert, um:

  • Doppelverarbeitung zu vermeiden
  • Performance stabil zu halten
  • Realtime-Detection sicherzustellen

Eine vollständig statische Datei erzeugt daher keine Events.

2. Warum Replay große Probleme verursacht

Beim Umkopieren historischer Logs in eine neue Datei (Replay-Ansatz):

  • Jede Zeile wird als neues Event behandelt.
  • Der Alert-Timestamp entspricht der Replay-Zeit.
  • Korrelationen (z. B. Brute-Force-Detection) werden verfälscht.

Beispiel:

Wenn 10.000 Login-Fehler aus einem Zeitraum von 3 Monaten innerhalb weniger Sekunden replayed werden, interpretiert Wazuh dies als massiven Brute-Force-Angriff.

3. Performance-Grenzen des Localfile-Moduls

Standardwerte:

  • ~500 Events pro Sekunde (EPS)
  • 5000 Events Buffer

Bei Millionen Logs bedeutet das:

  • mehrere Stunden bis Tage Ingest-Zeit
  • potenzielle Eventverluste bei Überlast
  • erhöhte CPU-Last auf Agent und Manager

Der Localfile-Mechanismus ist nicht für Massendatenmigration ausgelegt.

Lösung / Best Practices

Für historische Massendaten sind strukturierte Ansätze erforderlich.

Option 1: Kontrolliertes Throttling beim Replay

Wenn Replay zwingend erforderlich ist:

Vorgehen

  1. Neue Replay-Datei erstellen: /var/log/replay.log
  2. Agent konfigurieren: <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/replay.log</location>
    </localfile>
  3. Logs mit Rate-Limit einspielen, z. B.:
    • 50–100 Events pro Sekunde
    • Zeitliche Pausen zwischen Blöcken
    • Keine Burst-Injektion

Dadurch werden:

  • False-Positive-Korrelationen reduziert
  • Buffer-Überläufe vermieden
  • Brute-Force-Trigger minimiert

Option 2: Temporäre Deaktivierung korrelierender Regeln

Während der Replay-Phase können:

  • Brute-Force-Regeln
  • Frequency-basierten Regeln
  • Threshold-Detections

temporär deaktiviert oder angepasst werden.

Beispiel:

  • frequency-Parameter erhöhen
  • timeframe vergrößern
  • Regel temporär in local_rules.xml überschreiben

Nach Abschluss des Imports wieder aktivieren.

Diese Methode verhindert Fehlalarme, ohne den Datenbestand zu verfälschen.

Option 3: Direkter Indexer-Import (nur für Reporting-Zwecke)

Falls das Ziel ausschließlich Analyse und Dashboarding ist (keine Alarmierung):

  • Logs extern parsen (z. B. Logstash, Python)
  • In korrekt gemappte wazuh-alerts-* Indizes schreiben
  • Wazuh-Template zwingend anwenden

Wichtig:

  • Keine aktive Regel-Engine
  • Keine Echtzeit-Korrelation
  • Nur Visualisierung

Dieser Ansatz ist deutlich schneller für Millionen Datensätze.

Option 4: Offline-Analyse mit Wazuh-Logtest

Falls primär die Regelerkennung geprüft werden soll:

/var/ossec/bin/wazuh-logtest

Hiermit können:

  • FortiGate-Logs getestet
  • Decoder validiert
  • Regelmatches überprüft

werden – ohne produktives System zu beeinflussen.

Option 5: FortiGate-spezifische Decoder prüfen

Wazuh enthält native FortiGate-Decoder und -Regeln:

  • 0100-fortigate_decoders.xml
  • 0390-fortigate_rules.xml

Falls keine Alerts entstehen:

  • Logformat prüfen (syslog vs. raw)
  • Custom Decoder erstellen
  • Eigene Regeln definieren

Dokumentation:

Custom Decoders
https://documentation.wazuh.com/current/user-manual/ruleset/decoders/custom.html

Custom Rules
https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html

Lessons Learned / Best Practices

1. Wazuh ist primär ein Realtime-System

Batch-Import historischer Massendaten ist nicht Kernfunktion des Logcollectors.

2. Replay verfälscht zeitbasierte Korrelation

  • Alert-Zeit ≠ Original-Logzeit
  • Frequency-Detections werden verzerrt
  • Brute-Force-Detections triggern ungewollt

3. Millionen Logs benötigen ingest-strategische Planung

Unkontrolliertes Replay führt zu:

  • Performanceproblemen
  • Falschmeldungen
  • Eventverlust

Throttling ist zwingend erforderlich.

4. Reporting und Detection sind unterschiedliche Use Cases

Wenn das Ziel ist:

  • Historische Analyse → Direktindexierung
  • Regellogik testen → wazuh-logtest
  • Forensische Rekonstruktion → kontrollierter Replay

Die Architektur sollte dem Ziel entsprechen.

5. Template- und Mapping-Konsistenz sicherstellen

Bei jedem Import in wazuh-alerts-*:

  • Wazuh-Template prüfen
  • Feldtypen validieren
  • Keyword-Felder für Aggregationen sicherstellen

Fazit

Das Ingestieren statischer, historischer FortiGate-Logs ist in Wazuh grundsätzlich möglich – jedoch nicht als direkter Datei-Import im klassischen Sinne.

Der Logcollector verarbeitet ausschließlich neue Events. Für Millionen historischer Logzeilen sind daher kontrollierte Replay-Strategien oder alternative Importmethoden erforderlich.

Wer große Altbestände analysieren möchte, sollte:

  • die Echtzeitarchitektur von Wazuh berücksichtigen
  • Korrelationseffekte einplanen
  • ingest-raten kontrollieren
  • gegebenenfalls Detection und Reporting voneinander trennen

Mit einer sauberen Strategie lässt sich auch ein umfangreicher historischer Datenbestand strukturiert und sicher in Wazuh auswerten.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1769972326017929