Quando um ataque DDoS volumétrico atinge seu alvo, o provedor de conectividade frequentemente apresenta uma “solução”: blackhole routing. Em março de 2013, o ataque contra a Spamhaus gerou picos reportados próximos de 300 Gbps, baseado em reflexão e amplificação DNS. Um blackhole routing aplicado ao IP atacado não encerra necessariamente o ataque: descarta, na rede do operador, tanto o tráfego malicioso quanto o legítimo destinado ao alvo. Embora proteja a infraestrutura adjacente contra saturação, sacrifica temporariamente a disponibilidade do serviço e pode produzir exatamente o efeito de negação de serviço pretendido pelo atacante.
Blackhole routing (ou null routing) é uma técnica de engenharia de rede que descarta todo o tráfego destinado a um endereço IP específico, redirecionando-o para uma interface nula. O tráfego de ataque é eliminado — mas junto com ele vai todo o tráfego legítimo. Scrubbing, por sua vez, é o processo de inspeção e filtragem seletiva do tráfego, descartando apenas o malicioso e encaminhando o legítimo ao destino.
Como funciona o blackhole routing — RTBH e RFC 7999
O blackhole routing opera via BGP (RFC 4271). O mecanismo mais usado é o RTBH (Remotely Triggered Black Hole), padronizado pela RFC 5635, que permite acionar o descarte em múltiplos roteadores remotos por meio de uma sessão BGP de sinalização.
Operacionalmente, o fluxo ocorre da seguinte forma:
- O operador detecta um ataque volumétrico destinado ao IP
192.0.2.10/32. - Um roteador de sinalização anuncia via iBGP a rota
192.0.2.10/32com o next-hop configurado como192.0.2.1(endereço reservado para trigger de blackhole). - Os roteadores de borda, ao receber esse anúncio, consultam sua tabela estática e redirecionam o prefixo para a interface
null0. - Todo tráfego destinado ao IP da vítima é descartado nas bordas da rede do operador.
A RFC 7999 padronizou a comunidade BGP bem conhecida BLACKHOLE (65535:666) para sinalizar rotas de blackhole de forma interoperável entre sistemas autônomos. Quando uma organização anuncia um prefixo com essa comunidade para seu provedor de upstream, o prefixo é descartado em toda a rede do provedor. Os atributos NO_ADVERTISE e NO_EXPORT são frequentemente combinados para limitar a propagação do anúncio:
NO_ADVERTISE(community0xFFFFFF02): impede que o roteador receptor propague o anúncio para qualquer peer.NO_EXPORT(community0xFFFFFF01): impede a propagação para peers eBGP fora da confederação, contendo o blackhole dentro do AS receptor.
O resultado em termos de disponibilidade é inequívoco: o blackhole ativa em segundos e protege a infraestrutura de upstream (links e roteadores do ISP) de serem sobrecarregados. Mas do ponto de vista do negócio, o efeito é idêntico ao do ataque: indisponibilidade total.
Quando o blackhole routing é usado
Apesar das limitações, o blackhole tem casos de uso válidos:
- Proteção de infraestrutura compartilhada: Quando um ataque ameaça impactar outros clientes do ISP além da vítima, o blackhole isola o problema e protege a capacidade coletiva do link.
- IP sacrificado: Quando o IP atacado é secundário e o serviço principal pode ser mantido via outros IPs ou prefixos.
- Resposta emergencial temporária: Como medida de primeiros socorros enquanto uma solução de scrubbing é ativada e propagada.
- Ataque em IP não crítico: Quando o IP atacado não é necessário para a continuidade operacional do serviço.
BGP FlowSpec — filtragem granular no plano de controle
O BGP FlowSpec, definido originalmente pela RFC 5575 e atualizado pela RFC 8955, representa uma evolução significativa sobre o RTBH: em vez de descartar todo o tráfego para um prefixo, permite criar regras de ACL granulares distribuídas via plano de controle BGP.
O FlowSpec opera por meio de tuplas de correspondência combinadas com ações via comunidades estendidas:
Campos de correspondência (match):
- Endereço IP de origem e destino (prefixo)
- Protocolo de transporte (TCP, UDP, ICMP)
- Portas de origem e destino (intervalos e listas)
- Flags TCP (SYN, ACK, RST, FIN)
- Tamanho de pacote (range)
- Valor DSCP (QoS marking)
- Fragmentação de pacotes
Ações (via comunidades estendidas):
traffic-rate:AS:rate— descarta (rate=0) ou limita a taxa de encaminhamento em bits/straffic-action— marca ou redireciona para análise (espelhamento)redirect:VRF— desvia o tráfego correspondente para uma VRF de limpeza dedicadaredirect-to-NH— redireciona para um next-hop específico (scrubbing center)
Exemplo de regra FlowSpec:
Uma regra que descarta pacotes UDP com porta de destino 53, tamanho entre 60 e 80 bytes e IP de destino 198.51.100.0/24 — padrão de amplificação DNS — seria distribuída a todos os roteadores de borda via BGP sem intervenção manual em cada equipamento.
O FlowSpec posiciona-se como uma técnica intermediária entre o blackhole total e o scrubbing center:
- É mais granular que o RTBH: permite descartar apenas o tráfego malicioso enquanto preserva o legítimo.
- É mais simples que um scrubbing center: opera no plano de controle BGP sem exigir desvio de tráfego para infraestrutura dedicada.
- Tem limitações: não inspeciona conteúdo de camada 7 e não escala bem para regras muito dinâmicas ou de alta cardinalidade.
Como funciona o scrubbing centralizado
O scrubbing centralizado desvia o tráfego para um centro de limpeza dedicado onde é inspecionado em múltiplas camadas. O processo ocorre em quatro etapas:
- Durante um ataque, o operador anuncia via BGP que o prefixo afetado deve ser roteado ao scrubbing center (geralmente via community BGP específica do provedor de mitigação).
- O tráfego de toda a internet é redirecionado ao scrubbing center, onde passa por inspeção de camadas 3 e 4 (filtragem de IPs, portas, protocolos) e camada 7 (análise de comportamento HTTP, rate limiting, detecção de assinaturas).
- O tráfego limpo é encaminhado de volta ao servidor de origem via túnel GRE ou MPLS.
- Quando o ataque cessa, o operador reverte o anúncio BGP e o tráfego retorna ao caminho normal.
Limitações do scrubbing centralizado — hairpin e ataques L7
O modelo de scrubbing center centralizado tem dois problemas estruturais críticos.
Hairpin de latência: O tráfego de um usuário em São Paulo para um servidor em São Paulo pode ser desviado para um scrubbing center em Miami ou Amsterdam, aumentando a latência em 50–150ms.
| Cenário | Latência normal | Latência com scrubbing centralizado |
|---|---|---|
| Usuário BR → Servidor BR | 5–20ms | 80–180ms (via scrubbing nos EUA) |
| Usuário EU → Servidor EU | 10–30ms | 60–140ms (via scrubbing em Amsterdam) |
| Usuário APAC → Servidor APAC | 15–40ms | 100–200ms (via scrubbing externo) |
Ataques de camada 7 e exaustão criptográfica: Scrubbing centers tradicionais operam primariamente nas camadas 3 e 4. Ataques de HTTP Flood, Slowloris e R.U.D.Y. usam requisições HTTP sintaticamente válidas a baixo volume — invisíveis para filtragem L3/L4.
Ainda mais crítico: ataques de exaustão de handshake TLS/SSL como o THC-SSL-DoS exploram a assimetria computacional do protocolo TLS, onde estabelecer uma sessão TLS custa aproximadamente 15 vezes mais CPU no servidor do que no cliente. Um atacante com hardware modesto consegue iniciar renegociações em massa e saturar a capacidade criptográfica do servidor de origem antes de saturar a rede. Um scrubbing center que não realiza terminação TLS repassa essas conexões ao servidor de origem sem inspecioná-las, tornando-o vulnerável.
Scrubbing distribuído no edge
O modelo mais moderno elimina o hairpin e resolve as limitações de L7 e TLS: em vez de desviar tráfego para um scrubbing center centralizado, o scrubbing ocorre em cada data center da rede de distribuição, próximo à fonte do ataque.
O fluxo de proteção com scrubbing distribuído funciona assim:
- Tráfego de ataque originado na Europa atinge o data center de borda europeu mais próximo via roteamento Anycast.
- O data center europeu aplica inspeção L3/L4 (volumétrica), L7 (comportamento HTTP) e inspeciona conexões após terminação TLS.
- Apenas o tráfego que passa todas as camadas de inspeção é encaminhado ao servidor de origem.
- O mesmo processo ocorre simultaneamente em data centers nos EUA, APAC e demais regiões para tráfego gerado nesses locais.
- O servidor de origem recebe exclusivamente requisições completas, válidas e inspecionadas — independentemente da escala do ataque.
Os benefícios são estruturais:
- Tráfego de ataque filtrado próximo à fonte, reduzindo a carga transportada na rede.
- Usuários legítimos não sofrem desvio de rota e mantêm a latência original.
- A terminação TLS no edge permite inspeção de camada 7 sobre o tráfego descriptografado, sem expor o servidor de origem à carga de processamento criptográfico.
Edge TLS Termination e proteção contra exaustão criptográfica
A terminação TLS no edge resolve especificamente o vetor de exaustão criptográfica. O processo funciona da seguinte forma:
- Conexões TLS de clientes são encerradas nos data centers de borda, que operam hardware com aceleração criptográfica dedicada (AES-NI, Intel QAT).
- Após o handshake TLS ser concluído no edge, a requisição HTTP é descriptografada e submetida à inspeção de WAF e análise de comportamento em tempo real.
- Apenas requisições aprovadas são encaminhadas ao servidor de origem — em uma conexão separada, que pode ser HTTP simples ou TLS com handshake já estabelecido.
- O servidor de origem nunca processa handshakes TLS de clientes externos, eliminando completamente o vetor de exaustão criptográfica.
Matriz comparativa das quatro arquiteturas
| Critério | Blackhole (RTBH) | BGP FlowSpec | Scrubbing Centralizado | Scrubbing Distribuído no Edge |
|---|---|---|---|---|
| Mecanismo de operação | Descarte total via anúncio BGP (null0) | ACLs granulares distribuídas via BGP | Desvio de tráfego para centro de limpeza dedicado | Inspeção em cada PoP via Anycast |
| Camada OSI de atuação | L3 (prefixo IP) | L3–L4 (IP, porta, protocolo, flags, DSCP) | L3–L4 (primário) + L7 (limitado) | L3–L7 integrado |
| Granularidade de filtragem | Nenhuma — descarta tudo para o prefixo | Alta — por tupla (IP, porta, protocolo, flags, tamanho) | Média — por assinatura e comportamento | Alta — por comportamento, fingerprint e conteúdo L7 |
| Impacto na latência (hairpinning) | N/A — serviço offline | Nenhum — opera no plano de controle local | +50–150ms para usuários distantes do scrubbing center | Nenhum — inspeção local no PoP mais próximo |
| Proteção SSL/TLS | Nenhuma | Nenhuma (opera abaixo do TLS) | Limitada se não houver terminação TLS | Completa — terminação TLS no edge + inspeção pós-decrypt |
| Mitigação L7 / Low & Slow | Nenhuma | Nenhuma | Parcial — depende de capacidade L7 do centro | Completa — WAF + análise comportamental integrados |
| Tempo de ativação | Segundos (convergência BGP) | Segundos (convergência BGP) | Minutos (redirecionamento + propagação BGP) | Imediata (always-on, sem ativação manual) |
| Preservação de tráfego legítimo | Nenhuma — descarta junto com o ataque | Alta — filtra por tupla específica | Parcial — preserva com degradação de latência | Total — sem impacto para usuários legítimos |
O problema do collateral damage do blackhole
Um aspecto frequentemente ignorado: quando o ISP aplica blackhole, o IP da vítima pode ser anunciado como “buraco negro” em múltiplos roteadores BGP. Isso pode causar:
- Bloqueio de reputação: Sistemas de reputação de IP registram o IP como problemático, afetando entregas de e-mail e confiança em CDNs.
- Impacto em serviços relacionados: Outros serviços no mesmo bloco
/24podem ser afetados por filtros baseados em sub-rede. - Demora na remoção: Retirar o blackhole pode levar horas para se propagar via BGP dependendo da topologia e dos timers de cada peer.
Sinais de que blackhole foi aplicado ao seu IP
| Indicador | O que verificar |
|---|---|
| Serviço inacessível de múltiplas origens geográficas | Teste de ping e traceroute a partir de IPs em diferentes ASNs |
| BGP looking glass mostra rota null | Ferramentas como bgp.he.net ou route-views.oregon-ix.net |
| Sem logs de requisições no servidor | Servidor online mas sem tráfego entrante nos logs de acesso |
| ISP confirma blackhole | Abertura de chamado com o provedor de upstream |
Erros comuns e soluções
Erro: Aceitar blackhole como “solução de mitigação” do ISP sem questionar alternativas. Solução: Exija SLA de scrubbing com preservação de tráfego legítimo. Blackhole é uma medida de proteção da infraestrutura do ISP — não uma solução para o negócio da vítima.
Erro: Implementar scrubbing centralizado sem considerar o impacto de latência. Solução: Avalie a distribuição geográfica dos seus usuários. Se estão distribuídos globalmente, um único scrubbing center introduz hairpin inaceitável. Prefira scrubbing distribuído ou FlowSpec para ataques L3/L4 simples.
Erro: Ativar blackhole automaticamente como primeira resposta a qualquer ataque. Solução: Reserve o blackhole para situações onde a infraestrutura de upstream está em risco imediato de saturação. Use scrubbing ou FlowSpec como resposta padrão para preservar disponibilidade.
Erro: Assumir que scrubbing centralizado resolve ataques de camada 7 e exaustão TLS. Solução: Scrubbing L3/L4 é eficaz contra ataques volumétricos. Ataques L7 como HTTP Flood, Slowloris e exaustão de handshake TLS requerem terminação TLS no edge e inspeção de camada 7 integrada.
Perguntas frequentes
O que é a comunidade BGP BLACKHOLE (65535:666) e como usá-la?
A comunidade 65535:666, padronizada pela RFC 7999, é uma well-known community BGP que sinaliza ao receptor que o prefixo anunciado deve ser descartado (blackholed). Para usá-la, a organização anuncia o prefixo atacado com essa community para seu(s) provedor(es) de upstream. Os roteadores dos provedores que reconhecem a community descartam o tráfego antes de encaminhá-lo à rede da vítima. É mais interoperável que soluções proprietárias, pois é reconhecida por equipamentos de múltiplos fabricantes e ISPs.
Qual é a diferença entre RTBH (RFC 5635) e BGP FlowSpec (RFC 8955)?
RTBH descarta todo o tráfego para um prefixo IP /32 (host-route) sem distinção de protocolo, porta ou comportamento — é binário: tudo ou nada. O FlowSpec permite criar regras granulares com múltiplos campos de correspondência (IP, porta, protocolo, tamanho de pacote, flags TCP, DSCP) e diferentes ações (descarte, limitação de taxa, redirecionamento para VRF). O FlowSpec é distribuído via BGP como o RTBH, mas atua como um ACL remoto, permitindo proteger o tráfego legítimo enquanto descarta apenas os padrões maliciosos.
O blackhole routing pode ser parcial — apenas para certos tipos de tráfego? O blackhole BGP tradicional via RTBH descarta todo o tráfego para o IP. A variação D/RTBH (Destination-based RTBH) permite filtrar por prefixo de origem do atacante, mas requer inteligência sobre os IPs de ataque. Para filtragem por protocolo, porta ou comportamento, é necessário BGP FlowSpec — que oferece essa granularidade mantendo a distribuição via plano de controle BGP.
Scrubbing centralizado ainda faz sentido em 2026? Sim, em cenários específicos: quando o scrubbing center está geograficamente próximo dos usuários, quando o ataque é exclusivamente volumétrico L3/L4 e quando a organização não tem acesso a uma rede edge distribuída. Para ataques modernos multi-vetor que combinam flood volumétrico com HTTP Flood, TLS exhaustion e Slowloris, o modelo distribuído no edge é superior por operar em todas as camadas simultaneamente.
Como o roteamento Anycast se relaciona com o scrubbing distribuído? Com Anycast, o mesmo bloco de endereços IP é anunciado a partir de múltiplos data centers geograficamente distribuídos. O BGP roteia automaticamente cada conexão ao data center Anycast mais próximo da fonte. Para scrubbing distribuído, isso significa que o tráfego de ataque originado na Europa é filtrado em um data center europeu, enquanto o tráfego da APAC é filtrado em um data center asiático — sem hairpin, sem aumento de latência para usuários legítimos e sem ponto único de falha.
Por que ataques Slowloris e R.U.D.Y. passam por scrubbing centers tradicionais sem serem bloqueados? Ataques low and slow como Slowloris e R.U.D.Y. usam conexões HTTP sintaticamente válidas transmitidas em ritmo extremamente lento. Do ponto de vista de volume de rede (pacotes por segundo, bits por segundo), são invisíveis para filtros L3/L4. A detecção requer inspeção de camada 7 com análise de comportamento: número de conexões abertas por IP, taxa de completude de requisições, tempo de transmissão de headers e fingerprinting de cliente (JA3/JA4). Isso só é possível após a terminação TLS e com capacidade de análise L7 no ponto de inspeção.
Um scrubbing center pode ser sobrecarregado? Sim. Ataques acima da capacidade de scrubbing do provedor podem saturar os links de entrada do próprio scrubbing center. Provedores com scrubbing distribuído têm maior capacidade total agregada, pois distribuem a carga entre dezenas de data centers. Um ataque de 1 Tbps que saturaria um único scrubbing center de 500 Gbps é diluído entre 20 data centers de 100 Gbps cada um sem saturar nenhum deles individualmente.
Como implementar na Azion
A Azion opera um modelo de scrubbing distribuído always-on que endereça todos os vetores discutidos neste artigo:
- Scrubbing no edge com rede Anycast global: O tráfego é inspecionado em cada um dos 100+ data centers da Azion, próximo à fonte do ataque. O roteamento Anycast garante que usuários legítimos não sofram desvio de rota nem aumento de latência — a inspeção ocorre no mesmo caminho que o tráfego tomaria normalmente.
- DDoS Protection always-on: Não requer ativação manual, redirecionamento BGP ou ajuste de anúncio de rotas durante o ataque. A proteção está sempre ativa, com mitigação automática iniciando em segundos para ataques volumétricos L3/L4.
- Edge TLS Termination com inspeção L7: As conexões TLS são encerradas nos data centers da Azion, que usam hardware com aceleração criptográfica. O servidor de origem nunca processa handshakes TLS de clientes externos, eliminando o vetor de exaustão criptográfica (THC-SSL-DoS e similares). Sobre o tráfego descriptografado, o WAF integrado aplica inspeção de camada 7 em tempo real, detectando HTTP Flood, Slowloris, R.U.D.Y. e outros ataques low and slow.
- Sem blackhole forçado: A Azion não aplica blackhole routing nos IPs dos clientes como resposta padrão. O objetivo é manter o serviço disponível durante o ataque, não apenas proteger a infraestrutura de rede. A política é filtrar o tráfego malicioso e encaminhar o legítimo ao destino — independentemente da escala do ataque.
Saiba mais na documentação de DDoS Protection da Azion.