FortiGate-Logs in Wazuh in eigene Indizes routen

Einleitung

FortiGate-Firewalls erzeugen in vielen Wazuh-Umgebungen ein hohes Logvolumen. Standardmäßig landen daraus erzeugte Alerts im Muster wazuh-alerts-*. Für saubere Datenhaltung, gezieltere Dashboards und separate Retention Policies ist es sinnvoll, diese Events in ein eigenes Indexmuster wie fortigate-alerts-* oder wazuh-alerts-fortigate-* zu schreiben.

Ausgangslage / Problemstellung

Die Umgebung sammelt FortiGate-Logs in Wazuh. Die Events werden vom FortiGate-Decoder verarbeitet und anschließend über Filebeat an den Wazuh Indexer gesendet. Das Ziel ist:

FortiGate-Alerts sollen nicht zusammen mit allen anderen Alerts im Standardindex wazuh-alerts-* liegen, sondern in einem dedizierten Indexmuster. Dadurch können eigene Dashboards, Suchmuster und vor allem abweichende Retention- oder ILM-Regeln genutzt werden.

Technische Analyse

Wazuh speichert Alerts standardmäßig unter wazuh-alerts-*; Archive-Events liegen unter wazuh-archives-*. Eigene Indexmuster können zusätzlich in das Wazuh-Template aufgenommen werden, damit Felder, Mappings und Visualisierung korrekt funktionieren. Wichtig ist dabei das Sternchen am Ende des Patterns, da Filebeat die konkreten Tagesindizes anhand dieses Musters erzeugt.

Die eigentliche Trennung erfolgt nicht im Decoder oder in den Rules, sondern in der Filebeat-Ingest-Pipeline:

/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json

Dort verwendet Wazuh einen date_index_name-Processor, um aus dem Event-Zeitstempel den Zielindex zu bilden. Wird vor dem Standard-Processor ein bedingter date_index_name-Block für FortiGate eingefügt, können passende Events anhand von ctx.decoder?.name == 'fortigate' in ein eigenes Indexmuster geschrieben werden.

Wichtig: Diese Weiterleitung dupliziert die Events nicht. Wenn das neue Pattern außerhalb von wazuh-alerts-* liegt, erscheinen FortiGate-Events nur noch im neuen Zielindex.

Lösung / Best Practices

Zuerst sollten die relevanten Dateien gesichert werden:

cp /etc/filebeat/wazuh-template.json /etc/filebeat/wazuh-template.json.bak
cp /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json.bak

Anschließend wird das neue Pattern in das Wazuh-Template aufgenommen:

"index_patterns": [
  "wazuh-alerts-4.x-*",
  "wazuh-archives-4.x-*",
  "fortigate-alerts-*"
]

Danach wird das Template neu in den Indexer geladen:

sudo filebeat setup --index-management -E setup.template.overwrite=true

Nun wird in der Datei

/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json

direkt vor dem allgemeinen date_index_name-Processor folgender Block eingefügt:

{
  "date_index_name": {
    "description": "Fortigate firewall alerts to fortigate-alerts-YYYY.MM.DD",
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "fortigate-alerts-",
    "index_name_format": "yyyy.MM.dd",
    "ignore_failure": true,
    "if": "ctx.decoder?.name == 'fortigate'"
  }
},

Danach wird die Pipeline neu geladen und Filebeat neu gestartet:

sudo filebeat setup --pipelines --modules wazuh
sudo systemctl restart filebeat

Im Wazuh Dashboard sollte anschließend ein neues Index Pattern erstellt werden, falls es nicht automatisch sichtbar ist:

fortigate-alerts-*

Als Time Filter Field sollte timestamp verwendet werden. Die Wazuh-Dokumentation beschreibt ebenfalls, dass ein neues Pattern im Dashboard angelegt werden muss, wenn es dort noch nicht vorhanden ist.

Alternativ kann das Pattern bewusst so gewählt werden:

wazuh-alerts-fortigate-*

Der Vorteil: Dieses Muster liegt weiterhin im Suchbereich von wazuh-alerts-*. Damit bleiben übergreifende Alert-Sichten einfacher nutzbar. Für eine harte Trennung, etwa bei separater Retention, ist ein eigenes Muster wie fortigate-alerts-* meist sauberer.

Lessons Learned / Best Practices

Die Wahl des Indexnamens entscheidet über das spätere Betriebsmodell. Ein Pattern wie fortigate-alerts-* trennt FortiGate-Daten klar von allgemeinen Wazuh-Alerts und eignet sich besonders für eigene Retention Policies. Ein Pattern wie wazuh-alerts-fortigate-* bleibt näher am Wazuh-Standard und erleichtert globale Alert-Abfragen.

Bestehende Indizes werden durch diese Änderung nicht rückwirkend umbenannt. Die neue Pipeline wirkt nur auf neu eintreffende Events. Für historische Daten wäre ein Reindexing notwendig.

Vor produktivem Einsatz sollte geprüft werden, ob der Decodername tatsächlich fortigate lautet. Das lässt sich über bestehende Alerts oder eine Suche nach decoder.name verifizieren. Außerdem sollte die zusätzliche Indexanzahl in die Shard- und Retention-Planung einbezogen werden, da jedes neue tägliche Pattern zusätzliche Ressourcen im Indexer benötigt.

Fazit

FortiGate-Events lassen sich in Wazuh sauber über eine angepasste Filebeat-Ingest-Pipeline in eigene Indizes routen. Entscheidend sind drei Schritte: das neue Indexmuster im Wazuh-Template registrieren, den bedingten date_index_name-Processor für decoder.name == fortigate ergänzen und die Pipeline neu laden. Danach landen neue FortiGate-Alerts ausschließlich im dedizierten Zielindex und können separat durchsucht, visualisiert und aufbewahrt werden.