Wazuh-IoCs automatisiert an Palo Alto übergeben: Zwei belastbare Integrationsmuster für Blocklisten und Dynamic Address Groups

Einleitung

In vielen Wazuh-Umgebungen endet die Erkennung nicht beim Alerting. Sobald Wazuh belastbare Indicators of Compromise wie Quell-IP-Adressen, Ziel-IP-Adressen oder andere verifizierte Netzwerkindikatoren erkennt, entsteht schnell der Wunsch, diese Informationen unmittelbar für Containment-Maßnahmen auf der Firewall zu nutzen. Genau an dieser Stelle ist die Integration mit Palo Alto Networks besonders interessant: Die Firewall kann dynamische Listen importieren oder IPs samt Tags per API übernehmen und sofort in Security Policies verwenden. Wazuh bringt mit Active Response und dem Integrator-Modul bereits die notwendigen Bausteine mit, um solche Abläufe kontrolliert zu automatisieren.

Ausgangslage / Problemstellung

Die Anforderung ist klar: Wazuh erzeugt Alerts, einzelne davon enthalten verwertbare IoCs, und diese sollen ohne manuelle Zwischenschritte auf Palo Alto Firewalls durchgesetzt werden. Typischerweise geht es dabei um IP-Adressen aus bestätigten Erkennungen, etwa bei Brute-Force-Angriffen, Command-and-Control-Kommunikation, Scans oder Threat-Intel-Matches. Das Ziel ist nicht primär Log-Weiterleitung von Palo Alto nach Wazuh, sondern die Gegenrichtung: Wazuh erkennt, Palo Alto blockiert. Für diese Aufgabe haben sich in der Praxis zwei Architekturansätze herauskristallisiert: eine dateibasierte Übergabe über eine External Dynamic List und eine API-basierte Übergabe über Dynamic Address Groups. Beide Modelle lassen sich mit Wazuh-seitiger Logik, Regelgruppierung und zeitgesteuerter Rücknahme kombinieren.

Technische Analyse

Wazuh selbst blockiert nicht nativ auf Palo Alto, stellt aber zwei geeignete Integrationspfade bereit. Der erste ist Active Response. Dieses Modul führt Aktionen anhand definierter Regeln aus und unterstützt auch zustandsbehaftete Responses mit Timeout und Rücknahme. Für benutzerdefinierte Skripte verlangt Wazuh, dass die Aktion den JSON-Input verarbeitet und bei stateful Workflows sowohl add– als auch delete-Operationen unterstützt. Die Rücknahme wird über timeout_allowed im <command>-Block und <timeout> im <active-response>-Block gesteuert.

Der zweite Pfad ist das Wazuh-Integrator-Modul. Dieses kann Alerts im JSON-Format an externe APIs oder eigene Integrationen weiterreichen. In ossec.conf lassen sich dafür custom-*-Integrationen definieren, die gezielt nur bestimmte Gruppen oder Mindest-Level verarbeiten. Das ist sinnvoll, wenn nicht jeder Alert zu einer Firewall-Aktion führen soll, sondern nur sauber klassifizierte und angereicherte Erkennungen.

Auf Palo-Alto-Seite unterscheiden sich die beiden Zielmuster deutlich:

Eine External Dynamic List ist eine auf einem Webserver gehostete Textdatei, die von der Firewall regelmäßig abgerufen wird. Die Liste kann IP-Adressen, Domains oder URLs enthalten und in Policies referenziert werden. Änderungen an der Datei werden von der Firewall bei der nächsten Aktualisierung übernommen, ohne dass für den Listeninhalt selbst ein neuer Commit erforderlich ist. Fällt der Webserver aus, arbeitet die Firewall mit der zuletzt erfolgreich abgerufenen Version weiter. Das macht EDLs robust, einfach nachvollziehbar und betrieblich attraktiv. Allerdings ist die Wirkung nicht echtzeitnah, sondern an das Abrufintervall gekoppelt. Außerdem muss die Liste sauber gehostet, geschützt und gegen fehlerhafte Einträge abgesichert werden.

Dynamic Address Groups arbeiten anders. Hier registriert ein externes System IP-Adressen und Tags direkt auf der Firewall oder via Panorama. Die Mitgliedschaft der DAG wird nach dem API-Aufruf automatisch aktualisiert. Ein zusätzlicher Policy-Commit für jede einzelne IOC-Änderung ist nicht nötig, sofern die DAG bereits in einer Security Policy referenziert wird. Das ist für schnelle Reaktionen deutlich eleganter als eine dateibasierte Liste. Gleichzeitig steigt aber der Integrationsaufwand: API-Authentisierung, Fehlerbehandlung, Idempotenz, sauberes Entfernen von Tags und das Monitoring dynamischer Einträge müssen mitgedacht werden. Hinzu kommen modellabhängige Grenzen für die Anzahl dynamisch registrierter IPs. Je nach Plattform reichen diese von kleinen vierstelligen Werten bis zu mehreren hunderttausend Einträgen.

Architektonisch ist deshalb entscheidend, welche Art von Containment gefordert ist. EDLs sind sehr gut geeignet, wenn die Blockliste transparent, revisionsfähig und simpel bleiben soll. DAGs sind besser, wenn Reaktionszeit, Automatisierungsgrad und feingranulare Tag-Logik im Vordergrund stehen. In beiden Fällen gilt: Nicht jeder Wazuh-Alert darf automatisch auf Netzebene blockieren. Ohne vorgelagertes Rule-Tuning entstehen schnell Fehlblockaden, insbesondere bei NAT-Szenarien, Proxy-Infrastrukturen, Scanner-Hosts oder Shared Services.

Lösung / Best Practices

Für die meisten Umgebungen ist der beste Einstieg die EDL-Variante. Sie ist einfacher zu betreiben, leichter zu auditieren und reduziert das Risiko komplexer API-Fehler. Das Grundmuster sieht so aus:

Wazuh klassifiziert blockwürdige Alerts über eigene Regeln oder Gruppen.
Eine managerseitige Active Response oder eine Custom Integration extrahiert die relevante IP.
Ein Skript schreibt diese IP in eine gehostete Blocklist-Datei.
Palo Alto importiert die Datei als External Dynamic List.
Eine Security Policy referenziert diese EDL und blockiert die enthaltenen IPs.
Nach Ablauf eines definierten Zeitfensters entfernt Wazuh die IP wieder aus der Datei.

Wazuh-seitig kann ein solcher Response-Mechanismus sauber zustandsbehaftet gebaut werden. Das folgende Beispiel zeigt das Grundprinzip für einen benutzerdefinierten Active-Response-Befehl auf dem Manager:

<ossec_config>
  <command>
    <name>paloalto-edl-sync</name>
    <executable>paloalto_edl_sync.py</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>  <active-response>
    <disabled>no</disabled>
    <command>paloalto-edl-sync</command>
    <location>server</location>
    <rules_group>firewall_block_ioc,threat_intel,bruteforce_confirmed</rules_group>
    <timeout>3600</timeout>
  </active-response>
</ossec_config>

Dabei muss das Skript auf add die IOC-IP in eine zentrale Datei eintragen und auf delete denselben Eintrag wieder entfernen. Wichtig ist, dass die Datei atomar geschrieben wird, damit parallele Alerts keine beschädigte Liste erzeugen. Ebenso wichtig sind Deduplikation, Whitelists und ein Locking-Mechanismus. Wazuh dokumentiert explizit, wie stateful Active Responses mit add und delete arbeiten und wie der Timeout die Rücknahme auslöst.

Palo-Alto-seitig wird diese Datei als EDL eingebunden. Die Firewall erwartet dafür eine erreichbare Textdatei auf einem Webserver. Die EDL kann anschließend in Security Policies als Quell- oder Zieladressobjekt verwendet werden. Fällt die Quelle aus, nutzt die Firewall die letzte erfolgreich geladene Version weiter. Das ist betrieblich ein starkes Argument für dieses Muster.

Die DAG-Variante ist technisch eleganter, wenn nahezu sofortige Umsetzung gefragt ist. Hier sendet Wazuh nicht in eine Datei, sondern an die XML API von Palo Alto und registriert eine IOC-IP mit einem oder mehreren Tags, etwa wazuh.block oder wazuh.c2. Eine Dynamic Address Group wird so definiert, dass sie genau diese Tags matcht. Nach dem API-Aufruf aktualisiert Palo Alto die Gruppenzugehörigkeit automatisch. Das reduziert Latenz und erlaubt differenzierte Policies, etwa unterschiedliche Behandlungen für Scanner, C2, Brute Force oder Threat Intel.

Wazuh-seitig kann dafür entweder ein Active-Response-Skript direkt die API ansprechen oder das Integrator-Modul eine custom-*-Integration nutzen. Für die Selektionslogik ist das Integrator-Modul besonders interessant, weil sich Alerts nach Gruppen und Level filtern lassen. Ein minimales Muster in ossec.conf sieht so aus:

<ossec_config>
  <integration>
    <name>custom-paloalto</name>
    <level>10</level>
    <group>firewall_block_ioc,threat_intel,bruteforce_confirmed</group>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

Das eigentliche Skript übernimmt dann die Extraktion von srcip oder einer alternativen IOC-Quelle aus dem Alert-JSON, prüft lokale Ausnahmen und führt den API-Call aus. Für temporäre Sperren sollte die Rücknahme ebenfalls automatisiert sein, entweder durch gezieltes Entfernen des Tags oder durch einen zweiten Workflow. Palo Alto unterstützt das dynamische Registrieren von IPs und Tags direkt auf Firewall oder Panorama; die Mitgliedschaft der DAG wird daraus automatisch abgeleitet.

Für beide Varianten gelten dieselben fachlichen Schutzmaßnahmen:

Nur hochvertrauenswürdige Regeln dürfen Blockaktionen auslösen.
Interne Scanner, Jump Hosts, Proxy-Systeme, DNS-Resolver, Load Balancer und bekannte NAT-Quellen gehören auf Whitelists.
Mehrfache Treffer oder Korrelationen sind besser als Single-Event-Blockaden.
Jede Sperre braucht ein nachvollziehbares TTL-Konzept.
Logging und Audit-Trails müssen sowohl auf Wazuh- als auch auf Firewall-Seite vorhanden sein.

Lessons Learned / Best Practices

Der wichtigste Punkt ist die Trennung zwischen Erkennung und Durchsetzung. Wazuh kann sehr viele Signale erzeugen, aber nur ein kleiner Teil davon eignet sich für automatische Firewall-Blockaden. Wer diese Trennung nicht sauber über Regeln, Gruppen und Schwellwerte modelliert, erzeugt schnell operative Störungen statt zusätzlicher Sicherheit.

Für kleine und mittlere Umgebungen ist eine EDL meistens der bessere Start. Das Modell ist transparent, leicht testbar und gut mit Change- und Audit-Prozessen vereinbar. Es eignet sich besonders dann, wenn Blockierungen zeitlich begrenzt sind und ein Intervall von einigen Minuten akzeptabel ist. Außerdem lässt sich die gehostete Liste leicht versionieren, sichern und extern prüfen. Palo Alto empfiehlt bei mehreren virtuellen Systemen den Einsatz gemeinsamer EDLs, um unnötigen Speicherverbrauch durch doppelte Listen zu vermeiden.

DAGs spielen ihre Stärke in größeren oder reaktionskritischen Umgebungen aus. Dort überzeugt vor allem, dass Policies dauerhaft auf Tags arbeiten können, während nur die Tag-Zuordnung dynamisch geändert wird. Gleichzeitig müssen Betreiber die Skalierungsgrenzen je Modell kennen und die Pflege dynamischer Einträge überwachen. Palo Alto stellt dafür eigene CLI-Kommandos und Prüfpfade bereit.

Wazuh-seitig empfiehlt sich ein mehrstufiges Rollout: zuerst nur Loggen, dann Shadow Mode ohne echte Blockierung, anschließend zeitlich kurze Sperren und erst danach produktive Laufzeiten. Parallel sollten Positivlisten, Aufräumlogik und Fehlerszenarien getestet werden. Besonders wichtig ist das Verhalten bei API-Fehlern, bei nicht erreichbarem Webserver für die EDL und bei doppelten oder konkurrierenden Einträgen.

Fazit

Wer IoCs aus Wazuh automatisiert auf Palo Alto durchsetzen will, hat mit External Dynamic Lists und Dynamic Address Groups zwei praxistaugliche Wege. Die EDL-Variante ist einfacher, robuster und für viele Umgebungen der sinnvollste Einstieg. Die DAG-Variante bietet mehr Geschwindigkeit und Flexibilität, verlangt aber mehr Integrationsdisziplin. In beiden Fällen ist nicht die technische Verbindung der schwierige Teil, sondern die saubere Auswahl blockwürdiger Wazuh-Alerts, die kontrollierte Rücknahme und der Schutz vor False Positives. Genau dort entscheidet sich, ob aus einer SIEM-Erkennung tatsächlich ein belastbarer Containment-Workflow wird.

Quellenverweis

Wazuh Active Response
https://documentation.wazuh.com/current/user-manual/capabilities/active-response/index.html

Wazuh Custom Active Response Scripts
https://documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response-scripts.html

Wazuh External API Integration
https://documentation.wazuh.com/current/user-manual/manager/integration-with-external-apis.html

Wazuh integration (ossec.conf)
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/integration.html

Palo Alto Networks External Dynamic List
https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/policy/use-an-external-dynamic-list-in-policy/external-dynamic-list

Palo Alto Networks Use an External Dynamic List in Policy
https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/policy/use-an-external-dynamic-list-in-policy

Palo Alto Networks Dynamic Address Groups
https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/policy/monitor-changes-in-the-virtual-environment/use-dynamic-address-groups-in-policy

Palo Alto Networks Register IP Addresses and Tags Dynamically
https://docs.paloaltonetworks.com/network-security/security-policy/administration/objects/addresses/register-ip-addresses-and-tags-dynamically

Palo Alto Networks CLI Commands for Dynamic IP Addresses and Tags
https://docs.paloaltonetworks.com/network-security/security-policy/administration/objects/addresses/cli-commands-for-dynamic-ip-addresses-and-tags

Ergänzend, aber thematisch eher für die Log-Integration Palo Alto → Wazuh als für den IOC-Push Wazuh → Palo Alto:
https://medium.com/@avvik_poff.0w/complete-guide-integrating-palo-alto-firewall-with-wazuh-siem-2025-f97027f8b22a

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program