Minhas Primeiras 24 Horas Executando um Honeypot DNS

Como engenheiro que passa a maior parte dos dias imerso em ferramentas de observabilidade, tenho ocasionalmente uma ideia que simplesmente preciso colocar em prática. Este foi um desses experimentos: subir um resolvedor DNS em um IP limpo que ninguém anuncia, e depois deixar a internet falar com ele de qualquer forma. A única função do resolvedor era ficar quieto, registrar tudo e alimentar o Grafana com as consultas resultantes. Um docker compose up -d depois, eu tinha Unbound, Loki, Prometheus, Grafana e Traefik rastreando tráfego ao vivo e imprimindo histogramas de curiosidade, má configuração e o escaneador ocasional. Este README é o relatório desse primeiro dia, o que a pilha captura, por que isso é importante para mim e o que destaca sobre o cenário de segurança atual.

O experimento

Introduzi intencionalmente zero sinal da minha parte, sem descarte de pacotes, sem respostas personalizadas, sem mitigação. Apenas Unbound com registro ativado, Loki monitorando o arquivo de log, Prometheus coletando métricas do exportador, Traefik na frente do Grafana e Docker Compose conectando tudo. O resolvedor estava em 94.130.27.226, um IPv4 “limpo” refrescante que eu havia encontrado (verifique seu status em https://www.abuseipdb.com/check/94.130.27.226 se quiser uma base pré-ruído), e deixei o mundo fazer o que queria. Um único laptop podia assistir a todos os painéis, executar tools/dns_query_storm.sh quando eu quisesse agitar as coisas, e depois deixar o ruído se acomodar nos padrões que a internet global escolhesse enviar.

Você pode dar uma olhada nesses painéis ao vivo em https://dns.cybersafeintl.co.uk/public-dashboards/eb554b5b74e14f4d95e376c0033ee83d, embora estejam no servidor mais básico da pilha, então espere atualizações lentas durante consultas pesadas.

O que os painéis capturam

• Throughput: O Prometheus coleta a métrica unbound_total_num_queries do exportador do Unbound, então o painel “Throughput (QPS, 5m rate)” mostra consultas por segundo e detalha por origem. Essa visão responde à pergunta “quem está martelando o resolvedor?”, picos repentinos apontam diretamente para ASNs baseados em Bangladesh ou Polônia, e os logs facilitam ver se tempestades de SERVFAIL/NXDOMAIN acompanham as rajadas.
• Top clients: O LogQL do Loki agrupa por client_ip, e os painéis já encapsulam tudo em topk(sort_desc(...)). Isso mantém os painéis limpos enquanto o script exportador me permite despejar as mesmas consultas em CSVs para análise offline, relatórios ou histórias reproduzíveis. A primeira captura mostrou cinco endereços IP nas faixas 45.179.* e 45.6.*, cada um disparando mais de 5k consultas em cinco minutos, seja uma fazenda de scanners ou um cliente agressivo.
• Domínios: Os painéis “Top domains” exibem a popularidade de qname em janelas de 5m e 24h. O instantâneo de 5 minutos apresentou scb.se, dhl.com e cmu.edu, enquanto a exportação de 24h incluiu cbs.nl, scb.se, atlassian.com, e . Por que esses domínios? Essa é a parte interessante: são serviços legítimos, resolvedores mal configurados ou scanners oportunistas em busca de registros obsoletos? Mande uma nota se tiver uma teoria.

Cada painel que você vê tem um CSV correspondente em exports/; empacote-os (zip -r exports.zip exports/) quando quiser anexar a história bruta a uma postagem de blog ou relatório de incidente.

O que está por baixo dos panos

• docker-compose.yml sobe Unbound, o exportador do Unbound, Loki + Promtail, Prometheus, Grafana e Traefik com um único comando.
• unbound/ armazena configurações e logs do resolvedor. Controles de TTL, serve-expired e configurações de cache mantêm a fidelidade para capturarmos o que os clientes realmente pedem.
• Os diretórios prometheus/, loki/ e grafana/ contêm dados e arquivos de provisionamento para que métricas e painéis sobrevivam a reinicializações.
• grafana/dashboards/unbound-traffic-insights.json é pré-provisionado com a visão que você vê; todas as consultas PromQL/Loki já agregam e ordenam para manter os painéis legíveis.
• tools/dns_query_storm.sh permite simular tempestades de consultas quando você precisa testar tempos de reação.
• redeploy.sh automatiza a parada de toda a pilha, a atualização e a reconstrução com um único script.
• export_dashboard_data.py agora percorre o JSON do painel, executa cada consulta Prometheus/Loki e escreve arquivos CSV sanitizados em um diretório exports/ para compartilhamento.

Começando

1. cd hetzner_deploy/unbound-dns
2. cp .env.example .env e configure GRAFANA_DOMAIN, credenciais de admin do Grafana, LETSENCRYPT_EMAIL e quaisquer substituições de TLS necessárias.
3. sudo chown -R 472:472 grafana-data && sudo mkdir -p prometheus/data && sudo chown -R 65534:65534 prometheus/data
4. docker compose build && docker compose up -d
5. Aponte um cliente DNS para o host na porta 53, deixe o Traefik no HTTPS para o Grafana, e você estará assistindo tráfego passivo em minutos.

Exportando e compartilhando o que você vê

1. pip install requests (o exportador é Python puro).
2. python export_dashboard_data.py --duration 24h --outdir exports/24h --timeout 90 para extrair todas as consultas do painel, converter para CSV e colocar os resultados em exports/24h.
3. zip -r exports.zip exports/ para empacotar as tabelas brutas antes de publicá-las, anexá-las a uma postagem de blog ou enviá-las a colaboradores.
4. Execute novamente com --duration 6h ou timestamps --end para fatias direcionadas, ou use --filter domains se quiser apenas os painéis de domínio.

O que notei no primeiro dia

Na exportação granular de 5 minutos, scb.se, dhl.com, cmu.edu, up.pt e utc.fr geraram centenas de milhares de consultas cada. Por que esses alvos? A constelação de domínios corporativos europeus me faz suspeitar de uma CDN, serviço de restauração ou scanner tentando reidratar caches obsoletos.

A exportação de 24 horas pinta um quadro ainda maior: cbs.nl, scb.se, atlassian.com, abb.com e up.pt geraram coletivamente mais de 250 milhões de consultas. Esse nível de volume não é ruído aleatório, são clientes de grande escala ou um appliance persistente que nunca para de resolver.

Os clientes mais ativos foram um punhado de endereços IPv4 45.179.* e 45.6.*, cada um disparando mais de 5k consultas nos cinco minutos observados. Eles podem fazer parte de um ISP ou fazenda de scanners, mas sejam o que forem, os painéis tornam trivial rastreá-los.

O que isso destaca? Ilustra como uma infraestrutura DNS exposta pode se tornar um feed passivo de tráfego interessante mesmo quando não é anunciada. A internet continua fazendo perguntas, e esta configuração simplesmente ouve com atenção. Se você está curioso sobre como este experimento se encaixa no meu trabalho mais amplo, confira os outros repositórios, às vezes eu coloco uma ideia dessas em prática e preciso ver aonde ela leva.

Como este experimento tem sido sentido

• Esta configuração custa centavos e ainda assim parece um laboratório de pesquisa inteiro. Ver o resolvedor se encher de consultas não solicitadas fez a pilha parecer viva, meio inquietante mas fascinante.
• Não estou filtrando nada, então se quiser testá-lo sob estresse ou apontar seus próprios scripts para ele, vá em frente. Os painéis mostrarão exatamente quanto ruído você agitou.
• As exportações facilitam preservar esse ruído. Compacte a pasta exports/ ou anexe os CSVs diretamente onde você conta a história.
• Ainda estou curioso sobre esses domínios e IPs de clientes; se você vir padrões semelhantes no seu próprio honeypot, deixe as estatísticas aqui para compararmos notas.

Para onde ir a partir daqui

• Adicione Alertmanager ou scripts personalizados se quiser reagir a anomalias como rajadas de SERVFAIL ou tempestades repentinas de NXDOMAIN.
• Estenda export_dashboard_data.py ou consultas Loki com metadados adicionais (ASN do cliente, motivo de SERVFAIL, país) para responder perguntas mais profundas.
• Alimente a saída do Loki em um pipeline de análise secundário, ou despeje os CSVs do Prometheus em um notebook para experimentos de classificação.
• Mantenha a história viva: execute novamente o exportador com novas janelas (--duration 12h, --end ...), mantenha as saídas em diretórios com carimbo de data/hora e atualize este README com as estatísticas recentes para que a trama se mantenha atual.

Se você está acompanhando com seu próprio honeypot, atualize este README com estatísticas de suas exportações para que possamos comparar histórias e ver se os mesmos sites e clientes continuam voltando.

Aviso Legal

Este projeto é fornecido “como está.” Não há garantias de qualquer tipo, expressas ou implícitas, incluindo, mas não se limitando a comercialização, adequação a um propósito específico ou não violação, e não sou responsável por quaisquer danos decorrentes de seu uso. Você assume todos os riscos associados à implantação, configuração ou operação desta pilha.

Suporte

Se você achar este projeto útil, considere apoiá-lo: