Warum mein Azure-Logs-Wodle in GCC High plötzlich keine Events mehr holt (und warum Debug-Level „2“ nicht die eigentliche Lösung ist)

von

Ausgangslage: Azure Logs laufen… und dann plötzlich nicht mehr

User m letormd hatte eine Test-Wazuh-Umgebung (4.14.1), in der Azure-Logs zunächst sauber importiert wurden.
Später – auch auf einer frischen Neuinstallation – passierte Folgendes:

  • Azure-Logs werden nicht mehr importiert
  • Im Log taucht nur eine recht nichtssagende Meldung auf: ERROR: Couldn't get the token for authentication.

Spannend wurde es, als er Debugging aktivierte:

# /var/ossec/etc/internal_options.conf
wazuh_modules.debug=2

Subjektiver Eindruck: „Mit Debug an scheint es plötzlich zu funktionieren, ohne nicht.“
Das sieht so aus, als ob Debugging das Problem „fixt“ – tut es aber nicht wirklich.

Schritt 1: Debug an – aber was passiert wirklich?

Mit Debugging auf Stufe 2 sieht man z. B. im ossec.log:

wazuh-modulesd:azure-logs INFO  Azure Graph starting.
wazuh-modulesd:azure-logs DEBUG Graph: Using the auth file /var/ossec/wodles/credentials/graph_credentials for authentication
wazuh-modulesd:azure-logs INFO  Graph: Getting authentication token.
ERROR: Couldn't get the token for authentication.

Wichtig:

  • Debugging ändert nicht das Verhalten des Azure-Wodles.
  • Es schreibt nur mehr Details ins Log (z. B. welches Credential-File verwendet wird).
  • Die Token-Anfrage schlägt mit und ohne Debug fehl – man sieht es nur besser.

Also: nicht vom „Mehr Log-Ausgabe = es lebt wieder“ täuschen lassen.

Schritt 2: Token-Request manuell nachbauen

Um zu prüfen, ob das Problem bei Wazuh oder bei Azure liegt, schlug Christian vor, den Token-Request per cURL direkt am Wazuh-Server zu testen.

Für die globale Azure-Cloud sähe das z. B. so aus (vereinfacht):

curl -X POST "https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<CLIENT_ID>" \
  -d "client_secret=<CLIENT_SECRET>" \
  -d "scope=https://api.loganalytics.io/.default"

Aber:
Der User arbeitet nicht im Commercial Tenant, sondern in GCC High.

Damit ändern sich die Endpunkte:

  • Login: https://login.microsoftonline.us
  • Graph: https://graph.microsoft.us
  • Log Analytics: https://api.loganalytics.us

Also neuer Test, z. B.:

curl -X POST "https://login.microsoftonline.us/<TENANT_ID>/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=<CLIENT_ID>" \
  --data-urlencode "client_secret=<CLIENT_SECRET>" \
  --data-urlencode "scope=https://graph.microsoft.us/.default"

Trotz Anpassungen: Es gab HTTP-Fehler (u. a. 411 Length Required).
Parallel dazu zeigte der manuelle Aufruf des Wodles:

/var/ossec/wodles/azure/azure-logs \
  --log_analytics \
  --la_auth_path graph_credentials \
  --la_tenant_domain '…' \
  --la_tag azure-activity \
  --la_query "AzureActivity" \
  --workspace example-workspace \
  --la_time_offset 50d \
  --debug 2 \
  --reparse

immer wieder:

Log Analytics: Getting authentication token.
ERROR: Couldn't get the token for authentication.

Damit war klar:
Credentials stimmen, aber der Weg, wie der Wodle Azure anspricht, ist falsch.

Schritt 3: Blick in den Code – hartekodierte Public-Cloud-URLs

Im Wazuh-Quellcode für das Azure-Wodle (unter /var/ossec/wodles/azure) fiel dann der eigentliche Übeltäter auf:
Die URLs sind für die globale Azure-Cloud hart verdrahtet.

Beispiele (Version 4.14.1):

# azure_utils.py
URL_LOGGING = 'https://login.microsoftonline.com'

# azure_services/analytics.py
URL_ANALYTICS = 'https://api.loganalytics.io'

# azure_services/graph.py
URL_GRAPH = 'https://graph.microsoft.com'

Für GCC High hätten sie lauten müssen:

URL_LOGGING   = 'https://login.microsoftonline.us'
URL_ANALYTICS = 'https://api.loganalytics.us'
URL_GRAPH     = 'https://graph.microsoft.us'

Es gibt sogar ein offenes GitHub-Issue dazu:

„Azure wodle uses hardcoded cloud URLs“ (Issue #29696)

Kurz gesagt:
Der Azure-Wodle berücksichtigt derzeit keine National-Cloud-Varianten wie GCC High, im Gegensatz zu anderen Modulen (Office365, MS-Graph), die bereits einen api_type-Schalter besitzen.

Schritt 4: Der Workaround – URLs von Hand anpassen

Die Lösung im Thread war pragmatisch – aber effektiv:

  1. Auf dem Wazuh-Manager nach den .us-Endpunkten suchen: cd /var/ossec/wodles/azure grep -r ".us"
  2. In 4.14.1 gab es noch keine .us-Endpunkte, also wurden die drei Konstanten editiert: # azure_utils.py URL_LOGGING = 'https://login.microsoftonline.us' # azure_services/analytics.py URL_ANALYTICS = 'https://api.loganalytics.us' # azure_services/graph.py URL_GRAPH = 'https://graph.microsoft.us'
  3. Wazuh-Manager neu starten, Azure-Wodle erneut laufen lassen.

Ergebnis:

„it worked!“

Die Azure-Logs wurden wieder erfolgreich importiert – Token-Error verschwunden.

5. Wichtige Hinweise & Stolperfallen

5.1. Änderungen im Code überleben keine Updates

Die bearbeiteten Dateien liegen im Wazuh-Installationsbaum:

  • /var/ossec/wodles/azure/azure_utils.py
  • /var/ossec/wodles/azure/azure_services/analytics.py
  • /var/ossec/wodles/azure/azure_services/graph.py

Bei einem Wazuh-Upgrade können diese Dateien einfach überschrieben werden.
Heißt:

  • Nach einem Update unbedingt prüfen, ob die URLs noch passen.
  • Im Zweifel die Anpassung erneut einpflegen (oder diff/Backup parat haben).

5.2. Andere Module sind schon weiter

Interessanter Vergleich:

  • Office 365 Modul: unterstützt api_type (commercial, gcc, gcc-high)
  • MS-Graph Modul: unterstützt api_type (global, gcc-high, dod)
  • Azure-Log-Analytics Wodle: aktuell keine solche Option, nur fest verdrahtete Public-Cloud-URLs

Genau deswegen war hier ein manueller Fix nötig.

6. Best Practices für Azure-Integrationen (vor allem in National Clouds)

  1. Cloud-Umgebung kennen
    • Global (Public), GCC, GCC High, DoD, China, etc.
    • Zu jedem gibt es eigene login, graph, loganalytics-Endpunkte.
  2. Token-Flow immer auch manuell testen
    • Per curl vom Wazuh-Server
    • So erkennst du, ob es ein Problem mit:
      • Credentials,
      • Endpoints
      • oder dem Wodle-Code selbst ist.
  3. Debugging gezielt nutzen, aber nicht dauerhaft
    • wazuh_modules.debug=2 hilft enorm bei der Fehlersuche.
    • Danach wieder auf Standard zurück, um Disk-Usage & Log-Noise zu reduzieren.
  4. Nach Updates: Integrationen prüfen
    • Gerade bei „Spezial-Workarounds“ wie geänderten URLs.
    • Changelog und bekannte Issues im Blick behalten (z. B. #29696).

7. Fazit

Was wie ein klassischer „Wazuh spinnt, wenn Debug aus ist“-Bug wirkte, war am Ende:

  • Ein harcoded Public-Cloud-Design des Azure-Wodles,
  • das in einer GCC High-Umgebung zu Token-Fehlern führte,
  • und sich erst durch einen Blick in den Python-Code + Microsofts National-Cloud-Doku entlarven ließ.

Der Weg zur Lösung sah so aus:

  1. Debug aktivieren → mehr Logdetails
  2. Manuelle Token-Tests → bestätigen, dass der Flow grundsätzlich okay sein sollte
  3. Code prüfen → feststellen, dass falsche Endpoints verwendet werden
  4. URLs auf GCC-High-Endpoints anpassen → Import funktioniert wieder

Wenn du selbst Azure-Integrationen in einer National-Cloud betreibst (GCC, GCC High, DoD…), lohnt sich ein kurzer Blick in /var/ossec/wodles/azure – und ggf. derselbe Workaround, bis der Wodle offiziell api_type oder Ähnliches unterstützt.

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