Wazuh 4.11: Palo Alto Syslog und Agent-Alerts sauber trennen – Index-Routing über Ingest-Pipeline statt Filebeat-Conditions

Einleitung

In produktiven Wazuh-Setups kollidieren zwei Realitäten: Agent-Alerts sind für Detection und Response essenziell, während Firewall-Syslog (z. B. Palo Alto) oft extrem volumenstark ist und andere Aufbewahrungsanforderungen hat. Wer beide Datenströme im gleichen wazuh-alerts-* Index hält, steht schnell vor Problemen bei Retention, Storage-Kosten und Performance. Der naheliegende Ansatz, per Filebeat output.elasticsearch.indices zu routen, funktioniert in Einzelknoten-Szenarien gelegentlich – wird aber in Clustern mit Load Balancer und mehreren Managern schnell inkonsistent. Stabil wird das Ganze erst, wenn das Routing im Indexer auf Pipeline-Ebene erfolgt.

Ausgangslage / Problemstellung

Gegebenes Zielbild:

Wazuh 4.11, 4 Manager hinter einem Load Balancer
Indexer: OpenSearch Cluster
Quellen:
- Palo Alto Syslog (via LB auf alle Manager)
- Wazuh Agent-Events (Standard)
Status Quo: Alles landet in wazuh-alerts-* mit 7 Tagen Retention.
Ziel: Zwei getrennte Datenströme mit unterschiedlichen Policies:
- Palo Alto → wazuh-paloalto-* mit z. B. 180 Tagen
- Agent Alerts → wazuh-alerts-* mit 7 Tagen

Symptom beim Filebeat-Routing: Auf einem Node wird korrekt geroutet, auf anderen nicht; außerdem vermischen sich Agent- und Firewall-Events in beiden Indizes.

Technische Analyse

Der Kernfehler liegt selten in der Condition selbst, sondern im Ort der Entscheidung:

Filebeat sieht nicht immer die gleichen Felder in konsistenter Form
Bedingungen wie decoder.name, decoder.parent oder rule.groups sind zwar im Alert-JSON vorhanden, aber in Cluster-/LB-Szenarien können Timing, Parser-Varianten oder Event-Typen dazu führen, dass die Felder nicht zuverlässig so vorliegen, wie die Condition es erwartet.
Filebeat-Level-Routing kann Wazuh-Standards indirekt umgehen
Wazuh bringt eine definierte Kombination aus:
- Template (Mappings, Field Types)
- Ingest Pipeline (Normalisierung/Prozessoren)
Wenn man per Filebeat direkt in alternative Indexnamen schreibt, landet man leicht in Situationen, in denen:
- der Wazuh-Template nicht auf das neue Pattern greift,
- oder bereits existierende Indizes falsche Mappings besitzen,
- oder neue Indizes nicht mit dem erwarteten Pipeline-Set arbeiten.
Das robuste Routing gehört in die ingest node pipeline
Sobald Wazuh die Events bereits dekodiert und normalisiert hat, lässt sich auf stabilen Feldern (z. B. decoder.name == paloalto) zuverlässig routen – zentral, einheitlich und unabhängig davon, welcher Manager den Syslog-Event gerade angenommen hat.

Lösung / Best Practices

Die praxistaugliche Lösung ist ein zweistufiges Vorgehen:

1) Filebeat-Konfiguration zurück auf „Standard“

Ziel: Keine Output-Indices-Switches mehr in Filebeat. Filebeat soll wie vorgesehen gegen Wazuhs Standard-Setup laufen.

2) Wazuh-Template um das neue Index-Pattern erweitern

Damit wazuh-paloalto-* dieselben Field Mappings wie wazuh-alerts-* bekommt, muss das Standard-Template das neue Pattern kennen.

In /etc/filebeat/wazuh-template.json den Abschnitt index_patterns erweitern (Beispiel):

vorher:

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

nachher:

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

Dann Template neu pushen:

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

Wichtig: Falls bereits wazuh-paloalto-* Indizes existieren, die mit falschen Mappings erzeugt wurden, sollten sie vor dem Rollout entfernt werden – sonst drohen später Mapping-Konflikte.

3) Split Routing in Wazuhs Alerts-Ingest-Pipeline implementieren

Wazuh nutzt eine ingest pipeline für Alerts. Diese wird um einen Prozessor ergänzt, der bei Palo Alto Events den Zielindex per Datum setzt.

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

Vor dem remove message-Prozessor (oder an geeigneter Stelle) folgenden date_index_name-Block einfügen:

{
  "date_index_name": {
    "description": "Route Paloalto alerts to Paloalto-specific index name",
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "wazuh-paloalto-",
    "index_name_format": "yyyy.MM.dd",
    "ignore_failure": true,
    "if": "ctx.decoder?.name == 'paloalto'"
  }
}

Pipeline deployen:

filebeat setup --pipelines --modules wazuh

Ergebnis:

Neue Palo Alto Events gehen nach wazuh-paloalto-YYYY.MM.DD
Alle anderen Alerts bleiben in wazuh-alerts-*
Beide Indexpatterns nutzen weiterhin den Wazuh-Template und die Standardpipeline

4) Retention/ISM pro Index-Pattern anwenden

Jetzt kann OpenSearch ISM sauber getrennt greifen:

Policy A auf wazuh-alerts-* (7 Tage)
Policy B auf wazuh-paloalto-* (180 Tage)

Lessons Learned / Best Practices

Index-Routing in Filebeat ist in verteilten Wazuh-Manager-Clustern häufig fragil. Routing gehört in den Indexer, nicht an die Edge.
Neue Indizes immer zuerst mapping-sicher machen: Template-Pattern erweitern, dann erst Daten reinschreiben.
Bestehende „Test-Indizes“ mit falschem Mapping früh löschen, bevor sie technisch „vererbt“ werden und später Konflikte verursachen.
Pipeline-Anpassungen sind ein mächtiger Hebel: Neben Routing lassen sich dort auch Normalisierung, Feldbereinigung, Tagging und Anreicherung zentral steuern.

Fazit

Wer Palo Alto Syslog und Agent-Alerts in Wazuh sauber trennen will, erreicht eine stabile, clusterfähige Lösung nicht über Filebeat-Conditions, sondern über die Wazuh Indexer Ingest Pipeline. Mit einem gezielten date_index_name-Prozessor wird Palo Alto zuverlässig in wazuh-paloalto-* geroutet, während Agent-Alerts in wazuh-alerts-* bleiben – inklusive konsistenter Templates, Pipelines und getrennten Retention Policies.

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/p1769614803583219