Anti-DDoS para ISP: RTBH, FlowSpec e o que funciona de verdade

Quando um ataque volumétrico chega, ele não pede licença. Em poucos segundos o uplink satura, o jitter dispara, e o que era problema de um cliente vira problema de toda a base — porque o gargalo passa a ser o seu próprio enlace de trânsito. A boa notícia é que você não precisa começar comprando um scrubbing center caro. A maioria dos provedores já tem, no roteador de borda que opera hoje, as primitivas para montar uma defesa em camadas decente. O que falta, quase sempre, é desenho e disciplina operacional.

Este texto é sobre o que funciona na borda de um ISP brasileiro: blackhole/RTBH, FlowSpec e uRPF, mais a higiene básica que multiplica o efeito de todas elas.

O modelo mental: onde o ataque dói

Antes de mitigar, entenda a física do problema. Existem dois tipos de saturação:

Saturação do enlace de trânsito. O ataque enche o seu link de uplink (trânsito IP ou PTT) antes mesmo de chegar no roteador. Aqui, qualquer filtro dentro da sua rede é inútil — o dano já aconteceu na entrada. A solução tem que acontecer a montante, no provedor de trânsito.
Saturação de um host/cliente. O ataque mira um IP específico (um cliente, um servidor de jogos, um endereço de CGNAT). O volume cabe no seu uplink, mas derruba o alvo. Aqui você tem espaço para agir com precisão.

Essa distinção define qual ferramenta usar. RTBH resolve o primeiro caso ao custo de sacrificar o alvo; FlowSpec resolve o segundo com cirurgia; uRPF previne uma classe inteira de ataques na origem.

RTBH: o martelo que você anuncia para fora

Remotely Triggered Black Hole é o mecanismo mais simples e o mais importante de ter funcionando antes da crise. A ideia: você anuncia via BGP, para o seu provedor de trânsito, uma rota /32 do IP sob ataque marcada com uma community de blackhole. O upstream, ao recebê-la, descarta todo o tráfego daquele destino na borda dele — ou seja, antes de chegar no seu link saturado.

Pontos práticos que separam quem tem RTBH de papel de quem tem RTBH de verdade:

Combine com o trânsito antecipadamente. Cada upstream publica a community que aciona o blackhole. A RFC 7999 padronizou a community well-known 65535:666 (BLACKHOLE), mas muitas operadoras ainda usam communities próprias — confirme com cada uma e documente. No IX.br, o blackhole via servidor de rotas também segue a RFC 7999.
RTBH sacrifica o alvo. Você está, deliberadamente, tirando aquele IP do ar para salvar o resto da rede. É uma decisão de triagem, não uma cura. Comunique o cliente.
Automatize o gatilho e o timeout. Anunciar é fácil; lembrar de retirar o anúncio depois que o ataque cessa é o que falha na prática. Defina expiração automática.
RTBH local também serve. Anunciar o /32 para dentro, apontando para Null0, protege o restante da rede quando o ataque cabe no seu uplink mas mira a infraestrutura interna.

RTBH é grosseiro, mas é o seu botão de pânico confiável. Tem que estar testado e na ponta dos dedos do plantão.

FlowSpec: o bisturi (com manual de uso obrigatório)

BGP FlowSpec (RFC 8955) resolve a limitação do RTBH: em vez de descartar tudo para um destino, ele propaga regras de filtragem por múltiplos critérios — IP de origem/destino, protocolo, portas, flags TCP, tamanho de pacote. Dá para dizer "descarte UDP porta 19 (CharGen) para este /32" e manter o serviço legítimo no ar.

É poderoso e perigoso na mesma medida:

O suporte é desigual. Juniper e Cisco têm implementações maduras; no RouterOS (Mikrotik) o suporte historicamente é fraco ou ausente, o que pesa muito no mercado brasileiro. Verifique versão e capacidade de hardware antes de prometer FlowSpec ao cliente — em muitas plataformas a aplicação é em software e tem teto de PPS.
Uma regra ruim derruba você. FlowSpec aplica filtros na rede inteira de uma vez. Um critério mal escrito vira um self-DoS. Trate cada regra como mudança de produção: revisão, escopo mínimo, expiração.
Upstream FlowSpec é raro no Brasil. Diferente do RTBH, poucos trânsitos aceitam FlowSpec de cliente. Na prática, FlowSpec é arma interna: você o gera (manualmente ou via detecção por NetFlow/sFlow) e aplica nos seus próprios roteadores.

FlowSpec brilha contra ataques de reflexão/amplificação (DNS, NTP, memcached, SSDP) onde a assinatura de porta/protocolo é clara. Para tráfego que imita o legítimo, ele não substitui um scrubbing dedicado.

uRPF e higiene de borda: barato e subestimado

Boa parte do problema de DDoS no mundo existe porque redes deixam sair pacotes com IP de origem forjado (spoofing). O uRPF (Unicast Reverse Path Forwarding) e o BCP 38 (filtragem anti-spoofing na borda do assinante) cortam isso na origem.

uRPF em modo strict descarta pacotes cuja origem não casa com a rota de retorno pela mesma interface — ideal em links de assinante single-homed.
uRPF loose apenas verifica se a origem existe na tabela; é o que se usa em borda multi-homed sem quebrar rotas assimétricas.
Aplicar isso na ponta do cliente impede que a sua rede seja origem de ataques de reflexão — protege a internet e, mais imediatamente, mantém você fora de listas de reputação ruins e do desgaste de receber notificações de abuso e acionamentos do CERT.br.

Some a isso o básico que poucos mantêm: ACLs negando portas de amplificação conhecidas onde fizer sentido, control-plane policing para o roteador não cair junto com o ataque, e rate-limit de ICMP. Nenhum desses itens é glamoroso. Todos reduzem o tamanho do ataque que você precisa mitigar.

O que separa defesa de improviso: detecção e processo

Ferramenta sem detecção é reação manual no escuro. Você precisa enxergar o ataque chegando — coletores NetFlow/sFlow/IPFIX medindo PPS e bps por prefixo, com baseline do que é normal na sua rede, disparando o gatilho de RTBH ou a regra de FlowSpec. E precisa de runbook: quem aciona, qual community por upstream, qual o critério para sacrificar um /32, como e quando reverter.

Aqui o operacional pesa tanto quanto a topologia. Saber na hora qual a community de blackhole de cada trânsito, quais ASNs e prefixos são seus, quem é o contato de NOC do upstream e onde está cada credencial de acesso ao roteador é a diferença entre mitigar em dois minutos ou em vinte com o link saturado. É exatamente esse tipo de inventário vivo — prefixos, ASNs, enlaces, contatos e credenciais com cofre 2FA — que faz o NetPulse ganhar valor durante um incidente: a informação que você precisaria caçar já está documentada e à mão do plantão.

Resumindo a estratégia

uRPF/BCP 38 primeiro: barato, previne, e tira você da lista de quem causa DDoS.
RTBH sempre pronto: seu botão de pânico para ataques que saturam o uplink, acordado com cada trânsito.
FlowSpec onde o hardware aceita: cirurgia interna contra amplificação, tratada com o cuidado de uma mudança de produção.
Detecção + runbook: sem isso, as três camadas acima são só configuração parada.

Montar e operar essas camadas — do desenho na borda ao runbook do plantão e à detecção por fluxo — é trabalho de engenharia de rede, não de produto de prateleira. A CloudFace faz isso junto com você: consultoria e NOC para desenhar a defesa anti-DDoS na sua borda, mais o NetPulse para manter inventário, IPAM e credenciais prontos quando o ataque chega. Se quiser, mande um "oi" no WhatsApp e a gente faz um diagnóstico inicial gratuito da sua borda — sem compromisso.