Slack

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

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

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

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Vulnerability Detection ist in Wazuh ein zentrales Hygiene- und Exposure-Signal: Es korreliert die Software-Inventardaten der Agents mit Vulnerability-Intelligence und macht Schwachstellen im Dashboard und via Alerts sichtbar. Gerade auf Debian 12/13 sorgt dieses Feature aber immer wieder für Frust, wenn nach einer frischen Installation scheinbar „Hunderte bis Tausende“ CVEs auftauchen, hier weiterlesen

Wer mit Windows-Events in Wazuh arbeitet, landet früher oder später hier:Die Konsole ist voll mit ganz normalen, technischen Logons, vor allem Event ID 4624 (Logon Success) – z. B. Service-Logons über services.exe.Kein Angriff, kein Risiko – aber jede Menge Lärm. Genau das wollte Kashif in seinem Test-Setup lösen:„Wie unterdrücke ich nur diese Routine-Logons, ohne andere hier weiterlesen

Einleitung Windows BitLocker ist in vielen Umgebungen ein Sicherheitsanker – gerade deshalb sind Events wie „BitLocker was suspended“ operativ relevant: Sie können auf Wartungsfenster, policy-gesteuerte Änderungen oder auch auf ein Risiko (Schutz temporär deaktiviert) hinweisen. Wenn solche Ereignisse in Wazuh zwar in archives.log auftauchen, aber im Dashboard nicht sichtbar sind und Custom Rules nur bei hier weiterlesen

Einleitung Cloudflare stellt umfangreiche Logs zu Web-Anfragen, Firewall-Events und Audit-Daten bereit, die für Sicherheits- und Vorfallanalysen in modernen SIEM-Umgebungen essenziell sind. Wazuh als Open-Source-SIEM/EDR-Plattform kann diese Daten nicht „out-of-the-box“ direkt aus Cloudflare empfangen, bietet aber flexible Mechanismen zur Ingestion über Cloud-Storage-Ziele oder API-basierte Lösungen. Dieser Beitrag zeigt die verschiedenen technischen Pfade, Voraussetzungen und praktische Implementierungsschritte hier weiterlesen

Kevin stand vor einer typischen, aber extrem nervigen OpenSearch/Wazuh-Fehlermeldung. Beim Aggregieren nach manager.name kam vom Wazuh-Indexer: Kurz gesagt: Du willst ein Textfeld aggregieren, das als text gemappt ist, nicht als keyword. Im Wazuh-Kontext ist das ungewöhnlich – denn manager.name ist in der Standard-Template eigentlich schon als keyword definiert. Also: Was lief hier schief? Was die hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Zeitbasierte Korrelation gehört zu den häufigsten Anforderungen in SIEM- und HIDS-Umgebungen: Mehrere fehlgeschlagene VPN-Logins sollen zunächst als Verdachtsmoment erkannt und bei wiederholtem Auftreten zu einem höher priorisierten Alarm eskaliert werden. In Wazuh wird das oft mit frequency/timeframe und „Composite Rules“ (if_matched_sid) umgesetzt. In der Praxis scheitert genau diese Eskalationslogik jedoch hier weiterlesen

Einleitung Hochverfügbarkeit ist ein zentrales Thema beim Betrieb von SIEM- und Security-Monitoring-Plattformen. In Wazuh-Umgebungen wird dieses Ziel häufig über den Einsatz eines Clusters aus Master- und Worker-Nodes verfolgt. Dabei taucht regelmäßig die Frage auf, ob sich die Master-Rolle nachträglich oder im Fehlerfall dynamisch auf einen Worker verschieben lässt. Die kurze Antwort lautet: nein. Die längere hier weiterlesen

Einleitung CDB-Listen sind ein zentrales Werkzeug in Wazuh, um große Mengen an Indikatoren wie IPs, Domains oder Hashes performant gegen eingehende Events zu prüfen. Gerade im Kontext von Threat Intelligence und IOC-Matching entsteht jedoch häufig die Erwartung, dass CDB-Listen nicht nur zur Erkennung, sondern auch zur Datenanreicherung genutzt werden können – etwa um eine Beschreibung hier weiterlesen

Einleitung Der Betrieb von Wazuh auf Kubernetes bringt viele Vorteile in Bezug auf Skalierbarkeit und Automatisierung – erhöht aber gleichzeitig die Komplexität bei sicherheitsrelevanten Änderungen. Besonders deutlich wird dies beim Ändern von Benutzerpasswörtern für Indexer- und API-Komponenten. Ein scheinbar einfacher Vorgang kann schnell zu Authentifizierungsfehlern oder nicht mehr erreichbaren Services führen, wenn die Abhängigkeiten zwischen hier weiterlesen

Daniel meldete ein Problem, das viele Wazuh-Nutzer kennen:Beim Upload einer Custom Rule über das Dashboard erscheint nur: Selbst wenn die Regel eigentlich harmlos aussieht. In diesem Beitrag zeige ich: Problem 1: Fehlerhafte Syntax bei Frequenz-Regeln Die erste Regel des Users: Was war falsch? Fehler 1 — if_sid falsch eingesetzt if_sid ist für eine einfache Regellogik.Für hier weiterlesen

Einleitung Fehlgeschlagene Datenbank-Authentifizierungen gehören zu den wichtigsten Signalen in einem SIEM: Sie sind häufiges Symptom für Credential-Stuffing, Brute-Force-Versuche, Fehlkonfigurationen oder ausgerollte Systeme ohne korrekt gesetzte Secrets. Damit Wazuh solche Ereignisse zuverlässig erkennt, braucht es zwei Bausteine: einen Decoder, der die relevanten Felder aus dem Log extrahiert (z. B. den betroffenen PostgreSQL-User), und passende Rules, die hier weiterlesen