Wir verfolgen den internen Wazuh Slack-Channel aufmerksam und bereiten besonders interessante Diskussionen mithilfe von KI als Blogbeiträge auf. Da Slack-Unterhaltungen nach 90 Tagen automatisch gelöscht werden, sichern wir so wertvolles Wissen langfristig und machen es für alle jederzeit zugänglich.
-
Sophos Firewall Logs in Wazuh: Warum OpenSearch Data Streams (noch) nicht nativ gehen – und wie man Logs sauber in eigene Indizes routet und per ISM „datastream-ähnlich“ verwaltet
Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Netzwerk- und Firewall-Telemetrie wie Sophos-SSL-Rejects ist für Detection Engineering und Threat Hunting wertvoll – vorausgesetzt, die Daten landen strukturiert, performant und mit sinnvoller Lifecycle-Strategie im Indexer. In OpenSearch sind Data Streams ein komfortables Modell für kontinuierliche Logdaten. In Wazuh ist der Standardpfad jedoch weiterhin auf zeitbasierte Indizes plus Index State… hier weiterlesen
-
„Duplicate agent name“ bei der Wazuh-Agent-Enrollment: Ursachen in Agent-Inventory, Load Balancer und Authd-Debugging
Einleitung Die Wazuh-Agent-Enrollment ist der erste kritische Schritt, bevor Telemetrie, FIM, Vulnerability Detection oder Active Response überhaupt zuverlässig funktionieren. Wenn der Manager die Registrierung mit Duplicate agent name ablehnt, ist das selten nur ein „Name-Problem“. In der Praxis steckt häufig ein Zustand dahinter, in dem Agenten wiederholt (und erfolglos) re-enrollen, der Manager alte Agent-Identitäten nicht… hier weiterlesen
-
Mehrere Bedingungen in Wazuh-Regeln korrekt umsetzen: if_sid, if_matched_sid und Korrelationsdesign richtig einsetzen
Einleitung Komplexe Use Cases erfordern in Wazuh häufig mehr als eine einfache „Wenn Event X, dann Alert“-Logik. Typische Szenarien sind Multi-Stage-Angriffe, Brute-Force-Versuche mit Vorbedingungen oder Korrelation unterschiedlicher Logquellen innerhalb eines Zeitfensters. Eine häufige Frage lautet daher: Kann eine Wazuh-Regel mehrere Bedingungen enthalten – und wird der Alert nur ausgelöst, wenn alle erfüllt sind? Die kurze… hier weiterlesen
-
Wazuh Indexer im Single-Node dauerhaft „yellow“: Replica-Shards, Index-Templates und .sst-Wachstum sauber beheben
Einleitung Ein dauerhaft gelber Cluster-Status im Wazuh Indexer wirkt auf den ersten Blick wie ein „Kosmetikproblem“. In Single-Node-Installationen ist „yellow“ aber fast immer ein Symptom unpassender Replica-Konfigurationen – und kann reale Nebenwirkungen haben: blockierte Shard-Allokationen, verzögerte/ausbleibende Index-Aktualisierung und wachsender Plattenverbrauch durch shardbezogene Daten im Indexer-Datenpfad. Genau dieses Muster tritt häufig bei systemnahen Indizes wie .opendistro-*… hier weiterlesen
-
Wazuh Cloud mit GKE: Warum DaemonSet-Agents „keine Daten“ liefern, gcp-pubsub mit Exit Code 1 läuft und wie man Agent-Pods, Inventar und Auto-Cleanup richtig betreibt
Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) In GKE-Umgebungen entstehen zwei Datenpfade, die in Wazuh sauber zusammenspielen müssen: Cluster-/Workload- und Node-nahe Telemetrie (über Wazuh Agents im Cluster) sowie Cloud-Service-Logs (z. B. VPC Flow Logs, DNS, Firewall) – häufig über Pub/Sub. Wenn Agents zwar enrollen, im Dashboard aber fast nur „Agent started / disconnected“ erscheint, ist das meist… hier weiterlesen
-
Wazuh Decoder: Warum
user als dstuser erscheintProblem Ihr habt einen Custom-Decoder für Trellix/McAfee Web Gateway gebaut und extrahiert usrName erfolgreich: Sobald ihr aber versucht, das Feld auf einen „statischen“ Namen zu ändern … … taucht das Ergebnis nicht als user, sondern als dstuser auf. Ursache Das ist kein Bug in eurem Regex, sondern erwartetes Verhalten: Darum wird aus <order>user</order> immer dstuser,… hier weiterlesen
-
iMaster NCE Logs in Wazuh sauber dekodieren: Von Rohtext zu strukturierten Feldern und belastbaren Alerts
Einleitung Netzwerk- und Controller-Plattformen wie iMaster NCE liefern Alarmmeldungen häufig in proprietären Formaten, die sich nicht „out of the box“ in ein SIEM-Regelwerk integrieren lassen. Wazuh ist hier stark, weil sich Logquellen über Custom Decoders schnell strukturieren lassen – erst damit werden aus Textzeilen belastbare Felder für Korrelation, Dashboards und Alarmregeln. In diesem Beitrag zeige… hier weiterlesen
-
Custom Decoder & Rules für „Storage alarm“-Syslog: PCRE2 korrekt einsetzen, Syntaxfehler vermeiden, schneller testen
Einleitung Geräte- und Storage-Logs landen in Wazuh häufig als „Raw Syslog“: ein Syslog-Präfix (Timestamp/Tag) plus ein herstellerspezifischer Payload. Damit daraus verwertbare Alerts entstehen, braucht es zwei Dinge: Decoder, die relevante Felder extrahieren (User, Quell-IP, Ergebnis, Error-Code), und Rules, die diese Felder bewerten. Wazuh liefert dafür eine klare XML-Syntax und unterstützt neben OSRegex auch PCRE2 –… hier weiterlesen
-
Wazuh Office 365 Integration läuft, aber keine Logs im Dashboard – am Ende waren es Zertifikate & Filebeat
Ausgangslage In einem All-in-One-Setup (Wazuh Manager, Dashboard und Indexer auf derselben Azure-VM mit privater IP 10.0.1.4) wurde die Office 365 (O365) Integration eingerichtet. In ossec.log erschien zwar: …trotzdem waren keine O365-Events im Wazuh Dashboard sichtbar, obwohl in Microsoft 365 Audit Logs vorhanden waren. Symptome & erste Hinweise Wichtig war hier die Trennung: Entscheidender Diagnose-Schritt: Wo… hier weiterlesen
-
Produktionsreife Wazuh-SIEM-Architektur im Gesundheitswesen: Rollen, Konfigurationen und Rollout-Reihenfolge für Hot/Warm + Dedicated Masters + Ingest
Einleitung In großen Healthcare-Umgebungen (HIPAA/JCIA/ISO) ist Wazuh nicht nur „ein weiteres SIEM“, sondern ein Betriebs- und Compliance-System: hohe EPS, lange Retention, Auditierbarkeit, HA und vorhersagbare Performance sind entscheidend. Technisch steht und fällt das Design mit einer sauberen Trennung der Verantwortlichkeiten zwischen Wazuh Manager-Cluster (Analyse/Regeln/API), Wazuh Indexer (OpenSearch-Fork) für Storage/Suche und einem Dashboard für Visualisierung. Die… hier weiterlesen
-
O365-Integration läuft, aber im Wazuh Dashboard „keine Logs“: Wenn Filebeat am Indexer scheitert (SAN/Host-Mismatch)
TL;DR Wenn das Office365-Modul sauber startet und du O365-Events in alerts.json findest, aber im Dashboard nichts siehst, ist die Integration meist nicht das Problem – sondern der Transport in den Indexer (typisch: Filebeat → Indexer). In diesem Fall war die Ursache ein TLS-Zertifikat ohne passenden SAN für die private IP (10.0.1.4): Das Zertifikat war nur… hier weiterlesen
-
Vergangene Logs mit Wazuh erfassen: Was der Agent standardmäßig sammelt, was
wirklich tut und wie man historische Logs sicher nachlädt Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Wazuh ist primär als Realtime-SIEM/XDR-Plattform konzipiert. Entsprechend sammelt der Agent standardmäßig nur neue Logeinträge, die ab dem Start des Logcollectors entstehen. In der Praxis entsteht jedoch häufig der Bedarf, bereits vorhandene Logs (z. B. vor der Agent-Installation oder während einer Downtime) nachträglich zu analysieren – etwa im Rahmen einer forensischen… hier weiterlesen
-
Wazuh „Not enough buffer space“ in wazuh-remoted: Warum einzelne Agents Konfigs nicht mehr bekommen und wie man bqueue-/Send-Buffer-Backpressure sauber debuggt
Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Wenn Wazuh-Agenten keine Shared Configs oder Active-Response-Kommandos mehr erhalten, ist das kein „Komfortproblem“, sondern ein Sicherheitsrisiko: Policies, Detektionslogik und Reaktionen kommen nicht mehr zuverlässig am Endpoint an. In der Praxis äußert sich das häufig über wazuh-remoted-Meldungen wie „Not enough buffer space“ und „Package dropped“. Der reflexartige Ansatz, remoted.send_buffer_size hochzusetzen, hilft… hier weiterlesen
-
ILM/ISM Hot–Warm–Cold in einer Wazuh-Umgebung
Ausgangsfrage (Jonas) Jonas betreibt 1× Manager, 1× Dashboard, 1× Indexer und möchte Index Lifecycle Management (Wazuh Indexer / OpenSearch ISM) so konfigurieren, dass Indizes durch hot → warm → cold laufen – inkl. Shrink in warm und “cold phase”-Aktionen. Kernaussagen aus den Antworten 1) Hot–Warm–Cold braucht mindestens einen “Warm”-Node Mah Wen Qiang verweist auf die… hier weiterlesen
-
SentinelOne-Events als JSON
SentinelOne in Wazuh: Warum JSON-Events im Dashboard fehlen, Logtest „nicht erkannt“ meldet und wie du Parsing, Filebeat-Pipeline und Korrelation stabil bekommst Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Die SentinelOne-Integration ist in Wazuh ein klassischer „Datenpipeline“-Use-Case: Events kommen per API oder Syslog an, werden lokal als JSON oder CEF geschrieben, anschließend von Wazuh ingestiert, decodiert, in den… hier weiterlesen
-
Wazuh Dashboard zeigt nur noch Daten eines Workers: Systematische Fehleranalyse für „Filebeat sendet, Indexer ingestiert nicht“
Einleitung Wenn in einer Wazuh-Cluster-Architektur plötzlich nur noch Events von einem Worker im Dashboard auftauchen, wirkt es auf den ersten Blick wie ein Indexer-Problem. In der Praxis liegt die Ursache häufig an einer Kette aus Nebenwirkungen: ein kurzfristig voller Datenträger auf dem betroffenen Worker, ein danach „gesund“ wirkender Filebeat – und trotzdem keine ingestierten Dokumente.… hier weiterlesen
-
Thread-Zusammenfassung: “Sysmon Event kommt an – aber kein MISP-Alert im Dashboard”
In diesem Thread war der Kernfehler ein Missverständnis über den Datenfluss: Was Jitendra erwartet hat Warum 100622 nie feuern kann (so wie es gebaut ist) Die Regel 100622 matcht nicht Sysmon-Events – sie matcht Events, die bereits MISP-Felder enthalten, z. B.: Deine Sysmon-Roh-Events (EventChannel, EventID 22 / 1) enthalten aber kein integration:misp und kein misp.*.Also… hier weiterlesen
-
Wazuh Alerts während Wartungsfenstern gezielt unterdrücken
Einleitung Regelmäßige Betriebssystem- und Applikationsupdates gehören zum Alltag jeder IT-Umgebung. Für Security- und SIEM-Teams stellen diese Wartungsfenster jedoch eine besondere Herausforderung dar: Während Updates laufen, erzeugen Agenten oft eine Vielzahl erwartbarer, aber sicherheitlich irrelevanter Events. Ohne geeignete Maßnahmen kann dies zu Alert-Fluten, unnötiger Belastung des Wazuh-Managers und Alarmmüdigkeit bei Analysten führen. Dieser Artikel zeigt, wie… hier weiterlesen
-
Warum ein Sophos-Firewall-Decoder in Wazuh „nicht funktioniert“: Wenn mehrere Events in einer Logzeile stecken
EinleitungCustom Decoder sind in Wazuh ein Standardwerkzeug, um herstellerspezifische Logs (z. B. Sophos Firewall „SFW“) in strukturierte Felder zu überführen. Wenn ein Decoder trotz korrekter Regex scheinbar nicht greift, liegt die Ursache häufig nicht im Regex selbst, sondern im Ingestionsformat: Wazuh decodiert grundsätzlich pro eingehendem Event eine Logmessage – wenn ein Forwarder oder ein Logfile… hier weiterlesen
-
Wazuh + MISP + Sysmon: Warum Logtest klappt, aber live keine MISP-Alerts kommen (und warum full_log alles kaputtmachen kann)
In diesem Thread ging es um ein Problem, das in der Praxis extrem häufig ist: Hier ist die Essenz + die eigentliche Root Cause-Kette. 1) Warum Logtest funktioniert, aber live nicht wazuh-logtest prüft nur: Live passiert zusätzlich: Heißt: Logtest kann “grün” sein, obwohl die Integration live an einer anderen Stelle bricht. 2) Der echte Showstopper:… hier weiterlesen