Wazuh in verteilten Umgebungen effizient mit MISP integrieren: IOC-Sync nach SQLite statt API-Call pro Alert

Einleitung

Die Integration von Threat Intelligence aus MISP in Wazuh ist ein typischer „nächster Schritt“, sobald Detection und Alerting stabil laufen: Indicators aus einem (privaten) TAXII-Feed landen in MISP, und Wazuh soll bei passenden Observables (Hashes, IPs, Domains, URLs) automatisch anreichern und zusätzliche Alerts erzeugen. In produktiven, verteilten Wazuh-Architekturen entsteht dabei schnell ein Skalierungsproblem: Wenn jeder relevante Alert eine MISP-API-Abfrage auslöst, steigen Latenz, CPU-Last und API-Rate-Limits auf beiden Seiten.

Die gute Nachricht: Man muss sich nicht zwischen „Wazuh Storage“ und „Dauer-CPU“ entscheiden. Der praxistaugliche Mittelweg ist ein periodischer IOC-Sync von MISP in einen lokalen Lookup-Store auf dem Wazuh Manager (z. B. SQLite) und ein schneller Offline-Abgleich pro Alert. Genau dieses Pattern wurde im Thread beschrieben und lässt sich sauber mit dem Wazuh Integrator-Modul umsetzen.

Ausgangslage / Problemstellung

Produktionsumgebung: Distributed Wazuh Architecture
Ziel: Wazuh ↔ MISP Integration, MISP bezieht Intel über privaten TAXII Server
PoC vorhanden: Custom Python Script, das FIM- und Webserver-Alerts an MISP sendet, dort Hash/IP prüft und bei Treffer eine Zusatzmeldung zurück an Wazuh erzeugt (Custom Rules auf Response-Logs)
Herausforderung: Sehr hohe Alert-Volumes → „API call per alert“ skaliert schlecht und erzeugt Last/Latency

Zusatzanforderung: Unterstützung weiterer IOC-Typen (Domains/URLs/Patterns), ohne den Integrator zu überfahren.

Technische Analyse

1) Warum „API pro Alert“ in Wazuh schnell zum Bottleneck wird

Wazuhs Integrator-Modul ist dafür da, Alerts an externe Systeme weiterzugeben oder externe Abfragen anzustoßen. Es ist jedoch nicht als High-Throughput-Stream-Processor gedacht. Wenn man zu viele Alerts durch eine Integration laufen lässt (z. B. niedrige <level>-Schwelle oder keine Filter), können Queueing, Retries/Timeouts und Script-Laufzeiten die Integrator-Pipeline überlasten – unabhängig davon, ob MISP schnell antwortet. Die Dokumentation zeigt explizit, dass man Integrationen mit Filtern wie <group> oder <rule_id> eingrenzen sollte.

2) Periodischer IOC-Sync + lokaler Lookup ist das skalierbare Design

Das Thread-Ergebnis beschreibt eine zweigeteilte Lösung:

Sync-Service: Pullt regelmäßig IOCs aus MISP und speichert sie lokal in SQLite (z. B. stündlich), startet automatisch nach Reboot.
Integration-Script: Wird durch Wazuh Integrator getriggert, extrahiert Observables aus dem Alert (srcip/dstip/hashes/domains/URLs) und prüft diese gegen die lokale SQLite-Datenbank. Treffer werden als neue Events in die Analysis Queue geschrieben → Custom Rule erzeugt Alarm im Dashboard.

Dieses Muster reduziert die externen API-Calls drastisch (von „pro Alert“ auf „pro Sync-Intervall“) und macht den Abgleich pro Alert sehr schnell (lokale DB). In einem dazu passenden Referenz-Repo ist dieses Vorgehen Schritt für Schritt beschrieben.

3) TAXII ist upstream – für Wazuh zählt der stabile IOC-„Snapshot“

Dass MISP seine Intel aus einem privaten TAXII-Server bezieht, ändert am Wazuh-Design nichts: Wazuh sollte nicht direkt TAXII sprechen müssen. MISP ist die zentrale Normalisierung/Distribution. Der Wazuh Manager hält lokal einen zeitlich konsistenten Snapshot der IOCs (SQLite), der periodisch aktualisiert wird. Das entkoppelt Wazuh von TAXII-Latenzen und MISP-Lastspitzen.

Lösung / Best Practices

Schritt 1: IOC-Sync als separater Service (MISP → SQLite)

Implementieren Sie ein eigenes Sync-Script, das aus MISP alle relevanten Attribute zieht (Hashes, IPs, Domains, URLs, ggf. Patterns) und dedupliziert in SQLite speichert.
Frequenz pragmatisch wählen (z. B. 60 Minuten). Für viele Umgebungen reicht das, weil Threat Intel typischerweise nicht sekündlich kritisch ist, aber die Plattform stabil bleiben muss.
Wichtig: „Delta“-Sync bevorzugen (nur neue/aktualisierte IOCs), um IO und Laufzeit zu reduzieren.

Als Blaupause kann das veröffentlichte Beispielrepo dienen, das genau diesen Ansatz (SQLite Sync + Lookup) beschreibt.

Schritt 2: Integration-Script auf lokale DB statt MISP-API

Statt MISP per REST pro Alert zu befragen:

Alert aus JSON einlesen
Observable Extraction: srcip, dstip, Hash-Felder (z. B. sha256), Domain/URL-Felder aus Web-Logs
Lookup in SQLite über normalisierte Tabellen (z. B. ioc_type + ioc_value + confidence/tags/last_seen)
Bei Treffer: Ergebnislog in Wazuh Analysis Queue schreiben (damit Ruleset greift)

Das Grundmuster entspricht der offiziellen Wazuh-„Custom integration“-Mechanik: Integrator triggert Script, Script schreibt Ergebnis zurück → Rule generiert Alarm.

Schritt 3: Integrator richtig „drosseln“: Filter statt niedriger Level

Damit der Integrator nicht überrannt wird:

Nutzen Sie in ossec.conf im <integration>-Block gezielte Filter:
- <rule_id> für exakt die Rules, die IOC-Abgleich brauchen
- oder <group> für dedizierte Gruppen (z. B. web,, syscheck,, ids,)
- <level> nur als grobe Schranke, nicht als Hauptfilter

Die Wazuh-Doku zeigt die verfügbaren Optionen (u. a. level, group, rule_id, event_location, alert_format, timeout, retries).

Schritt 4: URL- und Domain-Matching robust umsetzen

URL-Erkennung ist fehleranfällig, wenn man „patterns“ unstrukturiert matcht. Bewährte Praxis:

Zuerst normalisieren:
- Scheme/Host/Path trennen
- Query-Strings optional entfernen oder separat behandeln
- Lowercasing von Hostnames
- Punycode/Unicode sauber handhaben
Zwei Lookup-Ebenen:
1. Domain/Hostname gegen Domain-IOCs
2. Voll-URL (oder URL-Path-Suffix) gegen URL-IOCs
Optional: „Suffix-Matching“ für Subdomains (z. B. *.example.com) – aber nur, wenn MISP-Attributes das sinnvoll abbilden.

Schritt 5: Betrieb & Sicherheit

DB-Größe: SQLite ist für Lookup sehr schnell, aber Sie brauchen Retention/Pruning (z. B. IOC TTL, last_seen).
Integrity: Sync-Prozess signieren/monitoren, damit „IOC poisoning“ (Supply Chain in TI) nicht blind durchschlägt.
Observability: Metriken zu Sync-Dauer, IOC-Anzahl, Lookup-Rate, Trefferquote, Queue-Lag.
Isolation: MISP API Key nur im Sync-Service, nicht im per-alert Integration-Script (Prinzip der minimalen Rechte).

Lessons Learned / Best Practices

Der richtige Skalierungshebel ist Entkopplung: regelmäßiger Sync + lokaler Lookup ist stabiler als API per Alert.
Der Wazuh Integrator muss hart gefiltert werden (Gruppen/Rule-IDs), sonst wird er bei hohem Event-Flow zum Bottleneck.
URL/Domain-Matching braucht Normalisierung und klare Matching-Strategie, sonst explodieren False Positives.
Ein Threat-Intel-Abgleich ist nur so gut wie seine Datenhygiene (Dedup, TTL, Confidence/Tags, Audit).

Fazit

In einer produktiven, verteilten Wazuh-Architektur ist „MISP API call pro Alert“ selten nachhaltig. Das skalierbare Muster ist ein periodischer IOC-Sync (MISP → SQLite auf dem Manager) und ein lokaler, schneller Abgleich im Integrations-Script, das nur für gezielt gefilterte Alerts läuft. Dadurch sinkt die externe Last drastisch, die Detection wird deterministischer, und Sie gewinnen Kontrolle über Retention, Normalisierung und Performance-Tuning – ohne auf MISP/TAXII-Threat-Intel verzichten zu müssen.