DDoS em ISPs: quando o ataque vem de fora, mas também pode sair de dentro da sua própria rede

Ataques DDoS em provedores de internet não podem mais ser tratados apenas como “muito tráfego contra um IP”. Em redes de ISPs, principalmente em ambientes com CGNAT, PPPoE, IPoE, múltiplos upstreams, IX, CDN, BNG/BRAS e mitigação via BGP Flowspec, a análise precisa ser muito mais profunda.

Um ataque pode estar entrando pela borda da rede.
Pode estar explorando portas específicas.
Pode estar usando pacotes SYN, DNS, fragmentação ou tráfego inválido.
Pode estar mascarado em um padrão aparentemente legítimo.
E, em muitos casos, pode estar saindo da própria rede do provedor por meio de clientes comprometidos atrás do CGNAT.

Esse último ponto é um dos mais perigosos para ISPs.

Quando um cliente infectado, CPE comprometido, roteador com firmware vulnerável, DVR, câmera IP ou equipamento exposto participa de um ataque, o tráfego sai pelo ASN do provedor. Para quem recebe o ataque, a origem pode parecer ser o IP público do provedor. Sem logs CGNAT, Radius Accounting e visibilidade de rede, o provedor fica sem resposta técnica rápida.

Foi exatamente esse tipo de cenário que analisamos em um conjunto recente de eventos DDoS: múltiplas anomalias simultâneas, ataques externos, tráfego SYN, eventos classificados como SSH, DNS, INVALID, FRAGMENT e, principalmente, origens internas CGNAT gerando tráfego agressor.

Por confidencialidade, os destinos atacados não serão expostos neste artigo. O objetivo é demonstrar a importância da visibilidade, da mitigação granular e da operação especializada em redes de provedores.

O erro comum: olhar apenas para o IP atacado

Em muitos ISPs, a análise de DDoS ainda começa com perguntas limitadas:

“Qual IP está sendo atacado?”
“Qual cliente caiu?”
“Vamos aplicar blackhole?”
“Vamos bloquear o destino?”
“Vamos abrir chamado com a operadora?”

Essas perguntas fazem parte do processo, mas não são suficientes.

Uma operação anti-DDoS profissional precisa responder também:

• Quais são os IPs de origem?
• Quais blocos aparecem de forma recorrente?
• Qual porta de origem ou destino está sendo usada?
• O tráfego é TCP, UDP, ICMP ou fragmentado?
• O volume está em bits por segundo ou em pacotes por segundo?
• O ataque está vindo de fora ou saindo de dentro?
• Existe origem CGNAT participando do ataque?
• O tráfego foi mitigado por Packet Filter, Cluster Filter ou BGP Flowspec?
• A regra aplicada foi precisa ou bloqueou tráfego além do necessário?
• O provedor consegue correlacionar a origem CGNAT com o assinante?

Sem essa visão, o provedor pode até conter parte do ataque, mas continua operando no escuro.

O que foi observado na análise

A análise mostrou dois grupos principais de tráfego agressor.

O primeiro grupo envolve origens públicas externas, com concentração em poucos blocos e participação recorrente nos eventos de ataque.

O segundo grupo envolve origens internas CGNAT, indicando tráfego agressor saindo da rede do próprio provedor.

Essa separação é fundamental. Ataques de entrada exigem mitigação para proteger a rede e os clientes. Ataques de saída exigem rastreabilidade, investigação, correlação com assinantes e ações de contenção interna.

Endereços públicos agressores identificados

No tráfego externo, foi observada forte concentração de origens no bloco 45.145.56.0/24, além de recorrência no bloco 195.66.24.0/24.

As principais origens públicas agressoras identificadas foram:

Origem agressora	Observação técnica
45.145.56.2	Origem observada nos eventos FLOW+SYN e SSH
45.145.56.22	Origem recorrente, também observada em ação de FilterCluster
45.145.56.217	Origem recorrente em eventos FLOW+SYN e SSH
45.145.56.218	Origem observada no início do evento
45.145.56.219	Uma das origens de maior destaque, com volume expressivo
45.145.56.220	Origem recorrente nos eventos SYN/SSH
45.145.56.221	Origem recorrente, também observada em FilterCluster
45.145.56.223	Origem recorrente nos eventos SYN/SSH
45.145.56.224	Origem observada com alarme ativo
45.145.56.225	Origem recorrente nos eventos iniciais
45.145.56.226	Origem observada com alarme ativo
45.145.56.227	Origem observada nos eventos SYN/SSH
195.66.24.22	Origem recorrente em eventos FLOW+SYN e SSH
195.66.24.23	Origem recorrente em eventos FLOW+SYN e SSH
195.66.24.24	Origem recorrente com participação relevante em FilterCluster
85.239.149.83	Origem isolada observada durante o evento

Esse comportamento indica uma campanha distribuída com concentração em poucos blocos de origem. Em uma operação anti-DDoS bem estruturada, esse tipo de padrão permite aplicar contenções temporárias por IP de origem, por prefixo ou por assinatura de tráfego, dependendo do risco de falso positivo.

Origens internas CGNAT identificadas

Além das origens públicas externas, foram identificadas origens internas CGNAT participando de tráfego agressor. Esse ponto é extremamente sensível para provedores, pois indica que clientes internos podem estar originando ataques para fora da rede.

As principais origens CGNAT observadas foram:

Origem CGNAT	Severidade operacional	Protocolos/portas observados
100.64.11.191	Crítica	UDP, TCP, regras genéricas e tráfego UDP/65535
100.64.16.151	Alta	UDP, TCP, regras genéricas e tráfego UDP/65535
100.64.25.79	Alta	UDP, TCP, regras genéricas e tráfego UDP/65535
100.64.13.117	Alta	UDP/65535 e UDP/80
100.64.15.9	Média	UDP e TCP
100.64.11.53	Média	UDP

O endereço 100.64.11.191 foi o caso mais expressivo, com grande quantidade de regras BGP Flowspec geradas ao longo do período analisado. Também houve recorrência em 100.64.16.151, 100.64.25.79 e 100.64.13.117, com padrões associados principalmente a UDP e porta de destino 65535.

Em uma rede com CGNAT, esses IPs não identificam diretamente o assinante final. Eles precisam ser correlacionados com logs de sessão, NAT, Radius, PPPoE/IPoE, porta de atendimento, ONT, OLT e horário exato do evento.

Portas e protocolos observados

As portas e protocolos mais relevantes foram:

Porta / protocolo	Tipo	Interpretação
TCP/22	Porta de origem	Tráfego classificado como SSH, associado a SYN em alto volume
UDP/53	Porta de destino	Vetor DNS
UDP/65535	Porta de destino	Principal assinatura observada em ataques originados por CGNAT
UDP/80	Porta de destino	Observada pontualmente em origem CGNAT
Protocol 17	UDP	Protocolo mais recorrente nas regras Flowspec internas
Protocol 6	TCP	Também observado em algumas regras Flowspec

A recorrência de UDP/65535 é um ponto técnico importante. Essa porta apareceu como assinatura clara em diferentes origens CGNAT, o que permite aplicar políticas de contenção mais precisas.

Em vez de bloquear todo o tráfego do cliente, a mitigação pode ser aplicada de forma seletiva:

• origem específica;
• protocolo UDP;
• porta de destino 65535;
• ação de descarte;
• tempo de expiração;
• automação via BGP Flowspec;
• posterior correlação com o assinante.

Essa abordagem reduz impacto colateral e evita interrupções desnecessárias em tráfego legítimo.

Por que o ataque classificado como SSH precisa ser bem interpretado

Um dos eventos observados foi classificado como SSH, com referência à porta TCP/22. Em análises DDoS, isso precisa ser interpretado com cuidado.

Nem sempre um evento classificado como SSH significa que o destino estava sendo atacado na porta 22. Em muitos cenários, a classificação pode estar associada à porta de origem ou à assinatura do fluxo.

Ataques SYN podem usar portas conhecidas como origem para tentar burlar filtros simples, gerar confusão na classificação ou simular tráfego legítimo. Por isso, uma análise correta precisa olhar o fluxo completo:

• IP de origem;
• IP de destino;
• porta de origem;
• porta de destino;
• flags TCP;
• volume em pps;
• distribuição temporal;
• recorrência da origem;
• ação aplicada pelo filtro.

Essa é a diferença entre olhar um alarme e fazer uma análise técnica de verdade.

BGP Flowspec como ferramenta de mitigação granular

BGP Flowspec é uma das ferramentas mais importantes para mitigação DDoS em redes de provedores.

Diferente do blackhole tradicional, que normalmente remove todo o tráfego para um destino, o Flowspec permite instalar regras específicas diretamente na infraestrutura de roteamento.

Uma regra Flowspec pode considerar:

• IP de origem;
• IP de destino;
• protocolo;
• porta de origem;
• porta de destino;
• TCP flags;
• fragmentação;
• ICMP type/code;
• ação de descarte;
• rate-limit;
• redirect;
• marcação de tráfego.

Na prática, isso permite mitigar o vetor malicioso com muito mais precisão.

Exemplo conceitual de ação possível:

• descartar tráfego UDP para porta 65535 originado de um cliente CGNAT específico;
• bloquear SYN com assinatura específica vindo de um bloco agressor;
• aplicar descarte por origem reincidente;
• manter o tráfego legítimo passando;
• expirar a regra automaticamente após o evento.

Essa granularidade é essencial em ISPs, porque um bloqueio amplo demais pode gerar indisponibilidade para clientes que não têm relação com o ataque.

O risco operacional do CGNAT em ataques de saída

O CGNAT resolve um problema de escassez de IPv4, mas cria um desafio enorme para segurança, rastreabilidade e resposta a incidentes.

Quando um ataque sai de um IP público compartilhado, a denúncia de abuse normalmente chega apontando o IP público do provedor. Mas internamente, dezenas, centenas ou milhares de assinantes podem estar usando aquele mesmo IP público em janelas diferentes ou até simultaneamente, diferenciados apenas por portas NAT.

Sem registros adequados, o provedor não consegue responder perguntas críticas:

• Qual cliente estava atrás daquele IP no horário do ataque?
• Qual porta NAT foi usada?
• Qual sessão PPPoE ou IPoE estava ativa?
• Qual CPE originou o tráfego?
• Qual ONT ou porta PON estava envolvida?
• O cliente é reincidente?
• O equipamento está comprometido?
• Deve haver bloqueio, quarentena ou notificação?

Por isso, uma operação anti-DDoS profissional precisa integrar detecção de tráfego com rastreabilidade interna.

Não basta bloquear o ataque.
É necessário identificar quem gerou o tráfego.

Por que apenas firewall manual não resolve

Muitos provedores ainda tentam lidar com DDoS usando apenas regras manuais de firewall.

Isso pode funcionar em incidentes pequenos, mas falha rapidamente em cenários reais.

Os principais problemas são:

• demora na resposta;
• alta chance de erro humano;
• ausência de baseline;
• dificuldade de identificar portas e protocolos dominantes;
• baixa visibilidade por origem;
• ausência de correlação com CGNAT;
• falta de automação;
• incapacidade de gerar evidência técnica pós-incidente;
• risco de bloquear tráfego legítimo;
• dificuldade de responder abuse com precisão.

Ataques DDoS modernos mudam de vetor rapidamente. Enquanto a equipe analisa manualmente, o ataque já pode ter saturado CPU, tabela de estado, uplink, sessão PPPoE, BNG, firewall ou appliance.

Mitigação DDoS precisa ser operacionalizada com sensores, thresholds, automação e engenharia de rede.

Arquitetura recomendada para ISPs

Uma arquitetura anti-DDoS eficiente para provedores deve combinar várias camadas:

1. Coleta de tráfego

• NetFlow;
• sFlow;
• IPFIX;
• Port Mirror quando necessário;
• sensores por borda, trânsito, IX, CDN e pontos críticos.

2. Detecção

• análise por baseline;
• thresholds por perfil de cliente;
• thresholds por ASN;
• detecção por protocolo;
• detecção por porta;
• anomalias por pps e bps;
• classificação por vetor.

3. Mitigação

• BGP Flowspec;
• RTBH quando necessário;
• Packet Filter;
• Cluster Filter;
• filtros locais;
• integração com roteadores de borda;
• ações automáticas e manuais controladas.

4. Correlação

• logs CGNAT;
• Radius Accounting;
• PPPoE/IPoE;
• Option 82;
• MAC address;
• ONT/OLT;
• BNG/BRAS;
• registros de sessão;
• logs de NAT por porta.

5. Operação

• SOC/NOC acompanhando eventos;
• dashboards técnicos;
• alertas por severidade;
• relatórios pós-incidente;
• resposta a abuse;
• ajuste contínuo de thresholds;
• redução de falso positivo;
• processos de quarentena para clientes comprometidos.

Essa combinação permite que o provedor deixe de agir de forma reativa e passe a operar com visibilidade e controle.

O papel da Flowspec Solutions

A Flowspec Solutions atua justamente nesse ponto: transformar tráfego bruto em decisão operacional.

Em uma análise DDoS, não basta saber que “houve ataque”. É necessário saber:

• qual foi o vetor;
• qual porta foi explorada;
• qual protocolo predominou;
• quais origens participaram;
• quais origens foram reincidentes;
• se o ataque veio de fora ou saiu de dentro;
• quais clientes CGNAT precisam ser investigados;
• qual regra foi aplicada;
• se a mitigação foi efetiva;
• se houve risco de falso positivo;
• se há evidência suficiente para resposta a abuse.

Nosso trabalho envolve implantação, operação e suporte de ambientes anti-DDoS para ISPs, incluindo:

• Wanguard;
• NetFlow, sFlow e IPFIX;
• BGP Flowspec;
• Packet Filter;
• Cluster Filter;
• mitigação local;
• análise de ataques reais;
• relatórios técnicos;
• dashboards operacionais;
• integração com Grafana e bases de dados;
• resposta a abuse;
• correlação com CGNAT;
• suporte NOC/SOC;
• tuning de thresholds;
• automação de ações de mitigação.

O objetivo não é apenas “bloquear ataque”. O objetivo é manter o provedor operando, proteger os clientes, reduzir impacto, preservar tráfego legítimo e entregar rastreabilidade técnica.

Mitigação local: controle dentro da própria rede

Muitos ISPs dependem apenas de scrubbing externo ou blackhole remoto. Essas alternativas têm seu lugar, principalmente em ataques volumétricos muito grandes, mas não substituem uma operação local bem estruturada.

A mitigação local permite agir dentro da própria rede do provedor, com maior controle e menor tempo de resposta.

Com uma arquitetura correta, o ISP consegue:

• detectar ataques em segundos;
• aplicar regras Flowspec automaticamente;
• bloquear vetores específicos;
• conter origens públicas agressoras;
• identificar clientes internos comprometidos;
• reduzir impacto sobre clientes legítimos;
• gerar evidência para abuse;
• ajustar thresholds conforme o perfil da rede;
• manter histórico técnico dos incidentes;
• evoluir a postura de segurança da operação.

Em muitos casos, o diferencial não está apenas na ferramenta, mas em quem opera, interpreta e ajusta o ambiente.

DDoS não é apenas volume

Um erro comum é medir a gravidade de um DDoS apenas em Gbps.

Em redes reais, principalmente em ISPs, um ataque de menor volume em bits pode causar grande impacto se vier com alto volume de pacotes por segundo, fragmentação, SYN flood, tráfego inválido ou exploração de caminho crítico.

Por isso, a análise precisa considerar:

• pacotes por segundo;
• bits por segundo;
• distribuição de origem;
• distribuição de portas;
• protocolos envolvidos;
• flags TCP;
• fragmentação;
• reincidência;
• comportamento por ASN;
• impacto em roteadores, firewalls e BNGs;
• efetividade da ação aplicada.

DDoS é um problema de engenharia de rede, operação e segurança. Não é apenas um gráfico alto.

A importância da resposta pós-incidente

Depois que o ataque termina, o trabalho ainda não acabou.

Uma operação madura precisa gerar um relatório técnico com:

• horário de início;
• horário de término;
• vetores identificados;
• portas envolvidas;
• protocolos;
• origens agressoras;
• ações aplicadas;
• regras Flowspec;
• impacto observado;
• reincidência;
• recomendações;
• evidências para abuse;
• lista de clientes internos a investigar, quando houver CGNAT.

Esse relatório permite que o provedor aprenda com o incidente e melhore sua postura de segurança.

Sem relatório, cada ataque vira apenas mais um susto.

Com relatório, o ataque vira inteligência operacional.

Conclusão

O caso analisado mostra uma realidade cada vez mais comum em ISPs: o ataque pode vir de fora, mas também pode sair de dentro.

Foram observadas origens públicas agressoras concentradas principalmente nos blocos 45.145.56.0/24 e 195.66.24.0/24, além de origens internas CGNAT como 100.64.11.191, 100.64.16.151, 100.64.25.79, 100.64.13.117, 100.64.15.9 e 100.64.11.53.

As portas e protocolos mais relevantes foram TCP/22, UDP/53, UDP/65535, UDP/80, protocol 17 e protocol 6.

O destaque técnico fica para o uso recorrente de UDP/65535 em tráfego originado por CGNAT, mostrando a importância de filtros granulares, correlação com assinantes e automação via BGP Flowspec.

Para provedores, a lição é clara: não basta ter link, roteador e firewall. É necessário ter visibilidade, mitigação, automação e operação especializada.

A Flowspec Solutions ajuda ISPs a implantar e operar ambientes anti-DDoS com foco em mitigação local, BGP Flowspec, NetFlow, Wanguard, análise de ataques, resposta a abuse e suporte técnico durante incidentes reais.

DDoS não se resolve apenas bloqueando tráfego.

DDoS se resolve com engenharia, visibilidade, automação e operação especializada.