Wazuh Indexer von 3 Nodes auf 1 Node reduzieren bei ~42 Mio. Discover-Hits/Tag: So bewertest du Risiko, Performance und Datenverlust sauber

von

Einleitung Viele Wazuh-Installationen starten mit einem Indexer-Cluster, weil Verfügbarkeit, Skalierung und Performance damit grundsätzlich einfacher abzusichern sind. Gleichzeitig ist ein 3-Node-Indexer-Cluster nicht „gratis“: mehr Ressourcen, mehr Betriebsaufwand, mehr Komplexität bei Shards, Replikation und Upgrades. Wenn in Discover im Schnitt ~42.360.000 Hits pro Tag auftauchen, ist die Frage berechtigt: Reicht ein einzelner, ausreichend dimensionierter Indexer? Die … Weiterlesen

Windows DNS-Client/Operational mit Wazuh erfassen: Warum Events in archives.json landen, aber nicht als Alerts im Dashboard erscheinen

von

Einleitung DNS-Telemetrie aus Windows-Endpoints ist für Threat Hunting und Incident Response extrem wertvoll: Sie liefert Domänenabfragen, Antwortcodes und Auflösungsfehler direkt vom Client und ergänzt klassische Netzwerk- oder Proxy-Logs. In Wazuh wird diese Datenquelle häufig über den Windows-Eventchannel Microsoft-Windows-DNS-Client/Operational angebunden. Ein typisches Praxisproblem: Die Events sind zwar auf dem Wazuh-Manager in den Archiven sichtbar, erscheinen aber … Weiterlesen

Wazuh „Too big message size“ bei VMware vSphere Syslog über Rsyslog: Ursachen, Grenzen und robuste Workarounds

von

Einleitung VMware® vSphere erzeugt teils sehr verbose Syslog-Ereignisse – insbesondere bei bestimmten Audit-, API-, Hostd-/Vpxa- oder Security-relevanten Events. In SIEM-Pipelines, die vSphere → Rsyslog → Wazuh führen, tritt dann häufig ein scheinbar „mysteriöses“ Verhalten auf: Wazuh meldet „Too big message size“, kürzt Events, Decoder greifen nicht mehr sauber – und im Dashboard fehlt die erwartete … Weiterlesen

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

von

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

von

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

von

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

von

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)

von

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

von

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

von

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