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

Einleitung Die Vulnerability Detection ist eines der leistungsstärksten, aber auch am häufigsten missverstandenen Module in Wazuh. Gerade bei Testszenarien – etwa dem absichtlichen Installieren veralteter Pakete – entsteht schnell der Eindruck, dass Wazuh Schwachstellen „nicht erkennt“ oder „nicht anzeigt“. In der Praxis liegt die Ursache jedoch fast immer im Zusammenspiel aus Paket-Inventarisierung, Feed-Updates und der hier weiterlesen

Einleitung Ein neu installiertes Wazuh-System ist funktional sofort einsatzbereit – sicherheitstechnisch jedoch nur dann, wenn Standardpasswörter konsequent ersetzt werden. Gerade in produktiven oder internetnahen Umgebungen ist das Ändern der Default-Zugänge für Dashboard, Indexer und Manager ein absolutes Muss. Dieser Beitrag erklärt sauber getrennt, welche Passwörter es in Wazuh überhaupt gibt, wie sie technisch zusammenhängen und hier weiterlesen

Einleitung Beim Bau eigener Wazuh-Rulesets entsteht schnell der Wunsch nach einer „Auffangregel“: Alles, was nicht spezifisch gematcht wird, soll trotzdem klassifiziert, geloggt und später analysierbar sein. Genau hier stolpern viele – weil Wazuh Regeln nicht nach Rule-ID priorisiert, sondern nach Evaluierungslogik (insbesondere Severity/Level, Rule-Chain und Matching). Das Ergebnis: Eine Catch-all-Regel feuert immer, während die eigentlich hier weiterlesen

Einleitung pfSense ist in vielen Umgebungen nicht nur ein Firewall-Gateway, sondern auch ein zentraler Audit-Punkt: WebGUI-Logins, Konfigurationsänderungen und das Anwenden von Filter-Regeln sind sicherheitsrelevant und gehören in ein SIEM. Wazuh eignet sich dafür hervorragend – allerdings stehen viele Integrationen und “funktioniert nur teilweise”-Symptome nicht im Zeichen falscher Regex, sondern in der falschen Kopplung zwischen Decoder-Ausgabe hier weiterlesen

Einleitung Upgrades der zentralen Wazuh-Komponenten (Manager, Indexer, Dashboard) gehören zum regulären Betrieb einer SIEM-Plattform. In der Praxis führt ein Versionssprung jedoch häufig zu Verunsicherung, wenn Agents nach dem Upgrade plötzlich als Pending erscheinen, nicht mehr Active sind oder ganz aus dem Dashboard verschwinden. Dieser Artikel fasst eine umfangreiche Community-Diskussion zusammen und zeigt, wie Agent-Status nach hier weiterlesen

Einleitung In vielen Security-Use-Cases ist nicht jede erkannte Aktivität gleich relevant. Besonders bei Webangriffen, Authentifizierungsereignissen oder IDS-Alerts ist es oft sinnvoll, interne (private) Quell-IP-Adressen auszuschließen und den Fokus auf öffentliche, potenziell externe Angreifer zu legen. In Wazuh scheint dies auf den ersten Blick trivial – etwa durch einen Regex im <srcip>-Feld. In der Praxis führt hier weiterlesen