O que é esse negócio de parquinho pegando fogo
Você provavelmente já ouviu alguém do ramo falar "vai montar um parquinho pegando fogo" e ficou achando que era metáfora. Não é. É a tradução de mão aberta do que os gringos chamam de honeypot, só que aqui no Brasil virou gíria de departamento de segurança antes de virar termo de dicionário. O conceito é simples demais pra causar confusão, mas a execução é onde todo mundo erra. Você coloca um sistema aparentemente valioso, mas isolado, cheio de portas abertas e senhas óbvias, esperando que o invasor morda a isca. A parte do "pegando fogo" vem justamente do fato de que, quando alguém tenta atacar, você vê tudo: IPs, técnicas, horários, ferramentas. É um show de dados.
Montando seu parquinho pegando fogo sem destruir a infraestrutura real
A primeira coisa que precisa entender é que um honeypot mal configurado vira vulnerabilidade ativas no seu ambiente. Eu já vi isso acontecer na prática. Um colega meu, por volta de 2019, montou um servidor Supercopy rodando num VPS de teste pra coletar logs de ataques. Esqueceu de isolar a rede corretamente. O primeiro bot que entrou no sistema usou uma falha no próprio serviço de isca pra escalar e alcançar a VLAN de desenvolvimento. Levamos três dias pra conter. Então a regra número um: isole. Use uma VLAN completamente separada, sem rota de retorno para a rede principal. Configure firewall com política de negação padrão. Tudo que entra no parquinho deve entrar e sair num túnel controlado. Não confie em regras de firewall que você escreveu apressado.
Agora sobre a escolha do que simular. Tem dois caminhos: low-interaction e high-interaction. Low-interaction é mais seguro, menos manutenção, roda em minutos. Exemplos são o Cowrie (simula SSH e Telnet), o Dionaea (simula Samba, HTTP, MySQL) e o HPEx. High-interaction é um sistema operacional real, com serviços reais rodando. Aí você coleta dados muito mais ricos, mas o risco de escape é real. Se não tem experiência prévia com análise forense, comece pelo low-interaction. Para o Cowrie, que é o ponto de entrada mais comum, o processo básico é: baixe a imagem Docker oficial, configure o docker-compose apontando a porta 2222 para a 22, defina senhas fake no arquivo de configuração, e rode. Em quinze minutos você tem um simulador de SSH ativo. Os logs vão parar em JSON dentro do container. Aí você precisa de algo pra processar esses logs. O HoneyPy ou o otterlog podem fazer esse trabalho.
O erro mais comum é achar que só monitorar é suficiente. Monitorar sem alertar é só juntar dado pra nada. Configure alertas por e-mail ou para uma ferramenta como o Graylog quando houver múltiplas tentativas de login falhas vindas do mesmo IP. Isso reduz o ruído e foca no que importa.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que esperar ver no lado de lá
Se você levantar um parquinho pegando fogo com pelo menos uma porta exposta à internet, começa a receber tentativa de acesso em questão de horas. Dias, no máximo. Os alvos mais comuns são SSH, RDP, serviços web vulneráveis, e scanners de IoT. A frequência varia conforme o ASN e a reputação do seu IP. IPs com histórico de abuso recebem mais tráfego de bots simples. IPs limpos recebem mais reconhecimento dirigido. Dentro dos logs, você vai notar padrões repetitivos. Scanners massivos usam ferramentas como ZMap e Masscan. Ataques dirigidos mostram comportamento diferente: testes manuais de credenciais, enumeração de versões, tentativas de exploração de vulnerabilidades específicas. Conseguir distinguir esses dois grupos é o que separa um parquinho que gera insight de um que só gera ruído.
Uma coisa que poucos mencionam é a utilidade do timeout. Se você configura seus serviços de isca com timeouts agressivos, o atacante gasta mais tempo e energia. Isso é intencional. Cada segundo que o script de ataque passa tentando conexão inútil é um segundo que ele não passa vasculhando seus sistemas reais. Não é defesa, é custo elevado para o inimigo.
Sobre limites e quando isso não funciona
Honeypots não previnem ataques. Eles informam sobre eles. Se a sua expectativa é que o parquinho impeça alguém de entrar na sua rede, você está confundindo detecção com prevenção. A prevenção acontece com hardening, segmentação, patch management e monitoramento contínuo dos serviços reais. Também tem o problema de falsos positivos. Um scanner legítimo de auditoria de segurança pode ser confundido com ataque malicioso. Um cliente que está testando sua própria infraestrutura pode tocar seu honeypot sem querer. Configure labels nos logs e, se possível, whitelist de IPs conhecidos de parceiros de segurança.
E tem ainda a questão legal. Em alguns países, capturar tráfego de attackers sem consentimento pode criar ambiguidades jurídicas. No Brasil, a LGPD se aplica a dados pessoais, e logs de ataque muitas vezes contêm informações que podem ser consideradas dados pessoais. Revise com um jurídico se for armazenar esses logs por períodos longos. O mínimo necessário, pelo tempo necessário, é o padrão a seguir. Se você quer algo mais prático pra começar agora, o projeto HoneyDB tem uma lista pública de honeypots ativos e configurações que você pode estudar. Não é download de ferramenta, é referência de arquitetura. Leia as configurações publicadas por outros timeops, compare com o que você pretende fazer, e ajuste antes de colocar no ar. Isso economiza horas de retrabalho.
