Como identificar DDoS: sinais, medição e passo a passo para provedores
Como identificar DDoS: compare o tráfego de agora com a linha de base da sua borda e procure três marcas juntas, que são subida brusca, destino concentrado e protocolo fora do padrão. A confirmação vem dos fluxos exportados pelo roteador, como NetFlow, sFlow ou IPFIX, que mostram alvo, vetor e tamanho do ataque enquanto ele acontece.
Resumo
- Sem uma linha de base de tráfego por horário, nenhum alarme sabe o que é anormal na sua rede.
- O gráfico da interface só diz que o link lotou; o NetFlow diz quem recebe, de onde vem e por qual porta.
- Ataque por pacotes aparece primeiro na CPU da borda e do CGNAT, antes de aparecer no gráfico de banda.
- Identificar é anotar alvo, vetor, tamanho e porta de entrada, porque são esses dados que escolhem a contenção.
O que significa identificar um DDoS na rede do provedor
Identificar um DDoS é responder com dados a quatro perguntas: qual IP é o alvo, qual é o vetor, qual é o tamanho e por onde o tráfego entra. Perceber que a rede ficou lenta é só o começo; sem essas respostas, qualquer contenção vira tentativa.
Muita equipe descobre o ataque pela fila de reclamações ou pelo gráfico do link encostado no teto. As duas coisas mostram o efeito, mas não a causa: não dizem se é ataque, qual assinante está na mira nem se o tráfego vem por uma operadora ou por todas ao mesmo tempo.
Saber como identificar DDoS exige duas coisas que precisam existir antes do ataque: telemetria ligada na borda e um retrato do que é normal na sua rede em cada horário. As quatro respostas alimentam todas as camadas de proteção DDoS para provedor, do blackhole na operadora à limpeza de tráfego.
Este guia trata da medição e do diagnóstico. A decisão sobre o que fazer com a rede lenta durante o incidente está no guia de ataque DDoS no provedor.
Os tipos de ataque e onde cada um aparece primeiro
Cada tipo de ataque deixa marca num lugar diferente da rede. Saber onde olhar primeiro economiza os minutos em que a equipe fica abrindo gráficos sem direção.
| Tipo | Vetores comuns | Onde aparece primeiro | Métrica que denuncia |
|---|---|---|---|
| Volumétrico | Reflexão UDP por DNS, NTP, CLDAP, SSDP ou Memcached | Interface do link de trânsito | Bits por segundo de entrada |
| Por pacotes | SYN flood, ACK flood, fragmentos UDP | CPU da borda, do CGNAT ou do concentrador | Pacotes por segundo e conexões novas |
| Aplicação | Consultas em massa ao DNS recursivo, requisições ao portal | O servidor atacado | Requisições por segundo e CPU do servidor |
| Espalhado num bloco | Tráfego dividido entre muitos IPs do mesmo prefixo | Soma do prefixo, não um IP isolado | Bytes somados por /24 de destino |
A última linha é a que mais engana. No ataque espalhado, chamado em inglês de carpet bombing, nenhum IP sozinho recebe muito, então a lista dos maiores destinos parece normal enquanto o link lota.
Como identificar DDoS antes do link lotar?
Antes do link lotar, o que denuncia o ataque é a diferença entre o tráfego de agora e o normal daquele horário. Por isso a primeira tarefa é medir a rede em semanas comuns e guardar esse retrato.
A linha de base não é um número único, porque o tráfego de um provedor às 4h da manhã não tem nada a ver com o das 21h. Ela precisa ser montada por faixa de horário e por dia da semana, com estes indicadores:
- Bits por segundo: entrada e saída de cada link de trânsito, de cada IX e de cada cache.
- Pacotes por segundo: nas mesmas interfaces, porque o ataque por pacotes quase não mexe na banda.
- Tamanho médio do pacote: bytes divididos por pacotes, o indicador mais simples de mudança de perfil.
- Maiores destinos: os IPs e prefixos que mais recebem tráfego num horário normal.
- Mistura de protocolos: a fatia de UDP, TCP e ICMP no tráfego que entra.
O tamanho médio do pacote merece atenção especial. Ataques de reflexão mandam respostas UDP grandes e fazem a média subir; um SYN flood manda pacotes mínimos e faz a média despencar, mesmo com a banda parecida com a de sempre.
Alarmes que separam ataque de pico normal
Com a linha de base pronta, os alarmes deixam de ser um limite fixo de banda. O alarme útil compara cada destino e cada protocolo com o histórico do mesmo horário.
- Por destino: um IP passa a receber uma fatia do tráfego muito acima do seu normal. [CONFIRMAR o limiar para a sua base]
- Por prefixo: a soma de um /24 dispara, mesmo sem nenhum IP isolado chamar atenção.
- Por protocolo: a fatia de UDP de entrada cresce de repente, vinda de portas de origem fixas.
- Por pacotes: os pacotes por segundo sobem sem a banda acompanhar, o que aponta para ataque por pacotes.
Esses alarmes dependem da coleta de fluxos. Os guias de implantação de sFlow e de implantação de IPFIX mostram como ligar a exportação sem pesar no roteador.
Como identificar DDoS durante o ataque, passo a passo
Durante o ataque, vá do mais grosso para o mais fino: confirme o gargalo, ache o destino, descubra o vetor e meça o tamanho. Com a telemetria pronta, cada passo cabe em poucos minutos.
- Gargalo: abra juntos o gráfico do link de trânsito e a CPU da borda e do CGNAT, para saber se falta banda, se sobram pacotes ou os dois.
- Destino: ordene os fluxos dos últimos minutos por bytes e por pacotes de destino; o IP ou o prefixo com fatia fora do normal é o alvo.
- Vetor: filtre os fluxos do alvo por protocolo e porta de origem; porta de origem fixa em UDP é sinal de reflexão.
- Entrada: veja por qual operadora ou IX o tráfego chega, porque a contenção vai ser pedida a quem entrega o ataque.
- Tamanho: some bits e pacotes por segundo do vetor e compare com a capacidade do link por onde ele entra.
- Registro: anote início, alvo, vetor, tamanho e porta de entrada num lugar que toda a equipe enxerga.
Os comandos abaixo fazem esses passos num coletor com nfdump, ferramenta de código aberto muito usada para guardar NetFlow e IPFIX. O IP 203.0.113.45 é de documentação e faz o papel do alvo.
# 1. maiores destinos nos últimos 15 minutos, por bytes e por pacotes
nfdump -R /var/cache/nfdump -t 2026/11/03.21:00-2026/11/03.21:15 -s dstip/bytes -n 10
nfdump -R /var/cache/nfdump -t 2026/11/03.21:00-2026/11/03.21:15 -s dstip/packets -n 10
# 2. vetor: protocolo e porta de origem do tráfego que vai para o alvo
nfdump -R /var/cache/nfdump -t 2026/11/03.21:00-2026/11/03.21:15 -s proto/bytes 'dst ip 203.0.113.45'
nfdump -R /var/cache/nfdump -t 2026/11/03.21:00-2026/11/03.21:15 -s srcport/bytes -n 10 'dst ip 203.0.113.45'
# 3. ataque espalhado: soma por prefixo /24 de destino
nfdump -R /var/cache/nfdump -t 2026/11/03.21:00-2026/11/03.21:15 -A dstip4/24 -O bytes -n 10
# 4. maiores origens do ataque (com amostragem 1:N, confira se o coletor já multiplica por N)
nfdump -R /var/cache/nfdump -t 2026/11/03.21:00-2026/11/03.21:15 -s srcip/bytes -n 20 'dst ip 203.0.113.45'A sua borda ainda não mostra o alvo do ataque?
Na proteção DDoS da Táquion Tech, a exportação de fluxos, os alarmes por destino e o roteiro de diagnóstico ficam prontos e testados antes do próximo incidente.
Sem NetFlow, os comandos do próprio roteador
Se a borda ainda não exporta fluxos, o próprio roteador dá uma visão parcial do ataque. No MikroTik, o torch mostra em tempo real quem recebe o tráfego de uma interface.
# banda e pacotes por segundo da interface de trânsito agora
/interface monitor-traffic sfp-sfpplus1 once
# quais destinos recebem o tráfego que entra pelo trânsito
/tool torch interface=sfp-sfpplus1 dst-address=0.0.0.0/0
# protocolo e porta do tráfego que vai para o IP suspeito
/tool torch interface=sfp-sfpplus1 dst-address=203.0.113.45/32 ip-protocol=any port=any
# o que está consumindo a CPU da borda
/tool profile duration=10sO torch também consome CPU, então use por pouco tempo e numa interface por vez. Em roteador já no limite, o guia de roteador de borda com CPU a 100% mostra o que olhar antes.
Exemplo: o que os fluxos mostraram numa terça à noite
Um caso típico de provedor regional mostra como a sequência fecha o diagnóstico. Às 21h, o link de uma das operadoras encosta no limite, e o gráfico da outra continua normal.
- Gargalo: a CPU da borda está tranquila e só a interface de uma operadora lotou, então o problema é banda.
- Destino: a lista dos maiores destinos parece normal, mas a soma por /24 mostra um prefixo do CGNAT muito acima do histórico.
- Vetor: quase tudo é UDP com porta de origem 123, vindo de milhares de servidores NTP diferentes.
- Conclusão: é reflexão por NTP espalhada pelo pool do CGNAT, entrando por uma operadora só, o que pede filtro na operadora e não blackhole de um IP.
Sem a soma por prefixo, a equipe teria procurado um IP alvo que não existia. Sem a porta de entrada, teria ligado para as duas operadoras em vez de uma.
Erros comuns ao identificar um ataque
Os erros de identificação quase sempre vêm de olhar a métrica errada ou de confiar numa medida que esconde o pico. Todos atrasam a contenção, e alguns levam a conter o alvo errado.
Evite
- Confiar na média de cinco minutos do SNMP, que achata ataques curtos de poucos segundos.
- Olhar só os maiores destinos por IP e não perceber o ataque espalhado pelo bloco.
- Ler o sFlow sem considerar a taxa de amostragem e subestimar o tamanho real.
- Monitorar só o IPv4 enquanto o ataque chega pelo IPv6.
- Deixar o relógio do coletor desalinhado do roteador, o que embaralha a linha do tempo.
- Acompanhar só o tráfego de entrada e não ver a própria rede atacando outra.
O relógio parece detalhe até a hora de cruzar o horário do fluxo com o log do CGNAT para achar o assinante. Coletor, borda e concentrador precisam do mesmo servidor de horário, ou a identificação do alvo atrás do NAT vira adivinhação.
Quando o ataque sai da sua rede
Às vezes o provedor não é o alvo, e sim a origem. Roteadores de assinante com DNS, SSDP ou NTP abertos para a internet respondem a pedidos forjados e mandam tráfego de reflexão para fora.
O sinal é a saída de UDP crescer a partir de muitos IPs de assinantes, sempre da mesma porta de origem. Outra pista são as notificações de abuso de outras redes, tratadas na gestão de abuse.
Sua rede está pronta para identificar um DDoS?
Está pronta quando a equipe consegue achar alvo, vetor e porta de entrada sem depender de uma pessoa específica. O checklist abaixo mostra o que falta.
Marque o que a sua borda já tem hoje
- Todos os links de trânsito e de IX exportam fluxos para um coletor.
- Existe uma linha de base de bits, pacotes e destinos por horário.
- Há alarme por destino e por prefixo, não só por banda total.
- O IPv6 é medido do mesmo jeito que o IPv4.
- Coletor, borda e CGNAT usam o mesmo servidor de horário.
- A equipe tem um roteiro escrito com as consultas do passo a passo.
Cada item sem marca é um minuto a mais de link lotado no próximo ataque. Três ou mais itens em branco indicam que a rede ainda descobre ataques pela reclamação do assinante.
A Táquion Tech configura a exportação de fluxos na borda, monta o coletor e os alarmes por destino e treina a equipe no roteiro de diagnóstico. O trabalho de coleta está detalhado na análise de fluxos com NetFlow, e a detecção ligada à contenção automática, na mitigação de DDoS.
O que fazer com o que foi identificado
Cada combinação de alvo, vetor e tamanho aponta para uma contenção diferente. A tabela liga o diagnóstico ao próximo passo, sem entrar na execução de cada um.
| O que o diagnóstico mostrou | Contenção indicada | Onde ler mais |
|---|---|---|
| Um IP de assinante, ataque maior que o link | Blackhole do IP na operadora | Configuração de RTBH |
| Vetor com porta e protocolo fixos | Regra de filtro enviada à operadora | Configuração de FlowSpec |
| IP de infraestrutura, como DNS ou concentrador | Desvio para limpeza de tráfego | Scrubbing de tráfego |
| Ataque menor que o link, CPU da borda alta | Filtro na borda e proteção do roteador | Hardening de roteadores |
A ordem entre esses degraus e o que fazer quando o vetor muda no meio do ataque estão no guia de como mitigar DDoS.
Quando o diagnóstico mostra que o link estava cheio sem alvo nem vetor estranho, o caso não é ataque, e sim capacidade. O guia de link de trânsito saturado trata dessa situação.
Perguntas frequentes
Dá para identificar DDoS só pelo gráfico do Zabbix?
Dá para desconfiar, mas não para identificar. O gráfico de interface mostra que o link lotou, enquanto o alvo, o vetor e a origem só aparecem nos fluxos ou numa captura de pacotes.
Quanto tempo leva para achar o alvo de um ataque?
Com fluxos exportados e um roteiro pronto, a equipe acha o alvo em poucos minutos. Sem coletor, depende de comandos no roteador e da experiência de quem está de turno, e pode levar bem mais. [CONFIRMAR]
Qual a diferença entre NetFlow, sFlow e IPFIX para detectar ataque?
O NetFlow e o IPFIX resumem conversas inteiras, enquanto o sFlow manda amostras de pacotes e é comum em switches. Os três servem para achar o alvo; o que muda é a precisão e o peso no equipamento.
Um pico de UDP sempre indica ataque?
Não. Atualizações de jogos e chamadas de vídeo também usam UDP, mas espalham o tráfego por muitos destinos. O ataque costuma concentrar o destino e repetir a mesma porta de origem.
Como achar o assinante atacado atrás do CGNAT?
Cruze o IP público e a porta que aparecem nos fluxos com o log de sessões do CGNAT no mesmo horário. Por isso o relógio sincronizado e a guarda dos registros de NAT fazem parte da detecção.
Fontes
- RFC 7011, IP Flow Information Export (IPFIX) Protocol: padrão de exportação de fluxos usado para achar alvo e vetor de um ataque.
- CISA, UDP-Based Amplification Attacks: protocolos e portas de origem usados em ataques de reflexão.
- Denial-of-service attack (Wikipédia em inglês): tipos de ataque volumétrico, por protocolo e de aplicação.