Firewall-Log-Pipeline mit Cursor

Du hast alles so gemacht, wie es in der Dokumentation steht. Remote-Logging auf der pfSense-Box aktiviert, auf deinen Windows-Rechner ausgerichtet, UDP-Port 514 geöffnet. Nichts kam an. Im Netgate-Forum sammeln sich seit über einem Jahrzehnt Threads über genau diese Stille: Logs wurden erzeugt, aber nie gesendet, syslogd war nach einem Neustart unbemerkt ausgefallen. Irgendwo zwischen der Firewall und deiner Festplatte verschwand das Ereignis - und nichts in der Kette verrät dir, wo.

Die Standardlösung ist ein SIEM, das ein Problem gegen ein größeres tauscht: Jetzt musst du dich um Elasticsearch kümmern. Dieser Leitfaden geht einen anderen Weg. Du öffnest Cursor, beantwortest fünf Fragen und genehmigst Befehle, während ein KI-Agent die Firewall-Log-Pipeline baut. Am Ende hast du ein verifiziertes Firewall-Ereignis auf der Festplatte, einen durchsuchbaren Verlauf in einer lokalen Datenbank und einen KI-Analysten, der deine Logs liest - aber deine Firewall nicht anfassen kann.

Gesamtumfang: ein Windows-Dienst, ein Ordner, eine SQLite-Datei.

Pixel-Art-Ziegelmauer als Firewall, Windows-Collector-Würfel, geschützte SQLite-Trommel und ein Detektiv-Cursor, der über eine gestrichelte Linie hinweg prüft — Die gestrichelte Linie ist das Sicherheitsmodell: ansehen, nicht anfassen.

Die Firewall-Log-Pipeline, die du baust

┌──────────┐  syslog   ┌────────┐        ┌────────────┐        ┌───────────┐
│ Firewall │──UDP 514─>│ NXLog  │──JSON─>│ C:\logdata │──5min─>│ fwlogs.db │
│ (any)    │           │ service│  spool │  \spool\   │ ingest │ (SQLite)  │
└──────────┘           └────────┘        └────────────┘        └─────┬─────┘
                                                                     │ SELECT only
                                                               ┌─────v─────┐
                                                               │  Cursor   │
                                                               │  agent    │
                                                               └───────────┘

pfSense dient durchgehend als Beispiel, aber jede Syslog-fähige Firewall funktioniert - OPNsense, UniFi, SonicWall oder ein verwalteter Switch. NXLog Community Edition nimmt Daten auf Port 514 entgegen und schreibt JSON-Spool-Dateien. Eine geplante Aufgabe lädt sie in SQLite. Der Agent fragt die Datenbank mit Nur-Lese-Zugriff ab und meldet, was er findet.

Moment - ist Cursor nicht ein Programmierwerkzeug?

So lautet das Marketing. Darunter steckt ein Agent, der Dateien liest, Dateien schreibt und mit deiner Genehmigung Terminalbefehle ausführt. Die Welt eines Sysadmins besteht aus Dateien: Konfigurationen, Logs, Skripten und Datenbanken. Du wirst keine einzige Codezeile schreiben - du benutzt nur zwei Bedienelemente, das Chatfeld und die Genehmigen-Schaltfläche. Der Agent schreibt die NXLog-Konfiguration, das SQL-Schema und das Importskript; du liest sie und klickst auf Ja.

Voraussetzungen

Anforderung	Hinweise
Windows 10/11 oder Server 2019+, x64	Für NXLog CE gibt es keinen Windows-ARM64-Build
Statische IP-Adresse des Collector-Rechners	Eine DHCP-Reservierung funktioniert ebenfalls
Der Rechner bleibt eingeschaltet	Unter Win11 den Energiesparmodus deaktivieren, sonst verschwinden UDP-Logs unbemerkt
Administratorrechte	Die Dienstinstallation erfordert erhöhte Rechte
Eine beliebige Firewall, die Syslog senden kann	Du greifst einmal auf ihre Administrationsoberfläche zu
Cursor installiert	Die kostenlose Stufe reicht aus

Schritt 1: Fünf Antworten, bevor irgendetwas ausgeführt wird

Erstelle einen Ordner - C:\fw-pipeline - und öffne ihn in Cursor. Erstelle darin eine Datei namens answers.yaml:

firewall:         "pfSense CE 2.7.2"  # vendor + version (or your model, e.g. Netgate 2100)
firewall_ip:      "192.168.1.1"       # address it sends syslog from
collector_ip:     "192.168.1.20"      # this machine's static IP
transport:        "udp"               # udp | tcp — pfSense native syslog is UDP-only
data_stays_local: true                # log data never leaves this machine

Alles, was der Agent erzeugt, wird aus diesen fünf Zeilen abgeleitet. Hersteller und Version bestimmen die genauen Klicks, die er dir nennt. Die IP-Adresse der Firewall wird zum Geräteschlüssel in der Datenbank. data_stays_local: true bedeutet, dass die Analyse auf der lokalen Datenbank läuft - Rohlogs werden nie vollständig in einen Prompt eingefügt.

Die Details, die dieser Beitrag auslässt, stehen in zwei Begleitdateien - der Bereitstellungsreferenz und den FAQ zur Fehlerbehebung. Der Agent lädt sie im nächsten Schritt herunter; die Links sind da, falls du vorher einen Blick darauf werfen möchtest.

Pixel-Art-Klemmbrett mit fünf Antworten, die in eine Maschine mit der Beschriftung Agentenkonfiguration wird erstellt fließen, während auf dem Förderband ein mit einem Tuch bedeckter Gegenstand liegt — Die abgedeckte Kiste ist der entscheidende Punkt: Nichts wird gebaut, bevor diese fünf Zeilen ausgefüllt sind.

Schritt 2: Leitplanken vor dem Agenten

Dreiundfünfzig Prozent der Sysadmins würden KI nicht unbeaufsichtigt an Produktionssysteme lassen. Der richtige Instinkt. Schreibe die Regeln nicht in den Prompt, sondern dorthin, wo der Agent sie nicht ignorieren kann. Erstelle .cursor/rules/pipeline.md:

- Show every terminal command and wait for approval. No auto-run.
- Query fwlogs.db with the read-only "analyst" account only.
- Never connect to the firewall. Its config is the human's job.
- If any value in answers.yaml is blank, stop and ask. Never guess.
- Append every database query you run to agent-audit.log, with timestamp.

Cursor lädt diese Regeln in jede Sitzung in diesem Ordner. Der Agent macht einen Vorschlag; du genehmigst ihn. Es ist dasselbe Vertrauensmodell, das du bei einem neuen Junior-Admin anwenden würdest - nur dass dieser sich nie langweilt und jede Logzeile liest.

Pixel-Art-Agent mit vorgeschlagenen Änderungen, während eine Person auf einem Bildschirm mit ausstehenden Befehlen auf Genehmigen zeigt; vor einer Firewall und einer gesperrten Datenbank verläuft eine rote gestrichelte Linie — Nichts auf diesem Klemmbrett ist eine Tatsache, bevor es die gestrichelte Linie überschritten hat.

Schritt 3: Lass den Agenten den Collector bauen

Jetzt kommt der erste echte Prompt - füge ihn in den Chat ein:

Download both companion files from https://gist.github.com/matbanik/18dadee60389913b982493c8cbbe99ad into this folder and read
them, then read answers.yaml. Install NXLog Community Edition as a service,
configure it to receive syslog on the chosen transport and write JSON spool
files to C:\logdata\spool with filenames like fw-{timestamp}.json, and open
the Windows Firewall port — bound to the Private and Domain profiles, not
Public. Show me each command before running it.

Du wirst eine MSI-Installation, eine erzeugte nxlog.conf und eine einzelne New-NetFirewallRule genehmigen. Prüfe zwei Details in der erzeugten Konfiguration: parse_syslog() am Eingang, damit sowohl RFC 3164 als auch RFC 5424 sauber ankommen, und einen erhöhten SockBufSize, denn der standardmäßige Windows-UDP-Puffer ist winzig und verwirft Lastspitzen.

Überprüfe:

Get-Service nxlog   # Status: Running

Schritt 4: Richte die Firewall darauf aus

Der eine manuelle Schritt. Der Agent liest answers.yaml und nennt dir die genauen Klicks für deine Plattform, aber du führst sie aus - die Firewall bleibt außerhalb seiner Reichweite. In pfSense: Status → System Logs → Settings → Remote Logging - aktivieren, Collector-IP, Port 514 und die gewünschten Kategorien auswählen. Bei anderen Firewalls gilt dasselbe Rezept: Ziel = Collector-IP, Port 514, RFC 5424, falls angeboten.

Eine Regel, die alle vergessen: Wenn sich der Collector in einem anderen Segment befindet, braucht die Firewall eine Egress-Regel, die ihr erlaubt, Port 514 zu erreichen. Eine Firewall protokolliert ihr eigenes verworfenes Syslog nicht.

Schritt 5: Das erste Ereignis - oder die Stelle, an der es starb

Beobachte den Spool-Ordner. Wenn eine Datei namens fw-*.json erscheint und wächst, ist der schwierige Teil geschafft. Falls nichts erscheint, kommt der Punkt, an dem jeder andere Leitfaden nur mit den Schultern zuckt. Bitte den Agenten, die Leiter abzuarbeiten:

event created on the firewall?      - no -> log category or severity filter
  │ yes
packet left the firewall?           - no -> syslogd died after reboot, egress rule
  │ yes
packet reached Windows?             - no -> routing or ACL on the path
  │ yes
NXLog listening on 514?             - no -> service stopped, port taken
  │ yes
Windows Firewall let it through?    - no -> rule bound to the wrong profile
  │ yes
line in the spool file?             - no -> EDR blocked NXLog, parse error

Der Agent prüft die meisten Sprossen selbst - er sendet ein synthetisches Syslog-Paket, kontrolliert den Listener, liest das eigene Log von NXLog - und sagt dir, an welchem Abschnitt dein Ereignis verloren ging. Der übliche Schuldige unter Windows 11: Das WLAN ist als Öffentlich verbunden, während die Regel an Privat gebunden ist.

Schritt 6: Mach die Pipeline dauerhaft

Noch ein Prompt:

Create fwlogs.db with an events table keyed by device IP and receive time,
an ingest path and a read-only analyst access pattern, and a scheduled task
that loads closed spool files every five minutes, checks the sqlite3 exit
code before archiving each file, and prunes anything older than 90 days.

Erst spoolen, dann importieren ist kein Kompromiss - NXLog Community Edition kann unter Windows ohnehin nicht direkt in eine Datenbank schreiben, und die Spool-Dateien dienen zugleich als erneut abspielbare Rohbelege. Die Prüfung des Exitcodes ist wichtig: Archiviere eine Datei erst, nachdem SQLite den Import bestätigt hat, sonst verschluckt eine vorübergehende Sperre unbemerkt eine Stunde an Logs.

Pixel-Art-Dokument, das zu einer Kabelspule fließt, dann zu einer gestreiften Barrikade, einem geschützten Zylinder, einem grünen Häkchen und einer Kiste mit Schlüsselloch — Die Barrikade ist die Exitcode-Prüfung: Die Kiste schließt sich erst, nachdem SQLite den Import bestätigt hat.

Schritt 7: Stell deinen Logs Fragen

Der Lohn kommt bewusst zuletzt - eine Analyse ist nur so gut wie die Pipeline darunter. Probiere Folgendes:

Using the analyst account, summarize the last 24 hours: repeated auth
failures, deny spikes, source IPs never seen before, config changes outside
business hours. For each finding, list the supporting event IDs and one
plausible benign explanation.

Der letzte Halbsatz leistet echte Arbeit. Ein Agent, der seine eigenen Ergebnisse infrage stellen muss, alarmiert dich wegen des VPN-Brute-Force-Versuchs, nicht weil dein Fernseher um 3 Uhr morgens nach Firmware sucht. Jedes Ergebnis kommt mit Belegen, die du überprüfen kannst - denn das Konto des Agenten darf ausschließlich lesen.

Pixel-Art-Person mit Lupe vor einem Monitor, der Ergebnistypen mit Ereignis-IDs auflistet, daneben ein Notizblock mit plausiblen harmlosen Erklärungen — Der Notizblock ist der letzte Halbsatz des Prompts: Jedes Ergebnis muss eine langweilige Erklärung überstehen.

Fallstricke, die deine Zeit verschwenden

Die Firewall-Regel ist an das Profil Öffentlich gebunden. Windows 11 verwendet bei WLAN standardmäßig Öffentlich und verwirft eingehenden Verkehr auf Port 514 unbemerkt. Stelle das Netzwerk auf Privat oder binde die Regel an jedes Profil, das du verwendest.

Der Collector ist eingeschlafen. UDP versucht es nicht erneut - ein schlafender Win11-Rechner verliert jedes Ereignis, bis er wieder aufwacht. powercfg /change standby-timeout-ac 0.

Logs kommen an, aber nicht die, die du brauchst. “Syslog funktioniert” und “Sicherheitsereignisse werden weitergeleitet” sind auf den meisten Firewalls getrennte Schalter. Eine fehlende Kategorie hat ihren eigenen Filter.

EDR hat NXLog unter Quarantäne gestellt. Eine neue Binärdatei, die einen lauschenden Port öffnet, sieht wie Schadsoftware aus. Füge vor der Installation eine Pfadausnahme hinzu, nicht danach.

Der Agent möchte die Firewall für dich reparieren. Erweitere seine Reichweite nicht, nur weil Schritt 5 gut lief. Nur-Lese-Zugriff mit Vorschlägen ist der sichere Dauerzustand.

Wo du damit stehst

Deine Firewall hat die ganze Zeit gesprochen. Jetzt gibt es Beweise auf der Festplatte, einen Verlauf, den du durchsuchen kannst, und einen Analysten in Bereitschaft, der alles liest und nichts anfasst. Wenn das nächste Mal etwas im Netzwerk falsch aussieht, wirst du keine Forenthreads lesen - du wirst deine eigenen Logs fragen.