Pipeline de logs de firewall com o Cursor

Você fez tudo o que a documentação mandava. Ativou o registro remoto no equipamento pfSense, apontou para sua máquina Windows e abriu a porta UDP 514. Nada chegou. Há mais de uma década, o fórum da Netgate acumula discussões sobre esse exato silêncio — logs gerados, mas nunca enviados, e o syslogd morrendo discretamente depois de uma reinicialização. Em algum lugar entre o firewall e seu disco, o evento desapareceu — e nada nessa cadeia vai dizer onde.

A solução convencional é um SIEM, que troca um problema por outro maior: agora você precisa administrar o Elasticsearch. Este guia segue um caminho diferente. Você abre o Cursor, responde a cinco perguntas e aprova comandos enquanto um agente de IA monta o pipeline de logs do firewall. No fim, você terá um evento verificado do firewall no disco, um histórico pesquisável em um banco de dados local e um analista de IA que lê seus logs — mas não pode tocar no seu firewall.

Estrutura total: um serviço do Windows, uma pasta e um arquivo SQLite.

Firewall de tijolos em arte pixelada, cubo coletor do Windows, tambor protegido do SQLite e um cursor detetive inspecionando através de uma linha tracejada — A linha tracejada é o modelo de segurança: olhar, sem tocar.

O pipeline de logs de firewall que você vai montar

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

O pfSense é o exemplo usado ao longo do texto, mas qualquer firewall compatível com syslog funciona — OPNsense, UniFi, SonicWall ou um switch gerenciável. O NXLog Community Edition recebe dados na porta 514 e grava arquivos JSON de spool. Uma tarefa agendada os carrega no SQLite. O agente consulta esse banco de dados com acesso somente leitura e informa o que encontra.

Espere — o Cursor não é uma ferramenta de programação?

É assim que ele é divulgado. Por baixo, o Cursor é um agente que lê arquivos, grava arquivos e executa comandos de terminal com sua aprovação. O mundo de um administrador de sistemas é feito de arquivos: configurações, logs, scripts e bancos de dados. Você não vai escrever uma linha de código — usará dois controles, a caixa de chat e o botão de aprovação. O agente escreve a configuração do NXLog, o esquema SQL e o script de ingestão; você lê e clica em sim.

Pré-requisitos

Requisito	Observações
Windows 10/11 ou Server 2019+, x64	O NXLog CE não tem uma versão para Windows ARM64
IP estático na máquina coletora	Uma reserva DHCP também funciona
A máquina permanece ligada	No Win11, desative a suspensão ou os logs UDP desaparecerão silenciosamente
Direitos de administrador	A instalação do serviço exige elevação de privilégios
Qualquer firewall capaz de enviar syslog	Você acessará o painel administrativo dele uma vez
Cursor instalado	O plano gratuito é suficiente

Etapa 1: cinco respostas antes de qualquer execução

Crie uma pasta — C:\fw-pipeline — e abra-a no Cursor. Crie um arquivo, 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

Tudo o que o agente gera deriva dessas cinco linhas. O fabricante e a versão determinam os cliques exatos que ele indicará. O IP do firewall vira a chave do dispositivo no banco de dados. data_stays_local: true significa que a análise é executada no banco de dados local — os logs brutos nunca são colados em massa em um prompt.

Os detalhes que este post não aborda estão em dois arquivos complementares — a referência de implantação e as perguntas frequentes sobre solução de problemas. O agente baixa os dois na próxima etapa; os links estão aí caso você queira consultá-los primeiro.

Prancheta em arte pixelada com cinco respostas alimentando uma máquina identificada como criação da configuração do agente, com um objeto coberto por um pano na esteira — A caixa coberta é a questão central: nada é montado até que essas cinco linhas sejam preenchidas.

Etapa 2: proteções antes do agente

Cinquenta e três por cento dos administradores de sistemas não deixariam uma IA tocar no ambiente de produção sem supervisão. É o instinto correto. Não coloque as regras no prompt — coloque-as onde o agente não possa ignorá-las. Crie .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.

O Cursor carrega essas regras em cada sessão nessa pasta. O agente propõe; você aprova. É o mesmo modelo de confiança que você aplicaria a um administrador júnior recém-contratado — com a diferença de que este nunca fica entediado e lê cada linha de log.

Agente em arte pixelada segurando mudanças propostas enquanto uma pessoa aponta para Aprovar em uma tela de comandos pendentes, com uma linha vermelha tracejada antes de um firewall e um banco de dados bloqueado — Nada naquela prancheta é fato até cruzar a linha tracejada.

Etapa 3: deixe o agente montar o coletor

Agora vem o primeiro prompt de verdade — cole-o no 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.

Você aprovará uma instalação MSI, um nxlog.conf gerado e uma regra New-NetFirewallRule. Verifique dois detalhes na configuração gerada: parse_syslog() na entrada, para que tanto o RFC 3164 quanto o RFC 5424 sejam recebidos corretamente, e um SockBufSize maior, porque o buffer UDP padrão do Windows é minúsculo e perde rajadas de dados.

Verifique:

Get-Service nxlog   # Status: Running

Etapa 4: aponte o firewall para o coletor

Esta é a única etapa manual. O agente lê answers.yaml e fornece os cliques exatos para sua plataforma, mas é você quem os executa — o firewall permanece fora do alcance dele. No pfSense: Status → System Logs → Settings → Remote Logging — ative, informe o IP do coletor e a porta 514 e marque as categorias desejadas. Em outros firewalls, a receita é a mesma: destino = IP do coletor, porta 514, RFC 5424 se houver essa opção.

Uma regra que todo mundo esquece: se o coletor estiver em outro segmento, o firewall precisará de uma regra de saída que permita a ele alcançar a porta 514. Um firewall não registrará o próprio syslog descartado.

Etapa 5: o primeiro evento — ou o ponto onde ele morreu

Observe a pasta de spool. Se um arquivo fw-*.json aparecer e crescer, a parte difícil terminou. Se nada aparecer — é aqui que todos os outros guias dão de ombros. Peça ao agente que percorra a sequência de diagnóstico:

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

O agente testa sozinho a maioria dos pontos — envia um pacote syslog sintético, verifica o processo que está escutando a porta e lê o log do próprio NXLog — e diz em qual salto o evento foi descartado. O culpado mais comum no Windows 11: a rede Wi-Fi foi definida como Pública, enquanto a regra está vinculada à rede Privada.

Etapa 6: torne o pipeline durável

Mais um 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.

Usar spool antes da ingestão não é uma concessão — o NXLog Community Edition não consegue gravar diretamente em um banco de dados no Windows, e os arquivos de spool também funcionam como evidência bruta que pode ser reprocessada. A verificação do código de saída é importante: arquive um arquivo somente depois que o SQLite confirmar o carregamento, ou um bloqueio temporário apagará silenciosamente uma hora de logs.

Documento em arte pixelada passando para uma bobina de cabo, depois por uma barreira listrada, um cilindro protegido, uma marca verde de confirmação e uma caixa com fechadura — A barreira é a verificação do código de saída: a caixa só fecha depois que o SQLite confirma o carregamento.

Etapa 7: faça perguntas aos seus logs

A recompensa vem por último de propósito — a qualidade da análise depende da qualidade do pipeline que a sustenta. Experimente:

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.

Essa última exigência faz diferença de verdade. Um agente obrigado a contestar as próprias conclusões alerta você sobre uma tentativa de força bruta contra a VPN, não sobre sua TV procurando atualizações de firmware às 3 da manhã. Cada descoberta vem acompanhada de evidências que você pode verificar — porque a conta do agente não pode fazer nada além de ler.

Pessoa em arte pixelada com uma lupa diante de um monitor que lista tipos de descobertas com IDs de eventos, ao lado de um bloco de notas com explicações benignas plausíveis — O bloco de notas representa a última exigência do prompt: cada descoberta precisa resistir a uma explicação entediante.

Armadilhas que vão fazer você perder tempo

A regra do firewall está vinculada ao perfil Público. No Wi-Fi, o Windows 11 usa o perfil Público por padrão e descarta silenciosamente o tráfego recebido na porta 514. Defina a rede como Privada ou vincule a regra a todos os perfis que você usa.

O coletor entrou em suspensão. O UDP não faz novas tentativas — uma máquina com Windows 11 suspensa perde todos os eventos até despertar. powercfg /change standby-timeout-ac 0.

Os logs chegam, mas não os que você precisa. “O syslog funciona” e “os eventos de segurança são encaminhados” são opções separadas na maioria dos firewalls. Uma categoria ausente tem seu próprio filtro.

O EDR colocou o NXLog em quarentena. Um binário novo abrindo uma porta de escuta parece malware. Adicione uma exclusão de caminho antes da instalação, não depois.

O agente quer corrigir o firewall para você. Não amplie o alcance dele só porque a etapa 5 funcionou. O estado permanente seguro é acesso somente leitura com propostas.

O que você tem agora

Seu firewall sempre esteve falando. Agora há provas no disco, um histórico que você pode consultar e um analista de plantão que lê tudo e não toca em nada. Da próxima vez que algo parecer errado na rede, você não estará lendo discussões em fóruns — estará fazendo perguntas aos seus próprios logs.