Wazuh + MISP für Firewall-Logs über Rsyslog: IP-IOC-Lookups statt nur Hash-Abgleich

von

Einleitung

Viele Wazuh–MISP-Anleitungen demonstrieren die Integration anhand von Datei-Hashes (z. B. FIM-basierte Use-Cases). In realen SIEM-Setups – besonders mit Firewalls – ist jedoch häufig der IP-basierte IOC-Abgleich entscheidend: „Ist die zugelassene oder geblockte Gegenstelle malicious?“ Die gute Nachricht: Aus Sicht des Wazuh Managers macht es keinen Unterschied, ob Logs direkt vom Agent kommen oder über eine Zwischenstation wie rsyslog gesammelt und dann per Wazuh Agent als Datei eingelesen werden – entscheidend ist, dass Wazuh daraus Alerts mit extrahierten IP-Feldern erzeugt. Wazuh Dokumentation+2Wazuh Dokumentation+2

Dieser Beitrag zeigt, wie man eine Architektur „Firewall → rsyslog → Wazuh Agent → Wazuh Manager → MISP“ so aufbaut, dass MISP IP-Attribute prüft (nicht nur Hashes), und woran es liegt, wenn aktuell „nur Hash“ funktioniert.

Ausgangslage / Problemstellung

Ein Setup sammelt Firewall-Logs zentral via rsyslog. Auf dem rsyslog-Server läuft ein Wazuh Agent, der die Logdatei überwacht und Events an den Manager sendet. MISP ist bereits integriert, aber:

  • Der Abgleich funktioniert nur für Hashes (klassischer FIM-Demo-Flow).
  • Gewünscht ist: Firewall-Events sollen IPs (src/dst/allowed traffic) gegen MISP-IOCs prüfen.
  • Decoder/Parsing der Firewall-Logs sei „in Ordnung“ – trotzdem werden IPs offenbar nicht von der Integration gegriffen.

In der Praxis liegt das selten an „Wazuh kann das nicht“, sondern fast immer an (a) fehlenden/uneinheitlichen IP-Feldern im Alert oder (b) Integrationsskript/Regeln sind nur auf Hash-Use-Cases ausgelegt (wie in vielen offiziellen/inoffiziellen Guides). MISP Plattform für Bedrohungsinformationen+2GitHub+2

Technische Analyse

1) Wazuh sieht Firewall-Logs über rsyslog wie jeden anderen Event-Stream

Wazuh sammelt Logs entweder direkt per Syslog oder über einen zentralen Logging-Server (rsyslog/Logstash), auf dem ein Agent installiert ist und Dateien über <localfile> überwacht. Genau dieses Muster ist in der Wazuh-Doku als valid beschrieben. Wazuh Dokumentation+2Wazuh Dokumentation+2

Das heißt: Ja, die Architektur ist grundsätzlich korrekt. Wenn der Manager Alerts erzeugt, ist der Weg bis Wazuh sauber.

2) Warum „nur Hash“? Viele MISP–Wazuh Beispiele sind absichtlich hash-zentriert

Die aktuelle offizielle MISP-Anleitung zur Wazuh-Integration fokussiert (laut Zielsetzung) auf File Hashes: Wazuh erkennt eine Dateiänderung/Neuanlage und fragt Hashes gegen MISP ab. MISP Plattform für Bedrohungsinformationen+1
Auch das MISP GitHub-Repo zur Wazuh-Integration beschreibt als Kernfunktion den Hash-Lookup via Skript. GitHub+1

Wenn du dieses Skript 1:1 übernommen hast, ist es erwartbar, dass es IPs gar nicht sucht, weil es nur Hash-Felder aus dem Alert-JSON ausliest.

3) IP-Lookups funktionieren nur, wenn Wazuh die IPs als Felder im Alert hat

Selbst mit einem IP-fähigen Skript gilt: Die Integration kann nur das prüfen, was im Alert strukturiert vorliegt. Das erfordert entweder:

  • passende Decoder/Rules, die z. B. srcip, dstip (oder vendor-spezifische Felder) setzen, oder
  • eine normalisierte Extraktion aus dem raw message.

Wazuh empfiehlt bei Format-/Decoder-Fragen das iterative Testen mit wazuh-logtest. GitHub+1

Lösung / Best Practices

Schritt 1: Firewall-Logs sauber einsammeln (rsyslog → Datei → Agent <localfile>)

Auf dem rsyslog-Server sollte der Agent die Logdatei überwachen. Das ist Standard über <localfile>. Wazuh Dokumentation+1

Beispiel (Agent ossec.conf auf dem rsyslog-Server):

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/firewall/firewall.log</location>
</localfile>

Wichtig ist weniger der Pfad, sondern dass die Events konsistent ankommen und sich dekodieren lassen.

Schritt 2: Decoder/Rules so bauen, dass srcip/dstip im Alert stehen

Für MISP-IP-Lookups brauchst du im Alert verlässliche Felder. Zielbild:

  • srcip und/oder dstip (oder data.srcip/data.dstip – je nach Ruleset)
  • idealerweise zusätzlich Port/Action (ALLOW/DENY) zur Priorisierung

Wenn „decoder is fine“, prüfe trotzdem im wazuh-logtest, ob die IPs tatsächlich als Felder extrahiert werden (Phase 2 Output). GitHub+1

Schritt 3: Integration so anpassen, dass sie IP-Attribute in MISP abfragt

Wenn du die MISP-Anleitung von Oktober 2025 umgesetzt hast, ist das Skript sehr wahrscheinlich auf Hash-Attribute ausgelegt. MISP Plattform für Bedrohungsinformationen+1
Für Firewall-Use-Cases braucht es eine Erweiterung der Logik:

  • Aus dem Wazuh-Alert JSON die IP(s) auslesen (srcip, dstip, ggf. data.srcip, data.dstip)
  • In MISP nach Attributen vom Typ ip-src, ip-dst oder generisch ip suchen
  • Treffer (Event-ID/Attribute/Tags) in den Wazuh-Alert zurückschreiben oder eine neue Alert-Routine triggern

Viele Community-Skripte beschreiben genau dieses Prinzip: „query MISP using IP addresses found in Wazuh alerts“. GitHub+1
Offiziell ist MISP in Wazuh nicht „out of the box“ als Standardintegration enthalten – es ist typischerweise eine Custom Integration über das Integrator-Modul/Skripting. Google Gruppen+1

Praktische Best Practice:

  • Zwei Modi im Skript: hash_lookup (FIM) und ip_lookup (Firewall/Netzwerk)
  • Whitelist/Noise-Filter: private RFC1918-Ziele oder bekannte Update-CDNs nicht ständig abfragen
  • Rate-Limits/Cache: MISP nicht bei 3k EPS für jede IP synchron „hammern“; lieber Cache (TTL) oder nur für hochpriorisierte Events

Schritt 4: Integration nur für relevante Alerts triggern (nicht für jedes Firewall-Log)

Damit MISP nicht zur Bottleneck-Komponente wird, sollte die Integration nur bei passenden Regeln laufen:

  • „Deny“-Events
  • „Allow“ nur bei riskanten Ports/Geos/Anomalien
  • Events, bei denen srcip/dstip valide sind

Das erreichst du über Regelgruppen/Rule-IDs und Integration-Matching im Wazuh Integrator-Konzept (Custom Integration), anstatt „alles“ zu prüfen. Google Gruppen+1

Lessons Learned / Best Practices

  • Architektur ist okay: rsyslog als Relay + Agent <localfile> ist ein gängiges Muster und wird von Wazuh dokumentiert. Wazuh Dokumentation+1
  • „Nur Hash“ ist normal, wenn du die MISP-Referenzintegration unverändert übernommen hast – sie ist in vielen Quellen bewusst hash-zentriert. MISP Plattform für Bedrohungsinformationen+1
  • IP-IOC braucht Felder, nicht nur Raw-Text: ohne srcip/dstip wird ein Skript zwangsläufig blind oder unzuverlässig.
  • Skalierung: IP-Lookups müssen gedrosselt/gefiltet werden (Cache/TTL, nur relevante Events), sonst wird MISP bei hoher EPS zum Engpass – besonders in Firewall-Szenarien.
  • Debugging-Standard: wazuh-logtest nutzen, um zu prüfen, ob IP-Felder wirklich extrahiert werden. GitHub+1

Fazit

Ja: Firewall-Logs, die über rsyslog gesammelt und vom Wazuh Agent eingelesen werden, können von MISP geprüft werden – wenn Wazuh daraus Alerts mit strukturierten IP-Feldern erzeugt und das Integrationsskript tatsächlich IP-Attribute in MISP abfragt. Dass aktuell „nur Hash“ geprüft wird, ist ein typisches Indiz dafür, dass eine hash-fokussierte Referenzintegration (FIM-Demo) übernommen wurde. Der nachhaltige Weg ist: IPs sauber decodieren (srcip/dstip), Integration gezielt nur für relevante Alerts triggern und das Skript um IP-Lookups (ip-src/ip-dst) erweitern – inklusive Caching/Filterung, damit das Ganze in Produktions-EPS stabil bleibt.

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