Parallele Firewall-Logabfrage mit KI-gestützter Ursachenanalyse
Von der Störungsmeldung bis zur fertigen Kundenmail ohne zentrales SIEM.
Wer Firewall-Support ohne Zugriff auf ein zentrales SIEM leisten muss, kennt das Muster genau: Eine Störungsmeldung trifft per Mail ein, und die Ursachensuche verteilt sich über mehrere getrennte Managementkonsolen. Aus einem parallelen Abfrage-Werkzeug für mehrere Firewall-Plattformen und einem streng belegbasierten Analyse-Prompt ist inzwischen eine durchgängige Kette geworden, die aus rohen Logdaten eine versandfertige Antwortmail macht.
Inhaltsverzeichnis
Wenn die Störungsmeldung im Postfach landet
Eine typische Meldung beschreibt eine fehlgeschlagene Verbindung zwischen zwei Systemen, oft mit ungenauen Angaben zu Uhrzeit oder betroffenem Port. Ohne SIEM bedeutet das: Jede beteiligte Firewall-Plattform muss einzeln befragt werden, mit unterschiedlichen Zeitformaten, unterschiedlichen Filtersprachen und unterschiedlichen Antwortstrukturen. Genau dieses Nebeneinander unterschiedlicher Systeme war schon 2024 der Ausgangspunkt für ein erstes, deutlich einfacheres Skript.
CP-Manager, FortiAnalyzer und OPNsense Firewalls direkt
Aus der ursprünglichen Sammlung einzelner SSH-Aufrufe ist inzwischen ein Werkzeug geworden, das alle Firewall-Plattformfamilien gleichzeitig befragt und die Ergebnisse in einem normalisierten Format ausgibt. Für Check Point sind das mittlerweile mehrere separate Management-Server, etwa weil unterschiedliche Standorte oder Test- und Produktivsysteme eigene Manager betreiben. Jeder Manager wird über dieselbe Funktion angesprochen, die sich per login an der Management-API anmeldet und Logs über den show-logs-Endpunkt abfragt. Er liefert die Ergebnisse in Seiten zu maximal 100 Einträgen und gibt dafür eine query-id für die Folgeseite zurück, wie es die offizielle Check-Point-Dokumentation zur Log-API beschreibt.
Für die FortiAnalyzer kommen inzwischen ebenfalls mehrere Instanzen zum Einsatz, jede über dasselbe asynchrone JSON-RPC-Verfahren angesprochen: Eine Suche wird per add gestartet, liefert eine tid zurück, und über wiederholte get-Aufrufe auf denselben Task wird der Fortschritt abgefragt, bis die Ergebnisseiten abrufbar sind, wie Fortinets Community-Dokumentation zur Logsearch-API zeigt.
Als dritte Plattformfamilie kommt eine eigene Gruppe von Unterfunktionen für OPNsense-Firewalls hinzu. Diese unterscheiden sich von den beiden anderen Familien vor allem im Authentifizierungsverfahren und in der Struktur der zurückgegebenen Logzeilen, weshalb sie als eigenständige Funktionsfamilie geführt werden statt in eine der bestehenden Funktionen gepresst zu werden.
Eine übergeordnete Funktion übernimmt weiterhin lediglich die Orchestrierung: Sie berechnet für alle beteiligten Systeme exakt denselben Zeitraum, der einfach als absolute Zahl in Minuten oder als Intervall gegeben werden kann, startet sämtliche Abfragen als Hintergrundprozesse und führt die Ergebnisse anschließend zeitlich sortiert zusammen. Zugangsdaten werden dabei nicht im Skript hinterlegt, sondern müssen bereits als Umgebungsvariablen in der aufrufenden Shell gesetzt sein.
# M. Meister - vereinfachte Orchestrierung über drei Plattformfamilien
# Erwartet Zugangsdaten bereits als Umgebungsvariablen in der Shell
# Die Checkpoint Manager:
cp_hosts=("$CP_HOST_1" "$CP_HOST_2" "$CP_HOST_3" ...)
faz_hosts=("$FAZ_HOST_1" "$FAZ_HOST_2" ...)
opn_hosts=("$OPN_HOST_1" "$OPN_HOST_2" "$OPN_HOST_3" ...)
{
for host in "${cp_hosts[@]}"; do
cp_logs "$host" "$START" "$END" "$IP1" "$IP2" "$FILTER" &
done
for host in "${faz_hosts[@]}"; do
fgt_logs "$host" "$START" "$END" "$IP1" "$IP2" "$FILTER" &
done
for host in "${opn_hosts[@]}"; do
opnsense_logs "$START" "$END" "$IP1" "$IP2" "$FILTER" &
done
wait
} | sort -t $'\t' -k1,1rErst der menschenlesbare Blick auf die Logs
Der erste Durchlauf erfolgt ohne besondere Flags. Das Werkzeug gibt dann eine schlichte, spaltenweise formatierte Tabelle aus - Zeitstempel, Firewall, Aktion, Regel, Quelle, Ziel, Port, und ein Infofeld für Zusatzmeldungen. Für den ersten Überblick reicht das völlig aus, um zu erkennen, welches der inzwischen sechs beteiligten Systeme überhaupt reagiert hat und welches nicht.
Time fw_device action r_nr rule_name in_iface src_ip src_nat_ip transport dest_port service dest_ip dest_nat_ip out_iface info
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2026-09-14 08:15:42 fw-muc-o02 accept 210 LAN_to_DMZ_HTTPS igb0 10.20.5.40 - tcp 443 https 10.40.12.8 - igb1 -
2026-09-14 08:15:41 fw-nue-c23 accept 118 DMZ-App-Access eth2 10.20.5.40 - tcp 443 https 10.40.12.8 - eth3 -
2026-09-14 08:15:40 fw-erl-f18 accept 44 Allow_HTTPS_Core port3 10.20.5.40 172.16.9.5 tcp 443 https 10.40.12.8 - port5 -
2026-09-14 08:14:58 fw-fra-c76 block 802 Deny_Diag_Ports eth0 10.20.5.40 - tcp 8443 https 10.40.12.8 - - -
2026-09-14 08:14:57 fw-muc-o02 block 88 Block_Mgmt_From_LAN igb0 10.20.5.40 - tcp 8443 https 10.40.12.8 - - -
2026-09-14 08:14:12 fw-bam-f41 block 210 Deny_RDP_External port1 10.20.5.40 - tcp 3389 rpd 10.40.12.8 - - policy violation
2026-09-14 08:14:11 fw-ham-c84 block 337 Cleanup_Rule eth1 10.20.5.40 - tcp 3389 rpd 10.40.12.8 - - -
2026-09-14 08:12:03 fw-fra-c76 accept 118 DMZ-App-Access eth0 10.20.5.40 - tcp 443 https 10.40.12.8 - eth2 -
2026-09-14 08:12:02 fw-muc-o02 accept 210 LAN_to_DMZ_HTTPS igb0 10.20.5.40 - tcp 443 https 10.40.12.8 - igb1 -
2026-09-14 08:11:59 fw-erl-f18 accept 44 Allow_HTTPS_Core port3 10.20.5.40 172.16.9.5 tcp 443 https 10.40.12.8 - port5 -
2026-09-14 08:09:30 fw-nue-c23 block 900 Cleanup_Rule eth3 192.168.4.12 - udp 161 snmp 10.40.12.8 - - -
2026-09-14 08:05:17 fw-bam-f41 accept 12 ICMP_Allow port1 10.20.5.40 - icmp - icmp 10.40.12.8 - port2 echo-requestGenau an dieser Stelle zeigt sich der eigentliche Vorteil gegenüber der einzelnen Abfrage jedes Systems: Innerhalb weniger Sekunden liegt eine gemeinsame, chronologisch sortierte Sicht auf drei unterschiedliche Firewall-Welten vor, statt mehrerer getrennter Browserfenster mit unterschiedlichen Zeitzonen und Spaltenlayouts. So läßt sich leicht erkennen, welchen Weg die Pakete durch die Firewalls genommen haben.
Gezielt gefiltert als JSON für die Auswertung
Sobald der auffällige Zeitraum und die betroffenen Adressen eingegrenzt sind, folgt ein zweiter, genau angepasster Durchlauf mit dem --debug-Schalter. Statt der aufbereiteten Tabelle liefert das Werkzeug dann die Rohantworten aller beteiligten APIs als JSON, exakt für das eingeschränkte Zeitfenster und die relevanten IP-Adressen.
{
"logs": [
{
"time": "2026-09-14T08:14:58Z",
"action": "Drop",
"orig": "fw-bam-c41",
"product": "VPN-1 & FireWall-1",
"i/f_name": "eth0",
"src": "10.20.5.40",
"s_port": "51422",
"dst": "10.40.12.8",
"service": "8443",
"proto": "6",
"rule": "802",
"rule_name": "Deny_Diag_Ports",
"message_info": "First packet isn't SYN, packet dropped",
"bytes": "0",
"packets": "1"
},
{
"time": "2026-09-14T08:15:42Z",
"action": "Accept",
"orig": "fw-bam-c41",
"product": "VPN-1 & FireWall-1",
"i/f_name": "eth2",
"src": "10.20.5.40",
"s_port": "51430",
"dst": "10.40.12.8",
"service": "443",
"proto": "6",
"rule": "118",
"rule_name": "DMZ-App-Access",
"client_inbound_bytes": "4218",
"client_inbound_packets": "31",
"server_inbound_bytes": "38904",
"server_inbound_packets": "47",
"bytes": "43122",
"packets": "78"
}
],
"query-id": "ea5b0b7d-0388-46d1-88d3-6f3f4b68ae76"
}Diese Reduktion ist kein kosmetisches Detail: In diesen Logs befinden sich deutlich mehr Informationen, als nur block oder accept. Hier finden sich auch Zusatzinformationen wie transportierte Datenmengen (ein Indiz dafür, dass die Firewall den Traffic nicht verhindert hat, sondern die Applikationen ein Problem haben) oder State-Probleme, wie "First Packet was not SYN".
Kundenmail und Logbefund treffen auf den Analyse-Prompt
Die gefilterte JSON-Ausgabe wird zusammen mit eventuell erstellten PCAPs und dem vollständigen Mailverlauf des Kunden in einen spezialisierten Prompt gegeben.

Dessen Grundprinzip folgt derselben forensischen Struktur, die bereits im Praxisbeispiel mit Hermes Agent an einem einzelnen FortiGate-Fall zu sehen war: strikte Trennung zwischen bewiesenen Tatsachen, nicht bewertbaren Punkten und offenen Prüfschritten, ergänzt um einen eigenen Falsifikations-Abschnitt, der ausdrücklich benennt, welche möglichen Erklärungen die Logs bereits widerlegen. Ein bloßer TCP-Verbindungsaufbau wird dabei nicht vorschnell als funktionierender TLS- oder HTTP-Aufruf verkauft, und fehlende Informationen wie SNI oder HTTP-Status werden als das benannt, was sie sind: in den vorliegenden Logs nicht enthalten oder aus den PCAPs analysiert.
Vom Befund zur versandfertigen Mail
Am Ende der Kette steht keine Stichpunktliste, sondern eine vollständig formatierte HTML-Mail mit Management-Zusammenfassung, tabellarischen Key Findings, einer eingebetteten Netzwerktopologie-Grafik und einer nach Verbindungstyp getrennten Ursachenbestimmung.

...

...

Weil sämtliche Formatierung inline und ohne externe Ressourcen erstellt wurden, lässt sich der sichtbare Inhalt per copy/paste direkt in eine neue eMail übertragen, inklusive Grafik. Aus Sicht des Arbeitsablaufs bleibt damit nur noch die Empfängeradresse und ein kurzer Blick auf die Formulierung übrig, bevor die Antwort tatsächlich verschickt wird.
Fazit
Aus einer losen Sammlung einzelner SSH- und API-Aufrufe ist eine Kette geworden, die alle vorhandenen Firewall-Plattformfamilien parallel befragt und von der eingehenden Störungsmeldung bis zur versandfertigen, belegbasierten Antwortmail reicht. Den größten Zeitgewinn bringt dabei weniger die reine Parallelisierung der Logabfrage ohne SIEM als vielmehr die klare Trennung zwischen grober menschenlesbarer Sichtung und eng gefilterter, maschinenlesbarer Auswertung.
So bleibt einem gut ausgebildeten Ingenieur mehr Zeit für seine Kernkompetenz an der Konsole, während sich die KI mit der Dokumentation und der diplomatischen Formulierung einer freundlichen Antwort an den Kunden befassen darf, der im vorgestellten Fall auf dem Server hätte sehen können, wo das Problem liegt.

