Slack

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

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