Azure-Logs in Wazuh: Warum das Wodle in Wellen arbeitet – und wie du Spikes, Flooding & Index-Hygiene in den Griff bekommst

von

Tim hat in der Wazuh-Community ein klassisches Szenario geschildert:

  • Er sammelt Azure Application Gateway Logs (Access & Firewall) mit dem
    azure-logs Wodle.
  • Das Wodle läuft alle 5 Minuten und zieht ca. 200 GB/Tag.
  • Anfangs lief es gar nicht, jetzt läuft es – aber mit merkwürdigen Lastspitzen:
    • Mehrere Durchläufe mit wenig Traffic
    • dann plötzlich eine massive Spike in Storage-Ingress/Egress
    • dabei Agent-Buffer flooded und Rule 87813 schießt > 1 Mio Events/h.

Dazu kamen zwei zentrale Fragen:

  1. Wie merkt sich das Wodle, welche Blobs schon verarbeitet wurden – also „Bookmarking“?
  2. Wie kann man die Flut an Alerts (insbesondere Rule 87813) und die Last im Indexer besser kontrollieren?

Schauen wir uns an, was im Thread herausgearbeitet wurde – und was du davon in deinem eigenen Setup nutzen kannst.

1. Setup: Azure Storage + azure-logs Wodle

Tim nutzt das azure-logs Wodle in der Storage-Variante (nicht Log Analytics):

<wodle name="azure-logs">
  <disabled>no</disabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>

  <storage>
    <auth_path>/var/ossec/wodles/credentials/azure-appgw_auth</auth_path>
    <tag>azure-appgw-activity</tag>

    <container name="insights-logs-applicationgatewayaccesslog">
      <blobs>.json</blobs>
      <content_type>json_inline</content_type>
      <time_offset>30d</time_offset>
    </container>

    <container name="insights-logs-applicationgatewayfirewalllog">
      <blobs>.json</blobs>
      <content_type>json_inline</content_type>
      <time_offset>30d</time_offset>
    </container>
  </storage>
</wodle>

Wichtige Punkte:

  • Interval 5m → alle 5 Minuten werden neue Blobs in den Containers geprüft.
  • time_offset 30d → beim Start sollen bis zu 30 Tage rückwirkend geholt werden.
  • Wazuh-Version: 4.14.0
  • Wodle läuft zunächst auf einem Agent als „Puffer“ zwischen Azure und Manager.

Er hat später die Activity Logs aus der Sammlung entfernt und nur noch Firewall-Logs gelassen – das Volumen sank auf etwa 1/10.
Trotzdem blieben die immer größer werdenden Spikes im Storage-Traffic.

2. Performance-Spikes & Flooding: Was steckt dahinter?

Tim beobachtet zwei Dinge:

  1. Eskalierende Spikes im Storage-Traffic, obwohl Azure selbst kontinuierlich und relativ gleichmäßig Logs in den Storage schreibt.
  2. Flooding-Meldungen auf Agent-Seite: der Agent-Queue/Client-Buffer wird immer wieder überlaufen.

[Javier Medeot] erklärt dazu:

  • Die Spikes können zwei Ursachen haben:
    1. Azure liefert Daten in „Batches“, die zum Zeitpunkt vorheriger Abfragen einfach noch nicht sichtbar waren.
    2. Oder: das Fortschritts-Tracking (Bookmarking) funktioniert nicht korrekt, sodass Daten mehrfach neu verarbeitet werden.
  • Die Flooding-Warnungen kommen vom Anti-Flooding-Mechanismus des Wazuh Agents:
    • Er schützt Manager/Indexer davor, von Events überrollt zu werden.
    • Man kann events_per_second und queue_size tunen.
    • Aber: Den Buffer komplett zu deaktivieren wird ausdrücklich nicht empfohlen.

Javier empfiehlt:

  • wazuh_modules.debug=2 in local_internal_options.conf setzen
    → um detailliertere Logs des azure-logs-Moduls zu erhalten.
  • Gezieltes Filtern: z. B. über <storage><container><path>…</path></container> nur bestimmte Blobs holen.
  • Testweise:
    • time_offset verkürzen
    • interval verlängern
      → um zu sehen, ob die Spikes „resetten“ oder weiter eskalieren.

3. Bookmarking: Wie weiß das Wodle, welche Blobs schon dran waren?

Die spannende Frage: „Sieht das Wodle alte Blobs jedes Mal wieder – oder nur neue?“

Javier schaut dazu direkt in den Wazuh-Code der Storage-Integration und fasst zusammen:

  • Das Wodle nutzt eine lokale Datenbank:
    /var/ossec/wodles/azure/azure.db
  • Beim Durchlauf prüft es pro Blob u. a.:
    • last_modified des Blobs
    • bereits verarbeitete Zeitfenster

Ein Blob wird übersprungen, wenn:

  • reparse = false und
  • der Blob entweder:
    • älter ist als das gewünschte desired_datetime
      oder
    • in einem bereits verarbeiteten Zeitraum liegt.

Im Log sollte man dazu Zeilen sehen wie:

Storage: Skipping blob ...

Empfehlung:

  • Prüfen, ob azure.db existiert und regelmäßig aktualisiert wird.
  • In den Debug-Logs nach Hinweisen auf:
    • Datenbankfehler
    • merkwürdige Sprünge in den Zeitstempeln
    • unerwartete Reparse-Szenarien

Tim hat bestätigt:

  • azure.db ist vorhanden und wird aktualisiert.
  • Er überlegt, den Code selbst mit weiteren Debug-Ausgaben zu versehen – und die Erkenntnisse zurück in die Wazuh Codebase zu tragen.

4. Agent vs. Manager: Wo sollte das azure-logs Wodle laufen?

Tim nutzt einen Agent als „Zwischenstufe“. Die Frage:

„Wäre es besser, das Wodle direkt auf dem Manager laufen zu lassen – ist der dann weniger flood-anfällig?“

Die Antwort ist eher architektonisch:

  • Die Flooding-Problematik entsteht, wenn:
    • mehr Events erzeugt werden, als die nächste Stufe (Manager/Indexer) verkraftet.
  • Ob das Wodle auf einem Agent oder direkt auf dem Manager läuft, ändert an dieser grundsätzlichen Physik wenig:
    • Es kann hilfreich sein, einen Agent als Puffer zu haben.
    • Aber wenn das Volumen exorbitant hoch ist, hilft eigentlich nur:
      • Filterung / Selektion der Logs
      • Tuning des Agents & Managers
      • oder Anpassungen an der Erfassungsstrategie (time_offset, Container/Paths etc.)

5. Regel 87813: 1 Mio Events pro Stunde – und was man dagegen tun kann

Tim hat noch eine zweite Baustelle:

„Triggert Rule 87813 bei jedem Azure-Storage-Event?
Die feuert über 1 Million Mal pro Stunde.
Kann ich das Level senken? Oder die Alerts in ein eigenes Index-Muster auslagern?“

5.1 Was macht Rule 87813?

  • Sie triggert bei jedem Azure Storage Operation Event, also wirklich breit.
  • Man kann sie:
    • per Custom Rule überschreiben (anderes Level, andere Gruppen)
    • oder durch eigene feinere Regeln ersetzen.

5.2 Eigener Index für „Large Ingest“-Regel 87813

Javier zeigt eine elegante Lösung über die Filebeat-Ingest-Pipeline:

In /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json kann man z. B. zwei date_index_name-Blöcke einbauen:

{
  "date_index_name": {
    "if": "ctx?.rule?.id == '87813'",
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "{{fields.index_prefix}}large-ingest-",
    "index_name_format": "yyyy.MM.dd",
    "ignore_failure": false
  }
},
{
  "date_index_name": {
    "if": "ctx?.rule?.id != '87813'",
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "{{fields.index_prefix}}",
    "index_name_format": "yyyy.MM.dd",
    "ignore_failure": true
  }
}

Wichtig:

  • Das sind zwei getrennte Prozessoren mit if-Bedingung.
  • Nur einer von beiden läuft pro Dokument:
    • Rule-ID 87813 → landet in Indexen mit Prefix
      wazuh-alerts-4.x-large-ingest-YYYY.MM.DD
    • alle anderen → wie gewohnt in
      wazuh-alerts-4.x-YYYY.MM.DD

Danach:

  1. Pipeline neu laden: filebeat setup --pipelines --modules wazuh
  2. In OpenSearch/Wazuh Indexer ein neues Index-Pattern anlegen:
    wazuh-alerts-4.x-large-ingest-*
  3. Für dieses Index-Pattern eine eigene ILM-Retention definieren:
    • z. B. sehr kurze Aufbewahrung für Massenevents
    • während „normale Alerts“ länger vorgehalten werden.

Damit erreichst du:

  • Rule 87813 „versaut“ nicht mehr dein Hauptindex-Volumen.
  • Du kannst sie getrennt betrachten, analysieren – oder frühzeitig wegrotieren.

Antwort auf Tims Frage:
Nein, die Events werden nicht doppelt geschrieben.
Das Dokument landet entweder im „large-ingest“-Index oder im Standard-Index – je nach rule.id.

6. Best Practices aus dem Thread – zusammengefasst

Für das azure-logs Wodle (Storage):

  • wazuh_modules.debug=2 aktivieren und Logs lesen:
    • „Storage: Skipping blob…“
    • Hinweise auf DB-Probleme / azure.db
  • azure.db regelmäßig prüfen:
    • existiert?
    • wird aktualisiert?
    • nicht versehentlich gelöscht oder überschrieben?
  • Logvolumen kontrollieren:
    • time_offset nicht unnötig hoch setzen
    • Container gezielt auswählen
    • ggf. Pfade / Präfixe einschränken
  • Mit Interval & time_offset experimentieren:
    • kürzere lookback-Fenster
    • längere Pausen zwischen Läufen

Für Flooding & Alert-Volumen:

  • Anti-Flooding NICHT deaktivieren:
    • lieber events_per_second & queue_size feinjustieren.
  • Massenregeln wie 87813:
    • per Custom Rule weichzeichnen (Level runter)
    • oder via Pipeline in einen separaten Index abzweigen.

7. Fazit

Der Thread zeigt sehr schön:

  • Das Problem sitzt selten in „Azure macht irgendwas Seltsames“, sondern:
    • in Bookmarking-Details,
    • Massenevents,
    • und dem Zusammenspiel von Agent → Manager → Indexer.
  • Wazuh bietet die Bausteine, um damit umzugehen:
    • azure.db als Fortschrittsdatenbank,
    • Debug-Logging im azure-logs-Modul,
    • Anti-Flooding im Agent,
    • und flexible Ingest-Pipelines, um Event-Hotspots (wie Rule 87813) auszulagern.

Tim geht jetzt sogar den nächsten Schritt und will den Code selbst instrumentieren und zurück in die Community tragen – genau so wächst ein Ökosystem.

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

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …