Cómo detectar un túnel DNS en un servidor Linux

Saber cómo es un túnel DNS

Capturar el tráfico DNS del servidor con tcpdump

Instala tcpdump, y tshark para el análisis de más abajo. En Debian y Ubuntu el instalador de tshark pregunta si los usuarios sin privilegios pueden capturar: responde que no.

sudo apt install tcpdump tshark

sudo dnf install tcpdump wireshark-cli

Graba cinco minutos de tráfico DNS, UDP y TCP, en todas las interfaces. Con systemd-resolved, los programas preguntan al stub local en 127.0.0.53 y el stub pregunta aguas arriba: -i any ve ambas cosas.

sudo timeout 300 tcpdump -i any -nn -Z root -w /root/dns.pcap 'port 53'

Después léelo. Primero la proporción de cada tipo de consulta: muchos TXT? o NULL? llaman la atención.

sudo tcpdump -nn -r /root/dns.pcap 'dst port 53' 2>/dev/null \
  | grep -oE '[A-Z0-9]+\? [^ ]+' | awk '{print $1}' | sort | uniq -c | sort -rn

Luego los dominios con más nombres únicos por debajo. Un túnel pone un dominio en cabeza con cientos de nombres; el tráfico normal se reparte entre muchos dominios con pocos nombres cada uno. (El recuento agrupa por las dos últimas etiquetas, así que example.co.uk aparece como co.uk.)

sudo tcpdump -nn -r /root/dns.pcap 'dst port 53' 2>/dev/null \
  | grep -oE '[A-Z0-9]+\? [^ ]+' | awk '{print tolower($2)}' | sort -u \
  | awk -F. '{n = NF - 1; if (n >= 2) print $(n-1) "." $n}' | sort | uniq -c | sort -rn | head -20

Y los nombres con una etiqueta de 30 caracteres o más:

sudo tcpdump -nn -r /root/dns.pcap 'dst port 53' 2>/dev/null \
  | grep -oE '[A-Z0-9]+\? [^ ]+' | awk '{print $2}' \
  | awk -F. '{for (i = 1; i < NF; i++) if (length($i) >= 30) {print; break}}' | sort -u | head -20

Lo mismo con tshark

tshark da estadísticas por tipo de consulta y el origen y el destino de cada consulta, y encuentra respuestas inusualmente grandes, que los túneles usan para traer datos de vuelta:

sudo tshark -r /root/dns.pcap -q -z dns,tree
sudo tshark -r /root/dns.pcap -Y 'dns.flags.response == 0' -T fields \
  -e ip.src -e ip.dst -e dns.qry.type -e dns.qry.name | head -50
sudo tshark -r /root/dns.pcap -Y 'dns.flags.response == 1 && udp.length > 512' -T fields \
  -e dns.qry.name | sort | uniq -c | sort -rn | head

Revisar los logs del resolver

Primero mira qué resolvers tiene configurados el servidor. Las consultas a cualquier otra dirección ya merecen una mirada por sí solas.

cat /etc/resolv.conf
resolvectl status 2>/dev/null | grep -E 'DNS Servers|Current DNS'

systemd-resolved no guarda un log de consultas, pero desde systemd 252 (Debian 12, Ubuntu 24.04, RHEL 9 y posteriores) muestra cada resolución en directo. Déjalo funcionando unos minutos y busca nombres largos y aleatorios:

sudo resolvectl monitor

Si el servidor tiene su propio resolver, activa su log de consultas. Para unbound, luego sudo systemctl restart unbound:

# /etc/unbound/unbound.conf (RHEL) or a file in /etc/unbound/unbound.conf.d/ (Debian, Ubuntu)
server:
    log-queries: yes
    log-replies: yes

sudo rndc querylog on

Los dos escriben en el journal. Esto lista los nombres con una etiqueta de 30 caracteres o más de la última hora:

sudo journalctl --since "1 hour ago" -u unbound -u named -u bind9 \
  | grep -ioE '([a-z0-9-]{30,}\.)+[a-z0-9.-]+' | sort | uniq -c | sort -rn | head -20

Encontrar el programa que hace las consultas

Los sockets DNS viven una fracción de segundo, así que toma muestras: esto mira una vez por segundo durante un minuto y cuenta los programas que tenían un socket DNS abierto. Los programas que preguntan al stub de systemd-resolved aparecen con su propio nombre, porque el stub también escucha en el puerto 53.

for i in $(seq 1 60); do sudo ss -unpH '( dport = :53 )'; sleep 1; done \
  | grep -o 'users:(("[^"]*",pid=[0-9]*' | sort | uniq -c | sort -rn

Si en cabeza aparecen systemd-resolve, unbound o named, las consultas pasan por el resolver desde otro programa: repite la captura solo en la interfaz de loopback (-i lo) y compara las horas. Para un programa que no conoces, mira su binario, su carpeta y la unidad que lo arrancó:

sudo ls -l /proc/PID/exe /proc/PID/cwd
sudo tr '\0' ' ' < /proc/PID/cmdline; echo
systemctl status PID

Un cliente de túnel es una señal de compromiso, no el compromiso en sí. Busca el resto como en Cómo encontrar y eliminar un minero de criptomonedas: persistencia en cron, systemd y claves SSH, binarios del sistema modificados, y cómo entró el atacante.

Bloquear el túnel

Detén primero el programa. Después asegúrate de que el DNS solo pueda salir por los resolvers que elegiste: esta tabla de nftables descarta el DNS hacia cualquier otra dirección, y DNS over TLS hacia todas. Sustituye 192.0.2.53 por tus resolvers del paso 3 (varios, separados por comas).

sudo nft add table inet dnsguard
sudo nft 'add chain inet dnsguard out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet dnsguard out ip daddr != { 127.0.0.0/8, 192.0.2.53 } meta l4proto { tcp, udp } th dport 53 drop
sudo nft add rule inet dnsguard out tcp dport 853 drop

Un túnel a través de tu propio resolver sigue funcionando, porque el resolver reenvía las consultas. Si usas unbound, responde al dominio del túnel con "no existe":

# In the server: section of unbound.conf
    local-zone: "tunnel.example." always_nxdomain

sudo unbound-checkconf && sudo systemctl restart unbound

Con systemd-resolved solo no hay bloqueo por dominio: apunta el servidor a un resolver que sí lo permita, o confía en eliminar el programa. /etc/hosts no sirve, porque no puede abarcar todos los subdominios.

Preguntas

Mi firewall bloquea el tráfico saliente. ¿Puede funcionar igualmente un túnel DNS?

Sí, si el servidor puede consultar un resolver, y casi todos pueden. El resolver reenvía por ti las consultas al servidor de nombres del atacante. Por eso el resolver también debe bloquear el dominio, o el programa tiene que desaparecer.

¿DNSSEC o DNS over HTTPS lo impiden?

No. DNSSEC demuestra que las respuestas son auténticas, y las respuestas del atacante son auténticas para su propio dominio. DNS over HTTPS oculta las consultas a la red, lo que hace un túnel más difícil de ver, no imposible de montar.

¿Qué tráfico legítimo se parece a un túnel?

Las consultas de antivirus y de reputación que codifican hashes de archivos en los nombres, las comprobaciones de listas negras de un servidor de correo y algunos nombres de CDN, nube y telemetría. Investiga el dominio antes de actuar.