Como a proteção DDoS realmente funciona

Atualizado em May 9, 2026X-ZoneServers Learn

Um ataque de Negação de Serviço Distribuído (DDoS) usa muitas fontes — tipicamente uma botnet de dispositivos comprometidos — para inundar um alvo com tráfego até que usuários legítimos não consigam alcançá-lo. Proteção DDoS não é um produto único; é um sistema em camadas de filtragem na borda da rede, scrubbing de tráfego e regras com consciência de aplicação. Entender qual camada um ataque mira é o primeiro passo para entender o que "protegido contra DDoS" realmente significa em um contrato de hospedagem.

Ataques nas camadas 3, 4 e 7

Ataques de camada 3 miram a camada de rede (IP, ICMP) — exemplos são ICMP flood e ataques de fragmentação IP. Ataques de camada 4 miram a camada de transporte (TCP, UDP) — exemplos são SYN flood, amplificação UDP e amplificação DNS. Ataques de camada 7 miram a camada de aplicação (HTTP, HTTPS) — exemplos são HTTP GET/POST flood e Slowloris. Cada camada exige mitigação diferente.

Ataques volumétricos nas camadas 3 e 4 tentam saturar o próprio cano da rede. Os maiores ataques publicamente divulgados ultrapassaram o limite de múltiplos terabits por segundo — a Cloudflare relatou ter mitigado um ataque de 7,3 Tbps em maio de 2025, e a AWS Shield relatou um ataque de 2,3 Tbps já em fevereiro de 2020. Esses ataques funcionam porque protocolos de amplificação (DNS, NTP, memcached, CLDAP) permitem que uma pequena consulta com IP forjado dispare uma resposta muito maior enviada à vítima — fatores de amplificação de 50x para DNS, 200x para NTP e 50.000x para memcached foram documentados. Ataques de protocolo na camada 4 — SYN flood, ACK flood, ataques de pacotes fragmentados — esgotam o estado de connection tracking em firewalls e balanceadores de carga em vez de saturar a banda. Ataques de camada 7 são os menores em bytes mas os mais difíceis de filtrar: um HTTP flood de uma botnet de 100.000 nós parece bit a bit como usuários reais, e somente lógica com consciência de aplicação consegue diferenciá-los.

BGP blackhole e remote-triggered black hole (RTBH)

BGP blackholing é a mitigação brutal mas eficaz de último recurso: o operador de rede anuncia uma rota /32 para o IP atacado em uma comunidade BGP especial de "blackhole", dizendo a todos os pares upstream para descartar todo o tráfego destinado àquele IP. O alvo permanece offline, mas o resto da rede continua no ar. RTBH é padronizado na RFC 5635 e suportado por toda operadora Tier 1.

RTBH está documentado na RFC 5635 (agosto de 2009) e funciona marcando uma rota com um atributo de comunidade que pares upstream interpretam como "descarte todo o tráfego destinado a esse prefixo". A mitigação é total — o IP protegido se torna inalcançável de toda a internet, incluindo de usuários legítimos — mas protege o resto da frota de clientes de danos colaterais. Por ser tão drástico, RTBH é apropriado quando um único IP está sendo saturado por um ataque de várias centenas de gigabits e o custo de uma indisponibilidade mais ampla supera mantê-lo online. Muitos planos de VPS de baixo nível "protegidos contra DDoS" significam exatamente isso: o provedor faz null-route do seu IP sob ataque para manter o resto da frota seguro. Isso é mitigação de negação de serviço por definição, mas o recurso protegido é a rede do provedor, não a sua.

Scrubbing centers e desvio de tráfego

Um scrubbing center é um site de rede endurecido onde tráfego de ataque é filtrado e tráfego limpo é encaminhado à origem. O tráfego é desviado por anúncio BGP (sempre ativo ou sob demanda) ou apontamento de DNS. A capacidade de scrubbing por Tbps é a métrica de destaque — os maiores provedores operam mais de 200 Tbps de scrubbing agregado, enquanto provedores de hospedagem especializados normalmente anunciam 1-10 Tbps.

Scrubbing centers rodam appliances especializados — Arbor TMS, Radware DefensePro, A10 Thunder, NSFOCUS ADS ou pipelines Linux/DPDK personalizados em larga escala — que inspecionam cada pacote, classificam padrões benignos versus maliciosos e encaminham apenas a fração limpa à origem. O desvio é geralmente feito por BGP: o prefixo do cliente é anunciado pela rede anycast do provedor de scrubbing durante um ataque, sugando todo o tráfego para o site de scrubbing mais próximo. Após a limpeza, o tráfego é tunelado (GRE, IPSec, cross-connect dedicado ou peering direto) de volta ao servidor de origem. A latência de scrubbing é tipicamente de 1-3 ms na região, mais o caminho extra que o desvio adicionar. Scrubbing sempre ativo mantém o desvio permanentemente, eliminando o tempo de início da mitigação ao custo de um imposto constante de latência. Scrubbing sob demanda só desvia durante ataques detectados, o que é mais barato mas introduz uma janela de ativação de 30-180 segundos durante a qual o ataque acerta.

Mitigação sempre ativa vs sob demanda

A mitigação sempre ativa roteia todo o tráfego pela camada de scrubbing 24/7 — zero atraso de ativação, mas cada pacote paga um pequeno imposto de latência (1-5 ms típicos). A mitigação sob demanda só ativa quando um ataque é detectado, eliminando latência em estado estável mas expondo a origem durante a janela de ativação (tipicamente 30-180 segundos). Configurações híbridas combinam ambas: sempre ativa para HTTP/HTTPS, sob demanda para tráfego IP bruto.

Escolher entre sempre ativa e sob demanda é uma troca entre latência em estado estável e vulnerabilidade na janela de ataque. Serviços sensíveis à latência — servidores de jogos multiplayer, trading de baixa latência, voz/vídeo — geralmente escolhem sob demanda e aceitam o intervalo de ativação porque cada milissegundo de RTT em estado estável os custa caro. Serviços web públicos, APIs e apps SaaS geralmente escolhem sempre ativa ou uma topologia totalmente proxiada estilo CDN, em que o IP de origem nem é publicamente conhecido, eliminando totalmente a janela de ataque. Provedores modernos de borda em nuvem (Cloudflare, Fastly, AWS Shield Advanced, Google Cloud Armor) tendem ao sempre ativo por padrão porque sua rede já termina o tráfego em centenas de pontos de presença e o "desvio" é praticamente zero.

Rate limiting, WAF e defesa na camada de aplicação

Rate limiting limita requisições por IP de origem, por sessão ou por URL, atenuando floods de camada 7 sem afetar tráfego legítimo. Um Web Application Firewall (WAF) inspeciona requisições HTTP contra regras — proteções OWASP Top 10, regras de taxa personalizadas, geo-blocking, desafios JS e CAPTCHA. Juntos, lidam com ataques de camada 7 que o scrubbing volumétrico sozinho não consegue.

O scrubbing volumétrico para no limite de IP e porta. Para parar um HTTP flood que parece tráfego real do Chrome, você precisa de regras que operem em URLs, cabeçalhos, cookies e comportamento. Rate limiting é o controle de camada 7 mais simples e mais eficaz: limite um único IP a, digamos, 60 requisições por minuto em /login e descarte o resto. Um WAF vai além com regras conscientes do conteúdo: bloqueia requisições com padrões de SQL injection, user agents anômalos, referrers ausentes, origens geográficas fora da sua área de serviço ou tamanhos de payload muito fora do intervalo legítimo. WAFs modernos (AWS WAF, Cloudflare WAF, Fastly Next-Gen WAF, ModSecurity com o OWASP Core Rule Set) também executam desafios JavaScript, hCaptcha e heurísticas de fingerprint de bot que reduzem a taxa de sucesso de uma botnet em 99%+ sem incomodar navegadores reais.

O que provedores de hospedagem normalmente incluem vs cobram à parte

Camadas gratuitas ou inclusas geralmente cobrem ataques volumétricos das camadas 3-4 até um teto fixo de gigabits por segundo (frequentemente 10-100 Gbps) usando rate limiting básico e BGP blackhole. Add-ons pagos geralmente incluem scrubbing sempre ativo, WAF, mitigação de camada 7, criação de regras personalizadas e garantias de mitigação respaldadas por SLA. Leia o contrato — "proteção DDoS ilimitada" frequentemente significa "vamos null-roteá-lo acima de X Gbps".

O marketing de DDoS dos provedores de hospedagem varia muito. Proteção genuinamente útil inclui três coisas: (1) uma capacidade declarada clara em Gbps ou Tbps, (2) cobertura das camadas 3 a 7, incluindo mitigação de HTTP flood, e (3) um SLA por escrito com tempo de início de mitigação e compromissos de perda de tráfego. Proteção menos útil é um simples selo de "DDoS protegido" sem número de capacidade, o que geralmente significa apenas BGP blackhole — seu IP é null-roteado sob ataque e você fica fora pelo tempo todo. Ao avaliar, pergunte: qual é a capacidade declarada por IP? É sempre ativa ou sob demanda? Cobre a camada 7? Qual é o SLA de tempo de ativação da mitigação? O que acontece quando o ataque excede o teto do seu nível? As respostas revelam se você está comprando proteção real ou apenas um rótulo de marketing.

Perguntas frequentes

Qual foi o maior ataque DDoS já registrado?
A Cloudflare relatou publicamente ter mitigado um ataque DDoS de 7,3 Tbps em maio de 2025, o maior já divulgado publicamente. Antes disso, picos registrados incluíam um ataque de 3,8 Tbps mitigado pela Cloudflare em outubro de 2024 e vários ataques de mais de 2 Tbps relatados pelo Microsoft Azure e pelo Google Cloud desde 2020.
A proteção DDoS deixa meu site mais lento?
O scrubbing sempre ativo adiciona 1-5 ms de latência em estado estável, a mitigação sob demanda não adiciona nada em estado estável mas o expõe durante a ativação, e redes de proxy de borda como Cloudflare ou Fastly frequentemente melhoram a latência ao servir de pontos de presença próximos.
Uma CDN pode substituir a proteção DDoS dedicada?
Para cargas HTTP/HTTPS, sim — CDNs modernas (Cloudflare, Fastly, Akamai) incluem proteção DDoS nas camadas 3, 4 e 7 por padrão, ocultando seu IP de origem atrás de anycast. Para cargas não HTTP (servidores de jogos, e-mail, TCP/UDP brutos), você ainda precisa de proteção dedicada na camada de rede.
O que é um SYN flood?
Um SYN flood é um ataque de camada 4 que abre conexões TCP de endereços de origem forjados mas nunca completa o handshake de três vias, esgotando a tabela de conexões do servidor. As mitigações incluem SYN cookies (RFC 4987), rate limiting de conexões no firewall e filtragem com estado na borda da rede.
O que é amplificação?
Amplificação abusa de serviços baseados em UDP (DNS, NTP, memcached, CLDAP) onde uma pequena consulta produz uma resposta muito maior. Atacantes forjam o IP da vítima como origem para que a resposta inunde a vítima. O maior fator de amplificação registrado é o memcached, com cerca de 51.000x.
A proteção DDoS é exigida por lei?
Não diretamente. No entanto, regulamentações associadas — PCI-DSS para processadores de cartão, HIPAA para saúde, regras de serviços financeiros na maioria das jurisdições — efetivamente a exigem porque mandam disponibilidade e capacidade de resposta a incidentes inviáveis sem mitigação de DDoS em vigor.