Defendendo Infraestrutura contra Ataques DDoS em Escala Terabit

A escala dos ataques DDoS modernos ultrapassou o que muitos consideravam possível há poucos anos. Em novembro de 2021, a Azure mitigou um ataque de 3.47 Tbps — o maior já registrado publicamente pela Microsoft — originado de aproximadamente 10.000 fontes distribuídas em múltiplos países. Dez meses antes, outro cliente europeu havia enfrentado 2.4 Tbps concentrados em apenas 10 minutos. Esses números não são aberrações: são tendências que refletem a commoditização de botnets massivas e a disponibilização de ferramentas de amplificação cada vez mais sofisticadas.

A questão central não é mais “se” sua infraestrutura será alvo, mas quando — e se sua arquitetura conseguirá absorver o impacto sem comprometer operações críticas. Defesas pontuais baseadas apenas em firewalls ou WAFs falham em ataques volumétricos porque a saturação ocorre antes mesmo do tráfego alcançar seus sistemas de filtragem. A resposta efetiva exige arquitetura em múltiplas camadas, onde cada componente contribui com capacidade específica de absorção e filtragem.

Este artigo examina as estratégias técnicas comprovadas para construir defesa contra ataques volumétricos: desde mitigação automática na camada de rede usando BGP FlowSpec, passando por rate limiting distribuído em edge proxies, até proteção de origem. Vamos explorar não apenas o “o quê”, mas principalmente o “como” e “porquê” cada camada funciona — incluindo limitações e trade-offs que raramente aparecem na documentação de marketing.

Arquitetura de Defesa em Múltiplas Camadas

A premissa fundamental da defesa contra DDoS volumétrico é simples: você precisa de mais capacidade de absorção do que o atacante tem capacidade de geração. Para ataques em escala Tbps, isso significa que nenhuma organização — exceto os maiores provedores de cloud e CDNs — consegue defender-se sozinha com infraestrutura própria. A matemática é brutal: se seu uplink é 100 Gbps e o ataque é 3 Tbps, o tráfego satura sua conectividade 30x antes de alcançar qualquer defesa que você tenha implementado.

A arquitetura recomendada pela AWS e implementada pelos principais cloud providers segue este modelo em camadas:

Camada 1 - Roteamento BGP e DNS Anycast: Esta é sua primeira linha de defesa e, paradoxalmente, também o ponto mais vulnerável. Quando um ataque volumétrico satura seu uplink, técnicas como Remote Triggered Black Hole (RTBH) permitem sinalizar via BGP que tráfego para IPs específicos deve ser descartado ainda na borda da rede do seu ISP ou transit provider. O RTBH usa BGP communities — tipicamente redirecionando tráfego para 192.0.2.1 como next-hop (null0 interface) — mas tem uma limitação crítica: descarta TODO o tráfego para aquele IP, incluindo requisições legítimas. É uma medida extrema útil apenas quando a alternativa é indisponibilidade total.

BGP FlowSpec oferece granularidade superior. Definido na RFC 8955, permite especificar regras de filtragem que combinam até 12 critérios: prefixo origem/destino, protocolo, portas, tamanho de pacote, flags TCP, DSCP, entre outros. Isso possibilita descartar apenas tráfego UDP/53 de tamanho específico (característico de amplificação DNS) enquanto permite HTTP/HTTPS legítimo passar. A Cloudflare reporta propagação de regras FlowSpec para 200+ locations em menos de 1 minuto, mas a efetividade depende de suporte em todos os routers no caminho — e nem todos ISPs permitem FlowSpec de clientes por questões de policy.

Camada 2 - Scrubbing Centers: Aqui o tráfego é redirecionado (via BGP Anycast ou DNS) para data centers especializados com capacidade massiva de absorção e filtragem. A Cloudflare opera uma rede com capacidade superior a 172 Tbps distribuída em 300+ cidades; a Akamai Prolexic mantém 17+ scrubbing centers com capacidade combinada de 15+ Tbps. A Azure documenta capacidade superior a 10 Tbps globalmente.

O processo de scrubbing analisa tráfego em alta velocidade, descartando pacotes maliciosos e encaminhando apenas tráfego validado para a origem. A latência adicional típica é 1-5ms para filtragem L3/L4 e 10-50ms para análise L7 completa. Scrubbing centers são efetivos porque agregam capacidade de múltiplos clientes, diluindo o impacto de ataques individuais.

Camada 3 - Edge Proxies e Rate Limiting: Mesmo após scrubbing, você precisa rate limiting na borda para proteger contra ataques distribuídos de baixa intensidade que passam despercebidos em scrubbing (milhares de IPs fazendo requisições “normais” mas cumulativamente sobrecarregando sua aplicação). Aqui entram reverse proxies como NGINX, Envoy, e HAProxy com rate limiting ativo.

Camada 4 - Web Application Firewall: WAFs analisam payloads L7, identificando padrões de ataque (SQL injection, XSS) e comportamentos anômalos. São essenciais contra ataques sofisticados que exploram lógica de aplicação, mas ineficazes sozinhos contra volumétricos puros.

Camada 5 - Proteção de Origem: Sua aplicação final deve estar isolada — acessível apenas via proxies autenticados. Isso previne bypass das defesas anteriores através de ataques diretos ao IP de origem.

O trade-off fundamental é latência versus proteção: cada camada adiciona 1-5ms. Para aplicações que exigem latência ultra-baixa (gaming, trading), isso pode ser inaceitável. Para a maioria das aplicações web e APIs, é o preço da resiliência.

Rate Limiting Distribuído: Implementação e Trade-offs

Rate limiting protege contra abuso de recursos quando tráfego já passou por scrubbing mas atacantes exploram distribuição geográfica ou rotação de IPs para contornar defesas volumétricas. O desafio técnico é coordenar limites entre múltiplas instâncias de proxy sem introduzir latência proibitiva ou criar gargalos de sincronização.

Algoritmos: Token Bucket vs Leaky Bucket

Token Bucket permite bursts controlados: tokens são adicionados a um bucket em taxa constante (ex: 100 tokens/segundo); cada requisição consome 1 token. Se o bucket tem tokens disponíveis, a requisição passa; caso contrário, é rejeitada. Isso permite que um cliente faça 150 requisições em 1 segundo se havia tokens acumulados, depois throttled para taxa sustentável. É ideal quando você quer permitir picos ocasionais de tráfego legítimo.

Leaky Bucket processa requisições em taxa constante independente de quando chegam: requisições entram em uma fila e são processadas a 100 req/s uniformemente. Excess requests que excedem capacidade da fila são descartados. Isso suaviza tráfego completamente, mas pode aumentar latência média porque requisições ficam enfileiradas.

NGINX usa leaky bucket no módulo ngx_http_limit_req_module. A implementação é local por worker process — não compartilha estado entre workers ou servidores diferentes. Se você tem 4 workers em um servidor NGINX e configura limite de 100 req/s, o limite efetivo é ~400 req/s porque cada worker mantém seu próprio bucket. Para rate limiting verdadeiramente distribuído, você precisa estado compartilhado.

Redis como Backend de Coordenação

Redis resolve sincronização distribuída através de operações atômicas em memória compartilhada. A implementação clássica usa Lua scripting para garantir atomicidade:

-- Sliding Window Counter: precisão 99%+ com O(1) memória
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current_time = tonumber(ARGV[3])

local count = redis.call('INCR', key)
if count == 1 then
    redis.call('EXPIRE', key, window)
end

if count > limit then
    return 0  -- rate limit exceeded
else
    return 1  -- request allowed
end

Este script executa atomicamente no Redis single-threaded, garantindo que contadores não tenham race conditions. Benchmarks oficiais mostram que Redis single-threaded processa 100k-300k operações/segundo nesse padrão. Redis 7.0+ com I/O multi-threading atinge 1M+ ops/s em cenários simples, mas Lua scripts ainda executam single-threaded.

O projeto envoyproxy/ratelimit implementa rate limiting distribuído usando Redis como backend. É um serviço gRPC standalone que Envoy consulta via rate_limit filter. Segundo benchmarks no GitHub do projeto, processa ~20k requests/segundo por instância com latência p99 <10ms. Para escala maior, você executa múltiplas instâncias do serviço stateless com Redis cluster sharded.

Trade-off Crítico: Precisão vs Performance

Rate limiting distribuído enfrenta o problema fundamental de sistemas distribuídos: você não consegue precisão absoluta sem sacrificar performance. As opções:

Sincronização estrita: Toda requisição consulta Redis. Precisão perfeita, mas Redis vira gargalo e adiciona latência (1-5ms por request segundo análise da Cloudflare).
Local bucket + sincronização periódica: Cada proxy mantém bucket local, sincroniza com Redis a cada 100ms. Latência mínima, mas pode ter overshoot de até 10-20% durante bursts distribuídos.
Sliding Window Counter: Aproximação que divide janela em buckets menores (ex: janela de 60s dividida em 6 buckets de 10s). Precisão 99%+ com apenas 2 chaves Redis por cliente.

HAProxy 2.4+ introduziu rate limiting nativo sem depender de sticky tables, melhorando performance em ~30% segundo documentação oficial. A implementação usa estruturas de dados otimizadas que reduzem overhead de memória, mas ainda é local por instância.

A realidade: se você precisa rate limiting distribuído verdadeiramente preciso em escala (centenas de milhares de req/s), inevitavelmente precisa de infraestrutura dedicada (Redis cluster) e arquitetura de proxy que suporte backend externo (Envoy). NGINX sozinho não resolve porque não tem mecanismo nativo de coordenação distribuída.

Automação de Mitigação com BGP FlowSpec e RTBH

Quando um ataque DDoS começa, tempo de resposta é crítico. Propagação manual de regras de mitigação para routers de borda pode levar minutos — tempo suficiente para causar indisponibilidade. Automação via BGP permite resposta em segundos, mas exige compreensão profunda de como BGP propaga informações de roteamento.

Remote Triggered Black Hole (RTBH)

RTBH funciona anunciando via BGP uma rota mais específica para o IP atacado, com next-hop apontando para endereço especial (tipicamente 192.0.2.1) que routers upstream reconhecem como “descartar”. Isso efetivamente remove o IP da Internet temporariamente. RFC 7999 documenta o padrão, mas a propagação depende da topologia BGP: 30-180 segundos é típico dependendo de quantos ASes estão no caminho.

A limitação fundamental já mencionada merece reforço: RTBH é binário. Você não consegue descartar “apenas tráfego malicioso” — todo o tráfego para aquele IP é bloqueado. Isso o torna útil apenas quando:

O ataque satura completamente o uplink (alternativa é indisponibilidade total)
O IP atacado não é crítico para operações (ex: servidor de teste, serviço não-essencial)
Você tem redundância e pode redirecionar tráfego legítimo para outro IP

Para automação, ExaBGP é ferramenta open-source que permite controlar sessões BGP via API Python. Você pode integrar detecção de ataque (ex: monitoramento de NetFlow/sFlow) com ExaBGP para ativar RTBH automaticamente quando tráfego para um IP excede threshold.

BGP FlowSpec: Granularidade na Camada de Rede

FlowSpec (RFC 8955) supera a limitação binária do RTBH permitindo filtros granulares. Exemplo: descartar apenas pacotes UDP porta 53 maiores que 512 bytes (típico de amplificação DNS) enquanto permite tráfego HTTP/HTTPS passar. Ou bloquear TCP SYN sem ACK flag (SYN floods) mas permitir conexões estabelecidas.

A estrutura de uma regra FlowSpec combina match criteria com ações:

Match Criteria (até 12 suportados):

Source/Destination prefix
IP protocol (TCP, UDP, ICMP)
Source/Destination port
Packet length
DSCP (Differentiated Services Code Point)
TCP flags (SYN, ACK, FIN, RST)
ICMP type/code
Fragment encoding

Ações:

Traffic-rate (rate limit em bps/pps)
Traffic-action (sample/terminal)
Redirect (VRF ou IP next-hop)
Traffic-marking (reescrever DSCP)

A propagação de FlowSpec usa BGP, aproveitando a infraestrutura existente. Isso é simultaneamente a força e a fraqueza: propagação é rápida uma vez estabelecidas as sessões BGP, mas requer que todos routers no path suportem FlowSpec e estejam configurados para aceitar anúncios. Muitos ISPs bloqueiam FlowSpec de clientes por policy de segurança (prevenir que clientes afetem routing de outros clientes).

Integração Prática: Detecção + Automação

O workflow típico de mitigação automatizada:

Detecção: Sistema de monitoramento (Netflow, sFlow, IDS) identifica anomalia — aumento súbito de tráfego para IP específico, padrão suspeito de portas/protocolos
Análise: Determina se é ataque real vs tráfego legítimo (pico de acesso após marketing campaign pode parecer ataque)
Decisão: Escolhe técnica de mitigação apropriada (RTBH para volumétrico puro, FlowSpec para ataques com padrão identificável)
Propagação: ExaBGP ou sistema similar anuncia regras via BGP
Validação: Monitora se ataque foi efetivamente mitigado; ajusta regras se necessário
Revogação: Remove regras quando ataque termina (evitar impacto prolongado em tráfego legítimo)

O tempo total desde detecção até mitigação efetiva: 1-3 minutos em sistemas bem projetados. Compare com resposta manual que pode levar 10-30 minutos dependendo de disponibilidade de equipe e complexidade de troubleshooting.

Mesmo com automação perfeita, ataques que saturam uplink antes da propagação de regras BGP causarão indisponibilidade temporária. Não existe solução mágica — apenas camadas de defesa que reduzem probabilidade e duração de incidentes.

Estratégia de Implementação Progressiva

Construir arquitetura completa de defesa contra DDoS Tbps não acontece overnight, especialmente para organizações que não são hyperscalers. A abordagem pragmática é implementação progressiva baseada em perfil de risco e recursos disponíveis:

Fase 1 - Fundação (Semanas 1-4):

Contrato com scrubbing service (Cloudflare, Akamai, ou DDoS protection nativa do cloud provider)
Rate limiting básico em NGINX/HAProxy na edge
Isolamento de IPs de origem (não expostos publicamente)
Monitoramento de tráfego (NetFlow/sFlow baseline)

Isso cobre ~80% dos cenários de ataque e pode ser implementado rapidamente. O custo é principalmente operacional (CapEx mínimo se já usa cloud/CDN).

Fase 2 - Automação (Meses 2-3):

Sistema de detecção automatizado integrado com monitoramento
ExaBGP ou equivalente para RTBH automático em ataques volumétricos
Rate limiting distribuído com Redis (se já tem escala que justifica complexidade)
Runbooks de incident response testados em tabletop exercises

Fase 3 - Refinamento (Mês 3+):

BGP FlowSpec para filtragem granular (se ISP/transit suporta)
Machine learning para detecção de anomalias (reduz false positives)
Múltiplos scrubbing providers para redundância (evita single point of failure)
Testes regulares de failover e capacidade

A chave é não tentar implementar tudo simultaneamente. Priorize camadas que protegem contra ataques mais prováveis no seu contexto. Uma startup de SaaS B2B provavelmente enfrenta ataques diferentes de uma exchange de criptomoedas ou plataforma de gaming.

O trade-off financeiro também é real: scrubbing services cobram por Gbps de proteção; rate limiting distribuído requer infraestrutura Redis dedicada; BGP FlowSpec pode exigir routers mais caros que suportam a feature. Faça análise de risco quantitativa: quanto custa 1 hora de indisponibilidade vs quanto custa implementar camada adicional de proteção?

Você nunca estará 100% protegido contra ataques determined com recursos suficientes. O objetivo é tornar o ataque custoso o suficiente que atacantes desistam e busquem alvos mais fáceis. Arquitetura em múltiplas camadas não garante invulnerabilidade — garante resiliência e redução de blast radius quando ataques inevitavelmente ocorrem.

Mitigação de Ataques DDoS Tbps: Arquitetura e Rate Limiting