Wazuh Agent Log-Noise reduzieren: Grenzen von und skalierbare Alternativen für Kubernetes

von

Einleitung

In Kubernetes-Umgebungen können Wazuh-Agenten sehr schnell große Mengen an Container- und Applikationslogs erfassen. Werden diese ungefiltert an den Wazuh Manager weitergeleitet, steigt die Last auf wazuh-analysisd, da Parsing, Decoding und Rule-Matching zentral auf Manager-Seite stattfinden. Besonders bei vielen Microservices führt Log-Noise daher nicht nur zu unnötigen Events, sondern auch zu messbaren Performance-Problemen.

Ausgangslage / Problemstellung

Ein Agent sammelt alle Dateien unterhalb eines Log-Verzeichnisses:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/*</location>
</localfile>

Bestimmte Dateien wie logfile2.log und logfile3.log sollen ausgeschlossen werden. Mehrere <exclude>-Einträge innerhalb desselben <localfile>-Blocks funktionieren dabei nicht wie erwartet; auch eine kommaseparierte Liste ist keine gültige Syntax.

Das eigentliche Betriebsproblem ist größer: In Kubernetes entstehen laufend neue Logdateien durch Pods und Microservices. Ohne Namenskonventionen ist eine manuelle Pflege einzelner Ausschlüsse weder stabil noch skalierbar.

Technische Analyse

Die Option <exclude> in einem Wazuh-localfile-Block ist für eine einzelne Datei oder ein Wildcard-Muster vorgesehen. Sie eignet sich gut für einfache Muster wie:

<exclude>/var/logs/e*</exclude>

oder für zusammenhängende Dateinamenbereiche:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/*</location>
  <exclude>/var/logs/logfile[2-3].log</exclude>
</localfile>

Das löst aber nur Fälle mit vorhersehbaren Dateinamen. Für dynamische Kubernetes-Logs ohne einheitliches Schema ist <exclude> kein vollwertiger dynamischer Filtermechanismus auf Dateiebene.

Wichtig ist außerdem die Architektur: Der Agent sammelt und leitet Logs weiter. Die rechenintensive Verarbeitung durch Decoder und Regeln erfolgt auf dem Manager, insbesondere durch wazuh-analysisd. Eine Regel mit Level 0 reduziert zwar Alerts, verhindert aber nicht, dass das Event den Manager erreicht und dort verarbeitet wird. Bei CPU-Problemen auf dem Manager muss der Logstrom daher möglichst vor dem Versand reduziert werden.

Lösung / Best Practices

Der bevorzugte Ansatz ist eine Include-Strategie statt einer Exclude-Strategie. Anstatt alles unter /var/logs/* zu erfassen und einzelne Dateien auszuschließen, sollten nur relevante Logquellen gezielt aufgenommen werden:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/auth.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/app-critical-*.log</location>
</localfile>

Wenn Dateinamen teilweise gruppierbar sind, können Wildcards genutzt werden:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/payment-*.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/security-*.log</location>
</localfile>

Wenn die Auswahl nicht zuverlässig über Dateinamen möglich ist, kann <restrict> helfen. Damit verarbeitet der Agent nur Logzeilen, die einem Muster entsprechen:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/*</location>
  <restrict type="PCRE2">ERROR|WARN|CRITICAL|SECURITY</restrict>
</localfile>

Mehrere <restrict>-Einträge im selben Block wirken restriktiv: Eine Logzeile muss alle Bedingungen erfüllen. Für Ausschlüsse auf Zeilenebene kann alternativ <ignore> verwendet werden:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/logs/*</location>
  <ignore type="PCRE2">healthcheck|readinessProbe|livenessProbe</ignore>
</localfile>

Wenn Dateiebene zwingend erforderlich ist und keine stabilen Muster existieren, ist eine vorgelagerte Filter-Schicht robuster. Ein Sidecar, DaemonSet oder Log-Router kann nur relevante Logs nach /var/wazuh-logs/ schreiben oder dort Symlinks auf freigegebene Dateien pflegen. Wazuh liest dann ausschließlich diese kuratierte Quelle:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/wazuh-logs/*</location>
</localfile>

Ein Symlink-basierter Ansatz kann besonders nützlich sein, wenn die Entscheidung auf Dateiebene getroffen wird:

mkdir -p /var/wazuh-logs
ln -s /var/logs/app-critical.log /var/wazuh-logs/app-critical.log
ln -s /var/logs/security-events.log /var/wazuh-logs/security-events.log

Damit bleibt die Wazuh-Agent-Konfiguration stabil, während die Auswahl der tatsächlich überwachten Dateien außerhalb von Wazuh automatisiert werden kann.

Lessons Learned / Best Practices

<exclude> ist kein dynamisches Policy-System für komplexe Kubernetes-Loglandschaften. Es sollte für einfache Dateinamen oder Wildcards genutzt werden, nicht für ständig wechselnde Microservice-Logs ohne Namensstandard.

Für skalierbare Umgebungen sind drei Prinzipien entscheidend: erstens klare Namenskonventionen für relevante Logs, zweitens möglichst frühe Reduktion des Logstroms, drittens Trennung zwischen Log-Routing und SIEM-Analyse. Wazuh sollte sicherheitsrelevante Daten erhalten, nicht jeden technischen Noise aus jedem Pod.

Regeln mit Level 0 sind sinnvoll zur Alert-Unterdrückung, aber keine Performance-Lösung für überlastete Manager. Wenn wazuh-analysisd bereits durch Logvolumen ausgelastet ist, muss die Menge der eingehenden Events reduziert werden.

Fazit

Für einzelne Dateien kann <exclude> mit Wildcards oder Bereichen ausreichen. Für dynamische Kubernetes-Umgebungen ist jedoch eine Include-Strategie oder eine vorgelagerte Filter-Schicht deutlich stabiler. Wer Log-Noise bereits am Agenten oder davor reduziert, entlastet den Wazuh Manager, schützt wazuh-analysisd vor unnötiger Verarbeitung und verbessert die Skalierbarkeit der gesamten SIEM-Pipeline.

Quellen

Wazuh Dokumentation: localfile / exclude
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#exclude

Wazuh Dokumentation: localfile / restrict
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#restrict

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/C07BK5RJM3R/p1772133942646419