Seguridad en IPv6: consideraciones que no debes ignorar

Es tentador tratar IPv6 como un sustituto directo de IPv4 que simplemente tiene un espacio de direcciones mayor. En materia de seguridad, hay unas cuantas diferencias reales que conviene entender en lugar de suponer que todo lo de IPv4 se aplica sin cambios.

La lista de bloqueo hay que construirla por separado, no solo hacerla más larga

IPv6 tiene sus propios rangos privados, de bucle local y de enlace local, estructurados de forma distinta a sus equivalentes de IPv4. Una comprobación de seguridad que solo sabe analizar y filtrar rangos IPv4 dejará pasar sin avisar todos estos del lado de IPv6; no porque IPv6 sea menos seguro, sino porque las protecciones equivalentes simplemente nunca se construyeron para él.

Direcciones IPv4 mapeadas: un punto ciego fácil de pasar por alto

IPv6 tiene una notación para incrustar una dirección IPv4 dentro de una IPv6 (por ejemplo, ::ffff:127.0.0.1, que se refiere a la misma dirección de bucle local que 127.0.0.1 a secas, solo que escrita en forma IPv6). Una comprobación que filtra correctamente el bucle local de IPv4 pero no desenvuelve esta forma incrustada aprobará una dirección funcionalmente idéntica a otra que habría bloqueado de plano.

• Cualquier sistema que compare las direcciones resueltas con una lista de bloqueo necesita una lógica realmente separada y completa para IPv6, no la suposición de que las reglas de IPv4 se generalizan automáticamente.
• Las direcciones IPv6 mapeadas a IPv4 deben desenvolverse y comprobarse específicamente con las reglas de IPv4, no evaluarse como direcciones IPv6 opacas.
• Los sistemas de doble pila (la mayoría de los modernos) necesitan que ambas comprobaciones se apliquen de forma coherente, porque un atacante usará simplemente la familia de direcciones en la que la comprobación sea más débil.

Nada de esto es un motivo para evitar IPv6: una adopción más amplia suele ser algo bueno, y la superficie de ataque específica de IPv6 no es intrínsecamente mayor que la de IPv4. Es un motivo para asegurarse de que la lógica de seguridad que maneja las direcciones se haya construido y probado realmente con ambas familias de direcciones, y no con una de ellas y la otra añadida como ocurrencia tardía.

NAT64 añade una segunda capa de traducción que conviene conocer

Algunas redes solo IPv6 usan NAT64 y DNS64 para que sus clientes puedan seguir llegando a la parte de internet que solo admite IPv4: DNS64 sintetiza al vuelo un registro AAAA para un dominio que solo tiene un registro A, incrustando la dirección IPv4 dentro de un prefijo especial (64:ff9b::/96 es el valor predeterminado más conocido), y NAT64 traduce el tráfico hacia esa dirección sintética de vuelta a IPv4 real en el borde de la red. Es un mecanismo legítimo y útil, pero implica que una dirección que cae en ese rango concreto no es una dirección IPv6 pura que evaluar por sí sola: es IPv4 disfrazada de IPv6, y hay que desenvolverla y comprobarla con las reglas de IPv4 igual que una dirección IPv4 mapeada.

Probar la lógica de seguridad significa probar ambas familias

Es fácil que las pruebas automatizadas se inclinen silenciosamente hacia IPv4: la mayoría de los dominios de ejemplo, de los datos de prueba y de las comprobaciones manuales rápidas lo usan por defecto sin que nadie lo decida de forma deliberada. Un conjunto de pruebas para cualquier cosa que resuelva y filtre direcciones es tan fiable como su cobertura de IPv6: los casos de los rangos privados, de bucle local y de enlace local anteriores, de una dirección IPv4 mapeada y de una dirección sintetizada al estilo NAT64 merecen cada uno sus propias aserciones explícitas, no solo un «seguramente funciona igual». El código de seguridad que maneja direcciones es justo el tipo de lógica donde una ruta de código sin probar y una rota son indistinguibles hasta que un atacante encuentra la diferencia antes que tú.