Reglas de cortafuegos que olvidan IPv6

En un equipo con las dos familias activas (doble pila) el tráfico IPv4 y el IPv6 son flujos distintos y los evalúa un conjunto de reglas distinto. Una regla escrita para IPv4 no se aplica a un paquete IPv6, aunque el servidor y el servicio sean los mismos. Si la política IPv6 no existe o es más abierta, lo que se bloqueó para IPv4 puede seguir accesible por IPv6.

La guía de seguridad operativa (RFC 9099) lo advierte: los sistemas operativos traen IPv6 activo por defecto, de modo que incluso en una red «solo IPv4» se puede alcanzar a equipos del mismo segmento por su dirección de enlace local.

Al revisar un conjunto de reglas hay un método simple: por cada regla de bloqueo IPv4, encontrar la que hace lo mismo en IPv6. La columna equivalente_v6 ya dice cuál es, o ninguna. Las reglas de permitir que no se copiaron son un descuido de otra clase (el servicio funciona menos de lo debido); los bloqueos que no se copiaron son el hueco: lo que se cerró para una familia queda abierto en la otra.

Filtra reglas_v4 por ninguna y quédate con la que niega tráfico.

En IPv4 las redes internas suelen usar direcciones privadas y salir por una traducción de direcciones (NAT). Mucha gente cree que esa traducción es lo que las protege. No lo es: la guía de diseño de protección de redes locales en IPv6 (RFC 4864) explica que traducir bits de una cabecera no da seguridad por sí mismo, y que la protección que se atribuye al NAT la da el filtrado con estado. En IPv6 cada equipo suele tener una dirección global; si la política lo permite, es alcanzable desde fuera, y no hay traducción que lo esconda.

Por eso una regla IPv6 que permite «cualquiera hacia la red de servidores» es más grave que su hermana de IPv4: no hay nada entre Internet y el servidor sino la propia regla.

Revisa reglas_v6 y busca la que permite cualquier origen y cualquier servicio hacia la red de servidores.

En IPv4 mucha gente bloquea todo el ICMP. En IPv6 no se puede: el ICMPv6 es parte del funcionamiento. Los routers no fragmentan los paquetes IPv6, y cuando uno es demasiado grande responden con el mensaje Paquete demasiado grande (tipo 2); sin él el emisor no se entera y algunas conexiones se cuelgan. La guía de filtrado de ICMPv6 (RFC 4890) lista los mensajes que no deben descartarse en tránsito: destino inalcanzable (tipo 1), paquete demasiado grande (2), tiempo excedido (3, código 0), problema de parámetro (4, códigos 1 y 2) y la petición y respuesta de eco (128 y 129). Dentro del enlace, además, el descubrimiento de vecinos (tipos 133 a 137) tampoco puede cortarse.

Una regla que descarta todo el ICMPv6 rompe eso. Lo correcto es permitir los tipos necesarios y descartar el resto.

Para dejar el hallazgo medido hace falta una cifra: de las reglas del conjunto IPv4, ¿cuántas tienen una equivalente en el conjunto IPv6? Cuenta las filas de reglas_v4 cuya columna equivalente_v6 no dice ninguna. En el informe esa cifra acompaña a la lista de las que faltan, con su acción.