Quelltext der Seite Wazuh 403-Fehler verstehen: Wenn wazuh-states-Indizes schreibgeschützt sind

In diesem Artikel zeige ich einen typischen, aber oft falsch interpretierten Fehler in '''Wazuh + Wazuh-Indexer''':
Vulnerabilities und Inventory-Daten funktionieren nicht mehr, Logs zeigen massenhaft <code>403</code> – 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
* <code>ossec.log</code> wird mit Fehlern geflutet

Typische Meldungen:

<syntaxhighlight lang="text">
indexer-connector: ERROR: Client error, status code: 403
</syntaxhighlight>

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 [https://documentation.wazuh.com/current/user-manual/reference/internal-options.html Debug-Level] im Wazuh Manager wird klar, '''was wirklich schiefgeht'''.

Im Debug-Log taucht plötzlich folgender Fehler auf:

<syntaxhighlight lang="text">
{
  "status": 403,
  "error": {
    "type": "cluster_block_exception",
    "reason": "index [wazuh-states-inventory-processes-wazuh] blocked by: [FORBIDDEN/8/index write (api)]"
  }
}
</syntaxhighlight>

🔍 '''Das ist der Schlüssel.'''

Nicht der Benutzer ist blockiert – '''der Index selbst ist schreibgeschützt'''.

== Was bedeutet <code>FORBIDDEN/8/index write (api)</code>? ==

Diese Meldung kommt direkt vom Wazuh-Indexer 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:

* <code>wazuh-states-*</code>
* 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:

<syntaxhighlight lang="text">
curl -k -u <user>:<password> \
  https://<indexer_ip>:9200/wazuh-states-inventory-processes-wazuh/_settings?pretty
</syntaxhighlight>

Ergebnis:

<syntaxhighlight lang="text">
"blocks": {
  "write": "true"
}
</syntaxhighlight>

✅ 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 ===

<syntaxhighlight lang="text">
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}'
</syntaxhighlight>

== 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

=== Alle Wazuh-States-Indizes entsperren (empfohlen) ===

<syntaxhighlight lang="text">
curl -k -u admin:PASS -X PUT \
  https://INDEXER:9200/wazuh-states-*/_settings \
  -H 'Content-Type: application/json' \
  -d '{"index.blocks.write": false}'
</syntaxhighlight>

Danach erneut prüfen:

<syntaxhighlight lang="text">
curl -k -u admin:PASS \
  https://INDEXER:9200/wazuh-states-inventory-processes-wazuh/_settings \
  | grep -i write
</syntaxhighlight>

== Fazit ==

Ein <code>403</code> 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 <code>curl</code>-Call''' die technische Lösung

Wer Wazuh produktiv betreibt, sollte bei 403-Fehlern '''immer zuerst die Index-Settings prüfen''' – besonders bei <code>wazuh-states-*</code>.

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/wazuh-403-fehler-verstehen-wenn-wazuh-states-indizes-schreibgeschuetzt-sind/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 20. Dezember 2025).

== Unterstützung von m.a.x. it ==
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]