Seguridad en IPv6 para Instituciones afiliadas a RedIRIS


Indice


Incidentes de Seguridad

Definimos incidente de seguridad como cualquier actividad imaliciosa de la que se tenga constancia en los sistemas conectados a RedIRIS y que implique a equipos dentro del ambito de actuación del equipo de seguridad de RedIRIS (IRIS-CERT), que se encuentra definido en la descripción de nuestro servicio segun el RFC 2350.

Dicho ámbito de actuación incluye básicamente a todas las instituciones conectadas a RedIRIS (servicio primario), dando además un servicio limitado (coordinación de incidentes) para todo el dominio *.es.

IRIS-CERT

Dentro de RedIRIS, IRIS-CERT lo constituye el grupo de personas y medios que se encargan de gestionar los incidentes de seguridad dentro la comunidad academica. Estos incidentes son detectados ya sea por:

  • Herramientas de uso interno en RedIRIS
  • Informaciones y comunicaciones de las instituciones afectadas
  • Comunicaciones de entidades externas de confianza
  • Otras comunicaciones de usuarios de Internet

Institución Afiliada

La gestion de incidentes de RedIRIS se proporciona a las instituciones afiliadas a RedIRIS, no a los usuarios finales que pueda haber en dichas instituciones. En el Documento de afiliacion, se especifica que cada institución debe designar las personas de contacto para la misma (tanto PER (Persona de Enlace con RedIRIS), como PEC (Persona de Enlace CERT)).

Es funcion de cada institución la organización interna para la gestion de los incidentes de seguridad.

IRIS-CERT mantiene una autoridad compartida con su comunidad para la atención de incidentes. Para mas información acerca de las repercusiones de dicha autoridad se puede consultar aquí.

Notificación de incidentes

En esta página se puede encontrar mas información sobre como notificar incidentes a IRIS-CERT asi como la informacion necesaria para poder comenzar la gestion del mismo.

Procedimiento general de gestión

Desde RedIRIS se intenta que todos los incidentes de seguridad se resuelvan con éxito en el menor tiempo posible, procurando que sea la institución la que adopte todas las medidas pertienentes para solucionar o paliar los efectos que esté ocasionando un incidente. Sin embargo, y debido a la interacción de muchos actores y la complejidad de algunos incidenes, éstos pueden llevar bastante tiempo en su resolucion.

El procedmiento general que se emplea en RedIRIS para la gestión de un incidente es el siguiente:

  1. La información relativa a incidentes de seguridad se almacenada en un sistema central de gestión de incidentes (RTIR). Gran parte de esta información se almacena automaticamente, mientras que otra (llamadas telefónicas, etc) se incorpora manualmente.
  2. Se realiza una primera valoración de la información para determinar si ésta corresponde efectivamente a un incidente de seguridad. En este paso suele haber una respuesta no automatica desde RedIRIS solicitando mas información o agradeciendo la informacion recibida.
  3. Una vez determinada la existencia de un problema de seguridad, se procede a contactar con el la persona de enlace CERT (PEC), designada por la persona de enlace con RedIRIS (PER) en cada institución afiliada a RedIRIS. Se recomienda que haya más de un contacto de seguridad y/o una lista de correo en la institución para evitar que por ausencias y/o vacaciones no lleguen los mensajes de queja a la institución. En caso de que el PER no designe a ningún contacto de seguridad, se comunicará la incidencia al mismo PER que será, a efectos de RedIRIS, el responsable de su gestión y resolución.
  4. La institución procederá a gestionar el incidente internamente, pudiendo requerir el apoyo de IRIS-CERT para tareas de análisis de la información, asesoramiento etc. Sin embargo la manipulación y acceso a los sistemas implicados en el incidente no será realiza, bajo ningún concepto, por miembros de IRIS-CERT, sino por el personal propio de la institución.
  5. En caso de no haber respuesta por parte de la institucióni en el plazo de 7 días y si todavia se tiene constancia de que persiste el problema (por las herramientas de monitorizacion internas de RedIRIS o por informacion externa, por ejemplo), se enviará un recordatorio sobre la incidencia a la institución, instándolos a tomar cartas en el asunto. Si el problema persiste, el CERT podrá hacer uso de otros métodos de contacto, como el teléfono, agotando todas las posibilidades de contactar con la institución. Si a pesar de todo esto el problema no se soluciona o no se tiene que constancia de que la institución esté haciendo nada para solucionar el problema, y dependiendo de la envergadura del mismo, RedIRIS podrá proceder al filtrado de las direcciones IP implicadas en el incidente de la siguiente forma:
    1. Se enviará un correo avisando del posible filtro a la las institución (vía PEC y PER) y a la red regional, si procede.
    2. Si tras un día no se ha recibido respuesta sobre el incidente, y en su caso la red regional no ha comunicado que ha aplicado el filtro, se procederá al filtrado de estos equipos
    3. Una vez hecho efectivo el filtro se comunicará a la institución implicada y a la red regional
    Cuando se solucione el problema de seguridad, la institución se deberá poner en contacto con IRIS-CERT para eliminar el bloqueo del equipo.
  6. En incidentes graves de seguridad, como puedan ser ataques de denegación de servicio o contra la infrastructura de comunicaciones, desde RedIRIS se podrán aplicar filtros sin haber trasncurrido el tiempo especificado más arriba. En estos casos, se intentará en la medida de lo posible que en primera instancia se aplique el filtro en la red regional o en la propia institución. En cualquier caso, se notificará la aplicación de los filtros a la institución y a la red regional si procede.

Para mas informacion se puede consultar la descripcion del servicio IRIS-CERT segun el RFC 2350 y nuestras paginas Web.

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.

  • Routers: Casi todos los modelos de los últimos 5 o 6 años soportan enrutamiento de paquetes IPv6, aunque es posible que algunas de las característicascaracterísticas avanzadas (filtrado de tráfico, inspección de este, etc) no se encuentren disponibles o requieran una actualización de hardware del equipo, por lo que hay que evaluar si la activación del trafico IPv6 puede ocasionar una disminución del rendimiento del equipo.

    Es muy importante el tener medidas "base" que nos permitan analizar la carga de CPU, saturación de enlaces, tráfico IPv4 e IPv6 , etc. estas medidas base o indicadores se deberían tener desde antes del despliegue de IPv6,

    En caso de que no se disponga de estas medidas, la implantación de IPV6 es una buena oportunidad para desplegar un sistema de estas características, es recomendable que como mínimo se tengan indicadores de la carga de CPU, nivel de tráfico en cada uno de los enlaces, y consumo de memoria, no solamente para comprobar si el despliegue de IPv6 ocasiona problemas en los equipos, , sino también para tener un registro histórico que pueda servir ante otros problemas, como DDOS, ataques dirigidos, etc.

    Existen diversas herramientas gratuitas como Cacti, MRTG etc que pueden servir para realizar esta monitorización, se basan en el empleo de consultas SNMP al equipo desde una servidor donde corren estos programas que se encargan de mantener el histórico y generar las gráficas correspondientes.

    Como se comentará en más profundidad en el apartado de translación de direcciones habrá que tener cuidado ya que uno de los mayores cambios con IPv6 será la desaparición del NAT

  • switches: Al igual que con los routers los modelos más comunes de conmutadores deberían soportar el multicast IPv6 (empleado en vez de ARP para el descubrimiento de equipos en el mismo segmento de red), pueden surgir problemas de rendimiento ya que el protocolo NDP de descubrimiento de vecinos es más activo que ARP.

    Al igual que se ha comentado en el apartado anterior, conviene tener los dispositivos de conmutación de red monitorizados, para poder detectar los problemas que puedan surgir con el despliegue de IPv6 , pueden surgir problemas con switches instalados sin control del servicio de informática en departamentos y centros , sobre todo en aquellos que no disponen de facilidades para su gestión.

  • Detectores de intrusión (IDS): por lo general estos equipos si que deben ser actualizados para analizar el trafico IPv6, en la mayoría de las configuraciones en las cuales el IDS recibe el tráfico en modo pasivo, empleando por ejemplo un puerto en modo "Span" . que reciba todo el tráfico o mediante algun dispositivo de duplicación pasiva de tráfico, el IDS recibirá el trafico IPv6 pero no será capaz de analizarlo, por lo que habrá que extremar las precauciones para evitar que los ataques puedan pasar inadvertidos.

    Aunque todavía no son frecuentes ya se están detectando reconocimiento de puertos y ataques contra equipos empleando IPv6 y seguramente se intentará explotar la novedad de este protocolo para realizar ataques contra equipos

  • Cortafuegos, Serán seguramente los dispositivos que necesiten una mayor revisión, su función es la de bloquear el tráfico por lo que si no soportan IPv6 lo más seguro es que no habría trafico de este protocolo. No es recomendable un "bypass" del trafico IPv6 porque como se comentará en otras secciones esto puede hacer que los equipos sean vulnerables desde Internet y ya se están detectando ataques.

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

    >
  • El sistema de cortafuegos de Linux (iptables) soporta IPv6 empleando por lo general unos ficheros de arranque y configuración distintos a los de IPtables, llamados ip6tables , sin embargo no todos los módulos a nivel de IPtables están implementados en IPv6, entre los módulos no implementados se encuentra implementados (en un RedHat 5.5 solamente la mitad de los módulos de Iptables están implementados en IPv6 (59/30) entre los módulos no implementados se encuentra el uLog , comment, Classify, clusterIP.

  • Hay que tener en cuenta en la configuración de aplicaciones como puede ser servidores HTTP, hosts.allow, correo-e, que en caso de que existan restricciones de conexión hay que configurar el acceso desde las direcciones IPv6.

  • La configuración por defecto de la pila TCP/IP en los sistemas Linux permite algunos ataques en la capa de enlace, como puede ser el uso de ICMPv6 para ataques de intermedio, etc. Es conveniente revisar los parámetros del kernel, como se comenta por ejemplo en esta página en www.cibercity.biz , para evitar estos ataques.

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:

  • Aplicaciones vulnerable
  • Ataques de ingeniería social hacia los usuarios del sistema.

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.

  • Mediante el protocolo NDP comentado anteriormente , El equipo obtiene una dirección IPv6 global basada en la MAC del equipo. Para poder salir a internet el equipo necesita un router que debe anunciarse empleando el protocolo de descubrimiento de rutas, que se comenta en este RFC.

    Esta sistema genera unas direcciones IPv6 bastante largas y además es poco seguro por la posibilidad de suplantación de identidad y ataques de "Man in the Midle"; que se pueden producir, como se comenta por ejemplo en www.iniqua.com .

  • Uso de DHCPD, de forma que se pueda gestionar la asignación de direcciones IP de forma estática (siempre la misma dirección IP para la misma MAC), desgraciadamente todavía no hay un standard para la asignación del router por defecto , por lo que con esta solución todavía es necesario el que los equipos reciban de forma dinámica la información de las rutas, aunque permite realizar "mapeos" entre la dirección IPv4 e IPv6 , por ejemplo emplear los dos últimos números de la dirección IPv4 dentro de la dirección IPv6 2001:....::101:30 para la dirección 192.187.101.30
  • Asignación de direccionamiento estático, puede que más complicada que gestionar, pero permite deshabilitar en los sistemas el procesamiento de los anuncios de rutas, evitando así lo ataques de "man in the middle".

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:

  • Obtención de un rango IPv6,como se describe en la guia de Despliegue
  • Instalación de la conexión IPv6, si hay dificultades para que el router de cabecera pueda soportar el tráfico IPv6 con las suficientes garantías de seguridad (flujos de Red, Filtros que sean necesarios, etc), se puede plantear la instalación de un equipo Unix/Linux que haga estas funciones . Existe software como Nprobe o Softflowd que permiten la generación de flujos IPv6, y el sistema operativo soporta vía IP6tables el filtrado de aquel trafico que viole la política de seguridad
  • Instalación de servicios instituciones en IPv6. El despliegue de IPv6 puede empezar con el despliegue aquellos servicios institucionales (Web, Correo, DNS, etc) que tienen más visibilidad desde el exterior . en el cuadro de Honor de RedIRIS, aparecen precisamente el estado del despliegue de IPv6 en los distintos centros afiliados a RedIRIS, seguramente para este despliegue mínimo se puede emplear direccionamiento estático , a la espera de que alternativas al RADV puedan ser desplegadas.

    Este despliegue inicial puede servir por un lado para adquirir experiencia sobre la implantación de IPv6 y por otro lado evaluar las dificultades que puedan surgir en el uso de IPv6, por ejemplo la adecuación de los permisos de acceso, herramientas internas de logs, etc que esperaban usar una dirección IPv4 y se encuentran con una dirección IPv6

  • A partir de este despliegue inicial de IPv6 ya se puede plantear un despliegue en aquellas redes con menos requisitos de seguridad, como puede ser las salas de libre acceso o Edoroam, que muchas veces han estado usando conexiones NAT y pueden verse beneficiadas por el uso de direccionamiento público IPv6, aunque se deba extremar el peligro de los ataques que puedan sufrir los usuarios Progresivamente se puede ir desplegando IPv6 en el resto de redes, teniendo siempre en cuenta las necesidades de seguridad