Sophos Firewall Logs in Wazuh: Warum OpenSearch Data Streams (noch) nicht nativ gehen – und wie man Logs sauber in eigene Indizes routet und per ISM „datastream-ähnlich“ verwaltet

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Netzwerk- und Firewall-Telemetrie wie Sophos-SSL-Rejects ist für Detection Engineering und Threat Hunting wertvoll – vorausgesetzt, die Daten landen strukturiert, performant und mit sinnvoller Lifecycle-Strategie im Indexer. In OpenSearch sind Data Streams ein komfortables Modell für kontinuierliche Logdaten. In Wazuh ist der Standardpfad jedoch weiterhin auf zeitbasierte Indizes plus Index State Management (ISM) ausgelegt. Dieser Beitrag zeigt, was aktuell möglich ist, wie Sie Sophos-Events in einen dedizierten Index-Prefix (z. B. sophos-alerts-*) schreiben und wie Sie „Data-Stream-ähnliches“ Rollover/Retention in Wazuh sauber abbilden.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

  • Sophos Firewall schreibt Logs in eine Datei (/var/log/sophos.log) auf einem Ubuntu-Host.
  • Custom Decoder sind bereits vorhanden und funktionieren.
  • Ziel: Logs nicht in den Standard-Indizes (wazuh-alerts-4.x-* / tägliche Indizes) ablegen, sondern in einem eigenen Index-Namensraum – idealerweise als OpenSearch Data Stream.
  • Fragen:
    1. Wie werden Sophos-Logs am besten zu Wazuh geleitet?
    2. Kann Wazuh statt täglicher Indizes „Data Streams“ nutzen?
    3. Wie route ich Sophos-Events in einen eigenen Index, ohne am Agent „Indexing“ zu konfigurieren?
    4. Wo landen „Raw Logs“ vs. dekodierte Felder/Alerts?

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) Wazuh nutzt heute primär zeitbasierte Indizes + Templates + ISM – nicht OpenSearch Data Streams

Wazuh schreibt Alerts standardmäßig in wazuh-alerts-* und nutzt dazu einen Shipper (Filebeat bzw. Indexer Connector), der Alerts in (typisch) tägliche Indexnamen formatiert. Die Wazuh-Doku beschreibt explizit, dass das Standardverhalten tägliche Indizes erzeugt und dass die Index-Namensbildung über die Filebeat Ingest-Pipeline (date_index_name) gesteuert werden kann.

OpenSearch Data Streams sind ein eigenständiges Konstrukt zur Verwaltung zeitbasierter, append-only Daten mit automatisch gemanagten Backing Indices.
Wazuh hat hierzu bereits ein Feature-Request/Issue, Data Streams statt klassischer Indizes zu verwenden – es ist also als Wunsch/Verbesserung adressiert, aber nicht der etablierte Default.

2) „Data Stream“ vs. Wazuh-Standard: Was Sie heute funktional erreichen können

Auch ohne Data Streams können Sie fast dasselbe Ziel erreichen:

  • Eigener Index-Prefix für Sophos (Organisation/Abgrenzung)
  • Automatisches Rollover/Retention via ISM (Lifecycle) statt manueller Index-Pflege

Wazuh dokumentiert ISM als Mechanismus, der Index-Operationen (z. B. Rollovers, Löschung) automatisiert – basierend auf Alter/Größe/Dokumentzahl.

3) Agent vs. Manager: Wo wird das Indexziel entschieden?

Wichtig für die Architektur: Der Agent „entscheidet“ nicht, in welchen Index etwas geht. Der Agent sammelt Logs (localfile, Syslog, etc.), der Manager korreliert/alertet, und der Shipper/Indexer-Pipeline entscheidet über den Zielindex für indexierte Dokumente. Wazuh beschreibt den Indexer-Integrationspfad (Filebeat/Indexer Connector) als Forwarder vom Manager zum Indexer.

4) Raw Logs vs. Alerts: Wo landet was?

  • Alerts (dekodiert + Regelmetadaten) gehen in wazuh-alerts-* (oder Ihren Custom-Index, wenn geroutet).
  • Alle Events (inkl. nicht-alerting) können in archives.json geschrieben und optional in wazuh-archives-* indexiert werden – erfordert bewusstes Aktivieren von logall_json.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: Ingestion sauber aufsetzen (Sophos → Wazuh)

Sie haben zwei robuste Standardwege:

  1. Syslog direkt an den Wazuh Manager (Manager als Syslog Listener via <remote>). Die <remote>-Optionen (connection/port/protocol/allowed-ips etc.) sind dokumentiert.
  2. Rsyslog-Relay/Ubuntu-Host + Wazuh Agent: Sophos schreibt lokal in Datei oder Rsyslog nimmt Syslog an, schreibt in /var/log/sophos.log, und der Wazuh Agent liest diese Datei per <localfile>. Das <localfile>-Konzept und die Optionen sind dokumentiert.
    Für Skalierung und Entkopplung ist das Rsyslog-Relay-Modell in der Praxis oft stabiler (Queueing, zentrale Sammelstelle). Zusätzlich gibt es einen offiziellen Wazuh-Guide zur Rsyslog-Weiterleitung.

Minimalbeispiel Agent (Datei lesen):

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/sophos.log</location>
</localfile>

Schritt 2: „Anchor“ schaffen, damit Routing technisch möglich ist (ohne Agent-Sonderlogik)

Ohne irgendein Merkmal kann die Ingest-Pipeline nicht entscheiden, ob ein Dokument nach sophos-* oder in den Default soll. Der sauberste Anker ist ein Rule-Group-Tag (oder ein anderes eindeutiges Feld im Alert-Dokument).

Best Practice: Regeln für Sophos in eine Gruppe, z. B. sophos-firewall. Das erzeugt im Alert rule.groups, worauf die Pipeline prüfen kann.

Schritt 3: Zielindex über Filebeat Ingest Pipeline routen (date_index_name + if-Bedingung)

Wazuh dokumentiert, dass die Index-Namensbildung über /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json gesteuert werden kann (Processor date_index_name, date_rounding, Format).

Prinzip:

  • Wenn ctx.rule.groups Ihre Sophos-Gruppe enthält → Indexprefix sophos-alerts-
  • Sonst → Standardprefix (z. B. wazuh-alerts-4.x-)

Der Processor date_index_name existiert im Wazuh-Alerts-Pipeline-File (GitHub-Referenz auf die Pipeline-Datei).

Wichtig: Nach Änderungen müssen die Pipeline(s) neu geladen und Filebeat neu gestartet werden (in Wazuh-Umgebungen üblich; je nach Setup via filebeat setup --pipelines und Service-Restart).

Schritt 4: Lifecycle wie „Data Streams“ – über ISM statt Data Stream

Anstatt Data Streams setzen Sie für sophos-alerts-* eine passende ISM-Policy (Rollover/Retention). Wazuh beschreibt ISM und wie Policies auf Indexpatterns angewendet und geprüft werden.

Damit erhalten Sie den praktischen Effekt:

  • kontrollierte Indexgrößen
  • automatische Rotation
  • automatisches Löschen alter Daten
  • bessere Performance als „unendliche“ Indizes

Schritt 5: Rohdaten vollständig behalten (optional) – Archives aktivieren und indexieren

Wenn Sie nicht nur Alerts, sondern alle Sophos-Events (inkl. nicht-alerting) später durchsuchen wollen:

  • logall_json aktivieren → schreibt alle Events nach archives.json
  • Filebeat Archives-Modul aktivieren → indexiert nach wazuh-archives-*

Das erhöht Speicher- und Indexlast spürbar; daher nur aktivieren, wenn Forensik/Compliance den Mehrwert rechtfertigt.

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • Wazuh Data Streams: Aktuell kein „Drop-in“-Schalter auf Data Streams; es gibt aber ein klares Tracking/Feature-Request dazu.
  • Index-Design: Für „High Volume“ sind getrennte Indizes pro Source-Typ (z. B. Sophos) ein gutes Pattern – kombiniert mit ISM, nicht mit gigantischen Dauerindizes.
  • Routing braucht ein Merkmal: Ohne Regelgruppe/Tag/Feld kann die Pipeline nicht deterministisch routen – ein minimaler Rule-Anchor ist daher praktisch Pflicht.
  • Raw vs. Alert trennen: Alerts sind kuratiert (Rules/Severity), Archives sind „alles“ – und müssen bewusst aktiviert werden.
  • Ingestion stabil halten: Syslog-Relay (Rsyslog) entkoppelt Firewall-Push-Verhalten von Wazuh-Last und ist operational häufig robuster als direkte Pushes.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn Sie Sophos-Firewall-Logs „wie einen Data Stream“ verwalten möchten, ist die Wazuh-Realität derzeit: zeitbasierte Indizes plus ISM statt nativer OpenSearch Data Streams. Funktional erreichen Sie das Ziel dennoch: Routen Sie Sophos-Alerts über einen Rule-Group-Anker in einen eigenen Index-Prefix (sophos-alerts-*) und steuern Sie Rollover/Retention per ISM. Für vollständige Rohdaten aktivieren Sie zusätzlich Archives (archives.json / wazuh-archives-*) – mit klarer Kosten-Nutzen-Abwägung bei Storage und Performance.

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