capítulo 01

Arquitetura & Threat Model

Antes de instalar qualquer coisa, vale entender por que as peças estão separadas do jeito que estão — e o que pode dar errado no próprio laboratório, não só no honeypot.

As quatro peças

O honeypot (Cowrie) e o sensor de rede (Suricata) observam o mesmo tráfego de dois jeitos diferentes e independentes. O Cowrie finge ser um servidor SSH/Telnet vulnerável e registra tudo que um visitante tenta fazer dentro dele. O Suricata não sabe nada sobre esse teatro — ele só olha os pacotes de rede chegando na interface, e reconhece padrões (uma tentativa de SSH, um scan de porta, uma assinatura de exploit conhecida) independente do que está por trás.

Essa independência é o ponto: se o Cowrie falhar silenciosamente, ou se alguém encontrar um jeito de escapar do sandbox dele, o Suricata continua vendo o tráfego de qualquer forma — ele opera numa camada abaixo, direto na interface de rede.

Onde cada peça roda

O Suricata roda nativo, fora de qualquer container, porque precisa de acesso direto e de baixo nível à interface de rede — meter uma camada de virtualização de rede do Docker no meio só adiciona complexidade sem ganho. O Cowrie, ao contrário, é exatamente o componente que mais se beneficia de isolamento, já que é o que fica exposto de propósito ao mundo — por isso ele vive dentro de um container, numa rede Docker dedicada, sem rota pra mais nada na máquina.

Isolamento de rede

A regra geral: só as portas do honeypot são alcançáveis de fora. Tudo o resto — gestão SSH da máquina, o dashboard do Grafana, a API do Loki — fica restrito à rede local ou a 127.0.0.1, nunca exposto.

• Porta de gestão SSH: só aceita conexões da rede local.
• Grafana e Loki: bind em 127.0.0.1, acessados via túnel SSH quando necessário — nunca publicados na rede.
• Só duas portas são de fato encaminhadas no roteador: as do Cowrie (SSH e Telnet falsos).

Threat model do próprio laboratório

Framework aplicado: STRIDE, focado na superfície que este projeto introduz na rede — o honeypot receber ataques é esperado; o risco real é o que acontece se o isolamento falhar.

Ameaça	Cenário	Mitigação	Prioridade
Elevação de privilégio	Falha de escape do sandbox do Cowrie, execução no host por trás do container	Container sem --privileged, usuário não-root, rede Docker isolada, imagem sempre atualizada	alta
Adulteração de evidência	Tentativa de apagar logs locais pra cobrir rastro, após um comprometimento	Logs replicados quase em tempo real pra fora do host (Loki), não dependem só da cópia local	alta
Exposição de informação	Dashboard ou API do Loki acessível publicamente por engano	Bind exclusivo em 127.0.0.1, nunca encaminhado no roteador	alta
Negação de serviço	Volume de conexões satura CPU/RAM da máquina, derrubando o próprio IDS	Limites de recurso no container, ruleset do Suricata dimensionado pro hardware disponível	média
Falsificação	Confusão entre o serviço de gestão real e o honeypot, se estiverem na mesma porta/rede	Gestão SSH em porta não-padrão, só acessível pela rede local	média

Rodando numa VM, na sua máquina principal?

Se o laboratório vai rodar numa máquina virtual dentro do computador que você usa no dia a dia (em vez de hardware dedicado), vale um ajuste de expectativa: o pior cenário de uma falha de isolamento deixa de ser "reflashar um dispositivo barato" e passa a ser "algo escapou até a máquina que você usa pra trabalhar". Isso não inviabiliza o projeto, mas justifica endurecer a própria VM — desabilitar clipboard e pastas compartilhadas entre host e VM, manter o hypervisor atualizado, e usar snapshots.