O desenvolvimento de serviços em nuvem e soluções IoT sem a devida atenção à segurança da informação leva a infecções por botnets como o Mirai. De acordo com dados da Cloudflare, no início de setembro de 2025, vários provedores de serviços IoT e serviços em nuvem, incluindo o Google Cloud, foram fontes de um ataque UDP Flood com potência de 11,5 Tbps e duração de 35 segundos. Isso é comparável à transmissão contínua de 10.000 horas de vídeo de alta qualidade em apenas meio minuto. Esses ataques demonstram claramente as capacidades dos atacantes: ataques DDoS de centenas de Gbps agora podem ser realizados com esforço mínimo, causando interrupções nos negócios por horas ou até dias.
Qual é a força desses ataques e como combatê-los? Explicamos neste artigo e sugerimos quais medidas devem ser tomadas para mitigar as consequências.
Como funciona o UDP Flood
UDP Flood é um tipo de ataque DDoS volumétrico na camada de transporte (L4) da rede, no qual o atacante envia uma grande quantidade de pacotes UDP para portas aleatórias ou predefinidas do host de destino.
Originalmente, o protocolo UDP (User Datagram Protocol) foi projetado como um transporte minimalista sobre IP para aplicações que não requerem mecanismos de entrega confiável: confirmação de recebimento, retransmissões ou controle da ordem dos pacotes. Por isso mesmo, um atacante pode continuamente “inundar” o alvo em uma única direção sem aguardar nenhuma resposta. Essas propriedades tornaram o UDP uma base conveniente para VoIP, streaming de vídeo e jogos on-line, onde a perda de pacotes individuais não é crítica.
Outra característica do protocolo UDP é que o host de destino responde com uma mensagem ICMP de “serviço indisponível” caso a porta esteja fechada e o ICMP não seja restringido por políticas de segurança. Esse processo sobrecarrega o servidor atacado com o processamento da requisição, a verificação da existência de um serviço na porta indicada e a formulação de uma resposta. A mensagem de resposta também carregaria a própria fonte do ataque, mas os atacantes passaram a utilizar a técnica de IP Spoofing, substituindo o endereço IP do remetente no pacote por um endereço aleatório. Dessa forma, usando recursos mínimos, o atacante consegue saturar tanto o canal de comunicação descendente quanto o ascendente.
Anteriormente, examinamos em detalhes o SYN Flood — um ataque TCP clássico voltado ao esgotamento das tabelas de conexões e dos recursos da pilha TCP.
Vamos comparar UDP Flood vs TCP SYN Flood.
| Critério | UDP Flood | TCP SYN Flood |
| Custo computacional do atacante | Baixo | Alto |
| Escalabilidade | Alta | Limitada pela manutenção de conexões semi-abertas |
| Facilidade de falsificação de endereço IP | Alta | Média |
| Esgotamento de recursos | Largura de banda / limites de hardware (tabelas TCAM, session tables, CPU do plano de controle) / CPU do host de destino | Número de usuários do serviço / CPU do host de destino |
| Impacto sobre o operador | Alto | Baixo |
| Método de detecção | Anomalias no perfil de tráfego (PPS/BPS, assimetria de fluxo, aumento múltiplo de fontes) | Proporção de pacotes SYN em relação ao total (SYN ratio) |
| Método de proteção no host atacado | Limitação de fluxo UDP (Rate-limiting), mecanismos de proteção de serviços (DNS RRL, SIP rate control, QUIC Retry Token) | SYN Cookies |
Tipos de UDP Flood
Saber que um ataque opera na camada de transporte via UDP é apenas o primeiro passo. Para uma proteção eficaz, é importante identificar seu tipo específico: o mecanismo, a fonte do tráfego e os protocolos de aplicação envolvidos. Sem isso, as contramedidas podem ser excessivas ou ineficazes. Vejamos as principais variantes de UDP Flood com as quais os operadores de telecomunicações se deparam com mais frequência.
UDP Flood via Botnet (non-spoofed)
Hoje, esse é o cenário mais comum. O crescente número de dispositivos IoT vulneráveis, servidores desatualizados e roteadores domésticos cria uma base massiva para botnets. O tráfego vem de IPs reais de dispositivos infectados, fazendo com que os pacotes pareçam legítimos e sejam difíceis de filtrar.
Os riscos vão além da parte atacada: um operador cuja rede contenha assinantes infectados pode se deparar com o estouro das tabelas CG-NAT devido ao maciço tráfego de saída. Como resultado, usuários comuns são prejudicados e o operador se torna de fato um participante involuntário do ataque.
UDP Flood Clássico (spoofed)
Um método antigo, mas ainda relevante: um fluxo de pacotes UDP é gerado com endereços de remetente falsificados, frequentemente com utilitários facilmente disponíveis. O baixo limiar de entrada o torna popular entre atacantes iniciantes.
Sua prevalência está diminuindo gradualmente graças à implementação da filtragem BCP38 e ao surgimento de métodos de amplificação mais eficazes. No entanto, com filtragem fraca, esse tipo de ataque ainda é capaz de saturar os canais.
Ambos os tipos podem atacar uma única porta ou muitas portas aleatórias. No segundo caso, o host alvo é adicionalmente sobrecarregado com o processamento de respostas ICMP.
UDP Flood por Reflexão (reflection/amplification)
Um subtipo especialmente perigoso que utiliza serviços refletores abertos. O atacante envia uma pequena requisição com o endereço falsificado da vítima, e o servidor retorna uma resposta significativamente maior para a vítima. O fator de amplificação pode chegar a dezenas, centenas e até milhares de vezes, permitindo gerar um tráfego enorme com recursos mínimos do atacante.
Ataques de Varredura e Multivetoriais
Qualquer um desses tipos pode ser direcionado não a um único host, mas a uma sub-rede inteira — o chamado carpet bombing, onde o tráfego é distribuído por vários endereços e é mais difícil de detectar. Na prática, os atacantes frequentemente combinam vários métodos simultaneamente, formando ataques multivetoriais que requerem proteção abrangente.
Como detectar um UDP Flood
O primeiro passo para construir uma proteção é aprender a identificar oportunamente qual tipo de ataque atingiu a infraestrutura.
O primeiro e mais evidente sinal é um aumento repentino e anômalo no tráfego de entrada. Ao contrário do crescimento orgânico de carga característico dos horários de pico, um ataque aparece como um pico vertical no gráfico: o tráfego aumenta várias vezes ou por ordens de grandeza em segundos. Ao mesmo tempo, a carga de CPU do roteador de borda ou firewall cresce rapidamente, pois o equipamento é obrigado a processar cada pacote recebido.
Simultaneamente, registra-se degradação na qualidade do serviço: a latência aumenta, a taxa de perda de pacotes cresce para os usuários legítimos, os serviços começam a responder com lentidão ou param de responder. No caso de um ataque ao CG-NAT, o operador recebe reclamações de assinantes sobre a impossibilidade de estabelecer novas conexões — sinal certo do esgotamento das tabelas de tradução.
Ao analisar o tráfego, observa-se um quadro característico: alta proporção de pacotes UDP com tamanho mínimo ou fixo, portas de destino pseudo-aleatórias ou claramente repetidas, um número anormalmente alto de endereços IP únicos de remetentes (em ataques spoofed) ou, ao contrário, tráfego proveniente de determinados ASNs ou regiões geográficas (em ataques de botnet). Em ataques de reflexão, o tráfego virá de endereços de servidores DNS ou NTP públicos conhecidos, o que por si só é uma anomalia. A lista de servidores vulneráveis costuma ser distribuída por plataformas de Threat Intelligence, fornecendo uma lista pronta para bloqueio ou limitação de fluxo.
Para a detecção oportuna de ataques, os operadores de telecomunicações geralmente utilizam várias fontes de monitoramento.
- NetFlow/sFlow/IPFIX — a telemetria dos roteadores continua sendo a principal fonte de dados para análise de tráfego no nível do operador. Os coletores permitem construir perfis de tráfego em tempo real e detectar anomalias por protocolo, porta, volume e geografia. Alertas de limiar para o crescimento repentino do tráfego UDP são configurados com base nas métricas de carga normal.
- Monitoramento SNMP de interfaces de roteadores via Zabbix, Prometheus com exportador SNMP ou Grafana permite registrar a saturação de canais e o crescimento anômalo de contadores de erros e pacotes descartados.
- DPI (Deep Packet Inspection) permite a análise no nível do conteúdo dos pacotes, identificando assinaturas características de ataques conhecidos, incluindo tráfego de reflexão de tipos específicos de refletores. Soluções baseadas em DPI, como o Stingray da VAS Experts, permitem não apenas detectar um ataque, mas também aplicar imediatamente políticas de filtragem granular sem bloquear o tráfego legítimo.
- Sistemas de detecção de anomalias (NBAD) — soluções AntiDDoS especializadas que analisam o comportamento do tráfego em relação a uma linha de base e acionam automaticamente os procedimentos de mitigação quando um ataque é detectado. O tempo de resposta desses sistemas é medido em segundos, o que é crítico durante ataques de alta intensidade. O Stingray AntiDDoS é um exemplo destacado de sistema dessa classe: ao analisar dados de QoE com redes neurais e algoritmos de machine learning, o detector identifica desvios da norma, classifica ameaças e determina suas fontes.
Métodos de proteção
A proteção contra UDP Flood não é universal: um servidor DNS, uma plataforma SIP e os serviços web são atacados de formas diferentes e requerem contramedidas distintas. A seguir, recomendações práticas para cada tipo de infraestrutura com comandos e configurações específicas.
Proteção de servidores DNS
O DNS é um alvo duplo: o servidor é atacado diretamente e também usado como refletor para ataques contra outros. Um resolver autoritativo com resolução recursiva aberta e sem rate limiting é um amplificador ideal para o atacante.
Fechar a recursão para clientes externos
Um servidor DNS autoritativo não deve responder a consultas recursivas de IPs externos. No BIND:
options { recursion yes; allow-recursion { 192.168.0.0/16; 10.0.0.0/8; }; allow-query-cache { 192.168.0.0/16; 10.0.0.0/8; }; };
No Unbound — negar consultas de todos exceto sub-redes confiáveis via access-control.
access-control: 192.168.0.0/16 allow access-control: 10.0.0.0/8 allow access-control: 0.0.0.0/0 refuse
Response Rate Limiting (RRL)
Limita o número de respostas enviadas a um mesmo endereço IP por unidade de tempo. Reduz a eficácia do DNS Amplification e protege contra a inundação direta de consultas. Exemplo para BIND 9.18+:
rate-limit { responses-per-second 15; window 15; slip 2; };
Minimização de respostas ANY
As consultas ANY produzem o maior fator de amplificação. As versões modernas de BIND e Unbound retornam minimal-any por padrão, mas vale especificá-lo explicitamente.
minimal-responses yes; // BIND minimal-any yes; // BIND 9.11+
Proteção da infraestrutura VoIP / SIP
O SIP opera sobre UDP (porta 5060) e é particularmente vulnerável a inundações: cada pacote recebido requer análise no nível de aplicação, o que esgota rapidamente os recursos do SBC (Session Border Controller) e do Asterisk/FreeSWITCH. Além disso, a infraestrutura SIP frequentemente sofre ataques combinados — a inundação se combina com spam de registro e Toll Fraud.
Rate limiting orientado a SIP no SBC
O Session Border Controller deve limitar o número de mensagens SIP (INVITE, REGISTER, OPTIONS) de um mesmo IP. Exemplo de configuração no Kamailio:
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 16)
modparam("pike", "remove_latency", 4)
O módulo pike bloqueia uma fonte quando ela ultrapassa 16 requisições em 2 segundos. Para tráfego corporativo, o limiar deve ser calibrado conforme a carga real.
Restrições no nível do subsistema do kernel Linux
A filtragem no nível do sistema operacional antes que os pacotes cheguem à pilha SIP reduz significativamente a carga. Com iptables:
iptables -A INPUT -p udp --dport 5060 -m hashlimit \ --hashlimit 50/sec --hashlimit-burst 100 \ --hashlimit-mode srcip --hashlimit-name SIP \ -j ACCEPT iptables -A INPUT -p udp --dport 5060 -j DROP
Com nftables:
table inet filter {
chain input {
type filter hook input priority 0;
ip protocol udp udp dport 5060 \
limit rate over 50/second burst 100 \
per ip saddr accept
ip protocol udp udp dport 5060 drop
}
}
O valor de 50/sec ou 50/second é ajustado à carga real — o valor atual é adequado para um SBC corporativo de pequeno porte. O limite deve ser aplicado por IP, caso contrário, tráfego burst legítimo pode ser descartado ou a negociação RTP prejudicada.
Ocultar a infraestrutura SIP atrás do SBC
Os servidores de mídia (Asterisk, FreeSWITCH) não devem ter IPs públicos. O SBC recebe todo o tráfego SIP/RTP externo, o encerra e o encaminha para a rede interna. Isso elimina ataques diretos aos servidores de aplicação.
Largura de banda dedicada para tráfego RTP
Os fluxos de mídia (RTP/UDP) devem ser alocados a uma faixa de portas separada e limitados em largura de banda no nível de QoS. Durante um ataque, a inundação na porta 5060 não deve competir com as sessões de voz ativas.
Importante: o SIP OPTIONS flood é um ataque popular que imita requisições keepalive legítimas. Certifique-se de que seu SBC distingue OPTIONS de pares confiáveis e fontes aleatórias, e limita estritamente essas últimas.
Proteção de serviços web e APIs
O HTTP opera sobre TCP, mas o UDP Flood afeta a infraestrutura web de forma indireta: ao saturar o canal e sobrecarregar o equipamento de borda, o ataque torna inacessíveis todos os serviços, incluindo os web. Uma ameaça separada é o QUIC (HTTP/3), que opera sobre UDP/443: os atacantes utilizam cada vez mais refletores QUIC ou atacam diretamente os endpoints QUIC.
Restrição de UDP/443 (QUIC) durante um ataque
Se o servidor web não usa HTTP/3, a porta UDP/443 deve ser fechada completamente. Se o QUIC for necessário, implemente rate limiting similar ao do SIP.
ip protocol udp udp dport 443 \ limit rate over 500/second burst 1000 \ per ip saddr accept ip protocol udp udp dport 443 drop
Uso da migração de conexão QUIC com cautela
A migração de conexão no QUIC permite a troca de IP sem interromper a conexão — útil para clientes móveis, mas pode ser explorada para amplificação. Controle os parâmetros preferred_address e migration na configuração do servidor.
Configuração do nginx para proteção contra ataques QUIC
Além dos filtros de rede, os parâmetros do nginx podem ser otimizados para reduzir a carga durante ataques UDP indiretos.
quic_retry on; quic_max_idle_timeout 30s; quic_max_packet_size 1350;
Certifique-se de que sua versão do nginx suporta QUIC e as diretivas correspondentes. Essas configurações não substituem a proteção no nível de rede, mas ajudam a reduzir a carga no servidor web.
Medidas de proteção universais para o operador
uRPF (BCP38)
Filtra pacotes com endereços falsificados diretamente no roteador — antes de entrar na rede do operador. O modo strict é mais eficaz, mas requer roteamento simétrico; o modo loose é adequado para multihoming. Exemplo para Cisco IOS em uma interface de borda:
ip verify unicast source reachable-via rx ! strict mode ip verify unicast source reachable-via any ! loose mode
BGP Flowspec
Permite distribuir regras de filtragem por toda a rede por meio de anúncios BGP — bloqueando o tráfego de ataque mais próximo da fonte sem sobrecarregar os nós centrais. Exemplo de regra para bloquear UDP Flood em um prefixo específico:
match destination 203.0.113.0/24 protocol udp dst-port 53 then discard
Para aplicar o Flowspec, o equipamento de rede deve suportar essa funcionalidade no nível do plano de dados.
RTBH (Remotely Triggered Black Hole)
Medida de emergência durante ataques de faixa de terabit: anúncio do prefixo atacado para a comunidade blackhole do provedor upstream. O tráfego é descartado no ponto de interconexão — antes de chegar ao seu canal. A vítima fica temporariamente inacessível, mas a infraestrutura do operador é protegida.
ip route 203.0.113.1/32 Null0 router bgp 65000 network 203.0.113.1/32 route-map BLACKHOLE
Centro de limpeza (Scrubbing Center)
Com um centro de limpeza de tráfego próprio ou alugado, o prefixo atacado é redirecionado por ele via BGP. O scrubbing center filtra o tráfego anômalo e devolve o fluxo limpo ao operador por meio de um túnel GRE ou MPLS.
Proteção da VAS Experts
O sistema Stingray AntiDDoS oferece proteção abrangente contra UDP Flood no nível do operador, combinando DPI, análise comportamental e mitigação automática em uma única solução.
| Capacidade | Descrição |
| DPI em velocidade de linha | Análise de tráfego de até 5 Tbps sem degradação de desempenho |
| Detecção de packet rate (nível Mpps) | Detecção instantânea do crescimento anômalo de PPS e proteção contra ataques de packet rate que sobrecarregam a CPU e o plano de controle dos equipamentos |
| Filtragem granular | Por protocolo, porta, tamanho de pacote, geografia — sem bloquear o tráfego legítimo |
| Proteção CG-NAT | Controle do flooding de saída, prevenção do esgotamento das tabelas de tradução |
| Integração BGP | Acionamento automático de RTBH e Flowspec ao detectar um ataque |
| Detecção de carpet bombing | Análise agregada no nível de AS — detecta ataques distribuídos em sub-redes |
| Filtragem inline no plano de dados | Mitigação diretamente no nó do operador sem redirecionar o tráfego para um scrubbing center externo — ciclo completo de proteção dentro de uma única plataforma |
Estudos de caso
A análise de incidentes públicos permite não apenas avaliar a escala das ameaças modernas, mas também extrair lições práticas para a própria infraestrutura.
Caso 1 — GitHub, fevereiro de 2018
| Potência do ataque | 1,35 Tbps (recorde na época) / 126,9 Mpps |
| Duração | ~10 minutos |
| Vetor | Memcached UDP Amplification (porta 11211), ~50.000 refletores |
| Fator de amplificação | Até 51.000x (1 byte de requisição → 51 KB de resposta) |
| Consequências | O GitHub ficou inacessível por vários minutos antes da migração para o Akamai Prolexic |
| Lição principal | O Memcached não deve ser acessível pela internet. UDP/11211 deve ser fechado globalmente |
| Como foi mitigado | O redirecionamento do tráfego pelo scrubbing center da Akamai absorveu o ataque em ~8 minutos |
Caso 2 — Cliente NDA da Microsoft Azure, novembro de 2021
| Potência do ataque | 3,47 Tbps / 340 milhões de pacotes por segundo |
| Duração | ~15 minutos |
| Vetor | UDP Reflection na porta 80 com uso simultâneo de quatro protocolos amplificadores: SSDP, CLDAP, DNS e NTP. |
| Distribuição | O ataque originou-se de aproximadamente 10.000 fontes em 10 países: EUA, China, Coreia do Sul, Rússia, Tailândia, Índia, Vietnã, Irã, Indonésia e Taiwan |
| Alvo | Cliente corporativo da Microsoft Azure na Ásia (não divulgado publicamente) |
| Consequências | Nenhuma; a mitigação automática foi realizada sem intervenção do operador |
| Lição principal | A amplificação multivetorial é a nova norma; a proteção deve ser automatizada |
| Como foi mitigado | Azure DDoS Protection; em seguida, proteção inline via NVA com Gateway Load Balancer |
Caso 3 — Cliente NDA da Cloudflare, setembro de 2024
| Potência do ataque | 3,8 Tbps / 2,14 bilhões de pacotes por segundo |
| Duração | ~65 segundos |
| Vetor | UDP Flood via botnet (roteadores ASUS, DVRs, servidores VPN) |
| Alvo | Cliente da Cloudflare do setor financeiro |
| Consequências | Nenhuma; a mitigação automática foi realizada sem intervenção do operador |
| Lição principal | Os ataques de faixa de terabit se tornaram corriqueiros; a resposta manual é impossível |
| Como foi mitigado | Sistemas automáticos: Anycast + análise comportamental + Flowspec instantâneo |
Caso 4 — DDoS Scrubbing na Europa Ocidental, setembro de 2025
| Potência do ataque | 1,5 bilhão de pacotes/s — um dos maiores em packet rate na história pública |
| Duração | ~65 segundos |
| Vetor | UDP Flood via botnet de dispositivos CPE/IoT; mais de 11.000 redes únicas em todo o mundo |
| Alvo | Site do fornecedor europeu de DDoS scrubbing FastNetMon — tentativa de neutralizar o próprio sistema de proteção |
| Problema | O tráfego para um IP individual estava abaixo dos limiares de alerta, mas o backbone estava saturado |
| Consequências | Nulas para os usuários; o incidente foi divulgado publicamente pela FastNetMon |
| Lição principal | A alta frequência de pacotes UDP pequenos sobrecarrega a CPU dos equipamentos de rede mais do que os ataques volumétricos |
| Como foi mitigado | O FastNetMon Advanced detectou o pico em segundos e automaticamente redirecionou e descartou o tráfego malicioso antes da saturação do canal |
Conclusão
O UDP Flood não é o único, mas é um dos tipos de ataques DDoS mais destrutivos. A natureza sem conexão do protocolo UDP o torna um vetor de ataque ideal: não há necessidade de estabelecer uma conexão, não há proteção integrada contra spoofing, e os mecanismos de amplificação podem transformar os modestos recursos do atacante em terabits de tráfego indesejado.
Os ataques modernos tornaram-se automatizados, multivetoriais e de curta duração — o que exclui a resposta manual e exige sistemas automáticos de detecção e mitigação. Os ataques de carpet bombing, além disso, contornam o monitoramento clássico por limiares. Nessas condições, vence quem construiu uma defesa em profundidade, e não um conjunto de ferramentas isoladas.
Lista de verificação rápida: o que precisa ser feito
- Implementar uRPF (BCP38) em todas as interfaces de borda — essa é a base;
- Configurar telemetria NetFlow/sFlow com análise no nível de AS, não apenas de hosts individuais;
- Fechar os resolvers DNS recursivos abertos e aplicar RRL nos servidores autoritativos;
- Colocar a infraestrutura SIP atrás de um SBC com rate limiting no nível de aplicação;
- Restringir ou fechar UDP/443 (QUIC) onde HTTP/3 não é utilizado;
- Ter procedimentos prontos para RTBH e BGP Flowspec — não configurá-los sob a pressão de um ataque;
- Considerar a implementação de uma plataforma DPI para visibilidade do tráfego no nível de pacote.
