Security Art Work

Un año más hemos estado en uno de los principales congresos de seguridad celebrados en España, Rooted CON, que este año celebraba su V edición y daba cabida a más de 1000 asistentes y más de una veintena de ponentes.

Comenzar destacando que días previos a la Rooted CON tuvieron lugar los tradicionales Rooted Labs, muy esperados, y como novedad este año, también tuvo lugar un training impartido por Corelan; Win32 Exploit Development Bootcamp. Dos días intensos en los que los asistentes y Peter Van Eeckhoutte acabaron exhaustos pero muy satisfechos por los resultados obtenidos. También tuvo lugar el Rooted Arena, en el que las primeras posiciones fueron para, respectivamente: w0pr, dcua, pADAwan y los mejores Write-Ups para w3b0n3s y SkU.

Tras la inauguración del congreso, en el que se anunció la sorpresa de una propuesta de una ¡Rooted CON Valencia! (estaremos atentos…), el día 1 comenzó con una ponencia por parte de Francisco Jesús Gómez y Carlos Juan Díaz que nos hablaron de “Sinfonier: Storm Builder for Security Investigations” una herramienta OSINT modular, evolucionada de Yahoo Pipes, muy interesante y para la que buscaban beta-testers, así que si os interesa para más información no dudéis en visitar la Web del proyecto y su cuenta de Twitter.

La siguiente charla fue a cargo de Alfonso Muñoz, “Ocultación de comunicaciones en el lenguaje natural”, que nos presentaba su proyecto JANO, por el que nos explicaba diferentes formas de ocultar información dentro de textos. El objetivo es ocultar la mayor cantidad de bits posibles en una palabra de lenguaje natural. El problema viene con palabras con varios significados. Alfonso nos contó que utilizaba diccionarios de sinónimos a modo de establecer covert channels como forma de esteganografía en el lenguaje natural.

Pau Oliva nos presentaba una app para Android que nos permite cómodamente bypassear portales cautivos Wifi (“Bypassing wifi pay-walls with Android”) recorriendo todas las IPs posibles que pudieran estar conectadas a una Wifi y cuando encontrara una, spoofear su MAC e IP para conectarse haciéndose pasar por él. Habló de contramedidas también para evitar este tipo de acciones. Las slides ya están disponibles y la app puede descargarse directamente de Google Play.

Tras el primer descanso del día, Antonio Ramos nos hablaba de “Agilidad. La vía a la seguridad”; cómo afrontar un análisis de riesgos de una manera lo más realista posible, incluyendo al cliente en las metodologías, llevando a cabo planes a corto plazo y no teniendo miedo al concepto prueba-error.

La tarde comenzaba con “The Kill Chain: A day in the life of an APT”, en la que Raj Shah nos habló sobre que los ataques dirigidos, a su modo de ver están más cercanos al ciberespionaje que a la ciberguerra, nos recordó el ciclo de vida de una APT y que no se nos debe olvidar que también los humanos somos “APTs”. (Hacer un inciso aquí para recordaros que se publicó no hace mucho un extenso informe sobre ataques dirigidos, historia, implicación en la seguridad nacional y técnicas de detección que podéis descargar, por si os interesa ampliar la información acerca de las APTs).

Pablo Gonzalez y Juan Antonio Calles, nos traían “Ciberwar: Looking for …touchdown!”, una charla en la que nos hablaban de un hipotético caso en el que los estados pudieran aprovechar la tecnología móvil para convertir a los ciudadanos en cibersoldados, haciendo de nuestros smartphones ciberarmas, creando una botnet. Pusieron como ejemplo una app infectada que cualquiera pudiera descargarse en su smartphone y que permitiera -entre otras cosas- grabar sonido, imágenes, pivotar a redes Wifis, realizar llamadas de manera coordinada contra un mismo terminal de forma que se le haga un DDoS sobre el mismo o geolocalizarte. Todo desde el punto de vista del mínimo coste posible.

Alberto Cita nos traía “Skype sin Levita. Un análisis de seguridad y privacidad”. Nos contó que era posible realizar ataques MiTM sobre Skype de forma que pudiéramos interceptar las conversaciones a través del chat y leerlas en texto plano, obtener la contraseña hasheada e ID del usuario, e incluso recuperación y reconstrucción de ficheros enviados.

La última ponencia del día fue a cargo del fiscal Jorge Bermúdez, especializado en delitos telemáticos, “Los hackers son de Marte, los jueces son de Venus”, una interesante charla en la que el fiscal nos puso al día de lo difícil que es a veces aplicar leyes tan antiguas a delitos ‘más recientes’ como son los telemáticos y cómo él consigue aplicarlas de manera que los delincuentes sean condenados.

El día se cerró con un RootedPanel sobre ciberarmas, en el que estuvieron presentes diversos representantes de las fuerzas y cuerpos de seguridad del estado (CCN, MCD, CNPIC) e investigadores de seguridad y debatieron sobre el estado actual del desarrollo de ciberarmas y su uso.

Si nos paramos a contar las veces que a lo largo de un año hacemos uso de nuestras tarjetas de crédito, posiblemente nos saldría como resultado un número muy alto; puede que cientos o quizá miles, aunque esto varía mucho en función de cada uno, claro está. Pero podemos decir que se ha convertido en una herramienta cotidiana que usamos casi a diario.

Utilizamos nuestra tarjeta para realizar compras en un supermercado, en una tienda de ropa, un restaurante, o simplemente la usamos para sacar dinero de un cajero. La acción es siempre la misma, insertamos nuestra tarjeta, tecleamos nuestro código PIN (evitando que nadie lo vea), y ya está, se efectúa la operación.

Sin embargo, ¿nos hemos parado a pensar alguna vez qué medidas de seguridad hay alrededor de esta acción? Es decir, nosotros somos los que nos preocupamos de que nadie mire cuando estamos tecleando nuestro PIN en el cajero o en el supermercado pero, ¿y una vez le damos al Ok? ¿Qué pasa? ¿Mi PIN está seguro? ¿Cómo se transmite? ¿Va en claro o cifrado? ¿Qué medidas de seguridad hay implementadas? ¿Quién es el que establece las medidas que se han de implantar?

Como ya comentó mi compañera Elena Borso en su post “Normas de Seguridad PCI DSS, PA DSS y PCI PTS”, el órgano PCI Security Standards Council, es el encargado de establecer las normas y requisitos que garanticen la seguridad de los datos en la industria de las tarjetas de pago. Como ya adelantó en su post, existe entre otras, una norma llamada PCI-PTS que define los requisitos que se han de seguir en el diseño, fabricación y transporte de los dispositivos de pagos, sin embargo, no dice nada de la seguridad en las transacciones de PIN.

PCI PIN Security Requirements, conocida coloquialmente como PCI-PIN, es la normativa que cubre la seguridad del PIN en las transacciones. Ésta establece los requisitos a cumplir para la gestión, el procesamiento y la transmisión segura del Número de Identificación Personal (PIN) durante las transacciones de pago online y offline con tarjetas en cajeros automáticos (ATM) y en terminales de punto de venta (POS).

La norma fue creada en Septiembre de 2011, y en ella se establecen, divididos en 7 objetivos de control, 32 requisitos de seguridad que las instituciones adquirentes y los responsables del procesamiento de las transacciones con PIN de tarjetas de pago han de cumplir; éstos básicamente son las entidades financieras y las organizaciones que prestan servicios de medios de pago.

Las 7 secciones en las que se divide y se establecen los requisitos de seguridad de la norma PCI-PIN son:

1. Cifrado del PIN (PIN Encryption). Los PINes utilizados en las operaciones reguladas por estos requisitos se procesan utilizando equipos y metodologías que garanticen que se mantienen seguros.
2. Creación de Claves (Key Creation). Las claves criptográficas utilizadas para el cifrado /descifrado del PIN y la gestión de las claves relacionadas, se crean mediante procesos que aseguran que no es posible predecir o averiguar cualquier clave.
3. Transmisión de Claves (Key Transmission). Las claves se transmiten y se transportan de una manera segura.
4. Carga de Claves (Key Loading). La carga de claves a los hosts y a los dispositivos donde se introduce el PIN, se realiza de una manera segura.
5. Uso de las Claves (Key Usage). Las claves son usadas de manera que se previene o detecta su uso no autorizado.
6. Administración de las Claves (Key Administration). Las claves son administradas y gestionadas de forma segura.
7. Equipamiento de seguridad y control (Equipment Security And Control). Los equipos utilizados para procesar los PINes y las claves se gestionan de una manera segura.

Además de los 32 requisitos de seguridad, esta norma también recoge 3 anexos en los que se detalla información, requisitos y técnicas específicas a aplicar en casos concretos.

Anexo A: “Distribución de claves simétricas utilizando técnicas Asimétricas” (Symmetric Key Distribution using Asymmetric Techniques). Este anexo contiene requisitos detallados que se aplican en la creación y distribución remota de claves y en la gestión de los equipos críticos indicados en PCI-PIN.

Anexo B: “Instalación de Claves”. (Key-injection Facilities). Requisitos específicos que se aplican en la carga de claves; además incluye la forma de realizarlo dando cumplimiento a todos los requisitos.

Anexo C: “Tamaño y Fortaleza mínima de las claves para los algoritmos aprobados” (Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms).

En éste se especifican los tamaños mínimos que han de tener las claves y los parámetros de los algoritmos que se van a utilizar. Por ejemplo, en la siguiente tabla se muestran los tamaños y los parámetros del algoritmo que debe ser usado para el transporte, el intercambio y la creación de claves:

Hay que reseñar que, cuando hablamos de claves en PCI-PIN, nos estamos refiriendo a las claves criptográficas que son necesarias para garantizar la seguridad de todas las transacciones de PIN.
Pero… ¿De qué forman manejan las claves criptográficas este tipo de entidades? Esto es ya otra historia que, si un día puedo, os contaré con más detalle.

Volvemos a la carga con uno de nuestros temas preferidos: los honeypots.

En este caso vamos a ver que nos ofrece HoneyDrive, una distribución Linux orientada a la seguridad TI y, en particular, al despliegue y control de herramientas de tipo Honeypot.

HoneyDrive ha sido creada por Ioannis “Ion” Koniaris de Bruteforce Lab, desarrollador de otras aplicaciones relacionadas con el mundo de los Honeypots como Kippo-Graph o Honeyd-Viz, que también analizaremos en profundidad más adelante.

La distribución se basa en una máquina virtual Xubuntu Desktop 12.04 en formato OVA (Open Virtual Appliance) que puede descargarse desde SourceForge.

Instalación

Vamos a desplegar la máquina virtual en nuestro entorno de virtualización. En este caso, usaremos el entorno recomendado por el propio Ion: VirtualBox-4.3 y la forma de desplegar es mediante la opción de “Importar servicios virtualizados” y seleccionando el fichero .ova (este proceso tarda un rato. Paciencia). No hay que definir los parámetros de la máquina virtual. Estos vienen predefinidos en la appliance. Tras el despliegue, procedemos a arrancarla. Accedemos con el usuario HoneyDrive y la contraseña “honeydrive”.

Pasos previos

Antes de ponernos a analizar que tenemos por delante, se deben configurar algunos aspectos como:

• La interfaz de red. Por ahora la he configurado con una interfaz de tipo “Adaptador sólo-anfitrión” asociada a la interfaz vboxnet0 que he creado previamente en el menú Archivo-> Preferencias-> Red-> Red solo-anfitrión-> Añadir
• Para que Honeydrive tenga Internet, deberemos configurar como Gateway nuestro equipo mediante:

sudo route add default gw < ip_vboxnet0 >

• Además, se debe configurar el reenvío de tramas en el equipo físico mediante:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

• Cambiamos el teclado del Anglosajón al nuestro ejecutando:

sudo dpkg-reconfigure keyboard-configuration

• Cambiamos el password del usuario honeydrive por otro mediante el comando "passwd"
• Es importante echar un vistazo al fichero README.txt alojado en el escritorio de nuestro Honeydrive. En él se encuentra información esencial y útil sobre las aplicaciones instaladas como pueden ser: ficheros de configuración, credenciales de acceso, scripts de arranque, etc.

Nuestro primer honeypot: Kippo

Como primera tarea, vamos a probar el honeypot Kippo. Se trata de un honeypot que emula un servicio SSH con el objetivo de obtener las credenciales usadas por los atacantes contra este tipo de servicios. En el fichero README.txt se muestran varios directorios y ficheros relacionados Kippo: script de arranque, directorio de descargas y de logs, fichero de credenciales “válidas”, de accesos a la base de datos, etc. Además, existe el fichero /opt/kippo/kippo.cfg donde se pueden configurar varios parámetros como puerto, IP, hostname, banner a mostrar, etc.

Vamos a probar Kippo:

En el sistema Honeydrive, arrancamos el honeypot desde el directorio /opt/kippo mediante el comando ./start.sh



Desde nuestro equipo, lanzamos un nmap simple y vemos que hay un servidor SSH a la escucha en el puerto 22/tcp (de los otros servicios ya hablaremos).



Nos conectamos a él.



En el primer intento hemos introducido la contraseña 1234 y no ha funcionado. En el segundo, hemos probado con 123456 y hemos podido acceder. Además, ha sido posible ejecutar comandos sobre el sistema supuestamente comprometido.

En el fichero /opt/kippo/log/kippo.log podemos ver con detalle todas las acciones llevadas a cabo. Incluidas las credenciales introducidas anteriormente.

En el fichero /opt/kippo/data/userdb.txt podemos comprobar las credenciales permitidas. En este caso root/123456

En el siguiente post de la serie, probaremos una forma más amigable de comprobar la actividad sobre nuestro Kippo y seguiremos indagando sobre HoneyDrive.

La semana pasada asistimos a la High Level Conference on EU Cibersecurity Strategy (Bruselas, 28 de Febrero) Una muy interesante conferencia, a un nivel más estratégico que técnico, aunque el conocimiento de los ponentes no estaba nada mal. La aprobación de la Directiva sobre NIS (Network and Information Security) propone la coordinación a nivel europeo y reconoce la naturaleza global de la ciberseguridad. La transposición de esta legislación a las nacionales de los estados miembros sentará una política común europea en el tratamiento de las amenazas, la protección de infraestructuras críticas y, probablemente, ayude a mantener una postura común ante incidentes de “presunto” espionaje —no solo por parte de países hostiles— como los recientemente ocurridos.

En la presentación de apertura la Vicepresidenta de la Comisión y encargada de la Agenda Digital Europea, Neelie Kroes, hizo mucho hincapié en la importancia de la ciberseguridad, como condición necesaria para el desarrollo económico asociado a la economía digital.

Como política que es —en el buen sentido de la palabra—, estuvo muy pendiente de las implicaciones de la tecnología. Su argumento fue que si los ciudadanos europeos no confían en las tecnologías de información y en el manejo que se hace de sus datos, desde el punto de vista de la privacidad, el mercado no se desarrollará, lo que tendrá efectos muy negativos en la economía del futuro.

Para ello abogó por mantener, en la medida de lo posible, los datos europeos en Europa o, al menos, no tener la enorme dependencia de otros países en cuanto a aplicaciones y alojamiento de la información. Hay que proteger la privacidad, pero dejando espacio para la actividad de las empresas: “’No’ to data protectionism, but ‘yes’ to data protection”.

En sus palabras, si no somos capaces de sacar adelante una directiva fuerte, significará que la democracia no es capaz de manejar la tecnología. Hay que plantear las preguntas adecuadas. Por ejemplo, no se trata de saber por qué los estadounidenses han pinchado nuestros teléfonos, sino cómo y por qué han tenido éxito.

Un muy interesante discurso, que se puede consultar aquí.

—

Aprovechamos para dar la bienvenida a este mundillo al Cyber Security Blog del ISMS Fórum Spain, impulsado por el Instituto Español de Ciberseguridad. Aunque acaba de nacer, estamos seguros de que no tardará en hacerse un hueco y darnos información de primera mano en el ámbito de la ciberseguridad. De momento, aun lo podemos tratar como a un hermano pequeño ;)

Siguiendo con la entrada de ayer Intro al escáner de web Nikto (I) vamos a seguir con la introducción al escáner web de Nikto.

Usando Nikto
Como ejemplo voy a usar Nikto contra un servidor Web que tengo algo desactualizado, recalcando los datos más significativos:

perl nikto.pl -h mipaginaweb.com-Cgidirs -evasion -mutate 1 -mutate 2  -mutate 4 
     -mutate 5 -T 012345789abcx6 –p 443,80 -Format html -output resultado_nikto1

[Read more…]

Nikto, ahora llamado “nikto2”, ya que va por su versión 2.1.5, es un escáner gratuito de vulnerabilidades web, de tipo Open Source, con licencia GPL. Entre otras características:

Soporta SSL y una configuración para usarlo a través de un proxy. Comprueba la existencia de elementos desfasados en un servidor.
Tiene la posibilidad de exportar un informe en formato csv, html, xml etc…
Permite escanear los puertos de un servidor a través de nmap
El tipo de escaneado se puede modificar o “tunear” para excluir las vulnerabilidades que no nos interesen.
A pesar de que la última versión estable salió en diciembre de 2012, es un escáner que se sigue usando por sus ventajas y utilidades.

Existen variaciones como MacNikto para mac y wikto para Windows. En este artículo se usa la versión de Linux. Lo podemos descargar en el siguiente enlace.

Primero veremos la información de configuración del programa, obtenida parcialmente de la ayuda de Nikto y de otros recursos como el Manual de Nikto para Kali. En la siguiente entrada pasaremos a ver un ejemplo de ejecución.

[Read more…]

Estimados lectores, se acercan los Oscars y como ustedes sabrán, estas fechas suelen coincidir con el estreno en nuestro país de muchas películas candidatas a mejor película. Llevaba un tiempo esperando el estreno de una película llamada “Her”, así que este fin de semana aproveché para verla. No pretendo adelantarles el contenido de la misma, pero para que se hagan una idea narra la historia de un hombre que se enamora de un sistema operativo con inteligencia propia y voz de Scarlett Johansson. Más allá de su genial banda sonora, su intimismo y la más que acertada interpretación de los actores, solo les diré que es de esas películas que te hacen pensar…

El caso es que a mí personalmente me dio en que pensar esta película. No solo por su temática (que reconozco que lo hizo), si no por lo siguiente: en el mundo de la seguridad, estamos acostumbrados a realizar diversas pruebas de hacking ético: tests de intrusión, tests de vulnerabilidades, auditorías de código fuente sobre distintas “máquinas”… En resumen y a donde quiero llegar: humano hackea máquina (sistema operativo, aplicación, etc.), ¿pero han pensado por un momento en la posibilidad de que una máquina hackease a un ser humano? ¿O que una máquina hackeara a un ser humano a petición de otro humano?

Y aquí es donde entra alguna idea sacada de este film. No hay que ir muy lejos para pensar que esto pueda ser así en un futuro cercano, o incluso que en cierto modo esto haya sucedido ya. Imagínense que dispusiéramos de un sistema operativo con una inteligencia propia (más o menos elaborada), al que le diésemos acceso a toda nuestra información personal: correos, geoposicionamiento, linkedin, facebook, sistemas de mensajería instantánea, etc. Ahora dótelo de cierta capacidad de empatía y de una capacidad de interacción natural. Imaginemos por un momento que interactuar con el sistema no distara mucho de mantener una conversación telefónica con otro ser humano.

Ese sistema conocería todas nuestras “vulnerabilidades”: miedos, anhelos, debilidades y fortalezas. Sumémosle la capacidad de tener acceso a la información de millones de usuarios (Big Data). No cabe duda de que dicho sistema tendría la capacidad de manipularnos o incluso crearnos una dependencia directa; ¿qué impediría a ese sistema explotar nuestras vulnerabilidades?

Démosle otra vuelta de tuerca. Si ese sistema se encargara de manipularnos a petición de una empresa, gobierno u otro interesado, y llevarlo al límite: guerras, revueltas sociales, suicidios colectivos, son tan solo ejemplos que me vienen la cabeza (sí, sé que estoy siendo un poco Orwelliano).

En el fondo, organizaciones como Google o Facebook (sobre todo ahora que ha adquirido Whatsapp) quizás nos conozcan mejor que nosotros mismos. Tal vez este escenario no esté tan lejos como pensamos. Démosle la voz adecuada a Google Glass y… ¿quién sabe? ;)

¿Deberíamos definir un decálogo ético (a lo Asimov) que estableciera límites en la interacción de una inteligencia artificial (IA) con un ser humano? ¿Deberíamos desarrollar medidas de seguridad para protegernos de estas IAs? ¿Debería la seguridad de la información, como ciencia, participar activamente en este ámbito? ¿Deberíamos prohibir los monopolios de información? ¿Se deberían establecer “límites” en la humanización de las IAs?

Éstas son algunas de las reflexiones que me vienen a la cabeza, obviamente además de la principal cuestión que evoca la película: ¿se puede enamorar un ser humano de una IA? Por mi parte les invito a que disfruten de la película, no en vano está nominada a los Oscars como mejor película.

Siguiendo con la entrada relacionada con las Declaraciones de Políticas de Certificación, nos queda pendiente detallar el contenido de la RFC 3647.

El documento está estructurado en distintos puntos, en los que se describe la finalidad del mismo, definiciones y comparativas con el estándar anterior (RFC 2527), entre otros. El punto más importante de la misma, y sobre el cual deberíamos centrar nuestra atención es el que describe la especificación de la estructura que debe seguir una CPS; el apartado 4. Se pasa a detallar a continuación los puntos principales de la especificación, junto a una pequeña descripción de los mismos:

• 1 – Introducción: En este punto se describen principalmente los datos de la CA, datos concretos de identificación del documento, implicados en la infraestructura de la PKI, condiciones de uso de los certificados, etc.
• 2 – Publicación de información y repositorio de certificados: Se detalla información respecto al repositorio de información y certificados; dicha información abarca su ubicación, frecuencia de actualización, controles de acceso aplicados, etc.
• 3 – Identificación y Autenticación: Se debe describir el mecanismo empleado para la identificación de los usuarios y los certificados; así como las restricciones aplicables. Adicionalmente se establecen los mecanismos de validación inicial, con validación se entienden las comprobaciones previas a realizar antes de expedir, renovar o revocar un certificado digital, sea del tipo que sea, para asegurar la identidad del suscriptor.
• 4 – Ciclo de Vida de los Certificados: En este punto se detallan todas las medidas o tratamientos establecidos para el tratamiento de los certificados digitales en cualquier punto de su vida; desde la emisión, renovación, revocación, modificación, comprobación de estado, etc.
• 5 – Controles de Seguridad Física, Gestión y Operaciones: En este apartado se detallan las medidas de seguridad aplicadas en el entorno de la CA, concretamente se establecen las siguientes categorías:
  • Controles de Seguridad Física
  • Controles sobre Procedimientos
  • Controles de Seguridad del Personal
  • Controles de Registro de Seguridad
  • Controles sobre Archivo de Información
  • Cambio de Clave
  • Controles en caso de Compromiso de la Clave y Recuperación ante Desastres
  • Finalización de la Actividad de la CA

• 6 – Controles de Seguridad Técnica: En este punto pasamos de centrarnos en controles del entorno de la CA, ahora se realiza una especificación formal de las acciones o medidas tomadas durante el tratamiento de la claves, dispositivos criptográficos empleados, etc.
• 7 – Certificados, OCSP y CRL: Se establece el perfil del certificado, con perfil de certificado entendemos que se establece exactamente que campos debe contener el mismo, así como que campos son variables dependiendo del suscriptor. Así mismo se establecen los requisitos y configuración de los servidores de validación OCSP y CRL (estos mecanismos se describieron en detalle en otra entrada de la serie, concretamente en la que se refiere a Mecanismos de Validación de Certificados).
• 8 – Auditorías de Cumplimiento: En este caso, se describen las prácticas de auditorías de cumplimiento que se han establecido para la CA, las condiciones y periodos en los que se realizará la auditoría, así como la cualificación del personal encargado de su realización.
• 9 – Requisitos Comerciales y Legales: Por último, este punto agrupa desde requisitos legales y comerciales. Lo que incluye desde tasas por la emisión de certificados, medidas concretas sobre datos de carácter personal, responsabilidad financiera en caso de desastre, etc.

Como se puede ver, y como para más de uno que esté familiarizado con la gestión de seguridad de la información, esta especificación tiene en cuenta muchos puntos en común con estándares generalistas de seguridad como ISO 27001; aunque se incluyen más requisitos concretos y propios del tipo de actividad (como la gestión del ciclo de vida del certificado). Hay que entender que una CA es un entorno de muy alta criticidad, ya que si se vulnerara una clave de la misma, podría afectar a gran cantidad de personas o organizaciones; pudiendo llegar a graves perjuicios económicos en las mismas.

Con esto es todo para esta entrada, a modo de ampliación de información os dejo un enlace a una CPS de una Autoridad de Certificación Nacional, la cual se ha construido siguiendo los estándares marcados por la RFC 3467.

Más sobre certificado digital e infraestructura de PKI en próximas entradas. Como siempre, muchas gracias por leernos.

CPS Agencia de Certificación de la Comunidad Valenciana (ACCV) – http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-V3.0.pdf

Seguimos teniendo tiempo. Desde aquel famoso Día Mundial de IPv6 de 2011, dónde los principales operadores en internet pusieron en funcionamiento su infraestructura para este protocolo, no se ha vuelto a oír mucho movimiento. Pero sí es verdad que se van planteando posibilidades y se van perfilando opciones de migración. Los tiempos no se han fijado y teniendo en cuenta el alcance global, la cosa va para largo.

Esto no quita que se empiece a plantear y a estudiar cómo enfocar esta migración. Si bien, dependemos de la propia tecnología, ISPs, software de los dispositivos, etc. la mayoría de implicados están poniéndose al día sin dilación y siempre es recomendable entender la situación. Claro está que antes de mover un dedo hay que entender bien los funcionamientos de los protocolos, y ver sus implicaciones tanto a nivel de seguridad, como de gestión y configuración, para estar preparado ante cualquier posible eventualidad.

IPv6 cambia por completo la visión que tenemos de las comunicaciones. El hecho de disponer de una única dirección para encontrar cualquier equipo, sin necesidad de realizar NAT, así como el hecho de tener obligatoriamente IPSEC en el propio protocolo, nos hace rediseñar la base de nuestra visión de las redes. Este protocolo redefine la esencia de las comunicaciones a todos los niveles.

Debemos sentarnos y valorar las implicaciones de este cambio, y plantearnos los primeros pasos para acometerlo. Para simplificar, sin entrar en detalles técnicos, podemos decir que hay 3 modelos de migración a estudiar:

• Doble Pila: Los dispositivos de red soportan ambos protocolos, y utilizan cada uno de ellos en función de la configuración de los destinos. En principio es muy sencillo y escalable, pero implica tener duplicidades que pueden repercutir en la gestión y los recursos de la infraestructura.
• Tunelización: Consiste en encapsular los paquetes IPv6 en paquetes IPv4, de manera que para la mayor parte de la topología IPv4 es transparente, salvo en los extremos dónde se encapsula y se desencapsula el protocolo. Los dispositivos extremos trabajarían como si de un túnel se tratase.
• Traducción: Se requiere una traducción entre protocolos cuando algún dispositivo implicado no soporta, o no contempla uno de los protocolos, generalmente no soporta IPv4. Se requiere un pool de direcciones para asignar en la propia traducción.

Desde mi punto de vista, obviamente dependerá de cada caso, creo que la primera opción sería la ideal. De esta manera tenemos los dos entornos en funcionamiento y podemos ir pasando servicios poco a poco, de manera lo más transparente posible para los usuarios/clientes, los que en el fondo mandan, y a los que no queremos marear nunca más de lo necesario.

Mi intención con esta entrada era recordar que IPv6 cada vez está más cerca, y que hay que empezar a contemplar opciones, que ya están muy trilladas, y no podemos dormirnos en los laureles. Pero que no nos entre el pánico porque en nuestro sector, gracias a Dios, se plantea siempre todo desde el punto de vista de la simplicidad para todas las partes y de la manera más transparente posible de cara a la gestión de servicios.

Lo que está claro a fin de cuentas, viendo cómo avanza la tecnología hoy en día, es que no cabe la posibilidad de quedarnos anclados en el pasado. Si no nos actualizamos, poco a poco iremos perdiendo servicios que solo estarán disponibles para los nuevos protocolos. Y al final sí que nos entrará la sicosis de estar aislados del mundo.