Welche Datenquellen lassen sich an Wazuh anbinden? Die Antwort entscheidet maßgeblich darüber, wie vollständig das Sicherheitslagebild eines Unternehmens ist. Denn ein SIEM kann nur die Ereignisse auswerten, die es tatsächlich erhält. Dafür müssen die relevanten Systeme angebunden sein und zuverlässig Protokolldaten liefern.
Wie wichtig das ist, zeigt auch ein aktueller Fall bei Cisco: Eine Schwachstelle in der Firewall-Protokollierung kann dazu führen, dass ein Gerät unter Last ausfällt und keine Logs mehr liefert (CVE-2026-20154). Welche Datenquellen Wazuh erfassen kann, welche Unterschiede zwischen agentbasierter und agentloser Anbindung bestehen und warum sich ein Blick auf die gespeicherten Rohdaten lohnt, zeigt dieser Beitrag.
Datenquellen: Agent-basiert vs. agentless
Wazuh erfasst Daten auf zwei grundsätzlich unterschiedlichen Wegen.
Der Wazuh-Agent läuft direkt auf dem überwachten System, etwa auf Windows- und Linux-Servern, Arbeitsplatzrechnern oder Cloud-Instanzen. Er liest lokale Protokolle, prüft Dateiintegrität, erkennt Rootkits und meldet Konfigurationsabweichungen. Die Daten gehen verschlüsselt an den Wazuh Manager.
Für Systeme, auf denen sich kein Agent installieren lässt, bietet Wazuh die agentlose Erfassung an. Dazu zählen Netzwerkgeräte wie Firewalls, Switches oder Router, aber auch Appliances und IoT-Geräte. Diese senden ihre Ereignisse per Syslog an den Wazuh Manager, der sie dort regelbasiert auswertet. Für einzelne Prüfungen, etwa Konfigurationsabfragen, kann Wazuh solche Systeme zusätzlich per SSH gezielt abfragen.
Für Unternehmen ist die Unterscheidung vor allem bei der Planung relevant: Server und Endgeräte lassen sich mit dem Agenten engmaschig überwachen, die Netzwerkinfrastruktur dagegen meist nur über Syslog. Ein vollständiges Lagebild entsteht erst, wenn beide Wege kombiniert werden.
Indexe: wazuh-archives und wazuh-alerts
Nicht jedes Ereignis, das Wazuh empfängt, erzeugt auch einen Alarm. Entscheidend ist, ob ein Ereignis eine Regel aus dem Ruleset trifft und welchen Schweregrad (Level) diese Regel hat. Nur Ereignisse, die eine solche Regel auslösen, landen im Index wazuh-alerts.
Alle eingehenden Ereignisse, unabhängig davon, ob sie eine Regel ausgelöst haben, lassen sich zusätzlich im Index wazuh-archives speichern. Diese Funktion muss im Wazuh Manager (logall und logall_json in der ossec.conf) sowie in Filebeat aktiv eingeschaltet werden, da sie standardmäßig deaktiviert ist.
Für Unternehmen ist dieser Unterschied besonders bei Nachweispflichten und Vorfallsanalysen relevant. Erkennt ein Regelwerk zum Zeitpunkt eines Angriffs ein bestimmtes Verhalten noch nicht, bleibt das zugehörige Ereignis in den Archives trotzdem nachvollziehbar und lässt sich im Nachhinein auswerten.
Archives-Funktion: Vollständige Protokollierung statt nur Alarme
Die Archives-Funktion schließt die Lücke zwischen dem, was ein Regelwerk heute erkennt, und dem, was tatsächlich im Netzwerk passiert. Jedes empfangene Ereignis wird im Rohformat gespeichert, unabhängig vom Alarmstatus.
Ein Ereignis in wazuh-archives enthält den vollständigen Agent- und Regelkontext, auch wenn der Level unterhalb der üblichen Alarmschwelle liegt:
{ "timestamp": "2026-10-12T08:14:03.221+0200", "agent": {"id": "004", "name": "fw-opnsense-01"}, "rule": {"level": 3, "description": "Firewall connection allowed", "id": "4501"}, "location": "/var/log/syslog", "full_log": "Oct 12 08:14:03 opnsense filterlog: ... pass ..."}Für Unternehmen, die Nachweispflichten erfüllen müssen, etwa im Rahmen von NIS2, ist das relevant. Ein Alarm allein belegt nur, was das Regelwerk zum jeweiligen Zeitpunkt als auffällig eingestuft hat. Die Archives liefern darüber hinaus die Rohdaten, um einen Vorfall im Nachhinein vollständig zu rekonstruieren oder eine Behörde im Meldefall mit Belegen zu versorgen.
Praxisbeispiel: Eine Firewall per Syslog anbinden
Die Anbindung einer Firewall läuft in der Regel über zwei Teile: Auf der Firewall wird ein Syslog-Ziel eingetragen, auf dem Wazuh Manager wird ein passender Decoder benötigt, der das empfangene Format versteht.
Im Wazuh Manager wird dazu in der ossec.conf ein Remote-Eingang für Syslog definiert:
<remote> <connection>syslog</connection> <port>514</port> <protocol>udp</protocol> <allowed-ips>192.0.2.10/32</allowed-ips></remote>Auf der Firewall selbst reicht häufig eine einzelne Konfigurationszeile, etwa bei einer Cisco-ASA-Firewall:
logging host 192.0.2.5logging trap informationalWichtig dabei ist, wie der aktuelle Fall von CVE-2026-20154 zeigt, dass eine aktivierte Syslog-Protokollierung selbst ausreichend dimensioniert und aktuell gepatcht sein muss. Eine Firewall, die unter Last ausfällt, liefert in diesem Moment auch keine Daten mehr an Wazuh.
Wazuh Dashboard: Datenquellen im Überblick
Im Wazuh Dashboard lässt sich der Überblick über angebundene Agenten und Syslog-Quellen direkt im Menu “Agents” sowie über eine eigene Visualisierung auf Basis von agent.name und location abrufen. Sinnvoll ist eine Übersicht, die Ereignisse pro Quelle, den Anteil agentloser Systeme und auffällig inaktive Agenten zeigt.
Wazuh Dashboard ‘Quellen, Syslog & Agent-Status’: Von rund 62,4 Millionen erfassten Events stammen 98,75 Prozent aus agent-basierten Quellen, der Rest aus angebundenen Syslog-Quellen (Stand Oktober 2026).
Fazit
Die Frage, welche Datenquellen an Wazuh angeschlossen werden, entscheidet darüber, wie vollständig das Lagebild eines Unternehmens am Ende ist. Agent-basierte und agentlose Erfassung ergänzen sich, die Archives-Funktion sichert zusätzlich das ab, was aktuelle Regeln noch nicht erkennen. Der aktuelle Fall bei Cisco zeigt, dass sich daneben auch ein Blick auf die Robustheit der Quellen selbst lohnt, nicht nur auf ihre Anbindung.
Wazuh-Datenquellen professionell anbinden
DigiFors unterstützt bei der Bestandsaufnahme vorhandener Systeme, der Entscheidung zwischen Agent und agentloser Erfassung und der Konfiguration einzelner Decoder und Rulesets.
