Em ambientes de provedores de internet, datacenters e redes críticas, o tráfego UDP merece atenção especial.
Em comunidades técnicas, muitas das melhores contribuições surgem da troca de experiências entre profissionais que atuam diretamente em ambientes reais de rede.
Este artigo foi desenvolvido a partir de uma contribuição técnica enviada pelo Fabio @fabiolehmkuhl, membro da comunidade Wanguard Brasil, trazendo um exemplo prático de Custom Decoder para classificação de tráfego UDP em portas altas no Wanguard.
A partir dessa contribuição, organizamos o conteúdo, aplicamos ajustes técnicos e adicionamos explicações práticas sobre Flow Syntax, GoBGP, ExaBGP, BPF, DPDK ACL, Netfilter e cuidados operacionais para evitar falsos positivos em ambientes de mitigação DDoS.
Muitos ataques DDoS utilizam UDP por ser um protocolo sem estado, com menor custo para o atacante e alta capacidade de geração de pacotes. Além disso, diversas aplicações legítimas também utilizam UDP em portas altas, como jogos online, aplicações P2P, VPNs, sistemas proprietários e serviços em tempo real.
Por isso, em uma solução de monitoramento e mitigação como o Wanguard, é importante classificar corretamente esse tipo de tráfego.
A lógica principal do decoder é:
Protocolo: UDP
Porta de origem: >= 1024
Porta de destino: >= 1024
Essa classificação ajuda a separar tráfego UDP genérico de um padrão mais específico: UDP com portas altas nos dois lados da comunicação.Objetivo do decoder UDP-ALTA
O decoder UDP-ALTA tem como objetivo identificar tráfego UDP que utiliza portas altas tanto na origem quanto no destino.
Em termos práticos, ele classifica pacotes ou fluxos com o seguinte perfil:
Protocolo: UDP
Porta de origem: 1024 até 65535
Porta de destino: 1024 até 65535
Exemplo de tráfego que casa com esse decoder:Origem: 198.51.100.10:54321
Destino: 203.0.113.20:27015
Protocolo: UDP
Exemplo de tráfego que não casa com esse decoder:
Origem: 198.51.100.10:54321
Destino: 203.0.113.53:53
Protocolo: UDP
No segundo exemplo, a porta de origem é alta, mas a porta de destino é 53, usada normalmente por DNS. Portanto, esse tráfego não atende ao critério do decoder, pois as duas portas precisam estar no intervalo de portas altas.Ajuste importante na descrição
Na tela, a descrição aparece como:
UDP PORTAS ALTAS >1024
Porém, as expressões utilizam ge 1024 e o range 1024-65535.Isso significa que a porta 1024 está incluída.
Por coerência técnica, a descrição recomendada é:
UDP PORTAS ALTAS >=1024
Ou, de forma mais simples:UDP PORTAS ALTAS 1024+
Esse ajuste evita ambiguidade entre >1024 e >=1024.Visão geral da configuração
A configuração principal do decoder é:
Decoder Name: UDP-ALTA
Decoder Description: UDP PORTAS ALTAS >=1024
Included Decoders: IP, UDP
Conflicting Decoders: UDP, IP
Filter Engine: Generic IPv4/IPv6
Essa configuração indica que o decoder é um subconjunto de tráfego IP e UDP, com suporte tanto para IPv4 quanto para IPv6.Flow Syntax
A expressão de Flow é usada quando o Wanguard recebe dados via NetFlow, IPFIX ou sFlow.
Na tela, a expressão aparece como:
proto 17 and src port ge 1024 and dst port ge 1024 and bpp 1052
Explicando cada parte:proto 17
Define que o protocolo é UDP. No cabeçalho IP, o UDP é representado pelo número 17.src port ge 1024
Define que a porta de origem deve ser maior ou igual a 1024.dst port ge 1024
Define que a porta de destino também deve ser maior ou igual a 1024.bpp 1052
Adiciona um critério específico relacionado ao BPP informado nos fluxos. Esse campo torna o decoder mais restritivo.Atenção ao uso de bpp 1052
O uso de:
and bpp 1052
faz com que o decoder não classifique todo UDP em portas altas. Ele passa a classificar somente o tráfego UDP em portas altas que também atenda ao critério de BPP definido.Isso pode ser útil quando existe uma assinatura de ataque muito específica, por exemplo:
Protocolo UDP
Porta origem >= 1024
Porta destino >= 1024
BPP específico observado durante o ataque
Por outro lado, se o objetivo for criar um decoder genérico para UDP em portas altas, a expressão recomendada seria:proto 17 and src port ge 1024 and dst port ge 1024
Portanto, existem dois cenários possíveis:
Decoder UDP-ALTA genérico
proto 17 and src port ge 1024 and dst port ge 1024
Uso recomendado para classificar tráfego UDP em portas altas de forma ampla.Decoder UDP-ALTA com assinatura específica
proto 17 and src port ge 1024 and dst port ge 1024 and bpp 1052
Uso recomendado quando o ataque ou tráfego anômalo apresenta esse padrão específico de BPP.GoBGP Syntax
Na tela, o campo GoBGP está configurado apenas como:
protocol udp
Essa configuração está incompleta para o objetivo do decoder.O problema é que protocol udp sozinho pode corresponder a tráfego UDP de forma ampla, sem restringir as portas altas.
Para manter coerência com a lógica do decoder, a expressão recomendada é:
source-port >=1024 destination-port >=1024 protocol udp
Essa expressão representa:Protocolo UDP
Porta de origem >= 1024
Porta de destino >= 1024
Em ambientes com BGP FlowSpec, isso é importante para evitar que uma mitigação seja aplicada sobre todo tráfego UDP, quando o objetivo é atuar apenas sobre UDP em portas altas.Quanto mais específica for a regra de mitigação, menor o risco de impacto em tráfego legítimo.
ExaBGP Syntax
Na tela, o campo ExaBGP está vazio.
Para manter a mesma lógica do decoder em ambientes que utilizam ExaBGP, a expressão recomendada é:
protocol [17]; source-port [>=1024]; destination-port [>=1024];
Explicação:protocol [17]
Define UDP.source-port [>=1024]
Define porta de origem maior ou igual a 1024.destination-port [>=1024]
Define porta de destino maior ou igual a 1024.Assim como no GoBGP, não é recomendado anunciar apenas protocolo UDP sem restringir as portas, pois isso pode gerar uma regra ampla demais.
BPF Syntax
A expressão BPF é usada em cenários de inspeção de pacotes, como Packet Sensor, Packet Filter, port mirror, TAP, PF_RING ou libpcap.
A expressão correta para este decoder é:
udp && src portrange 1024-65535 && dst portrange 1024-65535
Explicando:udp
Filtra apenas pacotes UDP.src portrange 1024-65535
Filtra pacotes com porta de origem entre 1024 e 65535.dst portrange 1024-65535
Filtra pacotes com porta de destino entre 1024 e 65535.Uma forma prática de validar isso em Linux seria:
tcpdump -ni <interface> 'udp && src portrange 1024-65535 && dst portrange 1024-65535'
Esse teste ajuda a confirmar se o tráfego esperado está chegando na interface monitorada antes de habilitar ações automáticas de mitigação.Correção na BPF Syntax da tela
Na tela, o campo BPF parece conter um trecho adicional semelhante a ACL DPDK no final da linha.
Para BPF, a expressão deve ficar somente assim:
udp && src portrange 1024-65535 && dst portrange 1024-65535
Os campos no formato:17-17 0/0x0 0/0x0 0-65535
pertencem à lógica de ACL DPDK, não à sintaxe BPF.ACL Syntax for IPv4 com DPDK
Quando o Wanguard Filter opera com DPDK, a expressão ACL IPv4 recomendada é:
0.0.0.0/0 0.0.0.0/0 1024-65535 1024-65535 17-17 0/0x0 0/0x0 0-65535
Explicação:| Campo | Valor | Significado |
|---|---|---|
| Rede de origem | 0.0.0.0/0 | Qualquer origem IPv4 |
| Rede de destino | 0.0.0.0/0 | Qualquer destino IPv4 |
| Porta de origem | 1024-65535 | Portas altas de origem |
| Porta de destino | 1024-65535 | Portas altas de destino |
| Protocolo | 17-17 | Apenas UDP |
| Flags/mask | 0/0x0 | Sem filtro específico por flags |
| Flags/mask | 0/0x0 | Sem máscara específica |
| Range final | 0-65535 | Sem restrição adicional nesse campo |
Essa regra não restringe IP de origem ou IP de destino. O critério principal é:
UDP
porta origem >= 1024
porta destino >= 1024
ACL Syntax for IPv6 com DPDK
A versão equivalente para IPv6 é:
::/0 ::/0 1024-65535 1024-65535 17-17 0/0x0 0/0x0 0-65535
Explicação:| Campo | Valor | Significado |
|---|---|---|
| Rede de origem | ::/0 | Qualquer origem IPv6 |
| Rede de destino | ::/0 | Qualquer destino IPv6 |
| Porta de origem | 1024-65535 | Portas altas de origem |
| Porta de destino | 1024-65535 | Portas altas de destino |
| Protocolo | 17-17 | Apenas UDP |
Essa configuração é importante em redes de provedores com IPv6 ativo, pois ataques e anomalias também podem ocorrer sobre IPv6.
Netfilter Expression
Na tela, a expressão Netfilter aparece truncada, iniciando com:
-p udp -m udp --sport 1024:655...
Para manter coerência com o decoder, a expressão recomendada é:-p udp -m udp --sport 1024:65535 --dport 1024:65535
Explicação:-p udp
Filtra apenas protocolo UDP.-m udp
Usa o módulo UDP do iptables.--sport 1024:65535
Filtra porta de origem entre 1024 e 65535.--dport 1024:65535
Filtra porta de destino entre 1024 e 65535.O ponto principal é garantir que a regra tenha as duas condições:
porta de origem alta
E
porta de destino alta
Não é a mesma coisa que filtrar UDP com porta de origem alta ou porta de destino alta. A lógica correta para este decoder exige as duas condições simultaneamente.Included Decoders
IP, UDP
O decoder UDP-ALTA é um subconjunto de UDP, e UDP é um subconjunto de IP.Por isso, faz sentido manter:
IP, UDP
como decoders incluídos.Essa configuração ajuda o Wanguard a organizar corretamente gráficos, relatórios e estatísticas.
Conflicting Decoders
UDP, IP
Como o tráfego UDP-ALTA também pode ser classificado genericamente como UDP, existe sobreposição com decoders mais amplos.O campo Conflicting Decoders ajuda a evitar interpretação incorreta em gráficos empilhados e classificações simultâneas.
Filter Engine
Generic IPv4/IPv6
A opção Generic IPv4/IPv6 é adequada porque o decoder possui expressões para IPv4 e IPv6.Essa escolha permite aplicar a lógica do decoder nas duas pilhas de protocolo, desde que os sensores e filtros estejam configurados corretamente.
Exemplo prático: tráfego que casa com o decoder
Imagine o seguinte fluxo:
Origem: 198.51.100.10:54321
Destino: 203.0.113.20:27015
Protocolo: UDP
Análise:Porta de origem: 54321
Porta de destino: 27015
Ambas são >= 1024
Protocolo: UDP
Resultado:Casa com o decoder UDP-ALTA
Esse tipo de tráfego pode aparecer em jogos online, aplicações P2P, serviços proprietários ou tráfego UDP não padronizado.Exemplo prático: tráfego que não casa com o decoder
Agora veja este fluxo:
Origem: 198.51.100.10:54321
Destino: 203.0.113.53:53
Protocolo: UDP
Análise:Porta de origem: 54321
Porta de destino: 53
Somente a origem é >= 1024
Resultado:Não casa com o decoder UDP-ALTA
Isso é positivo, pois evita classificar tráfego DNS comum como UDP em portas altas nos dois lados.Exemplo de uso em ataque DDoS
Imagine um ataque contra um IP específico:
Destino atacado: 203.0.113.100
Protocolo: UDP
Portas de origem: aleatórias acima de 1024
Portas de destino: aleatórias acima de 1024
Sintoma: aumento anormal de PPS e BPS
Nesse cenário, o decoder UDP-ALTA pode ajudar a separar esse tráfego do UDP convencional.
Uma política de análise poderia considerar:
Decoder = UDP-ALTA
Destino = IP atacado
PPS acima do baseline
BPS acima do baseline
Fluxos por segundo acima do normal
Duração mínima da anomalia
A mitigação poderia ser feita via:BGP FlowSpec
Netfilter
DPDK
Packet Filter
Rate-limit
Discard
Redirect para scrubbing
A ação ideal depende da política da rede, do perfil do cliente protegido e da análise de falso positivo.Atenção ao falso positivo
Portas altas não significam tráfego malicioso.
Muitas aplicações legítimas utilizam UDP em portas altas, principalmente:
Jogos online
Aplicações P2P
VPNs
Sistemas proprietários
Serviços internos
Aplicações em tempo real
Tráfego de mídia
Por isso, o decoder UDP-ALTA não deve ser usado isoladamente como critério único para bloqueio automático.
O ideal é combinar esse decoder com outros indicadores, como:
IP de destino atacado
Volume em bits por segundo
Pacotes por segundo
Fluxos por segundo
ASN de origem
País de origem
Baseline histórico
Threshold por IP Zone
Comportamento do serviço protegido
Mitigação DDoS eficiente não é bloquear o máximo possível. É aplicar a menor regra possível, no ponto correto, com o menor impacto possível no tráfego legítimo.
Validação técnica das expressões
Resumo recomendado para o decoder UDP-ALTA:
Flow Syntax:
proto 17 and src port ge 1024 and dst port ge 1024
Caso o objetivo seja manter a assinatura com BPP específico:
Flow Syntax com BPP:
proto 17 and src port ge 1024 and dst port ge 1024 and bpp 1052
GoBGP Syntax:
source-port >=1024 destination-port >=1024 protocol udp
ExaBGP Syntax:
protocol [17]; source-port [>=1024]; destination-port [>=1024];
BPF Syntax:
udp && src portrange 1024-65535 && dst portrange 1024-65535
ACL IPv4 DPDK:
0.0.0.0/0 0.0.0.0/0 1024-65535 1024-65535 17-17 0/0x0 0/0x0 0-65535
ACL IPv6 DPDK:
::/0 ::/0 1024-65535 1024-65535 17-17 0/0x0 0/0x0 0-65535
Netfilter:
-p udp -m udp --sport 1024:65535 --dport 1024:65535
Principais correções aplicadas
Com base na configuração apresentada, os principais ajustes recomendados são:
1. Ajustar a descrição de >1024 para >=1024 ou 1024+
2. Corrigir GoBGP para incluir source-port e destination-port
3. Preencher ExaBGP com protocolo e portas
4. Corrigir BPF para não conter trecho de ACL DPDK
5. Completar Netfilter com --sport e --dport
6. Validar se o uso de bpp 1052 é realmente necessário
A configuração original já aponta para a ideia correta: classificar UDP em portas altas.
As correções acima deixam o decoder mais coerente entre monitoramento, classificação e mitigação.
Conclusão
O decoder UDP-ALTA é útil para melhorar a visibilidade sobre tráfego UDP em portas altas.
Ele permite separar esse tipo de tráfego do UDP genérico e facilita a análise de anomalias, criação de thresholds específicos e aplicação de mitigações mais direcionadas.
Seu uso pode ser aplicado em ambientes com:
NetFlow
IPFIX
sFlow
Packet Sensor
Packet Filter
DPDK
Netfilter
BGP FlowSpec via GoBGP ou ExaBGP
IPv4 e IPv6
A principal vantagem é aumentar a precisão da classificação.
A principal cautela é evitar bloqueios agressivos sem validação.
Antes de ativar uma mitigação automática baseada nesse decoder, valide o comportamento em modo passivo, confira os gráficos, analise os tops de origem e destino, compare com o baseline e confirme se o tráfego classificado corresponde ao padrão esperado.
Em mitigação DDoS, visibilidade e precisão são fundamentais.
Quanto melhor a classificação, menor o impacto no cliente e maior a eficiência da resposta ao ataque.
Agradecimento
Agradecemos ao Fabio @fabiolehmkuhl, membro da comunidade Wanguard Brasil, pela contribuição técnica que serviu como base para este artigo.
A troca de conhecimento dentro da comunidade fortalece o ecossistema, ajuda outros profissionais a validar configurações em ambientes reais e contribui para a evolução das práticas de monitoramento e mitigação DDoS no Brasil.
Flowspec Solutions
Visibilidade, classificação e mitigação DDoS para ISPs, datacenters e redes críticas.
#DDoS #Wanguard #UDP #BGP #FlowSpec #NetFlow #IPFIX #DPDK #Netfilter #ISP #CyberSecurity #NetworkSecurity #AntiDDoS
