Slack

Einleitung Managed Security Service Provider stehen bei der Einführung von Wazuh vor einer grundlegenden Architekturentscheidung: Sollen alle Kunden über eine zentrale Wazuh-Umgebung überwacht werden, erhält jeder Kunde eine vollständig getrennte Installation oder werden dezentrale Kunden-Cluster über eine zentrale Oberfläche zusammengeführt? Die Entscheidung betrifft nicht nur Betriebskosten und Skalierbarkeit. Sie bestimmt auch, wie zuverlässig Kundendaten voneinander… hier weiterlesen

Einleitung Bei einem Wazuh-Agent-Upgrade auf Windows-Endpunkten wird die vorhandene Installation normalerweise über den Windows Installer entfernt oder direkt aktualisiert. Schlägt die Deinstallation jedoch mit dem MSI-Rückgabecode 1603 fehl, bleibt die alte Agent-Version registriert. Eine neuere Version kann anschließend häufig nicht sauber installiert werden. Im hier betrachteten Fall trat das Problem auf Windows-11-Systemen nach den kumulativen… hier weiterlesen

Einleitung Mit Wazuh 5.0 ändert sich die Methodik zur Entwicklung eigener Erkennungsregeln grundlegend. Während Wazuh 4.x benutzerdefinierte Regeln als XML-Dateien verarbeitet, setzt Wazuh 5.x auf YAML-Regeln mit Sigma-orientierter Erkennungslogik. Gleichzeitig werden Ereignisnormalisierung, Regelauswertung und die Verwaltung von Detection Content stärker voneinander getrennt. Für Betreiber umfangreicher Sysmon-Regelwerke bedeutet das: Bestehende XML-Regeln lassen sich nicht einfach in… hier weiterlesen

Einleitung Die Migration einer bestehenden Wazuh-Umgebung von einem zentralen Betriebsmodell zu einer mandantenfähigen Architektur betrifft nicht nur Benutzer, Rollen und Dashboards. Eine der größten Herausforderungen ist die eindeutige Zuordnung von Syslog-Ereignissen, die von Firewalls, Routern, Switches und anderen agentenlosen Geräten stammen. Werden diese Geräte direkt an den Syslog-Eingang des Wazuh Managers angebunden, fehlt eine belastbare… hier weiterlesen

Einleitung Security-Produkte und Log-Pipelines verpacken Ereignisse häufig mehrfach. Ein typisches Beispiel ist ein JSON-Dokument, das in einem seiner Felder wiederum eine Syslog-, CEF- oder Key-Value-Nachricht enthält. Für Wazuh entsteht dadurch eine zweistufige Struktur: Der integrierte JSON-Decoder verarbeitet zwar das äußere Dokument, interpretiert den Inhalt eines String-Feldes jedoch nicht automatisch als weiteres Logformat. Bei SentinelOne-Ereignissen kann… hier weiterlesen

Einleitung Windows-Eventlogs gehören zu den wichtigsten Datenquellen in einem SIEM. Sie liefern Informationen zu Authentifizierungen, Gruppenänderungen, Prozessstarts, Richtlinienänderungen und sicherheitsrelevanten Systemereignissen. In Wazuh werden solche Ereignisse normalerweise über die Windows-EventChannel-Integration des Wazuh-Agenten verarbeitet und anschließend durch die passenden Windows-Decoder und Rulesets analysiert. Komplexer wird es, wenn Windows-Events nicht direkt vom Wazuh-Agenten, sondern über eine bestehende… hier weiterlesen

Einleitung Die Kombination aus Wazuh File Integrity Monitoring und YARA ist ein wirksames Muster, um neu erstellte oder veränderte Dateien direkt auf Endpoints zu prüfen. Besonders Download-Verzeichnisse von Browsern sind sicherheitsrelevant, weil dort ausführbare Dateien, Archive, Office-Dokumente oder PDFs landen können, bevor sie durch weitere Prozesse geöffnet oder verteilt werden. Ausgangslage / Problemstellung In der… hier weiterlesen

Einleitung pfSense-Firewall-Logs sind eine wertvolle Datenquelle für Wazuh, insbesondere für die Erkennung blockierter Verbindungen, Portscans, lateral movement und unerwünschter Remote-Zugriffe. In der Praxis scheitert die Verarbeitung jedoch manchmal schon vor dem eigentlichen Decoder: Wenn pfSense-Logs im BSD-Syslog-Format ohne Hostnamen gesendet werden, verschiebt sich die Vorverarbeitung in Wazuh. Ausgangslage / Problemstellung Ein Wazuh Manager empfängt pfSense-Logs… hier weiterlesen

Einleitung Custom Branding im Wazuh Dashboard ist ein häufiger Wunsch in produktiven SIEM-Umgebungen. Eigene Logos, Titel und Ladebilder verbessern die Wiedererkennbarkeit der Plattform. Wenn Branding über die IP-Adresse korrekt angezeigt wird, über den DNS-Namen aber Standardlogos oder leere Platzhalter erscheinen, liegt die Ursache meist nicht im Branding selbst, sondern in URL-Auflösung, Routing oder statischer Dateiauslieferung.… hier weiterlesen

Einleitung UniFi kann System- und Sicherheitsereignisse im Common Event Format an ein SIEM senden. In Wazuh lassen sich diese CEF-Logs mit Custom Decodern und Regeln auswerten, um beispielsweise VPN-Verbindungen, Admin-Logins oder Konfigurationsänderungen sichtbar zu machen. Häufig funktioniert dabei zunächst das Decoding, während die darauf aufbauenden Regeln nicht auslösen. Die Ursache liegt meist in einer Abweichung… hier weiterlesen

Einleitung Die AWS-Integration von Wazuh liest CloudTrail-Logs aus einem S3-Bucket, verarbeitet sie über das AWS-Modul und erzeugt daraus Events für die Wazuh-Indizes. Wenn der Bucket erreichbar ist, im Dashboard aber keine CloudTrail-Daten erscheinen, liegt das Problem häufig nicht am Dashboard selbst, sondern an der vorgelagerten Erfassung: Wazuh findet keine neuen oder korrekt adressierbaren Logobjekte im… hier weiterlesen

Einleitung In Kubernetes-Umgebungen können Wazuh-Agenten sehr schnell große Mengen an Container- und Applikationslogs erfassen. Werden diese ungefiltert an den Wazuh Manager weitergeleitet, steigt die Last auf wazuh-analysisd, da Parsing, Decoding und Rule-Matching zentral auf Manager-Seite stattfinden. Besonders bei vielen Microservices führt Log-Noise daher nicht nur zu unnötigen Events, sondern auch zu messbaren Performance-Problemen. Ausgangslage /… hier weiterlesen

Einleitung Wireless-Infrastruktur erzeugt sicherheitsrelevante Logs zu Access Points, WLANs, Authentifizierungen, Client-Verbindungen und VLAN-Zuordnungen. Für Security Monitoring mit Wazuh sind diese Daten besonders wertvoll, weil sie Hinweise auf neue Clients, fehlgeschlagene Authentifizierungen, verdächtige SSIDs oder ungewöhnliche Client-IP-Zuweisungen liefern können. Bei Ruckus-Logs zeigt sich jedoch schnell: Nicht jedes Logformat lässt sich mit einem einzigen Decoder sauber abdecken.… hier weiterlesen

Einleitung Die Analyse von Sysmon-Logs gehört zu den zentralen Bausteinen moderner Endpoint Detection und SIEM-Strategien. Besonders interessant ist dabei Event ID 1 (Process Creation), da hier häufig CommandLines mit potenziell schädlichen Verbindungen oder Indicators of Compromise (IoCs) enthalten sind. Der Wunsch, IP-Adressen direkt aus diesen Feldern zu extrahieren und in Wazuh weiterzuverarbeiten, ist daher naheliegend… hier weiterlesen

Einleitung Bei der Integration von AWS CloudTrail in Wazuh erwarten viele Administratoren, dass jedes CloudTrail-Ereignis automatisch als Alert im Wazuh Dashboard erscheint. In der Praxis ist das nicht immer der Fall. Wazuh verarbeitet CloudTrail-Logs zwar aus S3, aber die Standardregeln entscheiden, welche Events tatsächlich als Alerts erzeugt und indexiert werden. Ausgangslage / Problemstellung Nach der… hier weiterlesen

Einleitung Scan-Tools erzeugen häufig umfangreiche JSON-Dateien mit Metadaten, Assets, Findings, DNS-Daten, HTTP-Ergebnissen oder Geolocation-Informationen. Für Wazuh ist dabei nicht nur entscheidend, ob die Daten syntaktisch korrektes JSON sind, sondern auch, wie sie strukturiert sind. Ein einzelnes großes JSON-Objekt mit verschachtelten Arrays ist für die Logverarbeitung deutlich schlechter geeignet als einzelne, zeilenbasierte Events. Ausgangslage / Problemstellung… hier weiterlesen

Einleitung Sysmon-basierte Detection Rules in Wazuh liefern wertvolle Telemetrie für sicherheitsrelevante Dateioperationen. Gleichzeitig erzeugen sie in der Praxis häufig False Positives, insbesondere bei legitimen Betriebssystemmechanismen. Ein klassisches Beispiel ist PowerShells Execution Policy Test, bei dem temporäre Dateien im Benutzer-Temp-Verzeichnis erstellt werden. Ohne gezielte Filterung führen diese Events zu unnötigem Alert-Noise auf hohem Severity-Level. Ausgangslage /… hier weiterlesen