Mitos sobre la seguridad en IPv6: desmontando falsas ideas
Con el paso del tiempo, han surgido diversos mitos sobre las propiedades y características de seguridad de IPv6. Este artículo técnico ofrece una evaluación realista de IPv6 desde la perspectiva de la seguridad y desmantela muchos de los mitos que aún subsisten sobre sus capacidades de seguridad.
IPv6, la última versión del Protocolo de Internet, está llamado a coexistir con IPv4, y finalmente a sustituirlo, proporcionando un mayor espacio de direcciones que permita impulsar el crecimiento de internet en los próximos años. Sin embargo, desde la especificación inicial del protocolo, han surgido diversos mitos sobre sus propiedades en el ámbito de la calidad del servicio (QoS), las características “plug-and-play” y especialmente la seguridad. Muchos de estos mitos han sido alimentados por los defensores de IPv6, quizás pensando que sus promesas publicitarias estimularían el despliegue de IPv6. Desgraciadamente, no sólo han fallado en su intento (IPv6 sólo se está implantando últimamente porque se están agotando las direcciones en v4), sino que muchos de esos mitos han sido tomados por realidades, lo que genera falsas expectativas sobre las propiedades y características que ofrece IPv6. Veamos cuáles son los mitos más comunes de IPv6 en relación con la seguridad del protocolo:
Mito Nº1. “IPv6 es más seguro que IPv4, ya que la seguridad se ha tenido en cuenta durante la fase de diseño del protocolo y no ha sido un elemento añadido a posteriori”. Los orígenes de este mito se remontan a la primera especificación de IPv6. En aquel momento, el soporte IPsec era obligatorio para IPv6, se esperaba un amplio despliegue de IPv6+IPsec a corto plazo y se pensaba que los proveedores no se molestarían en añadir soporte IPsec a sus implementaciones IPv4. Sin embargo, estas previsiones no se cumplieron: casi todas las implementaciones más populares de IPv4 incorporaron soporte para IPsec, y el conjunto IPv4+IPsec se desplegó mucho antes que cualquier despliegue significativo de IPv6 (por no citar el binomio IPv6+IPsec). También se suele decir que el traductor de direcciones de red (NAT) habría impedido el despliegue de IPsec para end-to-end, y que dado que IPv6 iba a eliminar la necesidad de NAT (ver el Mito nº3), el uso de IPsec end-to-end se haría omnipresente. Esta idea es falsa, ya que muchos (por no decir todos) los factores que han impedido el despliegue generalizado de IPsec para un uso general con IPv4 (como el requisito de una Infraestructura de Clave Pública) siguen estando presentes con IPv6. Aunque los informes y artículos recientes siguen alimentando la creencia de que los despliegues IPv6 darán lugar a un aumento del uso de IPsec, esta idea está más basada en la esperanza que en la realidad.
Mito Nº2: “IPv6 regresará el principio end-to-end a internet, por lo que las arquitecturas de seguridad pasarán de centrarse esencialmente en la red a centrarse en el host”. Uno de los principios básicos del diseño de internet es el conocido “principio end-to-end” , basado en la existencia de una “red tonta”, donde la mayoría de la “inteligencia” o de las capacidades de toma de decisiones complejas reside en los hosts. Este principio da lugar a una arquitectura en la que la red se limita a enviar datagramas desde un host de origen a un host de destino (o a un conjunto de hosts) sin efectuar una interpretación de los datagramas enviados. En internet IPv4, este principio es violado por distintos dispositivos, siendo los NATs en IPv4 probablemente los más conocidos y ampliamente desplegados. Se dice que una internet IPv6 exclusiva sin despliegue de NATs IPv6 (ver mito nº3) devolvería el principio del end-to-end a internet. Sin embargo, debemos señalar que aunque la gran cantidad de espacio de direcciones de IPv6 podría proporcionar direcciones IP únicas a cada dispositivo conectado a internet, para muchos usuarios o administradores de seguridad el principio end-to-end no es necesariamente una propiedad deseada.
Por ejemplo, los administradores quizás no quieran que cada host de una red sea directamente accesible desde cualquier host arbitrario en internet, una consecuencia no intencionada de IPv6 que podría dejar a la red expuesta a ataques exteriores. Por ello, los administradores quizás prefieran una arquitectura de red donde sólo se permita el tráfico de retorno (es decir, que sólo se permite el tráfico entrante en respuesta a comunicaciones originadas en la red interna).
Por consiguiente, lo más seguro sería proteger las subredes IPv6 típicas con un firewall de estado que sólo permita las comunicaciones originadas en la red interna. De esta manera, al menos en lo tocante al filtrado de paquetes, la arquitectura de la subred IPv6 típica no será diferente de una subred IPv4 típica. A título ilustrativo, un reciente trabajo de la Internet Engineering Task Force (IETF) sobre capacidades simples de seguridad en Equipos Locales del Cliente (CPE) parece abogar en esa dirección.
Mito Nº3: “Las redes IPv6 ya no tendrán NATs”. Este mito está muy relacionado con el mito Nº2 y se basa en la hipótesis de que IPv6 proporciona mucho más espacio de direcciones y los NATs ya no se desplegarán en las redes IPv6. Sin embargo, esta idea merece un análisis más profundo.
Durante la fase de coexistencia entre IPv6 e IPv4 y de transición hacia una internet exclusivamente basada en IPv6 (suponiendo que esto último esté comenzando ya), se ha producido un uso creciente de NATs. Por un lado, dado que la mayor parte de las tecnologías de transición/coexistencia no dispensan a los hosts de la necesidad de direcciones IPv4, lo más probable es que se desplieguen los llamados NATs a gran escala o Carrier-Grade NATs(CGNs), generando así un uso creciente de NATs en internet IPv4. Por otro lado, la única tecnología de transición/coexistencia que sí dispensa a las redes de la necesidad de direcciones IPv4 es NAT64, que permite la comunicación entre nodos IPv6 y nodos IPv4, pero a su vez introduce otro tipo más de NAT, tanto en internet IPv4 como en internet IPv6.
El potencial de despliegue de los traductores de direcciones de red/traductores de puertos (NAT-PTs) en Internet IPv6 también merece un análisis detallado. Si bien los NATs de IPv4 fueron introducidos como una solución provisional ante el rápido consumo de direcciones en IPv4, generalmente son percibidos como beneficiosos en el campo del enmascaramiento de hosts/redes y en el bloqueo de conexiones entrantes a la red interna (ya que, como efecto secundario de su modo de funcionamiento, el dispositivo NAT solo permite las conexiones iniciadas desde la red interna). Aunque se puede alegar que el bloqueo de las conexiones entrantes es fácil de conseguir con un firewall de estado normal (sin traducción de direcciones y puertos), y que el enmascaramiento de hosts/redes no añade mucho en términos de seguridad, también es cierto que los seres humanos suelen resistirse a los cambios: por ello, algunos administradores de redes diseñan sus subredes IPv6 de forma que imiten las subredes IPv4, es decir, desplegando un NAT-PT para IPv6 que actúa como pasarela de internet para los nodos internos. Así que en la mayoría de los escenarios de arquitecturas de red IPv6, parece que el NAT seguirá perdurando.
Mito Nº4: “El gran espacio de direcciones de IPv6 imposibilitará los escaneos de direcciones IPv6”. Se supone que el aumento de espacio de direcciones en IPv6 imposibilitará el escaneo de direcciones IPv6. Sin embargo, esta afirmación se basa en dos hipótesis que no son necesariamente ciertas en todos los casos. Primero, se da por supuesto que las direcciones de host IPv6 estarán uniformemente distribuidas por todo el espacio de direcciones asignado a la subred correspondiente. Segundo, se supone que un atacante sólo podrá efectuar un escaneo de direcciones utilizando la fuerza bruta.
Sin embargo, diversos estudiossobre las políticas empleadas para asignar direcciones IPv6 indican que no están uniformemente distribuidas; más bien siguen patrones específicos, como los resultantes de las configuraciones automáticas sin estado (SLAAC), configuración manual o uso de tecnologías de transición/coexistencia con IPv6. Además, ya se ha descubierto en estado salvajeque los atacantes no efectúan el escaneo de direcciones IPv6 mediante la fuerza bruta, sino que intentan mejorar sus métodos de escaneo aprovechando los ya conocidos patrones de asignación de direcciones IPv6.
Los ataques mediante escaneo de direcciones pueden ser mitigados de distintas formas. Primero, las denominadas “direcciones de privacidad” especificadas en RFC 4941 serían preferibles a los “Identificadores de Interfaz basado en el formato EUI-64 modificado” que se suelen utilizar en la configuración automática de direcciones sin estado. Además, como se indica anteriormente, otra solución es desplegar en el perímetro de la organización un firewall con estado que únicamente permita el tráfico de retorno, de manera que los paquetes de exploración enviados por el atacante nunca lleguen hasta los hosts internos.
Debemos señalar, asimismo, que la razón por la que son habituales los ataques de escaneo de direcciones en IPv4 mediante la fuerza bruta es porque el limitado espacio de direcciones de dicho protocolo facilita ese procedimiento al atacante (o, dicho de otro modo, no le compensa el esfuerzo de desarrollar otras estrategias de escaneo de direcciones más sofisticadas/fundamentadas). Esto significa que los escaneos de direcciones IPv6 no sólo serán más “fundamentados” sino que, además, es posible que los atacantes empleen otras estrategias de reconocimiento de red, como la identificación de hosts “vivos” desde las direcciones IPv6 filtradas por los protocolos de capa de aplicación (por ejemplo, cabeceras de e-mail), posiblemente en combinación con alguno de los populares motores de búsqueda en internet. El objetivo de este artículo ha sido arrojar luz sobre los distintos mitos surgidos en torno a las características de seguridad de IPv6 . Dado que es prácticamente imposible lograr un despliegue seguro de IPv6 sin hipótesis o expectativas realistas, nos parece necesario hacer un análisis a fondo de los citados mitos de seguridad en IPv6. ****
Acerca del autor: Fernando Gont es consultor en materia de redes y seguridad que ha trabajado en diversos proyectos en nombre de National Infrastructure Security Coordination Centre (NISCC) y el Centre for the Protection of National Infrastructure (CPNI), dos organismos del Reino Unido. Dentro de su labor para estas organizaciones, ha escrito una serie de documentos con recomendaciones para ingenieros de redes e implementadores de la suite del Protocolo de Internet. Gont es miembro activo de la Fuerza de Tareas de Ingeniería de Internet (IETF), donde participa en diversos grupos de trabajo y ha elaborado varios RFCs (solicitud de comentario). Asimismo, es ponente habitual en diversas conferencias, ferias de muestras y encuentros técnicos sobre seguridad informática, sistemas operativos e ingeniería de internet. Pueden encontrar más información en su Web: Gont's web site.
