Hohe Event-Drop-Rate in Wazuh: Ursachen verstehen und nachhaltig reduzieren

Einleitung Eine hohe Event-Drop-Rate ist eines der kritischsten Symptome in einer Wazuh-Umgebung. Sie bedeutet nicht nur verlorene Logs, sondern potenziell verpasste Sicherheitsereignisse, unvollständige Korrelationen und eingeschränkte Forensik. Gerade in Umgebungen mit vielen Agents, Firewalls oder stark loggenden Anwendungen stößt der Wazuh-Manager schnell an seine Grenzen. Dieser Artikel erklärt, wie Event Drops entstehen, wie man sie … Weiterlesen

Wazuh Indexer im Multi-Node-Setup über mehrere Hosts: Quorum-Fehler durch Docker-Netzwerke korrekt beheben

Einleitung Ein hochverfügbares Wazuh-Deployment steht und fällt mit einem stabilen Indexer-Cluster. Gerade bei Multi-Node-Architekturen ist der Wazuh Indexer (OpenSearch) der kritische Pfad für Suche, Dashboards und Alarmhistorie. Ein häufiger Stolperstein entsteht, wenn Indexer-Nodes “pro Server einzeln” per Docker Compose gestartet werden: Die Container laufen zwar, aber der Cluster bildet kein Quorum – und bleibt dauerhaft … Weiterlesen

Archive Indexing in Wazuh 4.14.1 auf Kubernetes (EKS): Warum Environment-Variablen nicht greifen und wie man Archive sauber und supportkonform indexiert

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Die Indexierung von Wazuh Archives (archives.json) ist ein häufiges Thema in SIEM-Umgebungen, wenn nicht nur Alerts, sondern alle Events (inklusive nicht alertender Logs) durchsuchbar sein sollen. In klassischen Bare-Metal- oder VM-Installationen ist das Aktivieren von Archive Indexing vergleichsweise trivial. In Kubernetes-Deployments, insbesondere auf AWS EKS, greifen diese Mechanismen jedoch nicht … Weiterlesen

Wazuh Logs & Indizes nach 60 Tagen automatisch nach Amazon S3 auslagern und lokal löschen: Snapshots (OpenSearch) vs. Datei-Archivierung und ISM-Retention richtig kombinieren

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Wenn Wazuh produktiv läuft, wachsen zwei Datenwelten schnell: (1) indexierte Security-Daten im Wazuh Indexer (Alerts/Archives-Indizes) und (2) Datei-Logs auf dem Manager unter /var/ossec/logs/. Wer beides nach 60 Tagen kostengünstig nach Amazon S3 auslagern und anschließend lokal löschen möchte, muss sauber trennen: Backup-/Restore-fähige Snapshots sind etwas anderes als „nur Dateien wegspeichern“. … Weiterlesen

Wazuh-Indexer: Warum 130 GB/Tag nicht einfach 11,7 TB für 90 Tage sind (und wie du sauber dimensionierst)

Ausgangslage:Du planst eine Wazuh-Umgebung mit ~130 GB Log-Ingestion pro Tag (hauptsächlich High-Volume-Quellen wie Server, Cloud-Logs, Network Devices) und 90 Tage Retention. Dazu ein Indexer-Cluster (≥3 Nodes) mit 1 Replica. 1) Die Grundrechnung (Raw-Volumen) Das ist aber nicht das, was am Ende auf dem Indexer liegt. 2) Warum der Index größer wird als die Rohdaten OpenSearch/Wazuh … Weiterlesen

LANCOM Switches und Access Points sauber in Wazuh dekodieren: Warum Syslog-Header „verschwinden“ und wie program_name-Decoder Kollisionen vermeiden

Einleitung Netzwerkgeräte wie LANCOM Switches und Access Points liefern häufig „syslog-ähnliche“ Zeilen, die auf den ersten Blick trivial zu parsen sind: Zeitstempel, Host/IP, Programmkennung, Nachricht. In Wazuh ist genau dieser Header jedoch gleichzeitig Fluch und Segen: Der integrierte Predecoder erkennt solche Header automatisch und extrahiert Felder wie timestamp, hostname und program_name bereits vor der eigentlichen … Weiterlesen

Wazuh IT-Hygiene: Entfernte Pakete im Dashboard bleiben sichtbar – Ursachen & Lösungen

Einleitung Viele Wazuh-Admins nutzen die IT-Hygiene-Funktion, um installierte Software-Pakete über alle Endpunkte hinweg zentral zu überwachen. Ein typisches Problem dabei: Auch nachdem Pakete auf Endpunkten deinstalliert wurden, erscheinen sie weiterhin im IT-Hygiene-Dashboard. Dieser Artikel erklärt die Ursachen, die Funktionsweise des Wazuh-Syscollector-Moduls und gibt praxisnahe Tipps zur Fehleranalyse und -behebung. Ausgangslage / Problemstellung Ein Nutzerbericht aus … Weiterlesen

Wazuh/ModSecurity JSON: Warum transaction.messages nicht weiter dekodiert wird – und wie du es sauber löst

Problem In deinem Event wird transaction.messages in Phase 2 zwar als Feld erkannt, aber der Inhalt wird nicht weiter „aufgefächert“ (also keine transaction.messages[0].details.ruleId usw.). Der Grund ist simpel: Für Wazuh ist transaction.messages ein einzelner Feldwert (String) – selbst wenn er „wie JSON“ aussieht. In deinem Decode-Output sieht man das auch: Das ist kein JSON-Array-Typ, sondern … Weiterlesen

Rate Limiting für Custom Email Alerts in Wazuh: Warum email_maxperhour nicht greift und was stattdessen vorgesehen ist

Einleitung E-Mail-Benachrichtigungen gehören zu den ältesten und zugleich kritischsten Alerting-Mechanismen in SIEM-Umgebungen. Wazuh bietet hierfür sowohl eine integrierte E-Mail-Funktion als auch die Möglichkeit, Custom Email Alerts über Integrationen umzusetzen. In der Praxis entsteht dabei häufig Verwirrung: Während das Standard-Alerting eine native Drosselung über <email_maxperhour> unterstützt, fehlt eine vergleichbare Option für Custom Integrations. Dieser Artikel ordnet … Weiterlesen

Wazuh Custom Rule greift nicht bei JSON-Logs: Sonderzeichen in korrekt escapen

Ausgangslage Ein Nutzer wollte ModSecurity-Events im JSON-Format mit einer eigenen Wazuh-Regel erkennen.Die Regel sah korrekt aus, erzeugte aber keine Alerts, obwohl die Events sauber dekodiert wurden. Regel (ursprünglich): Beispiel-Event (Auszug): Trotz passendem Feldinhalt wurde kein Alert generiert. Ursache Der entscheidende Punkt:Das <field>-Element in Wazuh-Regeln nutzt OS_Regex (osregex) – nicht einen reinen String-Vergleich. In osregex haben … Weiterlesen