In diesem Artikel zeige ich einen typischen, aber oft falsch interpretierten Fehler in Wazuh + Wazuh Indexer (OpenSearch):
Vulnerabilities und Inventory-Daten funktionieren nicht mehr, Logs zeigen massenhaft 403 – obwohl Authentifizierung korrekt ist.
Die eigentliche Ursache liegt nicht bei Usern oder Rollen, sondern bei gesperrten Wazuh-States-Indizes.
Symptome
Im laufenden Betrieb fallen mehrere Dinge auf:
- Vulnerabilities / Inventory-Daten aktualisieren sich nicht
- Wazuh Dashboard bleibt leer oder zeigt veraltete Daten
ossec.logwird mit Fehlern geflutet
Typische Meldungen:
indexer-connector: ERROR: Client error, status code: 403
Auf den ersten Blick sieht das nach einem klassischen Berechtigungsproblem aus – ist es aber nicht.
Der entscheidende Schritt: Wazuh Debug aktivieren
Erst mit erhöhtem Debug-Level im Wazuh Manager wird klar, was wirklich schiefgeht.
Im Debug-Log taucht plötzlich folgender Fehler auf:
{
"status": 403,
"error": {
"type": "cluster_block_exception",
"reason": "index [wazuh-states-inventory-processes-wazuh] blocked by: [FORBIDDEN/8/index write (api)]"
}
}
🔍 Das ist der Schlüssel.
Nicht der Benutzer ist blockiert – der Index selbst ist schreibgeschützt.
Was bedeutet FORBIDDEN/8/index write (api)?
Diese Meldung kommt direkt vom Wazuh Indexer (OpenSearch) und bedeutet:
- Schreib- oder Delete-Operationen auf diesem Index sind verboten
- Ursache ist ein gesetzter Index-Write-Block
Das betrifft besonders häufig folgende Indizes:
wazuh-states-*- Inventory- und State-Indizes
- Vulnerability-abhängige Daten
Beweis: Index-Settings prüfen
Mit einem gezielten API-Call lässt sich der Zustand sofort verifizieren:
curl -k -u admin:PASS \
https://INDEXER:9200/wazuh-states-inventory-processes-wazuh/_settings?pretty
Ergebnis:
"blocks": {
"write": "true"
}
✅ Ursache eindeutig bestätigt.
Warum werden Wazuh-States-Indizes schreibgeschützt?
Der häufigste Auslöser sind Disk Watermarks im OpenSearch-Cluster:
- Bei hoher Plattenauslastung setzt der Indexer automatisch Write-Blocks
- Ziel: Schutz vor vollständigem Storage-Exhaust
Für Wazuh hat das fatale Folgen:
- States können nicht aktualisiert oder gelöscht werden
- Inventory und Vulnerabilities „frieren ein“
- Der Manager wirft ununterbrochen 403-Fehler
Der Fix: Write-Block per API entfernen
Einzelnen Index entsperren
curl -k -u admin:PASS -X PUT \
https://INDEXER:9200/wazuh-states-inventory-processes-wazuh/_settings \
-H 'Content-Type: application/json' \
-d '{"index.blocks.write": false}'
Alle Wazuh-States-Indizes entsperren (empfohlen)
curl -k -u admin:PASS -X PUT \
https://INDEXER:9200/wazuh-states-*/_settings \
-H 'Content-Type: application/json' \
-d '{"index.blocks.write": false}'
Danach erneut prüfen:
curl -k -u admin:PASS \
https://INDEXER:9200/wazuh-states-inventory-processes-wazuh/_settings \
| grep -i write
Wichtig: Ursache beseitigen, sonst kommt der Block zurück
Das Entfernen des Write-Blocks ist nur der zweite Schritt.
Wenn der Index ursprünglich wegen Storage-Druck gesperrt wurde und kein Platz geschaffen wird, setzt OpenSearch den Block erneut.
Best Practices:
- Plattenplatz prüfen und erweitern
- Alte Wazuh-Indizes bereinigen
- Retention-Strategie definieren
- Disk-Watermarks im Blick behalten
Fazit
Ein 403 in Wazuh bedeutet nicht automatisch ein Rechte- oder Auth-Problem.
In diesem Fall war:
- 🔍 Wazuh Debug der Schlüssel zur Wahrheit
- 🔒 der Index selbst gesperrt, nicht der Benutzer
- 🛠️ ein einzelner
curl-Call die technische Lösung
Wer Wazuh produktiv betreibt, sollte bei 403-Fehlern immer zuerst die Index-Settings prüfen – besonders bei wazuh-states-*.