Windows EventID 4673 gezielt unterdrücken: Saubere Eventchannel-Filterung in Wazuh

Einleitung Windows-Security-Logs gehören zu den wichtigsten Datenquellen in Wazuh-basierten SIEM-Umgebungen. Gleichzeitig erzeugen sie häufig ein hohes Grundrauschen, insbesondere durch EventIDs mit geringer sicherheitsrelevanter Aussagekraft im jeweiligen Kontext. Ein typisches Beispiel ist EventID 4673 („A privileged service was called“), die in vielen Umgebungen massenhaft auftritt. Dieser Artikel zeigt, wie solche Events korrekt und nachhaltig bereits auf … Weiterlesen

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

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

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

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

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