DNS, DHCP y ARP: resolución y suplantación

1Por qué importa

Quien controla la resolución de nombres controla el destino de todo tu tráfico sin tocar tu código ni tus credenciales. No hace falta romper TLS: basta con que el nombre apunte a otro sitio y esperar a que alguien, en algún punto de la cadena, no verifique el certificado o acepte el aviso del navegador. En la práctica, la mitad de los ataques de intermediario empiezan aquí y no en la criptografía.

Hay un segundo motivo, menos vistoso y más frecuente: DNS es el mejor canal encubierto que existe en una red corporativa. Casi todos los perímetros permiten consultas salientes porque sin ellas no funciona nada, y muchos no las registran. Un nombre de subdominio puede transportar datos, y una respuesta puede transportar instrucciones. La fase 14 va a construir la detección de eso; aquí se construye el modelo que la hace posible.

Y hay un tercero, puramente operativo. La mayoría de las incidencias que parecen “la red va mal” son problemas de resolución: una caché con una entrada vieja, un resolutor que responde otra cosa dentro que fuera, un tiempo de vida de registro mal elegido durante una migración. Saber leer una resolución completa ahorra más horas que casi ninguna otra habilidad de esta fase.

2Conceptos

3Explicación profunda

Una resolución completa tiene más pasos de los que la gente imagina, y cada salto es una oportunidad. Tu proceso llama a la biblioteca del sistema. Esa biblioteca mira primero el archivo de hosts, después consulta al resolutor configurado. Ese resolutor, si es recursivo, pregunta a la raíz por el dominio de primer nivel, al dominio de primer nivel por el servidor de la zona, y a ese servidor por el registro concreto. Guarda el resultado durante el tiempo que diga el TTL y te lo devuelve. En tu laboratorio la cadena es corta porque el resolutor embebido de Docker responde por los nombres de servicio, pero la estructura es la misma.

El problema de diseño es que una respuesta DNS clásica no está autenticada de ninguna forma. El cliente acepta la primera respuesta que llegue con el identificador de transacción y el puerto de origen correctos, sobre UDP, sin firma. De ahí salen las cuatro familias de envenenamiento. Se puede mentir en la última milla, respondiendo antes que el resolutor legítimo si estás en el mismo segmento. Se puede mentir a la caché del recursivo, adivinando el identificador o aprovechando un fallo de implementación. Se puede mentir en el autoritativo, si alguien toma control de la zona o del registrador. Y se puede mentir sin tocar DNS, cambiando qué resolutor usas: eso es lo que hace un DHCP falso.

DHCP merece esa mención aparte porque casi nadie lo lee como lo que es: una entrega de confianza. Cuando un equipo se conecta, difunde una petición y acepta la primera oferta que llega. Esa oferta no trae solo una dirección: trae la ruta por defecto y el resolutor DNS. Quien conteste primero decide por dónde sale todo tu tráfico y quién traduce todos tus nombres. No hay credenciales de por medio ni verificación posible; es un protocolo que se diseñó para redes donde el cable ya era la autenticación.

ARP está un escalón por debajo y es todavía más crudo. Para hablar con un equipo del mismo segmento hace falta su dirección física; ARP la pide a gritos y cualquiera puede contestar. Peor: muchos sistemas aceptan respuestas que nadie pidió y actualizan su tabla con ellas. Un atacante que anuncia ser la puerta de enlace consigue que el tráfico de sus vecinos pase por él, sin explotar ninguna vulnerabilidad. El protocolo está funcionando exactamente como fue especificado; ese es el problema.

Las defensas hay que colocarlas con precisión porque resuelven cosas distintas. DNSSEC firma las respuestas: te dice que lo que recibes es lo que publicó el dueño de la zona, y detecta manipulación en cualquier punto intermedio. No cifra nada: quien mire el cable sigue viendo qué nombres consultas. DoT y DoH hacen lo contrario: cifran el transporte entre tú y tu resolutor, así que el vecino de red deja de ver tus consultas, pero no te dicen nada sobre si el resolutor te está mintiendo. Son complementarias, y el error de diseño más común de esta lección es creer que una sustituye a la otra.

Una opinión, y la señalo como tal: en una red que controlas, el control más rentable no es criptográfico sino topológico. Un segmento donde solo un equipo puede ser servidor DHCP, donde los clientes no se ven entre sí y donde el resolutor es fijo, elimina de golpe la última milla entera. DNSSEC y DoH resuelven lo que queda, que es mucho menos.

4Ejemplo sencillo

# Llegar a una casa en una ciudad desconocida

DHCP    en la estacion te dan un plano, un guia y una salida recomendada.
        Aceptas el primero que se acerca. Nadie comprueba su credencial.

DNS     le preguntas al guia "donde vive Ana?" y te da una direccion.
        Tu no verificas nada: te fias de que el guia sepa y no mienta.

ARP     ya en la calle correcta, gritas "quien es el numero 12?" y
        alguien levanta la mano. Tampoco compruebas que sea verdad.

# Y las tres defensas, que NO son intercambiables

DNSSEC  la direccion viene firmada por el ayuntamiento: sabes que es
        la autentica, aunque todo el mundo oiga lo que preguntaste.

DoH     hablas con el guia en un idioma que nadie mas entiende: nadie
        sabe por quien preguntas, pero el guia puede mentirte igual.

topologia  solo hay un guia autorizado en la estacion y los viajeros
           no pueden hablar entre ellos. Se acabaron los guias falsos.

5Ejemplo técnico

Así se lee una consulta real. Esta es del laboratorio de esta lección, preguntando por un nombre de servicio del propio compose:

Tres campos importan para seguridad y casi nunca se miran. El identificador de la cabecera, que es lo único que ata la respuesta a la pregunta en el DNS clásico: dieciséis bits, y por eso los ataques históricos de envenenamiento consistían en adivinarlo. Las banderas: rd dice que pediste recursión y ra que el servidor la ofrece; falta ad, que aparecería si la respuesta estuviera validada con DNSSEC. Y el TTL: seiscientos segundos durante los que cualquier mentira que haya entrado en la caché se sigue sirviendo aunque el origen ya esté corregido.

La última fila de la tabla es la que más sorprende a quien viene de la seguridad de aplicaciones: DNSSEC no protege de que alguien tome el control de tu zona. Firma lo que publica el titular; si el titular pasa a ser otro, la firma sigue siendo válida. Ese riesgo se mitiga en el registrador, no en el protocolo.

6Diagrama

flowchart LR
    APP[aplicacion] --> STUB[resolutor del sistema]
    STUB --> REC[recursivo con cache]
    REC --> AUT[jerarquia autoritativa]
    DHCP[DHCP falso] --> STUB
    ARP[ARP suplantado] --> STUB
    POI[cache envenenada] --> REC
    SEC[zona secuestrada] --> AUT

7Código

Una resolución auditable se parece más a esto que a un ping. El script compara lo que responden dos caminos distintos y avisa cuando no coinciden, que es la señal barata de que algo está reescribiendo respuestas:

#!/bin/sh
# auditar-resolucion.sh — dentro del laboratorio propio.
# Compara la vista de dos resolutores y marca las diferencias.
set -eu

NOMBRES="app db entrada"

for n in $NOMBRES; do
  # 1. lo que responde el resolutor configurado del sistema
  directa=$(docker compose exec -T cliente dig +short "$n" | head -1)

  # 2. lo que ve otro contenedor de la misma red, por si difieren
  segunda=$(docker compose exec -T sniffer getent hosts "$n" | awk '{print $1}')

  if [ "$directa" = "$segunda" ]; then
    echo "ok         $n"
  else
    echo "DIFIEREN   $n  ($directa vs $segunda)"
  fi

  # 3. el TTL importa: es la ventana en la que una mentira sobrevive
  docker compose exec -T cliente dig "$n" | awk '/ANSWER SECTION/{getline; print "   ttl:", $2}'
done

# 4. y lo que de verdad se envia por el cable, para no fiarse de la salida
echo "== captura de las consultas =="
docker compose exec -T -d sniffer sh -c "tcpdump -i any -w /tmp/dns.pcap port 53"
docker compose exec -T cliente sh -c "for n in app db entrada; do getent hosts \$n >/dev/null; done"
docker compose exec -T sniffer sh -c "pkill tcpdump; tcpdump -r /tmp/dns.pcap | head -20"

Lo que hace útil al script es el paso 4. Los tres primeros se fían de lo que las herramientas dicen haber hecho; el cuarto mira el cable. Cuando alguien está interceptando resolución, la diferencia entre esas dos fuentes es el primer indicio, y a veces el único.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

# dentro del contenedor cliente
cp /etc/hosts /etc/hosts.bak
getent hosts entrada | sed 's/entrada.*/app/' >> /etc/hosts
curl -s http://app/salud     # responde "entrada ok", no la app

# revertir
cp /etc/hosts.bak /etc/hosts

# en el cliente: el dato viaja en la PREGUNTA
docker compose exec cliente sh -c 'dig +short $(echo secreto-lab | base64 | tr -d "=").app'

# en el sniffer: la consulta aparece aunque no exista el nombre
docker compose exec sniffer sh -c 'tcpdump -r /tmp/dns.pcap | grep -i c2vjcmv'

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos