Você já ouviu um data center gritar? Não com palavras, mas com o zumbido ensurdecedor de milhares de discos rígidos tentando se sincronizar após um pico de tráfego não filtrado. Aconteceu comigo numa terça-feira, 3h da manhã, horário de Brasília.
O Caso do DNS Silencioso
O alerta chegou pelo Telegram do engenheiro de plantão: latência de 450ms para consultas DNS. Parecia pânico, mas era o começo de um ataque. Alguém tinha descoberto o servidor DNS autoritativo de uma corretora que operava em cinco continentes. Não era um ataque volumétrico, era cirúrgico: requisições DNS legítimas, mas em rajadas assimétricas — cada consulta parecia vir de um endpoint diferente, todas com o mesmo TTL de 1 segundo. O comportamento era robótico, mas inteligente.
A Anatomia do Erro
O servidor rodava BIND, versão 9.16, compilado com as flags padrão. Ninguém pensou em limitar o rate de consultas por IP de origem. O hardware era um VPS de 4 vCPUs, 8 GB de RAM, alocado como ‘máquina de produção’. Para o time, era apenas um bind resolver decente. Ninguém suspeitou que aquele VPS compartilhado poderia ser o calcanhar de Aquiles de uma operação de milhões de dólares.
O pior erro? A falta de um firewall de DNS. Sim, isso existe. É um firewall que inspeciona consultas DNS, identifica padrões anômalos e bloqueia antes que o cache enlouqueça. Nós não tínhamos. O ataque aproveitou a fragilidade do cache negativo (NXDOMAIN cache) para forçar o servidor a manter registros inválidos, aumentando a carga de CPU e memória. Em 20 minutos, o servidor parou de responder consultas legítimas.
O Patch Sujo que Salvou a Bolsa
Me lembro de estar em casa, no meio da madrugada, com o celular vibrando sem parar. Um dos colegas sugeriu: ‘E se a gente configurara o nftables para limitar o rate por IP a 10 consultas por segundo?’. Era a solução mais óbvia, mas ninguém tinha feito. O patch foi aplicado enquanto o servidor ainda estava no ar, com o firewall implantado em 30 segundos. A latência caiu para 2ms em cinco minutos. O cache foi limpo manualmente com uma série de comandos rndc flush e rndc status. O ataque continuou, mas foi absorvido.
Depois, descobrimos que o responsável era um script Python malicioso rodando em uma máquina na mesma rede interna da corretora. Alguém tinha se infiltrado via SSH com credenciais fracas. O servidor DNS era apenas um trampolim. Se tivéssemos implementado rate limiting proativo e configurado um cache DNS separado por zona (usando views no BIND), o ataque nem teria começado. Mas ninguém pensa em views para segurança, pensam? A verdade é que a segurança de DNS é uma arte negra — ignorada até que o pânico bate.
Lições do Subsolo da Infraestrutura
- Rate Limiting é sua mãe: Em servidores DNS autoritativos, configure
rate-limitno BIND (ourate-limitno NSD). Use respostas truncadas (TC=1) para evitar amplificação. - Firewall de Aplicação: Considere um módulo como o DNSDist ou o CoreDNS com plugins de filtragem. Eles inspecionam a semântica das consultas, não só os cabeçalhos.
- Cache Compartimentado: Use
viewsno BIND para criar caches diferentes para consultas internas e externas. Um vazamento de cache de zonas internas pode expor sua topologia de rede. - Monitoramento de Anomalias: Métricas como ‘consultas por segundo com TTL=1’ ou ‘consultas do tipo ANY subitamente altas’ são indicadores de ataque. Instale um agente como o Prometheus com um exporter de DNS.
- Nunca subestime o VPS: Sua VPS pode ser o gargalo invisível. Faça testes de stress com simulação de tráfego real, usando ferramentas como
dnsperf.
No final, o data center não gritou. Ele sussurrou: o barulho dos discos era apenas o som da redundância sendo posta à prova. Mas a lição ficou: o pior ataque não é o que derruba o servidor, é o que demora a ser percebido. O silêncio que antecede o caos. Agora, olhe para seus servidores DNS. Você sabe o que eles estão falando?