Pipeline de journaux de pare-feu avec Cursor

Tu as fait tout ce que disait la documentation. Tu as activé la journalisation distante sur le boîtier pfSense, tu l’as dirigée vers ta machine Windows et tu as ouvert le port UDP 514. Rien n’est arrivé. Depuis plus de dix ans, le forum Netgate accumule des discussions sur ce silence précis — des journaux générés mais jamais envoyés, syslogd discrètement arrêté après un redémarrage. Quelque part entre le pare-feu et ton disque, l’événement a disparu — et rien dans la chaîne ne t’indique où.

La solution habituelle est un SIEM, qui remplace un problème par un autre, plus gros : tu dois désormais administrer Elasticsearch. Ce guide emprunte une autre voie. Tu ouvres Cursor, tu réponds à cinq questions et tu approuves des commandes pendant qu’un agent d’IA construit le pipeline de journaux du pare-feu. À la fin, tu auras sur disque un événement de pare-feu vérifié, un historique consultable dans une base de données locale et un analyste IA qui lit tes journaux — mais qui ne peut pas toucher à ton pare-feu.

Empreinte totale : un service Windows, un dossier et un fichier SQLite.

Pare-feu en briques en pixel art, cube collecteur Windows, tambour SQLite protégé et curseur détective inspectant la scène de part et d'autre d'une ligne en pointillés — La ligne en pointillés représente le modèle de sécurité : regarder, ne pas toucher.

Le pipeline de journaux du pare-feu que tu vas construire

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

pfSense sert d’exemple tout au long du guide, mais n’importe quel pare-feu capable d’envoyer des messages syslog convient — OPNsense, UniFi, SonicWall ou un commutateur administrable. NXLog Community Edition reçoit les messages sur le port 514 et écrit des fichiers tampons JSON. Une tâche planifiée les charge dans SQLite. L’agent interroge la base en lecture seule et rend compte de ce qu’il trouve.

Attends — Cursor n’est-il pas un outil de programmation ?

C’est ce qu’en dit le marketing. Sous le capot, Cursor est un agent qui lit des fichiers, écrit des fichiers et exécute des commandes de terminal avec ton approbation. Le monde d’un administrateur système est fait de fichiers : configurations, journaux, scripts, bases de données. Tu n’écriras pas une seule ligne de code — tu utiliseras deux éléments de commande, la zone de discussion et le bouton d’approbation. L’agent écrit la configuration NXLog, le schéma SQL et le script d’ingestion ; tu les lis et tu cliques sur oui.

Prérequis

Exigence	Remarques
Windows 10/11 ou Server 2019+, x64	NXLog CE n’a pas de version Windows ARM64
Adresse IP statique sur la machine de collecte	Une réservation DHCP convient
La machine reste allumée	Win11 : désactive la mise en veille, sinon les journaux UDP disparaissent sans avertissement
Droits d’administrateur	L’installation du service nécessite une élévation de privilèges
N’importe quel pare-feu capable d’envoyer des messages syslog	Tu accéderas une fois à son panneau d’administration
Cursor installé	L’offre gratuite suffit

Étape 1 : cinq réponses avant toute exécution

Crée un dossier — C:\fw-pipeline — et ouvre-le dans Cursor. Crée un fichier, 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

Tout ce que l’agent génère découle de ces cinq lignes. Le fabricant et la version déterminent les clics précis qu’il t’indique. L’adresse IP du pare-feu devient la clé de l’appareil dans la base de données. data_stays_local: true signifie que l’analyse s’effectue sur la base de données locale — les journaux bruts ne sont jamais collés en masse dans une invite.

Les détails omis dans cet article se trouvent dans deux fichiers complémentaires — la référence de déploiement et la FAQ de dépannage. L’agent les télécharge à l’étape suivante ; les liens sont là si tu veux d’abord y jeter un coup d’oeil.

Presse-papiers en pixel art contenant cinq réponses et alimentant une machine étiquetée agent de construction de configuration, avec un objet recouvert de tissu sur le convoyeur — La boîte couverte est essentielle : rien n'est construit tant que ces cinq lignes ne sont pas remplies.

Étape 2 : des garde-fous avant l’agent

Cinquante-trois pour cent des administrateurs système ne laisseraient pas l’IA toucher à la production sans supervision. C’est un bon réflexe. Ne place pas les règles dans l’invite — place-les là où l’agent ne peut pas les ignorer. Crée .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 charge ces règles dans chaque session ouverte dans ce dossier. L’agent propose ; tu approuves. C’est le même modèle de confiance que tu appliquerais à un nouvel administrateur débutant — sauf que celui-ci ne s’ennuie jamais et lit chaque ligne de journal.

Agent en pixel art tenant des modifications proposées pendant qu'une personne montre le bouton Approve sur un écran de commandes en attente, avec une ligne rouge en pointillés devant un pare-feu et une base de données verrouillée — Rien sur ce presse-papiers n'est un fait avant d'avoir franchi la ligne en pointillés.

Étape 3 : laisse l’agent construire le collecteur

Voici maintenant la première véritable invite — colle-la dans la discussion :

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.

Tu approuveras l’installation d’un MSI, un fichier nxlog.conf généré et une commande New-NetFirewallRule. Vérifie deux détails dans la configuration générée : parse_syslog() sur l’entrée, afin que les formats RFC 3164 et RFC 5424 soient tous deux correctement enregistrés, et une valeur SockBufSize plus élevée, car le tampon UDP par défaut de Windows est minuscule et perd les rafales de messages.

Vérifie :

Get-Service nxlog   # Status: Running

Étape 4 : dirige le pare-feu vers le collecteur

La seule étape manuelle. L’agent lit answers.yaml et te donne les clics précis pour ta plateforme, mais c’est toi qui les effectues — le pare-feu reste hors de sa portée. Sur pfSense : Status → System Logs → Settings → Remote Logging — active la fonction, saisis l’adresse IP du collecteur et le port 514, puis coche les catégories souhaitées. Pour les autres pare-feu, la recette est la même : destination = adresse IP du collecteur, port 514, RFC 5424 si cette option est proposée.

Une règle que tout le monde oublie : si le collecteur se trouve sur un autre segment, le pare-feu a besoin d’une règle de sortie l’autorisant à atteindre le port 514. Un pare-feu ne journalisera pas ses propres messages syslog bloqués.

Étape 5 : le premier événement — ou l’endroit où il a disparu

Surveille le dossier tampon. Si un fichier fw-*.json apparaît et grossit, le plus difficile est fait. Si rien n’apparaît — c’est ici que tous les autres guides haussent les épaules. Demande à l’agent de parcourir l’échelle de dépannage :

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

L’agent teste lui-même la plupart des échelons — il envoie un message syslog synthétique, vérifie l’écouteur et lit le propre journal de NXLog — puis il t’indique quel saut a perdu ton événement. Sous Windows 11, le coupable habituel est un réseau Wi-Fi classé Public alors que la règle est liée au profil Private.

Étape 6 : rends le pipeline durable

Une dernière invite :

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.

L’utilisation de fichiers tampons avant l’ingestion n’est pas un compromis — NXLog Community Edition ne peut de toute façon pas écrire directement dans une base de données sous Windows, et les fichiers tampons servent aussi de preuves brutes rejouables. La vérification du code de sortie est importante : n’archive un fichier qu’après que SQLite a confirmé son chargement, sinon un verrouillage temporaire peut faire disparaître silencieusement une heure de journaux.

Document en pixel art allant vers une bobine de câble, puis vers une barricade rayée, un cylindre protégé, une coche verte et une caisse munie d'une serrure — La barricade représente la vérification du code de sortie : la caisse ne se ferme qu'après que SQLite a confirmé le chargement.

Étape 7 : interroge tes journaux

La récompense, volontairement placée à la fin — l’analyse ne vaut que ce que vaut le pipeline sur lequel elle repose. Essaie :

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.

Cette dernière exigence fait réellement la différence. Un agent obligé de contester ses propres constatations te signale la tentative d’attaque par force brute sur le VPN, pas ton téléviseur qui cherche un micrologiciel à 3 heures du matin. Chaque constatation est accompagnée de preuves que tu peux vérifier — car le compte de l’agent ne peut rien faire d’autre que lire.

Personne en pixel art tenant une loupe devant un écran qui répertorie des types de constatations avec des identifiants d'événements, ainsi qu'un bloc-notes d'explications bénignes plausibles — Le bloc-notes correspond à la dernière exigence de l'invite : chaque constatation doit résister à une explication banale.

Les pièges qui te feront perdre du temps

La règle du pare-feu est liée au profil Public. Sous Windows 11, le Wi-Fi utilise par défaut le profil Public et bloque silencieusement le trafic entrant sur le port 514. Passe le réseau en Private ou lie la règle à tous les profils que tu utilises.

Le collecteur s’est mis en veille. UDP ne réessaie pas — une machine Win11 en veille perd tous les événements jusqu’à son réveil. powercfg /change standby-timeout-ac 0.

Les journaux arrivent, mais pas ceux dont tu as besoin. « Syslog fonctionne » et « les événements de sécurité sont transférés » sont deux options distinctes sur la plupart des pare-feu. Une catégorie manquante possède son propre filtre.

L’EDR a mis NXLog en quarantaine. Un nouveau binaire qui ouvre un port d’écoute ressemble à un logiciel malveillant. Ajoute une exclusion de chemin avant l’installation, pas après.

L’agent veut réparer le pare-feu à ta place. N’étends pas sa portée parce que l’étape 5 s’est bien passée. La lecture seule avec des propositions constitue l’état permanent sûr.

Ce que tu as maintenant

Ton pare-feu a toujours communiqué. Tu en as maintenant la preuve sur disque, un historique que tu peux interroger et un analyste disponible qui lit tout et ne touche à rien. La prochaine fois que quelque chose semblera anormal sur le réseau, tu ne liras pas des discussions de forum — tu interrogeras tes propres journaux.