Um guia prático com as principais medidas que todo provedor de internet deve adotar para resistir e se recuperar rapidamente de ataques DDoS.
Ataques DDoS são uma realidade constante para provedores de internet brasileiros. A boa notícia é que grande parte do impacto pode ser reduzida ou eliminada com práticas de engenharia aplicadas antes do ataque acontecer. Este artigo reúne as principais medidas que um ISP deve adotar para aumentar sua resiliência.
O IPv6 é raramente alvo de ataques DDoS volumétricos. A esmagadora maioria das botnets e ferramentas de ataque ainda opera exclusivamente sobre IPv4, pois é onde estão concentrados os serviços e endereços expostos. Ao migrar assinantes, servidores DNS e interfaces de gerência para IPv6, o provedor reduz substancialmente a superfície de ataque.
Outro benefício direto é a redução de custos com serviços de mitigação em nuvem, que geralmente cobram pelo volume de tráfego IPv4 limpo entregue. Menos IPv4 exposto significa menos tráfego de ataque a ser processado — e menos conta no final do mês.
O DNS é um dos principais vetores de amplificação e alvo direto de ataques. Dois recursos combinados aumentam muito a resiliência: o hyperlocal e o anycast.
O hyperlocal consiste em manter uma cópia local da zona raiz da internet dentro do próprio servidor de resolução recursiva do ISP. Com isso, mesmo que os root servers estejam inacessíveis durante um ataque — ou que o link do provedor esteja saturado —, o DNS interno continua resolvendo normalmente para os assinantes.
Já o anycast distribui o mesmo endereço IP de DNS entre múltiplos servidores em localidades distintas. Quando um ataque volumétrico chega, ele se dilui entre os pontos de presença em vez de concentrar em um único servidor, tornando a derrubada muito mais difícil.
Loops de rota estática são um multiplicador silencioso de dano. Quando um ataque direciona tráfego para um prefixo que possui loop, o roteador processa o mesmo pacote repetidamente, consumindo CPU e banda simultaneamente no upload e no download. O impacto final é desproporcional ao volume do ataque.
Muitos provedores só descobrem que têm loops durante um ataque real, quando já é tarde. O correto é fazer uma auditoria preventiva de todas as rotas estáticas, garantindo que não existe dependência circular entre next-hops e que rotas de sumário apontem para descarte (blackhole) e não para interfaces dinâmicas.
Um loop de roteamento durante um ataque DDoS pode derrubar links que normalmente suportariam bem o tráfego. Corrija antes que um ataque exponha o problema.
MikroTik é amplamente usado em ISPs brasileiros pela excelente relação custo-benefício. Porém, diferente de equipamentos com ASICs dedicados ao forwarding, o RouterOS processa o tráfego pela CPU do equipamento. Isso cria um ponto de vulnerabilidade específico durante ataques volumétricos.
O equívoco mais comum é criar regras de firewall para descartar o tráfego de ataque diretamente no MikroTik. O problema é que, mesmo sendo descartado, cada pacote ainda precisa ser recebido e processado pela CPU antes do drop — o que pode travar o equipamento inteiro. A solução mais eficaz é retirar o tráfego malicioso antes que ele chegue ao MikroTik, usando blackhole no uplink ou FlowSpec.
Links ponto a ponto entre roteadores com endereços IPv4 públicos são alvos fáceis e frequentemente ignorados. Um ataque direcionado especificamente ao IP de uma interface pode sobrecarregar a control plane do roteador, derrubando todo o tráfego que passa por ele — mesmo que o link em si tenha capacidade para absorver o ataque.
A solução é simples: use endereços privados (RFC 1918) nos enlaces internos. Para links com peers e upstreams, muitos operadores já aceitam negociar interconexão em espaço privado. O que não tem endereço público não pode ser atacado diretamente.
Detectar um ataque DDoS manualmente e reagir a ele é lento demais. Ferramentas como Wanguard e FastNetMon analisam o NetFlow e o sFlow da rede em tempo real, identificam anomalias de tráfego e disparam contramedidas automaticamente — tudo isso em questão de segundos.
Sem automação, o processo de identificar o ataque, localizar o prefixo afetado, acionar o uplink e configurar o blackhole pode levar minutos ou até horas. Com um sistema automatizado, esse ciclo completo acontece antes que a maioria dos assinantes perceba qualquer degradação.
O FastNetMon tem uma versão open-source funcional que pode ser a porta de entrada para automação de mitigação sem custo inicial. Para ambientes maiores, o Wanguard oferece relatórios, integração com múltiplos uplinks e scrubbing centers.
As BGP communities são o principal mecanismo para solicitar ações ao seu upstream durante um ataque. A mais importante é a community de blackhole: ao anunciar um prefixo com ela, o uplink descarta todo o tráfego destinado àquele IP antes mesmo de encaminhá-lo para você. O ataque é bloqueado na borda do uplink, não na sua rede.
Na hora de contratar ou avaliar um uplink, questione quais communities estão disponíveis. Os melhores oferecem blackhole por AS de origem, por região geográfica e por tipo de protocolo — o que permite uma mitigação cirúrgica, bloqueando apenas o tráfego malicioso sem afetar os legítimos.
Túneis GRE são muito usados para encaminhar tráfego limpo de scrubbing centers de volta para o ISP. O problema é que o encapsulamento GRE adiciona overhead ao pacote, e sem o ajuste correto do TCP MSS (Maximum Segment Size), os pacotes TCP acabam sendo fragmentados. Fragmentação excessiva causa retransmissões, aumenta a latência e degrada a experiência do usuário — justamente quando a rede já está sob pressão.
Além do ajuste do MSS, uma boa prática é usar GRE sobre IPv6 sempre que possível, pois reduz o risco de o endereço do próprio túnel se tornar alvo de ataque.
Uma ferramenta de mitigação que nunca foi testada em produção tem grandes chances de falhar no momento em que mais importa. Sistemas mal configurados, integrações quebradas ou limiares incorretos só aparecem quando um ataque real acontece.
Programe testes periódicos fora do horário de pico: valide se a detecção automática está funcionando, se o blackhole é acionado dentro do tempo esperado e se os contatos e runbooks da equipe NOC estão atualizados. Descobrir uma falha durante um teste controlado é muito melhor do que descobri-la às 3h da manhã durante um ataque.
Documente um runbook de resposta a ataques: quem aciona o quê, em qual ordem, com quais contatos de uplink. Sem isso, cada ataque vira uma improvisação.
As práticas acima cobrem bem as necessidades da maioria dos provedores. Mas existem camadas adicionais de proteção que poucos ISPs brasileiros implementam completamente e que fazem diferença significativa:
Se tiver que escolher um ponto de partida, comece pelo RPKI. É gratuito, melhora a segurança do roteamento da internet como um todo e pode ser habilitado em qualquer roteador moderno em menos de uma hora.