Simulação de Resposta a Incidentes com LLM Local

Uma versão em japonês disso está no Note.

RoamSwitch é uma ferramenta de segurança de rede que eu construí sozinho para Mac e Linux. É Zero Telemetry, então nada sobre o seu uso sai da máquina, e quando detecta um comportamento que parece ransomware, faz algo drástico: corta todo o tráfego de rede. Chamamos isso de contenção Air-Gap. É a última linha de defesa contra exfiltração de dados e propagação lateral, e eu venho lidando com um fato desconfortável desde que a lancei.

No instante em que o Air-Gap dispara e interrompe sua conexão, qualquer IA em nuvem que você normalmente utilizaria, incluindo Claude Desktop, fica no escuro.

O Air-Gap dispara exatamente no momento em que você mais precisa de clareza. Algo está errado, e você precisa descobrir o que, sem entrar em pânico, e decidir o que fazer a seguir. Mas a ferramenta que você normalmente usaria está do outro lado da conexão que você acabou de cortar.

A única coisa que pode preencher essa lacuna é um modelo que nunca precisou da rede em primeiro lugar. O RoamSwitch já envia um servidor MCP (Model Context Protocol) somente leitura que agentes de IA podem consultar. Conecte isso a um LLM local rodando no Ollama, e o diagnóstico ainda deve funcionar mesmo com a rede completamente fora do ar.

Essa é a teoria, de qualquer forma. Teoria e "funciona de fato quando importa" são coisas diferentes. Detectores de fumaça que você nunca ouviu disparar são os que você confia menos. Então, em vez de esperar por um incidente real, eu realizei um exercício, não para apagar um incêndio, mas para descobrir se a ferramenta e eu realmente saberíamos o que fazer se um começasse.

1. As ferramentas MCP do RoamSwitch são sensores somente leitura, nada mais

Vale a pena afirmar desde o início: o servidor MCP do RoamSwitch não possui ferramentas que mudam a configuração ou alteram um estado de bloqueio. Um agente de IA só pode ler diagnósticos: portas expostas, status de proteção, histórico de incidentes. Nada do que faz pode piorar as coisas.

Para este exercício, usei três ferramentas que acabamos de lançar: get_port_anomaly_incidents, que retorna o histórico de portas de escuta suspeitas que o Guardião de Anomalias de Portas bloqueou automaticamente; get_ebpf_incidents, o histórico de contenção do guardião eBPF da Edição do Servidor; e get_canary_status, que relata se o canário de ransomware (um arquivo decoy) foi adulterado.

Todos os três são exatamente o tipo de evidência primária que poderia ser a razão pela qual o Air-Gap disparou em primeiro lugar. Até recentemente, nenhum deles era acessível a partir de um processo MCP separado, porque os dados do incidente só existiam na memória do daemon residente. Nós apenas persistimos isso em disco para que o MCP pudesse lê-lo, o que tornou natural colocá-lo em um exercício.

2. Encenação do incidente nos arquivos de estado reais do RoamSwitch

Você não acende um fogo real para um exercício de incêndio, e eu não estava prestes a rodar um ransomware real. Em vez disso, escrevi um cenário encenado diretamente nos arquivos de estado que o próprio RoamSwitch escreve (/var/lib/roamswitch/port_guard.json e canary_incidents.json), e confirmei via JSON-RPC bruto anteriormente que as ferramentas MCP podiam lê-lo corretamente.

Aqui está o cenário. Às 19:00:12, um processo desconhecido backdoor_svc (PID 88231) começa a escutar na porta 4444, a porta padrão bem conhecida do Metasploit para reverse-shell, e o Guardião de Anomalias de Portas o detecta e bloqueia automaticamente. Cerca de quatro minutos depois, às 19:04:47, o mesmo processo grava dados criptografados em um arquivo decoy monitorado (~/Documents/.roamswitch_security_canary_do_not_delete.xlsx), e o Canário de Ransomware o captura e bloqueia a gravação. É uma cadeia bastante plausível: acesso inicial, depois, alguns minutos depois, criptografia estilo ransomware.

Eu passei essa configuração para um LLM local (qwen3.8:27b, rodando Q4-quantizado no Ollama) através da ponte MCP embutida do RoamSwitch. Sem dicas, sem nomes de ferramentas especificados, apenas uma pergunta aberta, da mesma forma que você realmente perguntaria durante um incidente real:

Eu: "O RoamSwitch parece ter detectado algo incomum. Investigue o que está acontecendo nesta máquina agora. Diga-me tudo o que você puder encontrar: quando aconteceu, qual processo estava envolvido, o que ele fez e se há alguma atividade de rede suspeita ou adulteração."

3. Observando o modelo construir sua própria investigação

Esta foi a parte mais interessante. Eu não disse o que verificar, e ele começou a chamar ferramentas MCP por conta própria:

🔧 get_guard_status              → verificar quais guardas estão habilitados
🔧 get_port_anomaly_incidents    → puxar o histórico de anomalias de portas
🔧 get_ebpf_incidents            → verificar contenção em nível de eBPF (nenhum encontrado)
🔧 get_canary_status             → puxar o histórico de detecção do canário
🔧 get_quarantine_status         → também verificar malware em quarentena
🔧 audit_security_logs           → auditar logs de segurança recentes também
🔧 get_exposed_ports             → verificar as portas atualmente expostas
🔧 verify_fim                    → tentar uma verificação de integridade de arquivos

Ele não parou em "uma porta foi bloqueada." Ele começou a verificar se a mesma trilha aparecia no canário, no eBPF, nos logs, para ver se isso era um falso positivo isolado ou algo maior. Essa é a mesma intuição de triagem que um analista humano executa por reflexo.

Aqui está o que veio de volta depois que ele reuniu tudo. Ele respondeu em japonês, então esta é uma tradução fiel, não parafraseada ou resumida:

[A SAÍDA DA IA COMEÇA AQUI]

Relatório de Investigação de Segurança do RoamSwitch

Resumo: Entre 19:00 e 19:05 em 2026-09-09, um processo backdoor oculto backdoor_svc (PID 88231) comunicou-se externamente neste host, e então adulterou (criptografou) um arquivo canário, em um que parece ser um incidente combinado de backdoor e ransomware. O RoamSwitch o detectou e já isolou automaticamente quatro portas anômalas e contenção da adulteração.

1. Linha do tempo (todos os horários JST, 2026-09-09)

• 19:00:12 — /tmp/.hidden/backdoor_svc (PID 88231) detectado na porta 4444; portas 9005 / 33999 / 8791 sinalizadas simultaneamente.
• 19:00:12 — RoamSwitch isola automaticamente todas as 4 portas (4444, 9005, 33999, 8791). Linha de base já capturada.
• 19:04:47 — Arquivo canário /home/tetsuharu/Documents/.roamswitch_security_canary_do_not_delete.xlsx detectado adulterado/criptografado. Suspeita-se do mesmo ator, backdoor_svc (PID 88231). O RoamSwitch o conteve (isContained: true).
• 20:21:46 — Timestamp da inspeção mais recente do RoamSwitch (hora atual de verificação).

2. Perfil do processo suspeito

• Caminho do binário: /tmp/.hidden/backdoor_svc
• Nome do processo: backdoor_svc
• PID: 88231
• Método de ocultação: colocado sob um diretório pontilhado .hidden em /tmp/ (evitando visibilidade)
• Porta primária: 4444 (uma porta clássica de backdoor / reverse-shell)
• Portas anômalas associadas: 9005, 33999, 8791 (presumivelmente canal C2 ou uso de exfiltração de dados)

(⚠️ Uma estrutura de caminho /tmp/.hidden/ é um padrão típico que malware usa para auto-exclusão e evasão de detecção.)

3. Avaliação de impacto

3-1. Anomalias de rede (porta)

• 4444: presumivelmente canal C2 (comando e controle) para a própria backdoor.
• 9005 / 33999 / 8791: presumivelmente usados para exfiltração de dados secundária ou comunicação com outro C2.
• Todas as 4 portas foram isoladas automaticamente pelo RoamSwitch.
• A única porta de manutenção atualmente ativa é 22 (SSH). A possibilidade de que o acesso SSH não autorizado foi a inf