Michael Muenz

Einleitung Wenn ein Wazuh-Cluster plötzlich keine oder nur noch sporadisch Alerts im Dashboard anzeigt, wirkt das zunächst wie ein Problem auf den Managern oder bei Filebeat. In der Praxis liegt die Ursache jedoch sehr häufig im Wazuh Indexer (OpenSearch): Sobald Shards nicht mehr alloziert werden können oder neue Indizes nicht mehr sauber angelegt werden, bricht … Weiterlesen

Einleitung Eine All-in-One-Installation von Wazuh – also Server, Indexer und Dashboard auf einem einzelnen Host – ist für kleine bis mittlere Umgebungen ein praktikabler Einstieg. Mit steigender Agentenanzahl und hohem Logaufkommen stößt dieses Modell jedoch schnell an physische und architektonische Grenzen. In diesem Beitrag analysieren wir ein typisches Szenario mit über 120 Agents und mehr … Weiterlesen

Einleitung Wazuh ist primär für die Echtzeitüberwachung von Logquellen konzipiert. Dennoch entsteht in der Praxis häufig der Bedarf, historische Logdateien – etwa aus Firewalls – nachträglich zu analysieren, um: Ein typisches Szenario: Eine statische FortiGate-Logdatei mit Millionen Einträgen soll in Wazuh ingestiert und automatisiert ausgewertet werden. Dieser Beitrag erklärt, warum das direkte Einlesen nicht funktioniert, … Weiterlesen

Einleitung Reindexing ist im Wazuh-Umfeld ein bewährtes Mittel, um Mapping-Konflikte zu beheben oder Datenstrukturen zu bereinigen. Besonders bei wazuh-alerts-* Indizes können inkonsistente Feldtypen zu Aggregationsfehlern und fehlerhaften Dashboards führen. Doch nach einem Reindexing treten häufig neue Probleme auf: Visualisierungen brechen, Dashboards zeigen Fehler wie “Could not locate that index-pattern” oder Aggregationen funktionieren nicht mehr. Dieser … Weiterlesen

Einleitung pfSense ist in vielen Umgebungen die zentrale Telemetriequelle für Firewall- und Filterlog-Events. Wazuh kann diese Logs hervorragend korrelieren und alarmieren – allerdings nur, wenn die Syslog-Nachrichten in einer Form ankommen, die Wazuh sauber „pre-decodieren“ kann. Genau hier scheitern pfSense-Setups regelmäßig: pfSense sendet in der Praxis häufig BSD/RFC3164-ähnliche Messages ohne Hostname-Feld, was in Wazuh zu … Weiterlesen

Einleitung Wazuh erkennt Schwachstellen zuverlässig, indem es Softwareinventar über Syscollector mit Vulnerability-Content korreliert. In vielen Umgebungen beginnt das eigentliche Problem aber erst danach: Wie werden Findings priorisiert, einem Owner zugewiesen, fristgerecht verfolgt, sauber dokumentiert und nach dem Patchen verifiziert – ohne dass das Team in Tabellenkalkulationen und manuellen Nachprüfungen versinkt? In der Community wurde dafür … Weiterlesen

Einleitung Wenn nach einem Wazuh-Upgrade plötzlich keine Agenten mehr im Dashboard erscheinen, obwohl Events weiterhin vom Agenten ankommen, ist das fast nie ein „Agent offline“-Problem. In der Praxis steckt dahinter häufig eine Kombination aus RBAC (Rollen-/Rechtemodell), LDAP/AD-Mappings und einem instabilen oder nicht initialisierten OpenSearch-Security-Plugin. Das Ergebnis: Der Manager verarbeitet Daten, aber der Dashboard-User darf (scheinbar) … Weiterlesen

Einleitung Systemzustände per Command-Ausführung zu überwachen (Ports, Kernel-Flags, Prozesse, eBPF-Settings) ist in Wazuh ein etabliertes Muster – aber die Plattform bietet dafür zwei unterschiedliche Wege, die sich im Datenfluss, in der Standardauswertung und in der Alert-Erzeugung deutlich unterscheiden. Wer beides vermischt, stolpert schnell über scheinbar „verschwundene“ Events, fehlende Archive-Einträge oder Ausgaben, die unerwartet zeilenweise als … Weiterlesen

Einleitung Wer in Wazuh eigene Decoder baut, erwartet intuitiv häufig ein „Pipeline“-Verhalten: Der Parent extrahiert Basisfelder, Child-Decoder ergänzen weitere Felder – und Regeln können anschließend exakt auf den passenden Child matchen. In Wazuh ist das Decoder-Processing jedoch bewusst anders konstruiert: Es ist auf schnelle Klassifizierung und deterministisches Branching optimiert, nicht auf additive Feldvererbung. Das fällt … Weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Rootcheck ist ein zentraler Bestandteil der Host Integrity Monitoring-Strategie in Wazuh. Es prüft das System auf verdächtige Dateien, Rootkits, versteckte Objekte und Policy-Verstöße. Gerade in containerisierten Umgebungen oder bei stark genutzten Web-Roots entstehen jedoch viele „Noise“-Events – etwa unter /var/lib/docker/, /var/lib/containerd/, /tmp/ oder Applikationsverzeichnissen. Die naheliegende Lösung ist das <ignore>-Tag … Weiterlesen