Indice


Después de muchos años que se venía avisando, el año 2011 marca el agotamiento del espacio de direcciones IP version 4, (IPv4) por lo que empieza a ser necesario el despliegue IP versión 6 (IPv6). Este documento pretende complementar el informe que INTECO-CERT elaboró en el año 2010 sobre las implicaciones de seguridad en la implementación de IPv6 que se pude descargar de las guias de INTECO , centrandose en como puede afectar a las instituciones afiliadas a RedIRIS el despliegue de IPv6 en su red, intentando proporcionar unas recomendaciones prácticas para un despliegue mínimo de IPv6 sin comprometer las medidas de seguridad existentes.

Se presupone que la organización tiene un direccionamiento IPv6 asignado, así como un plan de direccionamiento, tal y como se explica en las la información del NOC de RedIRIS

La guia de seguridad de INTECO-CERT considera tres diferentes aspectos a la hora de tratar los aspectos de seguridad, técnicos, de gestión y propios del protocolo, en este documento se va a seguir la misma estructura, de forma que sirva como complemento a esta guia.

Aspectos técnicos

En este apartado se estudio el impacto que puede el despliegue de IPv6 en la infraestructura técnica de la red y en la seguridad de esta.

Dispositivos de seguridad que no analizan el protocolo IPv6

El primer problema que puede plantear el despliegue de IPv6 en la institución es que los dispositivos de seguridad y red no analicen y/o comprendan el protocolo IPv6. Esta limitación afecta de distinta forma a los distintos elementos de red.

Presencia de dispositivos de los que se desconoce que puedan usar IPv6 y túneles IPv6

IPv6 es un protocolo que lleva varios años en el mercado y más sistemas operativos que los que parece tienen soporte para IPv6, dependiendo de la versión del Sistema Operativo (Windows XP, Vista Windows 7) y de la versión de la release /patch el equipo puede intentar obtener una dirección IPv6 mediante un túnel, empleando para ello diversos mecanismos, que se explican más adelante denominados 6to4 y Teredo.

Así mismo hay algunas empresas que proporcionan direccionamiento IPv6 gratuito empleando túneles empleando un protocolo denominado 6in4 , que se puede confundir con 6to4, todos estos túneles al final pueden ser un mecanismo por el cual se produzcan fugas de información , dificulte el análisis de tráfico y ponga en peligro los sistemas al tener estos equipos direcciones IPv6 que seguramente no estén protegidas por las políticas de seguridad de los cortafuegos de la organización.

Existen principalmente tres tipos de túneles:

  1. Tuneles 6in4:,(Wikipedia Hurricane Networky otros proveedores. las direcciones IPv6 que se obtienen dependen del proveedor, ya que son direcciones IPv6 asignadas por a ellos. . Estos túneles deben ser solicitados por los usuarios y configurados manualmente por lo que pueden ser fáciles de detectar y controlar. Para la encapsulación se emplea el tipo de protocolo "41" , en el paquete IP.

  2. Túneles 6to4),(Wikipedia) Empleado por defecto en muchos sistemas Windows como se ha comentado antes, donde se configuran por defecto si el equipo tiene una dirección IPv4 pública. Estos túneles se establecen contra diversos servidores de Túneles desplegados geográficamente). Las direcciones IPv6 obtenidas tienen la peculiaridad de que tienen el siguiente formato.

    Poner imagne.

    Estos túnles se confunden muchas veces con los túneles 6in4 ya que emplean el mismo tipo de paquete IP (protocolo 41) para su conexión sin embargo las direcciones IPv6 generadas empiezan siempre por "2002" y llevan incluido como se ve en el gráfico la dirección del servidor de túneles y la dirección IPv4 origen de la conexión.

  3. Tuneles Teredo:,(Wikipedia) como mucha veces los equipos se encuentran detrás de un sistema NAT, dentro de la "dominación Global de Microsoft", los sistemas Windows proporcionan un servicio de túneles cuando los sistemas se encuentran detrás de un NAT, denominado TEREDO, RFC 4380 Este protocolo emplea conexiones UDP al puerto 3544 de un equipo configurado como servidor de túneles.

    Las direcciones IPv6 de los túneles TEREDO deben empezar siempre por "2001:0000:/32" , y el formato de la dirección se incluye no solamente la dirección IPv4 del servidor de túneles sino también la dirección IPv4 publica del router NAT, omo se ve en el siguiente esquema:

    poner imagen

    Existe una red de servidores Teredo, anunciados por Anycast en diversos proveedores al igual que en Microsoft para el procesamiento de este tráfico TEREDO

En muchas versiones de los sistemas Windows los mecanismos de túneles 6to4 y Teredo se activan por defecto salvo que se deshabilite expresamente en la configuración de los interfaces o se detecte que la red soporta IPv6 (ya sea por DHCPDv6 o por el descubrimiento de anuncios IPv6 mediante el protocolo de NDP para el anuncio de rutas.

En primer lugar esto significa que cuando se active IPv6 en un interface del router, puede haber más equipos de los esperados hablando IPv6, ya que muchos equipos emplean (YYYY Miguel) par asignar una dirección IPv6 automáticamente en base al prefijo anunciado y la dirección MAC del equipo.

Todo esto significa en primer lugar que desde el primer momento se debe plantear las redes que tengan IPv6 con reglas en los cortafuegos que por defecto bloqueen todo el tráfico no explícitamente permitido, para evitar que estos equipos con IPv6 sean alcanzables desde el exterior, sobre todo en aquellas redes en las que haya equipos de producción o en los que se quiera tener unos requisitos mínimos de seguridad, De no hacer esto se podría tener una situación parecida a de la segunda mitad de los años 90, en los cuales muchas redes locales que compartían recursos (impresoras, ficheros) mediante el protocolo NetBIOS sobre ethernet, eran accedidas desde el exterior al no haber reglas bloqueando los puertos de NetBIOS sobre TCP/IP, con el agravante de que este tipo de accesos puede ser ahora mucho más dañinos.

Para mitigar el efecto de los túneles y además poder tener controlado que equipos tienen esta funcionalidad activada se pueden tomar las siguientes medidas.

  1. Bloquear y generar un registro/log (o al menos almacenar flujos de NetFlow) de las conexiones con destino el puerto 3544/UDP que es empleado por defecto por los sistemas de Teredo, 6in4 y 6to4, de forma que se pueda tener información sobre que el número de equipos con IPv6.

  2. Si no se desea bloquear este tráfico es posible instalar un servidor de túneles TEREDO propio, existe un software denominado Miredo , que permite implementar un servidor de túneles TEREDO en nuestra organización, aunque requiere que este servidor tenga conectividad IPv6 , desde RedIRIS se esta planteando la posibilidad de ofertar un servidor de túneles TEREDO para las instituciones afiliadas

  3. Por defecto el servicio de túneles TEREDO no se activa si equipo detecta que se tiene una dirección IPv6 valida, por lo que si se activa IPv6 pero después se rechaza a nivel de cortafuegos todo el tráfico que no se desee, se elimina esta amenaza. <

    /li>

Esta medidas son complementarias,entre si, es decir, se debe intentar bloquear el trafico de túneles siempre que sea posible , sobre todo porque puede ser utilizado por atacantes para implementar túneles desde máquinas comprometidas al exterior (la dirección a la que se conectan los equipos que usan TEREDO es variable y puede ser cambiada por configuración), por lo que la posibilidad de que se pueden establecer estos túneles debe ser siempre tenida en cuenta.

Así mismo indicar que desde hace varios años se viene observando el uso de túneles 6to4 por parte de atacantes, para enviar información a una máquina de control sin que fuera detectada por los atacantes

Desaparición de NAT

Aunque gran parte de las instituciones afiliadas a RedIRIS disponen de un rango de direccionamiento IPv4 aceptable para las necesidades, en muchas instalaciones se emplea direccionamiento privado (RFC1918), presuponiendo que el uso de técnicas NAT supone una medida de seguridad, la experiencia ha demostrado que aunque el NAT elimina en gran parte la posibilidad de ataques a nivel de conexión desde el exterior, no hace los equipos menos vulnerables a otro tipo de problemas, por lo que siguen infectandose sistemas en redes NAT continuamente.

Con el mayor direccionamiendo que supone IPv6 gran parte de los sistemas que ahora mismo disponen de una dirección NAT pasaran a tener una dirección IPv6 global, alcanzable desde Internet, por lo que esta protección de "cortafuegos" que proporcionaba NAT desaparece , por lo que hay que volver a hacer hincapié en el despliegue de sistemas de cortafuegos IPv6 como parte integral de la instalación de IPv6 en la organización.

Necesidad de multicast e ICMP

En muchos entornos se aplican reglas a nivel de filtrado en cortafuegos y routers para bloquear el tráfico multicast y/o gran parte del tráfico ICMP, como medidas de seguridad que intentan evitar que desde el exterior un atacante pueda obtener información sobre los equipos en la organización, así como evitar algunos ataque por redirección de trafico (IMCP redirect).

Sin embargo IPv6r requiere ambos protocolos para el correcto funcionamiento de la red, por lo que es necesario permitir el transito de paquetes de estos tipos y se deben permitir gran parte del trafico ICMPv6 para el correcto funcionamiento de la conexión.

Monitorización de la red

Mientras que el despliegue de IPv4 en muchas organizaciones se hizo de una forma progresiva, muchas veces en función de la infraestructura y equipamiento de comunicaciones, es posible que IPv6 tenga un despliegue inicial más corto en las organizaciones (aunque el tráfico final resultante sea menor debido al uso de sistemas de doble pila), por lo que la monitorización del trafico IPv6 debe considerarse prioritaria para poder detectar problemas de seguridad.

Es muy recomendable el uso de NetFlow para tener información sobre el tráfico IPv6 que circula por nuestra red, la versión 9 de Netflow soporta la exportación de flujos de IPv6. En caso de que el equipamiento de red no pueda soportar el uso de esta versión de Netflow y si se dispone de mecanismos de copia de puertos (por mirroring) para sistemas de detección de intrusos, es posible utilizar un equipo Unix/Linux que mediante programas de código abierto como softflowd, permitan la exportación de flujos en versión 9.

Así mismo y como se ha comentado en la sección de dispositivos hay que revisar si los cortafuegos e IDS tienen un soporte completo o solamente parcial para IPv6 ya que es posible que no todas las funcionalidades soporten este protocolo.

Doble exposición IPv6 e IPv4

La misma gente que indicaba que la solución a todos los problemas de seguridad era el uso de un sistema de PKI basado en certificación X.509, hacen hincapié en que IPv6 es intrinsicamente mas seguro que IPv4, motivado sobre todo por la existencia de IPSec dentro de la pila IPv6, la realidad es que IPSec existe también sobre IPv4 desde hace más de 12 años y aún así se siguen produciendo problemas de seguridad.

Tanto IPv6 como IPv4 funcionan en la famosa "capa de red" de los protocolos OSI, mientras que los problemas de seguridad mas importantes en los ultimas años son debidos a problemas en las aplicaciones y técnicas de ingeniería social, por lo que se seguirán produciendo con independencia del protocolo de red empleado.

En foro sobre IPv6 ya se indicaba la facilidad para convertir ataques sobre IPv4 a IPv6 empleando aplicaciones que se encuentran en cualquier equipo Linux reciente, por lo que se debe tener controlado y vigilada esta doble exposición de servicios y aplicaciones en IPv6.

Actualización de protocolos y equipos a IPv6

Aunque IPv6 como estándar lleva varios años , la implementación de aplicaciones que usen IPv6 puede requerir actualizaciones de Software y aún de hardware , así mismo es posible que no todas las características de IPv6 estén implementadas. En este apartado pasamos a indicar algunos problemas que pueden surgir en diversos sistemas operativos y equipamiento con la implantación de IPv6, la lista no es exhaustiva y se debe revisar la información del fabricante en cuestión.

Linux

Correo electrónico

Si los servidores de correo soportan IPv6 , es necesario que el registro SPF incluya las direcciones en IPv6 desde las que se va a enviar correo, además se debe contactar con el servicio ESWL de RedIRIS para incluir las direcciones IPv6 en la lista blanca. Desde RedIRIS se considera que se debe hacer hincapié en el uso de mecanismos como SPF y DKIM desde el inicio del despliegue de IPv6 para evitar los problemas que surgen habitualmente de SPAM en IPv4.

Para aquellas instituciones afiliadas que empleen el servicio Lavadora de RedIRIS, se ha indicado por las listas de coordinación como se pueden emplear un mecanismo de No listing para recibir correo en IPv6 en un servidor de correo de la organización, desde RedIRIS se esta trabajando para la generación de una lista de reputación SMTP que soporte IPv6 y que permita eliminar el spam que ya se empieza a detectar en IPv6

Consideraciones de Gestion

Curva de aprendizaje

Como todas las nuevas tecnologías la implementación de IPv6 requiere un periodo de adaptación y aprendizaje, afortunadamente la experiencia acumulada en seguridad sobre protocolos IPv4 tiene que servir para reducir estas necesidades , como se ha comentado en el resto de secciones de este documento es poco probable que se produzcan muchos ataques específicos debidos a vulnerabilidades en la implementación del protocolo IPv6 o en los sistemas operativos que los soportan, por lo que los ataques que se produzcan sobre IPv6 seguirán teniendo los mismos vectores de ataque:

Para evitar que haya problemas de seguridad en las redes IPv6 hay que considerar como parte integral de la implementación de seguridad, al mismo nivel que puede ser el plan de direccionamiento o la configuración de los servicios básicos lo siguiente:

  1. Sistemas de monitorización de trafico, como se ha comentado antes gran parte de los dispositivos de red que soportan IPv6 soportan la generación de flujos version 9, y hay soluciones tanto comerciales como de código abierto , por ejemplo NFsen , para almacenar el trafico de red, es posible que cuando empiece a crecer el trafico IPv6 se deba recurrir al muestreo (recoger solamente un porcentaje de paquetes) de los flujos, pero inicialmente se debe empezar a almacenar y monitorizar el trafico en IPv6.
  2. Puesta en marcha desde el principio de cortafuegos, tanto para la protección de los servicios institucionales como para los usuarios, con la puesta en marcha de IPv6 muchos equipos que se encuentran en la actualidad tras sistemas NAT pueden ser accesibles directamente desde internet con el peligro que esto puede producir, siempre que sea posible es se deben implementar políticas de "denegación por defecto", de forma que solamente aquello que este explícitamente indicado pueda salir o entrar desde el exterior de la red a esta, bloqueando el resto.

Implementación de sistemas de doble pila

A nivel de gestión de la seguridad habrá que considerar que las direcciones de cada equipo aumentan , lo que equivale a que todos aquellos filtros y medidas que antes solamente se aplicaban en IPv4 habrá que aplicarlos en las direcciones IPv6 de los equipos.

Así mismo y dado que gran parte de los desarrollos en IPv6 están pensados para usar un protocolo por defecto y en caso de no estar disponible emplear el otro, hay que verificar siempre que la información que se mantiene en DNS esta actualizada correctamente y que se tienen en cuanta todas las posibilidades.

Estructura o características propias del protocolo

IPv6 tiene algunas características nuevas, que seguramente ocasionarán algunos problemas a la hora de del despliegue, como son:

Suplantación de identidad en la autoconfiguración de direcciones IPv6

Este es seguramente uno de los aspectos en los que más controversia ha habido, Los equipos con pila IPv6 disponen por lo general de una dirección de enlace, que comienza por "fe80::" y que esta basada en la la dirección MAC del interface ( RFC 4861 ) , y una dirección IPv6 global, que en el caso de las instituciones afiliadas a RedIRIS comienza por "2001:0720". Para la obtención de esta dirección IP y demás opciones de configuración hay varios supuestos.

Como solución general al problema de suplantación de identidad el protocolo SEND ( Secure Neighbor Discovery: http://tools.ietf.org/html/rfc3971), permite emplear autenticación basada en un intercambio de clave asimétrica y firma electrónica, pero todavía no esta implementado en algunos sistemas operativos y requiere una configuración inicial (intercambio de la clave, configuración de esta, etc) por lo que presupone un despliegue tan complicado como puede ser la asignación estática.

Como recomendación general , la opción de DHCPDv6 o el empleo del protocolo de descubrimiento se pueden emplear en redes donde no se requiera una seguridad muy alta y donde existan usuarios "visitantes", el caso más lógico parece ser los accesos Wireless mediante la red Eduroam.

En entornos departamentales, donde no sea probable los ataques de "man in the middle" se puede emplear igualmente estos protocolos, aunque es posible que sea más cómodo el empleo de DHCPDv6 para tener identificados cómodamente el usuario de una dirección IP, conociendo que puede haber casos de suplantación y que los ataques de Man in the middle .

En los entornos donde se requiera una mayor seguridad, desgraciadamente y por lo que lleva de gestión añadida, sigue siendo la asignación estática de las direcciones , deshabilitando el router adverstisement en el router , y configurando la pila TCP/IP de los equipos para evitar aceptar los anuncios de rutas que puedan llegar, para evitar que se puede hacer que el tráfico de un equipo sea encaminado a otro.

privacidad

Dado que por defecto las direcciones IPv6 se generan en base a la dirección MAC de un equipo cuando se emplea autoconfiguración , en algunas situaciones puede ser posible el asociar una dirección IP a un equipo concreto. En la mayoria de las situaciones es posible que esto no sea problema dentro de una organización , ya que los usuarios suelen estar identificados ya sea por DHCPD o por una solicitud previa del direccionamiento, pero puede haber situaciones en las que se requiera este anonimato y se deba tener en cuenta los problemas.

Por otro lado el uso de estas extensiones de privacidad puede dar lugar a situaciones en las que sea practicamente imposible para un administrador de red averiguar que equipo tenía una determinada dirección IPv6 en un momento dado, ya que estas se generan de forma aleatoria y van cambiando cada cierto tiempo.

Esto además puede ser un problema con determinadas aplicaciones en las que el control de acceso se base en las direcciones IP de un equipo ya que puede pasar que este vaya cambiando de dirección IP cada poco tiempo, seguramente no será probable que dos equipos tengan la misma dirección pero si que puede pasar que un equipo se produzcan cambios de dirección.

Hay varios sistemas, como pueden ser los portales bancarios, redes sociales, etc que llevan un control exhaustivo de las direcciones IP desde las que se conecta un usuario, pudiendo bloquear el acceso en caso de detectar que durante una misma sesión la conexión se ha realizado desde direcciones IP distintas. Por eso puede ser necesario advertir a los usuarios que eliminen los mecanismos de privacidad de la pila IPv6.

Recomendaciones de actuación

Recomendaciones generales

El documento de INTECO hace referencia a la necesidad de que IPv6 este incluido dentro de la política de seguridad de la organización, en general se debe tratar el tráfico IPv6 de igual forma que IPv4, ya que los problemas de seguridad que pueden existir debido a este son los mismos. Tener en cuanta que con la presencia de distintos mecanismos de túneles , es muy posible que algún equipo este usando ya IPv6 aunque no se sea consciente de ello. En medidas realizas en RedIRIS se desprende que hay bastantes equipos en instituciones afiliadas a RedIRIS (unos 10000 ) que están empleando algún mecanismo de túnel para tener conectividad IPv6.

IPv6 ha sido presentado, descrito y documentado desde hace más de 10 años en las distintas reuniones y grupos de trabajo , habiendo en las páginas WWW de RedIRIS abundante información que además ha sido actualizada y en los próximos grupos de trabajo habrá una sesión especial sobre este protocolo, pudiendo además contactar con el equipo técnico de RedIRIS para cualquier duda que tengáis.

Para las organizaciones que empiecen el despliegue de IPv6 se debe tener en cuanta todo lo comentado antes a nivel de seguridad, de forma que el despliegue aparte de hacerse escalonada se haga con una monitorización y control adecuados, para evitar que puedan surgir problemas de seguridad.

Recomendaciones en el uso de IPv6

Como se ha comentado a lo largo del documento el despliegue de IPv6 en la organización debe hacerse sin que perjudique o dimisnuya el nivel de seguridad que existe en la actualidad, por lo que no es aconsejable un "despliegue a ciegas", en el que no se tenga controlado en cada momento las amenazas de seguridad que este protocolo puede abrir.

Por otro lado se puede aprovechar el despliegue de IPv6 para la revisión de las políticas de seguridad dentro de la institución, aprovechando el despliegue del nuevo equipamiento para la instalación de aquellas herramientas de monitorización que sean necesarias para evitar que se produzcan ataques a la red.

Mientras no aparezca un uso revolucionario de red o "killing application", que impulse el IPv6 lo más seguro es que IPv6 se pueda ir desplegando en fases progresivas, de forma que se pueda ir adecuando la estructura de la red a la organización, es importante sin embargo que se empiece con el estudio y despliegue inicial de IPv6 cuanto antes para poder ir detectando aquellos problemas que pueda haber a nivel de equipamiento, configuraciones , cambios en las aplicaciones y se puedan abordar estos con tiempo, sin tener que llegar inicialmente a una implementación completa pero insegura de IPv6.

En una primera fase se puede plantear un despliegue inicial de IPv6 que contemple: