Parte: 0 — Fundamentos y prerrequisitos · Fuente: RFC 1035 (DNS), RFC 2131 (DHCP), RFC 826 (ARP) ⏱️ Duración estimada: 100 min · Nivel: Fundamentos
Comprender los tres protocolos de infraestructura que hacen funcionar cualquier red local e Internet: DNS (resolución de nombres), DHCP (asignación de direcciones) y ARP (mapeo IP↔MAC). Todos comparten un problema: se diseñaron sin autenticación, lo que los convierte en vectores clásicos de ataque en red local.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Resolución DNS | Cómo un nombre se vuelve una IP |
| 2 | Tipos de registro | A, AAAA, CNAME, MX, TXT, NS |
| 3 | Caché y recursión | Rendimiento y superficie de envenenamiento |
| 4 | DHCP DORA | Discover, Offer, Request, Ack |
| 5 | ARP | Puente entre capa 3 y capa 2 |
| 6 | ARP spoofing | Base del MITM en LAN |
| 7 | DNS/DHCP rogue | Redirección y control del tráfico |
| 8 | Defensas | DHCP snooping, DAI, DNSSEC |
En Kali: dig, nslookup, arp, ip neigh, dhclient, y para prácticas ofensivas de laboratorio ettercap o bettercap y arpspoof (dsniff). Wireshark para observar. Necesitas al menos tres nodos en tu red interna: atacante, víctima y gateway/servidor.
bash
dig A example.com +short
dig MX example.com
dig +trace example.com # observa la resolución jerárquica
bash
ip neigh show
Anota la MAC del gateway. 3. Observar DHCP. Captura mientras renuevas la concesión en la VM:
bash
sudo tcpdump -i eth0 -n port 67 or port 68 &
sudo dhclient -v eth0
Identifica los cuatro mensajes DORA. 4. ARP spoofing controlado (solo laboratorio). Habilita el reenvío y envenena entre víctima y gateway:
bash
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo arpspoof -i eth0 -t 10.10.10.6 10.10.10.1
ip neigh mostrará ahora tu MAC asociada a la IP del gateway. Captura su tráfico en Wireshark.⚠️ Nota ética: ARP/DNS/DHCP spoofing se practican exclusivamente en tu laboratorio aislado, entre tus propias VMs. Ejecutarlos en una red real ajena es interceptación ilegal de comunicaciones.
Monta en tu laboratorio un ataque de ARP spoofing entre dos VMs y demuéstralo con evidencia: captura la tabla ARP de la víctima antes y después, y muestra en Wireshark tráfico de la víctima pasando por el atacante. Después, describe una defensa que lo habría impedido.
Criterio de aceptación: la tabla ARP de la víctima muestra la MAC del atacante asociada a la IP del gateway tras el ataque, y hay una captura que evidencia el tráfico interceptado. La sección de defensa nombra un control real (DAI, ARP estático) y explica por qué funciona.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El ARP spoofing corta la conexión de la víctima | No habilitaste ip_forward. Actívalo para reenviar el tráfico. |
dig devuelve SERVFAIL |
Resolver mal configurado o DNSSEC fallando. Prueba otro servidor con @. |
| La víctima no cae en el spoofing | Tiene ARP estático o DAI. Es la defensa funcionando. |
| No veo los 4 mensajes DHCP | La concesión aún es válida; fuerza dhclient -r y renueva. |
| DNS spoofing no redirige | La víctima usa DoH/DoT o caché. Considera el cifrado del canal DNS. |
❓ ¿Por qué estos protocolos no tienen autenticación? Se diseñaron en los años 80 para redes confiables. Añadir seguridad después (DNSSEC, DAI) es más difícil que haberla incluido de origen; es una lección de diseño.
❓ ¿DNS over HTTPS (DoH) resuelve todo? Añade confidencialidad e integridad del canal cliente-resolver, dificultando el spoofing y la vigilancia, pero no autentica la zona como DNSSEC ni protege dentro de la LAN por sí solo.
❓ ¿ARP spoofing funciona en redes conmutadas modernas? Sí, porque explota la ausencia de autenticación de ARP, no el medio. Las mitigaciones son a nivel de switch (DAI) y segmentación.
❓ ¿Cómo detecto un servidor DHCP rogue? Monitorizando ofertas DHCP inesperadas y con DHCP snooping en switches, que solo confía en puertos autorizados.
Clase 011 — Protocolos de red: IP, TCP, UDP e ICMP en profundidad