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 von All-in-One zu Cluster skalieren: Sizing nach EPS statt Agent-Zählerei, Migration ohne Risiko und Konsolidierungsstrategie

    Einleitung Sobald Wazuh von „Proof of Concept“ in den produktiven SOC-Betrieb wächst, kippt ein All-in-One-Setup oft genau dort um, wo es weh tut: CPU/RAM-Spitzen durch Analyse und Korrelationsarbeit, I/O-Engpässe in /var/ossec, und vor allem Storage- und Performance-Druck im Indexer durch steigende Datenvolumina und Retention. Mit ~700 Agents plus zusätzlichen Integrationen (z. B. Firewalls via Syslog) hier weiterlesen

  • Kann man in Wazuh 4.14.x Regeln auf Basis von OpenSearch Anomaly Detection erstellen?

    Und wie arbeitet die eingebaute Anomaly Detection überhaupt? Ausgangsfrage aus dem Thread User Yugandhar M. wollte wissen: „Kann ich Wazuh-Regeln auf OpenSearch Anomaly Detection erstellen?“(gemeint: Kann man Alerts generieren oder Wazuh-Regeln schreiben, die auf Anomalien basieren, die OpenSearch erkennt?) Die Antwort von Wazuh Engineer Bony John lautet:Ja – in Wazuh 4.14.x ist Anomaly Detection voll hier weiterlesen

  • Wazuh All-in-One nach VM-Reboot instabil: Wazuh Indexer „request timeout“, Bootstrap-Checks (memory_lock) und API-Timeouts nachhaltig beheben

    Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) All-in-One-Installationen (Manager, Indexer, Dashboard auf einer VM) sind für den Einstieg bequem – im Betrieb aber empfindlich gegenüber Ressourcenkonkurrenz. Typische Symptome nach einem Reboot: Der Wazuh Indexer startet nicht mehr („service failed“, „request timeout“), Bootstrap-Checks brechen ab („memory locking requested … but memory is not locked“) und die Wazuh API hier weiterlesen

  • Windows Logoff-Events fluten Wazuh: So filterst du nur „echte“ User-Logins (AD/Windows Server)

    Problem:Auf einem Windows Server (z. B. Domain Controller/Active Directory) laufen die Windows User Logoff-Events heiß und erzeugen in Wazuh eine Log-Flut – ohne echten Mehrwert. Ziel ist: Nur relevante Login-Events behalten (z. B. interaktive Logins), den Rest möglichst früh abstellen. Warum das passiert Auf Windows-Systemen entstehen Login/Logout-Events sehr häufig – nicht nur durch „echte“ Benutzer, hier weiterlesen

  • DISK CRITICAL trotz 95 GB frei: Wenn /var wegen Inodes und Wazuh-Indexer-Queue (wazuh-states-vulnerabilities) explodiert

    Einleitung In Wazuh-Umgebungen mit vielen Agents kann „Disk Critical“ auf Worker-/Manager-Nodes plötzlich auftreten, obwohl df -h noch zweistellige Gigabytes an freiem Speicher zeigt. Der Grund ist häufig nicht der freie Platz, sondern ein Inode-Exhaustion (z. B. inode=99%) – ausgelöst durch sehr viele Dateien in Wazuh-Queues oder RocksDB/Indexer-Connector-Verzeichnissen. In diesem Beitrag geht es um ein konkretes hier weiterlesen

  • Wazuh + MISP für Firewall-Logs über Rsyslog: IP-IOC-Lookups statt nur Hash-Abgleich

    Einleitung Viele Wazuh–MISP-Anleitungen demonstrieren die Integration anhand von Datei-Hashes (z. B. FIM-basierte Use-Cases). In realen SIEM-Setups – besonders mit Firewalls – ist jedoch häufig der IP-basierte IOC-Abgleich entscheidend: „Ist die zugelassene oder geblockte Gegenstelle malicious?“ Die gute Nachricht: Aus Sicht des Wazuh Managers macht es keinen Unterschied, ob Logs direkt vom Agent kommen oder über hier weiterlesen

  • 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