O que foi implantado em 2015/2016
O trabalho “Estudo e implementação de um Honeypot Freeware em um ambiente de produção” implantou Kippo em CentOS 6.5 dentro de uma VM XenServer com IP público. O ambiente real possuía dois links dedicados (120 e 100 Mbit/s), servidores e equipamentos com endereços públicos. A metodologia foi: pesquisa, escolha do honeypot, preparação da VM, instalação, observação, geração de estatísticas e análise.
Os números abaixo pertencem ao experimento original e não são estatísticas atuais da Internet. Eles são preservados como evidência de um cenário real de 2015.
Arquitetura e metodologia originais
As imagens abaixo foram extraídas do próprio trabalho de 2016 e são mantidas como material histórico.
MetodologiaPesquisa → implantação → observação → gráficos → análise.
CenárioTopologia original do ambiente onde o sensor foi implantado.
KippoConfiguração histórica do honeypot SSH.O que os atacantes fizeram
O Kippo-Graph mostrou predominância do usuário root, senhas triviais e combinações previsíveis. O estudo também registrou comandos executados, transferências/downloads, reprodução de sessões e geolocalização aproximada das origens. Esses dados demonstram por que serviços SSH públicos recebem varredura e brute force automatizados rapidamente.
Usuáriosroot foi o principal nome tentado.
SenhasCredenciais simples aparecem entre as primeiras tentativas.
Sucesso controlado229 autenticações foram aceitas pelo honeypot para permitir observação.Não reproduza literalmente a instalação de 2016
- CentOS 6.5, Python 2.5+, PyCrypto e o endereço code.google.com do Kippo são legado.
- Kippo não deve ser apresentado como implementação atual; use Cowrie.
- Kippo-Graph/LAMP/phpMyAdmin não devem ser expostos publicamente como no desenho histórico.
- Credencial fraca é deliberada apenas dentro do sensor isolado; nunca é recomendação para um servidor real.
- Geolocalização de IP não identifica o atacante e pode refletir VPN, proxy, botnet ou infraestrutura comprometida.
Como implantar o equivalente em 2026
Internet
│
[Firewall/NAT]
│ TCP/22 externo → TCP/2222 sensor
▼
[VM/Container dedicado: Cowrie]
│ egress deny-by-default
├── cowrie.json / tty / downloads
│
└──► [coletor de logs/SIEM em rede de gerência]
Administração real SSH ──► rede/porta separada ──► host- Crie VM/host dedicado e segmento próprio.
- Bloqueie egress por padrão; libere somente destinos estritamente necessários para operação.
- Instale Cowrie com usuário não-root e virtualenv/pip ou container oficial.
- Mantenha SSH administrativo real fora da porta pública do honeypot.
- Redirecione TCP/22 externo para a porta do Cowrie somente após validar acesso administrativo alternativo.
- Envie logs para coletor remoto e configure retenção.
- Trate downloads como malware potencial; gere hash e armazene em quarentena.
- Teste uma sessão controlada e confirme eventos de conexão, autenticação, comandos e encerramento.
Fluxo recomendado pelos mantenedores
sudo adduser --disabled-password cowrie
sudo su - cowrie
mkdir ~/my-honeypot && cd ~/my-honeypot
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install cowrie
cowrie init
$EDITOR etc/cowrie.cfg
cowrie startO fluxo pip é recomendado para operadores na documentação atual do Cowrie 3.x. Antes de expor a porta 22, valide localmente na porta do sensor e configure coleta de logs.
Teste de aceite do laboratório
- Conectar de IP de laboratório e confirmar banner/serviço do honeypot.
- Executar autenticação de teste e verificar evento correspondente no JSON.
- Executar comandos inofensivos e verificar reprodução/session log.
- Tentar download de arquivo controlado e confirmar quarentena/hash.
- Confirmar que o sensor não alcança destinos externos arbitrários.
- Confirmar que administração real não está acessível pela mesma exposição.
- Reiniciar/restaurar o sensor e verificar persistência dos dados que devem sobreviver.
Por que isso continua relevante
O CERT.br mantém em 2026 o Projeto Honeypots Distribuídos para detecção de incidentes, correlação e tendências de ataques no espaço Internet brasileiro. O projeto utiliza sensores de baixa interação distribuídos e publica estatísticas de tráfego malicioso. Isso valida o uso de honeypots como fonte de consciência situacional, desde que implantados com contenção e finalidade definida.
Fontes
- Trabalho original de 2016 fornecido para o portal: “Estudo e implementação de um Honeypot Freeware em um ambiente de produção”.
- Cowrie 3.x — documentação estável
- Cowrie — instalação atual
- CERT.br — Projeto Honeypots Distribuídos
- CERT.br — estatísticas e metodologia