IPv6 ya no es una tecnología experimental ni una promesa futura. En muchas redes de proveedores de acceso, infraestructuras cloud y entornos corporativos es ya el protocolo predominante. Sin embargo, en numerosas ocasiones su despliegue se realiza sin que los equipos ni herramientas de seguridad tengan una visibilidad completa de su funcionamiento.
Desde la perspectiva de las pruebas técnicas de seguridad esto abre un escenario interesante: redes que operan en dual stack, servicios accesibles por IPv6 que no han sido auditados y mecanismos de autoconfiguración que pueden ser explotados, si no se entienden y configuran correctamente. Otro punto de atención lo constituye el sesgo con el que trabajan la mayoría de los ingenieros de redes y sistemas, que tienen a continuar con las reglas del modelo IPv4 en lugar de entender y plantearse un nuevo modelo. Así algunos de ellos siguen aduciendo que el NAT es una capa adicional de seguridad y apuestan por el uso de NAT66, cuando los mecanismos para saltarse los NAT, como NAT-traversal se estandarizaron hace tiempo.
Esta serie de artículos, publicada desde el IPv6 Council en Madrid, tiene como objetivo explorar IPv6 desde un punto de vista práctico y técnico, utilizando el enfoque y las herramientas habituales en auditoría de seguridad y pentesting.
El enfoque será eminentemente técnico y orientado a pruebas reales. A lo largo de los distintos artículos veremos cómo:
- preparar un entorno de laboratorio IPv6
- analizar el comportamiento del protocolo
- descubrir hosts y servicios
- identificar superficies de ataque
- aplicar técnicas ofensivas específicas sobre IPv6
En este primer artículo nos centraremos en establecer un laboratorio funcional IPv6 y en realizar las primeras verificaciones técnicas que nos permitan entender cómo se comporta el protocolo desde la perspectiva de un auditor de seguridad.
Preparando el entorno de laboratorio
Para las pruebas utilizaremos Kali Linux en nuestro host conectado al laboratorio del Council, una distribución ampliamente utilizada en auditorías de seguridad y análisis de redes.
El entorno de laboratorio utilizará dos fuentes principales de conectividad IPv6:
- una VPN WireGuard hacia el laboratorio IPv6 del IPv6 Council
- conectividad IPv6 sobre redes IPv4 mediante túneles IPv6
El laboratorio IPv6 del Council está patrocinado por la empresa W-A-T, que proporciona infraestructura IPv6 que utilizaremos a lo largo de esta serie para realizar pruebas técnicas y experimentos de seguridad más avanzados.
Mediante esta conectividad dispondremos de visibilidad sobre las máquinas controladas del laboratorio, cuya infraestructura opera exclusivamente sobre IPv6, sin conectividad IPv4 entre los hosts. Además, obtendremos acceso a Internet a través de IPv6, con un enfoque principalmente IPv6-only (si fuera necesario acceder a recursos IPv4, podría habilitarse un mecanismo de traducción mediante NAT64 y DNS64). Todo esto proporcionará un entorno controlado para la realización de pruebas ofensivas y el análisis de servicios desplegados sobre una pila de red IPv6 completa, permitiendo observar su comportamiento sin la intervención de mecanismos heredados de IPv4.
Conectividad IPv6 mediante WireGuard
Una vez establecida la conexión VPN mediante WireGuard podemos verificar la configuración de red del sistema con el comando:
ip a
La salida del comando confirma que la máquina dispone de tres interfaces relevantes: lo, enX0 y enX1.
Las interfaces enX0 y enX1 aparecen activas y con capacidad MULTICAST, algo esperable en un entorno IPv6, donde muchos mecanismos de control y descubrimiento sustituyen el broadcast de IPv4 por multicast. Además, en IPv6 es normal que una misma interfaz tenga varias direcciones simultáneamente con distinto alcance o scope, por ejemplo una dirección global para comunicación normal y una dirección link-local para funciones locales del enlace.
En IPv6 existen distintos tipos de direcciones, pero en un laboratorio como este veremos principalmente dos:
1. Direcciones Link-Local
Pertenecen al prefijo fe80::/10
Estas direcciones se generan automáticamente en cada interfaz IPv6 y están diseñadas para funcionar únicamente dentro del segmento de red local al que pertenece el dispositivo. Su alcance queda limitado a ese enlace, por lo que no pueden ser enrutadas ni utilizadas para comunicarse con equipos situados fuera de la red local.
En términos de funcionamiento de red, se utilizan para procesos esenciales como Neighbor Discovery, la autoconfiguración automática de direcciones y la comunicación directa entre nodos conectados al mismo enlace de red.
Desde la perspectiva de seguridad, muchas operaciones críticas del protocolo IPv6 dependen exclusivamente de direcciones link-local, lo que las convierte en un punto de interés para ataques locales en la red.
2.Direcciones Global Unicast
Las direcciones Global Unicast son el equivalente funcional a las direcciones públicas de IPv4. Normalmente pertenecen a prefijos como 2000::/3, por ello es muy habitual observar direcciones IPv6 que comienzan por 2xxx:
Estas direcciones son globalmente enrutables y únicas en Internet y utilizadas para comunicación end-to-end.
En otras palabras, cuando un host dispone de una dirección Global Unicast puede comunicarse directamente con cualquier otro host IPv6 en Internet sin necesidad de NAT.
Desde la perspectiva de la ciberseguridad, este modelo tiene implicaciones relevantes. En IPv6, una configuración deficiente puede exponer servicios directamente a Internet, ya que desaparece la capa de pseudo-ocultación que suele aportar la traducción de direcciones (NAT) en muchos entornos IPv4, aunque dicha protección nunca ha sido absoluta y puede ser sorteada mediante diversas técnicas. El diseño nativo de IPv6 favorece una conectividad real de extremo a extremo entre hosts, lo que implica que cada dispositivo o servicio puede ser potencialmente alcanzable desde cualquier punto de Internet IPv6 si las políticas de filtrado y control de acceso no están correctamente configuradas. Como consecuencia, las superficies de ataque de cada dispositivo o servicio son potencialmente accesibles desde cualquier punto de Internet IPv6.
Tabla de rutas IPv6
Podemos examinar la tabla de rutas IPv6 con:
ip -6 route
Este comando nos permite identificar el gateway IPv6, el prefijo asignado al laboratorio y las rutas necesarias para alcanzar Internet, otras redes…
El campo proto kernel significa que estas rutas han sido creadas automáticamente por el kernel al asignar direcciones IPv6 a esas interfaces, y su presencia confirma que vm0 tiene conectividad local simultánea en ambos segmentos.
Además, aparecen dos rutas por defecto: una mediante la dirección global 2001:920:580d:f00::1 y otra aprendida automáticamente por Router Advertisement usando la dirección link-local fe80::4c4f:53ff:fef5:ffca en enX0. Esta segunda entrada ilustra muy bien cómo IPv6 utiliza NDP y Router Advertisement para aprender gateways de forma dinámica, sin depender exclusivamente de configuración manual.
Descubrimiento de hosts mediante multicast
A diferencia de IPv4, IPv6 elimina el concepto de broadcast y utiliza multicast para muchas operaciones del protocolo.
Una dirección especialmente interesante es ff02::1. Esta dirección corresponde al grupo all-nodes multicast, que incluye todos los dispositivos IPv6 del enlace local.
Podemos enviar un ping multicast con:
Si existen otros hosts IPv6 en el mismo segmento, estos pueden responder al ping, lo que permite observar qué dispositivos están presentes en la red.
Desde la perspectiva de auditoría, este comportamiento puede utilizarse para descubrimiento rápido de nodos en redes IPv6 locales.
Resolución DNS en IPv6
Los servicios accesibles mediante IPv6 se publican en DNS mediante registros AAAA. La consulta propiamente dicha del registro AAAA puede hacerse sobre IPv4 o sobre IPv6 indistintamente. En nuestro Laboratorio irán por IPv6 salvo que sea necesario (algunos DNS autoritativos podrían no contestar en IPv6). En ese caso se habilitaría un DNS64+NAT64.
Podemos consultarlos con:
dig google.com AAAA
Esto indica que el servicio dispone de una dirección IPv6 accesible públicamente.
En redes dual stack los sistemas operativos modernos suelen aplicar políticas como Happy Eyeballs, eligiendo dinámicamente entre IPv4 e IPv6 según latencia y disponibilidad.
Observando el tráfico IPv6 con Wireshark
Una forma excelente de comprender el funcionamiento del protocolo es capturar tráfico de red. Podemos generar tráfico simple con:
ping6 google.com
En los paquetes capturados podremos analizar la cabecera IPv6, que contiene campos como:
- Version
- Traffic Class
- Flow Label
- Payload Length
- Next Header
- Hop Limit
- Source Address
- Destination Address
A diferencia de IPv4, IPv6 simplifica la cabecera base y delega funcionalidades adicionales en extension headers, lo cual tiene implicaciones relevantes en sistemas de inspección de tráfico y seguridad.
Neighbor Discovery (ND)
IPv6 reemplaza el protocolo ARP utilizado en IPv4 mediante Neighbor Discovery Protocol (NDP).
NDP utiliza mensajes ICMPv6 para llevar a cabo funciones esenciales para el funcionamiento de una red IPv6. Entre ellas se encuentran el descubrimiento de nodos vecinos, la resolución de direcciones MAC asociadas a direcciones IPv6, la detección y localización de routers disponibles en el enlace, así como el mantenimiento de la conectividad local mediante diversos mecanismos de verificación y actualización de información sobre los dispositivos presentes en la red.
Los mensajes principales son:
- Neighbor Solicitation
- Neighbor Advertisement
- Router Solicitation
- Router Advertisement
Podemos observar estos mensajes capturando tráfico con Wireshark mientras interactuamos con otros hosts.
En la siguiente imagen se puede observar el intercambio Neighbor Solicitation/Neighbor Advertisement entre vm0 y lab-gw:
También el paquete de router Solicitation:
NDP es especialmente relevante porque es susceptible a diferentes ataques locales, como: NDP spoofing, MITM en redes IPv6, Interceptación de tráfico local…
Autoconfiguración de direcciones (SLAAC)
Una característica fundamental de IPv6 es la Stateless Address Autoconfiguration (SLAAC).
Mediante SLAAC, un host puede obtener automáticamente una dirección IPv6 válida utilizando:
- un prefijo anunciado por el router
- un identificador de interfaz
Este proceso se basa en mensajes Router Advertisement (RA) enviados por routers de la red. Podemos observarlos capturando tráfico en la interfaz local del laboratorio:
Los campos de tiempo de vida también son relevantes: valid time 86400s (24 horas) indica cuánto tiempo es válida la dirección generada, y pref. time 14400s (4 horas) marca el periodo durante el cual se prefiere esa dirección para nuevas conexiones. El campo router lifetime 1800s indica que los nodos deben considerar este router como gateway válido durante 30 minutos si dejan de recibir anuncios.
Podemos ver el resultado en la tabla de direcciones de vm0:
En este laboratorio vm0 tiene configurada estáticamente la dirección 2a0e:a980:ff00::1000 dentro del prefijo anunciado por el RA — por eso aparece con valid_lft forever en lugar de un tiempo de vida limitado. Una dirección generada por SLAAC puro tendría un sufijo derivado de la MAC de la interfaz (por ejemplo 2a0e:a980:ff00::4c4f:53ff:fef5:ffcb) o uno aleatorio si el sistema usa Privacy Extensions, y mostraría los tiempos de vida anunciados en el RA.
Esto simplifica enormemente la configuración de redes IPv6, pero también introduce implicaciones de seguridad importantes. Un atacante con acceso al segmento local podría enviar Router Advertisements falsos para anunciar un prefijo y un gateway bajo su control, logrando redirigir el tráfico de todos los hosts que procesen ese RA, introducir gateways maliciosos o interceptar comunicaciones de forma transparente. Este tipo de ataques, conocidos como Rogue Router Advertisements, se analizará en detalle en artículos posteriores.
Escaneo de hosts IPv6 con Nmap
La herramienta Nmap soporta escaneo de hosts IPv6 mediante la opción -6.
Por ejemplo:
nmap -6 -Pn -sV 2a0e:a980:ff00::CAFE:1001
Sin embargo, IPv6 introduce un cambio fundamental en la forma de realizar descubrimiento de hosts.
Un prefijo típico /64 contiene 264 direcciones (exactamente 18.446.744.073.709.551.616)
Esto hace que los métodos tradicionales de escaneo exhaustivo utilizados en IPv4 sean completamente impracticables.
Por tanto el descubrimiento de hosts en redes IPv6 requiere técnicas diferentes, como análisis de tráfico, observación de Neighbor Discovery, enumeración de DNS y heurísticas sobre direccionamiento. Existe una RFC de IETF en la que se ha abordado precisamente que, a pesar de que es costoso, existen técnicas para descubrir o predecir de alguna manera las direcciones a tacar. Es la RFC 7707 “ Network Reconnaissance in IPv6 Networks” accesible aquí.