Wazuh-Blog

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 … 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) … 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 … 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 … 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 … 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 … Weiterlesen

Einleitung Bei Wazuh-Integrationen rund um Microsoft 365 (Office 365 Audit Logs) und Microsoft Graph entstehen Probleme oft nicht im „Abrufen“ der Daten, sondern in der Indexierung: Filebeat liefert Events an den Indexer, doch einzelne Felder passen nicht zum erwarteten Mapping. Das Resultat sind mapper_parsing_exception-Fehler, verworfene Dokumente und am Ende „fehlende Alerts“, obwohl der Manager eigentlich … Weiterlesen

Einleitung Wenn Wazuh Dashboard in Modulen wie Threat Hunting, Vulnerabilities und Inventory „No data“ anzeigt, obwohl die zugehörigen wazuh-states-*-Indizes im Indexer nachweislich Dokumente enthalten, liegt das Problem fast nie an der Datenerhebung. In der Praxis sind es typischerweise Kommunikations- und Integrationsprobleme zwischen Dashboard ↔ Indexer (OpenSearch) und Dashboard ↔ Wazuh API – besonders häufig im … Weiterlesen