1. Wazuh 5.0 im Kontext: Die nächste Generation der Open-Source-Sicherheit
Wazuh hat sich in den letzten Jahren als ernstzunehmende Alternative zu kommerziellen SIEM- und XDR-Lösungen etabliert. Die aktuelle Version 4.14.x ist stabil und wird kontinuierlich mit kleineren Security- und Funktions-Updates weiterentwickelt. Mit dem kommenden Release Wazuh 5.0 steht jedoch ein großer Sprung bevor – und dieser bringt architektonische Änderungen, die weit über ein normales Minor-Release hinausgehen.
Wazuh 5.0 befindet sich derzeit in aktiver Entwicklung. Einen offiziellen Veröffentlichungstermin hat Wazuh Inc. noch nicht kommuniziert. Der Fortschritt lässt sich öffentlich über das GitHub-Projektboard und die Pre-Releases verfolgen. Für Unternehmen, die heute produktiv Wazuh einsetzen oder eine Einführung planen, ist jetzt der richtige Zeitpunkt, sich mit den anstehenden Änderungen vertraut zu machen – denn einige davon betreffen grundlegende Komponenten der Architektur.
2. Die wichtigsten Neuerungen im Überblick
Wazuh 5.0 ist kein reines Bugfix-Release. Die Entwickler räumen mit vielen Altlasten auf, vereinfachen die Architektur und führen strategisch wichtige neue Funktionen ein. Die Highlights:
- Cluster-Betrieb wird zum Standardmodell
- Filebeat wird als Log-Shipper abgelöst
- Umfassende Überarbeitung des Rollen- und Rechtekonzepts (RBAC)
- Deutlich erweiterte Threat-Intelligence-Plattform Wazuh CTI
- Entfernung zahlreicher Legacy-Komponenten und Daemons
- Windows-Agent nur noch als MSI-Paket
- Neuer Synchronisations-Algorithmus für die Vulnerability Detection
Schauen wir uns die wichtigsten Punkte im Detail an.
3. Architektonische Änderungen
Cluster-Betrieb als Standard
Bislang unterschied Wazuh zwischen Stand-alone-Installationen und Cluster-Deployments. In Wazuh 5.0 fällt diese Unterscheidung weg: Jede Wazuh-Server-Installation läuft ab Version 5.0 als Cluster-Knoten. Die Konfigurationsoption cluster.disabled wird entfernt. Das klingt zunächst nach Mehraufwand, vereinfacht aber langfristig den Betrieb und das Upgrade-Verhalten erheblich, weil es nur noch ein Deployment-Modell gibt.
Für Bestandskunden mit Single-Node-Installationen bedeutet das: Die Migration muss sorgfältig geplant werden. Auch ein „Cluster“ mit nur einem Knoten ist ab Wazuh 5.0 formal ein Cluster – die Umstellung ist also nicht disruptiv, erfordert aber geänderte Konfigurationsdateien.
Filebeat wird abgelöst
Eine der spürbarsten Änderungen: Filebeat fällt weg. Bisher nutzte Wazuh Filebeat als Log-Shipper, um Events vom Wazuh-Server zum Wazuh-Indexer (OpenSearch) zu transportieren. In Wazuh 5.0 übernimmt der neue indexer-connector diese Aufgabe direkt über nativen Wazuh-Server-Code – ohne Filebeat als Zwischenkomponente.
Das reduziert den Wartungsaufwand, eliminiert eine potenzielle Fehlerquelle und verbessert die Performance. Gleichzeitig müssen Bestandsinstallationen angepasst werden, weil vorhandene Filebeat-Konfigurationen, -Module und -Templates entfallen.
Aufräumen bei den Daemons
Wazuh 5.0 entfernt eine ganze Reihe veralteter Komponenten, darunter die Daemons ossec-authd, wazuh-agentlessd, wazuh-maild und wazuh-dbd. Auch die C-basierten CLI-Tools manage_agents und agent-auth sowie das serverseitige OpenSCAP-Modul werden entfernt. Unternehmen, die Skripte oder Automatisierungen auf diese Komponenten aufgebaut haben, sollten ihre Prozesse entsprechend überarbeiten.
Windows-Agent ausschließlich als MSI
Der bisherige NSIS-basierte Windows-Installer wird entfernt. Der Wazuh-Agent für Windows wird ab Version 5.0 ausschließlich als MSI-Paket ausgeliefert. Das ist eine gute Nachricht für Unternehmen mit etablierten Deployment-Prozessen via Group Policy, Microsoft Intune oder SCCM – MSI-Pakete lassen sich dort wesentlich sauberer integrieren.
4. Neue Sicherheits- und Bedienfunktionen
Überarbeitetes RBAC-Konzept
Rollenbasierte Zugriffskontrollen (RBAC) werden in Wazuh 5.0 grundlegend überarbeitet. Das neue Modell ermöglicht feingranularere Berechtigungen, einen sauberen Upgrade-Mechanismus für bestehende RBAC-Konfigurationen und eine insgesamt übersichtlichere Verwaltung. Gerade für größere Organisationen mit mandantenähnlichen Strukturen oder klaren Trennungen zwischen Plattform-Admins und Security-Analysten ist das ein wichtiger Schritt.
Wazuh CTI: Threat Intelligence auf einer neuen Stufe
Die Threat-Intelligence-Plattform Wazuh CTI spielte bisher vor allem für die Vulnerability Detection eine Rolle. Mit Wazuh 5.0 wird sie deutlich ausgebaut: Ab der neuen Version umfasst CTI auch Indicators of Compromise (IOCs) wie IP-Adressen, Datei-Hashes und URLs. Zusätzlich werden die Wazuh-Detection-Regeln künftig direkt über die CTI-Plattform ausgeliefert.
Für Unternehmen bedeutet das: eine deutlich schnellere Reaktion auf neue Bedrohungen, ohne dass Wazuh-Server-Updates abgewartet werden müssen. Das nähert Wazuh funktional weiter an kommerzielle Threat-Intelligence-Angebote an.
Neuer Synchronisations-Algorithmus
Die Vulnerability-Detection-Pipeline wurde an einen neuen Sync-Algorithmus angepasst, der First-Scan-, Inventory-Change- und Feed-Update-Szenarien sauberer abbildet. Das Ergebnis: konsistentere Vulnerability-Scans, geringere Netzwerklast und weniger Fehler bei inkrementellen Updates.
5. Auswirkungen auf Bestandsinstallationen
Für Unternehmen, die heute Wazuh 4.x produktiv einsetzen, ergeben sich mehrere konkrete Handlungsfelder:
- Skripte und Automatisierungen überprüfen: Alles, was auf entfernte Daemons, Filebeat oder die alten CLI-Tools zugreift, muss angepasst werden.
- Deployment-Prozesse für Windows-Agents auf MSI umstellen, falls bisher NSIS-basierte Installer verwendet wurden.
- RBAC-Konfigurationen dokumentieren und auf die neue Rollen-Semantik vorbereiten.
- Monitoring- und Alerting-Integrationen an die neue Log-Transport-Architektur anpassen.
- Backup- und Disaster-Recovery-Pläne für die Cluster-by-default-Architektur aktualisieren.
Die gute Nachricht: Wazuh 5.0 bringt einen offiziellen Upgrade-Pfad und Migrationswerkzeuge. Die Weichenstellungen sollten aber vor dem Release sinnvoll überlegt werden – nicht erst beim eigentlichen Upgrade.
6. Migrations-Checkliste: Was Sie jetzt vorbereiten sollten
Auch wenn Wazuh 5.0 noch nicht finalisiert ist, lohnt es sich, bereits heute Vorbereitungen zu treffen. Eine pragmatische Checkliste für IT-Verantwortliche:
- Bestandsaufnahme: Welche Wazuh-Version wird aktuell eingesetzt? Welche Agents, welche Integrationen, welche Anpassungen?
- Abhängigkeiten dokumentieren: Wo greifen Skripte, Monitoring-Tools oder SIEM-Integrationen auf Wazuh-Komponenten zu?
- Architektur-Review: Ist die aktuelle Installation auf den Cluster-Betrieb vorbereitet? Gibt es Single-Points-of-Failure, die jetzt adressiert werden sollten?
- Testumgebung aufbauen: Eine dedizierte Test- oder Staging-Umgebung erlaubt das risikofreie Erproben von Pre-Releases.
- Rollout-Plan für Windows-MSI: Falls das Agent-Deployment bislang manuell oder via NSIS erfolgt, Umstieg auf MSI-basierte Verteilung (z. B. via Intune, GPO, SCCM) vorbereiten.
- RBAC-Audit: Bestehende Rollen und Berechtigungen bereinigen – ein frisches RBAC-Modell ist die bessere Ausgangsbasis für die Migration.
- Schulungsbedarf ermitteln: Welche Admins und Analysten benötigen Updates zu den neuen Konzepten?
7. Häufig gestellte Fragen (FAQ) zu Wazuh 5.0
Wann erscheint Wazuh 5.0?
Ein konkretes Veröffentlichungsdatum hat Wazuh Inc. bislang nicht kommuniziert. Die Entwicklung läuft aktiv, und Pre-Releases werden über das offizielle GitHub-Repository veröffentlicht. Ein produktiver Einsatz sollte erst nach einem stabilen General-Availability-Release geplant werden.
Können Wazuh 4.x und 5.0 parallel betrieben werden?
Ein paralleler Betrieb in getrennten Umgebungen (z. B. Produktion auf 4.x, Staging auf 5.0) ist sinnvoll und wird für die Migrationsvorbereitung empfohlen. Ein gemischter Cluster aus 4.x- und 5.0-Knoten ist nicht vorgesehen.
Muss ich auf Wazuh 5.0 upgraden?
Zwangsläufig nicht – aber sinnvoll. Wazuh 4.x wird zunächst weiter mit Sicherheits-Updates versorgt, langfristig wird der Support jedoch auslaufen. Wer neue Funktionen wie die erweiterte CTI-Integration nutzen möchte, kommt an Wazuh 5.0 nicht vorbei.
Was passiert mit unseren bestehenden Custom-Regeln und Decoders?
Custom-Regeln und -Decoders bleiben grundsätzlich kompatibel. Individuelle Anpassungen an der Server-Konfiguration, an Filebeat oder an entfernten Daemons müssen dagegen überarbeitet werden. Ein Regel- und Konfigurations-Review vor der Migration ist daher zu empfehlen.
Wie aufwendig ist die Migration von Wazuh 4.x auf 5.0?
Das hängt von der Umgebung ab. Für einfache Single-Node-Installationen ist der Aufwand überschaubar. Größere Cluster mit vielen Agents, Integrationen und Automatisierungen benötigen ein strukturiertes Migrationsprojekt mit Gap-Analyse, Staging-Test und geplantem Rollout.
8. Fazit: Strategisch planen statt reagieren
Wazuh 5.0 ist mehr als ein Update – es ist ein strategisches Release, das die Plattform für die nächsten Jahre positioniert. Die Kombination aus vereinfachter Architektur, überarbeitetem RBAC, erweiterter Threat Intelligence und klaren Deployment-Modellen macht Wazuh für mittelständische Unternehmen und Betreiber kritischer Infrastrukturen noch attraktiver.
Gleichzeitig gilt: Wer heute Wazuh produktiv einsetzt, sollte den Release nicht unvorbereitet auf sich zukommen lassen. Die hier beschriebenen Änderungen – Cluster-Default, Filebeat-Ablösung, Daemon-Cleanup – sind grundlegend genug, um ein strukturiertes Migrationsprojekt zu rechtfertigen.
Die SCI Systems GmbH unterstützt Unternehmen bei der Planung und Durchführung solcher Migrationsprojekte – von der initialen Bewertung über den Aufbau einer Staging-Umgebung bis zum produktiven Upgrade. Kontaktieren Sie uns, wenn Sie Ihren Migrationspfad frühzeitig abstimmen möchten.
Weitere Artikel aus unserer Wazuh-Serie:
