Einleitung
In Wazuh ist der reine Eingang eines Syslog-Streams noch kein Beleg dafür, dass die Daten auch inhaltlich ausgewertet werden. Gerade bei Netzwerkgeräten wie Netgear-Switches zeigt sich häufig ein typisches Muster: Die Logs landen per rsyslog in einer Datei, der Wazuh-Agent liest diese Datei korrekt ein, im Dashboard tauchen aber keine verwertbaren Events oder Alerts auf. Der Grund liegt meist nicht in der Logsammlung, sondern in der Analysepipeline aus Pre-Decoding, Decoder und Ruleset. Wazuh verarbeitet eingehende Logdaten in genau dieser Reihenfolge und erzeugt erst dann Alerts, die anschließend in alerts.log und alerts.json landen und über den Indexer durchsuchbar werden.
Ausgangslage / Problemstellung
Die Umgebung bestand aus einem Ubuntu-System mit rsyslog, das bereits Syslog-Daten anderer Netzwerkgeräte erfolgreich annahm. Neu hinzu kam ein Netgear-Switch, dessen Meldungen per rsyslog anhand eines String-Matches in eine dedizierte Datei geschrieben wurden, etwa nach /var/log/sws-cv-core-switch.log. Auf Agent-Seite war diese Datei per <localfile> eingebunden, und der Logcollector registrierte auch Events. Das spricht dafür, dass Transport, Dateischreiben und File-Monitoring grundsätzlich funktionierten.
Ein typischer Logeintrag sah wie folgt aus:
2026-04-03T12:00:02+00:00 CV Admin Srv Rm Core-4 TRAPMGR[emWeb]: traputil.c(795) 400675 %% HTTP session : Login to the switch is not successful, User ID: checkingafterintegration
Die entscheidende Beobachtung ergab der Ruleset-Test: Phase 1, also das Pre-Decoding, erkannte lediglich den Timestamp. Phase 2 endete mit No decoder matched. Damit war klar, dass Wazuh die Datei zwar liest, das Format aber keinem vorhandenen Decoder zuordnen kann. Ohne Decoder gibt es keine extrahierten Felder, ohne passende Regel in der Folge keine Alerts und damit auch nichts sinnvoll Suchbares in Discover. Genau für diese Prüfung empfiehlt Wazuh den Einsatz von wazuh-logtest beziehungsweise des Dashboard-Tools „Ruleset test“.
Technische Analyse
Das Kernproblem lag in der Struktur des Netgear-Logs. Die Zeilen sind zwar syslog-ähnlich, folgen aber nicht sauber einem Standardformat, das von den mitgelieferten Wazuh-Decodern zuverlässig erkannt wird. Wazuh versucht in der Pre-Decoding-Phase zunächst, generische Elemente wie Zeitstempel, Hostname und Programmnamen zu extrahieren. Bei klassischen Syslog-Quellen gelingt das oft automatisch. Bei proprietären oder abweichenden Netzwerk-Logs bleibt dieser Schritt jedoch unvollständig, sodass der nachgelagerte Decoder keine stabile Ankerstruktur mehr vorfindet. Wazuh weist selbst darauf hin, dass Default-Decoder nicht jedes kundenspezifische oder nicht standardisierte Logformat korrekt parsen.
Genau deshalb reichte es in diesem Fall nicht aus, nur rsyslog-seitig sauber in eine Datei zu schreiben. Der Datenfluss war technisch intakt, aber semantisch unvollständig. Das ist ein wichtiger Unterschied:
Datei vorhanden und vom Agent gelesen bedeutet nicht automatisch, dass Analyse und Alarmierung funktionieren.
Ein weiterer interessanter Punkt ist der Versuch, mit <out_format> einen festen Präfix wie CVCore: vor jede Zeile zu setzen. Diese Idee ist grundsätzlich sinnvoll, weil ein eindeutiger Präfix das Matching für einen Custom Decoder deutlich vereinfacht. Wazuh unterstützt out_format im <localfile>-Block explizit, um beim Versand ein angepasstes Zielformat zu erzeugen. Auch aus der Community wird dieser Ansatz empfohlen, wenn proprietäre Logheader schwierig zu dekodieren sind.
Der Zwischenschritt schlug hier jedoch zunächst fehl, weil der anschließend definierte Decoder mit einer fehlerhaften Regex geladen wurde. Der Analysis-Daemon meldete einen Syntaxfehler und verweigerte daraufhin die Decoder-Konfiguration. Solche Fehler sind typisch, wenn Sonderzeichen unnötig escaped werden oder der Prematch nicht exakt zum tatsächlich gesendeten Präfix passt. Das ist besonders kritisch, weil ein fehlerhafter Decoder nicht nur die neue Logquelle unbrauchbar macht, sondern den Reload der Analysekonfiguration insgesamt stören kann.
Lösung / Best Practices
Die saubere Lösung bestand aus vier Schritten.
Zuerst musste verifiziert werden, dass die Logquelle tatsächlich zuverlässig bis zur Datei gelangt. Dafür sind drei Prüfungen sinnvoll: Netzwerktransport zum Syslog-Listener, Inhalt der Zieldatei und Event-Zähler des Agenten. Erst wenn diese drei Ebenen stimmen, lohnt sich die Decoder-Arbeit.
Danach sollte der Agent die Datei explizit als lokale Logquelle überwachen. Eine robuste Basiskonfiguration sieht so aus:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/sws-cv-core-switch.log</location>
</localfile>
Wenn das Format schwer greifbar ist, kann ein definierter Präfix per out_format helfen, damit jede Zeile am Wazuh-Server mit einem stabilen Marker beginnt:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/sws-cv-core-switch.log</location>
<out_format>CVCore: $(log)</out_format>
</localfile>
Wichtig ist dabei die Erwartungshaltung: out_format ersetzt keinen Decoder. Es macht die Daten lediglich leichter erkennbar. Die eigentliche Interpretation erfolgt weiterhin erst über Decoder und Regeln.
Im nächsten Schritt gehört ein Custom Decoder auf den Wazuh-Server, typischerweise in /var/ossec/etc/decoders/local_decoder.xml. Wazuh dokumentiert genau diesen Pfad für eigene Decoder. Der Decoder sollte nicht sofort mit komplexen Extraktionen starten, sondern zuerst nur den neuen Präfix sauber erkennen. Darauf aufbauend wird ein Child-Decoder ergänzt, der die relevanten Felder extrahiert.
Ein pragmatisches Beispiel für diese Netgear-ähnlichen Meldungen wäre:
<decoder name="netgear_cvcore_base">
<prematch>^CVCore:</prematch>
</decoder><decoder name="netgear_cvcore_auth_failed">
<parent>netgear_cvcore_base</parent>
<regex>^CVCore:\s+\S+\s+(.+?)\s+([A-Z_]+)\[([^\]]+)\]:\s+([^(]+)\((\d+)\)\s+(\d+)\s+%%\s+(.+)$</regex>
<order>device_name, module, interface, source_file, source_line, event_id, message</order>
</decoder>
Danach folgt die zugehörige Regel in /var/ossec/etc/rules/local_rules.xml. Für Custom Rules empfiehlt Wazuh IDs im Bereich 100000 bis 120000, um Konflikte mit Standardregeln zu vermeiden.
Ein einfaches Beispiel:
<group name="netgear,network,authentication,">
<rule id="100100" level="5">
<decoded_as>netgear_cvcore_auth_failed</decoded_as>
<match>couldn't login|Login to the switch is not successful|Authenticate user unsuccessful</match>
<description>Netgear Core Switch: Fehlgeschlagene Anmeldung erkannt</description>
</rule>
</group>
Erst danach sollte mit wazuh-logtest beziehungsweise im Dashboard unter „Tools / Ruleset test“ geprüft werden, ob Phase 2 jetzt einen Decoder liefert und ob eine Regel feuert. Genau für diesen Ablauf ist das Tool gedacht: Log einfügen, Decoder-Zuordnung prüfen, Matching-Regel bestätigen. Sobald die Tests erfolgreich sind, wird der Wazuh-Manager neu gestartet, damit die Änderungen produktiv Alerts generieren.
Für die Verifikation auf Serverseite sind anschließend zwei Orte besonders wichtig:
/var/ossec/logs/alerts/alerts.log
/var/ossec/logs/alerts/alerts.json
Taucht dort nach einem Testevent ein Alert auf, ist die Pipeline vollständig: Agent liest Datei, Server dekodiert Event, Regel erzeugt Alert, Indexer macht ihn durchsuchbar.
Lessons Learned / Best Practices
Die wichtigste Erkenntnis aus diesem Fall ist, dass Logtransport und Loganalyse in Wazuh strikt getrennt betrachtet werden müssen. Sobald im Ruleset-Test No decoder matched erscheint, liegt das Problem nicht mehr bei rsyslog oder der Dateisammlung, sondern im Analysemodell.
Für Netzwerkgeräte mit proprietären Syslog-Varianten empfiehlt es sich, immer zuerst mit einem minimalen Decoder zu starten. Erst wenn Prematch oder Programmanbindung stabil greifen, sollten zusätzliche Felder per Regex extrahiert werden. Das reduziert Fehlersuche erheblich.
Ebenso wichtig ist ein eindeutiger Präfix per out_format, wenn das Originalformat keinen belastbaren Programmnamen oder Header liefert. Diese Technik ist kein Ersatz für Parsing, aber ein sehr wirksamer Stabilisator für Custom-Decoding. Sie ist besonders nützlich, wenn mehrere unstrukturierte Quellen über denselben Agenten laufen.
Custom Rules und Decoder sollten außerdem sauber getrennt von Standarddateien abgelegt werden. Wazuh empfiehlt für Decoder eigene Dateien unter /var/ossec/etc/decoders/ beziehungsweise local_decoder.xml und für kleinere Regelanpassungen local_rules.xml. Das schützt die Konfiguration vor Verlusten oder Konflikten bei Upgrades.
Ein weiterer Betriebsaspekt betrifft die Suche im Dashboard: Roh eingelesene Logs ohne Alerting sind oft schwer auffindbar, weil Administratoren intuitiv nach Agent oder bekannten Standardfeldern filtern. Sobald eine dedizierte Regel greift, wird die Quelle über Gruppen, Regel-ID, Description und extrahierte Felder sauber sichtbar. Für operative Teams ist das deutlich wartbarer als die ausschließliche Suche nach Dateipfaden oder Volltextfragmenten.
Fazit
Der Fall zeigt sehr klar ein klassisches Wazuh-Missverständnis: Dass ein Agent Events zählt, bedeutet noch nicht, dass Wazuh sie semantisch versteht. Bei den Netgear-Switch-Logs war die Sammlung bereits korrekt, die Auswertung scheiterte aber an einem fehlenden Decoder. Der entscheidende Weg zum Ziel bestand daher nicht in weiterer rsyslog-Feinarbeit, sondern in einer stabilen Wazuh-Analysepipeline aus optionalem out_format, passendem Custom Decoder, sauberer Custom Rule und konsequentem Testen mit wazuh-logtest. Genau so werden proprietäre Netzwerk-Logs in Wazuh aus „irgendwo vorhanden“ zu tatsächlich nutzbaren Security-Events.
Quellenverweis
https://documentation.wazuh.com/current/user-manual/ruleset/decoders/custom.html
https://documentation.wazuh.com/current/user-manual/ruleset/testing.html
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html
https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html
https://groups.google.com/g/wazuh/c/aeRzqoBYIKU
https://github.com/wazuh/wazuh/issues/33294
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/p1775235317995009