RTBH: blackhole via BGP para conter ataque DDoS no provedor

Um ataque volumétrico contra um único IP de cliente pode encher o link de trânsito inteiro. Quando isso acontece, todo mundo atrás daquele link sofre, não só o alvo. O RTBH (Remotely Triggered Black Hole) é a saída mais simples que existe para esse cenário: você anuncia por BGP o /32 atacado com uma community de blackhole, e a operadora de trânsito passa a descartar o tráfego para aquele IP antes de ele chegar ao seu link.

O preço é claro: o IP atacado fica fora do ar enquanto o bloqueio durar. Em troca, o resto do bloco continua navegando. Este guia explica quando vale usar RTBH, como funcionam as communities de blackhole, a configuração completa no Huawei VRP e os cuidados para não vazar um /32 nem esquecer um bloqueio ativo por semanas. Os exemplos usam endereços e ASNs de documentação. Se sessão eBGP, AS-path e prefixo ainda são novidade, leia antes o guia o que é BGP e como ele funciona.

Resposta rápida: o que é RTBH e quando usar

1. RTBH é um descarte de tráfego disparado por BGP: você anuncia o IP atacado e quem recebe o anúncio joga fora todo o tráfego destinado a ele.
2. Use quando o ataque é maior que o seu link e o alvo é um IP só (ou poucos). Se o link não está cheio, filtros locais costumam bastar.
3. O anúncio é um /32 (ou /128 no IPv6) marcado com a community de blackhole do trânsito. A RFC 7999 definiu a community BLACKHOLE (65535:666); muitas operadoras usam a sua própria.
4. Marque também NO_EXPORT, para o /32 não sair do AS do trânsito.
5. Tire o bloqueio quando o ataque acabar. RTBH esquecido é cliente fora do ar sem motivo.

Como o RTBH funciona

O roteamento na internet segue o prefixo mais específico. Se você anuncia 203.0.113.0/24 e passa a anunciar também 203.0.113.45/32, qualquer roteador que aceite esse /32 vai usá-lo para aquele IP. No RTBH, o /32 vai junto com uma community que diz à operadora: o tráfego para este destino deve ir para o descarte. A operadora tem uma política pronta que casa essa community e troca o next-hop por uma interface nula.

Sacrificar um IP para salvar o link

Pense num link de 10 Gbit/s com 40 Gbit/s de ataque vindo na direção de um servidor de jogo de um cliente. Nenhum filtro na sua borda resolve, porque o gargalo é o próprio link: o tráfego ruim já ocupou a banda antes de chegar ao seu roteador. Quem pode descartar é quem está do outro lado. O blackhole tira aquele IP do ar e devolve a banda aos outros milhares de clientes.

Quem descarta: você ou o trânsito

A rota estática para NULL0 que dispara o RTBH já descarta o tráfego no seu roteador. Isso protege a rede interna, mas não alivia o link. O alívio vem quando o trânsito aceita o /32 e descarta na borda dele. Por isso a parte que importa é a community certa no anúncio, e não a rota estática em si.

Quando usar RTBH e quando não usar

O blackhole completa o serviço do atacante: o alvo cai do mesmo jeito, só que pelas suas mãos. Isso é aceitável quando a outra opção é derrubar o provedor inteiro. A tabela ajuda a decidir.

Antes de disparar, confirme o destino. Uma leitura de NetFlow ou sFlow com os maiores destinos do momento costuma mostrar o IP atacado em segundos. Bloquear o IP errado é derrubar um cliente e continuar com o link cheio.

Community BLACKHOLE e as communities das operadoras

A RFC 7999 reservou a community 65535:666 com o nome BLACKHOLE, para padronizar o pedido de descarte. Na prática, cada operadora de trânsito publica a community que aceita e as regras do serviço: tamanho máximo do prefixo (quase sempre /32 no IPv4 e /128 no IPv6), se exige que o bloco maior já esteja anunciado e se precisa de cadastro prévio do prefixo no IRR. A mesma RFC recomenda marcar o anúncio com NO_EXPORT ou NO_ADVERTISE.

O primeiro passo não é o roteador: é pedir ao comercial ou ao NOC de cada trânsito a documentação de blackhole. Guarde num lugar que o plantão encontre às três da manhã. Nos exemplos abaixo, o trânsito é o AS 64510 e a community de blackhole dele é 64510:666.

Configuração do RTBH no Huawei VRP passo a passo

O cenário tem uma borda Huawei com AS 64500, o bloco 203.0.113.0/24 e um trânsito no 198.51.100.1. A ideia é que o plantão só precise criar uma rota estática com tag para disparar o bloqueio. Todo o resto fica pronto antes do ataque. Os comandos rodam no system-view, e o commit é usado nas versões com confirmação em duas etapas. O /24 já está no BGP pelo network de sempre; aqui entra só o que o RTBH acrescenta. Para os básicos do VRP, veja a lista de comandos para roteadores e switches Huawei.

1. Filtros de prefixo e de community

ip ip-prefix MEUS-BLOCOS index 10 permit 203.0.113.0 24
ip ip-prefix RTBH-PERMITIDOS index 10 permit 203.0.113.0 24 greater-equal 32
ip community-filter basic RTBH-INTERNO index 10 permit 64500:666
commit

• MEUS-BLOCOS casa o /24 exato que você anuncia normalmente.
• RTBH-PERMITIDOS casa qualquer /32 dentro do seu /24. É a trava que impede o blackhole de anunciar um IP que não é seu, mesmo que alguém digite errado.
• RTBH-INTERNO casa a community interna 64500:666, que marca a rota como blackhole dentro do seu AS.

2. Importar a rota estática com tag

route-policy RTBH-IMPORT permit node 10
 if-match tag 666
 if-match ip-prefix RTBH-PERMITIDOS
 apply community 64500:666 additive
 quit
route-policy RTBH-IMPORT deny node 100
 quit
bgp 64500
 ipv4-family unicast
  import-route static route-policy RTBH-IMPORT
  quit
 quit
commit

• O nó 10 só deixa passar rota estática com tag 666 e dentro de RTBH-PERMITIDOS.
• apply community 64500:666 additive marca a rota como blackhole interno.
• O deny node 100 garante que nenhuma outra rota estática da borda entre no BGP por acidente.
• import-route static route-policy RTBH-IMPORT liga tudo isso ao BGP.

3. Exportar para o trânsito com a community dele

route-policy EXPORT-TRANSITO-A permit node 5
 if-match community-filter RTBH-INTERNO
 if-match ip-prefix RTBH-PERMITIDOS
 apply community 64510:666 no-export
 quit
route-policy EXPORT-TRANSITO-A permit node 10
 if-match ip-prefix MEUS-BLOCOS
 quit
route-policy EXPORT-TRANSITO-A deny node 100
 quit
commit

• O nó 5 vem primeiro: rota com a community interna e dentro do bloco permitido sai com 64510:666 e no-export.
• Sem additive, o apply community substitui as communities da rota. A community interna não vaza para o trânsito.
• O nó 10 é o anúncio normal do /24. O deny node 100 bloqueia qualquer outra coisa, inclusive um /32 sem a marca de blackhole.
• Se o peer já tem uma política de export, não crie outra: acrescente só o nó 5 à política que já existe, antes dos nós de permit. Trocar a política do peer por esta tira do ar qualquer anúncio que não esteja no MEUS-BLOCOS, como os blocos de clientes BGP.

4. Sessão com o trânsito enviando communities

bgp 64500
 peer 198.51.100.1 as-number 64510
 peer 198.51.100.1 description TRANSITO-A
 ipv4-family unicast
  peer 198.51.100.1 enable
  peer 198.51.100.1 route-policy EXPORT-TRANSITO-A export
  peer 198.51.100.1 advertise-community
  quit
 quit
commit

No VRP, o BGP não envia communities para o vizinho por padrão. Sem peer 198.51.100.1 advertise-community, o /32 chega ao trânsito sem a community, cai no filtro de prefixo dele e o descarte não acontece. Esse comando aparece com mais detalhe no post de BGP communities no Huawei.

5. Disparar o blackhole

ip route-static 203.0.113.45 255.255.255.255 NULL0 tag 666
commit

Esta é a única linha que o plantão digita durante o ataque. A rota manda o /32 para NULL0, a tag 666 faz o RTBH-IMPORT trazê-la para o BGP, e o EXPORT-TRANSITO-A anuncia o /32 com 64510:666 e no-export.

6. Conferir se o trânsito recebeu

display ip routing-table 203.0.113.45
display bgp routing-table 203.0.113.45
display bgp routing-table peer 198.51.100.1 advertised-routes

• O primeiro comando mostra a rota para NULL0 na tabela de roteamento.
• O segundo mostra a rota no BGP; o detalhe traz as communities.
• O terceiro lista o que foi anunciado ao trânsito. O /32 tem de estar lá.

Depois, confira de fora: o looking glass do trânsito ou o gráfico do link. Em poucos segundos o tráfego de entrada deve cair. Se não cair, o problema costuma ser community errada ou falta do advertise-community.

7. Tirar o bloqueio

undo ip route-static 203.0.113.45 255.255.255.255 NULL0
commit

Removida a rota estática, o BGP retira o /32 e o tráfego para o IP volta pelo /24. Faça um teste antes de liberar de vez: se o ataque continua, o link enche de novo em segundos.

Mais de uma borda: gatilho com next-hop de descarte

Com várias bordas, criar a rota estática em cada uma é lento e fácil de esquecer. O desenho das RFCs 3882 e 5635 resolve isso com um roteador de gatilho. Cada borda tem uma rota estática fixa para um IP de descarte (por exemplo, 192.0.2.1) apontando para NULL0. O gatilho anuncia por iBGP o /32 atacado com next-hop 192.0.2.1 e com a community interna de blackhole. Todas as bordas descartam localmente e reanunciam o /32 para os seus trânsitos com a community de cada um.

O resultado é um comando só, num lugar só, refletido na rede inteira. A política de exportação de cada borda continua a mesma do passo 3, só que casando a community vinda do iBGP.

RTBH pedido pelo cliente BGP

Se você vende trânsito para outros provedores, eles também vão querer disparar blackhole. O cliente anuncia o /32 com 65535:666 ou com a sua community de blackhole, você valida que o IP é do cliente e repassa para os seus trânsitos com a community de cada um. A validação do prefixo é obrigatória: sem ela, um cliente pode derrubar o IP de qualquer pessoa. O post de BGP communities no Huawei mostra esse desenho com os filtros de entrada.

FlowSpec como próximo passo

O blackhole por destino é um machado: corta todo o tráfego para o IP. O BGP FlowSpec (RFC 8955) é um bisturi: anuncia regras com destino, protocolo e porta, como descartar só UDP de origem 123 (NTP) para aquele IP. O cliente continua no ar e o ataque some. O problema é o suporte: nem todo trânsito aceita FlowSpec de cliente, e o roteador precisa aguentar as regras em hardware. Na maior parte dos provedores, RTBH vem primeiro e FlowSpec depois, junto com um serviço de scrubbing para os ataques maiores.

Riscos e erros comuns no RTBH

• Vazar o /32. Sem no-export e sem o filtro RTBH-PERMITIDOS, um /32 pode sair para onde não devia. Teste a política com um IP de laboratório antes do primeiro ataque.
• Esquecer o bloqueio. O cliente liga dias depois dizendo que o IP não funciona. Abra chamado a cada bloqueio, com dono e horário para revisar, e liste as rotas com tag 666 no começo de cada plantão.
• Community errada. Cada trânsito tem a sua. Um /32 com a community de outro trânsito é só um /32 filtrado.
• Faltar advertise-community. Tudo parece certo na sua borda, mas a community nunca chega ao vizinho.
• Bloquear o IP errado. Confirme o destino no NetFlow antes. O alvo nem sempre é o IP que aparece no primeiro alerta.
• Esquecer o IPv6. O mesmo raciocínio vale para /128, com a community aceita pelo trânsito na sessão IPv6. Se ainda está montando o IPv6, comece pelo guia de o que é IPv6.

Perguntas frequentes

O que é RTBH?

É o Remotely Triggered Black Hole, um descarte de tráfego disparado por BGP. Você anuncia o IP atacado com uma community de blackhole e a operadora de trânsito descarta tudo que vai para ele, antes de chegar ao seu link.

Qual a community de blackhole padrão?

A RFC 7999 definiu 65535:666 como BLACKHOLE. Muitas operadoras aceitam esse valor, mas várias usam uma community própria, então confira a documentação de cada trânsito.

O RTBH derruba o cliente atacado?

Sim. Todo o tráfego para aquele IP é descartado, inclusive o legítimo. O ganho é manter o link e o resto dos clientes no ar até o ataque passar.

Posso anunciar um /32 para o trânsito sem community?

Não adianta. A maioria das operadoras filtra prefixos menores que /24, e o /32 só é aceito com a community de blackhole. Se passar sem ela, ainda atrai mais tráfego para o seu link.

Qual a diferença entre RTBH e FlowSpec?

O RTBH descarta todo o tráfego para um IP. O FlowSpec descarta só o tráfego que casa com uma regra, como protocolo e porta, e mantém o cliente no ar. O FlowSpec exige suporte do trânsito e do hardware.

Conclusão

O RTBH não resolve DDoS, mas tira o provedor do buraco quando o ataque é maior que o link. Deixe tudo pronto antes de precisar: communities de cada trânsito anotadas, filtros que só aceitam /32 do seu bloco, no-export e advertise-community. No dia do ataque, o plantão só cria uma rota estática com tag e acompanha o gráfico do link.

Depois, cuide da saída: chamado aberto para cada blackhole, revisão no começo do plantão e remoção assim que o ataque passar. Com isso funcionando, o próximo passo é FlowSpec ou scrubbing, para não precisar derrubar o cliente.

Leitura recomendada: para a parte de prevenção (peering com CDNs, IPv6 e serviços de mitigação), veja Recomendações sobre Mitigação DDoS, do Brasil Peering Forum (CC BY-NC 4.0).