OpenSearch Audit Logs im Wazuh Indexer: Audit-Index wächst explosionsartig – auf Authentifizierung fokussieren und Cluster stabil halten

von

Einleitung

Audit-Logs im OpenSearch Security Plugin sind für Compliance (z. B. PCI DSS) ein zentrales Kontrollinstrument, weil sich damit unter anderem erfolgreiche und fehlgeschlagene Authentifizierungen nachvollziehen lassen. Gleichzeitig können Audit-Logs in SIEM-Stacks wie Wazuh schnell zum Betriebsrisiko werden: Wenn jede systeminterne Bulk-Operation, jeder Indexzugriff und jede Hintergrundabfrage auditpflichtig protokolliert wird, wächst der Audit-Index massiv – bis hin zu Indexer-Instabilität oder Crash-Loops. Dieser Beitrag zeigt, wie man Audit-Logging gezielt so konfiguriert, dass primär AUTHENTICATED/FAILED_LOGIN übrig bleiben und „Noisy“-Events (z. B. aus Wazuh-Status-/Inventory-Indizes) nicht mehr den Cluster überrollen.

Ausgangslage / Problemstellung

Audit-Logging wurde in OpenSearch per:

plugins.security.audit.type: internal_opensearch

aktiviert. Das funktionierte zunächst stabil. Seit einiger Zeit wächst jedoch der Audit-Index (z. B. security-auditlog-* bzw. auditlog-YYYY.MM.dd) extrem schnell, insbesondere durch viele Einträge im Zusammenhang mit Wazuh-eigenen Indizes (z. B. wazuh-states-inventory-processes-*). Der Indexer wird instabil und crasht, sodass Audit-Logging deaktiviert werden musste.

Ziel: Audit-Logs beibehalten, aber auf Authentifizierung (Login/Failed Login) fokussieren und die restliche „Datenflut“ vermeiden.

Technische Analyse

1) Was internal_opensearch bewirkt

Mit plugins.security.audit.type: internal_opensearch schreibt das Security Plugin Audit-Events in denselben OpenSearch-Cluster (Rolling Index, standardmäßig täglich). OpenSearch Dokumentation
Das ist bequem, aber riskant: Wenn Audit-Events sehr hochfrequent entstehen, erhöhen sie Schreiblast, Indexanzahl/Segmentdruck und Ressourcenverbrauch — und können dadurch genau den Cluster destabilisieren, dessen Sicherheit man eigentlich überwachen möchte.

2) Warum Wazuh-Indices Audit-Logs „fluten“ können

Wazuh erzeugt durch Agents/Manager/Indexer regelmäßig Zustands- und Inventory-Daten (z. B. Prozesse, Pakete, Hardware-Inventory). Diese Datenströme resultieren in vielen Index- und Bulk-Operationen. Wenn Audit-Logging breit aktiviert ist, werden solche Requests (je nach Audit-Kategorie, REST/Transport-Layer, Request-Body-Logging, Resolve-Indizes etc.) auditrelevant und landen massenhaft im Audit-Index. OpenSearch bietet dafür explizite Stellschrauben: Kategorien deaktivieren, Requests ignorieren, Benutzer ausschließen und Logging-Detailgrad reduzieren. OpenSearch Dokumentation

3) „Nur Authentifizierung“ ist in OpenSearch über Kategorien abbildbar

OpenSearch definiert Audit-Kategorien wie FAILED_LOGIN und AUTHENTICATED (sowie weitere wie MISSING_PRIVILEGES, BAD_HEADERS, SSL_EXCEPTION, OPENSEARCH_SECURITY_INDEX_ATTEMPT, GRANTED_PRIVILEGES). OpenSearch Dokumentation
Statt alles zu loggen und anschließend zu „filtern“, ist die stabile Strategie: alle nicht benötigten Kategorien deaktivieren, sodass nur die für Compliance nötigen Kategorien übrig bleiben.

Lösung / Best Practices

1) Audit-Kategorien hart reduzieren (Auth-only)

OpenSearch erlaubt das Deaktivieren von Kategorien getrennt nach REST- und Transport-Layer:

plugins.security.audit.config.disabled_rest_categories: <...>
plugins.security.audit.config.disabled_transport_categories: <...>

OpenSearch Dokumentation

Praxisansatz für „nur Authentifizierung“:

  • Ziel: AUTHENTICATED und FAILED_LOGIN behalten
  • Alle anderen Kategorien in disabled_*_categories aufnehmen

Da OpenSearch in der Doku die Kategorie-Liste referenziert, sollte die Deaktivierungs-Liste alle Kategorien außer AUTHENTICATED/FAILED_LOGIN umfassen (je nach gewünschter Tiefe ggf. auch MISSING_PRIVILEGES behalten). Die Kategorien sind in der Field Reference dokumentiert. OpenSearch Dokumentation

2) REST- oder Transport-Layer gezielt abschalten (wenn nicht benötigt)

Audit-Logging ist standardmäßig auf REST und Transport aktiv. Du kannst eine Ebene deaktivieren:

plugins.security.audit.config.enable_rest: false
plugins.security.audit.config.enable_transport: false

OpenSearch Dokumentation

Für viele Compliance-Use-Cases rund um Login/Failed Login ist REST häufig der primäre relevante Pfad (abhängig von Auth-Setup und Zugriffspfaden). Der offizielle Punkt ist: Reduziere die Audit-Oberfläche auf das, was du wirklich brauchst.

3) Noisy Requests ausklammern: ignore_requests

OpenSearch unterstützt das Ausschließen bestimmter Requests – entweder als Transport-Actions (z. B. indices:data/read/*) oder als REST-Request-Pfade:

plugins.security.audit.config.ignore_requests: ["indices:data/read/*", "SearchRequest"]

OpenSearch Dokumentation

Für dein Symptom („Auditlog voll mit Wazuh-Inventory-Prozessen“) ist das die offizielle Stellschraube, um wiederkehrende Bulk/Read/Meta-Requests oder bestimmte Request-Pfade zu ignorieren, die in deiner Umgebung den Audit-Index dominieren.

4) System-/Service-User ausnehmen: ignore_users

Wenn die Audit-Flut hauptsächlich durch einen technischen Benutzer entsteht (z. B. ein Wazuh-Servicekonto oder Dashboards-Server-User), lässt er sich von der Audit-Erfassung ausschließen:

plugins.security.audit.config.ignore_users:
  - kibanaserver
  - admin

OpenSearch Dokumentation

Das ist besonders wirkungsvoll, wenn Wazuh-Komponenten mit einem dedizierten User schreiben und genau dieser User den Großteil der Inventory-/States-Write-Last verursacht. Vorgehen: Audit kurz aktivieren, den audit_request_effective_user in den Audit-Events identifizieren und dann gezielt in ignore_users aufnehmen. Die relevanten Felder sind dokumentiert. OpenSearch Dokumentation

5) Logging-Detailgrad reduzieren: Request Body & Indizes

Zwei Optionen reduzieren Eventgröße und Overhead deutlich:

  • Request-Body Logging deaktivieren: plugins.security.audit.config.log_request_body: false OpenSearch Dokumentation
  • Index-Namen-Auflösung deaktivieren (nur möglich, wenn Request Body Logging aus ist): plugins.security.audit.config.resolve_indices: false OpenSearch Dokumentation

Gerade bei automatisierten Schreibpfaden (Bulk, häufige Indizes) kann das die Audit-Event-Payload spürbar verkleinern.

6) Bulk-Handling nicht „verschärfen“

OpenSearch kann so konfiguriert werden, dass Bulk-Requests in Einzeloperationen aufgelöst und einzeln geloggt werden – die Doku warnt explizit davor, weil das extrem viele Audit-Events erzeugt:

plugins.security.audit.config.resolve_bulk_requests: true

Diese Option sollte in High-Volume-Umgebungen nicht aktiviert werden. OpenSearch Dokumentation

Lessons Learned / Best Practices

  • internal_opensearch ist funktional, erhöht aber das Risiko eines Selbstverstärkungs-Effekts: Audit-Logging erzeugt zusätzliche Schreiblast im gleichen Cluster. OpenSearch Dokumentation
  • Für PCI- und Auth-Use-Cases ist die sauberste Strategie: Audit-Kategorien reduzieren und nur AUTHENTICATED/FAILED_LOGIN behalten (optional MISSING_PRIVILEGES). OpenSearch Dokumentation+1
  • Noisy Datenpfade (Bulk, Search, Meta) gehören in ignore_requests, nicht in nachgelagerte Visualisierungen.
  • System- und Service-User sind häufig der größte Audit-Treiber → ignore_users gezielt nutzen. OpenSearch Dokumentation
  • Reduziere Payload: log_request_body: false und – wenn möglich – resolve_indices: false. OpenSearch Dokumentation
  • In Wazuh-Stacks ist Kontext wichtig: Wazuh kann OpenSearch als Indexer-/Analysekomponente nutzen; hohe Wazuh-State-/Inventory-Schreiblast ist daher normal – Audit muss daran angepasst werden, nicht umgekehrt. Wazuh Dokumentation

Fazit

Wenn Audit-Logging im OpenSearch/Wazuh-Indexer den Audit-Index explodieren lässt, ist das fast immer ein Konfigurationsproblem: zu viele Kategorien, zu viele Requests, falsche Benutzerabdeckung oder zu hoher Detailgrad. OpenSearch bietet dafür offiziell dokumentierte Controls (disabled_*_categories, ignore_requests, ignore_users, log_request_body, resolve_indices). Wer Audit auf AUTHENTICATED/FAILED_LOGIN fokussiert, erhält Compliance-relevante Nachweise – ohne den Indexer durch systeminterne Wazuh-Indexlast in die Instabilität zu treiben.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1767622751095699