Wir verfolgen den internen Wazuh Slack-Channel aufmerksam und bereiten besonders interessante Diskussionen mithilfe von KI als Blogbeiträge auf. Da Slack-Unterhaltungen nach 90 Tagen automatisch gelöscht werden, sichern wir so wertvolles Wissen langfristig und machen es für alle jederzeit zugänglich.
-
Wazuh Indexer „Circuit Breaking Exception“: Warum dein Cluster plötzlich stehenbleibt – und wie du es sauber behebst
Suresh und Bhanu meldeten ein Problem, das in vielen produktiven Wazuh-Installationen auftaucht:Plötzlich ist das Dashboard nicht erreichbar, Queries schlagen fehl – und der Wazuh-Indexer meldet: Ein klassischer Fall von: Zu wenig Heap – zu viel Arbeit für den Indexer OpenSearch (bzw. der Wazuh-Indexer) schützt sich selbst vor Out-of-Memory-Situationen. Wenn eine Operation (z. B. eine Suche,… hier weiterlesen
-
Wazuh Migration & Wiederherstellung
RBAC, Rollen, User und Agent-Gruppen korrekt sichern und wiederherstellen Einleitung Nach einer Neuinstallation oder Migration eines Wazuh-Clusters stellt sich häufig heraus, dass zwar Agenten, Indizes und Logs wieder vorhanden sind – aber sicherheitsrelevante Metadaten fehlen. Dazu zählen insbesondere: Dieser Artikel erklärt wo diese Informationen gespeichert sind, wie sie korrekt gesichert werden und welche Restore-Strategien zukunftssicher… hier weiterlesen
-
Azure-Logs in Wazuh: Warum das Wodle in Wellen arbeitet – und wie du Spikes, Flooding & Index-Hygiene in den Griff bekommst
Tim hat in der Wazuh-Community ein klassisches Szenario geschildert: Dazu kamen zwei zentrale Fragen: Schauen wir uns an, was im Thread herausgearbeitet wurde – und was du davon in deinem eigenen Setup nutzen kannst. 1. Setup: Azure Storage + azure-logs Wodle Tim nutzt das azure-logs Wodle in der Storage-Variante (nicht Log Analytics): Wichtige Punkte: Er… hier weiterlesen
-
Custom Fortigate-Decoders und -Rules nach Linux-Migration in Wazuh: „Permission denied“ sauber beheben und Updatesicher deployen
Einleitung Bei einer Migration des Wazuh-Servers (z. B. von CentOS 8 auf Rocky Linux) sind Custom Decoders und Rules oft der Teil, der am schnellsten „still“ kaputtgeht: Die Dateien sind zwar kopiert, aber Wazuh lädt sie nicht – und im Dashboard erscheinen kryptische Meldungen wie „No decoder was returned (1502)“ oder „No rule was returned… hier weiterlesen
-
SFTP-Logs mit Wazuh decodieren: Vom Regex-Monster zur eleganten Ein-Zeilen-Lösung
Costantino wollte SFTP-Transfers auf einem Linux-Server sauber in Wazuh auswerten.Die Logs sehen in etwa so aus: Mit anderen Worten: Costantino wollte daraus u. a. folgende Felder holen: Sein erster Ansatz: sehr komplexe Regexe mit Timestamp am Anfang und jede Menge Child-Decoder. Ergebnis: Logs wurden nicht oder nur teilweise korrekt decodiert. Schauen wir uns an, warum… hier weiterlesen
-
Wazuh-Agenten plötzlich offline: Wie eine fehlerhafte Syslog-Konfiguration die gesamte Agent-Kommunikation lahmlegt
Einleitung Stabile Agent-Konnektivität ist die Grundlage jeder Wazuh-Installation. Wenn plötzlich alle Agenten im Dashboard als „disconnected“ erscheinen, obwohl Systeme laufen und Benutzer aktiv sind, deutet dies meist auf ein zentrales Konfigurations- oder Kommunikationsproblem hin. Besonders kritisch wird es, wenn mehrere Funktionen – etwa Agent-Kommunikation und Syslog-Empfang – auf derselben Schnittstelle konfiguriert werden. Dieser Beitrag analysiert… hier weiterlesen
-
Wazuh High Availability ohne Load-Balancing: Was wirklich möglich ist bei Indexer, Manager und Dashboard
Einleitung High Availability (HA) in SIEM- und XDR-Umgebungen wird oft mit “mehr Knoten” gleichgesetzt. In der Praxis unterscheiden sich jedoch Datenebene, Kontroll-/Konfigurationsebene und UI-Schicht deutlich darin, wie (und ob) sie sich hochverfügbar betreiben lassen. In Wazuh ist das besonders relevant, weil der Wazuh Manager (Server) neben Event-Ingestion auch zentrale Steuerfunktionen übernimmt, während der Wazuh Indexer… hier weiterlesen
-
CrowdStrike-Logs in Wazuh: Wenn Alerts im Archiv sichtbar sind, aber wegen full_log nie im Index landen
Mah Wen Qiang wollte CrowdStrike-Logs sauber in Wazuh integrieren: „Crowdstrike alert – User authentication success – UserId: …“ Im archives.json ist das Event da – mit sauberem JSON-Decoder und data.metadata / data.event Feldern. Aber:Im Wazuh „Discover“/„Kibana“/„OpenSearch Dashboards“ taucht der Alert nicht auf.Gleichzeitig meldet Filebeat: mapper_parsing_exception … failed to parse field [full_log] of type [text] Später… hier weiterlesen
-
Wazuh Dashboard Fehler „Socket ‚auth‘ cannot receive connections“ in 4.11.2 beheben: API erreichbar, aber Manager-Authd/Socket blockiert
Einleitung Wenn das Wazuh Dashboard zwar lädt, aber bei API-Aufrufen mit [WazuhError]: API error: ERR_BAD_RESPONSE – Error connecting with socket: Socket ‚auth‘ cannot receive connections abbricht, ist die Lage oft trügerisch: Der Wazuh API-Port (55000) kann erreichbar sein, während intern eine Manager-Komponente nicht verfügbar ist. Gerade bei Single-Node-Installationen führt das schnell zu einer Situation, in… hier weiterlesen
-
Zeek + Wazuh: Wie man JSON-Felder ohne Konflikte ingestiert – inklusive sauberer Full-Parse-Lösung über den Indexer-Pipeline
Zeek erzeugt strukturiertes JSON – und das ist großartig.Aber wenn man diese Logs direkt über den Wazuh Agent ins System sendet, stößt man sehr schnell auf ein Problem: Die Felder unter id.* kollidieren mit OpenSearch-Mappings Beispiel-Zeek-Log: OpenSearch sagt dann: object mapping for [id] tried to parse field [orig_h] as type keyword, but found conflicting type… hier weiterlesen
-
Wazuh-Indexer im Status „yellow“: Wenn Replica-Shards deinen Single-Node-Cluster blockieren
Ein „yellow“ Cluster-Status im Wazuh-Indexer (OpenSearch) sorgt oft für Unruhe: Läuft noch alles? Gehen Daten verloren? Muss ich mir Sorgen machen? Im Fall von Johan Ekenlycka war die Situation typisch für viele All-in-one- oder Single-Node-Wazuh-Setups:Der Cluster lief, aber: Schauen wir uns an, was genau passiert ist – und wie das Problem sauber gelöst wurde. 1.… hier weiterlesen
-
SentinelOne Activity Alerts in Wazuh: Warum Regeln nicht feuerten – und wie das Problem sauber gelöst wurde
Use Case:Ein Community-Mitglied wollte neben den SentinelOne Threat Alerts auch Activity Alerts per API in Wazuh integrieren – basierend auf dem offiziellen Wazuh-Blog zur SentinelOne-Integration. Die Logs wurden korrekt abgeholt und in separate JSON-Dateien geschrieben, dennoch wurden Activity Alerts weder im Dashboard angezeigt noch durch Custom Rules erkannt. Ausgangslage Setup Symptome Root Cause 1: Indexing-… hier weiterlesen
-
Wazuh HAProxy Helper: Master-Node gezielt vom Agent-Load (Port 1514) ausschließen
Ausgangssituation In großen Wazuh-Umgebungen (hier: >6.000 Agents) ist es Best Practice, den Master-Node möglichst schlank zu halten und primär für Agent-Registrierungen (Port 1515) sowie Cluster-Koordination zu nutzen. Der Nutzer hatte bereits erfolgreich: 👉 Die einzige offene Frage:Wie kann verhindert werden, dass der Master-Node vom HAProxy Helper automatisch als Backend für Agent-Traffic (Port 1514) verwendet wird?… hier weiterlesen
-
Wazuh & Windows EventChannel: Warum du den Decoder „windows_eventchannel“ nicht findest – und wie EventChannel-Events wirklich funktionieren
Windows PowerShell- oder Security-Events aus dem Microsoft-Windows-PowerShell/Operational Channel verhalten sich in Wazuh auf den ersten Blick merkwürdig: Warum ist das so? Die Antwort steckt tief in der Architektur von Wazuh. Dieser Artikel erklärt: 1. Warum du den Decoder „windows_eventchannel“ nicht findest Wazuh unterscheidet zwischen: Der Windows EventChannel-Decoder gehört zur zweiten Kategorie. Jakub Pacowski erklärt es… hier weiterlesen
-
Wazuh + GCP: „Received 0 messages“ beim GCS-Bucket – warum Audit-Logs (JSON) nicht ankommen und was stattdessen funktioniert
Ausgangslage Ein Wazuh-Cluster auf v4.14.1 verarbeitet GCP-Logs aus einem Google Cloud Storage Bucket. Die Dateien liegen im Bucket vor (sichtbar, korrekter Inhalt), der Wazuh-Log zeigt auch „Processing …“, aber am Ende steht: INFO: Received 0 messages Beispiel aus dem Log: Im Bucket liegen Cloud Audit Logs als JSON (z. B. cloudaudit.googleapis.com/activity). Warum das passiert (Root… hier weiterlesen
-
Azure-Felder wie data.activityDateTime in echte Datumsfelder für Wazuh-Visualisierungen umwandeln
Wer Azure-Logs über das Wazuh Azure-Modul einbindet, kennt das Problem:Viele Zeitstempel kommen zwar wie ein Datum aus, werden vom Wazuh Indexer aber nur als String gespeichert. Ein typisches Beispiel: In der Oberfläche sehen diese Werte korrekt aus – aber in Visualisierungen, Timelines, Aggregationen oder Range-Filtern sind sie nicht als Datum nutzbar, weil der Feldtyp nicht… hier weiterlesen
-
Wazuh Manager Cluster über WAN? – Ja, das geht! (Aber nur für Manager, nicht für Indexer)
Viele Unternehmen betreiben Wazuh in der Cloud – etwa in AWS – möchten aber gleichzeitig auch on-prem Komponenten integrieren.Genau das plante Obeyd:Ein großer Wazuh-Cluster in AWS (5 Manager, 9 Indexer, 1 Dashboard) – und zusätzlich ein weiterer Manager-Worker in einem entfernten On-Prem-Standort. Die Frage:Kann ein Wazuh Manager Cluster stabil funktionieren, wenn ein Worker über WAN… hier weiterlesen
-
AWS WAF + Wazuh: Wie man „verflachte“ JSON-Header wieder brauchbar macht
Wer AWS WAF-Logs mit Wazuh auswertet, stößt früher oder später auf ein nerviges Detail:Arrays von Objekten werden vom JSON-Decoder „plattgemacht“ – und plötzlich ist die Zuordnung von Header-Name zu Header-Wert kaputt. Genau das passierte Prathamesh Bakliwal, der WAF-Logs aus CloudWatch über das Wazuh-aws-s3-Modul einspeist. Die Felder waren zwar dekodiert – aber nicht so, wie er… hier weiterlesen
-
Wazuh Indexer „yellow“ wegen unassigned Shards – was tun?
Im Thread von Ewin Loppe ging es um ein typisches Thema in Wazuh-/OpenSearch-Umgebungen:Der Cluster-Status ist gelb, einige Shards sind unassigned, und Dev Tools werfen plötzlich 403 / security_exception. Schauen wir uns an, warum das passiert – und wie man es sauber behebt. 1. Ausgangslage: Cluster „yellow“ und unassigned Shards Ewin hat den Clusterzustand geprüft: Ausgabe… hier weiterlesen
-
WatchGuard-Firewall-Logs in Wazuh: Von „No decoder matched“ zur sauberen, voll geparsten Analyse
Wer WatchGuard-Firewall-Logs über einen Syslog-Collector in Wazuh einspeist, trifft schnell auf diese frustrierende Meldung: No decoder matched Genau das ist Nikola passiert:Die Logs der WatchGuard-Firewall landen per rsyslog → lokale Datei → Wazuh-Agent → Manager im System, tauchen in archives.log auf – aber keiner der gefundenen WatchGuard-Decoder von GitHub greift. In diesem Artikel schauen wir… hier weiterlesen