Custom Fortigate-Decoders und -Rules nach Linux-Migration in Wazuh: „Permission denied“ sauber beheben und Updatesicher deployen

von

Einleitung

Bei einer Migration des Wazuh-Servers (z. B. von CentOS 8 auf Rocky Linux) sind Custom Decoders und Rules oft der Teil, der am schnellsten „still“ kaputtgeht: Die Dateien sind zwar kopiert, aber Wazuh lädt sie nicht – und im Dashboard erscheinen kryptische Meldungen wie „No decoder was returned (1502)“ oder „No rule was returned (1414)“. In Security-Operations ist das besonders kritisch, weil damit genau die umgebungsspezifischen Detection-Regeln (z. B. Fortigate-Events) ausfallen und relevante Logs wieder als „unbekannt“ oder gar nicht korreliert werden.

Der Thread zeigt ein sehr typisches Muster: Dateien werden per scp übertragen, landen im richtigen Pfad – aber wazuh-analysisd kann sie nicht lesen.

Ausgangslage / Problemstellung

Nach der Migration wurden Custom-Dateien für Fortigate-Decoders und -Rules manuell auf den neuen Server kopiert und in folgende Verzeichnisse gelegt:

  • /var/ossec/etc/decoders und /var/ossec/etc/rules (erstes Ziel)
  • später testweise auch /var/ossec/ruleset/decoders und /var/ossec/ruleset/rules

Im Wazuh Dashboard traten danach Fehler beim Anzeigen/Lesen der Dateien auf, u. a.:

  • Error: No decoder was returned (1502) - Error reading decoders file: ...
  • Error: No rule was returned (1414) - Error reading rules file: ...

Der entscheidende Hinweis kam aus ossec.log:

  • wazuh-analysisd: WARNING: (1103): Could not open file ... [(13)-(Permission denied)]

Damit ist klar: Nicht XML-Syntax oder Pfad sind das Kernproblem, sondern Dateirechte/Ownership.

Technische Analyse

Warum „No decoder/rule was returned“ häufig ein Symptom ist

Die Dashboard-Fehlercodes (1502/1414) entstehen oft nicht, weil die Dateien fachlich falsch sind, sondern weil das Backend die Datei nicht öffnen kann. Der Wazuh-Manager (insb. wazuh-analysisd) muss die Decoder-/Rule-Dateien lesen, parsen und laden. Wenn das Lesen scheitert, bekommt das Dashboard keine Inhalte zurück und meldet „No decoder/rule was returned“.

Root-Ursache: scp + neue Systemhärtung = Ownership/Permissions passen nicht

In der Praxis gibt es bei OS-Migrationen drei typische Permission-Fallen:

  1. Ownership nicht mehr wazuh:wazuh
    Nach Copy/Restore (oder bei unterschiedlichen Defaults) liegen Dateien schnell bei root:root oder anderen Usern.
  2. Dateimodus zu restriktiv oder inkonsistent
    Wazuh erwartet im Regelfall, dass seine Ruleset-Dateien für den wazuh-User lesbar sind. In vielen Setups ist 660 (rw-rw—-) der Standard, zusammen mit wazuh:wazuh.
  3. SELinux-Kontexte (Rocky Linux!)
    Selbst bei korrekten Unix-Rechten kann SELinux den Zugriff blockieren. Das äußert sich ebenfalls als „Permission denied“. (Im Thread war bereits Ownership/Mode die Ursache – aber nach CentOS→Rocky ist SELinux als zweite Ebene unbedingt im Blick zu behalten.)

Best Practice: Updatesichere Ablage für Custom Content

Wazuh empfiehlt für Customizing typischerweise die lokalen Dateien:

Das reduziert Upgrade-Risiken, weil eigene Dateien nicht durch Ruleset-Updates überschrieben werden. Alternativ kann man eigene Dateien auch über den <ruleset>-Block in ossec.conf gezielt includen (Decoder/Rule Include/Dir/Exclude), was besonders bei größeren Custom-Rulesets sinnvoll ist. wazuh-documentation-49-master.readthedocs.io

Lösung / Best Practices

1) Fehlerbild korrekt verifizieren

Auf dem Manager:

sudo grep wazuh-analysisd /var/ossec/logs/ossec.log | grep -i "permission\|could not open\|1103"

Wenn dort (13)-(Permission denied) steht, ist der Fix in der Regel unmittelbar: Ownership/Mode korrigieren (und ggf. SELinux).

2) Ownership und Rechte sauber setzen

Für die betroffenen Custom-Dateien (Beispielpfade aus dem Thread):

sudo chown wazuh:wazuh /var/ossec/ruleset/decoders/*.xml /var/ossec/ruleset/rules/*.xml
sudo chmod 660 /var/ossec/ruleset/decoders/*.xml /var/ossec/ruleset/rules/*.xml

Wenn die Dateien in /var/ossec/etc/decoders bzw. /var/ossec/etc/rules liegen:

sudo chown wazuh:wazuh /var/ossec/etc/decoders/*.xml /var/ossec/etc/rules/*.xml
sudo chmod 660 /var/ossec/etc/decoders/*.xml /var/ossec/etc/rules/*.xml

Hinweis: Diese Ownership/Permission-Kombination taucht auch in Wazuh-eigenen Automatisierungsbeispielen auf (z. B. beim „Ruleset as Code“-Ansatz, der nach dem Pull bewusst chown wazuh:wazuh und chmod 660 setzt). Wazuh

3) (Rocky Linux) SELinux als zweite Ebene prüfen

Wenn nach chown/chmod weiterhin „Permission denied“ auftaucht:

  • Temporär prüfen, ob SELinux beteiligt ist: getenforce
  • Kontexte für die betroffenen Dateien wiederherstellen (konservativ): sudo restorecon -Rv /var/ossec

In gehärteten Umgebungen ist das oft der fehlende Schritt nach Migration oder manuellen Dateioperationen.

4) Wazuh Manager neu starten und Ladevorgang kontrollieren

sudo systemctl restart wazuh-manager
sudo tail -n 200 /var/ossec/logs/ossec.log

Achte darauf, dass keine neuen Parser-/Load-Fehler auftauchen.

5) Updatesichere Ablagestrategie für Fortigate-Decoders/Rules

Wenn die Fortigate-Customizations in mehreren Dateien gepflegt werden (z. B. fortigateV7_decoders.xml, fortigate-firewall-v7_rules.xml), sind zwei robuste Wege üblich:

Variante A: Konsolidieren in local_decoder.xml / local_rules.xml (simpel und upgradefest)

Variante B: Eigene Dateien behalten und über <ruleset> gezielt einbinden (skalierbar)

  • Eigene decoder_include / rule_include oder *_dir im <ruleset> konfigurieren, inkl. Pattern-Steuerung. wazuh-documentation-49-master.readthedocs.io
    Das ist besonders sinnvoll, wenn Fortigate-Regeln als Paket/Repo versioniert werden.

Lessons Learned / Best Practices

  • Dashboard-Fehler (1502/1414) sind häufig nur „Folgefehler“ – die Wahrheit steht meist in ossec.log bei wazuh-analysisd.
  • Nach Migrationen immer Ownership/Permissions prüfen, bevor man XML-Debugging betreibt.
  • Rocky Linux bringt SELinux realistisch ins Spiel: restorecon gehört in die Standard-Checkliste.
  • Custom Content updatefest halten: lokale Dateien oder kontrollierte <ruleset>-Includes statt „wild“ im Standard-Ruleset verteilen. Wazuh Dokumentation+2Wazuh Dokumentation+2
  • Automatisiere den Ruleset-Deploy (Git/CI/CD) und setze am Ende konsequent chown/chmod, wie es auch im „Ruleset as Code“-Ansatz vorgesehen ist. Wazuh

Fazit

Wenn nach einer OS-Migration Custom Fortigate-Decoders und -Rules in Wazuh „verschwinden“, liegt es sehr häufig nicht an der Logik der Regeln, sondern an Dateirechten und Ownership. Der klare Indikator ist wazuh-analysisd mit (13)-(Permission denied) in ossec.log. Mit chown wazuh:wazuh und chmod 660 (plus ggf. restorecon unter Rocky Linux) ist das Problem in der Regel sofort behoben.

Wer die Gelegenheit nutzt, die Customizations anschließend updatesicher über local_decoder.xml/local_rules.xml oder einen sauberen <ruleset>-Include-Mechanismus zu organisieren, reduziert langfristig Betriebskosten und vermeidet Regressionen bei Upgrades.

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