Botnets en la red del suscriptor: cuando el DDoS viene de adentro
La defensa anti-DDoS en ISPs está diseñada, históricamente, para ataques que vienen de afuera: tráfico de origen externo que satura un enlace, abruma un servidor, o agota las sesiones de un firewall. El modelo mental es el de una muralla: protegemos el interior del exterior.
Pero hay una clase de ataques que ese modelo no contempla bien: los que se originan dentro de la propia red del ISP, desde los dispositivos de los suscriptores.
Las botnets modernas reclutan dispositivos domésticos —set-top boxes Android, routers hogareños, cámaras IP, televisores inteligentes— que una vez comprometidos actúan como agentes de ataque desde adentro de la red. Para un ISP, el problema no es solo que sus clientes participen involuntariamente en ataques a terceros: es que ese tráfico malicioso puede saturar segmentos de la red interna, degradar la experiencia de otros suscriptores, y generar costos operativos significativos.
Cómo un dispositivo del suscriptor se convierte en bot
El vector de infección más común en dispositivos domésticos no es un exploit sofisticado. Son dos mecanismos simples y masivos:
1. Credenciales por defecto nunca cambiadas
La mayoría de los routers domésticos y dispositivos IoT se envían con credenciales de administración por defecto (admin/admin, admin/1234, o variantes similares). Si ese dispositivo tiene la interfaz de administración expuesta a internet —algo que ocurre cuando el ISP no filtra los puertos de administración en la red de acceso— cualquier scanner automatizado puede comprometer el dispositivo en minutos.
2. Puertos de debug o gestión expuestos
Muchos set-top boxes Android y dispositivos de bajo costo del mercado tienen habilitado por defecto el Android Debug Bridge (ADB) en el puerto TCP 5555. ADB fue diseñado para desarrollo y debugging, no para producción. Un dispositivo con ADB expuesto permite que un atacante remoto ejecute comandos arbitrarios sin autenticación. Esto es suficiente para instalar agentes de botnet, modificar configuraciones, o establecer túneles de tráfico a través del dispositivo.
3. SDKs de proxy residencial embebidos
Una categoría menos conocida pero creciente: algunos dispositivos de bajo costo (especialmente en el segmento de IPTV y streaming) incluyen SDKs de terceros que monetizan el dispositivo convirtiendo su conexión a internet en un proxy residencial que se vende a clientes del mercado de proxies. El usuario del dispositivo no sabe que su conexión está siendo vendida. El fabricante recibe un pago por incluir el SDK.
Desde la perspectiva del ISP, el tráfico generado por estos SDKs es indistinguible del tráfico legítimo en la capa de inspección superficial, lo que lo hace difícil de detectar con reglas estáticas.
El impacto en la red del ISP
Cuando una fracción de los suscriptores tiene dispositivos comprometidos y actúan como bots, los efectos sobre la red son concretos:
Congestión en la red de acceso: El tráfico de ataque se genera distribuido por todos los segmentos donde hay suscriptores infectados. En redes PON y DOCSIS, esto puede generar congestión asimétrica en el uplink (los ataques son mayoritariamente outbound), degradando la experiencia de todos los suscriptores del mismo segmento, no solo de los infectados.
Aumento de tráfico inter-AS inesperado: Si los bots están siendo usados para proxying o para ataques volumétricos, el ISP verá un incremento sostenido en tráfico de salida que puede impactar en los costos de tránsito y en los acuerdos de peering.
Tickets de soporte difíciles de resolver: Un suscriptor cuyo router está comprometido puede experimentar lentitud, cortes esporádicos, y comportamientos extraños que no tienen una causa obvia en la capa física. El técnico de soporte que no está mirando el tráfico del dispositivo no puede diagnosticarlo correctamente.
Reputación de IP: Los bloques IPv4 del ISP pueden terminar en listas negras (SpamRaus, Spamhaus, SORBS) si los dispositivos comprometidos participan en campañas de spam o escaneo masivo. Esto afecta a todos los clientes del ISP, incluyendo los que no tienen dispositivos infectados.
Responsabilidad legal: En países donde la regulación exige que el ISP tome medidas para prevenir el uso de su red para ataques (Brasil tiene normativas específicas de ANATEL, Argentina tiene resoluciones de ENACOM), la inacción ante botnets conocidas puede tener consecuencias regulatorias.
Detección: qué buscar en tu red
La detección de actividad de botnet en la red de suscriptores no requiere DPI (Deep Packet Inspection) completo. Hay señales más simples y de menor costo que ya indican el problema:
NetFlow / sFlow anómalos: Un suscriptor residencial normal no genera miles de flujos distintos por minuto hacia IPs externas aleatorias. El análisis de NetFlow con umbrales de número de destinos únicos por suscriptor es una forma de detectar escaneo masivo o DDoS distribuido.
Puertos conocidos de botnet/C2: Las botnets IoT más comunes usan puertos específicos para comunicación con el servidor de comando y control (C2). Filtros en el perímetro que detecten tráfico a destinos conocidos de C2 (usando feeds de threat intelligence como Emerging Threats, Spamhaus, o fuentes comerciales) pueden identificar dispositivos infectados.
ADB expuesto: Un scan periódico de la red de suscriptores buscando el puerto TCP 5555 abierto identifica todos los dispositivos con ADB habilitado. Este es un indicador de alto riesgo aunque el dispositivo no esté aún comprometido.
Volumen de tráfico asimétrico: Ratios de subida/bajada muy fuera de lo normal en un suscriptor (ej: un cliente residencial que sube 10x lo que baja durante horas) es una señal de actividad de botnet o proxying.
Anomalías en DNS: Los bots frecuentemente realizan consultas DNS a dominios generados algorítmicamente (DGA — Domain Generation Algorithms) que tienen patrones reconocibles. Un resolver con logging de consultas puede identificar estos patrones.
Mitigación: qué puede hacer el ISP
El ISP tiene herramientas que el suscriptor no tiene para mitigar este problema:
Bloquear puertos de administración en la red de acceso
El puerto TCP 5555 (ADB), 23 (Telnet), 2323 (Telnet alternativo), y 7547 (TR-069/CWMP expuesto sin autenticación) no deberían ser accesibles desde internet hacia los dispositivos de los suscriptores. Una ACL en el borde de la red de acceso que filtre tráfico entrante a estos puertos reduce masivamente la superficie de ataque.
! Ejemplo: bloquear tráfico entrante a puertos de administración de dispositivos CPE
! (aplicar en interfaz hacia internet/uplink, sentido entrante)
ip access-list extended BLOQUEO-PUERTOS-ADMIN-CPE
deny tcp any any eq 23
deny tcp any any eq 2323
deny tcp any any eq 5555
deny tcp any any eq 7547
permit ip any any
Notificación activa a suscriptores comprometidos
Cuando se detecta actividad de botnet desde un suscriptor, notificarlo proactivamente tiene dos efectos: ayuda al cliente a resolver el problema (lo que reduce tickets de soporte) y demuestra una política activa de seguridad que protege al ISP legalmente.
Los mecanismos van desde un email hasta un portal cautivo que muestra el aviso cuando el suscriptor intenta navegar (técnica usada por ISPs en Europa y Estados Unidos).
Sinkholing de C2 conocidos
Un resolver DNS interno que redirige dominios de C2 conocidos (usando feeds de threat intelligence actualizados) a una IP controlada por el ISP interrumpe la comunicación entre los bots y el atacante. Los dispositivos infectados quedan aislados del C2 sin necesidad de contactar al suscriptor.
Rate limiting de escaneo y flood
En el BRAS o equipo de aggregación, implementar rate limiting en el uplink por suscriptor para tráfico que coincida con patrones de flood (alta tasa de SYN, ICMP flood, UDP flood hacia destinos múltiples) limita el impacto que un suscriptor comprometido puede tener sobre el resto de la red.
Uso de feeds de threat intelligence
La comunidad de seguridad publica listas actualizadas de IPs, dominios, y rangos asociados a infraestructura de botnets. CAIDA, Shadowserver, Team Cymru, y Spamhaus son fuentes de alta calidad y bajo costo. Integrar estos feeds en el sistema de filtrado del ISP es una de las medidas con mejor relación esfuerzo/resultado.
El rol del ISP como actor de ciberseguridad en Latam
La narrativa de ciberseguridad en Latinoamérica suele centrarse en el usuario final como víctima o como ignorante. Pero los ISPs tienen un rol de infraestructura que los coloca en una posición única: pueden ver y controlar el tráfico en la red de una manera que ningún antivirus o firewall doméstico puede igualar.
No se trata de vigilancia ni de inspección de contenido. Se trata de mitigar, en la capa de red, comportamientos claramente maliciosos que afectan a terceros y degradan la propia red del ISP.
Los ISPs que adoptan una postura activa frente a las botnets de suscriptores no solo protegen su red — también construyen un diferenciador competitivo y cumplen con sus obligaciones regulatorias de manera más robusta.
¿Querés revisar la exposición de tu red ante botnets de suscriptores?
En Ayuda.LA hacemos análisis de exposición y ayudamos a implementar controles en la capa de acceso y el core. Sin venta de hardware, sin conflicto de interés.
Conocé más sobre nuestros servicios de ciberseguridad para ISPs.
¿Tenés preguntas sobre detección de botnets o seguridad en redes de acceso? Escribinos a [email protected] — respondemos todos los mensajes.