Slack

Einleitung In Wazuh ist der reine Eingang eines Syslog-Streams noch kein Beleg dafür, dass die Daten auch inhaltlich ausgewertet werden. Gerade bei Netzwerkgeräten wie Netgear-Switches zeigt sich häufig ein typisches Muster: Die Logs landen per rsyslog in einer Datei, der Wazuh-Agent liest diese Datei korrekt ein, im Dashboard tauchen aber keine verwertbaren Events oder Alerts… hier weiterlesen

Einleitung Wenn Wazuh in großen Umgebungen plötzlich nur einen Teil der Agents im Vulnerability-Index anzeigt, liegt die Ursache oft nicht im CVE-Feed selbst und auch nicht primär im Indexer-Cluster. Die Vulnerability Detection in Wazuh arbeitet auf Basis der Syscollector-Inventardaten der Agents. Fehlen Paketdaten oder kommen sie verspätet bzw. unvollständig am Manager an, erscheinen betroffene Endpunkte… hier weiterlesen

Einleitung Wazuh ist darauf ausgelegt, kontinuierliche Ereignisströme zu verarbeiten – nicht statische Datenbestände. In der Praxis entsteht jedoch häufig die Anforderung, bereits vorhandene Logdateien nachträglich in Wazuh zu integrieren, etwa bei Migrationen, forensischen Analysen oder beim initialen Onboarding neuer Datenquellen. Gerade bei JSON-Logs im NDJSON-Format scheint dies auf den ersten Blick trivial: Datei ablegen, Monitoring… hier weiterlesen

Einleitung In vielen Wazuh-Umgebungen endet die Erkennung nicht beim Alerting. Sobald Wazuh belastbare Indicators of Compromise wie Quell-IP-Adressen, Ziel-IP-Adressen oder andere verifizierte Netzwerkindikatoren erkennt, entsteht schnell der Wunsch, diese Informationen unmittelbar für Containment-Maßnahmen auf der Firewall zu nutzen. Genau an dieser Stelle ist die Integration mit Palo Alto Networks besonders interessant: Die Firewall kann dynamische… hier weiterlesen

Einleitung Wenn der Wazuh Indexer einen gelben Cluster-Status zeigt und ein sensibler Systemindex wie .opendistro_security über Tage im Zustand Recovery bleibt, wirkt das schnell wie ein Sicherheits- oder Datenintegritätsproblem. In vielen Fällen ist die Ursache aber deutlich banaler: Nicht ein defekter Security-Index blockiert den Cluster, sondern die Shard-Zuweisung wird durch Recovery-Grenzwerte gedrosselt. OpenSearch unterscheidet klar… hier weiterlesen

Einleitung Die Anpassung von Feldtypen im Wazuh Indexer ist ein häufiger Anwendungsfall, insbesondere wenn numerische Auswertungen oder Aggregationen benötigt werden. Ein klassisches Beispiel ist die Umwandlung eines Feldes wie data.count von string zu integer, um es in Dashboards oder für Metriken nutzbar zu machen. Was auf den ersten Blick wie eine einfache Mapping-Anpassung erscheint, kann… hier weiterlesen

Einleitung Die Erstellung eigener Decoder gehört zu den zentralen Erweiterungsmöglichkeiten von Wazuh. Gerade bei Tools wie Fail2ban ist eine saubere Log-Parsing-Logik essenziell, um sicherheitsrelevante Ereignisse wie gebannte IP-Adressen korrekt zu erkennen und weiterzuverarbeiten. In der Praxis treten dabei jedoch häufig XML-Syntaxfehler oder unerwartetes Decoder-Verhalten auf, obwohl die regulären Ausdrücke scheinbar korrekt sind. Dieser Beitrag zeigt… hier weiterlesen

Einleitung Wer Wazuh-Daten langfristig sichern und gleichzeitig alte Indizes automatisiert aus dem Cluster entfernen will, landet schnell bei zwei eng verwandten, aber funktional getrennten Mechanismen: Snapshot Management für Backups und Index State Management (ISM) für Aufbewahrung und Löschung. Genau an dieser Stelle entsteht in der Praxis häufig Verwirrung, weil in der Wazuh-Oberfläche unter der State-Definition… hier weiterlesen

Einleitung Backups von Security-Daten sind kein Nice-to-have, sondern ein zwingender Bestandteil jeder SIEM-Architektur. Mit dem Wazuh Indexer (basierend auf OpenSearch) stehen dafür leistungsfähige Mechanismen zur Verfügung – allerdings nicht immer dort, wo man sie intuitiv erwartet. Besonders häufig entsteht Verwirrung rund um Index State Management (ISM), Snapshot Policies und die unterschiedlichen Wazuh-Index-Typen. Dieser Artikel erklärt,… hier weiterlesen

Einleitung Browser-Erweiterungen sind ein oft unterschätzter Teil der Angriffsfläche. Gerade in Unternehmensumgebungen können unscheinbare Add-ons Daten abgreifen, den Browser manipulieren, unerwünschte Werbung einschleusen oder als Persistenzmechanismus dienen. Mit den erweiterten Inventory-Funktionen von Wazuh lassen sich Browser-Erweiterungen zentral erfassen, im Dashboard sichtbar machen und über benutzerdefinierte Regeln gegen eine Negativliste prüfen. Wazuh speichert Browser-Extension-Inventardaten in eigenen… hier weiterlesen

Einleitung Die Überwachung von USB-Geräten ist in Wazuh ein typischer Anwendungsfall für Endpoint Visibility, Datenabflussprävention und die Erkennung unerlaubter Peripherie. Gerade in Windows-Umgebungen wird häufig versucht, autorisierte Datenträger über CDB-Listen zu erlauben und unbekannte Geräte als verdächtig zu markieren. In der Praxis scheitert diese Logik jedoch oft nicht an Wazuh selbst, sondern an einer falschen… hier weiterlesen

Einleitung In verteilten Wazuh-Deployments (Manager/Cluster, Indexer, Dashboard und Load Balancer auf getrennten Hosts) ist die Verbindung zwischen Wazuh Dashboard und Wazuh Server API eine der häufigsten Fehlerquellen. Typische Symptome sind „Wazuh server API seems to be down“, HTTP 401 sowie ERROR3099 – Invalid credentials. Der Effekt ist gravierend: Ohne API-Verbindung kann das Dashboard keine Agenten-,… hier weiterlesen

Einleitung Wenn ein Wazuh-Cluster plötzlich keine oder nur noch sporadisch Alerts im Dashboard anzeigt, wirkt das zunächst wie ein Problem auf den Managern oder bei Filebeat. In der Praxis liegt die Ursache jedoch sehr häufig im Wazuh Indexer (OpenSearch): Sobald Shards nicht mehr alloziert werden können oder neue Indizes nicht mehr sauber angelegt werden, bricht… hier weiterlesen

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