O que é QUIC Flood? Ataques DDoS contra HTTP/3 e como mitigá-los

QUIC Flood é uma família de ataques DDoS que explora o protocolo QUIC — a base do HTTP/3 — para pressionar CPU, memória, conexões e aplicações. Diferente de ataques clássicos como o SYN Flood sobre TCP, os floods QUIC operam sobre UDP com criptografia integrada em user-space, o que altera como dispositivos de segurança observam e controlam o tráfego.

QUIC, TLS 1.3 e HTTP/3: arquitetura e visibilidade de segurança

O QUIC foi padronizado pelo IETF na RFC 9000, publicada em 2021. A RFC 9001 define a integração de TLS 1.3 com QUIC, e a RFC 9114, publicada em 2022, define HTTP/3 sobre QUIC. O QUIC foi inicialmente desenvolvido pelo Google, mas a versão IETF é uma padronização própria com especificação distinta.

A integração de transporte e criptografia no QUIC tem implicações diretas para segurança. Na pilha TCP/TLS, o handshake TCP ocorre antes do TLS — o que permite que dispositivos stateful observem o estabelecimento de conexão no nível de transporte antes de qualquer dado criptografado. No QUIC, o handshake de transporte e o handshake criptográfico ocorrem de forma integrada. A pilha QUIC — incluindo TLS — costuma rodar em user-space; o kernel fornece o socket UDP, mas não tem visibilidade sobre as estruturas internas do protocolo QUIC.

Isso não torna o tráfego QUIC completamente opaco para toda finalidade de controle. Dispositivos de rede e firewalls podem observar e controlar atributos como endereços IP, portas, tamanho de datagrama, PPS, duração e padrões de fluxo. Pacotes QUIC Initial possuem campos identificáveis e podem ser processados parcialmente por ferramentas especializadas. O que exige terminação QUIC e TLS é a inspeção integral de HTTP/3 — requisições, cabeçalhos, corpo e lógica de aplicação — e políticas baseadas no conteúdo.

A tabela a seguir resume propriedades relevantes para segurança das três pilhas:

Sem terminação QUIC e TLS, dispositivos de segurança não conseguem inspecionar integralmente o conteúdo HTTP/3. Ainda assim, podem aplicar controles L3/L4, análise de fluxos, limitação de taxa, filtragem de pacotes malformados e políticas por endereço, prefixo, ASN, porta ou comportamento.

Como funciona um QUIC Flood?

O QUIC Flood explora características do protocolo para pressionar recursos do servidor de formas que ferramentas projetadas exclusivamente para TCP podem não detectar ou controlar. Os vetores variam em mecanismo, recurso alvo e dificuldade de mitigação — e frequentemente são combinados em campanhas sofisticadas.

O recurso pressionado depende do vetor: um flood de UDP/443 pressiona banda e PPS; um flood de Initial packets pode pressionar CPU de parsing e derivação de chaves; abuso de streams HTTP/3 pressiona lógica de aplicação. O efeito real depende da implementação QUIC do servidor, da configuração de defesas, da capacidade da infraestrutura e do perfil específico do ataque.

Principais vetores de ataque contra QUIC e HTTP/3

Flood de UDP/443

O vetor mais direto: inundar o servidor com datagramas UDP na porta 443. Quando o tráfego UDP/443 alcança a pilha ou a implementação QUIC, o destino pode precisar classificar e processar parte dos datagramas para identificar pacotes válidos ou aplicar regras de descarte. Controles de rede, firewall, load balancer, mitigação upstream, XDP/eBPF ou filtros de borda podem filtrar parte desse tráfego antes que ele alcance o servidor de aplicação. Em volumes elevados de PPS, esse processamento pode pressionar CPU mesmo quando parte do tráfego é descartada antes de atingir a implementação QUIC.

Bloquear UDP 443 por completo como resposta imediata resolve o flood, mas elimina HTTP/3 para todos os usuários legítimos — um trade-off que a maioria dos operadores não pode aceitar durante todo um incidente. Controles mais granulares, como rate limiting por prefixo, filtragem de pacotes malformados e validação de versão, permitem reduzir o impacto sem eliminar o serviço.

QUIC Initial Flood

O atacante envia grandes volumes de QUIC Initial packets. Um flood de QUIC Initial pode pressionar CPU, parsing, validação de tokens, buffers e recursos de handshake. O impacto depende de quanto trabalho a implementação realiza antes de validar o endereço do cliente e de aplicar limites de taxa.

Implementações robustas podem aplicar validação de endereço e limitar recursos antes de manter estado completo. Mesmo assim, floods de Initial válidos podem gerar custo de parsing, derivação de chaves iniciais, geração de Retry, timers ou buffers — especialmente quando originárias de botnets com IPs reais que completam a validação.

Ataques com IP spoofed e ataques de botnets com IPs reais têm características diferentes: no primeiro caso, o mecanismo de Retry pode reduzir o trabalho antes da validação; no segundo, a validação é completada e o custo recai sobre as etapas seguintes do handshake.

Pacotes malformados ou de versão inválida

Enviar pacotes QUIC com conteúdo malformado, campos inválidos ou versões não suportadas força o servidor a tentar parsear e classificar cada pacote antes de descartá-lo. Em volumes elevados, isso pode pressionar CPU de parsing. Dispositivos que conseguem identificar e filtrar esses pacotes antes do processamento mais profundo reduzem esse custo.

HTTP Flood sobre HTTP/3

Um HTTP Flood transportado via HTTP/3 segue a mesma lógica de qualquer ataque de camada de aplicação: requisições sintaticamente válidas que esgotam CPU, banco de dados, chamadas a terceiros ou lógica de negócio. Esse vetor exige terminação QUIC/TLS para inspeção e controle eficazes.

A diferença em relação ao HTTP Flood sobre TCP é que, sem terminação QUIC, dispositivos intermediários não conseguem inspecionar o conteúdo da requisição e aplicar políticas de WAF, rate limiting por rota ou proteção de APIs.

Abuso de streams HTTP/3

O QUIC permite multiplexação de múltiplos streams sobre uma única conexão. Um cliente pode abrir um grande número de streams simultâneos, cada um gerando custo de processamento. O protocolo define limites de streams via frames MAX_STREAMS, mas o custo de gerenciar os limites e de processar streams até esse limite ainda pode ser relevante sob ataque.

Limites de streams por conexão devem ser configurados com atenção ao perfil de uso legítimo — valores muito restritivos podem impactar aplicações que dependem de alta concorrência de streams.

0-RTT replay

O 0-RTT permite que um cliente reutilize informações de uma sessão TLS anterior — normalmente por meio de PSK (Pre-Shared Key) ou tickets de sessão — para enviar dados antes da conclusão completa do handshake. Tokens de validação de endereço e tickets/PSK para retomada de sessão são mecanismos distintos.

Dados 0-RTT podem estar sujeitos a replay em condições específicas. Aplicações devem aceitá-los apenas em operações idempotentes ou implementar medidas próprias de anti-replay. Não é correto tratar 0-RTT replay como falsificação trivial de tráfego por um terceiro sem chaves — um adversário sem acesso às chaves de sessão não consegue forjar pacotes 0-RTT válidos.

Do ponto de vista de ataques, 0-RTT pode ser usado por clientes que possuem tickets válidos para enviar requisições custosas antes da validação completa do handshake, potencialmente amplificando o custo por conexão para operações não idempotentes.

Connection ID e migração

O Connection ID (CID) identifica uma conexão QUIC e permite que ela persista durante mudanças de endereço IP. CIDs podem ser rotacionados ou emitidos conforme políticas dos endpoints; durante o handshake inicial, valores de CID podem ser controlados pelo cliente.

CID não é identidade confiável de usuário e não deve ser o único sinal para políticas de segurança. Deve ser usado como sinal complementar a IP, prefixo, ASN, reputação, identidade, sessão, credencial, token, endpoint e comportamento.

Migrações QUIC normalmente exigem validação de caminho via PATH_CHALLENGE e PATH_RESPONSE antes de enviar dados significativos ao novo caminho. Migrações excessivas ou em padrão anômalo podem ser sinal de tentativa de evasão de controles por IP e devem ser monitoradas.

Validação de endereço, Retry e limites anti-amplificação

Address Validation e Retry

A validação de endereço, definida na RFC 9000 Seção 8, é o mecanismo pelo qual um servidor confirma que o endereço de origem de um cliente é alcançável antes de investir recursos significativos no handshake.

Retry é um mecanismo opcional de validação de endereço. O servidor pode responder a um Initial packet com um Retry packet que contém um token. O cliente deve incluir esse token em um novo Initial packet para provar alcançabilidade. Um cliente com IP spoofed nunca recebe o Retry e não consegue completar o ciclo.

Retry é opcional: não é emitido automaticamente para todo Initial. Pode ser usado para exigir prova de alcançabilidade antes de investir mais recursos, mas seu uso deve equilibrar proteção, custo operacional e impacto de latência no estabelecimento de conexões. A tokenização e validação do Retry têm custo; sob um flood intenso de Initials, o próprio processamento de Retry pode ser relevante.

Outros mecanismos também podem contribuir para validação de endereço, como tokens emitidos em conexões anteriores.

Limite anti-amplificação

Antes de validar o endereço do cliente, o QUIC limita a quantidade de dados que um servidor pode enviar em resposta ao tráfego recebido. Como regra geral, antes da validação o endpoint não deve enviar mais de três vezes os bytes recebidos naquele caminho. Esse limite reduz a assimetria explorável em ataques de reflexão sobre QUIC.

Além disso, datagramas que carregam QUIC Initial devem ter pelo menos 1.200 bytes, conforme RFC 9000. Esse requisito reduz o fator de amplificação disponível: o atacante precisa enviar pelo menos 1.200 bytes para que o servidor processe um Initial, o que limita a assimetria em comparação com protocolos sem requisito de tamanho mínimo.

Em conjunto, o limite anti-amplificação e o requisito de tamanho mínimo reduzem o potencial de reflexão/amplificação, mas não eliminam ataques de IPs reais, floods de PPS ou pressão de CPU sobre parsing e handshake. Operadores devem aplicar limitação de taxa, filtragem anti-spoofing e controles de capacidade em complemento.

Telemetria e detecção de anomalias em QUIC

A detecção eficaz de anomalias em QUIC exige telemetria específica do protocolo — métricas TCP tradicionais não capturam sinais QUIC relevantes. Alertas devem ser calibrados com baseline histórico e segmentados por serviço, região, versão de cliente, rede de acesso e perfil de tráfego. Uma mudança pode indicar ataque, alteração de adoção de HTTP/3, problema de compatibilidade ou variação legítima de demanda.

Mitigação de QUIC Flood em camadas

Uma arquitetura de mitigação eficaz para QUIC combina controles em múltiplas camadas. Nenhum controle isolado resolve todos os vetores.

Mitigação L3/L4 para UDP

• Limitação de taxa por IP, prefixo, ASN e porta — aplicável a tráfego UDP sem necessidade de terminação QUIC.
• Filtragem de pacotes malformados ou com campos inválidos identificáveis sem terminação TLS.
• Descarte de datagramas que carregam QUIC Initial abaixo de 1.200 bytes, conforme as regras da RFC 9000. O custo desse controle depende de onde a validação é aplicada — por exemplo, na borda, no balanceador de carga, no kernel via XDP/eBPF ou na implementação QUIC.
• Filtragem de versões QUIC não suportadas antes de processamento mais profundo.
• BCP 38/uRPF no upstream para reduzir a viabilidade de IP spoofing na origem.
• Limitação de taxa de Initial packets por janela de tempo, por origem ou globalmente.

Controles L3/L4 protegem contra floods volumétricos e alguns Initial floods, mas não inspecionam o conteúdo HTTP/3 nem detectam abuso de streams ou HTTP Flood.

Validação de endereço, Retry e tokens

• Habilitar validação de endereço na implementação QUIC, com Retry quando adequado ao perfil de latência e compatibilidade.
• Utilizar tokens de conexões anteriores para reduzir latência de validação em clientes conhecidos.
• Quando Retry e tokens estiverem habilitados, monitorar sua emissão, aceitação, rejeição e expiração como indicadores adicionais de saúde e pressão sobre o handshake.
• Avaliar o custo do próprio processamento de Retry sob floods intensos e calibrar limites upstream em complemento.

Limitação de conexões, streams e requisições

• Limites de conexões por IP, prefixo e globalmente — para controlar o custo total de handshakes pendentes.
• Limites de streams HTTP/3 por conexão — configurados conforme o perfil de uso legítimo.
• Rate limiting por rota HTTP/3, identidade, token, tenant e comportamento — aplicável após terminação QUIC/TLS.
• Limites de 0-RTT por cliente, sessão e operação — aceitar apenas para operações idempotentes.

Terminação QUIC/TLS e controles L7

Quando QUIC e TLS são terminados na borda, controles de camada 7 podem ser aplicados às requisições HTTP/3: WAF, rate limiting por endpoint, proteção de APIs, detecção de bots e políticas por identidade e comportamento. Isso normalmente é necessário para inspeção integral de HTTP/3 e para responder a vetores como HTTP Flood e abuso de streams.

Sem terminação, ainda é possível aplicar os controles L3/L4 descritos acima e reduzir uma parcela significativa do risco — mas não todos os vetores.

Observabilidade e ajuste de políticas

• Telemetria separada para UDP/443 e QUIC — independente dos painéis TCP.
• Correlação entre métricas de rede (PPS, banda, descartes) e métricas de aplicação (latência, erros, custo por endpoint).
• Ajuste contínuo de políticas com base em baseline por serviço, região e período.
• Testes periódicos do processo de mitigação em exercícios controlados.

Consideração sobre fallback TCP

Operadores podem optar por reduzir ou suspender temporariamente QUIC para segmentos ou perfis de risco específicos durante incidentes. Isso pode direcionar tráfego para HTTP/2 sobre TCP, onde ferramentas de inspeção stateful são mais maduras. Esse comportamento de fallback pode ocorrer em navegadores e clientes que suportam Alt-Svc, mas não deve ser tratado como garantido. Mudanças devem ser testadas, monitoradas e ter critérios de rollback — podem afetar desempenho, compatibilidade e experiência do usuário.

Uma arquitetura distribuída de edge ou scrubbing pode ajudar a absorver e filtrar tráfego antes da origem. Os resultados dependem da topologia, cobertura, capacidade, configuração, perfil do ataque e integração com os protocolos publicados.

Erros comuns ao proteger QUIC e HTTP/3

Bloquear UDP 443 como resposta imediata a qualquer tráfego QUIC anômalo: isso elimina HTTP/3 para todos os usuários legítimos. Use controles granulares — filtragem de pacotes inválidos, limitação de taxa por prefixo, validação de tamanho mínimo — como primeiras respostas, preservando o serviço enquanto reduz o impacto.

Assumir que proteções de SYN Flood TCP se aplicam automaticamente ao QUIC: SYN Cookies não têm equivalente direto em todas as implementações QUIC. Verifique explicitamente se sua implementação tem validação de endereço via Retry habilitada e quais mecanismos são configuráveis.

Não diferenciar telemetria UDP/443 de TCP/443: ataques QUIC são invisíveis em dashboards focados exclusivamente em TCP. Configure coleta de telemetria separada para UDP/443 e métricas específicas do protocolo QUIC.

Tratar terminação QUIC como única defesa possível: terminação é necessária para inspeção L7 completa, mas controles L3/L4, limitação de taxa, validação de endereço e filtragem de pacotes malformados são eficazes para vetores volumétricos e de Initial flood sem exigir terminação.

Usar Connection ID como único identificador para políticas de segurança: CID não é identidade confiável. Use-o como sinal complementar, não substituto para IP, prefixo, identidade, sessão e comportamento.

Não calibrar alertas com baseline por serviço e região: thresholds globais geram falsos positivos e podem não detectar anomalias concentradas em subconjuntos de tráfego. Segmente baseline por aplicação, endpoint, versão de cliente e período.

Perguntas frequentes

O QUIC é intrinsecamente mais vulnerável a DDoS que o TCP por usar UDP? Não necessariamente. O QUIC foi projetado com mecanismos de defesa específicos — validação de endereço, Retry, limite anti-amplificação e requisito de tamanho mínimo para Initials. O desafio principal é que ferramentas e processos historicamente desenvolvidos para TCP precisam ser adaptados ou complementados para observar e controlar tráfego QUIC de forma eficaz.

Como o QUIC Flood se diferencia de ataques low and slow como Slowloris? São vetores diferentes. Slowloris mantém conexões TCP abertas com transmissão mínima, esgotando pools de conexão. Floods de QUIC Initial pressionam CPU de parsing e recursos de handshake; HTTP Flood sobre HTTP/3 pressiona a aplicação; floods volumétricos de UDP pressionam banda e PPS. As contramedidas são distintas para cada vetor.

Por que o requisito de 1.200 bytes para Initial packets é importante? Um datagrama que carrega um QUIC Initial abaixo de 1.200 bytes deve ser descartado pelo servidor conforme a RFC 9000. O requisito reduz a assimetria de tamanho que poderia favorecer ataques de reflexão. Ao exigir um datagrama maior para transportar um Initial, o protocolo eleva o custo de banda do emissor e limita a relação entre bytes enviados pelo atacante e bytes que o servidor pode transmitir antes de validar o endereço. A regra não elimina o custo de processamento de floods de alto PPS, parsing, derivação de chaves, validação de tokens, buffers ou pressão de handshake.

Retry é suficiente para proteger contra Initial floods? Retry pode reduzir o trabalho realizado antes da validação do endereço, especialmente contra ataques com IP spoofed. Não resolve diretamente ataques de botnets com IPs reais que completam a validação. O próprio processamento de Retry tem custo; sob floods intensos, complementar com rate limiting upstream é importante.

Como lidar com 0-RTT de forma segura? Aceitar dados 0-RTT apenas em operações idempotentes. Implementar medidas de anti-replay adequadas na aplicação. Monitorar a proporção de aceitação e rejeição de 0-RTT como parte da telemetria de segurança. Dados 0-RTT não podem ser forjados por terceiros sem as chaves de sessão — o risco de replay é para clientes que possuem tickets válidos, não para adversários externos sem chaves.

Como distinguir flood de QUIC de aumento legítimo de adoção de HTTP/3? A distinção requer baseline histórico por serviço e região. Floods podem apresentar picos abruptos, falhas de validação, pacotes inválidos, aumento de CPU por handshake ou crescimento desproporcional de tentativas em relação a sessões e requisições úteis. Porém, botnets distribuídas com IPs reais podem se parecer com tráfego legítimo em algumas métricas individuais. A análise deve correlacionar rede, handshake, aplicação, identidade e comportamento — nenhum indicador isolado é conclusivo.

Em ambientes que usam validação de endereço observável, crescimento legítimo tende a manter taxas de conclusão compatíveis com o baseline. Ainda assim, a interpretação deve considerar a política de Retry adotada, uso de tokens, redes móveis, NATs, versões de cliente e mudanças de configuração que podem afetar as métricas de conclusão independentemente de ataque.

Referências técnicas

• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9001 — Using TLS to Secure QUIC
• RFC 9114 — HTTP/3
• RFC 9002 — QUIC Loss Detection and Congestion Control
• RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks (BCP 38)
• RFC 3704 — Ingress Filtering for Multihomed Networks

Como implementar na Azion

A Azion pode compor uma estratégia de proteção para aplicações que publicam QUIC e HTTP/3, conforme os produtos contratados, os protocolos habilitados e as políticas configuradas.

1. Controles de borda para UDP e QUIC: políticas de rede, limitação de taxa e mecanismos de mitigação podem ajudar a reduzir tráfego anômalo antes que ele alcance a origem.

2. Terminação e proteção de aplicação: quando QUIC, TLS e HTTP/3 são terminados na borda, controles de camada 7 podem ser aplicados às requisições, incluindo políticas de segurança, limitação de taxa e proteção de APIs, conforme a configuração do ambiente.

3. Controles de conexão e comportamento: validação de clientes, limites de conexão, limites de requisição e análise de comportamento podem ajudar a reduzir a exposição a floods de handshake, abuso de streams e automação maliciosa.

4. Observabilidade: logs, métricas e telemetria podem apoiar a detecção de anomalias, a investigação de incidentes e o ajuste de políticas de mitigação.

A cobertura efetiva depende da arquitetura da aplicação, das implementações QUIC e HTTP/3 utilizadas, dos produtos habilitados, das políticas configuradas e do perfil do ataque.

Saiba mais na documentação de DDoS Protection da Azion.