2

Pitch: Fiz um firewall de aplicação open source que mostra e bloqueia cada conexão de saída por processo

Sempre quis um Little Snitch / LuLu open source que funcionasse de verdade no Windows, macOS e Linux. Acabei construindo o Snitch (AGPL-3.0) — um firewall de aplicação que mostra em tempo real cada conexão de saída por processo e permite bloquear com um clique.

O que ele faz

  • Captura local via libpcap/Npcap (ctypes, sem Scapy) com parser próprio IPv4/IPv6/TCP/UDP/DNS/TLS-SNI
  • Bloqueio por processo: eBPF, NFQUEUE, nftables ou WFP no Windows — com modo ask-on-first-connect
  • Motor de regras compatível com Sigma + YARA-L, threat intel 100% offline
  • Detecção de domínios DGA, túneis ICMP, beaconing e anomalias (Isolation Forest)
  • 100% local: GeoIP offline (DB-IP/MaxMind), API só no 127.0.0.1 com token, zero telemetria, sem conta
  • Agente Rust leve para servidores headless, exportação SIEM (ECS/CEF/JSON/Syslog), Docker/Helm/Ansible/GPO
  • Interface em 8 idiomas — incluindo português (pt-BR)

Stack

Backend Python (FastAPI + WebSocket), frontend React/Vite, empacotado em Electron. Tem modo demo (SNITCH_DEMO=1) que gera tráfego sintético pelo pipeline real — dá para testar tudo sem root.

GitHub: https://github.com/aixisstudio/Snitch

Feedback é muito bem-vindo — principalmente de quem mexe com netsec ou eBPF.

Carregando publicação patrocinada...
1

Uma coisa que eu olharia é como fica a regra quando o processo é um interpretador. Muito servidor MCP e ferramenta de agente roda via npx ou uvx, então quem abre a conexão é sempre o node ou o python. Se a regra for por executável, liberar o node uma vez libera tudo que roda em cima dele. Dá pra diferenciar pela linha de comando ou pelo processo pai? Pro caso de vigiar agente que o Oletros citou isso faz bastante diferença.

1

Boa pergunta — você tocou num ponto real.

Hoje o Snitch já diferencia na atribuição: a aba de processos mostra a linha de comando completa e a cadeia de pais, então node /…/mcp-server.js aparece distinto de outro node qualquer.

Mas as regras de bloqueio casam por executável — é a mesma limitação do WFP ALE_APP_ID no Windows e do owner match do iptables: a camada de kernel filtra por identidade do binário, não por argv. Ou seja, liberar node hoje libera tudo que roda nele — exatamente o problema que você descreveu com npx/uvx.

O caminho honesto que eu vejo:

  • Regras de alerta por cmdline (regex): viável já — cada spawn do npx gera um PID novo com argv distinto, resolvemos PID→cmdline no momento do evento e cacheamos
  • Bloqueio por cmdline: aplicável no caminho de veredito em userspace (NFQUEUE/ask-mode no Linux); no Windows o WFP não expõe argv, seria resolução por PID — mais frágil mas possível
  • Parent process matching: a cadeia já é coletada, falta expor como campo de regra

Ressalva honesta: argv é controlável pelo próprio processo, então é heurística boa pra distinguir agentes/MCPs, não fronteira de segurança rígida. Pra isso o ideal seria eBPF/cgroup no Linux — já temos eBPF no roadmap.

Abri a issue #61 pra trackear: github.com/aixisstudio/Snitch/issues/61 — valeu pelo olhar afiado, é exatamente o tipo de feedback técnico que a gente precisa.

1

valeu por abrir a issue. no Linux tem um meio-termo antes do eBPF que talvez ajude: subir cada servidor MCP no próprio scope com systemd-run --user --scope e casar a regra pelo cgroup (o iptables tem -m cgroup --path no cgroup v2, e o nftables tem socket cgroupv2). aí o node de um MCP e o node do outro ficam separados sem depender do argv, que o próprio processo consegue mudar. o lado chato é que depende de como o cliente sobe o processo, então ia precisar de um wrapper no comando do MCP.

1

Meus 2 cents,

Parabens pela iniciativa !

Eh um sistema interessante para controlar agentes - para ver onde os guardrails e sandbox nao estao sendo o bastante.

Repositorio devidamente starreado e forkeado, obrigado por compartilhar !

Saude e Sucesso !


Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS