Cómo encontramos equipos infectados dentro de una red de más de 1.000 abonados
Qué hicimos cuando direcciones IP públicas comenzaron a perder reputación, cómo identificamos a los abonados responsables entre más de mil conexiones y cómo automatizamos la contención del tráfico malicioso.
Una dirección IP pública puede continuar funcionando perfectamente desde el punto de vista técnico y, al mismo tiempo, haberse vuelto prácticamente inutilizable para determinados servicios de Internet.
Cuando desde una IP pública comienzan a originarse envíos de spam, scanning automatizado, intentos masivos de conexión o tráfico generado por dispositivos comprometidos, esa dirección puede terminar reportada en sistemas de reputación y listas negras como Spamhaus, Barracuda y otros servicios utilizados por proveedores, plataformas de seguridad y sistemas antifraude.
En la práctica, esto puede traducirse en usuarios que comienzan a informar problemas para acceder a determinados sitios web, servicios de correo, plataformas corporativas, sistemas de autenticación o incluso determinados servicios de home banking.
Para un ISP el problema es especialmente serio: una dirección IP puede estar perfectamente conectada a Internet, responder correctamente y transportar tráfico, pero su mala reputación puede volverla prácticamente inutilizable para parte de los clientes.
Para un proveedor de Internet no resulta razonable simplemente descartar o reemplazar una IP cada vez que Spamhaus, Barracuda u otro sistema de reputación detecta actividad anormal. La solución correcta es identificar qué abonado está originando el tráfico, contenerlo y recuperar la reputación de la dirección pública.
Ese fue precisamente el desafío que encontramos recientemente en una infraestructura administrada por NetPRO.
La red contaba con más de 1.000 conexiones PPPoE, múltiples redes privadas, diferentes rutas de salida a Internet y NAT centralizado.
Sabíamos que detrás de esas direcciones públicas había cientos de usuarios navegando normalmente y, probablemente, apenas uno o unos pocos dispositivos comprometidos generando el problema.
El problema del NAT
En una red ISP, cientos de clientes pueden compartir una misma dirección IP pública mediante NAT.
Desde Internet puede observarse que una determinada IP genera tráfico sospechoso, pero eso no significa que el router principal o toda la red estén comprometidos. El origen real puede encontrarse detrás de cualquiera de los abonados que utilizan esa dirección pública.
Podíamos bloquear determinados puertos, revisar conexiones activas y analizar el tráfico en el router principal, pero necesitábamos algo mucho más valioso:
DNS: una fuente de información que estaba delante nuestro
Implementamos un resolver DNS recursivo dedicado basado en Unbound, integrado con el router principal MikroTik.
A través de reglas de redirección controladas, las consultas DNS tradicionales de los abonados comenzaron a pasar transparentemente por el nuevo resolver.
El punto técnico fundamental fue mantener la dirección IP privada original del abonado durante todo el recorrido.
Sabíamos que existía un problema, pero no qué abonado lo generaba.
Cada consulta podía asociarse directamente a la conexión PPPoE correspondiente.
De esta manera comenzamos a registrar, para cada consulta:
- fecha y hora;
- dirección IP privada del abonado;
- dominio consultado;
- tipo de consulta DNS.
Con más de mil abonados conectados, el sistema comenzó a procesar aproximadamente 20.000 consultas DNS por minuto, manteniendo un consumo muy reducido de CPU y memoria.
Los clientes comprometidos empezaron a sobresalir
La enorme mayoría de los abonados mostraba el comportamiento esperado: consultas hacia Google, WhatsApp, Microsoft, Apple, Netflix, TikTok, servidores de actualización y otros servicios habituales.
Pero algunos clientes presentaban un comportamiento radicalmente distinto.
Uno de ellos comenzó a generar enormes cantidades de consultas DNS hacia nombres anormales, repetitivos o directamente malformados.
cliente-X → ???x???7???????.org
cliente-X → dominio-sospechoso.example
cliente-X → ????????xyz????.org
No hablamos de diez o veinte consultas ocasionales.
En uno de los abonados encontramos más de 100.000 consultas DNS anómalas durante el período analizado.
Otro cliente mostraba varios miles.
Mientras tanto, la enorme mayoría de los demás abonados presentaba apenas valores aislados o directamente ninguno.
Los clientes problemáticos sobresalían por varios órdenes de magnitud respecto del comportamiento habitual de la red.
No alcanza con contar consultas
Un punto importante fue evitar una conclusión demasiado simple.
Un cliente corporativo, hotel, institución educativa o empresa con decenas de dispositivos puede generar naturalmente mucho más tráfico DNS que una vivienda.
Por eso, el volumen total de consultas no puede utilizarse por sí solo como indicador de infección.
Lo realmente útil fue buscar patrones:
- cantidad de consultas malformadas;
- porcentaje de consultas anómalas sobre el total;
- nombres de dominio aparentemente generados de forma aleatoria;
- consultas repetitivas hacia determinados dominios sospechosos;
- consultas TXT inusualmente largas o frecuentes;
- cantidad de dominios diferentes generados por un mismo abonado;
- coincidencia de los mismos indicadores entre distintos clientes.
DNS nos dio la pista. El tráfico confirmó el diagnóstico.
Una consulta DNS extraña por sí sola no demuestra la existencia de malware.
Por eso correlacionamos los resultados obtenidos en Unbound con el tráfico que el router MikroTik observaba realmente desde esos mismos abonados.
Allí apareció la segunda señal.
Los mismos clientes que mostraban comportamiento DNS anormal estaban intentando establecer conexiones automáticamente contra grandes cantidades de direcciones IP diferentes en Internet.
El patrón observado era compatible con scanning automatizado de Internet: muchos destinos diferentes, intentos muy breves y repetitivos sobre puertos utilizados habitualmente por servicios de administración.
Este comportamiento suele aparecer cuando dentro de la red del abonado existe algún router, DVR, cámara, TV Box, computadora u otro dispositivo comprometido.
De detectar el problema a contenerlo automáticamente
Identificar al abonado era sólo una parte del trabajo.
El siguiente objetivo fue conseguir que la propia infraestructura pudiera reaccionar automáticamente ante este tipo de comportamiento.
Implementamos en MikroTik un mecanismo de detección que observa conexiones nuevas hacia determinados servicios sensibles y clasifica a los clientes que exceden ciertos parámetros.
Esto modifica completamente la dinámica de respuesta ante incidentes.
Ya no resulta imprescindible localizar físicamente al cliente en el mismo momento en que se descubre el problema para proteger al ISP.
Primero se contiene el tráfico. Después se puede informar al abonado y revisar con más tranquilidad qué dispositivo dentro de su red se encuentra comprometido.
¿Qué pasa si falla el servidor DNS?
Centralizar el DNS introducía una responsabilidad importante: el nuevo resolver no podía transformarse en un punto único de falla.
Por eso implementamos un sistema de fail-open automático.
Cuando el resolver vuelve a estar disponible, MikroTik recupera automáticamente las reglas correspondientes y el tráfico vuelve a pasar por Unbound.
No nos limitamos a comprobar que el servidor respondiera a ping. El monitoreo verifica que efectivamente pueda realizar una resolución DNS.
El mecanismo fue probado deliberadamente deteniendo el servicio, verificando la conmutación automática y posteriormente comprobando la recuperación completa.
El resultado
Antes del trabajo, la situación podía resumirse así:
Después de implementar el sistema:
Qué quedó funcionando
Registro de consultas preservando la IP privada de cada abonado.
Identificación de clientes cuyo comportamiento DNS se aparta fuertemente del patrón normal.
Identificación automática de intentos masivos hacia SSH y Telnet.
Bloqueo selectivo del tráfico perjudicial sin suspender completamente el acceso a Internet del cliente.
Registros disponibles para análisis posteriores y correlación de incidentes.
Una falla del resolver central no deja sin DNS a los abonados.
Proteger la reputación también es proteger un recurso escaso
Durante muchos años una dirección IP pública fue vista simplemente como un elemento más de configuración.
Hoy la situación es diferente.
El agotamiento del espacio IPv4 hace que disponer de direcciones públicas sea cada vez más valioso para operadores e ISP.
Cambiar permanentemente una IP cada vez que aparece reportada por Spamhaus, Barracuda u otro sistema de reputación no resuelve la causa.
Si el dispositivo comprometido permanece activo, tarde o temprano la nueva dirección puede terminar exactamente en la misma situación.
El verdadero objetivo debe ser encontrar el origen, contenerlo y corregir la causa.
¿Querés probarlo en tu casa?
No hace falta administrar un ISP con mil abonados para experimentar con este concepto.
Cualquier entusiasta puede montar un pequeño laboratorio utilizando una PC vieja, Raspberry Pi, mini PC o máquina virtual con Linux.
El objetivo es hacer que las consultas DNS de nuestra red pasen por un resolver propio y comenzar a observar qué hacen realmente los dispositivos.
192.168.1.0/24
192.168.1.2
1. Preparar una máquina Linux
Para el ejemplo utilizaremos:
Servidor DNS: 192.168.1.2
Red LAN: 192.168.1.0/24
En Debian o Ubuntu instalamos Unbound:
sudo apt update
sudo apt install unbound2. Configurar Unbound
Creamos un archivo de configuración:
sudo nano /etc/unbound/unbound.conf.d/home.confComo punto de partida podemos utilizar:
server:
interface: 127.0.0.1
interface: 192.168.1.2
access-control: 127.0.0.0/8 allow
access-control: 192.168.1.0/24 allow
access-control: 0.0.0.0/0 refuse
hide-identity: yes
hide-version: yes
verbosity: 1
log-queries: yes
log-time-ascii: yes
logfile: "/var/log/unbound/queries.log"Verificamos la sintaxis:
sudo unbound-checkconfY reiniciamos:
sudo systemctl restart unbound3. Probar nuestro DNS
Desde otra computadora:
nslookup www.google.com 192.168.1.2O utilizando dig:
dig @192.168.1.2 www.google.comPodemos observar las consultas en tiempo real:
tail -f /var/log/unbound/queries.logY empezar a ver información similar a:
192.168.1.50 www.google.com. A IN
192.168.1.23 youtube.com. A IN
192.168.1.77 whatsapp.net. A IN4. Entregar nuestro DNS mediante DHCP
La opción más sencilla consiste en configurar el DHCP del router para entregar:
A partir de ese momento, teléfonos, computadoras, televisores y otros equipos que utilizan DHCP comenzarán a consultar nuestro servidor.
5. Opcional: forzar el DNS desde MikroTik
Algunos dispositivos ignoran el DNS entregado por DHCP y utilizan directamente servidores como 8.8.8.8 o 1.1.1.1.
Con MikroTik podemos redirigir las consultas DNS tradicionales hacia nuestro resolver.
/ip firewall nat
add chain=dstnat \
src-address=192.168.1.0/24 \
protocol=udp \
dst-port=53 \
action=dst-nat \
to-addresses=192.168.1.2 \
to-ports=53 \
comment="DNS LOCAL UDP"
add chain=dstnat \
src-address=192.168.1.0/24 \
protocol=tcp \
dst-port=53 \
action=dst-nat \
to-addresses=192.168.1.2 \
to-ports=53 \
comment="DNS LOCAL TCP"6. Empezar a investigar nuestros propios logs
Una vez que tenemos tráfico real podemos empezar a experimentar.
Para conocer qué dispositivos generan más consultas:
awk '$5=="info:" {print $6}' \
/var/log/unbound/queries.log \
| sort | uniq -c | sort -nr | head -20Para conocer los dominios más consultados:
awk '$5=="info:" {print $7}' \
/var/log/unbound/queries.log \
| sort | uniq -c | sort -nr | head -30Y para buscar nombres DNS que aparezcan malformados:
awk '$5=="info:" && index($7,"?") {print $6}' \
/var/log/unbound/queries.log \
| sort | uniq -c | sort -nr | head -20Un dominio extraño o un dispositivo que genera muchas consultas DNS no significa automáticamente que exista una infección. El análisis debe realizarse correlacionando varias señales: frecuencia, dominios consultados, destinos de red, puertos utilizados y comportamiento general del dispositivo.
Una Smart TV, un teléfono Android, un iPhone, una consola, una cámara IP o un simple TV Box pueden generar cientos de consultas diferentes sin que normalmente tengamos visibilidad de ellas. Montar nuestro propio resolver DNS es una excelente forma de comenzar a entender qué ocurre realmente dentro de nuestra propia red.
Una herramienta de seguridad que ya estaba delante nuestro
Uno de los aspectos más interesantes del proyecto fue comprobar cuánto puede decirnos el DNS acerca del comportamiento de una red.
El análisis DNS no reemplaza un IDS, un antivirus, un firewall avanzado ni otras plataformas específicas de seguridad.
Pero dentro de una infraestructura correctamente diseñada puede convertirse en una extraordinaria fuente de telemetría.
Especialmente cuando la información se correlaciona con:
- firewall;
- connection tracking;
- sesiones PPPoE;
- volumen y frecuencia de conexiones;
- destinos y puertos utilizados;
- listas dinámicas de detección.
En nuestro caso permitió encontrar, entre más de mil usuarios, unos pocos abonados cuyo comportamiento sobresalía por varios órdenes de magnitud respecto del resto.
Conclusión
En redes grandes, bloquear el síntoma no siempre resuelve el problema.
Si una IP aparece reportada por Spamhaus o Barracuda, cambiarla puede resolver momentáneamente el inconveniente, pero no elimina el dispositivo que provocó el reporte.
La clave está en disponer de suficiente visibilidad para descubrir quién está generando el tráfico.
En NetPRO trabajamos sobre infraestructura MikroTik, Linux, routing y seguridad para transformar información que normalmente queda dispersa dentro de una red en herramientas concretas de diagnóstico, prevención y respuesta ante incidentes.
La diferencia está en hacer que la propia red nos diga dónde está la aguja.