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 E-Mail-Alerts nach Agent-Gruppen filtern: Warum event_location nicht passt und welche Ansätze wirklich funktionieren

    Einleitung E-Mail-Alerts sind in Wazuh ein bewährter „Last Mile“-Kanal für kritische Events – besonders, wenn ein SOC nicht permanent im Dashboard arbeitet oder bestimmte Betriebsgruppen (z. B. Business Units) eigene Benachrichtigungswege brauchen. Häufig lautet die Anforderung: „Sende Alerts nur für Agent-Gruppe X an Empfänger A und nur für Gruppe Y an Empfänger B.“Genau hier stößt hier weiterlesen

  • Warum mein Azure-Logs-Wodle in GCC High plötzlich keine Events mehr holt (und warum Debug-Level „2“ nicht die eigentliche Lösung ist)

    Ausgangslage: Azure Logs laufen… und dann plötzlich nicht mehr User m letormd hatte eine Test-Wazuh-Umgebung (4.14.1), in der Azure-Logs zunächst sauber importiert wurden.Später – auch auf einer frischen Neuinstallation – passierte Folgendes: Spannend wurde es, als er Debugging aktivierte: Subjektiver Eindruck: „Mit Debug an scheint es plötzlich zu funktionieren, ohne nicht.“Das sieht so aus, als hier weiterlesen

  • Wazuh Decoder für UniFi CEF-Logs: Feld-Splitting, Formatabweichungen und Decoder-Konflikte sauber lösen

    Einleitung CEF (Common Event Format) ist ein etabliertes Log-Format mit einem festen Header (Version|Vendor|Product|…) und einer variablen Extension als Key-Value-Liste. Genau diese Mischung sorgt in Wazuh häufig für zwei typische Probleme: Decoder „catcht“ nicht zuverlässig (wegen leicht abweichender CEF-Header-Darstellung) oder Decoder kollidiert mit anderen CEF-Decodern (weil die Prematches zu generisch sind). CEF selbst ist als hier weiterlesen

  • Wazuh Index-Patterns in Discover verbergen oder umbenennen: Was geht nicht – und welche Multi-Tenancy-Workarounds funktionieren

    Einleitung Sobald Wazuh produktiv genutzt wird, taucht ein wiederkehrendes Bedürfnis auf: Nicht jeder Nutzer soll in OpenSearch Dashboards (Wazuh Dashboard) im Discover-Dropdown alle Index-Patterns sehen – vor allem nicht technische Wazuh-States- oder Vulnerability-Indizes wie wazuh-states-vulnerabilities-*. Gleichzeitig sollen die Nutzer aber weiterhin die Wazuh-Apps (z. B. Vulnerability/IT Hygiene/Endpoints) bedienen können. Genau an dieser Stelle kollidieren Erwartungen hier weiterlesen

  • Wazuh File Integrity Monitoring unter Windows: File-Limit, Datenbanküberlauf und MAX_PATH korrekt einordnen

    Einleitung File Integrity Monitoring (FIM) gehört zu den zentralen Sicherheitsfunktionen von Wazuh und ist insbesondere auf Windows-Systemen ein häufig genutztes Werkzeug zur Überwachung kritischer Dateien und Verzeichnisse. In der Praxis stoßen Administratoren jedoch regelmäßig auf Warnungen über ein erreichtes Datei-Limit oder überlange Dateipfade. Dieser Artikel basiert auf einer realen Wazuh-Community-Diskussion und ordnet diese Meldungen technisch hier weiterlesen

  • Wazuh + AWS Security Hub (SQS Subscriber) und CloudTrail im selben aws-s3-Wodle: Wenn nur der erste Collector läuft

    Einleitung Viele Wazuh-Deployments in AWS starten mit CloudTrail – zurecht, denn damit landen IAM-, API- und Control-Plane-Aktivitäten zuverlässig im SIEM. Der nächste logische Schritt ist die Anbindung von AWS Security Hub, um normalisierte Findings (ASFF) zentral zu korrelieren. In der Praxis scheitert das aber oft nicht an AWS selbst, sondern an der Art, wie das hier weiterlesen

  • Wazuh & MISP: Warum deine FIM-Alerts nicht „nachträglich“ angereichert werden können (und wie du es trotzdem löst)

    Im Thread wollte Logitech Flames folgendes erreichen: Ergebnis: Die Frage war: „Wie bekomme ich die MISP-Metadaten in denselben Alert wie Rule 100100?“ 1. Wichtiger Grundsatz: Wazuh-Alerts sind „fertig“, sobald sie geschrieben sind [Wazuh] Hossam bringt den Knackpunkt ziemlich klar auf den Punkt: Wazuh-Alerts sind praktisch unveränderlich.Wenn ein Alert einmal ausgelöst und indiziert ist, wird er hier weiterlesen

  • SCA-Ergebnisse in Wazuh Dashboards visualisieren: Windows Screen Saver Compliance korrekt abbilden

    EinleitungSecurity Configuration Assessment (SCA) ist eines der wirkungsvollsten Module in Wazuh, um Konfigurationsabweichungen auf Endpunkten frühzeitig zu erkennen. Gerade bei Windows-Systemen sind scheinbar einfache Einstellungen wie ein aktiver, passwortgeschützter Bildschirmschoner sicherheitsrelevant, da sie direkten Einfluss auf physische Zugriffsmöglichkeiten haben. In der Praxis entsteht jedoch häufig Verwirrung, wenn Administratoren versuchen, diese SCA-Ergebnisse in einem eigenen Wazuh-Dashboard hier weiterlesen

  • Wazuh Default-Regeln sicher tunen: Warum frequency/timeframe/ignore in 0016-wazuh_rules.xml scheitern – und wie du Rule 203/204 korrekt überschreibst

    Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) In produktiven Wazuh-Umgebungen ist „Alert Noise“ oft weniger ein Detection-Problem als ein Betriebsproblem: Zu viele legitime Ereignisse erzeugen Warnungen, SOC-Workflows werden überlastet und echte Incidents gehen unter. Gleichzeitig ist das Ruleset in Wazuh eng mit der Event-Pipeline (Agent → Manager → Queues → Analysis) verzahnt. Wer Default-Regeln direkt in den hier weiterlesen

  • OPNsense-WebGUI-Login-Logs korrekt dekodieren: Wenn der Solaris-Decoder dazwischenfunkt

    Einleitung Beim Einbinden neuer Logquellen in Wazuh stoßen Einsteiger wie erfahrene Administratoren gleichermaßen auf ein wiederkehrendes Problem: Ein vorhandener Standard-Decoder greift „zu früh“ und verhindert die saubere Analyse eines eigentlich ganz anderen Logformats. Besonders häufig tritt dies bei Syslog-basierten Quellen auf, deren program_name generisch ist. Ein typisches Beispiel sind OPNsense-WebGUI-Logs, die durch den integrierten solaris_bsm-Decoder hier weiterlesen

  • Wazuh E-Mail-Flut stoppen, ohne Detection zu verlieren: noalert vs. no_email_alert und saubere Rule-Änderungen für Frequency/Timeframe-Korrelation

    Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) E-Mail-Benachrichtigungen sind in Wazuh ein bewährtes Mittel, um kritische Ereignisse schnell sichtbar zu machen. In der Praxis kippt dieses Signal aber schnell in Lärm – insbesondere bei Korrelationsregeln mit frequency/timeframe, die bei Scan- oder Recon-Mustern viele Alerts erzeugen. Der typische Wunsch aus dem Betrieb lautet dann: „Regel soll weiter funktionieren, hier weiterlesen

  • Wazuh im Docker-Cluster horizontal skalieren: Warum der neue Worker keine Alerts liefert

    Viele starten mit der offiziellen Wazuh Docker Multi-Node Deployment:3× Indexer, 2× Manager, Dashboard, Nginx – alles auf einem Host.Früher oder später kommt dann die Frage: „Wie skaliere ich das Ganze horizontal auf einen zweiten Server und hänge dort einen weiteren Manager-Worker dran?“ Genau das hat der Nutzer im Thread versucht – mit einigen Stolpersteinen: Schauen hier weiterlesen

  • Wazuh Dashboard zeigt plötzlich keine neuen Logs mehr: Shard-Limit im Indexer als versteckte Ursache

    Einleitung Wenn im Wazuh Dashboard „von jetzt auf gleich“ keine neuen Events mehr erscheinen, wirkt das zunächst wie ein klassisches Pipeline-Problem: Filebeat, Indexer, Manager oder Dashboard „hängen“. In vielen Fällen laufen aber alle Services fehlerfrei, die Alerts liegen sogar weiterhin auf dem Manager vor – und trotzdem bleibt das Dashboard leer. Ein typischer Grund dafür hier weiterlesen

  • Warum der Wazuh-Agent keine Windows Certificate Store Zertifikate nutzen kann – und was das für deine Sicherheitsarchitektur bedeutet

    Wenn Unternehmen beginnen, Wazuh-Agenten per Zertifikat zu authentifizieren, kommt schnell eine naheliegende Frage auf: Kann der Wazuh-Agent Zertifikate aus dem Windows Certificate Store nutzen – z. B. aus „Local Machine → Personal“? Die intuitive Antwort wäre:„Natürlich – Windows verwaltet Zertifikate doch zentral, warum sollte Wazuh sie nicht einfach dort abholen?“ Die tatsächliche Antwort lautet jedoch: hier weiterlesen

  • OpenSearch-Mapping-Konflikte in Wazuh beheben: Netflow-Bytes aggregierbar machen und Visualisierungen retten

    Einleitung Wer Netzflussdaten (z. B. Netflow via Filebeat) in Wazuh nutzt, möchte früher oder später Bandbreite historisch auswerten: Bytes über Zeit, getrennt nach „intern → extern“ und „extern → intern“. In der Praxis scheitert das oft nicht an der Visualisierung selbst, sondern an Index-Mappings, Konflikten über Tagesindizes hinweg und „kaputten“ Saved Objects im Dashboard. Dieser hier weiterlesen

  • Synology-Logs in Wazuh: Warum deine Regeln erst mit den richtigen Decodern funktionieren

    Wer sein Synology NAS mit Wazuh überwacht, stolpert früher oder später über Community-Projekte wie dieses: GitHub: Tomo-9925 / wazuh-synology-dsm-decoder-and-rules– synology-rules.xml (Regeln)– synology-syslog.xml (Decoder) Genau das wollte auch ein User im Wazuh-Community-Channel einbinden – und bekam nur: XML syntax error Die Ursache war am Ende nicht „kaputte XML“, sondern die Reihenfolge & Vollständigkeit der Integration. 1. hier weiterlesen

  • Windows EventID 4624 gezielt filtern: Erfolgreiche RDP-Anmeldungen (LogonType 10) sauber mit Wazuh erfassen

    Einleitung Erfolgreiche Windows-Anmeldungen (EventID 4624) gehören zu den zentralen Telemetriedaten in Wazuh-Umgebungen. Gleichzeitig erzeugen sie ein enormes Datenvolumen, da nahezu jede lokale, Netzwerk- oder Dienstanmeldung dieses Event auslöst. Für viele Security- und SOC-Use-Cases sind jedoch nur bestimmte Anmeldearten relevant – insbesondere Remote Desktop (RDP), das über LogonType 10 abgebildet wird. Dieser Artikel zeigt, wie sich hier weiterlesen

  • TP-Link Access-Point-Logs in Wazuh dekodieren: Vom „archive.json“-Event zum sauberen Custom-Decoder

    Einleitung Netzwerkgeräte wie Access Points liefern häufig sehr hilfreiche Telemetrie: MAC-Adressen, Quell-/Ziel-IP, Protokoll und Ports. Für Security-Teams sind das ideale Datenpunkte, um laterale Bewegung, ungewöhnliche Verbindungen oder auffällige Client-Aktivität frühzeitig zu erkennen. Damit Wazuh diese Informationen regelbasiert auswerten kann, müssen die Rohlogs jedoch korrekt dekodiert werden. In der Praxis scheitert das oft daran, dass statt hier weiterlesen

  • Warum frisst mein Wazuh Indexer-Cluster mehr Speicher als die “Rohdaten-Rechnung” erwarten lässt?

    Ausgangslage: 3 Indexer-Nodes à ~1,7 TB (= ~5,1 TB). Ingestion ~100 GB/Tag ⇒ ~3 TB Rohdaten für 30 Tage. Trotzdem sind ~5,1 TB belegt. Das ist in OpenSearch/Wazuh nicht ungewöhnlich – weil (a) Replikation und Shards Daten vervielfachen und (b) der “Index auf Platte” deutlich mehr ist als der reine JSON-Logstrom. 1) Der häufigste Grund: hier weiterlesen

  • Auditd-Decoder in Wazuh erweitern: PROCTITLE korrekt extrahieren

    EinleitungAuditd-Logs gehören zu den wichtigsten Telemetriedaten für Sicherheits-Monitoring, Incident Response und forensische Analysen. Besonders in Linux-Umgebungen liefern sie reichhaltige Informationen zu Systemaufrufen, Ausführungsparametern und Prozessmetadaten. Eine Herausforderung in Wazuh ist dabei die Decodierung von PROCTITLE, dem Feld, das die vollständige Prozess-Commandline enthält. Dieser Artikel zeigt, wie Sie Ihre auditd-Decoder in Wazuh so erweitern, dass PROCTITLE hier weiterlesen