Synology-Logs in Wazuh: Warum deine Regeln erst mit den richtigen Decodern funktionieren

Wer sein Synology NAS mit Wazuh überwacht, stolpert früher oder später über Community-Projekte wie dieses:

GitHub: Tomo-9925 / wazuh-synology-dsm-decoder-and-rules
– synology-rules.xml (Regeln)
– synology-syslog.xml (Decoder)

Genau das wollte auch ein User im Wazuh-Community-Channel einbinden – und bekam nur:

XML syntax error

Die Ursache war am Ende nicht „kaputte XML“, sondern die Reihenfolge & Vollständigkeit der Integration.

1. Warum die Regeln alleine nicht funktionieren

Im Regelset sieht man z. B.:

<rule id="100001" level="5">
    <decoded_as>synology-connection</decoded_as>
    ...
</rule>

Damit sagt die Regel im Klartext:

„Ich erwarte, dass es einen Decoder gibt, der Events als synology-connection dekodiert.“

Wenn du jetzt nur synology-rules.xml einbindest, aber nicht die dazugehörigen Decoder aus synology-syslog.xml, passiert Folgendes:

Wazuh lädt das Regelset
Sieht <decoded_as>synology-connection</decoded_as>
Findet dazu keinen passenden Decoder-Namen
Beim Laden des kompletten Rulesets kann das zu Syntax- / Validierungsfehlern führen

Ergebnis:
Dein Manager startet entweder nicht sauber, oder du bekommst Fehler à la „XML syntax error“, obwohl die Datei selbst formal korrekt ist.

Damit das Ganze sauber läuft, brauchst du:

Decoder-Datei (synology-syslog.xml)
→ Sie sorgt dafür, dass Synology-Syslog-Nachrichten in interne Felder und einen Decoder-Namen (synology-connection, synology-auth etc.) übersetzt werden.
Regel-Datei (synology-rules.xml)
→ Sie baut auf diesen Decoder-Namen auf (<decoded_as>…</decoded_as>) und bewertet die Events.

Auf dem Wazuh-Manager:

/var/ossec/etc/decoders/synology-syslog.xml
/var/ossec/etc/rules/synology-rules.xml

/var/ossec/bin/wazuh-logtest

systemctl restart wazuh-manager

In dem Slack-Thread war genau das die Lösung:

User hatte nur die Regeln eingebunden → Fehler
Dann auch die Decoder-Datei eingebunden → alles lief.

In der Community-Antwort hieß es sinngemäß:

„War mir nicht bewusst, dass die Reihenfolge wichtig ist. Jetzt funktioniert’s.“

Gemeint ist nicht nur die Lade-Reihenfolge (Decoder werden generell vor Regeln geladen), sondern vor allem:

Du kannst keine Regeln verwenden, die sich auf einen Decoder beziehen, den es (noch) nicht gibt
In vielen Community-Beispielen sind Decoder und Regeln getrennte Dateien – du musst beides übernehmen, nicht nur das, was „spannender“ aussieht (Spoiler: das sind meistens die Regeln)

Wenn du wieder mal an einem „XML syntax error“ verzweifelst:

In die Logs schauen
- Auf dem Manager: cat /var/ossec/logs/ossec.log
- Dort steht meist ziemlich klar, welche Datei und manchmal sogar welche Zeile Probleme macht.
Prüfen, ob alle referenzierten Decoder existieren
- Kommen in den Regeln <decoded_as>xyz</decoded_as> oder <if_decoder_name>xyz</if_decoder_name> vor?
- Gibt es dazu wirklich einen <decoder name="xyz"> in irgendeiner Datei unter etc/decoders/?
Regeln testweise auskommentieren / entfernen
- Wenn du unsicher bist, ob eine neu hinzugefügte Datei das Problem ist:
  - Datei kurz entfernen oder umbenennen
  - wazuh-manager neu starten
  - Wenn es dann läuft → Fokus auf diese Datei

Aus dem kleinen Synology-Beispiel lässt sich eine generelle Lektion für Wazuh mitnehmen:

Decoder sind die Grundlage – Regeln sind das „Gehirn“ darüber.
Community-Regeln, die decoded_as verwenden, brauchen immer die passenden Decoder-Dateien.
XML-Fehler bedeuten nicht automatisch „kaputte Datei“ – oft fehlt einfach ein Referenz-Baustein.

Wenn du magst, kann ich als nächsten Blogpost etwas machen wie:

„How-To: Synology DSM sauber in Wazuh integrieren (Syslog, Decoder, Regeln, Index-Felder)“
oder
„Checkliste: So integrierst du Community-Decoders & Rulesets in Wazuh, ohne den Manager zu schrotten“