Pipeline de registros de firewall con Cursor

Hiciste todo lo que indicaba la documentación. Activaste el registro remoto en el equipo pfSense, lo dirigiste a tu máquina Windows y abriste el puerto UDP 514. No llegó nada. El foro de Netgate lleva más de una década acumulando hilos sobre este silencio exacto: registros generados pero nunca enviados, syslogd inactivo sin avisar después de un reinicio. En algún punto entre el firewall y tu disco, el evento desapareció, y nada en la cadena te dirá dónde.

La solución estándar es un SIEM, que cambia un problema por otro mayor: ahora Elasticsearch es responsabilidad tuya. Esta guía toma un camino diferente. Abres Cursor, respondes cinco preguntas y apruebas comandos mientras un agente de IA crea el pipeline de registros del firewall. Al terminar, tendrás en el disco un evento de firewall verificado, un historial que puedes consultar en una base de datos local y un analista de IA que lee tus registros, pero no puede tocar tu firewall.

Huella total: un servicio de Windows, una carpeta y un archivo SQLite.

Firewall de ladrillos en pixel art, cubo colector de Windows, tambor protegido de SQLite y un cursor detective que inspecciona al otro lado de una línea discontinua — La línea discontinua es el modelo de seguridad: mirar, no tocar.

El pipeline de registros de firewall que vas a crear

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

pfSense es el ejemplo utilizado en toda la guía, pero sirve cualquier firewall compatible con syslog: OPNsense, UniFi, SonicWall o un switch gestionado. NXLog Community Edition recibe en el puerto 514 y escribe archivos JSON de spool. Una tarea programada los carga en SQLite. El agente consulta la base de datos en modo de solo lectura e informa de lo que encuentra.

Espera, ¿Cursor no es una herramienta de programación?

Eso es el marketing. Por debajo, Cursor es un agente que lee archivos, escribe archivos y ejecuta comandos de terminal con tu aprobación. El mundo de un administrador de sistemas está hecho de archivos: configuraciones, registros, scripts y bases de datos. No escribirás ni una línea de código; usarás dos controles, el cuadro de chat y el botón de aprobación. El agente escribe la configuración de NXLog, el esquema SQL y el script de ingesta; tú los lees y haces clic en sí.

Requisitos previos

Requisito	Notas
Windows 10/11 o Server 2019+, x64	NXLog CE no tiene una compilación para Windows ARM64
IP estática en la máquina colectora	Una reserva DHCP también sirve
La máquina permanece encendida	Win11: desactiva la suspensión o los registros UDP desaparecerán sin avisar
Derechos de administrador	La instalación del servicio necesita elevación de privilegios
Cualquier firewall que pueda enviar syslog	Tendrás que entrar una vez en su panel de administración
Cursor instalado	El plan gratuito es suficiente

Paso 1: cinco respuestas antes de ejecutar nada

Crea una carpeta, C:\fw-pipeline, y ábrela en Cursor. Crea un archivo, 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

Todo lo que genera el agente deriva de estas cinco líneas. El fabricante y la versión determinan los pasos exactos que te indica. La IP del firewall se convierte en la clave del dispositivo en la base de datos. data_stays_local: true significa que el análisis se ejecuta sobre la base de datos local: los registros sin procesar nunca se pegan en bloque en un prompt.

Los detalles que omite este artículo están en dos archivos complementarios: la referencia de despliegue y las preguntas frecuentes sobre solución de problemas. El agente los descarga en el paso siguiente; puedes abrir los enlaces antes si quieres echarles un vistazo.

Portapapeles en pixel art con cinco respuestas que alimentan una máquina etiquetada como agente creando la configuración, con un objeto cubierto por una tela en la cinta transportadora — La caja cubierta es la clave: no se crea nada hasta que completas esas cinco líneas.

Paso 2: barreras de seguridad antes del agente

El cincuenta y tres por ciento de los administradores de sistemas no permitiría que una IA tocara producción sin supervisión. Es el instinto correcto. No pongas las reglas en el prompt: ponlas donde el agente no pueda ignorarlas. Crea .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 carga estas reglas en cada sesión de esta carpeta. El agente propone; tú apruebas. Es el mismo modelo de confianza que aplicarías a un administrador junior recién llegado, salvo que este nunca se aburre y lee cada línea de registro.

Agente en pixel art que sostiene cambios propuestos mientras una persona señala Aprobar en una pantalla de comandos pendientes, con una línea roja discontinua delante de un firewall y una base de datos bloqueada — Nada de ese portapapeles es un hecho hasta que cruza la línea discontinua.

Paso 3: deja que el agente cree el colector

Ahora viene el primer prompt de verdad; pégalo en el chat:

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.

Aprobarás una instalación MSI, un archivo nxlog.conf generado y una regla New-NetFirewallRule. Comprueba dos detalles de la configuración generada: parse_syslog() en la entrada, para que tanto RFC 3164 como RFC 5424 se reciban correctamente, y un SockBufSize aumentado, porque el búfer UDP predeterminado de Windows es diminuto y pierde las ráfagas.

Verifica:

Get-Service nxlog   # Status: Running

Paso 4: dirige el firewall hacia el colector

El único paso manual. El agente lee answers.yaml y te indica los pasos exactos para tu plataforma, pero eres tú quien los ejecuta: el firewall permanece fuera de su alcance. En pfSense: Status → System Logs → Settings → Remote Logging; activa la opción, introduce la IP del colector y el puerto 514, y marca las categorías que quieras. En otros firewalls se sigue la misma receta: destino = IP del colector, puerto 514, RFC 5424 si está disponible.

Una regla que todo el mundo olvida: si el colector está en otro segmento, el firewall necesita una regla de salida que le permita llegar al puerto 514. Un firewall no registrará su propio syslog descartado.

Paso 5: el primer evento o el lugar donde murió

Vigila la carpeta de spool. Si aparece un archivo fw-*.json y aumenta de tamaño, la parte difícil ha terminado. Si no aparece nada, aquí es donde todas las demás guías se encogen de hombros. Pide al agente que recorra la escalera:

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

El agente prueba por sí mismo la mayoría de los peldaños: envía un paquete syslog sintético, comprueba el proceso que escucha y lee el propio registro de NXLog; después te dice en qué salto se perdió tu evento. El culpable habitual en Windows 11 es una conexión Wi-Fi configurada como Public mientras la regla está asociada a Private.

Paso 6: hazlo duradero

Un prompt más:

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.

Usar spool antes de la ingesta no es una concesión: NXLog Community Edition no puede escribir directamente en una base de datos en Windows, y los archivos de spool sirven además como evidencia sin procesar que puedes volver a reproducir. La comprobación del código de salida importa: archiva un archivo solo después de que SQLite confirme la carga, o un bloqueo transitorio se tragará una hora de registros sin avisar.

Documento en pixel art que fluye hacia una bobina de cable, después hacia una barrera a rayas, un cilindro protegido, una marca verde y una caja con cerradura — La barrera es la comprobación del código de salida: la caja solo se cierra después de que SQLite confirme la carga.

Paso 7: haz preguntas a tus registros

La recompensa, deliberadamente al final: el análisis solo es tan bueno como el pipeline que lo sustenta. Prueba esto:

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.

Esa última cláusula hace un trabajo de verdad. Un agente obligado a argumentar contra sus propios hallazgos te avisa del intento de fuerza bruta contra la VPN, no de que tu televisor esté buscando firmware a las 3 a. m. Cada hallazgo llega con evidencia que puedes verificar, porque la cuenta del agente no puede hacer nada salvo leer.

Persona en pixel art con una lupa ante un monitor que enumera tipos de hallazgos con identificadores de eventos, y un bloc de notas con explicaciones benignas plausibles — El bloc de notas es la última cláusula del prompt: cada hallazgo tiene que sobrevivir a una explicación aburrida.

Errores que te harán perder el tiempo

La regla del firewall está asociada al perfil Public. Windows 11 en Wi-Fi usa Public de forma predeterminada y descarta sin avisar el tráfico entrante del puerto 514. Configura la red como Private o asocia la regla a todos los perfiles que uses.

El colector entró en suspensión. UDP no reintenta: un equipo con Win11 suspendido pierde todos los eventos hasta que se reactiva. powercfg /change standby-timeout-ac 0.

Llegan registros, pero no los que necesitas. “Syslog funciona” y “se reenvían los eventos de seguridad” son opciones distintas en la mayoría de los firewalls. Una categoría ausente tiene su propio filtro.

El EDR puso NXLog en cuarentena. Un binario nuevo que abre un puerto a la escucha parece malware. Añade una exclusión de ruta antes de instalarlo, no después.

El agente quiere arreglar el firewall por ti. No amplíes su alcance solo porque el paso 5 salió bien. El acceso de solo lectura con propuestas es el estado permanente seguro.

Dónde te deja esto

Tu firewall siempre estuvo hablando. Ahora hay pruebas en el disco, un historial que puedes consultar y un analista de guardia que lo lee todo y no toca nada. La próxima vez que algo parezca ir mal en la red, no estarás leyendo hilos de foros: se lo preguntarás a tus propios registros.