Realtime-Attack-Map
SURICATA / LIVE FEED

Parallele Firewall-Logabfrage mit KI-gestützter Ursachenanalyse

Von der Störungsmeldung bis zur fertigen Kundenmail ohne zentrales SIEM.

Parallele Firewall-Logabfrage mit KI-gestützter Ursachenanalyse

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.

    Platformübergreifende Log-Analyse ohne SIEM
    Parallele Datenabfrage über mehrere Managementsysteme

    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,1r

    Erst 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-request

    Genau 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.

    Von OpenClaw zu Hermes
    Ein Vergleich zweier selbst gehosteter KI-Agenten, samt Installation und Praxisbeispielen.

    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.

    Bereits hier könnte der Kunde bereits auf seinem Server sehen, dass der vorgelagerte Router falsch konfiguriert ist...

    ...

    ... denn der Server erhält ja die Information "Host unreachable", was klar aufzeigt: Der gelbe Router glaube dass der blaue Client direkt an seinem Interface angeschlossen wäre...

    ...

    ... womit im Vorfeld der Kunde sich eigentlich an das Router-Team hätte wenden müssen. Aber das darf dann die lokale KI freundlich beantworten.

    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.