O que é HTTP Flood? Como mitigar ataques DDoS de camada 7

Entenda o que é HTTP Flood, como ataques DDoS de camada 7 pressionam aplicações web e APIs, e conheça defesas como WAF, rate limiting, proteção contra bots e mitigação na borda.

27 JUL, 2026 • 18 min de leitura

Um ataque HTTP Flood é um ataque DDoS de camada 7 (aplicação) que inunda um servidor web ou API com um volume elevado de requisições HTTP GET, POST ou por meio de vetores específicos do protocolo HTTP/2. Diferente de ataques volumétricos que saturam a largura de banda, o HTTP Flood esgota recursos do servidor — threads, conexões, CPU e memória — usando requisições que podem parecer legítimas para dispositivos de rede que não inspecionam o conteúdo.

Como funcionam os ataques HTTP Flood

O impacto de um HTTP Flood depende do custo por requisição no lado do servidor. Requisições a endpoints que consultam banco de dados, executam lógica de negócio, fazem chamadas a serviços externos ou renderizam conteúdo dinâmico podem esgotar recursos com volume relativamente baixo. O atacante não precisa gerar terabits de tráfego — basta concentrar requisições em rotas custosas.

O ataque pode usar uma botnet com muitos IPs de origem ou um conjunto menor de clientes que abrem múltiplas conexões ou streams. A detecção requer análise de padrão, comportamento, custo por rota e baseline histórico — não apenas volume bruto.

Taxonomia: HTTP Flood em contexto com outros ataques

A classificação por camadas OSI é um modelo operacional útil, mas não é rígida. Um mesmo ataque pode explorar um protocolo de aplicação, trafegar sobre TCP e, ao mesmo tempo, pressionar CPU, filas de conexão e lógica de negócio. A tabela abaixo usa categorias operacionais para orientar a defesa.

Categoria operacional	Exemplos	Recursos frequentemente pressionados
HTTP Flood (L7)	GET Flood, POST Flood, cache bypass, Rapid Reset	CPU, threads, memória, banco de dados, lógica de negócio
Low and slow (L7)	Slowloris, R.U.D.Y., Slow POST	Pool de conexões TCP, workers
Estado e protocolo (L4)	SYN Flood, ACK Flood	Filas de handshake, tabelas stateful, CPU
Reflexão/amplificação	DNS Amplification, NTP, SSDP	Largura de banda, PPS, links
Volumétrico puro (L3/L4)	UDP Flood, ICMP Flood	Banda, PPS, uplinks

Roteadores e controles de rede normalmente atuam nas camadas 3 e 4, aplicando políticas por IP, porta, protocolo, volume e comportamento de fluxo. Firewalls modernos e proxies podem oferecer recursos adicionais de inspeção, mas a análise completa de requisições HTTP normalmente exige um WAF, proxy reverso ou outro componente que termine TLS.

Tipos de HTTP Flood

GET Flood

Envia requisições HTTP GET em volume elevado contra uma ou mais URLs do servidor. URLs que acionam consultas ao banco de dados, renderização de páginas dinâmicas ou processamento pesado no backend são alvos preferidos — cada requisição consome mais recursos do que uma resposta estática. O objetivo é ocupar todas as threads de processamento disponíveis até que o servidor pare de responder.

POST Flood

Combina volume de requisições com o custo de processar payloads. Formulários de autenticação, endpoints de busca e APIs de processamento de dados são alvos comuns — cada requisição POST força o servidor a analisar o corpo da mensagem antes de responder. Um POST Flood pode ter impacto maior por requisição do que um GET Flood, o que significa que volumes menores de RPS podem produzir efeito similar.

Cache bypass

Um atacante pode tentar reduzir a eficiência de cache ao usar parâmetros aleatórios, caminhos únicos ou atributos que alteram a chave de cache — como ?cb=7f3a9 ou ?ts=1687234561. O efeito depende da política de cache: algumas CDNs incluem query strings na chave, enquanto outras podem ignorar, normalizar ou limitar determinados parâmetros.

Quando o ataque é bem-sucedido, o número de cache misses pode aumentar e mais requisições alcançam a origem, elevando sua carga. Uma queda abrupta no cache hit rate é um sinal relevante, mas deve ser correlacionada com mudanças de configuração, deploys, campanhas, mix de conteúdo e métricas de origem antes de ser classificada como ataque.

HTTP/2 Rapid Reset

O HTTP/2 Rapid Reset explora o mecanismo de multiplexação do HTTP/2. No HTTP/1.1, conexões persistentes podem transportar múltiplas requisições sequenciais, mas o protocolo não oferece multiplexação simultânea nativa. O HTTP/2 introduziu streams independentes que permitem várias requisições concorrentes sobre uma única conexão TCP.

O ataque abre um stream com um frame HEADERS e o encerra rapidamente com RST_STREAM. Dependendo da implementação, o servidor, proxy ou balanceador pode precisar criar estado para o stream, processar headers, atualizar contadores, aplicar limites e lidar com o cancelamento antes de liberar recursos.

O impacto não exige que toda requisição alcance o backend. O custo de criar e cancelar streams em alta velocidade pode ser suficiente para pressionar CPU e estruturas internas da pilha HTTP/2. A característica central do CVE-2023-44487 era a possibilidade de contornar proteções baseadas apenas no máximo de streams concorrentes, abrindo e resetando streams rapidamente para manter o número ativo baixo enquanto acumulava trabalho no servidor.

A detecção requer monitoramento de métricas específicas do HTTP/2: uma proporção elevada de frames RST_STREAM em relação a streams completados, combinada com alto consumo de CPU sem tráfego de resposta proporcional, é o padrão característico desse vetor.

Sinais operacionais: o que observar

A correlação de múltiplas métricas é mais confiável do que qualquer indicador isolado. Os valores abaixo são ilustrativos — use baseline por aplicação, rota, método HTTP, região e período. Uma API autenticada pode ter cache hit rate próximo de zero em operação normal; um serviço de conteúdo estático pode operar acima de 95%.

Indicador	O que observar	Interpretação possível
RPS por rota e método	Crescimento acima do baseline histórico	HTTP Flood, lançamento de campanha ou crescimento legítimo
Custo por endpoint	Aumento de CPU, banco, chamadas externas ou latência para rotas específicas	Ataque direcionado a rota cara, regressão de código ou problema de dependência
Cache hit rate por tipo de conteúdo	Queda em relação ao baseline da rota ou serviço	Cache bypass, alteração de cache, deploy ou mudança de mix de conteúdo
Erros 5xx e timeouts	Crescimento correlacionado com pressão de tráfego	Saturação de origem, falha de backend ou alteração de política
CPU do servidor de origem	Pico sem incremento proporcional de banda L3/L4	HTTP Flood — não volumétrico
Proporção RST_STREAM / HEADERS	Crescimento abrupto por conexão ou cliente	Possível HTTP/2 Rapid Reset
Fingerprints TLS e comportamento	Concentração ou mudança inesperada de padrões	Automação, mudança de cliente ou tráfego legítimo concentrado
Sessões, cookies e sequência de navegação	Padrões incomuns para o endpoint	Bot, integração desconhecida ou falha de cliente

Nenhum indicador isolado confirma um HTTP Flood. A análise deve correlacionar telemetria de rede, TLS, HTTP, cache, aplicação e comportamento de usuários.

Alertas devem detectar mudanças relevantes em relação ao histórico daquele fluxo, e não depender de percentuais fixos universais.

Técnicas de mitigação

WAF com score-based detection

O WAF inspeciona requisições HTTP na camada 7 e pode avaliar múltiplos fatores: anomalias em headers, frequência de requisições por IP, correspondência com assinaturas conhecidas e reputação de origem.

Headers incomuns, ausentes ou inconsistentes podem ser usados como sinais adicionais, mas não devem bloquear tráfego isoladamente. A avaliação deve considerar o tipo de endpoint, o contrato da API, o perfil de clientes legítimos e a correlação com taxa, identidade, fingerprint, sessão e comportamento. Clients legítimos como APIs, aplicativos móveis, health checks e integrações backend-to-backend podem omitir headers como Accept-Language ou Referer por razões válidas.

WAF requer tuning contínuo. Regras muito agressivas podem bloquear tráfego legítimo; regras muito permissivas falham em detectar ataques. Baseline de comportamento por aplicação e endpoint é essencial para calibração.

TLS fingerprinting JA3/JA4

JA3 e JA4 são sinais de fingerprinting TLS baseados em características do Client Hello, como versões, cipher suites e extensões. Eles podem ajudar a agrupar clientes com comportamentos semelhantes e identificar automação ou ferramentas conhecidas quando correlacionados com outros sinais.

Esses fingerprints não identificam de forma única um usuário ou bot. Clientes legítimos podem compartilhar a mesma assinatura, e atacantes sofisticados podem imitar fingerprints de navegadores ou usar navegadores reais. Bots avançados podem usar Playwright, Puppeteer, Selenium ou ambientes móveis. Por isso, JA3/JA4 devem compor um score de risco junto a reputação, taxa de requisições, cookies, comportamento de navegação, identidade, rota acessada e sinais de aplicação.

JA4 é uma família mais recente de fingerprints, proposta para reduzir algumas limitações práticas do JA3, como variações de ordenação em determinados campos. Sua disponibilidade, formato e utilidade dependem da ferramenta de segurança utilizada.

Rate limiting granular por endpoint

Rate limiting pode ser aplicado por IP, prefixo, sessão, credencial, token, tenant, fingerprint, rota e comportamento. Limites somente por IP podem afetar usuários atrás de NAT ou CGNAT e são menos eficazes contra botnets distribuídas. O objetivo é impedir que requisições abusivas avancem para a origem, mas os controles de borda ainda precisam ser dimensionados para absorver e classificar o tráfego.

A granularidade por endpoint é essencial: um threshold único para toda a aplicação protege mal endpoints caros (autenticação, busca, checkout) e pode bloquear tráfego legítimo em endpoints de alto volume. Uma resposta HTTP 429 informa ao cliente que deve aguardar — e evita que a requisição consuma recursos da origem, dependendo da arquitetura.

Browser challenge e CAPTCHA adaptativo

Browser challenges e CAPTCHAs podem elevar o custo de automação e reduzir ataques de bots simples. No entanto, bots avançados podem executar JavaScript ou usar navegadores reais, e challenges podem afetar acessibilidade, APIs, aplicativos mobile, WebViews e usuários com JavaScript bloqueado. Por isso, devem ser aplicados de forma adaptativa, com monitoramento de falsos positivos e rotas de exceção para integrações confiáveis.

Proteção na borda — controles antes da origem

A mitigação mais eficaz ocorre antes que as requisições alcancem o servidor de origem. Quando o tráfego HTTPS é terminado na borda, políticas de WAF, limitação de taxa e proteção de APIs podem ser aplicadas antes que requisições selecionadas sejam encaminhadas à origem.

Uma arquitetura distribuída de edge pode reduzir a necessidade de desvio para um único centro de scrubbing e aproximar a mitigação das fontes de tráfego. O impacto de latência depende da topologia, do roteamento, da localização dos pontos de presença, da capacidade, da terminação de protocolos e das políticas aplicadas.

Erros comuns ao mitigar HTTP Flood

Bloquear IPs individualmente durante o ataque: HTTP Floods modernos usam botnets distribuídas ou múltiplos IPs. O bloqueio por IP isolado é lento e pouco eficaz. Use rate limiting baseado em comportamento, fingerprint e padrão de acesso — que funcionam mesmo quando os IPs variam.

Aplicar o mesmo rate limit para todos os endpoints: endpoints críticos (autenticação, API, checkout) têm tolerância menor a volume abusivo. Configure políticas granulares por URI com thresholds distintos por custo de processamento.

Confiar apenas em firewall de rede L3/L4: firewalls de rede não inspecionam conteúdo HTTP. Um WAF de camada 7 é necessário para detectar HTTP Flood, cache bypass e HTTP/2 Rapid Reset.

Usar thresholds fixos para cache hit rate: uma queda no cache hit rate pode ter muitas causas além de um ataque — deploy, expiração de TTL, mudança de mix de conteúdo, campanhas. Calibre alertas com baseline histórico da rota e correlacione com outras métricas.

Ignorar métricas de protocolo HTTP/2: a proporção de frames RST_STREAM é um indicador específico do Rapid Reset. Ferramentas de observabilidade de camada 7 devem incluir métricas de streams HTTP/2 além de RPS.

Perguntas frequentes

HTTP Flood e DDoS de camada 7 são a mesma coisa? HTTP Flood é uma das formas mais frequentes de DDoS de camada de aplicação, especialmente em serviços web e APIs. Outros ataques L7 incluem ataques low and slow (Slowloris, R.U.D.Y.), DNS Water Torture e exploração de APIs específicas. O HTTP Flood se distingue pelo alto volume de requisições ou pelo alto custo por requisição, enquanto low and slow opera com poucas conexões mantidas intencionalmente lentas. A prevalência varia conforme a base observada por cada provedor e período analisado.

Como TLS fingerprinting JA3/JA4 auxilia na detecção? JA3/JA4 analisa o Client Hello da negociação TLS — não os headers HTTP. Cada implementação de biblioteca de rede tende a produzir uma combinação específica de cipher suites, extensões TLS e curvas elípticas. Isso pode ajudar a identificar automação ou ferramentas conhecidas. Esses fingerprints não são identificadores únicos — muitos usuários legítimos podem compartilhar a mesma assinatura — e bots sofisticados podem imitar navegadores. Devem ser usados como parte de um score de risco, não como critério isolado.

O que torna o HTTP/2 Rapid Reset perigoso? O cliente envia apenas dois frames por tentativa (HEADERS + RST_STREAM). Dependendo da implementação, o servidor pode precisar criar estado para o stream, processar headers, atualizar contadores e lidar com o cancelamento antes de liberar recursos — mesmo que o resultado seja descartado logo em seguida. O CVE-2023-44487 demonstrou que implementações que se protegiam apenas pelo limite de streams concorrentes eram vulneráveis a esse padrão de abertura e reset rápido. O resultado pode ser saturação de CPU sem tráfego de resposta proporcional.

Por que HTTPS dificulta a mitigação? HTTPS criptografa o conteúdo das requisições. Dispositivos de rede sem terminação TLS não conseguem inspecionar headers HTTP, URLs ou payloads. A mitigação eficaz de HTTP Flood requer terminação TLS na borda, o que permite ao WAF inspecionar o conteúdo completo da requisição. Isso é relevante especialmente para a detecção de cache bypass e análise de comportamento.

CDN protege automaticamente contra HTTP Flood? CDNs absorvem carga para conteúdo cacheável. HTTP Floods que alvejam endpoints dinâmicos — APIs, autenticação, checkout — tendem a bypassar o cache por definição ou a usar técnicas de cache bypass. Proteção eficaz requer WAF e rate limiting integrados à CDN para inspeção de camada 7 antes do encaminhamento à origem.

Como distinguir HTTP Flood de um teste de carga legítimo? Testes de carga legítimos devem ter escopo, janelas, responsáveis, origem e métodos previamente acordados. A investigação deve correlacionar esses registros com telemetria de tráfego, autenticação, origem, comportamento, impacto de aplicação e mudanças de configuração. Sinais de browser, cookies e fingerprints podem ajudar, mas não são prova isolada de legitimidade ou ataque.

Qual é a diferença operacional entre HTTP Flood e ataques low and slow? HTTP Flood tende a gerar alto volume de requisições ou alto custo por requisição, podendo reutilizar conexões persistentes, HTTP/2 ou HTTP/3. Ataques low and slow como Slowloris priorizam manter conexões ou requisições incompletas abertas por longos períodos com baixa taxa de dados — saturando o pool de conexões sem gerar RPS elevado. As defesas também diferem: rate limiting e WAF focam no HTTP Flood; timeouts de conexão e limites de sessões simultâneas são mais relevantes para low and slow.

Referências técnicas

Como implementar na Azion

A Azion pode compor uma estratégia de mitigação de HTTP Flood e abuso de aplicações web, conforme os produtos contratados, os protocolos publicados e as políticas configuradas.

Controles de camada 7 na borda: quando o tráfego HTTPS é terminado na borda, políticas de WAF, limitação de taxa e proteção de APIs podem ser aplicadas antes que requisições selecionadas sejam encaminhadas à origem.
Rate limiting por rota e comportamento: limites podem ser configurados por IP, URI, método, credencial, sessão, tenant ou outros critérios disponíveis na política, considerando o custo e o perfil legítimo de cada endpoint.
Detecção de automação: sinais de comportamento, reputação, headers, sessões e fingerprints TLS — quando disponíveis — podem ajudar a identificar tráfego automatizado. Esses sinais devem ser usados de forma combinada para reduzir falsos positivos.
Observabilidade: logs, métricas de requisições, erros, cache, latência e políticas aplicadas podem apoiar a detecção de anomalias e o ajuste de controles durante um incidente.

A cobertura efetiva depende da arquitetura da aplicação, da terminação de TLS, dos produtos habilitados, das políticas configuradas e do perfil do tráfego e do ataque.

Saiba mais na documentação do WAF da Azion.

Conteúdo Relacionado

Comunidade