RAM-Auslastung in ausgewählten Wazuh-Agent-Gruppen überwachen – ohne Remote Commands

Einleitung

Die Überwachung der Arbeitsspeicherauslastung gehört zu den klassischen Aufgaben eines Infrastruktur-Monitorings. In einer Wazuh-Umgebung entsteht dabei häufig der Wunsch, nicht jede Messung als Ereignis zu übertragen, sondern nur dann einen Alert zu erzeugen, wenn ein definierter Schwellwert überschritten wird.

Besonders relevant wird die Architekturentscheidung, wenn die Überwachung ausschließlich für eine bestimmte Agent-Gruppe gelten soll. Eine naheliegende Lösung ist, das Wazuh Command Module über die zentrale agent.conf der betreffenden Gruppe zu konfigurieren. Genau dieser Ansatz erfordert jedoch die Aktivierung von wazuh_command.remote_commands=1 auf den Endpunkten.

Diese Einstellung ist kein rein technischer Schalter. Sie erweitert die Vertrauensstellung des Wazuh Managers erheblich: Der Manager darf anschließend Befehle definieren, die auf den Agenten ausgeführt werden. Für eine reine RAM-Schwellwertüberwachung ist es daher in vielen Umgebungen sinnvoller, die Command-Konfiguration lokal auf den betroffenen Agenten zu hinterlegen und über ein separates Configuration-Management-System auszurollen.

Ausgangslage / Problemstellung

Die betrachtete Umgebung verwendet eine aktuelle Wazuh-Installation als All-in-one-Deployment. Die Agenten sind mehreren Gruppen zugeordnet. Nur die Systeme der Gruppe OBS sollen auf eine RAM-Auslastung von mehr als 90 Prozent überwacht werden.

Die Anforderungen lauten:

Die Prüfung soll ausschließlich auf Agenten der Gruppe OBS laufen.
Ein Wazuh-Alert soll nur entstehen, wenn die RAM-Auslastung 90 Prozent überschreitet.
Solange die Auslastung unterhalb des Schwellwerts liegt, sollen keine periodischen Telemetrieereignisse an den Manager übertragen werden.
Andere Agent-Gruppen dürfen nicht beeinflusst werden.
Die sicherheitskritische Aktivierung von wazuh_command.remote_commands=1 soll vermieden werden.

Wazuh unterstützt Command Monitoring sowohl über die lokale ossec.conf eines Endpunkts als auch über die zentral bereitgestellte agent.conf. Wird ein <wodle name="command">-Block jedoch über die zentrale Agent-Konfiguration verteilt, akzeptiert der Agent diesen standardmäßig nicht. Erst die lokale Einstellung

wazuh_command.remote_commands=1

erlaubt dem Manager, entsprechende Command-Definitionen an den Agenten zu übertragen. Wazuh deaktiviert diese Funktion standardmäßig aus Sicherheitsgründen.

Damit stehen zwei Ziele in direktem Konflikt:

Die Command-Konfiguration soll vollständig über Wazuh-Gruppen verteilt werden.
Der Wazuh Manager soll keine Berechtigung zur zentralen Definition ausführbarer Befehle erhalten.

Beides gleichzeitig ist mit dem Command Module nicht möglich. Die Sicherheitsgrenze muss deshalb an einer anderen Stelle gezogen werden.

Technische Analyse

Warum `agent.conf` Remote Commands benötigt

Die Datei agent.conf wird vom Wazuh Manager an die Mitglieder einer Agent-Gruppe verteilt. Bei gewöhnlichen Monitoring-Funktionen wie File Integrity Monitoring, Syscollector oder Labels ist das unkritisch, weil die Agenten nur bekannte Wazuh-Funktionen konfigurieren.

Ein Command-Wodle enthält dagegen eine konkrete Befehlszeile:

<wodle name="command">
  <command>/pfad/zu/einem/script</command>
</wodle>

Akzeptiert ein Agent solche Blöcke aus der zentralen Konfiguration, kann der Manager bestimmen, welcher lokale Prozess ausgeführt wird. Die offizielle Dokumentation weist deshalb ausdrücklich darauf hin, dass Remote Command Execution mit Vorsicht aktiviert werden muss.

Die Verschlüsselung und Authentifizierung der Manager-Agent-Kommunikation löst dieses Problem nicht. Sie schützt den Transportweg, verhindert aber nicht, dass ein kompromittierter Manager, ein missbrauchtes Administratorkonto oder eine manipulierte Gruppen-Konfiguration einen legitimen Kommunikationskanal zur Befehlsausführung verwendet.

Die mögliche Schadensreichweite hängt von der Gruppenzuordnung ab. Bei einer großen Agent-Gruppe kann eine einzige Änderung der agent.conf viele Endpunkte gleichzeitig betreffen. Damit wird der Wazuh Manager von einem Monitoring-System zu einem potenziellen zentralen Ausführungspunkt.

Eine unabhängige Sicherheitsbetrachtung weist außerdem darauf hin, dass neben wazuh_command.remote_commands auch logcollector.remote_commands und sca.remote_commands vergleichbare Vertrauensausweitungen erzeugen. Die Empfehlung lautet, diese Optionen nicht ohne zwingenden betrieblichen Grund zu aktivieren.

Warum die lokale `ossec.conf` die Sicherheitsgrenze verändert

Wird der Command-Wodle direkt in der lokalen ossec.conf des Agenten definiert, stammt die auszuführende Befehlszeile nicht aus der zentralen Wazuh-Konfiguration. wazuh_command.remote_commands=1 ist in diesem Fall nicht erforderlich.

Die Architektur sieht dann so aus:

Configuration Management
        |
        |-- lokales Prüfskript
        |-- lokaler Command-Wodle
        v
   OBS-Agent
        |
        |-- Ausgabe nur bei RAM > 90 %
        v
   Wazuh Manager
        |
        |-- Decoder
        |-- Regel
        v
   Wazuh Alert

Die zentrale Verwaltung verschwindet damit nicht vollständig. Sie wird lediglich aus der Wazuh-Gruppenkonfiguration in ein dafür vorgesehenes Configuration-Management-System verlagert, beispielsweise Ansible, Puppet, Salt, ein Softwareverteilungssystem oder ein gehärtetes Golden Image.

Wichtig ist, dass nicht nur der Wodle lokal definiert wird. Auch das ausgeführte Skript sollte nicht aus einem vom Wazuh Manager veränderbaren Shared-Verzeichnis geladen werden. Andernfalls könnte ein kompromittierter Manager zwar nicht die Befehlszeile ändern, aber möglicherweise den Inhalt des bereits lokal referenzierten Skripts austauschen.

Ereignisfilterung auf dem Endpunkt

Wazuh Command Monitoring führt einen Befehl in einem festgelegten Intervall aus und überträgt dessen Ausgabe zur Analyse an den Manager. Der Manager verarbeitet die Ausgabe anschließend über Decoder und Regeln.

Würde das Prüfskript bei jedem Lauf beispielsweise diese Zeile ausgeben,

ram_usage=43.21

entstünde auch unterhalb des Schwellwerts regelmäßig ein Ereignis. Selbst wenn keine Alert-Regel darauf reagiert, müsste Wazuh die Daten transportieren und analysieren. Bei vielen Agenten und kurzen Intervallen erzeugt das unnötige Last und zusätzliches Datenvolumen.

Die effizientere Lösung ist eine Filterung direkt im Skript:

RAM <= 90 %  -> keine Ausgabe
RAM > 90 %   -> strukturierte Ausgabe

Damit gelangt nur ein tatsächlicher Schwellwertverstoß in die Wazuh-Analysekette.

Lösung / Best Practices

Das folgende Beispiel gilt für Linux-Agenten. Die zugrunde liegende Architektur kann für Windows oder macOS mit einem betriebssystemspezifischen lokalen Skript übernommen werden.

1. Lokales RAM-Prüfskript erstellen

Auf jedem Agenten der Gruppe OBS wird das folgende Skript unter

/usr/local/libexec/wazuh/check-ram-threshold.sh

angelegt:

#!/usr/bin/env bash

set -euo pipefail

threshold="${1:-90}"

case "${threshold}" in
  ''|*[!0-9]*)
    exit 2
    ;;
esac

if (( threshold < 0 || threshold > 100 )); then
  exit 2
fi

awk -v threshold="${threshold}" '
  /^MemTotal:/ {
    total_kib = $2
  }

  /^MemAvailable:/ {
    available_kib = $2
  }

  END {
    if (total_kib <= 0 || available_kib < 0) {
      exit 2
    }

    used_pct = ((total_kib - available_kib) * 100) / total_kib

    if (used_pct > threshold) {
      printf "wazuh_ram_threshold: used_pct=%.2f threshold=%d total_kib=%d available_kib=%d\n",
             used_pct,
             threshold,
             total_kib,
             available_kib
    }
  }
' /proc/meminfo

Das Skript verwendet MemAvailable aus /proc/meminfo. Dieser Wert ist für die praktische Speicherbewertung aussagekräftiger als eine reine Auswertung von MemFree, da Linux freien Speicher unter anderem für Page Cache und Buffer verwendet.

Bei einer Auslastung unterhalb oder genau auf dem Schwellwert erzeugt das Skript keine Standardausgabe. Erst bei mehr als 90 Prozent wird eine strukturierte Zeile ausgegeben:

wazuh_ram_threshold: used_pct=93.27 threshold=90 total_kib=16329920 available_kib=1098952

2. Dateiberechtigungen absichern

Das Skript und seine übergeordneten Verzeichnisse dürfen nicht durch unprivilegierte Benutzer veränderbar sein:

sudo chown root:root /usr/local/libexec/wazuh/check-ram-threshold.sh
sudo chmod 0755 /usr/local/libexec/wazuh/check-ram-threshold.sh

Zusätzlich sollten die Berechtigungen der Verzeichnisse kontrolliert werden:

namei -l /usr/local/libexec/wazuh/check-ram-threshold.sh

Ein durch normale Benutzer veränderbares Skript würde einen lokalen Privilege-Escalation-Pfad schaffen, da es später durch den Wazuh-Agent-Prozess ausgeführt wird.

3. SHA-256-Prüfsumme berechnen

Das Command Module kann die Integrität des ausgeführten Programms vor der Ausführung überprüfen:

sha256sum /usr/local/libexec/wazuh/check-ram-threshold.sh

Beispiel:

d20f5f7d61d7a1c1178d7d18666e108fc44e78cdd747438be236cfc0672aa123  /usr/local/libexec/wazuh/check-ram-threshold.sh

Der konkrete Hash muss aus der eigenen Datei übernommen werden.

Wichtig ist, das Skript direkt als ersten Eintrag in <command> aufzurufen. Das Command Module überprüft bei mehreren Argumenten nur das erste Element der Befehlszeile. Bei einem Aufruf über

/bin/bash /usr/local/libexec/wazuh/check-ram-threshold.sh

würde deshalb lediglich /bin/bash verifiziert, nicht das eigentliche Skript.

4. Command-Wodle lokal konfigurieren

Der folgende Block wird ausschließlich auf den Agenten der Gruppe OBS innerhalb des vorhandenen <ossec_config>-Elements der lokalen Datei /var/ossec/etc/ossec.conf ergänzt:

<wodle name="command">
  <disabled>no</disabled>
  <tag>ram-threshold</tag>
  <command>/usr/local/libexec/wazuh/check-ram-threshold.sh 90</command>
  <interval>1m</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>10</timeout>
  <verify_sha256>d20f5f7d61d7a1c1178d7d18666e108fc44e78cdd747438be236cfc0672aa123</verify_sha256>
  <skip_verification>no</skip_verification>
</wodle>

Der Hash im Beispiel muss ersetzt werden.

Die Konfiguration bewirkt:

Prüfung einmal pro Minute
zusätzliche Prüfung beim Start des Agenten
Abbruch nach maximal zehn Sekunden
Integritätsprüfung des Skripts
Übertragung der Ausgabe nur dann, wenn das Skript tatsächlich eine Zeile erzeugt

Anschließend wird der Agent neu gestartet:

sudo systemctl restart wazuh-agent

Die Konfiguration wird nicht in der agent.conf der Gruppe OBS hinterlegt. Dadurch bleibt folgende Einstellung deaktiviert beziehungsweise vollständig abwesend:

wazuh_command.remote_commands=0

5. Decoder auf dem Wazuh Manager anlegen

Auf dem Wazuh Manager wird in /var/ossec/etc/decoders/local_decoder.xml ein Decoder für die strukturierte Ausgabe ergänzt:

<decoder name="wazuh-ram-threshold">
  <prematch>^wazuh_ram_threshold: </prematch>
  <regex type="pcre2" offset="after_prematch">used_pct=([0-9]+\.[0-9]{2})\s+threshold=([0-9]+)\s+total_kib=([0-9]+)\s+available_kib=([0-9]+)</regex>
  <order>ram_used_pct,ram_threshold,ram_total_kib,ram_available_kib</order>
</decoder>

Der Decoder extrahiert folgende Felder:

ram_used_pct
ram_threshold
ram_total_kib
ram_available_kib

6. Alert-Regel erstellen

In /var/ossec/etc/rules/local_rules.xml wird eine lokale Regel ergänzt:

<group name="ram_threshold,system_resource,availability,">
  <rule id="100200" level="10">
    <decoded_as>wazuh-ram-threshold</decoded_as>
    <description>RAM-Auslastung von $(ram_used_pct)% überschreitet den Schwellwert von $(ram_threshold)%.</description>
  </rule>
</group>

Die Regel-ID 100200 muss in der jeweiligen Umgebung frei sein. Falls sie bereits verwendet wird, ist eine andere freie ID aus dem lokalen Regelbereich zu wählen.

Eine zusätzliche numerische Prüfung innerhalb der Wazuh-Regel ist nicht erforderlich, weil das Agent-Skript ausschließlich bei Überschreitung des Schwellwerts eine Ausgabe erzeugt. Die Regel verarbeitet damit nur bereits qualifizierte Schwellwertverletzungen.

Nach der Änderung wird der Manager neu gestartet:

sudo systemctl restart wazuh-manager

7. Decoder und Regel testen

Das Skript lässt sich mit einem bewusst niedrigen Testschwellwert ausführen:

sudo /usr/local/libexec/wazuh/check-ram-threshold.sh 1

Auf einem normalen System sollte dadurch eine Testausgabe entstehen.

Diese Ausgabe kann anschließend mit wazuh-logtest geprüft werden:

sudo /var/ossec/bin/wazuh-logtest

Beispielereignis:

wazuh_ram_threshold: used_pct=43.27 threshold=1 total_kib=16329920 available_kib=9263212

Die erwartete Verarbeitung umfasst:

decoder: wazuh-ram-threshold
rule.id: 100200
rule.level: 10

Die produktive Wodle-Konfiguration bleibt weiterhin auf dem Schwellwert 90.

8. Konfiguration nur auf OBS-Agenten verteilen

Bei wenigen Agenten können Skript und Wodle manuell installiert werden. Für größere Umgebungen sollte ein Configuration-Management-System verwendet werden.

Die Zielauswahl muss dort der Wazuh-Gruppe OBS entsprechen, beispielsweise über:

ein Ansible-Inventar
Host-Gruppen im Configuration Management
Betriebssystemrollen
Deployment-Tags
ein spezielles Golden Image
dynamische Inventare aus CMDB oder Asset Management

Dabei sollten Skript, SHA-256-Hash und ossec.conf als eine versionierte Änderung behandelt werden. Nach einer Skriptänderung muss auch der konfigurierte Hash aktualisiert werden.

Lessons Learned / Best Practices

Remote Commands nicht nur nach Funktion, sondern nach Vertrauensmodell bewerten

wazuh_command.remote_commands=1 ist keine gewöhnliche Monitoring-Einstellung. Sie delegiert die Definition auszuführender Befehle an den Wazuh Manager. Diese Entscheidung sollte deshalb wie die Einführung eines administrativen Remote-Ausführungssystems behandelt werden.

Vor einer Aktivierung sind mindestens folgende Fragen zu beantworten:

Wer kann die Gruppen-agent.conf verändern?
Welche Konten besitzen administrativen Zugriff auf den Manager?
Wie werden Änderungen geprüft und freigegeben?
Wie groß ist die betroffene Agent-Gruppe?
Welche Auswirkungen hätte eine Manager-Kompromittierung?
Existieren Auditierung und Vier-Augen-Prinzip?
Gibt es bereits ein besser geeignetes Configuration-Management-System?

Ausführbare Inhalte nicht über denselben Vertrauenspfad verteilen

Ein lokal definierter Wodle schützt nur dann vor einer zentralen Befehlsänderung, wenn das aufgerufene Skript ebenfalls außerhalb der Kontrolle des Wazuh Managers liegt.

Ein lokal konfigurierter Wodle, der ein Skript aus /var/ossec/etc/shared/ ausführt, verlagert das Problem lediglich. Der Manager könnte weiterhin den Skriptinhalt verändern. Ausführbare Dateien sollten daher über ein separates, kontrolliertes Deployment-System bereitgestellt werden.

Nur notwendige Daten übertragen

Die Filterung am Endpunkt verhindert:

regelmäßige Events bei normaler RAM-Auslastung
unnötige Verarbeitung in wazuh-analysisd
zusätzliches Indexvolumen
vermeidbare Dashboard-Daten
unnötige Netzwerkübertragung
Alert-Rauschen durch zu allgemein formulierte Regeln

Dieses Prinzip lässt sich auch auf Dateisystembelegung, Prozesszahlen, Queue-Längen, Zertifikatslaufzeiten oder anwendungsspezifische Metriken übertragen.

Wiederholungsintervalle bewusst wählen

Mit dem gezeigten stateless Skript entsteht bei jedem Prüfintervall ein Ereignis, solange die RAM-Auslastung oberhalb von 90 Prozent liegt. Unterhalb des Schwellwerts entstehen keine Ereignisse.

Das ist für viele Monitoring-Szenarien sinnvoll, weil ein dauerhaft kritischer Zustand sichtbar bleibt. Soll ausschließlich der Übergang von „normal“ zu „kritisch“ gemeldet werden, wäre eine zustandsbehaftete Implementierung mit lokaler State-Datei erforderlich. Dabei sollte zusätzlich ein Recovery-Ereignis erzeugt werden, sobald die Auslastung wieder unter den Schwellwert fällt.

Schwellwerte nicht isoliert betrachten

Eine RAM-Auslastung von mehr als 90 Prozent bedeutet unter Linux nicht automatisch einen unmittelbaren Ausfall. Für die Bewertung sind unter anderem folgende Faktoren relevant:

verfügbare Speichermenge
Swap-Nutzung
Paging-Aktivität
OOM-Killer-Ereignisse
Container-Limits
anhaltende oder kurzfristige Lastspitzen
Speicherwachstum einzelner Prozesse

Für produktive Umgebungen kann es sinnvoll sein, die Schwellwertregel später um Swap-Auslastung, OOM-Ereignisse oder eine Mindestdauer zu ergänzen.

Das Configuration-Management-System wird Teil der Sicherheitsarchitektur

Die Verlagerung aus agent.conf in Ansible, Puppet oder ein anderes Deployment-System beseitigt die Notwendigkeit für Wazuh Remote Commands. Sie beseitigt jedoch nicht grundsätzlich das Risiko zentraler Administration.

Auch das alternative System benötigt:

rollenbasierte Zugriffsrechte
geschützte Zugangsdaten
Change Control
nachvollziehbare Deployments
Code Review
manipulationsgeschützte Repositories
begrenzte Zielgruppen
regelmäßige Berechtigungsprüfungen

Der Vorteil besteht darin, dass diese Systeme üblicherweise genau für kontrollierte Software- und Konfigurationsverteilung vorgesehen sind.

Fazit

Eine gruppenspezifische RAM-Schwellwertüberwachung lässt sich mit Wazuh umsetzen, ohne wazuh_command.remote_commands=1 zu aktivieren. Dafür muss die ausführbare Command-Konfiguration lokal auf den betroffenen Agenten hinterlegt werden.

Die empfohlene Architektur besteht aus drei klar getrennten Teilen:

Ein lokal installiertes und integritätsgeprüftes Skript misst die RAM-Auslastung und erzeugt nur oberhalb von 90 Prozent eine Ausgabe.
Ein lokaler Command-Wodle führt das Skript ausschließlich auf den vorgesehenen OBS-Agenten aus.
Decoder und Regel auf dem Wazuh Manager wandeln die Ausgabe in einen strukturierten Alert um.

Die zentrale Verwaltung erfolgt über ein bestehendes Configuration-Management-System und nicht über die Wazuh-agent.conf. Dadurch bleiben die Remote-Command-Funktionen deaktiviert, andere Agent-Gruppen bleiben unverändert und unterhalb des Schwellwerts entstehen keine periodischen Wazuh-Ereignisse.