Veamos qué ocurre dentro del CG-NAT bajo carga de botnet, por qué sufren los suscriptores comunes y qué herramientas permiten detenerlo.
Cómo una botnet «consume» los recursos del CG-NAT
La mayoría de los operadores utiliza la tecnología CG-NAT (Carrier-Grade NAT). Se trata de una tecnología en la que el operador de telecomunicaciones usa una única dirección IPv4 pública para un grupo de suscriptores de forma simultánea. Los suscriptores reciben direcciones IP privadas y, al acceder a internet, su tráfico pasa por una puerta de enlace compartida donde se traduce a una de las direcciones públicas del operador.
Esto soluciona el problema de escasez de espacio de direcciones, pero al mismo tiempo crea una dependencia: el recurso NAT es finito.
Los operadores generalmente distribuyen los puertos NAT con sobreasignación. A un suscriptor se le pueden asignar hasta 2 000 puertos, mientras que decenas de usuarios comparten simultáneamente la misma IP pública. En teoría esto ofrece cientos de miles de conexiones, pero el límite físico sigue siendo el mismo: alrededor de 64 000 puertos por dirección IP.
Cuando varios suscriptores con dispositivos infectados que comparten la misma dirección pública comienzan a generar miles de sesiones UDP cortas, agotan instantáneamente todo el pool de puertos asignado.
Como resultado, los suscriptores legítimos que utilizan esa misma dirección se ven obligados a competir por puertos con los dispositivos de la botnet y dejan de recibir nuevas conexiones: los navegadores se cuelgan, las llamadas se cortan, el streaming se interrumpe. Mientras tanto, el propio usuario infectado generalmente ni siquiera sabe que su dispositivo está participando en un ataque.
Qué le ocurre al NAT bajo carga de botnet
Además del agotamiento de puertos, los ataques de botnet afectan directamente el rendimiento del CG-NAT. El flood de botnet se convierte en una prueba de estrés para caminos de búsqueda lineal poco evidentes en el código del NAT. Un suscriptor común mantiene en promedio algunas decenas o cientos de conexiones simultáneas. En cambio, un dispositivo infectado crea miles por segundo, con patrones de tráfico fundamentalmente distintos al comportamiento de un usuario normal.
Como resultado, este tráfico:
- llena rápidamente las tablas de traducción;
- satura las colas;
- genera contención de recursos entre hilos.
Si existe aunque sea un único camino de código no optimizado, una botnet muy probablemente lo convertirá en un cuello de botella. El resultado final es la degradación no solo de la disponibilidad, sino del rendimiento de todo el sistema NAT. Por eso, al optimizar el producto CG-NAT, los desarrolladores de VAS Experts tienen en cuenta no solo el comportamiento del tráfico normal, sino también los posibles escenarios de ataque que pueden afectar la estabilidad del sistema en su conjunto.
La principal fuente de botnets: los dispositivos de los suscriptores
El principal vector de infección son los routers domésticos y SOHO que no han recibido actualizaciones de seguridad desde hace mucho tiempo. En abril de 2026, la NSA de EE. UU. instó oficialmente a los usuarios a actualizar el firmware de sus routers, tras registrar una ola de ataques a través de dispositivos desactualizados.
Advertencia de la NSA / FBI (abril de 2026)
La Agencia de Seguridad Nacional de EE. UU. respaldó una advertencia del FBI según la cual grupos de hackers extranjeros atacan deliberadamente routers vulnerables en todo el mundo, incluyendo a través de la vulnerabilidad CVE-2023-50224 en dispositivos TP-Link. Los atacantes explotan routers domésticos mal protegidos para interceptar datos y construir infraestructura de botnet.
Las recomendaciones regulatorias se reducen a una higiene básica: cambiar los nombres de usuario y contraseñas predeterminados, desactivar la administración remota desde internet, instalar el firmware actualizado y reemplazar los dispositivos que ya no cuentan con soporte del fabricante. Sin embargo, en la práctica, la mayoría de los usuarios domésticos no realiza estos pasos por cuenta propia.
Esto significa que el operador debe proteger no solo su propia infraestructura, sino también los dispositivos de los suscriptores; de lo contrario, el daño causado por la botnet se distribuye entre todos.
Listas negras de IP: un problema para toda la base de suscriptores
El segundo efecto crítico de una botnet es que las direcciones IP del operador terminan en listas de bloqueo. Cuando los hosts infectados comienzan a enviar spam, a participar en ataques DDoS o a escanear internet, las IPs públicas del operador quedan registradas en listas negras de servicios como Spamhaus, AbuseIPDB, Cloudflare Radar y otros.
El impacto de una infección de botnet se extiende a todos. Bloquear una única IP pública en una lista de bloqueo afecta instantáneamente a hasta 100 suscriptores «limpios» que están detrás de esa misma dirección NAT. Estos comienzan a recibir rechazos al intentar enviar correos electrónicos, registrarse en sitios web, usar servicios CDN o acceder a almacenamiento en la nube. Las quejas llegan al soporte técnico, pero la fuente del problema está en el suscriptor de al lado.
Como resultado, el problema trasciende un incidente aislado. El operador enfrenta no solo un riesgo técnico, sino también daños a su reputación. Los usuarios perciben las restricciones como una falla del servicio, no como una consecuencia de una infección en la red.
El diagnóstico también se complica. En un entorno CG-NAT, vincular la actividad maliciosa a un suscriptor específico es más difícil, y el proceso de limpiar la reputación de la IP lleva tiempo y requiere coordinación con servicios externos.
Para el operador, esto ya no es un problema de seguridad local, sino un factor que incide directamente en la calidad del servicio y la retención de suscriptores.
Cómo funciona en la práctica: detección y mitigación del UDP flood
A continuación se presenta un ejemplo práctico de detección de actividad de botnet y su neutralización en uno de los operadores clientes de VAS Experts.
Paso 1. Detección del ataque mediante QoE Analytics
En el módulo QoE Analytics, en la ruta QoE Analytics → DDoS Attacks → Top Attacks, se exportaron las estadísticas de las últimas 24 horas. El ordenamiento se configuró por la columna Sessions en orden descendente para identificar de inmediato las direcciones con mayor carga de sesiones.
En una situación normal, la parte superior de la lista es bastante uniforme: los valores pueden diferir, pero sin picos abruptos. Sin embargo, en este caso, en el tope de la lista se destacaba actividad anómala en una dirección interna: 10.248.90.181, con un número de sesiones radicalmente superior a la norma.
Paso 2. Análisis del tráfico y firma del ataque
Se accedió a QoE Analytics → DDoS Attacks Log para examinar exactamente de qué estaba compuesta esa carga. Se mantuvo el mismo período — Last 24 Hours — y se agregó un filtro por Target IP address = 10.248.90.181, ordenando nuevamente por Sessions.
El filtrado del log por la IP de destino 10.248.90.181 reveló un patrón característico:
| Protocolo ~99% del tráfico — UDP (Net protocol: 17) |
Sesiones por registro ~12 000–13 000 por entrada del log |
Paquetes por flujo Mediana 2–4 paquetes (flujos muy cortos) |
| Puerto de destino Casi todo el tráfico apuntando al puerto 41880 |
Puertos del atacante Gran dispersión — típico de una botnet |
Conclusión UDP Flood — ataque DDoS volumétrico desde una botnet |
Casi todo el tráfico resultó ser UDP (Net protocol: 17). TCP estaba prácticamente ausente, por lo que la posibilidad de actividad de usuario ordinaria — navegación web, streaming, mensajería — podía descartarse de inmediato.
Al examinar la estructura de los registros: el log contenía muchas filas, cada una describiendo un flujo corto con un número muy grande de sesiones — aproximadamente 12 000–13 000 sesiones por entrada, pero solo 2–4 paquetes por flujo.
Un gran número de registros (decenas de miles) con pocos paquetes por flujo y un enorme número de sesiones es la firma clásica de una botnet generando sesiones UDP cortas.
Al analizar el destino del tráfico: el informe mostraba un gran número de puertos en la columna Event Object, mientras que casi todas las entradas apuntaban al mismo puerto de destino: 41880. La carga, por tanto, no era aleatoria sino dirigida a un punto específico. La dispersión de puertos en el lado del origen descarta un único origen del ataque y confirma la participación coordinada de múltiples dispositivos infectados.
Un cuadro clásico de UDP Flood, distribuido entre múltiples fuentes.
Paso 3. Mitigación automatizada
El proceso de neutralización se activa automáticamente a través de la siguiente cadena:
- Detector QoE. Detección de anomalía por número de sesiones.
- Lista de IPs atacantes. Se forma el contenedor de Ataques.
- GUI / script. Se asigna el perfil UDP UNKNOWN DROP.
- Despliegue en DPI. Se aplica el bloqueo en los nodos de la red.
- Levantamiento del bloqueo. Una vez al día si no se detectan ataques.
Todo el ciclo — desde la inserción del dump hasta la aplicación del perfil en el DPI — toma unos pocos minutos. Al detectar un ataque, se aplica el perfil UDP UNKNOWN – DROP en el DPI para los suscriptores incluidos en el contenedor. Se bloquea todo el tráfico UDP clasificado como UNKNOWN.
El contenedor se revisa una vez al día. Si durante ese tiempo no se registra actividad repetida, la IP se excluye automáticamente y el bloqueo se levanta de forma automática.
Para el monitoreo en tiempo real, se configuran notificaciones al canal de Telegram ante cada cambio en el contenedor de ataques:
- IP agregada → de forma instantánea al detectarse.
- IP eliminada → una vez al día a medianoche.
Un ingeniero puede verificar el estado actual de los contenedores y bloqueos en la CLI en cualquier momento.
Stingray AntiDDoS — protección de la red del operador contra DDoS y botnets
La plataforma Stingray AntiDDoS detecta y bloquea ataques en tiempo real. El módulo QoE Analytics recopila datos IPFIX Fullflow del Stingray DPI, construye un perfil de referencia del tráfico normal y, mediante algoritmos de redes neuronales, identifica desviaciones, incluyendo actividad de botnet, UDP Flood y SYN Flood.
Al detectar un ataque, el sistema automáticamente:
- forma una lista de IPs atacantes,
- aplica un perfil de bloqueo en el DPI,
- elimina las restricciones tras la normalización del tráfico.
Por qué el operador está obligado a combatir las botnets en su red
En primer lugar, el tráfico de botnet agota directamente el recurso NAT. Un único suscriptor infectado puede ocupar puertos diseñados para decenas de otros usuarios. En segundo lugar, las direcciones IP públicas del operador terminan en listas de bloqueo internacionales, y las restricciones comienzan a afectar a todos los clientes detrás de esa dirección, no solo al origen del problema. En tercer lugar, los dispositivos con firmware desactualizado se reinfectan si no se toman medidas centralizadas.
En estas condiciones, la automatización se vuelve obligatoria. La respuesta manual lleva horas y escala mal. Los escenarios automatizados basados en QoE y DPI permiten detectar anomalías y restringir la actividad maliciosa en minutos, sin que los ingenieros deban intervenir en cada incidente.
