Quelltext der Seite YARA-Scans per Wazuh Active Response aus FIM-Events auslösen

== Einleitung ==

Die Kombination aus Wazuh File Integrity Monitoring und YARA ist ein wirksames Muster, um neu erstellte oder veränderte Dateien direkt auf Endpoints zu prüfen. Besonders Download-Verzeichnisse von Browsern sind sicherheitsrelevant, weil dort ausführbare Dateien, Archive, Office-Dokumente oder PDFs landen können, bevor sie durch weitere Prozesse geöffnet oder verteilt werden.

== Ausgangslage / Problemstellung ==

In der Umgebung soll Wazuh FIM ein Browser-Download-Verzeichnis unter Linux in Echtzeit überwachen. Sobald dort eine neue Datei erscheint, soll eine Active Response ein lokales <code>yara.sh</code> ausführen und die Datei mit YARA-Regeln scannen.

Die FIM-Alerts werden bereits erzeugt, aber in

<syntaxhighlight lang="text">
/var/ossec/logs/active-responses.log
</syntaxhighlight>

erscheinen keine <code>wazuh-yara</code>-Einträge. Das spricht dafür, dass nicht YARA selbst das Hauptproblem ist, sondern dass die Active Response nicht ausgelöst wird oder das Skript vor der Logausgabe beendet wird.

== Technische Analyse ==

Der Dateipfad aus einem FIM-Alert wird bei der YARA-Active-Response über folgenden JSON-Pfad übergeben:

<syntaxhighlight lang="text">
.parameters.alert.syscheck.path
</syntaxhighlight>

Das ist auch der Pfad, den die aktuelle Wazuh-Dokumentation für das Linux-Skript verwendet. Dort werden außerdem <code>extra_args[1]</code> für den YARA-Pfad und <code>extra_args[3]</code> für die YARA-Regeldatei genutzt.

Entscheidend ist aber: Das Skript wird nur ausgeführt, wenn die Active Response auf eine passende Rule-ID reagiert. In der offiziellen Beispielkonfiguration wird das Kommando <code>yara_linux</code> über <code><rules_id></code> an FIM-Regeln für neue oder geänderte Dateien gebunden.

Wenn FIM-Alerts sichtbar sind, aber <code>active-responses.log</code> leer bleibt, sind die häufigsten Ursachen:

Die Rule-ID des tatsächlichen FIM-Alerts passt nicht zu <code><rules_id></code> in der Active-Response-Konfiguration.

Das Skript liegt nicht unter:

<syntaxhighlight lang="text">
/var/ossec/active-response/bin/yara.sh
</syntaxhighlight>

oder hat falsche Rechte.

<code>jq</code> fehlt auf dem Agent.

Die Active Response ist auf dem Manager konfiguriert, aber nicht korrekt mit <code><location>local</location></code> auf dem meldenden Agent ausführbar.

Der Erweiterungsfilter im Skript beendet die Ausführung frühzeitig, bevor ein Logeintrag geschrieben wird.

== Lösung / Best Practices ==

Zunächst sollte das Skript mit Start-Logging versehen werden. So lässt sich unterscheiden, ob die Active Response gar nicht startet oder ob sie später im Skript aussteigt:

<syntaxhighlight lang="text">
#!/bin/bash

read INPUT_JSON

LOG_FILE="/var/ossec/logs/active-responses.log"
echo "wazuh-yara: DEBUG - Active response started" >> "$LOG_FILE"
echo "wazuh-yara: DEBUG - Input JSON: $INPUT_JSON" >> "$LOG_FILE"

YARA_PATH=$(echo "$INPUT_JSON" | jq -r '.parameters.extra_args[1]')
YARA_RULES=$(echo "$INPUT_JSON" | jq -r '.parameters.extra_args[3]')
FILE_PATH=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.syscheck.path')

echo "wazuh-yara: DEBUG - File path: $FILE_PATH" >> "$LOG_FILE"
</syntaxhighlight>

Danach sollten Rechte und Besitzer geprüft werden:

<syntaxhighlight lang="text">
sudo chmod 750 /var/ossec/active-response/bin/yara.sh
sudo chown root:wazuh /var/ossec/active-response/bin/yara.sh
sudo apt install -y jq
</syntaxhighlight>

Die FIM-Konfiguration auf dem Agent sollte das Download-Verzeichnis explizit überwachen:

<syntaxhighlight lang="text">
<syscheck>
  <directories realtime="yes">/home/<user>/Downloads</directories>
</syscheck>
</syntaxhighlight>

Anschließend den Agent neu starten:

<syntaxhighlight lang="text">
sudo systemctl restart wazuh-agent
</syntaxhighlight>

Auf dem Wazuh Manager muss das Kommando und die Active Response definiert sein:

<syntaxhighlight lang="text">
<command>
  <name>yara_linux</name>
  <executable>yara.sh</executable>
  <extra_args>-yara_path /usr/local/bin -yara_rules /tmp/yara/rules/yara_rules.yar</extra_args>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <disabled>no</disabled>
  <command>yara_linux</command>
  <location>local</location>
  <rules_id>100200,100201</rules_id>
</active-response>
</syntaxhighlight>

Wichtig: Die Rule-IDs müssen zur eigenen FIM-Regel passen. In einer produktiven Umgebung sollte daher im Alert geprüft werden, welche <code>rule.id</code> tatsächlich für neue oder geänderte Dateien im Download-Verzeichnis erzeugt wird. Genau diese IDs müssen in <code><rules_id></code> stehen.

Danach den Manager neu starten:

<syntaxhighlight lang="text">
sudo systemctl restart wazuh-manager
</syntaxhighlight>

Das Skript selbst sollte temporäre Browser-Dateien wie <code>.crdownload</code>, <code>.part</code> und <code>.tmp</code> überspringen. Gleichzeitig sollte jede wichtige Exit-Stelle geloggt werden, zumindest während der Fehleranalyse. Sonst wirkt es so, als würde die Active Response nicht starten, obwohl das Skript lediglich wegen Dateiendung, fehlender Datei oder leerem Pfad beendet wird.

== Lessons Learned / Best Practices ==

<code>parameters.alert.syscheck.path</code> ist der richtige Schlüssel für den FIM-Dateipfad. Wenn keine YARA-Logs erscheinen, liegt der Fehler meist nicht an diesem JSON-Pfad, sondern an Trigger-Logik, Rule-IDs, Berechtigungen oder fehlenden Abhängigkeiten.

Für den Betrieb ist ein mehrstufiger Test sinnvoll:

Erstens prüfen, ob FIM für das Download-Verzeichnis Alerts erzeugt.

Zweitens die tatsächliche <code>rule.id</code> des Alerts auslesen.

Drittens diese Rule-ID in der Active Response referenzieren.

Viertens das Skript mit Debug-Logging starten lassen.

Fünftens erst danach Filter für Dateiendungen und temporäre Downloads schärfen.

Für produktive Umgebungen sollte außerdem vermieden werden, jede einzelne Datei ungefiltert mit großen YARA-Regelsätzen rekursiv zu scannen. Download-Verzeichnisse können hohe Eventraten erzeugen. Extension-Filter, Größenlimits, stabile Datei-Checks und gezielte YARA-Regeln reduzieren Last und False Positives.

== Fazit ==

Wazuh FIM und YARA lassen sich zuverlässig kombinieren, wenn FIM-Alert, Active-Response-Regel und Skriptparameter sauber zusammenpassen. Der FIM-Dateipfad liegt unter <code>parameters.alert.syscheck.path</code>. Bleiben Einträge in <code>active-responses.log</code> aus, sollte zuerst geprüft werden, ob die passende FIM-Rule-ID in <code><rules_id></code> eingetragen ist und ob das Skript überhaupt gestartet wird. Debug-Logging im Skript ist dabei der schnellste Weg zur Ursache.

== Quellen ==

Wazuh-Dokumentation: File integrity monitoring and YARA
[https://documentation.wazuh.com/current/user-manual/capabilities/malware-detection/fim-yara.html?utm_source=chatgpt.com https://documentation.wazuh.com/current/user-manual/capabilities/malware-detection/fim-yara.html]

Mehr zu Wazuh …
[https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program 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.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program]

[https://wazuh.slack.com/archives/C07CCCCGHHP/p1771527492331489 https://wazuh.slack.com/archives/C07CCCCGHHP/p1771527492331489]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/yara-scans-per-wazuh-active-response-aus-fim-events-ausloesen/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 7. Juni 2026).

== Unterstützung von m.a.x. it ==
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]