Slack

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… hier 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,… hier 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… hier 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… hier 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… hier 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)… hier 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… hier 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… hier 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… hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) In vielen Wazuh-Deployments landen Applikations- und Container-Logs als Datei-Rotation in Sammelverzeichnissen wie /var/log/docker-logs/. Der typische Ansatz ist ein breites Wildcard-Pattern (*.log) für maximale Abdeckung. Spätestens wenn einzelne Dateien Multiline-Stacktraces oder Batch-Events enthalten, wird das jedoch heikel: Diese Files müssen anders geparst werden (z. B. multi-line-regex), dürfen also nicht gleichzeitig über… hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Vulnerability Detection ist in Wazuh nur so gut wie die zugrunde liegenden Datenflüsse: Software-Inventar vom Agent (Syscollector), Korrelationslogik im Manager (Vulnerability Detection / vulnerability-scanner), Persistenz im Wazuh-DB-Subsystem sowie die Ablage/Abfrage im Indexer. Wenn ein Server gepatcht wurde, CVEs aber „eine Woche später immer noch“ im Dashboard stehen, ist das fast… hier weiterlesen

Einleitung Regelmäßige Schwachstellenscans von Infrastruktur- und Security-Komponenten sind Best Practice – und führen nicht selten zu Befunden in Drittbibliotheken. Besonders sensibel ist dies bei SIEM-Frontends wie dem Wazuh Dashboard, da hier potenziell sicherheitskritische Interaktionen zwischen Backend, Dateisystem und Benutzeroberfläche stattfinden. Dieser Beitrag beleuchtet den Umgang mit CVE-2025-68428 in Wazuh v4.14.1, erklärt die architektonischen Hintergründe und… hier weiterlesen

Einleitung Ein häufiges Ziel im Security Monitoring ist nicht nur das Erkennen verdächtiger Aktivitäten, sondern auch das Erkennen von Abweichungen vom Sollzustand: Ein wichtiger Prozess läuft nicht (mehr), ein Agent ist „blind“, oder eine sicherheitsrelevante Komponente wurde deaktiviert. In Wazuh ist die Versuchung groß, dafür einfach Regeln auf Syscollector-Prozessdaten zu bauen. In der Praxis stößt… hier weiterlesen

Einleitung Bei Firewalls und Security-Appliances ist Syslog oft die einzige Telemetriequelle – und gleichzeitig die unbequemste: viele Module, wechselnde Felder, keine Herstellerdokumentation. Für Wazuh-Administratoren entsteht damit ein doppeltes Problem: Einerseits will man saubere Decoder und sinnvolle Regeln für bekannte Message-Typen, andererseits möchte man sofort alarmiert werden, wenn neue Message-Typen oder neue Felder auftauchen, um den… hier weiterlesen

Einleitung Die Einbindung von Netzwerkgeräten über Syslog gehört zu den klassischen Einsatzszenarien von Wazuh. Gerade Router wie MikroTik liefern sicherheitsrelevante Informationen zu Verbindungen, Firewalls, NAT und Systemereignissen. Häufig tritt jedoch ein typisches Problem auf: Die Logs werden korrekt per Syslog empfangen und sogar im Wazuh-Archiv gespeichert, tauchen aber weder als Alerts noch in den Dashboards… hier weiterlesen

Einleitung Wazuh skaliert gut – aber bei mehreren tausend Agents, zusätzlicher Syslog- und Datenbank-Ingestion sowie 90 Tagen Aufbewahrung entscheidet die Architektur über Stabilität, Kosten und Betriebskomplexität. Besonders kritisch sind dabei die Trennung von Analyse (Manager-Cluster) und Storage/Search (Indexer-Cluster), eine saubere Hot/Warm-Strategie im Indexer sowie ein realistisches Kapazitätsmodell (EPS, Eventgröße, Index-Overhead, Replikate, Shards). Dieser Beitrag konsolidiert… hier weiterlesen

Einleitung Archive-Logging (logall / logall_json) gehört zu den mächtigsten, aber zugleich riskantesten Funktionen im Wazuh-Manager. Es ermöglicht vollständige Transparenz über alle verarbeiteten Events – inklusive jener, die keine Alerts erzeugen. Genau diese Eigenschaft macht Archive-Logs für Debugging, Troubleshooting und Regelentwicklung unverzichtbar. In produktiven Umgebungen mit hohem Eventdurchsatz kann das globale Aktivieren von Archives jedoch schnell… hier weiterlesen

Einleitung Wer Wazuh in Kubernetes (z. B. EKS) betreibt, will früher oder später mehr als nur alerts.json in den Indexer schreiben: Für forensische Analysen, Incident Response und Compliance ist das Archiv-Logging (archives.json) extrem wertvoll. In klassischen Deployments genügt oft ein simples Aktivieren des Filebeat-Archives-Filesets. In Kubernetes kann genau dieser Schritt jedoch dazu führen, dass der… hier weiterlesen