Wazuh-Blog

Einleitung Netzwerk- und Controller-Plattformen wie iMaster NCE liefern Alarmmeldungen häufig in proprietären Formaten, die sich nicht „out of the box“ in ein SIEM-Regelwerk integrieren lassen. Wazuh ist hier stark, weil sich Logquellen über Custom Decoders schnell strukturieren lassen – erst damit werden aus Textzeilen belastbare Felder für Korrelation, Dashboards und Alarmregeln. In diesem Beitrag zeige … Weiterlesen

Einleitung Geräte- und Storage-Logs landen in Wazuh häufig als „Raw Syslog“: ein Syslog-Präfix (Timestamp/Tag) plus ein herstellerspezifischer Payload. Damit daraus verwertbare Alerts entstehen, braucht es zwei Dinge: Decoder, die relevante Felder extrahieren (User, Quell-IP, Ergebnis, Error-Code), und Rules, die diese Felder bewerten. Wazuh liefert dafür eine klare XML-Syntax und unterstützt neben OSRegex auch PCRE2 – … Weiterlesen

Einleitung In großen Healthcare-Umgebungen (HIPAA/JCIA/ISO) ist Wazuh nicht nur „ein weiteres SIEM“, sondern ein Betriebs- und Compliance-System: hohe EPS, lange Retention, Auditierbarkeit, HA und vorhersagbare Performance sind entscheidend. Technisch steht und fällt das Design mit einer sauberen Trennung der Verantwortlichkeiten zwischen Wazuh Manager-Cluster (Analyse/Regeln/API), Wazuh Indexer (OpenSearch-Fork) für Storage/Suche und einem Dashboard für Visualisierung. Die … Weiterlesen

TL;DR Wenn das Office365-Modul sauber startet und du O365-Events in alerts.json findest, aber im Dashboard nichts siehst, ist die Integration meist nicht das Problem – sondern der Transport in den Indexer (typisch: Filebeat → Indexer). In diesem Fall war die Ursache ein TLS-Zertifikat ohne passenden SAN für die private IP (10.0.1.4): Das Zertifikat war nur … Weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Wazuh ist primär als Realtime-SIEM/XDR-Plattform konzipiert. Entsprechend sammelt der Agent standardmäßig nur neue Logeinträge, die ab dem Start des Logcollectors entstehen. In der Praxis entsteht jedoch häufig der Bedarf, bereits vorhandene Logs (z. B. vor der Agent-Installation oder während einer Downtime) nachträglich zu analysieren – etwa im Rahmen einer forensischen … Weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Wenn Wazuh-Agenten keine Shared Configs oder Active-Response-Kommandos mehr erhalten, ist das kein „Komfortproblem“, sondern ein Sicherheitsrisiko: Policies, Detektionslogik und Reaktionen kommen nicht mehr zuverlässig am Endpoint an. In der Praxis äußert sich das häufig über wazuh-remoted-Meldungen wie „Not enough buffer space“ und „Package dropped“. Der reflexartige Ansatz, remoted.send_buffer_size hochzusetzen, hilft … Weiterlesen

SentinelOne in Wazuh: Warum JSON-Events im Dashboard fehlen, Logtest „nicht erkannt“ meldet und wie du Parsing, Filebeat-Pipeline und Korrelation stabil bekommst Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Die SentinelOne-Integration ist in Wazuh ein klassischer „Datenpipeline“-Use-Case: Events kommen per API oder Syslog an, werden lokal als JSON oder CEF geschrieben, anschließend von Wazuh ingestiert, decodiert, in den … Weiterlesen

Einleitung Wenn in einer Wazuh-Cluster-Architektur plötzlich nur noch Events von einem Worker im Dashboard auftauchen, wirkt es auf den ersten Blick wie ein Indexer-Problem. In der Praxis liegt die Ursache häufig an einer Kette aus Nebenwirkungen: ein kurzfristig voller Datenträger auf dem betroffenen Worker, ein danach „gesund“ wirkender Filebeat – und trotzdem keine ingestierten Dokumente. … Weiterlesen