capítulo 06
Lições Aprendidas
O que fica depois de montar isso do zero, e por onde continuar.
Princípios que se confirmaram na prática
- Duas fontes de verdade independentes valem mais que uma sofisticada. O honeypot e o IDS nunca dependeram um do outro pra funcionar — quando um teve problema de configuração, o outro continuou registrando normalmente, e essa independência foi o que tornou o diagnóstico possível em vários pontos.
- Container minimalista corta dois lados. A imagem do Cowrie não ter utilitários básicos é ótimo pra reduzir superfície de ataque, mas também quebra hábitos comuns de debug (como usar
docker exec ... tail) — vale sempre verificar o que uma imagem "oficial" realmente contém antes de assumir. - IPv4 e IPv6 são duas superfícies de exposição diferentes. Regra de firewall pensada só em IPv4 pode deixar um buraco inteiro do lado do IPv6, sem nenhum sinal óbvio de que isso aconteceu.
- "Sem erro" não é o mesmo que "funcionando". Mais de uma vez, um serviço subiu sem reclamar (Suricata com interface errada, Alloy sem permissão de leitura) e simplesmente não fez o que devia, silenciosamente. Validar o resultado fim-a-fim importa mais do que confiar em "não deu erro".
- Snapshots mudam a relação com o risco. Ter a opção de voltar a um estado limpo em segundos deixa mais seguro testar mudanças mais arriscadas do que seria razoável fazer em hardware físico sem essa rede de segurança.
o resultado final
Um honeypot recebendo tentativas reais e não solicitadas da internet, um IDS classificando esse tráfego de forma independente, e um dashboard mostrando os dois lados da história em tempo real — construído, quebrado, e consertado o suficiente pra virar este guia.
Próximos passos possíveis
- Enriquecimento de geolocalização. Um estágio de lookup GeoIP (MaxMind GeoLite2) antes dos logs chegarem no Loki permite um painel de mapa mostrando de onde vêm as tentativas.
- Mais protocolos no honeypot. Cowrie cobre SSH/Telnet; existem honeypots especializados em outros serviços (HTTP, bancos de dados, RDP) que podem rodar em paralelo, cada um na sua própria rede isolada.
- Alertas ativos. Em vez de só olhar o dashboard, configurar o Grafana pra notificar (email, webhook) quando um padrão específico aparecer — um pico de tentativas, ou uma assinatura de severidade alta do Suricata.
- Migrar pra hardware dedicado. Se o laboratório está numa VM na máquina do dia a dia, vale considerar mover pra um dispositivo próprio assim que o setup estiver validado — reduz o pior cenário de uma falha de isolamento de volta pra "só aquele dispositivo", não a máquina de trabalho.
Fontes e documentação oficial
- Suricata — Quickstart guide
- Suricata — Adding Your Own Rules
- Cowrie — repositório oficial
- Cowrie — imagem Docker oficial
- Grafana Loki — Install with Docker
- Grafana Alloy — Install on Linux
- Grafana Alloy — Monitor logs from a local file
- VBoxManage — referência de comandos
licença de uso
Este material foi escrito como registro pessoal de um laboratório de segurança defensiva, com fins educacionais. Sinta-se à vontade pra adaptar, republicar com atribuição, ou usar como base pro seu próprio projeto.