Vamos examinar o que acontece dentro do CG-NAT sob carga de botnet, por que os assinantes comuns sofrem com isso e quais ferramentas permitem detê-lo.
Como uma botnet “consome” os recursos do CG-NAT
A maioria das operadoras utiliza a tecnologia CG-NAT (Carrier-Grade NAT). Trata-se de uma tecnologia em que a operadora de telecomunicações usa um único endereço IPv4 público para um grupo de assinantes simultaneamente. Os assinantes recebem endereços IP privados e, ao acessar a internet, seu tráfego passa por um gateway compartilhado onde é traduzido para um dos endereços públicos da operadora.
Isso resolve o problema da escassez de espaço de endereçamento, mas ao mesmo tempo cria uma dependência: o recurso NAT é finito.
As operadoras geralmente distribuem as portas NAT com sobreassinatura. A um único assinante podem ser atribuídas até 2.000 portas, enquanto dezenas de usuários compartilham simultaneamente o mesmo IP público. Em teoria, isso oferece centenas de milhares de conexões, mas o limite físico permanece o mesmo: cerca de 64.000 portas por endereço IP.
Quando vários assinantes com dispositivos infectados que compartilham o mesmo endereço público começam a gerar milhares de sessões UDP curtas, eles esgotam instantaneamente todo o pool de portas alocado.
Como resultado, assinantes legítimos que utilizam esse mesmo endereço são forçados a competir com os dispositivos da botnet pelas portas e deixam de receber novas conexões: os navegadores travam, as chamadas caem, o streaming é interrompido. Enquanto isso, o próprio usuário infectado muitas vezes nem sabe que seu dispositivo está participando de um ataque.
O que acontece com o NAT sob carga de botnet
Além do esgotamento de portas, os ataques de botnet impactam diretamente o desempenho do CG-NAT. O flood de botnet se torna um teste de estresse para caminhos de busca linear pouco evidentes no código do NAT. Um assinante comum mantém em média algumas dezenas ou centenas de conexões simultâneas. Já um dispositivo infectado cria milhares por segundo, com padrões de tráfego fundamentalmente diferentes do comportamento de um usuário normal.
Como resultado, esse tráfego:
- preenche rapidamente as tabelas de tradução;
- sobrecarrega as filas;
- cria contenção de recursos entre threads.
Se houver mesmo um único caminho de código não otimizado, uma botnet muito provavelmente o tornará um gargalo. O resultado final é a degradação não apenas da disponibilidade, mas do desempenho de todo o sistema NAT. Por isso, ao otimizar o produto CG-NAT, os desenvolvedores da VAS Experts levam em conta não apenas o comportamento do tráfego normal, mas também os possíveis cenários de ataque que podem afetar a estabilidade do sistema como um todo.
A principal fonte de botnets: os dispositivos dos assinantes
O principal vetor de infecção são os roteadores domésticos e SOHO que não recebem atualizações de segurança há muito tempo. Em abril de 2026, a NSA dos EUA instou oficialmente os usuários a atualizarem o firmware de seus roteadores, tendo registrado uma onda de ataques por meio de dispositivos desatualizados.
Aviso da NSA / FBI (abril de 2026)
A Agência de Segurança Nacional dos EUA apoiou um aviso do FBI informando que grupos de hackers estrangeiros atacam deliberadamente roteadores vulneráveis ao redor do mundo, inclusive por meio da vulnerabilidade CVE-2023-50224 em dispositivos TP-Link. Os invasores exploram roteadores domésticos com baixa proteção para interceptar dados e construir infraestrutura de botnet.
As recomendações dos órgãos reguladores se resumem a uma higiene básica: alterar os logins e senhas padrão, desabilitar o gerenciamento remoto a partir da internet, instalar o firmware atualizado e substituir os dispositivos que não contam mais com suporte do fabricante. Na prática, porém, a maioria dos usuários domésticos não realiza essas etapas por conta própria.
Isso significa que a operadora precisa proteger não apenas sua própria infraestrutura, mas também os dispositivos dos assinantes — caso contrário, o dano causado pela botnet é distribuído por todos.
Listas negras de IP: um problema para toda a base de assinantes
O segundo efeito crítico de uma botnet é a inclusão dos endereços IP da operadora em listas de bloqueio. Quando os hosts infectados começam a enviar spam, participar de ataques DDoS ou varrer a internet, os IPs públicos da operadora são registrados em listas negras de serviços como Spamhaus, AbuseIPDB, Cloudflare Radar e outros.
O impacto de uma infecção de botnet se estende a todos. O bloqueio de um único IP público em uma lista de bloqueio afeta instantaneamente até 100 assinantes “limpos” que estão atrás do mesmo endereço NAT. Eles passam a receber rejeições ao tentar enviar e-mails, se cadastrar em sites, usar serviços CDN ou acessar armazenamentos na nuvem. As reclamações chegam ao suporte técnico, mas a fonte do problema está no assinante vizinho.
Como resultado, o problema vai além de um incidente isolado. A operadora enfrenta não apenas um risco técnico, mas também perdas de reputação. Os usuários percebem as restrições como uma falha no serviço, e não como consequência de uma infecção na rede.
O diagnóstico também se torna mais complexo. Em um ambiente CG-NAT, vincular a atividade maliciosa a um assinante específico é mais difícil, e o processo de limpeza da reputação do IP leva tempo e requer interação com serviços externos.
Para a operadora, isso já não é um problema local de segurança, mas um fator que afeta diretamente a qualidade do serviço e a retenção de assinantes.
Como funciona na prática: detecção e mitigação do UDP flood
A seguir, apresentamos um exemplo prático de detecção de atividade de botnet e sua neutralização em uma das operadoras clientes da VAS Experts.
Passo 1. Detecção do ataque via QoE Analytics
No módulo QoE Analytics, no caminho QoE Analytics → DDoS Attacks → Top Attacks, foram exportadas as estatísticas das últimas 24 horas. A ordenação foi configurada pela coluna Sessions em ordem decrescente para identificar imediatamente as direções com maior carga de sessões.
Em uma situação normal, o topo da lista é bastante uniforme: os valores podem diferir, mas sem picos abruptos. No entanto, neste caso, o topo da lista exibia atividade anômala em um endereço interno — 10.248.90.181 — com um número de sessões radicalmente acima da norma.
Passo 2. Análise do tráfego e assinatura do ataque
O próximo passo foi acessar QoE Analytics → DDoS Attacks Log para examinar exatamente o que compunha essa carga. O período foi mantido em Last 24 Hours, foi adicionado um filtro por Target IP address = 10.248.90.181 e a ordenação por Sessions foi aplicada novamente.
A filtragem do log pelo endereço IP de destino 10.248.90.181 revelou um padrão característico:
| Protocolo ~99% do tráfego — UDP (Net protocol: 17) |
Sessões por registro ~12.000–13.000 por entrada do log |
Pacotes por fluxo Mediana 2–4 pacotes (fluxos muito curtos) |
| Porta de destino Quase todo o tráfego mirando a porta 41880 |
Portas do atacante Grande dispersão — típico de botnet |
Conclusão UDP Flood — ataque DDoS volumétrico proveniente de botnet |
Quase todo o tráfego se revelou UDP (Net protocol: 17). O TCP estava praticamente ausente, de modo que a possibilidade de atividade comum de usuário — navegação web, streaming, mensagens — podia ser descartada imediatamente.
Ao examinar a estrutura dos registros: o log continha muitas linhas, cada uma descrevendo um fluxo curto com um número muito grande de sessões — aproximadamente 12.000–13.000 sessões por entrada, mas apenas 2 a 4 pacotes por fluxo.
Um grande número de registros (dezenas de milhares) com poucos pacotes por fluxo e um número enorme de sessões é a assinatura clássica de uma botnet gerando sessões UDP curtas.
Ao analisar o destino do tráfego: o relatório exibia um grande número de portas na coluna Event Object, enquanto quase todas as entradas apontavam para a mesma porta de destino — 41880. A carga, portanto, não era aleatória, mas direcionada a um ponto específico. A dispersão das portas no lado da origem exclui uma única fonte de ataque e confirma a participação coordenada de múltiplos dispositivos infectados.
Um quadro clássico de UDP Flood, distribuído por múltiplas fontes.
Passo 3. Mitigação automatizada
O processo de neutralização é acionado automaticamente pela seguinte cadeia:
- Detector QoE. Detecção de anomalia por número de sessões.
- Lista de IPs atacantes. Formação do contêiner de Ataques.
- Interface gráfica / script. Atribuição do perfil UDP UNKNOWN DROP.
- Implantação no DPI. Aplicação do bloqueio nos nós da rede.
- Remoção do bloqueio. Uma vez por dia na ausência de ataques.
Todo o ciclo — da inserção do dump à aplicação do perfil no DPI — leva alguns minutos. Ao detectar um ataque, o perfil UDP UNKNOWN – DROP é aplicado no DPI para os assinantes incluídos no contêiner. Todo o tráfego UDP classificado como UNKNOWN é bloqueado.
O contêiner é revisado uma vez por dia. Se nenhuma atividade repetida for registrada durante esse período, o IP é automaticamente removido e o bloqueio é levantado de forma automática.
Para monitoramento em tempo real, são configuradas notificações para um canal do Telegram a cada alteração no contêiner de ataques:
- IP adicionado → imediatamente ao ser detectado.
- IP removido → uma vez por dia à meia-noite.
Um engenheiro pode verificar o estado atual dos contêineres e bloqueios na CLI a qualquer momento.
Stingray AntiDDoS — proteção da rede da operadora contra DDoS e botnets
A plataforma Stingray AntiDDoS detecta e bloqueia ataques em tempo real. O módulo QoE Analytics coleta dados IPFIX Fullflow do Stingray DPI, constrói um perfil de referência do tráfego normal e, por meio de algoritmos de redes neurais, identifica desvios — incluindo atividade de botnet, UDP Flood e SYN Flood.
Ao detectar um ataque, o sistema automaticamente:
- forma uma lista de IPs atacantes,
- aplica um perfil de bloqueio no DPI,
- remove as restrições após a normalização do tráfego.
Por que a operadora é obrigada a combater botnets em sua própria rede
Em primeiro lugar, o tráfego de botnet esgota diretamente o recurso NAT. Um único assinante infectado pode ocupar portas destinadas a dezenas de outros usuários. Em segundo lugar, os endereços IP públicos da operadora acabam em listas de bloqueio internacionais, e as restrições passam a afetar todos os clientes atrás desse endereço, não apenas a fonte do problema. Em terceiro lugar, dispositivos com firmware desatualizado são reinfectados caso nenhuma medida centralizada seja adotada.
Nessas condições, a automação se torna obrigatória. A resposta manual leva horas e escala mal. Os cenários automatizados baseados em QoE e DPI permitem detectar anomalias e restringir a atividade maliciosa em minutos, sem exigir a participação dos engenheiros em cada incidente.
