Wazuh AWS CloudTrail Dashboard bleibt leer: Analyse von „No logs to process in bucket“

Einleitung

Die AWS-Integration von Wazuh liest CloudTrail-Logs aus einem S3-Bucket, verarbeitet sie über das AWS-Modul und erzeugt daraus Events für die Wazuh-Indizes. Wenn der Bucket erreichbar ist, im Dashboard aber keine CloudTrail-Daten erscheinen, liegt das Problem häufig nicht am Dashboard selbst, sondern an der vorgelagerten Erfassung: Wazuh findet keine neuen oder korrekt adressierbaren Logobjekte im S3-Pfad.

Ausgangslage / Problemstellung

Die AWS-CloudTrail-Integration ist konfiguriert, der S3-Bucket ist vom Wazuh-Server aus erreichbar. Trotzdem zeigt das Wazuh Dashboard keine CloudTrail-Events.

Im Debug-Log erscheint unter anderem:

INFO: Executing Bucket Analysis: (Bucket: wazuh-cloudtrail-logs-..., Type: cloudtrail)
DEBUG: +++ Working on 927505956742 - ap-northeast-1
DEBUG: +++ Marker: AWSLogs/927505956742/CloudTrail/ap-northeast-1/2026/02/12/...
DEBUG: +++ No logs to process in bucket: 927505956742/ap-northeast-1

Der entscheidende Hinweis ist:

No logs to process in bucket

Das bedeutet: Das AWS-Modul läuft grundsätzlich, kann den Bucket analysieren und arbeitet Regionen ab. Es findet aber keine neuen CloudTrail-Objekte, die gemäß aktueller Konfiguration verarbeitet werden sollen.

Technische Analyse

Die Wazuh-AWS-Integration wird über wazuh-modulesd ausgeführt. Für CloudTrail ruft Wazuh intern das Skript aws-s3.py auf und verarbeitet S3-Objekte anhand von Bucket, Typ, optionalem Pfad, Account-ID, Region und internem Marker.

Eine typische Konfiguration sieht so aus:

<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>no</skip_on_error>

  <bucket type="cloudtrail">
    <name>wazuh-cloudtrail-logs-example</name>
    <aws_profile>default</aws_profile>
  </bucket>
</wodle>

CloudTrail-Logs liegen normalerweise in einer Struktur ähnlich dieser:

s3://<BUCKET>/<PREFIX>/AWSLogs/<ACCOUNT_ID>/CloudTrail/<REGION>/<YEAR>/<MONTH>/<DAY>/

Ohne Prefix entsprechend:

s3://<BUCKET>/AWSLogs/<ACCOUNT_ID>/CloudTrail/<REGION>/<YEAR>/<MONTH>/<DAY>/

Wenn im Bucket ein zusätzlicher Prefix verwendet wird, muss dieser in der Wazuh-Konfiguration berücksichtigt werden:

<bucket type="cloudtrail">
  <name>wazuh-cloudtrail-logs-example</name>
  <path>mein/prefix</path>
  <aws_profile>default</aws_profile>
</bucket>

Ein leerer Dashboard-Bereich kann daher mehrere Ursachen haben:

Die CloudTrail-Dateien werden nicht mit aktuellem Datum geschrieben.

Wazuh liest den falschen Bucket oder den falschen Prefix.

Die Region stimmt nicht mit den tatsächlich erzeugten CloudTrail-Logs überein.

Der interne Marker zeigt bereits auf die zuletzt bekannte Datei, sodass keine neueren Objekte verarbeitet werden.

Die IAM-Policy erlaubt zwar Bucket-Zugriff, aber nicht alle benötigten Aktionen wie s3:ListBucket und s3:GetObject.

Die Events werden verarbeitet, landen aber nicht im erwarteten Indexmuster oder Zeitraum des Dashboards.

Lösung / Best Practices

Zuerst sollte Debug-Logging für das AWS-Modul aktiviert werden:

echo "wazuh_modules.debug=2" >> /var/ossec/etc/local_internal_options.conf
systemctl restart wazuh-manager

Danach einige Minuten warten und die Modul-Logs prüfen:

grep modulesd /var/ossec/logs/ossec.log

Anschließend sollte die Integration manuell als Benutzer wazuh ausgeführt werden:

sudo -u wazuh /var/ossec/framework/python/bin/python3 \
  /var/ossec/wodles/aws/aws-s3.py \
  --bucket wazuh-cloudtrail-logs-example \
  --type cloudtrail \
  --debug 2

Falls ein Prefix genutzt wird:

sudo -u wazuh /var/ossec/framework/python/bin/python3 \
  /var/ossec/wodles/aws/aws-s3.py \
  --bucket wazuh-cloudtrail-logs-example \
  --type cloudtrail \
  --prefix mein/prefix \
  --debug 2

Parallel muss im S3-Bucket geprüft werden, ob aktuelle CloudTrail-Dateien existieren:

AWSLogs/<ACCOUNT_ID>/CloudTrail/<REGION>/<YEAR>/<MONTH>/<DAY>/

Für den Beispielzeitpunkt aus dem Log wäre also besonders zu prüfen:

AWSLogs/927505956742/CloudTrail/ap-south-1/2026/02/13/

Die IAM-Policy sollte mindestens das Auflisten des Buckets und das Lesen der Objekte erlauben:

{
  "Effect": "Allow",
  "Action": [
    "s3:ListBucket",
    "s3:GetObject"
  ],
  "Resource": [
    "arn:aws:s3:::wazuh-cloudtrail-logs-example",
    "arn:aws:s3:::wazuh-cloudtrail-logs-example/*"
  ]
}

Wenn nur bestimmte Regionen relevant sind, sollte die Konfiguration eingeschränkt werden. Das reduziert unnötige Scans und macht Debugging einfacher:

<bucket type="cloudtrail">
  <name>wazuh-cloudtrail-logs-example</name>
  <aws_profile>default</aws_profile>
  <regions>ap-south-1</regions>
</bucket>

Nach erfolgreicher Verarbeitung sollten CloudTrail-Events nicht nur im Dashboard, sondern auch direkt in den Wazuh-Alerts sichtbar sein. Zur Kontrolle:

grep -i cloudtrail /var/ossec/logs/alerts/alerts.json
grep -i aws /var/ossec/logs/alerts/alerts.json

Wenn dort keine Events erscheinen, ist das Problem weiterhin vor der Dashboard-Ebene zu suchen. Wenn Events vorhanden sind, sollte im Dashboard der Zeitfilter, das Indexmuster und die AWS-Ansicht geprüft werden.

Lessons Learned / Best Practices

Ein erreichbarer S3-Bucket reicht nicht aus. Entscheidend ist, ob Wazuh neue Objekte im erwarteten CloudTrail-Pfad findet und diese mit der konfigurierten Bucket-Struktur übereinstimmen.

Die Meldung No logs to process in bucket ist kein klassischer Berechtigungsfehler. Sie zeigt meist, dass keine neuen Dateien zur Verarbeitung gefunden wurden oder dass Wazuh durch Marker, Prefix, Region oder Pfadstruktur an den relevanten Objekten vorbeiläuft.

Für produktive Umgebungen sollten Bucket-Name, Prefix, Account-ID, Region und CloudTrail-Ablagepfad sauber dokumentiert werden. Besonders bei automatisch erzeugten CloudTrail-Buckets oder Organizations-Trails können zusätzliche Pfadbestandteile entstehen.

Fazit

Wenn das Wazuh AWS CloudTrail Dashboard leer bleibt, sollte zuerst die S3-Verarbeitung geprüft werden, nicht das Dashboard. Debug-Logs, manuelle Ausführung von aws-s3.py, Kontrolle aktueller CloudTrail-Dateien und Abgleich von Bucket-Prefix und Regionen führen in der Regel schnell zur Ursache. Erst wenn Events in alerts.json vorhanden sind, lohnt sich die Analyse von Dashboard, Indexmuster und Zeitfilter.