Por Que É Difícil Combatê-las

O problema de defender algo contra ataques distribuídos

A defesa sempre parte em desvantagem numérica contra botnets e ataques DDoS de larga escala. Isso não é teoria — é uma questão matemática e operacional que qualquer engenheiro de segurança já viu travar no meio da madrugada. Vou explicar como funciona na prática, porque a explicação técnica sozinha não mostra onde o sistema realmente quebra.

Por que é difícil combatê-las: a assimetria estrutural

O atacante precisa de um único ponto de entrada. O defensor precisa proteger todos os pontos possíveis simultaneamente. Se você tem uma rede com 50 interfaces de saída e o adversário decide floodar apenas três delas com tráfego sintetizado, você precisa de capacidade excedente em todas as cinquenta, mesmo que o ataque ocorra em menos de 5% da sua largura de banda total. Isto gera dois problemas concretos. Primeiro, custo. Capacidade ociosa para absorver ataques volumétricos de 100+ Gbps é cara. Segundo, complexidade operacional. Quando o ataque vem de milhares de IPs distribuídos globalmente, suas listas negras tradicionais ficam desatualizadas em minutos, não em horas. Em 2019, lidamos com um cliente que sofria ataques de reflexão NTP contra sua infraestrutura de CDN. O volume nunca ultrapassava 15 Gbps, mas vinha de mais de 40 mil IPs diferentes, muitos deles servidores legítimos comprometidos. Cada bloqueio manual levava cerca de 20 minutos do tempo da equipe. O ataque durava cerca de 45 segundos por onda. Não havia como.

O que realmente acontece durante um ataque

Existem camadas de ataque que as pessoas costumam confundir, e confundir as camadas leva a soluções erradas. Ataques volumétricos tentam sufocar a banda disponível. UDP floods, amplificação DNS e NTP são comuns aqui. A mitigação geralmente envolve upstream scrubbing — redirecionar o tráfego para um datacenter que filtra antes de encaminhar ao destino. Ataques protocolares atacam a camada 4 e 7. SYN floods, HTTP floods com requests aparentemente legítimas, e ataques que exploram o estado das conexões. Estes são mais difíceis porque exigem entender o comportamento normal do serviço para distinguir tráfego bom do ruim.

Ataques semânticos são os mais traiçoeiros. Simulam padrões de uso real de usuários legítimos. Um bot que navega, clica, preenche formulários lentamente, com delays humanos entre ações. Detecção baseada apenas em análise de request por request falha completamente aqui. É necessário análise comportamental de longo prazo com telemetria de sessão.

A falácia da lista negra

A maioria das equipes começa tentando bloquear IPs de ataque. Funciona até o atacante mudar de IP, o que leva segundos. Uma abordagem mais sofisticada é bloquear ranges inteiros, mas isso cria falsos positivos significativos quando o range contém usuários legítimos compartilhando NAT ou provedores ISP comuns. Uma técnica que funciona melhor é fingerprinting de tráfego malicioso antes dele atingir seu serviço. Assinaturas de handshake TLS anormal, padrões de timing de packet splitting, e anomalias em headers HTTP que bots frequentemente erram. Isto requer telemetria de rede no edge, não apenas logs de aplicação. O workaround que implementamos para o cliente do NTP foi criar uma regra de BGP communities que enviava todo tráfego potencialmente malicioso para scrubbing automático antes de qualquer inspeção local. O resultado foi redução de 94% no tempo de resposta da equipe durante incidentes. A equipe parou de agir manualmente e passou a monitorar apenas exceções.

Mitigação em camadas: o que funciona de verdade

CAPA 1 — Edge hardening. Configurar rate limiting baseado em sessão, não por IP isolado. Usar TLS fingerprinting para identificar clients conhecidos como bots. Isto resolve cerca de 60% dos ataques de camada 7 sem impacto em tráfego legítimo, desde que bem calibrado. CAPA 2 — Anycast distribution. Distribuir a infraestrutura em múltiplos pontos de presença faz com que o ataque se dissipe geograficamente. Um ataque direcionado a um único datacenter pode ser absorvido porque o tráfego legítimo também chega por outros caminhos. Isto exige arquitetura projetada para isso desde o início, não é um patch posterior. CAPA 3 — Cleanup upstream. Contratar serviço de scrubbing com capacidade suficiente para o pico histórico mais 50%. Isto cobre os ataques volumétricos que qualquer firewall local não aguentaria. O custo é previsível, mas o SLA de failover entre seu datacenter e o scrubber precisa ser testado mensalmente, não apenas no papel.

CAPA 4 — Behavioral analysis. ML-based detection para ataques semânticos. Modelos treinados com dados do próprio serviço performam significativamente melhor que assinaturas genéricas, pois aprendem o padrão real de uso legítimo daquele serviço específico. O desafio é o tempo de convergência do modelo após mudanças na aplicação.

Limitações que ninguém comenta

Nenhuma solução cobre todos os vetores. Um scrubber volumétrico não detecta um HTTP flood behavioral. Uma WAF não para um UDP amplification attack. Você precisa de múltiplas camadas funcionando em sequência, não de uma única ferramenta "tudo-em-um". Ataques dirigidos e de baixa taxa são praticamente indetectáveis por automação pura. Se alguém dedica 10 requests por segundo contra sua API de login durante dias, cada request parece legítimo individualmente. A detecção aqui depende de correlação cross-sessão e baseline comportamental, e mesmo assim a taxa de falsos positivos pode ser alta demais para automatizar sem supervisão humana. O maior problema operacional não é técnico, é processual. Equipe sob ataque toma decisões piores. Runbooks precisam ser escritos de forma que qualquer pessoa na escala consiga executá-los sem consultar documentação externa. Na prática, a maioria das equipes não treina para incidentes até que aconteçam. E quando acontecem, o tempo perdido procurando a procedure certa é onde o dano se consolida.

A mitigação eficaz exige investimento contínuo em telemetria, testar a cadeia de mitigação a cada mudança de infraestrutura, e aceitar que alguns ataques vão atingir o serviço. O objetivo não é zero downtime — é tempo de recuperação previsível e dano contido.