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 yara.sh ausführen und die Datei mit YARA-Regeln scannen.

Die FIM-Alerts werden bereits erzeugt, aber in

/var/ossec/logs/active-responses.log

erscheinen keine wazuh-yara-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:

.parameters.alert.syscheck.path

Das ist auch der Pfad, den die aktuelle Wazuh-Dokumentation für das Linux-Skript verwendet. Dort werden außerdem extra_args[1] für den YARA-Pfad und extra_args[3] 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 yara_linux über <rules_id> an FIM-Regeln für neue oder geänderte Dateien gebunden.

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

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

Das Skript liegt nicht unter:

/var/ossec/active-response/bin/yara.sh

oder hat falsche Rechte.

jq fehlt auf dem Agent.

Die Active Response ist auf dem Manager konfiguriert, aber nicht korrekt mit <location>local</location> 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:

#!/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"

Danach sollten Rechte und Besitzer geprüft werden:

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

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

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

Anschließend den Agent neu starten:

sudo systemctl restart wazuh-agent

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

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

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

Danach den Manager neu starten:

sudo systemctl restart wazuh-manager

Das Skript selbst sollte temporäre Browser-Dateien wie .crdownload, .part und .tmp ü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

parameters.alert.syscheck.path 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 rule.id 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 parameters.alert.syscheck.path. Bleiben Einträge in active-responses.log aus, sollte zuerst geprüft werden, ob die passende FIM-Rule-ID in <rules_id> eingetragen ist und ob das Skript überhaupt gestartet wird. Debug-Logging im Skript ist dabei der schnellste Weg zur Ursache.