Slack

Einleitung Nach einem Upgrade des Wazuh Managers auf Version 4.14.7 kann beim Aufruf des Kommandozeilenwerkzeugs agent_upgrade eine Python-Warnung erscheinen: Die Meldung wirkt auf den ersten Blick wie ein Fehler im Agent-Upgrade-Prozess. Tatsächlich handelt es sich jedoch um eine Deprecation-Warnung aus der mit Wazuh ausgelieferten Python-Laufzeitumgebung. Das eigentliche CLI-Werkzeug und der Upgrade-Mechanismus können weiterhin ordnungsgemäß funktionieren.… hier weiterlesen

Einleitung In produktiven Wazuh-Umgebungen entstehen regelmäßig legitime Ereignisse, die technisch auf Erkennungsregeln passen, aber keinen Sicherheitsvorfall darstellen. Typische Beispiele sind Schwachstellenscanner, Monitoring-Systeme, interne Administrationsserver oder autorisierte Penetrationstests. Solche Quellen sollen häufig von bestimmten Alarmen ausgenommen werden. Eine Ausnahme in einer einzelnen Wazuh-Regel bedeutet jedoch nicht automatisch, dass das Ereignis vollständig ignoriert wird. Passt dasselbe Ereignis… hier weiterlesen

Einleitung Die File Integrity Monitoring (FIM)-Funktion von Wazuh gehört zu den wichtigsten Sicherheitsmechanismen für die Erkennung unerwarteter Dateiänderungen. Gerade auf Endgeräten lassen sich damit Manipulationen an Konfigurationsdateien, Autostart-Mechanismen oder sicherheitsrelevanten Verzeichnissen frühzeitig erkennen. Wer Wazuh erstmals auf macOS-Systemen einsetzt, stößt jedoch häufig auf Warnmeldungen, sobald Echtzeitüberwachung (realtime) aktiviert wird. Diese Meldungen wirken zunächst wie ein… hier weiterlesen

Einleitung Strukturierte JSON-Logs sind eine wichtige Grundlage für zuverlässige Erkennungsregeln, Korrelationen und forensische Analysen in Wazuh. Felder wie level, userId, requestId, module, method oder url lassen sich wesentlich präziser auswerten als unstrukturierte Textnachrichten. Beim direkten Einlesen der Dateien des Docker-Logging-Treibers json-file entsteht jedoch häufig ein unerwartetes Problem: Docker speichert die eigentliche Anwendungsmeldung innerhalb eines äußeren… hier weiterlesen

Einleitung Die Linux-Audit-Infrastruktur wird häufig von mehreren Sicherheitskomponenten gleichzeitig genutzt. Neben Wazuh können beispielsweise zusätzliche SIEM-Forwarder, Compliance-Werkzeuge oder forensische Audit-Plugins dieselben Ereignisse verarbeiten. In einer solchen Multi-Plugin-Architektur darf der Ausfall eines einzelnen Verbrauchers nicht die gesamte Audit-Pipeline beeinträchtigen. Genau dieses Fehlerbild kann jedoch entstehen, wenn Wazuh Whodata im Audit-Modus verwendet wird: Bleibt der Wazuh-seitige UNIX-Socket… hier weiterlesen

Einleitung Bei der Bewertung von Schwachstellen in Linux-Umgebungen reicht ein Vergleich der installierten Softwareversion mit der Upstream-Versionsangabe häufig nicht aus. Distributionen pflegen eigene Pakete, übernehmen Sicherheitspatches per Backport und veröffentlichen distributionsspezifische Statusinformationen. Dadurch kann eine vermeintlich eindeutige Aussage wie „ab Version 1.8.19 behoben“ im konkreten Betriebssystemkontext zu einem anderen Ergebnis führen. Ein typisches Beispiel ist… hier weiterlesen

Einleitung Die Ansicht Alerting → Alerts → Alerts by triggers im Wazuh Dashboard wird häufig mit den eigentlichen Wazuh-Sicherheitsalerts verwechselt. Technisch handelt es sich jedoch um zwei unterschiedliche Datenarten mit jeweils eigener Speicherung und Aufbewahrungslogik. Die Indizes wazuh-alerts-* enthalten Ereignisse, die der Wazuh Manager anhand seiner Decoder und Regeln erzeugt. Die Einträge unter „Alerts by… hier weiterlesen

Einleitung Mit Wazuh 5.x vollzieht die Plattform einen grundlegenden Architekturwechsel. Administratoren, die von einer bestehenden Wazuh-4.x-Umgebung migrieren möchten, müssen sich darauf einstellen, dass die Migration nicht mit einem klassischen Versionsupgrade vergleichbar ist. Stattdessen werden Konfiguration, Regelverwaltung und Teile der Datenanalyse neu organisiert. Dieser Artikel erläutert die wichtigsten Unterschiede zwischen Wazuh 4.x und 5.x, beschreibt den… hier weiterlesen

Einleitung Dashboards eignen sich gut zur visuellen Kontrolle von Sicherheitsereignissen. Sie ersetzen jedoch keine automatisierte Erkennung. Wer täglich manuell prüft, ob ein Host mehr oder weniger Events als am Vortag erzeugt hat, übersieht zwangsläufig Veränderungen oder bewertet normale Schwankungen als Sicherheitsvorfall. In einer Wazuh-Umgebung können solche Abweichungen grundsätzlich auf zwei Arten erkannt werden: Beide Verfahren… hier weiterlesen

Einleitung Eine gemeinsam genutzte Wazuh-Infrastruktur kann für Managed-Security-Provider und Betreiber mehrerer kleiner Umgebungen wirtschaftlich attraktiv sein. Zentrale Komponenten, ein gemeinsames Regelwerk und eine konsolidierte Indexer-Infrastruktur reduzieren Betriebsaufwand und Ressourcenverbrauch. Technisch muss dabei jedoch zwischen zwei grundsätzlich verschiedenen Ebenen unterschieden werden: der Ereignisanalyse auf dem Wazuh-Manager und der späteren Speicherung im Wazuh-Indexer. Eine saubere Trennung von… hier weiterlesen

Einleitung Eine hohe Anzahl erkannter Felder in einem Wazuh-Datenbestand wirkt auf den ersten Blick wie ein unmittelbar bevorstehendes Indexierungsproblem. Besonders kritisch erscheint die Situation, wenn das Wazuh Dashboard mehr als 10.000 Felder meldet, während im Index-Template ein index.mapping.total_fields.limit von 10.000 konfiguriert ist. Die beiden Werte lassen sich jedoch nicht direkt miteinander vergleichen. Das Mapping-Limit gilt… hier weiterlesen

Einleitung Bei der Integration von AWS Client VPN-Verbindungsprotokollen in Wazuh kann ein irreführendes Fehlerbild entstehen: Der Decoder verarbeitet das Ereignis korrekt, die benutzerdefinierte Regel erzeugt einen Alert und der Eintrag erscheint sowohl in alerts.json als auch in alerts.log. Im Wazuh Dashboard bleibt das Ereignis jedoch unsichtbar. In diesem Fall liegt das Problem nicht bei der… hier weiterlesen

Einleitung Die Security Configuration Assessment von Wazuh ist ein wirkungsvolles Werkzeug, um Fehlkonfigurationen, unzureichende Härtung und Abweichungen von Sicherheitsstandards auf Endpoints sichtbar zu machen. Die Aussagekraft der Ergebnisse hängt jedoch unmittelbar von der verwendeten SCA-Policy ab. Stimmen Betriebssystemversion, Benchmark-Version und technische Prüfregeln nicht überein, können formal plausible Ergebnisse entstehen, die nicht dem tatsächlich geforderten Sicherheitsstandard… hier weiterlesen

Einleitung Die Überwachung der Arbeitsspeicherauslastung gehört zu den klassischen Aufgaben eines Infrastruktur-Monitorings. In einer Wazuh-Umgebung entsteht dabei häufig der Wunsch, nicht jede Messung als Ereignis zu übertragen, sondern nur dann einen Alert zu erzeugen, wenn ein definierter Schwellwert überschritten wird. Besonders relevant wird die Architekturentscheidung, wenn die Überwachung ausschließlich für eine bestimmte Agent-Gruppe gelten soll.… hier weiterlesen

Einleitung Cisco-IOS-Geräte können Syslog-Zeitstempel in unterschiedlichen Varianten ausgeben: mit oder ohne Jahr, Zeitzone und Millisekunden. Für Wazuh ist diese Formatvielfalt relevant, weil bereits eine kleine Abweichung im Zeitstempel dazu führen kann, dass der übergeordnete Cisco-IOS-Decoder nicht greift. Das Ereignis wird in diesem Fall zwar vom Wazuh Manager empfangen, aber nicht als Cisco-IOS-Meldung strukturiert. Felder wie… hier weiterlesen

Einleitung Die Qualität einer Schwachstellenerkennung hängt unmittelbar von der Aktualität ihrer Vulnerability-Informationen ab. Selbst wenn Wazuh die installierten Betriebssysteme, Pakete und Anwendungen korrekt inventarisiert, können neue CVEs erst erkannt werden, wenn dem Wazuh Manager ein aktueller Vulnerability-Feed zur Verfügung steht. In abgeschotteten oder stark reglementierten Umgebungen entstehen dabei häufig Missverständnisse zwischen eingeschränktem Internetzugriff und einem… hier weiterlesen

Einleitung Snapshots sind ein zentraler Bestandteil einer belastbaren Backup-, Recovery- und Migrationsstrategie für den Wazuh Indexer. Sie ermöglichen es, Alert-Indizes, Archivdaten und weitere im Indexer gespeicherte Informationen nach einem Ausfall wiederherzustellen oder in einen neuen Cluster zu übertragen. Bei der Wiederherstellung eines Snapshots kann jedoch eine Besonderheit des OpenSearch Security Plugins zu Problemen führen: Enthält… hier weiterlesen

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