Wazuh Office365 & curl_max_size

von

Was wirklich passiert, wenn API-Antworten größer als 1 MB werden

Das <office365>-Modul von Wazuh nutzt die Office 365 Management Activity API, um Audit-Logs aus Microsoft 365 abzurufen. In produktiven Tenants taucht dabei früher oder später eine Konfigurationsoption auf, die Fragen aufwirft:

<curl_max_size>1M</curl_max_size>

Was bedeutet dieses Limit genau? Wann wird es überschritten? Und ist es gefährlich, es deutlich zu erhöhen?

Dieser Beitrag fasst die Antworten aus dem Thread zusammen und ordnet sie technisch ein.

Was ist curl_max_size?

curl_max_size ist kein Office365-spezifischer Parameter, sondern eine globale Sicherheitsbremse in Wazuh für alle Module, die HTTP-Requests über libcurl ausführen.

Ziel:

  • Schutz vor unkontrolliert großen API-Antworten
  • Begrenzung des RAM-Verbrauchs pro Request
  • Vermeidung von Instabilität bei externen APIs

Standardwert:

1 MB

Wann können Office365-API-Antworten > 1 MB werden?

Das passiert häufiger als viele erwarten, insbesondere bei:

  • Großen oder sehr aktiven Tenants
  • Abonnements wie:
    • Audit.General
    • DLP.All
    • kombinierte Audit-Subscriptions
  • Zeiträumen mit:
    • Massiven Login-Events
    • DLP-Scans
    • Admin-Aktionen
    • Security-Incidents

Die Office365 Management Activity API liefert Events in Blobs, nicht als einzeln paginierbare Datensätze mit konfigurierbarer Seitengröße.

Kann man Microsoft dazu zwingen, kleinere Antworten zu liefern?

Kurz: Nein.

  • Die API bietet keine Option, einen einzelnen Content-Blob weiter zu unterteilen.
  • Wazuh kann keine kleinere Antwort anfordern, wenn der Blob bereits erzeugt wurde.
  • Die einzige Stellschraube auf Wazuh-Seite ist:
    • Polling-Intervall
    • curl_max_size

Was passiert, wenn curl_max_size überschritten wird?

Technisch läuft es so ab:

  1. Wazuh startet einen HTTP-Request (curl)
  2. Die Antwort wächst über das konfigurierte Limit hinaus
  3. libcurl bricht den Transfer ab
  4. Wazuh:
    • verwirft die komplette Antwort
    • verarbeitet keine Events aus diesem Poll
    • setzt den Bookmark nicht erfolgreich fort

Wichtig:

  • Es gibt keine automatische Wiederholung mit kleinerem Payload
  • Die Daten werden nicht teilweise ingestiert
  • Beim nächsten erfolgreichen Poll werden neuere Events abgeholt

Wie sieht man das im Log?

In /var/ossec/logs/ossec.log erscheinen Warnungen wie:

wazuh-modulesd:office365 WARNING: Reached maximum CURL size.
Consider increasing the value of 'curl_max_size'

Mit zusätzlichem Debugging:

wazuh_modules.debug=2

werden diese Meldungen sehr deutlich und detailliert protokolliert.

Führt ein kurzes Poll-Intervall zu größeren Blobs?

Überraschenderweise: Nein, nicht zwingend.

  • Ein 1-Minuten-Intervall liegt weit unter Microsofts Throttling-Limits
    (≈ 2000 Requests/Minute/Tenant)
  • Verzögerungen von 60–90 Minuten sind bei Microsoft normal
  • Auch mehrstündige Verzögerungen kommen gelegentlich vor und sind dokumentiert

Ein längeres Poll-Intervall kann jedoch das Risiko erhöhen, dass:

  • mehr Events in einem einzelnen Blob landen
  • damit die 1-MB-Grenze überschritten wird

Ist es gefährlich, curl_max_size stark zu erhöhen (z. B. 100 MB)?

Die klare Antwort von Wazuh:

Nein – solange einzelne Logs < 64 KB bleiben.

Wichtige Details:

  • curl_max_size beeinflusst:
    • temporären RAM-Verbrauch während des HTTP-Abrufs
  • Es triggert keine weiteren internen Buffer-Limits
  • Es müssen keine anderen Wazuh-Puffer angepasst werden
  • Die kritische Grenze liegt nicht beim Blob, sondern bei:
    • Einzelnen Log-Einträgen > 64 KB (die sind problematisch)

Best Practices für produktive Umgebungen

1. curl_max_size realistisch erhöhen

Für große Tenants z. B.:

<curl_max_size>50M</curl_max_size>

oder

<curl_max_size>100M</curl_max_size>

2. RAM-Verbrauch beobachten

Vor allem bei:

  • vielen parallelen Wazuh-Modulen
  • kleinen Manager-VMs

3. Debug nur temporär aktivieren

wazuh_modules.debug=2

→ nach Analyse wieder deaktivieren

4. Office365-Ingestion nicht überoptimieren

  • Verzögerungen kommen primär von Microsoft
  • Wazuh ist selten der Engpass

Fazit

  • curl_max_size ist eine Sicherheitsgrenze, kein Funktionsfehler
  • Große Office365-Tenants überschreiten 1 MB problemlos
  • Wird das Limit erreicht:
    • geht der komplette Poll verloren
  • Das Erhöhen des Limits ist sicher, solange:
    • Logs < 64 KB bleiben
    • ausreichend RAM vorhanden ist

Für produktive M365-Integrationen ist ein höherer Wert nicht nur erlaubt, sondern oft notwendig.

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