ARP spoofing y MITM en la LAN:
por qué funciona y cómo se corta
Serie Blue Team | unfantasmaenelsistema.com
Dentro de un segmento de red local, los equipos se localizan entre sí por dirección MAC, y la traducción de «IP a MAC» la hace un protocolo de 1982 que no autentica nada: ARP. Cualquier equipo del segmento puede afirmar «la IP de la puerta de enlace soy yo» y el resto lo creerá. Sobre esa base se monta el ataque man-in-the-middle más antiguo y más enseñado de las redes conmutadas.
Este artículo lo aborda desde el lado defensivo: qué hace que ARP sea manipulable, qué queda expuesto cuando alguien se coloca en medio, cómo se detecta ese envenenamiento y, sobre todo, cómo se mitiga en el switch y en el diseño de red. Es el complemento de nuestros artículos sobre Responder/LLMNR y sobre segmentación con VLAN. No incluye ninguna receta de envenenamiento.
Qué aprenderas en este articulo
Por qué ARP no autentica y qué es el envenenamiento de caché ARP · Qué expone un MITM en la LAN: tráfico sin cifrar, downgrade, robo de credenciales · Señales de detección: varias IP para una misma MAC, ARP gratuito anómalo, arpwatch · Mitigación en el switch: DHCP snooping + Dynamic ARP Inspection, port security · Defensa en profundidad: 802.1X, segmentación, y TLS/HSTS en todo
1. Por qué ARP se deja engañar
Cuando un equipo quiere enviar un paquete a una IP de su misma subred, necesita la MAC de destino. Emite una pregunta por difusión (ARP request: «¿quién tiene 192.168.1.1?») y espera una ARP reply. Guarda la respuesta en su caché ARP durante unos minutos.
- ARP no tiene autenticación ni estado: un equipo acepta una ARP reply aunque no haya preguntado nada («gratuitous ARP»), y acepta la última que llega, sobrescribiendo lo que tuviera
- Un atacante en el mismo segmento envía respuestas falsas asociando la IP del router con su propia MAC. La víctima actualiza su caché y empieza a mandarle a él todo el tráfico destinado a fuera
- Haciendo lo mismo hacia el router (asociar la IP de la víctima con la MAC del atacante), el atacante queda en medio de la conversación en los dos sentidos y la reenvía para que nada se note
El ataque es puramente de capa 2: no explota ningún fallo de software, solo el diseño del protocolo. Por eso lleva décadas funcionando y por eso la defensa no es «parchear» sino controlar quién puede decir qué en el segmento.
2. Qué queda expuesto con un MITM en la LAN
| Exposición | Qué permite al atacante | Qué lo limita |
|---|---|---|
| Tráfico en claro (HTTP, FTP, Telnet, SNMPv1/2, SMB sin firma) | Leer y modificar contenido, capturar credenciales y cookies de sesión | TLS en todo; SMB signing; sustituir protocolos legados |
| Downgrade de HTTPS | Forzar HTTP con técnicas de stripping si el usuario teclea el dominio sin https:// | HSTS con preload; redirecciones del lado servidor; DNS interno correcto |
| Suplantación de DNS interno | Responder consultas DNS antes que el servidor real y desviar a servicios falsos | DNSSEC en zonas internas donde aplique; validar el resolutor; segmentación |
| Captura de autenticación de red (NTLM, Kerberos) | Recoger material para relay o cracking offline (ver artículos de Responder y NTLM relay) | Firma y sellado de canal; EPA; deshabilitar LLMNR/NBT-NS |
| Denegación de servicio | Enviar a un agujero negro el tráfico de un host o de todo el segmento | DAI, port security, monitorización |
La conclusión práctica: un MITM de LAN es devastador contra protocolos sin cifrar y molesto pero contenido contra tráfico bien cifrado y autenticado. Buena parte de la defensa consiste en no tener nada que valga la pena capturar en claro.
3. Detección
El envenenamiento ARP deja rastros característicos porque rompe una regla que en una red sana casi siempre se cumple: una MAC, una IP.
- Una misma MAC reclamando varias IP (sobre todo si una de ellas es la de la puerta de enlace), o una misma IP resuelta a MAC distintas en poco tiempo
- Ráfagas de ARP reply gratuito, o replies sin request previo, especialmente hacia la IP del router o de servidores clave
- Cambios en la caché ARP de hosts y del router que no corresponden a altas o cambios planificados
- Aumento de tráfico redirigido: un puerto de acceso que de repente ve mucho más tráfico del habitual, latencias raras, TTL alterados
| Herramienta / fuente | Qué aporta | Dónde |
|---|---|---|
| arpwatch / arpalert | Registra los pares IP-MAC y alerta de nuevos o cambiados | Un host con visibilidad del segmento (SPAN) |
| Logs de Dynamic ARP Inspection | El switch registra y descarta los ARP que no cuadran con la tabla de DHCP snooping | Switch de acceso |
| IDS de red (Suricata/Zeek) | Reglas y scripts para anomalías ARP y para el efecto (DNS spoof, stripping) | Sensor con SPAN/tap |
| NAC / inventario | Detecta MAC nuevas y puertos con más de una MAC activa | Plataforma NAC |
| Sondas en el endpoint | Alertan si la MAC de la gateway cambia (EDR, scripts, agentes) | Equipos cliente y servidores |
Una comprobación rápida en el propio equipo
En Windows: `arp -a` y comparar la MAC de la puerta de enlace con la conocida; `Get-NetNeighbor` · En Linux: `ip neigh` y `arp -n`; fijarse en entradas duplicadas o en flags ‘STALE/FAILED’ raras · Si dos IP distintas muestran la MISMA MAC (y no es un router haciendo proxy ARP legítimo), es una señal de alarma que hay que investigar
4. Mitigación en el switch
La defensa efectiva vive en la electrónica de acceso. Los tres controles se apoyan unos en otros y se despliegan juntos:
| Control | Qué hace | Notas de despliegue |
|---|---|---|
| DHCP Snooping | El switch observa el DHCP y construye una tabla fiable de IP-MAC-puerto para los clientes; marca puertos ‘trusted’ (hacia el servidor DHCP) y ‘untrusted’ (acceso) | Es la base: sin esta tabla, DAI no tiene contra qué comparar. Añadir entradas estáticas para hosts con IP fija |
| Dynamic ARP Inspection (DAI) | Intercepta todas las ARP de los puertos untrusted y descarta las que no coinciden con la tabla de DHCP snooping (o con ACL ARP estáticas) | Activar por VLAN; configurar rate-limit de ARP para que un flood no sature la CPU del switch |
| Port Security | Limita cuántas MAC y cuáles pueden aparecer en un puerto de acceso | Frena también MAC flooding y equipos no autorizados; modo ‘restrict’ con log antes que ‘shutdown’ en producción |
| IP Source Guard | Filtra el tráfico IP por puerto según la tabla de DHCP snooping | Complemento: evita spoofing de IP una vez controlado el de ARP |
- En redes pequeñas o de laboratorio sin switches gestionables, se puede recurrir a entradas ARP estáticas para la puerta de enlace y los servidores críticos, pero no escala y hay que mantenerlo a mano
- El proxy ARP legítimo de algunos routers puede parecer un ataque a la vista de arpwatch; conviene conocer el diseño antes de perseguir falsas alarmas
- Documenta las entradas estáticas de DHCP snooping (impresoras, servidores, dispositivos IoT con IP fija) o DAI las bloqueará
5. Defensa en profundidad
DAI corta el ataque en el segmento donde está activo. El resto de capas reducen lo que un atacante gana si consigue posición o si el control del switch falla:
- Segmentación con VLAN y microsegmentación. Cuanto más pequeño es el dominio de difusión, menos alcance tiene un MITM y menos hosts comparten el riesgo. Aísla IoT, invitados, OT y servidores en segmentos propios
- 802.1X / NAC. Autenticar el equipo antes de darle acceso al puerto impide que un dispositivo no autorizado se enchufe y empiece a hablar ARP
- Cifrado y autenticación de extremo a extremo. TLS en todos los servicios internos, HSTS (idealmente con preload), SMB signing obligatorio, LDAP sobre TLS, SNMPv3. Si no hay nada en claro, un MITM ve poco
- Apagar los protocolos de resolución heredados (LLMNR, NBT-NS, mDNS donde no haga falta) para no regalar autenticación de red
- Puertos físicos. Deshabilitar los puertos de red que no se usan y proteger salas y tomas accesibles al público
Solo en red propia, laboratorio o con autorización escrita
Todo lo de este artículo (revisar cachés ARP, montar arpwatch, activar DAI, analizar tráfico en tu red) es administración y defensa legítimas · Ejecutar herramientas de envenenamiento ARP o interceptar el tráfico de otras personas en una red que no administras, aunque sea «para demostrar el riesgo», puede constituir un delito de descubrimiento y revelación de secretos y de daños (en España, arts. 197, 197 bis, 197 ter y 264 del Código Penal), además de vulnerar la normativa de protección de datos · Para practicar el ataque y las defensas, monta un laboratorio aislado (dos o tres VM y un switch virtual, rango 192.168.56.x) o usa los entornos de formación como GNS3/EVE-NG y las máquinas de práctica de plataformas de CTF
Conclusión
El ARP spoofing sigue vivo porque no es un bug: es el comportamiento normal de un protocolo que confía en todo el mundo dentro del segmento. No se parchea, se contiene controlando quién puede hablar en la red de acceso.
La receta defensiva es conocida y estable: DHCP snooping y Dynamic ARP Inspection en los switches, port security y 802.1X para el control de acceso, segmentación para reducir el alcance, y cifrado autenticado en todos los servicios para que, incluso si alguien se cuela en medio, no se lleve nada útil. Añade arpwatch o los logs de DAI a tu SIEM y tendrás además el aviso temprano.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)