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 angebunden ist?
Und gibt es Sicherheitsrisiken?
Die gute Nachricht:
Ja, das ist möglich – und Wazuh ist hier erstaunlich tolerant.
1. Manager-Cluster: WAN-tauglich und flexibel
Wazuh Manager Nodes kommunizieren im Cluster über:
- TCP Port 1516
- TLS-Zertifikate
- relativ leichtgewichtige Cluster-Metadaten
Das bedeutet:
geringe Bandbreitenanforderungen
gute Fehlertoleranz
robuste Replikationsmechanismen
Kevin Branch fasst es ideal zusammen:
„Wazuh manager clusters are pretty forgiving about having managers at WAN distances from each other.
Reasonable network reliability and an open network path should be enough.
High bandwidth is not necessary.“
Das ist keine Theorie – zahlreiche Installationen weltweit funktionieren genau so.
Warum funktioniert das?
- Die Manager teilen Agent-Status, integrity checks, API-State, cluster election, etc.
- Das sind vergleichsweise kleine Datenmengen.
- Der Manager-Cluster benötigt keine synchronen High-Throughput-Operationen.
Ergebnis:
Ein Manager-Worker on-prem ist kein Problem, wenn die Leitung stabil ist.
2. Was wird benötigt? – Voraussetzungen für einen Remote-Worker
2.1 Netzwerk & Ports
Laut Wazuh-Dokumentation:
- TCP 1516 muss offen sein (Cluster-Synchronisation)
- stabile Verbindung (keine High-Latency-Peaks)
- keine Paketverluste über längere Zeit
2.2 Zertifikate müssen exakt stimmen
Ein Manager-Worker, egal wo er steht, ist ein vollwertiger Teil des Clusters und braucht:
- ein gültiges
node*.pemZertifikat - eine gültige CA
- korrekte Rollen (Master / Worker)
Stuti Gupta betont hier klar:
„Make sure the certificates match correctly between the remote worker and the AWS managers.“
Dokumentation zur Zertifikatserstellung:
https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/adding-new-server-nodes/certificates-creation.html
3. Sicherheit: Gibt es Risiken?
Keine besonderen Risiken durch WAN-Manager
Solange:
- TLS-Zertifikate korrekt sind
- Ports sauber gefiltert sind
- nur autorisierte Nodes im Cluster zugelassen werden
ist das Modell absolut sicher.
Die Clusterkommunikation ist vollständig verschlüsselt.
Best Practice:
- VPN oder Site-to-Site IPsec
- Firewall-Regeln nur für Manager<→Manager
- kein offenes Internet-Routing
4. Wichtige Einschränkung: Indexer dürfen NICHT über WAN verteilt werden
Das ist der entscheidende Punkt:
„This is not the case for Wazuh indexer clusters.“
Warum?
Wazuh Indexer (OpenSearch) benötigt:
- extrem geringe Latenz (< 5 ms)
- sehr hohen Durchsatz
- kontinuierliche Replikation
- schnelle Shard-Bewegungen
- konsistente Cluster-Elections
Ein Indexer-Cluster über WAN führt unvermeidlich zu:
Shard-Failures
Cluster-Instabilität
Verlust von Replica-Verfügbarkeit
massiver Performanceeinbruch
Daher: Indexer-Cluster immer lokal & eng gekoppelt halten.
Wenn man Daten remote durchsuchen möchte, ist das Feature:
Cross-Cluster Search (CCS)
die einzige stabile Methode.
Dokumentation:
https://documentation.wazuh.com/current/indexer/cross-cluster-search/
5. Fazit
Die Kombination aus AWS und On-Prem ist nicht nur möglich, sondern häufig sinnvoll.
Ein Wazuh Manager kann problemlos remote stehen
Solange:
- Port 1516 offen ist
- die Verbindung stabil bleibt
- Zertifikate sauber eingerichtet werden
Ein Wazuh Indexer darf NICHT remote stehen
Für Indexer gelten strenge Performancevorgaben – WAN distanzen würden das Cluster zerstören.
Für remote Index-Durchsuchung eignet sich CCS
Statt Indexer zu verteilen → Cluster getrennt halten und Abfragen verbinden.
Obeyd hat daher grünes Licht:
Der Architekturansatz ist korrekt, technisch möglich und sicher – unter Beachtung der genannten Bedingungen.
https://wazuh.slack.com/archives/C0A933R8E/p1763925365079779