Einleitung
In vielen Wazuh-Umgebungen ist die Standardarchitektur ausreichend: Alerts und bei Bedarf auch Archive-Events werden vom Wazuh-Server über Filebeat in den Wazuh Indexer geschrieben. In regulierten Umgebungen reicht dieses Modell jedoch oft nicht aus. Sobald Roh- oder Archivdaten aus Compliance-, Audit- oder Aufbewahrungsgründen getrennt gespeichert werden müssen, stellt sich die Frage nach einer belastbaren Trennung der Datenströme. Genau an dieser Stelle zeigt sich, dass die Standardintegration von Wazuh zwar einfach, aber nicht für jede Routing-Anforderung flexibel genug ist. Wazuh beschreibt Filebeat explizit als Forwarder für Alerts und archivierte Events vom Manager zum Indexer.
Ausgangslage / Problemstellung
Ausgangspunkt war die Anforderung, die regulären Alert-Events weiterhin im Wazuh Indexer zu halten, die Archive-Events jedoch in eine separate OpenSearch-Instanz auszulagern. Hintergrund sind regulatorische Anforderungen, die eine getrennte Speicherung oder andere Retention- und Zugriffskonzepte für Rohdaten erzwingen.
Der naheliegende erste Gedanke ist architektonisch plausibel: Filebeat auf dem Wazuh-Server einsammeln lassen, an Logstash senden und dort anhand der Quelle oder des Event-Typs auf zwei verschiedene OpenSearch-Ziele routen. Das Problem dabei ist jedoch nicht Logstash selbst, sondern die Art, wie Filebeat in der Standard-Wazuh-Integration eingesetzt wird. Wazuh dokumentiert, dass Filebeat Alerts und archivierte Events aus der Analyse-Engine liest und an den Indexer weiterleitet. Sobald Archive-Events in dieser Standardkette aktiviert werden, landen sie regulär ebenfalls in der Index-Pipeline.
Zusätzlich kommt eine technische Einschränkung von Filebeat hinzu: Es kann pro Instanz nur ein Output definiert werden. Damit scheidet die Idee aus, innerhalb derselben Filebeat-Instanz gleichzeitig Alerts an den Wazuh Indexer und Archive an eine zweite OpenSearch-Instanz zu schicken. Elastic dokumentiert diese Einschränkung ausdrücklich.
Technische Analyse
Für die Bewertung der Architektur ist zunächst wichtig, wie Wazuh Events trennt. Alerts werden standardmäßig in alerts.json und alerts.log geschrieben. Archivierte Roh-Events entstehen nur dann, wenn Event-Archiving aktiviert wurde; dann erzeugt Wazuh unter /var/ossec/logs/archives/ Dateien wie archives.json oder archives.log. Wazuh beschreibt außerdem klar, dass archivierte Events zur Visualisierung im Dashboard zusätzlich in Filebeat aktiviert werden müssen.
Damit ergeben sich drei technisch unterschiedliche Ebenen:
Erstens die Wazuh-Erzeugung der Dateien auf dem Manager.
Zweitens das Einsammeln dieser Dateien durch einen Forwarder wie Filebeat oder Logstash.
Drittens das Schreiben in ein Zielsystem wie Wazuh Indexer oder eine externe OpenSearch-Instanz.
Die kritische Grenze liegt in Ebene zwei. Die Standard-Filebeat-Integration auf dem Wazuh-Server ist für den regulären Wazuh-Datenpfad gedacht. Sie ist nicht dafür ausgelegt, pro Datenstrom unterschiedliche Outputs innerhalb derselben Instanz zu verwenden, weil Filebeat nur einen Output pro Instanz unterstützt.
Daraus folgt: Eine reine „eine Filebeat-Instanz, zwei Ziele“-Architektur ist nicht sauber umsetzbar. Nicht Logstash ist hier das Problem, sondern die Erwartung, dass dieselbe Standard-Filebeat-Instanz selektiv unterschiedliche Ziele bedienen kann.
Hinzu kommt ein zweiter betrieblicher Aspekt: Sobald Archive-Events separat an ein anderes OpenSearch-Cluster gesendet werden, müssen dort passende Index-Templates und gegebenenfalls Ingest-Pipelines vorhanden sein, wenn die Felder, Mappings oder Dashboards konsistent bleiben sollen. Wazuh dokumentiert bei Integrationen mit Elastic/Logstash, dass Pipelines, Plugins und Versionen bewusst abgestimmt werden müssen.
Lösung / Best Practices
Die robusteste Bewertung ist daher: Ja, eine Trennung ist sinnvoll möglich, aber nicht über eine einzelne Standard-Filebeat-Instanz mit internem Per-Stream-Routing.
In der Praxis haben sich dafür zwei belastbare Wege herauskristallisiert.
Variante 1: Zweite Filebeat-Instanz nur für Archive-Events
Das ist der geradlinigste Ansatz, wenn die bestehende Wazuh-Standardintegration für Alerts möglichst unangetastet bleiben soll. Die reguläre Wazuh-Filebeat-Instanz bleibt verantwortlich für alerts.json und damit für die Versorgung des Wazuh Indexers. Parallel wird eine zweite, getrennte Filebeat-Instanz auf demselben Wazuh-Server betrieben, die ausschließlich archives.json liest und an die externe OpenSearch-Instanz sendet.
Der Vorteil dieser Architektur ist die klare Verantwortlichkeit:
- Standard-Alerts bleiben auf dem unterstützten Default-Pfad.
- Archive-Events werden unabhängig davon separat versendet.
- Änderungen an der Archivierungsroute gefährden nicht den Alert-Pfad.
Voraussetzung ist, dass Event-Archiving auf dem Wazuh-Server aktiviert ist, damit archives.json überhaupt geschrieben wird. Wazuh nennt dafür logall_json als relevante Option und dokumentiert den Speicherort der Archivdateien unter /var/ossec/logs/archives/.
Konzeptionell sieht das dann so aus:
Wazuh manager
├─ /var/ossec/logs/alerts/alerts.json -> Standard-Filebeat -> Wazuh Indexer
└─ /var/ossec/logs/archives/archives.json -> Zweite Filebeat-Instanz -> Externe OpenSearch-Instanz
Diese Variante ist besonders dann empfehlenswert, wenn Alerts operativ im Wazuh-Dashboard verbleiben sollen und Archive eher als regulatorischer Datenbestand behandelt werden.
Variante 2: Logstash liest direkt aus archives.json
Die flexiblere, aber auch betreuungsintensivere Variante besteht darin, Logstash direkt auf dem Wazuh-Server oder einem nachgelagerten Ingest-System aus archives.json lesen zu lassen. In diesem Modell bleibt Filebeat entweder nur für Alerts aktiv oder wird für die Archivroute gar nicht verwendet. Logstash kann dann Archive gezielt an die externe OpenSearch-Instanz senden und bei Bedarf zusätzlich weitere Transformationen, Anreicherungen oder Routing-Entscheidungen umsetzen.
Wazuh dokumentiert Logstash als Integrationspfad für den Export von Wazuh-Daten in Elastic-Umgebungen und beschreibt dabei den Betrieb mit Plugins, Zertifikaten und abgestimmten Versionen.
Der große Vorteil von Logstash liegt in der Kontrolle:
- Trennung nach Dateiquelle oder Inhalt
- Enrichment per Filter
- zusätzliche Governance- und Normalisierungsschritte
- flexible Zielindizes und Retention-Strategien
Ein vereinfachtes Modell dafür wäre:
Wazuh manager
├─ /var/ossec/logs/alerts/alerts.json -> Standard-Filebeat -> Wazuh Indexer
└─ /var/ossec/logs/archives/archives.json -> Logstash -> Externe OpenSearch-Instanz
Diese Variante ist vorzuziehen, wenn Archive nicht nur ausgelagert, sondern auch transformiert, angereichert oder nach regulatorischen Klassen segmentiert werden müssen.
Welche Variante ist zu bevorzugen?
Wenn es nur um eine saubere Trennung zwischen Alerts und Archivdaten geht, ist die zweite Filebeat-Instanz meist der pragmatischste Weg. Sie verursacht weniger Umbauten am Wazuh-Standardpfad und passt gut zu Umgebungen, in denen Archive lediglich separat gespeichert werden sollen.
Wenn dagegen komplexeres Routing, Metadaten-Anreicherung, Mandantentrennung oder eine feinere Indexlogik gefordert sind, ist Logstash die bessere Architekturentscheidung.
Lessons Learned / Best Practices
Die wichtigste Lehre aus diesem Szenario ist, dass „separate Speicherung“ und „separates Routing“ in Wazuh zwei verschiedene Fragestellungen sind. Dass Wazuh Archivdaten erzeugen kann, bedeutet noch nicht, dass dieselbe Standard-Transportinstanz diese Daten flexibel auf mehrere Zielsysteme verteilen kann.
Ein häufiger Denkfehler besteht darin, Filebeat wie einen universellen Router zu behandeln. Genau das ist es in dieser Konstellation nicht. Elastic legt fest, dass pro Filebeat-Instanz nur ein Output definiert werden kann. Für regulatorisch motivierte Datentrennung ist daher fast immer eine Trennung auf Instanz- oder Pipeline-Ebene erforderlich.
Ebenso wichtig ist die betriebliche Seite: Wer Archive in ein zweites OpenSearch-System auslagert, muss sich bewusst um Mappings, Templates, Pipelines, Zertifikate, Berechtigungen und Lifecycle-Policies kümmern. Andernfalls entsteht zwar eine zweite Datensenke, aber kein sauber nutzbarer Datenbestand.
Für produktive Umgebungen empfiehlt sich daher ein konservativer Ansatz:
- Alerts auf dem Wazuh-Standardpfad belassen
- Archive über einen dedizierten zweiten Ingest-Pfad versenden
- Zielcluster unabhängig absichern und mit passenden Templates vorbereiten
- klare Ownership zwischen Security Operations und Plattformbetrieb festlegen
Fazit
Die Anforderung, Archive-Events in eine separate OpenSearch-Instanz auszulagern, ist technisch sinnvoll und mit Wazuh gut umsetzbar. Der zentrale Punkt ist jedoch, dass dies nicht sauber über eine einzelne Standard-Filebeat-Instanz mit internem Dual-Routing gelöst werden kann. Filebeat unterstützt nur einen Output pro Instanz, und die Wazuh-Standardintegration ist auf den regulären Indexer-Pfad ausgelegt.
Die praxistauglichen Wege sind deshalb entweder eine zweite Filebeat-Instanz ausschließlich für archives.json oder ein separater Logstash-Pfad, der die Archivdatei direkt verarbeitet. Für reine Datentrennung ist die zusätzliche Filebeat-Instanz meist der einfachste und stabilste Weg. Für komplexere Governance- und Routing-Anforderungen ist Logstash die langfristig flexiblere Architektur.
Quellenverweis
https://documentation.wazuh.com/current/user-manual/manager/indexer-integration.html
https://documentation.wazuh.com/current/user-manual/manager/event-logging.html
https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-indices.html
https://documentation.wazuh.com/current/integrations-guide/elastic-stack/index.html
https://www.elastic.co/docs/reference/beats/filebeat/configuring-output
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/C07CCCCGHHP/p1776085777736879