Wazuh

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Vulnerability Detection ist in Wazuh nur so gut wie die zugrunde liegenden Datenflüsse: Software-Inventar vom Agent (Syscollector), Korrelationslogik im Manager (Vulnerability Detection / vulnerability-scanner), Persistenz im Wazuh-DB-Subsystem sowie die Ablage/Abfrage im Indexer. Wenn ein Server gepatcht wurde, CVEs aber „eine Woche später immer noch“ im Dashboard stehen, ist das fast … Weiterlesen

Einleitung Regelmäßige Schwachstellenscans von Infrastruktur- und Security-Komponenten sind Best Practice – und führen nicht selten zu Befunden in Drittbibliotheken. Besonders sensibel ist dies bei SIEM-Frontends wie dem Wazuh Dashboard, da hier potenziell sicherheitskritische Interaktionen zwischen Backend, Dateisystem und Benutzeroberfläche stattfinden. Dieser Beitrag beleuchtet den Umgang mit CVE-2025-68428 in Wazuh v4.14.1, erklärt die architektonischen Hintergründe und … Weiterlesen

Einleitung Ein häufiges Ziel im Security Monitoring ist nicht nur das Erkennen verdächtiger Aktivitäten, sondern auch das Erkennen von Abweichungen vom Sollzustand: Ein wichtiger Prozess läuft nicht (mehr), ein Agent ist „blind“, oder eine sicherheitsrelevante Komponente wurde deaktiviert. In Wazuh ist die Versuchung groß, dafür einfach Regeln auf Syscollector-Prozessdaten zu bauen. In der Praxis stößt … Weiterlesen

Einleitung Bei Firewalls und Security-Appliances ist Syslog oft die einzige Telemetriequelle – und gleichzeitig die unbequemste: viele Module, wechselnde Felder, keine Herstellerdokumentation. Für Wazuh-Administratoren entsteht damit ein doppeltes Problem: Einerseits will man saubere Decoder und sinnvolle Regeln für bekannte Message-Typen, andererseits möchte man sofort alarmiert werden, wenn neue Message-Typen oder neue Felder auftauchen, um den … Weiterlesen

Einleitung Die Einbindung von Netzwerkgeräten über Syslog gehört zu den klassischen Einsatzszenarien von Wazuh. Gerade Router wie MikroTik liefern sicherheitsrelevante Informationen zu Verbindungen, Firewalls, NAT und Systemereignissen. Häufig tritt jedoch ein typisches Problem auf: Die Logs werden korrekt per Syslog empfangen und sogar im Wazuh-Archiv gespeichert, tauchen aber weder als Alerts noch in den Dashboards … Weiterlesen

Einleitung Wazuh skaliert gut – aber bei mehreren tausend Agents, zusätzlicher Syslog- und Datenbank-Ingestion sowie 90 Tagen Aufbewahrung entscheidet die Architektur über Stabilität, Kosten und Betriebskomplexität. Besonders kritisch sind dabei die Trennung von Analyse (Manager-Cluster) und Storage/Search (Indexer-Cluster), eine saubere Hot/Warm-Strategie im Indexer sowie ein realistisches Kapazitätsmodell (EPS, Eventgröße, Index-Overhead, Replikate, Shards). Dieser Beitrag konsolidiert … Weiterlesen

Einleitung Archive-Logging (logall / logall_json) gehört zu den mächtigsten, aber zugleich riskantesten Funktionen im Wazuh-Manager. Es ermöglicht vollständige Transparenz über alle verarbeiteten Events – inklusive jener, die keine Alerts erzeugen. Genau diese Eigenschaft macht Archive-Logs für Debugging, Troubleshooting und Regelentwicklung unverzichtbar. In produktiven Umgebungen mit hohem Eventdurchsatz kann das globale Aktivieren von Archives jedoch schnell … Weiterlesen

Einleitung Wer Wazuh in Kubernetes (z. B. EKS) betreibt, will früher oder später mehr als nur alerts.json in den Indexer schreiben: Für forensische Analysen, Incident Response und Compliance ist das Archiv-Logging (archives.json) extrem wertvoll. In klassischen Deployments genügt oft ein simples Aktivieren des Filebeat-Archives-Filesets. In Kubernetes kann genau dieser Schritt jedoch dazu führen, dass der … Weiterlesen