Configuração de RTBH: guia prático para provedores

O que é RTBH e como funciona a configuração de RTBH?

RTBH quer dizer remotely triggered black hole: um roteador gatilho anuncia o IP atacado como /32 com uma marca, e quem recebe esse anúncio passa a mandar o tráfego para lugar nenhum. O IP fica fora do ar, mas o resto da rede volta a funcionar.

Num ataque de DDoS volumétrico, o problema raramente é o assinante atacado, e sim o link de trânsito cheio que derruba todos os outros. O RTBH troca um provedor inteiro parado por um IP parado, por isso é uma medida de contenção, não de limpeza.

A página de blackhole BGP para provedores trata dos acordos com cada operadora e do processo de disparo. Este guia mostra a configuração de referência, os filtros e a validação.

RTBH por destino e por origem

O uso mais comum é por destino: descartar o que vai para o IP atacado. A RFC 5635 descreve também a variação por origem, que combina o blackhole com uRPF para descartar o que vem de endereços de ataque conhecidos.

Num provedor regional, o RTBH por destino resolve a maior parte dos casos e é o que as operadoras costumam aceitar. O por origem exige uRPF nas interfaces certas e mais cuidado para não descartar tráfego legítimo.

O que muda no RTBH em ponto de troca

No IX, o anúncio com a community de blackhole vai para o route server, que repassa aos participantes que aceitam descartar. O efeito vale só para o tráfego que chega por ali.

Por isso o RTBH no IX complementa o da operadora, mas não substitui. Se a maior parte do ataque entra pelo trânsito, só o anúncio para a operadora alivia o link que está cheio.

Quando vale usar RTBH em vez de Flowspec ou firewall?

Vale usar RTBH quando o volume do ataque passa da capacidade do link e não há tempo para filtrar com precisão. Se o link aguenta e o ataque tem assinatura clara, filtros mais finos preservam o tráfego legítimo.

Um firewall na borda não salva o link, porque o tráfego já atravessou o trânsito quando chega a ele. O guia de configuração de Flowspec mostra a alternativa que filtra por assinatura, e o de ataque DDoS no provedor mostra como decidir durante o incidente.

Configuração de RTBH passo a passo

A configuração de RTBH exige um endereço de descarte em todos os roteadores de borda, um route-map que marca o anúncio e uma forma rápida de disparar. O exemplo usa rota estática com tag, que é simples de operar.

1. Descarte: crie em todos os roteadores de borda a rota do endereço de descarte para Null0.
2. Route-map: marque as rotas com tag 666, troque o next-hop para o endereço de descarte e acrescente a community com no-export.
3. Redistribuição: redistribua as rotas estáticas no BGP passando pelo route-map do gatilho.
4. Disparo: para pôr um IP no blackhole, crie a rota estática /32 dele com a tag 666.
5. Remoção: quando o ataque passar, apague essa rota estática e confira se o anúncio saiu.

O exemplo é em Cisco IOS-XE, com ASN de documentação 64500. Uma rota estática marcada com tag dispara o anúncio com a community BLACKHOLE (65535:666) para a operadora.

! endereço de descarte em todos os roteadores de borda
ip route 192.0.2.1 255.255.255.255 Null0
!
route-map RTBH-GATILHO permit 10
 match tag 666
 set ip next-hop 192.0.2.1
 set community 65535:666 no-export additive
 set origin igp
!
router bgp 64500
 redistribute static route-map RTBH-GATILHO
!
! para disparar: IP atacado 203.0.113.45
ip route 203.0.113.45 255.255.255.255 Null0 tag 666

Como adaptar para outros fabricantes

A sintaxe muda de um fabricante para outro, mas os três elementos são os mesmos. Quem entende o exemplo em IOS-XE consegue montar o equivalente na sua borda.

• Rota de descarte: um endereço que aponta para a interface nula ou para descarte, presente em todas as bordas.
• Política de saída: a regra que reconhece a marca do gatilho, troca o next-hop e acrescenta a community com no-export.
• Forma de disparo: rota estática com tag, community interna ou um roteador dedicado que anuncia os /32.

Antes de copiar, confira na documentação do fabricante como ele trata no-export e next-hop em rotas redistribuídas. [CONFIRMAR comportamento por fabricante]

Como configurar blackhole no MikroTik com RouterOS 7

No MikroTik com RouterOS 7, o blackhole segue a mesma lógica do exemplo em IOS-XE: uma rota de descarte para o /32 atacado e um filtro de saída que acrescenta a community. A diferença é que o anúncio sai de uma lista de endereços, então o disparo tem dois comandos.

# ASN 64500, bloco 203.0.113.0/24, operadora 198.51.100.1 (AS 64511)
/ip route add dst-address=203.0.113.0/24 blackhole comment="agregado"
/ip firewall address-list add list=BLOCOS address=203.0.113.0/24

/routing filter rule
add chain=SAIDA-TRANSITO rule="if (dst in 203.0.113.0/24 && dst-len == 32) { append bgp-communities 65535:666,no-export; accept }"
add chain=SAIDA-TRANSITO rule="if (dst == 203.0.113.0/24) { accept }"
add chain=SAIDA-TRANSITO rule="reject"

/routing bgp connection add name=TRANSITO-A as=64500 local.role=ebgp \
    remote.address=198.51.100.1 remote.as=64511 \
    output.network=BLOCOS output.filter-chain=SAIDA-TRANSITO

# para disparar: IP atacado 203.0.113.45
/ip route add dst-address=203.0.113.45/32 blackhole comment="RTBH"
/ip firewall address-list add list=BLOCOS address=203.0.113.45/32 comment="RTBH"

Para remover, apague a rota e a entrada da lista marcadas com o comentário RTBH. O filtro só põe a community em /32 de dentro do seu bloco, o que faz o papel da prefix-list de saída; no RouterOS 6 a sintaxe de BGP e de filtros é outra, e este exemplo não serve.

Exemplo: disparo durante um ataque

Um caso típico mostra o tempo que a configuração pronta economiza. Às 21h, o link de trânsito enche e o NOC vê que quase todo o tráfego vai para um único IP de assinante.

1. Detecção: a coleta de fluxos aponta o IP 203.0.113.45 como destino de quase todo o tráfego de entrada.
2. Decisão: o IP é de um assinante residencial, que pode ficar fora por algum tempo sem afetar outros.
3. Disparo: o técnico cria a rota estática /32 com tag 666, e o anúncio sai para a operadora com a community.
4. Conferência: o looking glass da operadora mostra a rota marcada, e o link de trânsito volta ao normal.
5. Remoção: quando o ataque para, a rota estática é apagada e o assinante volta a navegar.

Sem a configuração pronta, o mesmo caso vira uma ligação para a operadora no meio da noite, com o provedor inteiro fora do ar enquanto alguém procura a community certa.

Filtros que a operadora exige na sessão BGP

Como o anúncio de /32 foge da regra normal, a sessão BGP precisa de filtros próprios dos dois lados. Sem eles, um erro de digitação pode tirar do ar endereços que não são seus.

• Prefix-list de saída: só /32 que estejam dentro dos seus blocos podem sair com a community.
• No-export: impede que o /32 se espalhe além da operadora vizinha.
• Limite de prefixos: evita que um erro de script anuncie milhares de /32.

Para montar as listas, veja a configuração de prefix-lists. Para detectar o ataque antes de disparar, veja a implantação de sFlow e a implantação de IPFIX.

Proteja o roteador gatilho

Quem consegue criar uma rota estática no gatilho consegue tirar qualquer IP do ar. Por isso o acesso a esse roteador entra no hardening da borda, com contas individuais e registro de comandos.

• Acesso: só quem dispara o RTBH tem permissão de configuração no roteador gatilho.
• Registro: cada disparo e cada remoção ficam anotados com hora, IP e motivo.
• Revisão: uma conferência periódica lista os /32 ainda anunciados e remove os esquecidos.

Erros comuns na configuração de RTBH

Os erros de RTBH costumam aparecer no pior momento, durante o ataque. Quase todos se resolvem com teste antes e com um roteiro escrito.

O último erro é o mais caro: o RTBH num IP de infraestrutura transforma o ataque em queda total, feita pelo próprio provedor. Para esses endereços, a saída é limpeza de tráfego, e não blackhole.

Sinais de que o RTBH ficou mal configurado

Alguns sintomas aparecem logo no primeiro teste e apontam direto para a causa. Vale conferir cada um antes de dar a configuração por pronta.

• Tráfego continua chegando: a operadora não aceitou a community ou o /32 foi barrado pelo filtro dela.
• Rota aparece longe demais: o /32 saiu sem no-export e se espalhou para outras redes.
• IP não volta depois: a rota estática foi removida em um roteador, mas outro ainda anuncia o /32.

Como validar o RTBH antes de um ataque?

Faça um teste controlado com um IP de laboratório, combinado com a operadora em horário de baixo uso. O teste mostra se o anúncio sai certo, se é aceito e se a remoção funciona.

Roteiro de disparo para o NOC

O RTBH só ajuda se quem está de turno sabe disparar sem depender de uma pessoa específica. Um roteiro curto, escrito e testado resolve isso.

• Gatilho: em que situação disparar, como link acima de um limite combinado e um IP concentrando o tráfego.
• Proibidos: a lista de IPs de infraestrutura que nunca entram no blackhole.
• Registro: onde anotar o disparo, que serve também para o registro do incidente de segurança. [CONFIRMAR na norma]
• Saída: quando e como remover, e quem avisa o assinante afetado.

A detecção que alimenta o roteiro vem da coleta de fluxos, como NetFlow, IPFIX ou sFlow, apontando o IP de destino que concentra o tráfego.

O registro de cada disparo também ajuda na conformidade: o R-Ciber da Anatel cobra dos provedores o registro e o aviso de incidentes de segurança. [CONFIRMAR na norma]

Perguntas frequentes sobre configuração de RTBH

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech