Firma digital de páginas HTML con PGP

Empleo de Webber para automatizar la firma de páginas HTML

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.

  • 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 Este servicio permite el registro de documentos vía correo electrónico. En principio esta diseñado para que cualquier usuario pueda registrar un documento simplemente empleando el correo electrónico.

    Por "registro" de un documento se entiende la posibilidad de comprobar a posteriori si un documento dado existía en una fecha determinada.

    Actualmente el registro funciona vía correo electrónico, solamente hay que enviar un correo a la dirección del registro:

    (sellado @ rediris . es )

    conteniendo como anexos o attach los documentos que se quieren registrar.

    El usuario recibirá en su cuenta de correo un mensaje del registrador cuando los documentos son procesados, con información sobre como verificar la información.

    Verificación de la información.

    Para verificar la información que envía el mensaje puede:

    Documentación Adicional.

    En la página de preguntas más frecuentes encontrará respuesta a algunas de las preguntas que los usuarios suelen plantear.

    Presentaciones

    • Presentación Jornadas Técnicas RedIRIS 2002
    • Presentación Jornadas de Usuarios Científicos en RedIRIS 2002
      • ¿Para qué firmar las páginas HTML ?

        Muchas veces es conveniente estar seguros de que la inforMación reflejada en un documento esta tal y como fue publicada y que por lo tanto tenemos acceso a la información original.

        Este es el fin de la firma mediante PGP de algunas de las páginas HTML del servidor de RedIRIS, que cualquier usuario pueda comprobar que la información no ha sido modificada. Para realizar esto se emplea se pueden emplear diversas técnicas matemáticas, entre ellas la criptografía de clave publica y el programa PGP.

        Criptografía de clave publica.

        La criptografía de clave publica se basa en la existencia de dos "claves" o funciones matematicas con caracteristica fundamental de que lo que solamente es posible decodificar un mensaje empleando la clave complementaria. Se llama de clave publica porque una de ellas se mantiene en secreto, mientras que la otra se hace publica y cualquier persona puede acceder a ella.

        A la hora de firmar un documento este se firma con la clave privada y cualquiera puede, empleando la clave publica, comprobar que el documento no ha sido modificado, ya que cualquier modificación en el texto haría que la comprobación del mensaje no fuera correcta.

        ¿Qué es PGP ?

        Existen diversos programas que nos permiten firmar digitalmente los documentos. Para la firma de las páginas HTML del servidor se ha optado por emplear el programa PGP . Este programa fue uno de los primeros aparecidos que permitian a los usuarios firmar y codificar documentos. Tiene una larga e interesante historia y existen versiones de dominio publico para casi todas las plataformas y sistemas operativos lo que permite comprobar que las páginas no han sido modificadas en cualquier sistema operativo.

        ¿Por qué no emplear SSL/TLS ?

        Existe otro mecanismo denominado SSL/TLS que permite mantener conexiones seguras y autenticadas desde navegadores WWW como Netscape o Internet Explorer, de una forma hasta más transparente y directa que el mecanismo empleado por RedIRIS. El problema que tienee este sistema es que requiere que todas las operaciones criptograficas se realizen para cada conexión que se establezca, lo que enlentece la conexión. El sistema empleado en el servidor de RedIRIS, aunque no tan transparente al navegador solamente firma las páginas una vez (cuando se modifican desde RedIRIS), y las páginas firmadas se cargan a la misma velocidad que las páginas que no están firmadas.

        Información de la clave publica PGP

        La clave publica empleada para firmar las páginas HTML de RedIRIS tiene la siguiente información:

        gpg --list-secret-keys
        gpg: signature packet without keyid
        /.gnupg/secring.gpg
        - ---------------------------------------------
        sec  2048R/2C4C669B 2000-10-19 PGP certificate of RedIRIS Web Server 
              , see http://www.rediris.es/pgp/firmaweb/
        uid               CN=www.rediris.es, OU=IRIS-CERT, O=RedIRIS, ST=Madrid, C=ES
        gpg --list-keys --fingerprint 
        /.gnupg/pubring.gpg
        - ---------------------------------------------
        pub  2048R/2C4C669B 2000-10-19 PGP certificate of RedIRIS Web Server 
               see http://www.rediris.es/pgp/firmaweb/
             Key fingerprint = 99 A8 78 63 8C 5C E8 0A  8C 54 FE 46 81 25 A6 CA
        
        
        El par de claves RSA empleado es exactamente el mismo que esta ahora mismo en uso en el servidor SSL . La clave publica para PGP se puede obtener aquí

        ¿Como Verificar que una página es correcta ?

        Los navegadores no disponen de un mecanismo para automatizar la firma de las paginas WWW mediante PGP por lo que para comprobar que una página no ha sido modificada debe cguardar la pagina en el disco y realizar la comprobación con el programa PGP. Dado que PGP esta disponible para varios sistemas Operativos, en diferentes versiones los ejemplos que aparecen a continuación pueden variar dependiendo del sistema.

        Algunos ejemplos de comprobación.

        Comprobación en versiones Unix de PGP

        Emplenado el programa GnuPgP la verificacion de una pagina firmada con el servidor de RedIRIS da este resultado:

        gpg --verify < index.es.html 
        gpg: Signature made Tue Dec 12 23:32:30 2000 MET using RSA key ID 2C4C669B
        gpg: Good signature from "PGP certificate of RedIRIS Web Server \\
           ,  see http://www.rediris.es/pgp/firmaweb/"
        
        Con PGP 2.6 el resultado es similar:
        gp < index.es.html 
        Pretty Good Privacy(tm) 2.6.3ia - Criptografía de clave pública para todos.
        (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
        Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
        Hora actual: 2000/12/12 22:34 GMT
        
        El fichero tiene firma. Se necesita la clave pública para comprobarla.
        .
        Firma correcta de "PGP certificate of RedIRIS Web Server  \\
        	 see http://www.rediris.es/pgp/firmaweb/".
        Firma realizada el 2000/12/12 22:33 GMT con una clave de 2048 bits, 
        identificador 2C4C669B
        
        AVISO: Esta clave pública no está certificada con una firmade confianza,
        por lo que no se sabe con seguridad si realmente pertenece a:
         "PGP certificate of RedIRIS Web Server , see http://www.rediris.es/pgp/firmaweb/".
        

        Comprobación en MacOS con PGP 6.5

        ¿Por qué me dice que la firma es invalida ?

        La firma de documentos electronicos con claves digitales permite dos cosas:

        • Comprobar que el documento no ha sido modificado
        • Comprobar que el documento ha sido firmado por quien dice ser

        Algunas versiones de PGP indican que la firma es invalida cuando la página bien firmada pero no se le ha indicado al programa que debe considerar como "verdadera" la clave PGP que ha firmado la página.

        en el ejemplo de comprobación en Unix aparece al final indicado que la clave no esta dentro de la Red de Confianza PGP.

        Consulte la información disponible en la sección de PGP si desea más información sobre el funcionamiento de las redes de confianza de PGP

        ¿Como se han firmado las páginas ?

        La información de las páginas HTML del Servidor de RedIRIS se procesa empleando un sistema de Agentes denominado Webber desarrollado en RedIRIS.

        Webber permite la automatización de diversos aspectos del diseño de la información mostrada en el servidor y se ha desarrollado un procesador que realiza la firma de las páginas HTML de una forma automatica a partir de los fuentes webber iniciales.

        Consulte las páginas de Webber para más información.

Esta página ha sido firmada digitalmente usando PGP