DDoS scrubbing com BGP: como funciona a mitigação no nível de roteamento para operadores
Os ataques DDoS continuam sendo um dos vetores de interrupção mais frequentes para ISPs e infraestrutura crítica na América Latina. A resposta instintiva de muitos operadores é buscar appliances ou serviços de scrubbing cloud, mas a realidade é que a primeira linha de defesa efetiva passa pelo BGP — o mesmo protocolo que move o tráfego de internet também pode ser usado para desviar, filtrar e bloquear ataques antes que saturem os enlaces dos clientes.
O RIPE Labs publicou em abril de 2026 uma análise dos cinco principais scrubbers do mundo vistos a partir de dados de roteamento BGP. Os padrões que essa análise revela são algo que os operadores LATAM deveriam entender: as diferenças entre mitigação always-on e on-demand não são apenas operacionais — têm implicações diretas na visibilidade RPKI e em como um ataque é (ou não é) visto de fora da sua rede.
O problema que o BGP resolve
Quando chega um ataque volumétrico — 50 Gbps de UDP flood, por exemplo — o problema não é apenas que o servidor destino não consegue processá-lo. O problema é que o tráfego já consumiu o enlace antes de chegar ao destino. Se o uplink do cliente é de 1 Gbps e o ataque chega a 10 Gbps, os 9 Gbps de excesso estão saturando sua rede de distribuição e afetando outros clientes.
A única forma de resolver isso é agir mais acima na topologia: desviar ou bloquear o tráfego de ataque antes que entre nos segmentos congestionados. O BGP é o mecanismo natural para isso porque permite sinalizar aos roteadores vizinhos que tratem um prefixo de uma maneira específica.
As três técnicas principais são RTBH, BGP Flowspec e scrubbing por desvio (sink-then-reinject).
Técnica 1: RTBH — Remote Triggered Black Hole
O RTBH (Remotely Triggered Black Hole, RFC 5635) é a técnica mais simples e a mais amplamente implementada. O princípio é direto: quando um prefixo está sendo atacado, anuncia-se uma rota para ele com uma community especial que indica aos roteadores upstream que descartem esse tráfego em vez de reencaminhá-lo.
Como funciona na prática
A maioria dos upstreams tem communities BGP documentadas para RTBH. Por exemplo, no formato clássico:
64496:666 → blackhole o prefixo destino (destination-based RTBH)
64496:9999 → blackhole o prefixo origem (source-based RTBH)
Quando você anuncia o prefixo atacado com essa community, o upstream descarta o tráfego para esse destino nos seus roteadores de borda — antes de entrar na sua rede.
Destination-based RTBH bloqueia todo o tráfego para o IP ou prefixo atacado. É efetivo mas também bloqueia o tráfego legítimo: o cliente deixa de receber ataques mas também deixa de receber serviço. Para ataques curtos ou quando o cliente está disposto a sacrificar disponibilidade temporariamente, é a resposta mais rápida.
Source-based RTBH é mais cirúrgico: bloqueia tráfego originado de IPs ou prefixos específicos conhecidos como fontes do ataque. Requer que você tenha identificado as fontes (que em ataques amplificados podem ser milhares de refletores legítimos) e que seu upstream suporte essa variante.
Configuração básica em IOS-XR
route-policy RTBH-TRIGGER
set community (64496:666) additive
set local-preference 50
set next-hop 192.0.2.1 # null route address
pass
end-policy
router bgp 65000
neighbor 203.0.113.1
address-family ipv4 unicast
route-policy RTBH-TRIGGER out
O que esse exemplo faz: quando um operador quer ativar RTBH para um prefixo, adiciona manualmente uma rota estática para 192.0.2.1 (o endereço de null route), que é redistribuída no BGP com a community de blackhole. O upstream recebe a rota com essa community e descarta o tráfego.
Técnica 2: BGP Flowspec
O BGP Flowspec (RFC 5575 / RFC 8955) é uma extensão do protocolo BGP que permite distribuir regras de filtragem de tráfego detalhadas como se fossem rotas. Diferente do RTBH (que trabalha apenas com prefixos origem/destino), o Flowspec pode filtrar combinando:
- IP origem e destino
- Porta origem e destino
- Protocolo (TCP, UDP, ICMP)
- Flags TCP
- DSCP
- Comprimento do pacote
- Fragmentação
Um caso real: filtrar amplificação DNS
Um ataque de amplificação DNS usa servidores DNS abertos para amplificar tráfego em direção ao alvo. O tráfego de ataque tem características muito específicas: UDP, porta 53 de origem, pacotes de resposta grandes (>512 bytes). O Flowspec pode filtrar exatamente isso sem bloquear o tráfego legítimo para o mesmo destino:
ip flowspec address-family ipv4 unicast
match destination-prefix 192.0.2.100/32
match source-port 53
match ip protocol 17 # UDP
match packet-length 512-65535
action drop
Essa regra é distribuída via BGP para todos os roteadores que a suportem e que tenham Flowspec ativado. Em uma rede própria ou com upstream que o suporte, isso pode ser ativado em segundos e bloquear o componente malicioso do ataque sem descartar o serviço completo.
Limitações do Flowspec
O Flowspec não é universalmente suportado. Os principais upstreams tier-1 e tier-2 têm suporte variável — alguns o oferecem como serviço adicional, outros simplesmente não o têm disponível. Na prática, o Flowspec é mais útil dentro da rede própria do ISP do que como ferramenta para sinalizar em direção ao upstream.
Outro desafio: a complexidade operacional. Regras Flowspec mal configuradas podem bloquear tráfego legítimo com muita facilidade. Requerem um processo de ativação e validação cuidadoso.
Técnica 3: Scrubbing por desvio (sink-then-reinject)
Esta é a arquitetura usada pelos serviços profissionais de scrubbing (Cloudflare, NETSCOUT, Radware, etc.) e que os ISPs maiores implementam internamente. O conceito: em vez de descartar o tráfego atacado, ele é desviado para um centro de limpeza (scrubbing center) onde é filtrado, e o tráfego legítimo é reinjetado em direção ao destino real.
O fluxo da mitigação
- O ataque é detectado (por anomalias de volume, tipo de tráfego, ou alertas manuais)
- O roteador de borda anuncia o prefixo atacado com uma rota mais específica que o desvia para o scrubbing center
- O scrubbing center recebe todo o tráfego (ataque + legítimo)
- Aplica análise e filtros: stateful inspection, rate limiting, pattern matching, challenge-response para HTTP
- O tráfego limpo é reinjetado em direção ao destino mediante um túnel GRE, MPLS ou VPN
Como isso se vê no BGP
De fora da rede, o scrubbing por desvio se vê como uma mudança de rota: o prefixo atacado começa a ser anunciado a partir de um endereço diferente (o scrubbing center). Se o scrubbing é always-on, essa rota existe permanentemente. Se é on-demand, a rota aparece quando a mitigação é ativada.
Aqui aparece a implicação RPKI que menciona a análise do RIPE Labs: se o scrubbing center está em um ASN diferente do proprietário legítimo do prefixo, o ROA do prefixo pode não cobrir esse ASN. Um observador externo com RPKI ativo veria o anúncio do prefixo a partir do scrubbing center como RPKI Invalid — o que pode causar que alguns pares com validação estrita descartem essas rotas.
A solução correta é que o scrubbing center anuncie o prefixo usando o ASN do cliente (através de trânsito direto) ou que o cliente crie um ROA adicional que autorize o ASN do scrubbing center como origem válida. Os operadores que implantam scrubbing de terceiros com RPKI ativo precisam coordenar isso explicitamente.
Always-on vs on-demand: o que escolher
| Critério | Always-on | On-demand |
|---|---|---|
| Latência de ativação | Instantânea | Minutos (manual) ou segundos (automático) |
| Custo de tráfego | Alto (tudo passa por scrubbing) | Baixo (apenas tráfego sob ataque) |
| Visibilidade BGP | Estável, sempre a partir do scrubber | Muda durante ativação |
| Risco de RPKI | Requer ROA coordenado desde o início | Risco durante a transição |
| Adequado para | Clientes críticos, baixo limiar de tolerância | Maioria dos clientes ISP |
Para a maioria dos ISPs LATAM de porte médio, a arquitetura recomendada é on-demand com ativação automática: um sistema de detecção (NetFlow + SNMP ou solução dedicada como NETSCOUT/NSFOCUS) aciona o desvio BGP automaticamente quando um limiar de tráfego anômalo é superado, sem necessidade de intervenção manual.
O mínimo viável para um ISP LATAM
Se está começando do zero, o stack de defesa por prioridade:
Nível 1 — RTBH com upstream (1-2 semanas de implementação)
- Documentar as communities de RTBH de cada upstream
- Criar o processo operacional para ativar blackhole manualmente
- Integrar com o NOC: quem autoriza, como se ativa, como se desativa
Nível 2 — RTBH automático (1 mês)
- Adicionar monitoramento de volume por prefixo (NetFlow)
- Script de ativação automática de RTBH quando um prefixo supera o limiar
- Alertas e logging do evento
Nível 3 — Flowspec interno (3-6 meses)
- Validar suporte na plataforma de roteadores
- Desenvolver playbooks de mitigação por tipo de ataque
- Integrar com sistema de ticketing/NOC
Nível 4 — Scrubbing dedicado (se a escala justificar)
- Avaliar solução própria vs serviço cloud
- Coordenar ROAs com ASN de scrubbing se aplicável
- Implementar GRE/VPN para reinserção do tráfego limpo
RPKI e scrubbing: a lista de verificação
Se sua rede tem RPKI ativo e você está implementando ou já tem scrubbing, verifique:
- O scrubbing center usa o seu mesmo ASN ou um diferente?
- Seus ROAs cobrem os prefixos que são desviados para scrubbing?
- Se o scrubbing center tem um ASN próprio, você criou um ROA com max-length apropriado que o autorize?
- Seus pares com validação RPKI estrita vão ver o anúncio como Valid ou Invalid durante a mitigação?
- Você tem um procedimento de rollback se a mitigação introduzir um estado RPKI inválido?
A interação entre scrubbing e RPKI é uma das áreas onde mais erros de configuração ocorrem silenciosamente — o scrubbing funciona mas introduz uma validação inválida que pode afetar a acessibilidade do prefixo a partir de redes com política de rejeição de rotas RPKI Invalid.
Sua rede tem RPKI ativo mas você nunca coordenou a validação com seu provedor de scrubbing? Escreva para [email protected] — realizamos auditorias de configuração BGP/RPKI e ajudamos a fechar essa lacuna antes que se torne um problema durante um incidente real.