Quelltext der Seite Warum in Wazuh nicht alle AWS-CloudTrail-Events erscheinen

== Einleitung ==

Bei der Integration von AWS CloudTrail in Wazuh erwarten viele Administratoren, dass jedes CloudTrail-Ereignis automatisch als Alert im Wazuh Dashboard erscheint. In der Praxis ist das nicht immer der Fall. Wazuh verarbeitet CloudTrail-Logs zwar aus S3, aber die Standardregeln entscheiden, welche Events tatsächlich als Alerts erzeugt und indexiert werden.

== Ausgangslage / Problemstellung ==

Nach der Einrichtung der AWS-Integration gemäß Wazuh-Dokumentation werden CloudTrail-Events aus einem S3-Bucket abgeholt. Trotzdem erscheinen in Wazuh deutlich weniger Events als in der CloudTrail-Ansicht der AWS-Konsole. Zusätzlich wirkt es so, als ob das konfigurierte Abfrageintervall von einer Minute nicht eingehalten wird, weil neue Events nur alle 10 bis 20 Minuten sichtbar werden.

Typische Symptome sind:

<syntaxhighlight lang="text">
CloudTrail zeigt Events, die in Wazuh nicht auftauchen.
Wazuh erzeugt Alerts nur für bestimmte AWS-Aktionen.
Das aws-s3-Modul ist auf ein kurzes Intervall konfiguriert, aber Events erscheinen verzögert.
Nach Anpassung der Regel erscheinen plötzlich deutlich mehr Events als in der CloudTrail-Konsole.
</syntaxhighlight>

== Technische Analyse ==

Die Ursache liegt in zwei unterschiedlichen Ebenen der Verarbeitung.

Erstens liest Wazuh CloudTrail-Daten nicht aus der CloudTrail-Konsole, sondern direkt aus den Logdateien im S3-Bucket. Die AWS-Konsole ist daher nicht zwingend eine vollständige 1:1-Referenz für das, was Wazuh verarbeitet. Filter, Ansichten, Event-History-Grenzen oder Suchparameter in der Konsole können dazu führen, dass dort weniger oder andere Events sichtbar sind als in den eigentlichen S3-Logdateien.

Zweitens bedeutet „Log wurde von Wazuh gelesen“ nicht automatisch „Alert wurde erzeugt“. Für CloudTrail ist die Wazuh-Regel <code>80202</code> relevant. Diese Standardregel filtert CloudTrail-Events anhand bekannter AWS-Eventnamen aus der CDB-Liste:

<syntaxhighlight lang="text">
/var/ossec/etc/lists/amazon/aws-eventnames
</syntaxhighlight>

Ist ein bestimmter Wert aus <code>aws.eventName</code> nicht in dieser Liste enthalten, kann das Event zwar grundsätzlich eingelesen werden, erzeugt aber unter Umständen keinen Alert über diese Regel. Das ist kein Decoder-Fehler, sondern Teil der Standardklassifizierung im Wazuh-Ruleset.

Das beobachtete Zeitverhalten hat eine weitere Ursache: Das <code><interval></code> im <code>aws-s3</code>-Wodle steuert nur, wie häufig Wazuh den S3-Bucket prüft. Es steuert nicht, wann AWS die CloudTrail-Logdateien in S3 bereitstellt. Eine Verzögerung von mehreren Minuten zwischen API-Ereignis, Ablage in S3 und Verarbeitung durch Wazuh ist daher erwartbar.

== Lösung / Best Practices ==

Der erste Schritt sollte immer der Vergleich des fehlenden CloudTrail-Events mit der CDB-Liste sein. Dafür wird der Wert aus <code>aws.eventName</code> geprüft:

<syntaxhighlight lang="text">
grep -x "EventNameHierEintragen" /var/ossec/etc/lists/amazon/aws-eventnames
</syntaxhighlight>

Fehlt der Eventname, gibt es zwei saubere Optionen.

Die konservative Variante ist, die CDB-Liste gezielt zu erweitern. Das ist sinnvoll, wenn nur bestimmte AWS-Aktionen zusätzlich alerten sollen. So bleibt die Alert-Menge kontrollierbar.

Die breitere Variante ist ein Override der CloudTrail-Regel <code>80202</code>, damit alle Events mit <code>aws.source = cloudtrail</code> einen Alert erzeugen. Dazu wird in <code>/var/ossec/etc/rules/local_rules.xml</code> folgende Regel hinterlegt:

<syntaxhighlight lang="text">
<group name="amazon,aws,">
  <rule id="80202" level="3" overwrite="yes">
    <field name="aws.source">cloudtrail</field>
    <options>no_full_log</options>
    <description>AWS Cloudtrail: $(aws.eventSource) - $(aws.eventName).</description>
    <group>aws_cloudtrail,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,pci_dss_10.6.1,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>
</syntaxhighlight>

Anschließend muss der Wazuh Manager neu gestartet werden:

<syntaxhighlight lang="text">
systemctl restart wazuh-manager
</syntaxhighlight>

Diese Anpassung sorgt dafür, dass CloudTrail-Events unabhängig von der Eventname-CDB-Liste als Alerts erscheinen, sofern sie korrekt als AWS-CloudTrail-Event dekodiert wurden.

Die Nebenwirkung ist wichtig: Die Alert-Menge kann stark steigen. Das belastet Speicher, Indexer, Dashboards, Retention und gegebenenfalls Benachrichtigungen. In produktiven Umgebungen sollte diese Änderung daher mit Index-Lifecycle-Management, Retention-Planung und gezielten Dashboard-Filtern kombiniert werden.

== Lessons Learned / Best Practices ==

CloudTrail-Integration in Wazuh sollte nicht ausschließlich über die AWS-Konsole validiert werden. Die belastbarere Referenz sind die tatsächlich im S3-Bucket gespeicherten CloudTrail-Dateien.

Für Troubleshooting empfiehlt sich diese Reihenfolge:

<syntaxhighlight lang="text">
1. Prüfen, ob CloudTrail das Event in S3 abgelegt hat.
2. Prüfen, ob das aws-s3-Modul den Bucket korrekt liest.
3. Prüfen, ob das Event dekodiert wird.
4. Prüfen, ob eine Wazuh-Regel einen Alert erzeugt.
5. Prüfen, ob Dashboard-Filter oder Index-Patterns das Event ausblenden.
</syntaxhighlight>

Ein globaler Override der Regel <code>80202</code> ist technisch wirksam, aber nicht immer die beste Betriebsstrategie. Für produktive SIEM-Umgebungen ist oft ein abgestuftes Modell besser:

<syntaxhighlight lang="text">
Level 3: vollständige CloudTrail-Sichtbarkeit für Audit- und Hunting-Zwecke
Level 5–7: relevante administrative Änderungen
Level 8+: sicherheitskritische Aktionen wie IAM-, KMS-, CloudTrail-, GuardDuty- oder Root-Account-Aktivität
</syntaxhighlight>

So bleibt die Sichtbarkeit erhalten, ohne dass alle AWS-API-Aufrufe als gleich wichtig behandelt werden.

== Fazit ==

Wenn in Wazuh weniger CloudTrail-Events erscheinen als erwartet, liegt die Ursache häufig nicht an der AWS-Integration selbst, sondern an der Standardregel-Logik und der CDB-Liste für bekannte AWS-Eventnamen. Wer vollständige CloudTrail-Sichtbarkeit benötigt, kann Regel <code>80202</code> überschreiben und alle CloudTrail-Events alerten lassen. Dabei sollte jedoch bewusst mit höherem Datenvolumen, mehr Alerts und zusätzlicher Indexer-Last gerechnet werden.

== Quellenverweis ==

Wazuh-Dokumentation: AWS prerequisites
[https://documentation.wazuh.com/current/cloud-security/amazon/services/prerequisites/index.html?utm_source=chatgpt.com https://documentation.wazuh.com/current/cloud-security/amazon/services/prerequisites/index.html]

Wazuh-Dokumentation: AWS CloudTrail supported service
[https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/cloudtrail.html?utm_source=chatgpt.com https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/cloudtrail.html]

Wazuh-Dokumentation: aws-s3 wodle configuration
[https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/wodle-s3.html?utm_source=chatgpt.com https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/wodle-s3.html]

Wazuh-Dokumentation: CDB lists
[https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html?utm_source=chatgpt.com https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html]

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

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

[https://wazuh.slack.com/archives/C0A933R8E/p1772635420919879 https://wazuh.slack.com/archives/C0A933R8E/p1772635420919879]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/warum-in-wazuh-nicht-alle-aws-cloudtrail-events-erscheinen/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 29. Mai 2026).

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