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.

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.

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.

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

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.

sudo apt update
sudo apt install unbound

sudo nano /etc/unbound/unbound.conf.d/home.conf

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"

sudo unbound-checkconf

sudo systemctl restart unbound

nslookup www.google.com 192.168.1.2

dig @192.168.1.2 www.google.com

tail -f /var/log/unbound/queries.log

192.168.1.50 www.google.com. A IN
192.168.1.23 youtube.com. A IN
192.168.1.77 whatsapp.net. A IN

/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"

awk '$5=="info:" {print $6}' \
/var/log/unbound/queries.log \
| sort | uniq -c | sort -nr | head -20

awk '$5=="info:" {print $7}' \
/var/log/unbound/queries.log \
| sort | uniq -c | sort -nr | head -30

awk '$5=="info:" && index($7,"?") {print $6}' \
/var/log/unbound/queries.log \
| sort | uniq -c | sort -nr | head -20

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.