Slack

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Single Sign-on (SSO) über Microsoft Entra ID ist in vielen SIEM-Umgebungen ein Muss: zentrale Identitäten, MFA, kontrollierte Rollenvergabe und nachvollziehbare Zugriffe auf Dashboards. In Wazuh basiert SSO (SAML) im Kern auf der OpenSearch-Security-Konfiguration des Wazuh Indexers und erfordert ein sauberes Zusammenspiel aus YAML-Struktur, Dateipfaden und dem korrekten Einsatz von securityadmin.sh.… hier weiterlesen

Einleitung Forcepoint DLP liefert für SIEM-Integrationen häufig CEF über Syslog. Auf dem Papier ist das ideal: ein standardisierter CEF-Header plus Extension als Key-Value-Paare. In der Praxis scheitert die Dekodierung in Wazuh aber oft genau dort, wo DLP-Events wertvoll werden: bei freien Textfeldern und Policy-/Kategorie-Namen mit Leerzeichen, Sonderzeichen oder Doppelpunkten. Das führt zu unvollständigen Feldern und… hier weiterlesen

Einleitung CEF (Common Event Format) ist in vielen SIEM-Pipelines der „kleinste gemeinsame Nenner“ für Security-Telemetrie. In der Praxis stolpern Wazuh-Administratoren aber regelmäßig darüber, dass CEF-Events aus Kaspersky Security Center (KSC) nur teilweise geparst werden: Statt Header + Extension-Key/Value-Paare landen nur wenige Felder im Event. Das ist nicht nur lästig, sondern reduziert direkt den Detection- und… hier weiterlesen

In der Praxis landen Citrix ADC (ehem. NetScaler) Syslog-Zeilen oft in einem Format, das stark an klassische ns.log-/Syslog-Ausgaben erinnert (z. B. 0-PPE-0 : TCP CONN_TERMINATE …). Dieses Muster matcht schnell auf generische/Default-Decoder (z. B. netscaler), sodass eigene Felder nicht wie gewünscht extrahiert werden oder „falsch“ interpretiert wirken. Ein typisches Citrix-Beispiel sieht u. a. so aus:… hier weiterlesen

Einleitung Vulnerability Detection ist nur dann wirklich hilfreich, wenn Findings korrekt eingeordnet werden können. Gerade bei CVEs mit hohem Schweregrad führt eine falsche oder missverständliche Zuordnung schnell zu Verunsicherung – insbesondere in Audits oder Compliance-Prüfungen. Ein aktuelles Beispiel ist CVE-2024-56180, das in Wazuh auf Ubuntu 24.04 LTS als kritisch gemeldet wird, obwohl das betroffene Produkt… hier weiterlesen

Einleitung Die Qualität und Aktualität von Vulnerability-Daten ist ein zentraler Erfolgsfaktor für jede SIEM- und Vulnerability-Management-Strategie. In Wazuh übernimmt diese Rolle die Cyber Threat Intelligence (CTI), die CVEs, Schwachstellen-Metadaten und zugehörige Informationen bereitstellt. In der Community taucht regelmäßig die Frage auf, wie aktuell diese Daten tatsächlich sind, wie oft neue CVEs verfügbar werden und warum… hier weiterlesen

Einleitung Brute-Force- und Password-Spraying-Angriffe laufen selten „sauber“ auf einem einzigen System. In realen SIEM-Szenarien verteilen sich fehlgeschlagene Anmeldungen über verschiedene Hosts, Dienste und Logquellen – oft mit identischem Quell-IP-Adressraum oder identischem Benutzernamen. Wazuh kann solche Muster grundsätzlich über Frequenz-/Zeitfenster-Regeln korrelieren. In der Praxis scheitern entsprechende Custom Rules jedoch häufig daran, dass die Korrelation nicht auf… hier weiterlesen

Ursachenanalyse und saubere Lösung bei Distributed / All-in-One Deployments Einleitung Beim Deployment des Wazuh Dashboards nach offizieller Anleitung kann es zu einer verwirrenden Situation kommen: Dieser Artikel erklärt: 1. Ausgangssituation Setup Beobachtungen 2. Wichtige Hintergrundinfo: Wann wird wazuh.yml erstellt? Die Datei wazuh.yml wird nicht während der Paketinstallation erzeugt. 📌 Sie wird erst automatisch generiert, wenn:… hier weiterlesen

Custom Decoder & Rules korrekt umsetzen (inkl. typischer Stolperfallen) Einleitung Viele Organisationen betreiben CMS-basierte Webanwendungen wie Drupal und stehen vor der Herausforderung, End-of-Life-Versionen (EOL) zuverlässig zu erkennen.Wazuh bietet dafür alle notwendigen Bausteine – Logsammlung, Decoder und Regeln – allerdings mit einigen syntaktischen und logischen Feinheiten. Dieser Artikel zeigt anhand eines realen Community-Falls: 1. Ausgangssituation &… hier weiterlesen

Einleitung HTTP-Access-Logs sind in Wazuh häufig der Einstiegspunkt für Web- und AppSec-Korrelationen: Brute-Force, Scans, verdächtige User-Agents, Exploit-Versuche und Policy-Verstöße werden oft erst durch sauber extrahierte Felder wirklich auswertbar. In der Praxis scheitert die Erweiterung bestehender Decoder jedoch oft an einem Detail: der Decoder-Pipeline und der Art, wie Wazuh Parent-, Child- und „Sibling“-Decoder auswertet. Dieser Beitrag… hier weiterlesen

Einleitung UniFi UDM Pro (inkl. IDS/IPS-Daemon) produziert Syslog-Events, die in Wazuh oft zunächst nur als generische Syslog-Meldungen landen. Ohne passende Decoder fehlen strukturierte Felder wie srcip, dstip, dstport oder protocol – und damit auch die Basis für belastbare Regeln und Threat-Hunting-Queries. In diesem Beitrag geht es darum, UDM-Logs in eine eigene Logdatei (z. B. UDMPrologs.log)… hier weiterlesen

Einleitung Die Integration von Threat Intelligence aus MISP in Wazuh ist ein typischer „nächster Schritt“, sobald Detection und Alerting stabil laufen: Indicators aus einem (privaten) TAXII-Feed landen in MISP, und Wazuh soll bei passenden Observables (Hashes, IPs, Domains, URLs) automatisch anreichern und zusätzliche Alerts erzeugen. In produktiven, verteilten Wazuh-Architekturen entsteht dabei schnell ein Skalierungsproblem: Wenn… hier weiterlesen

Einleitung Beim Umzug einer Wazuh All-in-One-Installation auf neue Server ist die häufigste und sinnvollste Designentscheidung: Rollen trennen (Indexer/Dashboard getrennt vom Manager) und – sobald Last oder Verfügbarkeit relevant werden – den Wazuh-Manager als Cluster betreiben. Das reduziert Ressourcenkonkurrenz, vereinfacht Skalierung und schafft eine Grundlage für stabile Agent-Konnektivität. Dieser Beitrag ordnet die typischen Fragen aus der… hier weiterlesen

Einleitung In produktiven SIEM-Umgebungen mit Wazuh ist ein präzises Alert-Tuning essenziell. Gerade auf Windows-Systemen entstehen regelmäßig Events, die sicherheitsrelevant erscheinen, in der Praxis jedoch legitime Systemprozesse darstellen. Ein typisches Beispiel sind temporäre Dateien mit dem Präfix __PSScriptPolicyTest_, die im Zusammenhang mit PowerShell-Ausführungsrichtlinien erzeugt werden. Wenn diese Dateien durch Windows Event Logs erfasst werden, können mehrere… hier weiterlesen

Einleitung Ein klassisches Troubleshooting-Szenario in produktiven Wazuh-Umgebungen: Syslog ist korrekt konfiguriert, Logs erscheinen in archives.json, Decoder- und Rule-Tests funktionieren – aber im Wazuh Dashboard (Discover) sind keine Events sichtbar. In vielen Fällen liegt das Problem nicht an Decodern oder Filebeat-Modulen, sondern am Wazuh Indexer selbst: Der Cluster hat das Maximum an offenen Shards erreicht und… hier weiterlesen