Slack

Einleitung Bei Wazuh-Integrationen rund um Microsoft 365 (Office 365 Audit Logs) und Microsoft Graph entstehen Probleme oft nicht im „Abrufen“ der Daten, sondern in der Indexierung: Filebeat liefert Events an den Indexer, doch einzelne Felder passen nicht zum erwarteten Mapping. Das Resultat sind mapper_parsing_exception-Fehler, verworfene Dokumente und am Ende „fehlende Alerts“, obwohl der Manager eigentlich … Weiterlesen

Einleitung Wenn Wazuh Dashboard in Modulen wie Threat Hunting, Vulnerabilities und Inventory „No data“ anzeigt, obwohl die zugehörigen wazuh-states-*-Indizes im Indexer nachweislich Dokumente enthalten, liegt das Problem fast nie an der Datenerhebung. In der Praxis sind es typischerweise Kommunikations- und Integrationsprobleme zwischen Dashboard ↔ Indexer (OpenSearch) und Dashboard ↔ Wazuh API – besonders häufig im … Weiterlesen

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

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

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

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

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

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