Wazuh + AWS Security Hub (SQS Subscriber) und CloudTrail im selben aws-s3-Wodle: Wenn nur der erste Collector läuft

von

Einleitung

Viele Wazuh-Deployments in AWS starten mit CloudTrail – zurecht, denn damit landen IAM-, API- und Control-Plane-Aktivitäten zuverlässig im SIEM. Der nächste logische Schritt ist die Anbindung von AWS Security Hub, um normalisierte Findings (ASFF) zentral zu korrelieren. In der Praxis scheitert das aber oft nicht an AWS selbst, sondern an der Art, wie das Wazuh-aws-s3-Wodle konfiguriert ist – insbesondere sobald mehrere Sammelquellen (Bucket + Subscriber) kombiniert werden. Wazuh unterstützt zwar mehrere Buckets/Subscriber in einem Block, dennoch gibt es typische Fallen, die dazu führen, dass nur „der erste Teil“ läuft.

Ausgangslage / Problemstellung

In einer EC2-Installation mit Instance Profile (IAM Role am EC2-Host) soll Wazuh:

  • CloudTrail-Logs aus einem S3-Bucket einsammeln
  • Security Hub Findings über einen SQS-basierten Subscriber (type="security_hub") verarbeiten

Anfangs tritt ein Fehler auf:

  • Returned exit code 12
  • The config profile (default) could not be found

Später wird der Fehler durch Entfernen eines zweiten aws-s3-Blocks „gelöst“, jedoch bleibt ein neues Symptom: Nach dem Zusammenführen in einen aws-s3-Block läuft nur CloudTrail, der Security-Hub-Subscriber wird nicht sichtbar ausgeführt (keine „Subscriber fetch“-Logs), obwohl SQS grundsätzlich funktioniert.

Technische Analyse

1) Exit Code 12: „Config profile (default) could not be found“ trotz IAM Role

Der Fehler ist in Wazuh als Auth-/Credential-Problem beschrieben und tritt auf, wenn das Modul keine gültige Authentifizierung findet oder unerwartet nach einem Profil sucht.

Auch wenn IAM Roles auf EC2 „ohne Eintrag im ossec.conf“ empfohlen sind, gibt es zwei häufige Gründe, warum Wazuh dennoch nach einem Profil greift:

  • Instance Metadata / IMDS nicht erreichbar oder eingeschränkt (z. B. IMDSv2-Härtung falsch umgesetzt)
  • AWS CLI/SDK-Umgebung erzwingt ein Profil: Variablen wie AWS_PROFILE/AWS_DEFAULT_PROFILE können die Standardprofil-Logik beeinflussen und Profil-Resolution triggern.

Wichtig: Das Wazuh-Modul nutzt die AWS SDK/Boto3-Mechanik – wenn die Rolle nicht sauber gezogen wird, ist „Profil nicht gefunden“ oft nur ein Sekundärsymptom.

2) Zwei aws-s3-Blöcke: nicht „zwei Jobs“, sondern Konflikt

Ein zentraler Punkt: In der Praxis ist es nicht zuverlässig möglich, mehrere getrennte <wodle name="aws-s3">...</wodle>-Sektionen parallel zu betreiben – je nach Version/Parsing greift dann nur eine oder keine. Genau deshalb empfiehlt Wazuh (auch in Community-Antworten) die Konsolidierung in einen Block.

3) Warum läuft im kombinierten Block nur CloudTrail?

Offiziell ist es erlaubt, mehrere Buckets und Subscriber innerhalb eines aws-s3-Blocks zu konfigurieren.
Wenn trotzdem nur CloudTrail „sichtbar“ läuft, sind drei Ursachen besonders typisch:

A) CloudTrail-Backlog blockiert den Laufzyklus (Runtime dominiert das Intervall)
CloudTrail kann beim ersten Durchlauf sehr weit zurückgreifen (Default-Verhalten ohne Filter) und dadurch lange laufen. Wazuh weist selbst darauf hin, dass ohne only_logs_after „ab sehr früh“ verarbeitet werden kann – insbesondere beim ersten Run.
Dann passiert Folgendes operativ: Der Zyklus ist mit Bucket-Verarbeitung beschäftigt, und der Subscriber wirkt „stumm“, weil er nicht (rechtzeitig) dran kommt bzw. keine separate Logzeile schreibt, bevor der nächste Intervallstart kommt.

B) Subscriber hat nichts zu tun (keine neuen Objekte/Notifications)
Der Security-Hub-Flow in Wazuh ist S3→SQS-getrieben: Wazuh pollt SQS, um Objekt-Neuanlagen im S3-Bucket zu erkennen und lädt dann die Logs. Wenn keine neuen Findings nach dem Setup erzeugt wurden (oder der Export nicht korrekt läuft), bleibt SQS leer oder wird von Wazuh sofort abgearbeitet – dann sieht man „Fetching logs finished“ ohne erkennbare Findings.

C) Konfigurations-/Pipeline-Details: Security Hub ist „Findings“, nicht CloudTrail
Security Hub normalisiert Findings ins AWS Security Finding Format (ASFF). Damit Wazuh etwas sieht, muss der Exportweg in S3 korrekt sein (und die Findings müssen tatsächlich entstehen).

Lösung / Best Practices

Schritt 1: Authentifizierung sauber verifizieren (EC2 IAM Role)

Auf der Wazuh-EC2-Instanz (als Root) prüfen:

  • Rolle via Instance Metadata erreichbar
  • Identität via STS verfügbar

Wenn STS nicht geht, ist die „Profil“-Meldung erwartbar (Fallback). Für die Ursachenanalyse sind AWS-CLI-Envvars relevant: sicherstellen, dass kein AWS_PROFILE/AWS_DEFAULT_PROFILE gesetzt ist, das ein Profil erzwingt.

Schritt 2: Ein aws-s3-Block – aber CloudTrail gezielt begrenzen

Damit CloudTrail nicht den gesamten Lauf dominiert:

  • only_logs_after setzen (z. B. auf das Go-Live-Datum oder „heute minus X Tage“)
  • ggf. regions explizit definieren
  • skip_on_error aktiv lassen, um nicht an einzelnen Objekten hängen zu bleiben

Wazuh dokumentiert only_logs_after explizit als entscheidenden Filter und beschreibt die Konsequenzen des ersten Runs.

Beispiel (Prinzipdarstellung):

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

  <bucket type="cloudtrail">
    <name>cloudtrail-XXXX</name>
    <aws_organization_id>o-XXXX</aws_organization_id>
    <aws_account_id>XXXX</aws_account_id>
    <regions>eu-central-1</regions>
    <only_logs_after>2026-JAN-20</only_logs_after>
  </bucket>

  <subscriber type="security_hub">
    <sqs_name>wazuh-sec-hub-notification-queue</sqs_name>
  </subscriber>
</wodle>

Schritt 3: Security Hub Datenfluss testbar machen

„Keine Findings in Wazuh“ ist oft schlicht: Es gibt keine neuen Findings, oder sie kommen nicht als S3-Objekt an.

Pragmatischer Test ohne eigenes ASFF-Basteln:

  1. Einen Service aktivieren, der Findings an Security Hub liefert (z. B. GuardDuty/Inspector je nach Umgebung).
  2. Sample Findings dort erzeugen (GuardDuty bietet dafür ein CLI-Kommando).
  3. Prüfen, ob die Findings in Security Hub auftauchen (ASFF).
  4. Prüfen, ob im S3-Bucket neue Objekte entstehen und ob SQS Notifications erhält (ApproximateNumberOfMessages).
  5. Erst dann Wazuh-Seite prüfen.

Schritt 4: In Wazuh prüfen, ob Logs überhaupt ankommen (auch ohne Regeln/Alerts)

Wazuh empfiehlt zum reinen „Transportnachweis“, temporär Rohdaten in die Archive zu schreiben (logall_json). Damit lässt sich unabhängig von Regeln zeigen, ob Events den Analyzer erreichen.

Zusätzlich: Debug-Mode für wazuh-modulesd nur kurzfristig aktivieren, um zu sehen, ob Subscriber-Calls überhaupt abgesetzt werden.

Lessons Learned / Best Practices

  • Nie mehrere aws-s3-Wodle-Blöcke parallel konfigurieren. Konsolidieren, sonst gewinnt „eine“ Sektion – oder keine.
  • CloudTrail immer mit only_logs_after starten, außer ihr plant bewusst einen historischen Re-Import. Sonst kann der Erstlauf riesige Backlogs bearbeiten und die operative Erwartung „Subscriber läuft auch“ wirkt gebrochen.
  • Security Hub ist nur so gut wie die Finding-Quelle: Ohne aktivierte Standards/Integrationen und ohne neue Findings bleibt Wazuh leer, obwohl SQS/Fetch „grün“ sind. ASFF ist das Datenformat, nicht CloudTrail.
  • Environment-Drift vermeiden: Profile-Fehler können durch AWS-Envvars entstehen, selbst wenn ihr auf EC2 mit Role arbeitet. Das ist besonders relevant auf Hosts, die auch „normal“ AWS CLI nutzen.
  • Transport vs. Detection trennen: Erst belegen, dass Logs ankommen (Archive/Debug), dann Regeln/Visualisierung optimieren.

Fazit

Die Kombination aus CloudTrail und Security Hub im Wazuh-aws-s3-Wodle ist grundsätzlich vorgesehen – aber nur, wenn sie sauber in einem Block umgesetzt wird und CloudTrail nicht ungebremst einen historischen Backlog abarbeitet. In der Praxis lösen only_logs_after, eine klare Pipeline-Verifikation (Security Hub → S3 → SQS → Wazuh) und ein kurzer Debug-/Archive-Nachweis fast alle „Subscriber wird übersprungen“-Szenarien. So wird aus „Fetch läuft, aber nichts kommt an“ eine belastbar überprüfbare Integration.

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/p1768988969332699