Slack

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.

  • 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 hier 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 hier 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“. hier 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 hier 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 hier 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 hier 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 hier 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 hier 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 hier weiterlesen

  • Wazuh Cross-Cluster Search (CCS): Warum ein klassischer Read-Only-User nicht ausreicht und welche RBAC-Rollen wirklich benötigt werden

    Einleitung Cross-Cluster Search (CCS) ermöglicht es, mehrere Wazuh-Cluster zentral über einen Wazuh-Indexer abzufragen und die aggregierten Daten im Dashboard darzustellen. Gerade in Multi-Site- oder Mandanten-Umgebungen ist CCS ein essenzieller Baustein für zentrale Security-Analysen, SOC-Betrieb und konsolidierte Incident-Response-Prozesse. In der Praxis zeigt sich jedoch häufig ein Problem: Ein nach Dokumentation erstellter Read-Only-User kann sich zwar am hier weiterlesen

  • Wazuh 4.11 stoppt Datenaufnahme durch Shard-Limit im Indexer: Ursachen, Sofortfix und nachhaltige Retention-Strategie

    Einleitung Wenn im Wazuh Dashboard plötzlich keine neuen Events mehr erscheinen, wirkt das zunächst wie ein Pipeline-Problem (Manager, Filebeat, Indexer, Dashboard). In der Praxis ist die Ursache häufig eine Schutzgrenze im Wazuh Indexer (OpenSearch): Sobald das Cluster das maximale Shard-Limit erreicht, scheitert die Index-Erstellung – und damit bricht die Datenaufnahme ab. Besonders in Single-Node-Setups mit hier weiterlesen

  • Wazuh OpenClaw Autopilot mit Ollama statt Claude betreiben: Air-gapped Setup ohne Tailscale und ohne Cloud-API-Keys

    Einleitung „Autonomous SOC“-Ansätze klingen attraktiv: Alerts automatisch triagieren, zusammenhängende Incidents korrelieren, Evidence Packs erzeugen und Response-Pläne vorschlagen – idealerweise mit Human-in-the-Loop und klaren Policies. In der Praxis scheitert die Evaluierung aber oft an zwei Punkten: (1) das Projekt ist auf Cloud-LLMs (z. B. Claude) vorgeprägt und (2) die Referenzinstallation nutzt Tailscale für Zero-Trust-Networking. Dieser Beitrag hier weiterlesen

  • 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 erscheint

    Problem 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