Mitigando DDoS volumétrico no vetor DNS com Wanguard Anti DDOS

Por que seu trânsito IP precisa oferecer Flowspec — e o que fazer quando ele oferece

Abrint 2026

Arquitetura em duas camadas (ACL/MQC local + BGP Flowspec estático no upstream) Validado em Huawei NetEngine 8000 F1A · VRP V800R023

Quem sou eu

Raphael Rodrigues
CTO na Flowspec Solutions

23 anos em operação de
redes para ISP
Foco em arquitetura de
borda, BGP e mitigação
DDoS
Pai, marido, Nerd,
apaixonado por suf, jiu-jitsu
e tudo que envolve o mundo
digital.

Contato

LinkedIn: linkedin.com/in/raphaelisp
E-mail: raphael@flowspec.net.br
QR Code no slide final para baixar o artigo técnico completo

O que você vai levar daqui

Ao final desta palestra, você vai saber:

Por que nenhuma defesa local do seu ISP, por mais sofisticada, mitiga volumetria
Como BGP Flowspec usa a rede do seu upstream pra proteger seu uplink
Quais são as 6 assinaturas de ataque DNS que você deve bloquear hoje
Como implementar a solução completa em Huawei NE8000
O que exigir do seu trânsito IP na próxima renovação contratual

Material técnico completo distribuído por QR code ao final.

A história: novembro de 2025, o maior DDoS já registrado

31,4 Tbps. Trinta e um terabits por segundo.

Isso é o pico do maior ataque DDoS volumétrico já registrado na história da Internet. Mitigado pela Cloudflare em novembro de 2025.

Para contextualizar o tamanho

Cerca de três mil vezes a banda de um ISP regional brasileiro médio
Suficiente para saturar o link de qualquer provedor brasileiro simultaneamente
Originado da botnet Aisuru, estimada em 1 a 4 milhões de dispositivos infectados (IoT, NVRs, Android TVs, roteadores SOHO)

Duração do ataque

35 segundos.

Tempo curto demais para qualquer mitigação manual. E isso é o padrão em 2025.

O DDoS cresceu absurdamente nos últimos 24 meses

Dados da Cloudflare para 2025:

Métrica	2024	2025	Crescimento
Total de ataques mitigados	21,3 milhões	~46 milhões	+116%
Ataques hiper-volumétricos (>1 Tbps)	~50/trimestre	6.500+ só no Q2	+13.000%
Ataques DDoS por hora (média)	2.400	5.376	+124%

E o mais importante pra nós

O Brasil é o 2º país mais atacado do mundo em 2025, atrás só da China.

Telecoms e ISPs são a indústria mais atacada.

Se você opera ISP no Brasil, você vai sofrer DDoS. Não é questão de “se”, é questão de “quando”.

Agora a sua realidade

Você é provedor regional brasileiro. Seu trânsito IP é de 1 a 10 Gbps por upstream.

Um ataque DDoS moderno, mesmo pequeno para os padrões de 2025, facilmente atinge 30 a 100 Gbps.

O que acontece quando 30 Gbps chegam no seu link de 1 Gbps?

O buffer do upstream enche e começa a descartar pacotes aleatoriamente
Tráfego legítimo dos seus clientes é descartado junto com o ataque
Seu NOC vê latência subindo, perda de pacotes em tudo
Clientes residenciais ligam reclamando “a internet caiu”
Clientes corporativos com SLA começam a exigir crédito na fatura

Não importa o firewall, ACL ou engine que você tem dentro da sua rede. O jogo já acabou no uplink.

A assimetria estrutural

	Você (ISP regional)	O atacante
Banda contratada	1 a 10 Gbps	Zero — usa recursos de terceiros
Custo por Gbps	R$ caro, recorrente	Praticamente zero
Escalabilidade	Limitada pelo contrato	Limitada só pela botnet
Tempo pra escalar	Meses (aumentar trânsito)	Minutos (adicionar bots)

Esta assimetria é permanente. Você nunca vai contratar trânsito suficiente para “absorver” um ataque DDoS moderno. Ninguém vai.

A única saída é usar uma rede maior do que a sua.

E a única rede maior do que a sua, à qual você tem acesso contratual, é a rede do seu upstream.

Por que defesa local não resolve volumetria

Defesa	Onde atua	Mitiga volumetria?
Firewall L4	Host	❌
ACL/MQC no roteador de borda	Borda do ISP	❌
Engine DDoS local (Wanguard, FastNetMon)	Dentro do ISP	❌ (detecta, mas não para sozinho)
RTBH	Upstream	⚠️ Sim, mas derruba o alvo junto
Scrubbing center	Externo (desvio BGP)	✅ Caro, latência adicional
BGP Flowspec	Upstream	✅ Granular, rápido, barato

Defesa local protege recursos internos (CPU, sessões, buffers). Defesa no upstream protege o uplink.

Você precisa das duas. Mas sem a defesa no upstream, volumetria te derruba sempre.

BGP Flowspec — a ideia central

Use a rede da sua operadora pra impedir que a volumetria chegue até você.

O seu upstream tem:

PE routers de 100, 400, 1000 Gbps por placa
Capacidade agregada de centenas de Tbps na rede deles
Filtros ASIC que operam em velocidade de linha, custo zero de CPU

Você tem:

Uma sessão BGP com eles, que já existe
Os prefixos da sua rede (que você anuncia por ela)
Controle sobre o que acontece dentro da sua rede — mas não fora

BGP Flowspec te dá um jeito padronizado de estender esse controle para dentro da rede do upstream, sem precisar de acesso administrativo nenhum. Você anuncia uma regra via BGP, ele instala em hardware. Em segundos.

A volumetria nunca chega no seu link. Morre no PE do upstream.

BGP Flowspec — como funciona tecnicamente

RFC 5575 (2009) e RFC 8955 (2020)

Funciona assim:

Você cria a regra no seu roteador: “descarte UDP com porta origem 53 indo pro meu /24”
Ela vira uma rota BGP especial — não é rota de prefixo, é rota de “filtro”
Sua sessão BGP anuncia essa rota ao upstream (NLRI ipv4-flow)
O upstream instala a regra em hardware nos PE routers dele
O ataque morre no upstream, nunca chega no seu link

Mesma sessão TCP do BGP que você já usa. Mesma capability negociada no OPEN. Filtro instalado em ASIC, na velocidade do link do upstream.

Instalação em segundos. Remoção em segundos. Granularidade cirúrgica.

Flowspec vs RTBH: a diferença que muda tudo

RTBH (Remote Triggered Black Hole) — ferramenta antiga, granularidade grossa:

IP alvo em ataque?  →  Descartar TODO tráfego pra esse IP

Resultado: ataque parou. Serviço do cliente também parou. Para o atacante, isso é vitória. Ele derrubou o serviço sem precisar saturar seu link.

BGP Flowspec — granularidade cirúrgica:

IP alvo em ataque por DNS amp?  →  Descartar só UDP src:53 + dst <1024 pra esse IP

Resultado: ataque parou. Serviço do cliente (webserver na 443, SSH na 22, qualquer outra coisa) continua funcionando normalmente.

BGP Flowspec é “RTBH cirúrgico”.

Flowspec estático vs dinâmico

Duas abordagens complementares — as duas convivem bem no mesmo ambiente:

Estático (foco desta palestra)

Regras criadas manualmente pelo administrador
Sempre ativas, 24/7
Apropriado para padrões que são sempre inválidos (ex: UDP src:53 + dst:53)
Zero overhead operacional depois de configurado

Dinâmico

Regras geradas automaticamente por traffic analyzer (Wanguard, FastNetMon)
Analisa sFlow/NetFlow/IPFIX em tempo real
Gera regras quando detecta padrão de ataque
Remove quando ataque cessa
Apropriado para padrões variáveis

Estático cobre o óbvio e permanente. Dinâmico cobre o resto.

Topologia do cenário

Três zonas:

Internet (esquerda): botnet + refletores DNS geram o ataque
Upstream (centro): AS64501 — zona de mitigação onde o Flowspec atua
ISP (direita): AS64500 — NE8000 recebe só tráfego limpo

Dados sanitizados: ASNs e prefixos substituídos por blocos reservados nas RFCs 5398 e 5737 para proteger a confidencialidade do ambiente real.

Sem Flowspec vs com Flowspec

Sem Flowspec

30 Gbps de ataque
      ↓
PE do upstream encaminha tudo
      ↓
Link contratado (1 Gbps) satura
      ↓
NE8000 recebe link 100% lixo
      ↓
Todos os clientes prejudicados

Com BGP Flowspec

30 Gbps de ataque
      ↓
PE do upstream aplica filtro (ASIC, custo zero)
      ↓
Só ~50 Mbps de DNS legítimo passam
      ↓
Link contratado calmo
      ↓
NE8000 opera normalmente

A volumetria morre na borda do upstream. Você nem percebe o ataque.

Por que DNS é o vetor preferido dos atacantes

Três características do DNS sobre UDP/53:

1. Resposta maior que pergunta

Query “ANY” de 60 bytes → resposta de até 4.000 bytes (EDNS0 + DNSSEC) Amplificação de 28× a 54×

2. UDP sem handshake

Servidor responde sem validar origem. Spoofing de IP é trivial.

3. Abundância de refletores

Mais de 1,5 milhão de resolvedores abertos (ShadowServer)
Todos os servidores autoritativos do mundo
Qualquer um responde pra qualquer IP

Matemática do atacante

10.000 queries/s × 3.000 B por resposta = 240 Mbps por refletor 200 refletores → 48 Gbps chegando na vítima Tudo isso com uma botnet modesta.

As 6 assinaturas de ataque DNS

Todo pacote de ataque DNS tem marca. Estas são as 6 que você precisa bloquear:

#	Assinatura	Ação	Por quê
1	UDP src:53 + dst<1024	Drop	Resposta pra porta privilegiada — sem uso legítimo
2	TCP src:53 + dst<1024	Drop	Idem em TCP
3	UDP src:53 + len<45B	Drop	Menor que pacote DNS mínimo possível
4	UDP src:53 + len>512B	Rate-limit	Respostas amplificadas (preserva EDNS0 legítimo)
5	UDP src:53 + dst:53	Drop	Reflexão clássica — nunca é legítimo
6	UDP src:53 + fragmentado	Rate-limit	Vetor comum de amp e evasão

Drop = comportamento que nunca é legítimo Rate-limit = comportamento que pode ser legítimo mas é abusado

Por que não bloquear tudo com src:53?

A tentação é simples: “vou dropar todo tráfego UDP porta origem 53 exceto da minha whitelist de DNS público”.

Você quebra metade dos seus clientes.

Muitos clientes rodam resolvedores recursivos próprios. Esses resolvedores consultam servidores autoritativos do mundo inteiro — todos respondendo com src-port 53 legítimo.

Você não tem como listar todos os autoritativos do mundo.

A abordagem correta

Whitelist de DNS públicos conhecidos → rate-limit 10 Mbps por IP
Qualquer outro src:53 → drop
Resto do tráfego → passa intocado

Whitelist granular + drop agressivo no que sobra = você pega o ataque sem quebrar o cliente.

Arquitetura em duas camadas

Camada 1: Local (NE8000)

Onde: dentro do seu roteador de borda Como: ACL avançada + MQC (traffic-policy) Protege: exaustão de recursos internos (CPU, sessões, buffers) Vantagem: resposta imediata, controle total, sem depender de terceiros

Camada 2: Upstream (BGP Flowspec)

Onde: nos PE routers do seu trânsito Como: flow-routes estáticas anunciadas via BGP Protege: saturação do uplink contratado (volumetria) Vantagem: mata o tráfego antes de tocar seu link

Você precisa das duas. Cada uma resolve um problema que a outra não resolve.

Camada local no NE8000 — estrutura MQC

Modular QoS CLI — três objetos encadeados:

Classifier (identifica)

traffic classifier C-DNS-WHITELIST operator or
 if-match acl 3100

Behavior (age)

traffic behavior B-DNS-CAR
 car cir 10000 pir 10000 red discard    # 10 Mbps

Policy (amarra e aplica)

traffic policy TP-DNS-MITIGATION
 classifier C-DNS-WHITELIST behavior B-DNS-CAR
 classifier C-DNS-ANY        behavior B-DNS-DROP

interface GigabitEthernet0/1/2
 traffic-policy TP-DNS-MITIGATION inbound

Lógica: first-match-wins. Whitelist casa primeiro, pega CAR. Resto cai no drop. Tráfego não-DNS passa intocado.

Camada upstream — habilitar Flowspec no BGP

A family ipv4-flow roda na mesma sessão TCP do BGP unicast que você já tem. Não é uma nova sessão BGP. É uma nova NLRI na sessão existente.

bgp 64500
 ipv4-family flow
  peer 192.0.2.10 enable
  peer 192.0.2.10 advertise-community
  peer 192.0.2.10 route-limit 200
  commit

Pré-requisitos contratuais com o upstream

Sessão eBGP com family ipv4-flow habilitada do lado deles
route-limit de pelo menos 200 rotas
Política clara sobre validação de destination-prefix

Sem isso do lado do upstream, os comandos acima não fazem nada.

Flow-routes de assinaturas — exemplo

Cada flow-route é uma regra com matching (if-match) e ação (apply). Múltiplos if-match na mesma rota = lógica AND.

Exemplo: assinatura 4 (respostas amplificadas)

flow-route FS-DNS-AMP-HOMOLOG
 if-match destination 192.0.2.0 24
 if-match protocol udp
 if-match source-port equal 53
 if-match packet-length greater-than 512
 apply traffic-rate 2500        # 20 Mbps
 commit

6 flow-routes × 3 prefixos do ISP = 18 rotas para cobrir todas as assinaturas em toda a rede.

Flow-routes de whitelist — o problema da granularidade

Diferente do MQC local, Flowspec não aceita pools de IP. Cada IP da whitelist vira uma rota separada.

Conta rápida

13 root servers
8 DNS públicos principais (Google ×2, Cloudflare ×2, Quad9 ×2, OpenDNS ×2)
= 21 rotas de whitelist por prefixo

Mais 2 rotas catch-all (UDP + TCP) + 6 de assinaturas = 29 rotas por prefixo

Para 3 prefixos do ISP = 87 flow-routes no deploy completo

Por isso o `route-limit 200` no contrato

Provedores que oferecem route-limit baixo (20, 50 rotas) inviabilizam a solução completa. Negocie antes de fechar.

Whitelist — exemplo de flow-route

flow-route FS-DNS-WL-GOOGLE-1-HOMOLOG
 if-match destination 192.0.2.0 24
 if-match protocol udp
 if-match source 8.8.8.8 32
 if-match source-port equal 53
 apply traffic-rate 1250        # 10 Mbps
 commit

Precedência automática (RFC 5575 §5.1)

Flowspec ordena regras por especificidade do matching:

source 8.8.8.8/32 + source-port 53 vence source 0.0.0.0/0 + source-port 53
Mais campos de match = mais específica = aplicada primeiro

Você não precisa ordenar manualmente. A whitelist sempre vence o catch-all.

Catch-all — dropar tudo que sobrou

Depois das 21 rotas de whitelist em /32, qualquer outro pacote com src:53 cai aqui:

flow-route FS-DNS-DENY-UDP-HOMOLOG
 if-match destination 192.0.2.0 24
 if-match protocol udp
 if-match source-port equal 53
 apply deny
 commit

flow-route FS-DNS-DENY-TCP-HOMOLOG
 if-match destination 192.0.2.0 24
 if-match protocol tcp
 if-match source-port equal 53
 apply deny
 commit

Sem pools, é uma rota genérica para UDP e outra para TCP. A especificidade garante que a whitelist /32 vence antes de chegar aqui.

Matriz de comportamento resultante

Com as 29 flow-routes ativas no prefixo:

Tipo de pacote	Ação
UDP src:53 de IP da whitelist → sua rede	Rate-limit 10 Mbps
UDP src:53 de IP fora da whitelist, tamanho normal	Drop
UDP src:53, dst<1024	Drop (assinatura 1)
UDP src:53, len>512	Rate-limit 20 Mbps (assinatura 4)
UDP src:53, len<45	Drop (assinatura 3)
UDP src:53, dst:53	Drop (assinatura 5)
UDP src:53 fragmentado	Rate-limit 10 Mbps (assinatura 6)
TCP src:53 → sua rede	Drop (catch-all TCP)
Qualquer outro tráfego	Passa intocado

Teto total de DNS entrando: 21 IPs × 10 Mbps = 210 Mbps por prefixo Volumetria acima disso é impossível — o upstream mata.

Homologação — nunca é big bang

Deploy em produção sempre por etapas:

Etapa	Ação	Tempo de observação
1	Deploy só das 6 assinaturas em 1 prefixo	24-72h
2	Adicionar whitelist + catch-all no mesmo prefixo	24-72h
3	Replicar tudo para o 2º prefixo	2-6h
4	Replicar tudo para o 3º prefixo	2-6h

O que monitorar em cada etapa

display bgp flow routing-table peer X advertised-routes — as rotas chegaram no upstream?
display flowspec statistics <reindex> — estão batendo tráfego?
Tickets do suporte — algum cliente reclamando de DNS?
Dashboard de bps/pps do uplink — comportamento mudou?

Qualquer sinal estranho → rollback imediato → investigar → repetir.

Comandos de verificação essenciais

Aprenda estes 5 comandos. Resolvem 90% dos problemas:

display bgp flow peer
→ Sessão Flowspec está Established? Quantas rotas trocadas?

display bgp flow routing-table
→ Lista todas as rotas conhecidas (suas e recebidas)

display bgp flow routing-table peer <ip> advertised-routes
→ Suas rotas chegaram no upstream?

display flowspec statistics
→ Quantos pacotes bateram em cada regra? Passaram ou foram dropados?

display flowspec rule <reindex> slot N
→ A regra está programada em hardware na placa N?

Matched sem Passed/Dropped = rota no RIB mas não em forwarding. Investigar.

Rollback — tenha o script pronto

Sempre antes de aplicar qualquer regra, tenha o script de remoção pronto em outra janela.

Rollback da camada Flowspec

system-view
undo flow-route FS-DNS-LOWPORT-UDP-HOMOLOG
undo flow-route FS-DNS-LOWPORT-TCP-HOMOLOG
undo flow-route FS-DNS-TINY-HOMOLOG
undo flow-route FS-DNS-AMP-HOMOLOG
undo flow-route FS-DNS-REFLECTION-HOMOLOG
undo flow-route FS-DNS-FRAG-HOMOLOG
# ...whitelist e catch-all também
commit

Rollback da camada local

interface GigabitEthernet0/1/2
 undo traffic-policy TP-DNS-MITIGATION inbound
commit

Script pronto = rollback em segundos. Confiança pra aplicar.

DNS é só o começo — outros vetores de amplificação

A mesma arquitetura (flow-routes por source-port + ação) serve para qualquer protocolo amplificável:

Protocolo	Porta	Amp factor	Nota
Memcached	UDP/11211	até 51.000×	GitHub 2018, 1,35 Tbps
NTP monlist	UDP/123	até 556×	Vários ataques 2013-2014
CLDAP	UDP/389	até 70×	Recorrente em 2020-2025
Chargen	UDP/19	até 358×	Antigo mas ainda usado
SSDP	UDP/1900	até 30×	IoT doméstico
DNS	UDP/53	até 54×	Mais comum no dia-a-dia

Depois do DNS funcionando, replique a lógica para os outros.

Controles complementares obrigatórios

Flowspec resolve tráfego de ataque entrando. Você também precisa resolver tráfego de ataque saindo da sua rede:

RRL (Response Rate Limiting) nos seus resolvedores/autoritativos → impede sua rede ser usada como amplificador contra terceiros
uRPF strict nas interfaces de clientes → impede spoofing de origem saindo
BCP38 (ingress filtering) em toda a borda → política de rede alinhada ao uRPF

Você não quer que seu ISP apareça na lista pública de amplificadores abusivos

Quando isso acontece, outros ISPs começam a bloquear sua rede. Sua reputação BGP vai pro chão.

Case real: ISP regional brasileiro

Perfil do ISP

Provedor regional, alguns milhares de clientes
3 prefixos anunciados
Trânsito IP com ~[X] Gbps contratados por upstream
2 upstreams eBGP + PTT

Situação antes

Ataques DNS amp semanais, escalando em frequência
Saturação de uplink por 15 a 40 min durante cada evento
Tickets de clientes residenciais + corporativos acumulando
Escalada para o NOC do upstream cada vez com resposta diferente (às vezes RTBH, às vezes “não tem como”)

Decisão técnica

Migrar para upstream que oferecesse BGP Flowspec no contrato
Implementar solução em duas camadas (MQC + Flowspec estático)

Resultado após implementação

Métricas observadas

Zero saturações de uplink por DNS amp nos meses seguintes
Volumetria detectada em display flowspec statistics sem impacto no uplink
Tempo médio de mitigação de novos vetores: minutos, não horas
Tickets de cliente por indisponibilidade caíram para patamares normais

Aprendizados operacionais

Homologação foi crítica — peguei dois falsos positivos em assinatura 4 que teriam quebrado clientes
Alinhamento com o NOC do upstream sobre comportamento pós-reboot do PE foi fundamental
Ter script de rollback pronto deu confiança pra aplicar em produção

Requisitos contratuais — o que exigir do trânsito IP

Antes de fechar contrato de trânsito novo, pergunte ao comercial e peça por escrito:

Habilitam BGP Flowspec (RFC 5575/8955) na sessão eBGP?
Quais matching fields são aceitos? Especialmente packet-length, fragment-type, tcp-flags?
Quais ações? discard, traffic-rate, redirect, mark DSCP?
Qual o route-limit no peer?
Há validação de destination-prefix? Como funciona?
SLA de instalação em hardware após anúncio?
As regras se aplicam em todos os PoPs por onde seu tráfego pode entrar?
Comportamento pós-reboot do PE — reinstalação automática?

Se o comercial não sabe responder, peça para escalar para engenharia antes de fechar.

Respostas-alerta do upstream

Frases comuns que devem disparar atenção:

❌ “Temos RTBH, cobre a mesma necessidade”

Não cobre. Granularidade IP inteiro derruba o serviço junto com o ataque.

❌ “Temos Anti-DDoS gerenciado por R$ X/mês”

Provavelmente scrubbing terceirizado. Útil como extra. Não substitui BGP Flowspec.

❌ “Flowspec é inseguro, não habilitamos”

Preocupação resolvida pela própria RFC há 15 anos via validação de destination-prefix. Provedor que diz isso não investiu no assunto.

❌ “Pode habilitar, mas precisa abrir ticket pra cada regra”

Isso não é Flowspec. É política de filtro manual. BGP Flowspec é anúncio via BGP com aplicação automática em segundos.

Mensagem final

BGP Flowspec deixou de ser nice to have.

É dependência estrutural para operar ISP com SLA decente em 2026.

Nenhuma defesa local, por mais sofisticada, substitui bloqueio no upstream para tráfego volumétrico — isso é restrição física do caminho dos pacotes, não opinião.

Ação concreta saindo daqui

Verifique hoje se seus upstreams oferecem BGP Flowspec real
Se não oferecem, coloque isso como critério da próxima renovação
Comece com as 6 assinaturas em 1 prefixo — ganho imediato, risco baixo
Expanda para whitelist + catch-all quando tiver o route-limit contratual certo

Operadoras sérias oferecem. Não aceite menos.

Obrigado