imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

2026-09-15T00:00:00Z

Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

Neue Seite

== Einleitung ==

FortiGate-Firewalls erzeugen in vielen Wazuh-Umgebungen ein hohes Logvolumen. Standardmäßig landen daraus erzeugte Alerts im Muster <code>wazuh-alerts-*</code>. Für saubere Datenhaltung, gezieltere Dashboards und separate Retention Policies ist es sinnvoll, diese Events in ein eigenes Indexmuster wie <code>fortigate-alerts-*</code> oder <code>wazuh-alerts-fortigate-*</code> 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 <code>wazuh-alerts-*</code> 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 <code>wazuh-alerts-*</code>; Archive-Events liegen unter <code>wazuh-archives-*</code>. 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:

<syntaxhighlight lang="text">
/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json
</syntaxhighlight>

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

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

== Lösung / Best Practices ==

Zuerst sollten die relevanten Dateien gesichert werden:

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

<syntaxhighlight lang="text">
"index_patterns": [
"wazuh-alerts-4.x-*",
"wazuh-archives-4.x-*",
"fortigate-alerts-*"
]
</syntaxhighlight>

Danach wird das Template neu in den Indexer geladen:

<syntaxhighlight lang="text">
sudo filebeat setup --index-management -E setup.template.overwrite=true
</syntaxhighlight>

Nun wird in der Datei

<syntaxhighlight lang="text">
/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json
</syntaxhighlight>

direkt vor dem allgemeinen <code>date_index_name</code>-Processor folgender Block eingefügt:

<syntaxhighlight lang="text">
{
"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'"
}
},
</syntaxhighlight>

Danach wird die Pipeline neu geladen und Filebeat neu gestartet:

<syntaxhighlight lang="text">
sudo filebeat setup --pipelines --modules wazuh
sudo systemctl restart filebeat
</syntaxhighlight>

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

<syntaxhighlight lang="text">
fortigate-alerts-*
</syntaxhighlight>

Als Time Filter Field sollte <code>timestamp</code> 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:

<syntaxhighlight lang="text">
wazuh-alerts-fortigate-*
</syntaxhighlight>

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

== Lessons Learned / Best Practices ==

Die Wahl des Indexnamens entscheidet über das spätere Betriebsmodell. Ein Pattern wie <code>fortigate-alerts-*</code> trennt FortiGate-Daten klar von allgemeinen Wazuh-Alerts und eignet sich besonders für eigene Retention Policies. Ein Pattern wie <code>wazuh-alerts-fortigate-*</code> 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 <code>fortigate</code> lautet. Das lässt sich über bestehende Alerts oder eine Suche nach <code>decoder.name</code> 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 <code>date_index_name</code>-Processor für <code>decoder.name == fortigate</code> 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.

== Quellen ==

Wazuh-Dokumentation: Wazuh indexer indices
[https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-indices.html#creating-custom-index-pattern https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-indices.html#creating-custom-index-pattern]

Kevin Branch: Ninja Nugget #1 – Wazuh split routing quick example
[https://www.linkedin.com/pulse/ninja-nugget-1-wazuh-split-routing-quick-example-kevin-branch-ryakc/?utm_source=chatgpt.com https://www.linkedin.com/pulse/ninja-nugget-1-wazuh-split-routing-quick-example-kevin-branch-ryakc/]

Mehr zu Wazuh …
[https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program 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.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program]

[https://wazuh.slack.com/archives/C07CCCCGHHP/p1771506232486559 https://wazuh.slack.com/archives/C07CCCCGHHP/p1771506232486559]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/fortigate-logs-in-wazuh-in-eigene-indizes-routen/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 6. Juni 2026).

== Unterstützung von m.a.x. it ==
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]

FortiGate-Logs in Wazuh in eigene Indizes routen - Versionsgeschichte

imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)