Wazuh-Blog

Ein Upgrade eines Wazuh-Clusters ist nicht nur eine Frage der korrekten Aktualisierung von Manager-, Worker- und Indexer-Komponenten. Gerade in größeren Umgebungen entsteht eine zusätzliche Herausforderung, sobald nach einem Wartungsfenster mehrere Tausend Wazuh-Agenten nahezu gleichzeitig ihre Verbindung zum Cluster wiederherstellen. Die Folge können kurzfristige Lastspitzen, überfüllte Decoder-Queues und im ungünstigsten Fall verlorene Security-Events sein. Besonders kritisch … Weiterlesen

Einleitung Die Integration von AWS CloudTrail in Wazuh ermöglicht es, Aktivitäten innerhalb einer AWS-Umgebung zentral zu überwachen, sicherheitsrelevante API-Aufrufe zu erkennen und Cloud-Ereignisse für spätere Untersuchungen verfügbar zu machen. Während die kontinuierliche Verarbeitung neuer CloudTrail-Ereignisse in vielen Umgebungen problemlos funktioniert, stellt der nachträgliche Import großer historischer Datenmengen besondere Anforderungen an die Wazuh-Architektur. Bereits ein einzelner … Weiterlesen

Einleitung Kritische Schwachstellen in PHP stellen Security Operations Center (SOC) vor besondere Herausforderungen. Insbesondere dann, wenn betroffene Webanwendungen außerhalb der eigenen Infrastruktur betrieben werden und keine direkte Überwachung der Webserver möglich ist. Mit den unter der Bezeichnung PHP2Shell diskutierten Schwachstellen CVE-2026-109618 und CVE-2026-109619 rückt diese Problematik erneut in den Fokus. Beide Schwachstellen werden mit einer … Weiterlesen

Einleitung Nach einem Upgrade des Wazuh Managers auf Version 4.14.7 kann beim Aufruf des Kommandozeilenwerkzeugs agent_upgrade eine Python-Warnung erscheinen: Die Meldung wirkt auf den ersten Blick wie ein Fehler im Agent-Upgrade-Prozess. Tatsächlich handelt es sich jedoch um eine Deprecation-Warnung aus der mit Wazuh ausgelieferten Python-Laufzeitumgebung. Das eigentliche CLI-Werkzeug und der Upgrade-Mechanismus können weiterhin ordnungsgemäß funktionieren. … Weiterlesen

Einleitung In produktiven Wazuh-Umgebungen entstehen regelmäßig legitime Ereignisse, die technisch auf Erkennungsregeln passen, aber keinen Sicherheitsvorfall darstellen. Typische Beispiele sind Schwachstellenscanner, Monitoring-Systeme, interne Administrationsserver oder autorisierte Penetrationstests. Solche Quellen sollen häufig von bestimmten Alarmen ausgenommen werden. Eine Ausnahme in einer einzelnen Wazuh-Regel bedeutet jedoch nicht automatisch, dass das Ereignis vollständig ignoriert wird. Passt dasselbe Ereignis … Weiterlesen

Einleitung Die File Integrity Monitoring (FIM)-Funktion von Wazuh gehört zu den wichtigsten Sicherheitsmechanismen für die Erkennung unerwarteter Dateiänderungen. Gerade auf Endgeräten lassen sich damit Manipulationen an Konfigurationsdateien, Autostart-Mechanismen oder sicherheitsrelevanten Verzeichnissen frühzeitig erkennen. Wer Wazuh erstmals auf macOS-Systemen einsetzt, stößt jedoch häufig auf Warnmeldungen, sobald Echtzeitüberwachung (realtime) aktiviert wird. Diese Meldungen wirken zunächst wie ein … Weiterlesen

Einleitung Strukturierte JSON-Logs sind eine wichtige Grundlage für zuverlässige Erkennungsregeln, Korrelationen und forensische Analysen in Wazuh. Felder wie level, userId, requestId, module, method oder url lassen sich wesentlich präziser auswerten als unstrukturierte Textnachrichten. Beim direkten Einlesen der Dateien des Docker-Logging-Treibers json-file entsteht jedoch häufig ein unerwartetes Problem: Docker speichert die eigentliche Anwendungsmeldung innerhalb eines äußeren … Weiterlesen

Einleitung Die Linux-Audit-Infrastruktur wird häufig von mehreren Sicherheitskomponenten gleichzeitig genutzt. Neben Wazuh können beispielsweise zusätzliche SIEM-Forwarder, Compliance-Werkzeuge oder forensische Audit-Plugins dieselben Ereignisse verarbeiten. In einer solchen Multi-Plugin-Architektur darf der Ausfall eines einzelnen Verbrauchers nicht die gesamte Audit-Pipeline beeinträchtigen. Genau dieses Fehlerbild kann jedoch entstehen, wenn Wazuh Whodata im Audit-Modus verwendet wird: Bleibt der Wazuh-seitige UNIX-Socket … Weiterlesen

Einleitung Bei der Bewertung von Schwachstellen in Linux-Umgebungen reicht ein Vergleich der installierten Softwareversion mit der Upstream-Versionsangabe häufig nicht aus. Distributionen pflegen eigene Pakete, übernehmen Sicherheitspatches per Backport und veröffentlichen distributionsspezifische Statusinformationen. Dadurch kann eine vermeintlich eindeutige Aussage wie „ab Version 1.8.19 behoben“ im konkreten Betriebssystemkontext zu einem anderen Ergebnis führen. Ein typisches Beispiel ist … Weiterlesen

Einleitung Die Ansicht Alerting → Alerts → Alerts by triggers im Wazuh Dashboard wird häufig mit den eigentlichen Wazuh-Sicherheitsalerts verwechselt. Technisch handelt es sich jedoch um zwei unterschiedliche Datenarten mit jeweils eigener Speicherung und Aufbewahrungslogik. Die Indizes wazuh-alerts-* enthalten Ereignisse, die der Wazuh Manager anhand seiner Decoder und Regeln erzeugt. Die Einträge unter „Alerts by … Weiterlesen