El blog de los empleados
de Telefónica I+D

Autor: Erik Miguel Fernández

El martes salió la noticia de que se había detectado en Irán un ataque de suplantación SSL contra los usuarios que querían conectarse a la web de Gmail.

Se trata de un ataque man-in-the-middle en el que se emplea un certificado falso. Cuando el usuario intenta conectarse a Google de forma segura, en realidad se conecta al atacante, que para establecer la conexión le envía un certificado falso diciendo que es Google. La autoridad certificadora es legítima (DigiNotar), pero DigiNotar no tiene autoridad para expedir certificados de Google.

El problema es que en algunos sistemas y navegadores se chequea que la autoridad certificadora es legítima, pero no se chequea que además de ser legítima tenga autoridad para emitir ese certificado en particular.

El resultado en esos navegadores es que el usuario no percibe absolutamente nada y cree estar en una conexión segura con Google, cuando en realidad está en una conexión segura con el atacante (que a su vez establece una conexión segura con Google para redirigirle el tráfico y que el usuario no perciba nada). Con ello, el atacante tiene acceso a todo lo que circule por la conexión (usuario, contraseña, correos enviados o leídos, destinatarios, etc.). También podría manipular la conexión para enviar información falsa al usuario, ocultarle información, suplantar al usuario para enviar información en su nombre, etc.

 Si el navegador está programado correctamente, en estos casos debe generar una alerta de seguridad para avisar al usuario (otra cosa es que el usuario decida ignorar la alerta y conectarse de todos modos…)

Ayer jueves nos enteramos que además de Gmail y otros servicios de Google, también han sido atacadas por el mismo sistema las conexiones de usuarios iraníes a Yahoo, Mozilla y WordPress, entre otras. Se sospecha que puede estar un Gobierno (presumiblemente el iraní) detrás del ataque.

 La entidad certificadora (DigiNotar, de Holanda) ha reconocido que le han robado una docena de certificados en un ataque que sufrió en julio de hackers iraníes. Mientras se resuelve el problema, tanto Google (Chrome), como Microsoft (Internet Explorer) como Mozilla han retirado a DigiNotar del listado de autoridades de certificación de confianza.

El problema aparece con Mac OS X, ya que a raíz del problema anterior se ha descubierto un bug por el cual Mac OS X no es capaz de desconfiar de certificados emitidos por una Entidad revocada por el usuario. Esto significa que, hasta que se resuelva el problema, se recomienda a los usuarios que no se fíen de los sitios web firmados por DigiNotar cuando se navegue con Apple Safari…

Por otra parte, Apple también ha tenido este mismo problema con el iOS, ya que no chequeaba en las conexiones que la autoridad certificadora realmente tuviera autoridad para emitir los certificados que enviaba al terminal. Esto afecta tanto a iPad como a iPhone en las versiones anteriores al iOS 4.3.5

Así que si el iPhone (o la iPad) tiene una versión de SO anterior a la 4.3.5, cuidado…

Por cierto, el jailbraking más sencillo del iPhone se hace hasta la versión 4.3.3, con lo que el que quiera hacer jailbraking en su iPhone debe saber que va a tener este bonito agujero de seguridad en sus conexiones SSL…

Autor: Carlos Plaza

En Internet muchos de los dispositivos diseñados para hacer el “bien” se utilizan para hacer el “mal” cuando hablamos de seguridad y privacidad.

Por ejemplo, el hecho de que la petición http incluya información sobre el tamaño de pantalla,  versión e idioma del navegador o las fuentes disponibles, etc., se realizaba para que los sitios web pudieran personalizar la distribución y localización del contenido ofrecido.

Sin embargo, esta información también se utiliza para obtener la huella digital de dispositivos con el fin de rastrear a los usuarios.

De la misma manera, la característica que se suele utilizar, mostrando mediante distintos colores un enlace visitado y no visitado ha sido empleado para “robar historiales”, por ejemplo una página web sospechosa contiene una lista de enlaces, y con JavaScript se revisa el color de los enlaces para saber si has visitado una de esas webs.

De esta manera, esa web puede aprender “cosas interesantes” como bancos (de datos)  visitados para identificar ataques “phising”

 Existen incluso empresas que venden productos o servicios que son utilizados por programadores de la Web para “robar historiales” o empresas que quieren saber si un usuario que visita su web ha visitado antes otras webs con información acerca de la empresa (Tealium).

Este dispositivo se ha extendido por comprometer la privacidad del usuario de una forma sofisticada, según han publicado   investigadores de la Universidad de Stanford  recientemente: un profundo estudio de una empresa rastreadora online la cual comprueba si el usuario ha visitado alguna página web de una lista de más de 15000 enlaces, divididos cuidadosamente en categorías como compras de grupo, aplicaciones para casa ,coches, o incluso información delicada como la salud o asuntos financieros…

¿Cuál es la protección de usuario disponible?

Navegadores como Firefox incorporan en sus últimas versiones un seguro para protegerse del “robo de historiales”, aunque nunca se garantiza al 100%  que los asaltantes no sean capaces de burlar la seguridad( por ejemplo, en vez de utilizar JavaScript utilizan máscaras de pantalla para los enlaces visitados)… De hecho, en la comunidad Mozilla han tardado unos años en elegir un mecanismo, ya que no había una opción clara para eliminar el ataque sin afectar a otras funcionalidades.

Así que no es una mala idea utilizar algunos complementos gratis- como Ghostery  u otras herramientas que previenen el rastreamiento y evitan la ejecución de comandos por parte de rastreadores bloqueados- o NoScript para bloquear /permitir comandos de forma selectiva. Y por supuesto, configurar tu navegador para eliminar el historial una vez terminado.

Autor: Juan Pedro Fernández-Palacios

El aumento progresivo de capacidad tanto en el acceso fijo como en el móvil está introduciendo una gran presión de tráfico en el núcleo de red lo que podría generar importantes problemas de escalabilidad y eficiencia en costes a corto y medio plazo. En este artículo, se propone la evolución hacia un nuevo modelo de red de transporte escalable y fácil de operar capaz de ofrecer nuevos servicios y de absorber las nuevas demandas de tráfico con un mínimo coste.

Situación actual del núcleo de red

En la actualidad, el transporte troncal y metropolitano se caracteriza por la multiplicidad de redes, tecnologías y suministradores. Las redes metropolitanas, encargadas de agregar el tráfico procedente de los diferentes nodos de acceso (p.ej DSLAM, OLTs, Nodos B, empresas, etc), están típicamente basadas soluciones MAN Ethernet de diferentes suministradores. Por otro lado, tanto el acceso a los centros de servicio (voz, video, datos, etc) como la interconexión con otros operadores se realizan sobre el núcleo IP/MPLS compuesto por nodos de acceso y de tránsito de diferentes suministradores.

Figura 1.-Modelo actual de núcleo de red

El núcleo de red podría constituir un cuello de botella

Las estimaciones para el futuro hacen pensar que el coste de incrementar la capacidad de transmisión de los nodos con las tecnologías actualmente utilizadas haga entrar a las operadoras entrar en márgenes negativos.

Una de las soluciones adoptadas por algunas operadoras  para hacer frente a este problema ha sido el despliegue de una malla fotónica capaz de conmutar circuitos ópticos de gran capacidad sin necesidad de realizar costosas conversiones optoelectrónicas.

Por otro lado, los procesos de planificación de la red IP/MPLS y la malla fotónica son totalmente independientes lo que impide la aplicación de mecanismos optimización conjunta que permitan minimizar los costes totales de la red para demandas crecientes de tráfico.

Complejidad de operación en el modelo actual

Actualmente las actividades de operación de red  se realizan mediante le uso de diferentes sistemas de gestión en cada segmento de red: MAN Ethernet, núcleo d red IP/MPLS y malla fotónica.  Los sistemas de gestión  requieren de frecuentes inversiones en infraestructura (e.g servidores) y mantenimiento. Además, los procesos de actualización debidos a la introducción, de nuevos servicios, tecnologías o suministradores son lentos y complejos ya que a menudo requieren la implementación de desarrollos específicos para el operador.  Por otro lado,  la provisión y monitorización de servicios de conectividad entre segmentos de red operados por diferentes sistemas se resuelven normalmente mediante el uso de procedimientos y actuaciones manuales lo que complica y ralentiza el proceso.

Figura 2.- Modelo de operación en el núcleo de red

En resumen, podemos concluir que el modelo actual basado en el uso de diferentes procesos de planificación y sistemas de gestión reduce la escalabilidad de la red, aumenta su coste y ralentiza, complica y encarece  la operación y desarrollo de nuevos de servicios.

Nuevo modelo de red multicapa

A continuación se describe un nuevo modelo de red propuesto en la iniciativa  “Scalable Multilayer Photonic Networks” de Telefonica I+D capaz de hacer frente a los problemas originados por el modelo actual.

¿Cómo simplificar la operación en el núcleo de red?

Se propone el uso de soluciones de plano de control multicapa capaces de coordinar de forma  automática los planos de control de la red IP/MPLS y la malla fotónica y de  reducir el tiempo y el número de actuaciones necesarias para la provisión de circuitos ópticos sobre malla fotónica entre nodos de la red IP/MPLS (e.g configuración automática de una nueva planificación, nuevos mecanismos de restauración multicapa, etc). La siguiente figura muestra el esquema genérico del escenario e demostración realizado en colaboración con Juniper en la conferencia OFC celebrada en Los Angeles en Marzo de 2011 [1]-[3].

Figura 3.-Escenario de demostración del prototipo de plano de control multicapa desarrollado por TID. OFC2011, Los Angeles 08 Marzo 2011

Este solución,  es capaz de coordinar automáticamente una red IP/MPLS y una malla fotónica de diferentes suministradores mediante el uso de interfaces de señalización estándar. Estamos participando activamente en los grupos CCAMP y PCE del IETF. Hasta el momento se han realizado pruebas de concepto con diferentes suministradores como Juniper, ADVA y Huawei.

¿Cómo aumentar la capacidad y escalabilidad de la red?

Se propone el uso de herramientas de planificación multicapa capaces de optimizar conjuntamente los recursos y la capacidad de la red IP/MPLS y la malla fotónica. Una herramienta de planificación multicapa integrada, facilitaría el dimensionado coherente de ambas capas en un único ciclo lo que generaría importantes ahorros en CAPEX. La siguiente figura muestra la evolución de inversiones en el núcleo de red según el modelo actual (IP transit) y en el caso de aplicar estrategias de planificación multicapa (IP offloading).

Figura 4.-Comparación del CAPEX relativo en una red de tamaño medio cuando se sigue el modelo actual y el modelo de planificación multicapa. Fuente:  “CAPEX Savings by a Scalable IP Offloading Approach ”, TID, OFC2011, Los Angeles 08 Marzo 2011

Referencias

[1] http://www.lightreading.com/document.asp?doc_id=209272&f_src=lrdailynewsletter

[2] http://www.lightwaveonline.com/networking/news/Juniper-Networks-Telefonica-demo-IPoptical-multilayer-architecture-124348324.html

[3]http://www.juniper.net/us/en/company/press-center/press-releases/2011/pr_2011_06_22-08_01.html

Autor: Diego González

Los días 8 y 9 de Junio se celebró una reunión de OneAPI, un estándar de referencia en la apertura de capacidades del operador a terceros, en la sede de Telefónica I+D en Madrid. En ella se trataron interesantes temas sobre la exposición de capacidades del operador a terceros mediante APIs de red, un aspecto en auge y que está siendo estudiado bajo diferentes perspectivas en diversos grupos industriales y de estandarización.

En primer lugar, OMA (Open Mobile Alliance). Este organismo de estandarización por excelencia de la capa de aplicación es el encargado de definir APIs REST genéricos (OMA Parlay REST), que son reutilizados por la GSMA (GSM Association). Esta última se encarga de definir perfiles mínimos de interoperabilidad (GSMA OneAPI). Por otra parte, WAC es la iniciativa empresarial a través de la cual los operadores van a ofrecer a los desarrolladores un punto de acceso único a los APIs de red y tiendas de aplicaciones de los operadores.

La definición de APIs estándar para el entorno telco se ha constituido en una actividad clave en el panorama de estandarización actual, como forma de atraer al área de influencia del operador al cada vez más relevante ecosistema de desarrolladores y también como forma de agilizar el ciclo de creación de aplicaciones y servicios.

Estas APIs son expuestas por BlueVia, iniciativa pionera en la apertura de capacidades del operador a terceros. En BlueVia, cualquier desarrollador puede darse de alta y fácilmente, usando las herramientas que se facilitan, crear aplicaciones que utilicen capacidades del operador como Mensajería (SMS y MMS), Localización u obtención de información de contexto de usuario. Y lo más importante de todo, el desarrollador recibe una parte de los ingresos generados por el tráfico de red (revenue share).

¿Cuál fue el objetivo de la reunión?

En la reunión celebrada en Madrid, se realizó una comparativa entre las APIs de BlueVia y las APIs de OneAPI, buscando similitudes y diferencias, para poder así concluir cuales son las mejores prácticas a la hora de exponer capacidades telco a desarrolladores mediante APIs abiertas..

También se aprovechó la reunión para que los diversos operadores y vendors que asistieron a la misma pudieran debatir sobre el futuro de la exposición de capacidades de red, sobre los siguientes pasos a dar. Se debatió acerca de cuestiones cómo: ¿Qué capacidades tiene el operador?, ¿cuales son más interesantes para los desarrolladores y, por tanto, se deben exponer?, ¿qué tecnologías y protocolos deben usarse? ¿qué herramientas y facilidades deben darse a los desarrolladores?

Para resolver todas estas preguntas, lo más importante es el feedback de los propios desarrolladores.

Respecto a los formatos y protocolos la industria lo tiene claro, puesto que así lo hacen ver los desarrolladores, la exposición de capacidades debe basarse en interfaces REST y, sin descartar otros formatos, lo que más demandan los desarrolladores es JSON como formato de intercambio de datos. Tanto las APIs de OneAPI como las APIs expuestas en BlueVia cumplen estos puntos.

En resumen, con iniciativas como BlueVia, basada en ofrecer un mismo set de APIs para acceder a las capacidades telco de todos los operadores del grupo Telefónica, se pretende conseguir que los desarrolladores accedan a dichas capacidades sin tener que lidiar con interfaces telco (desconocidos para los desarrolladores y menos ‘amigables’) y pudiendo usar el mismo interfaz para acceder a diferentes operadores en todo el mundo. Es el ‘write once, run everywhere’. Y, claro, con un beneficio económico para el desarrollador, ya sea al vender sus aplicaciones o al recibir revenue por el tráfico que éstas generan.

Autor: Primitivo Matas 

Normalmente FMC (Fixed Mobile Convergence), término que describe las tecnologías que permitan una convergencia entre comunicaciones cableadas y las no cableadas o wireless, se asocia con dos tecnologías diferentes: Wi-FI FMC y Femtonodo FMC. La primera de ellas parte de terminales que utilizan tecnologías Wi-Fi y que , por tanto, exige unos dispositivos nuevos adaptados, mientras que la segunda hace uso de terminales “normales” de telefonía móvil que se conectan a través de nodos específicos denominados Femtonodos, tanto en el hogar como en otros entornos de interiores descongestionando la red móvil y mejorando la cobertura.

Los Femtonodos(o Home Enhanced Node B, en terminología 3GPP)  son estaciones base de telefonía móvil muy pequeñas, de muy poca potencia y coste reducido que se conectan con el resto de la red utilizando la conexión a internet del hogar (ADSL o similar) o de cualquier empresa y que son capaces de realizar, con menos capacidad (menos usuarios con llamadas activas a la vez), las misma funciones de una estación base en entornos de interior limitados. Además, al tener un enlace directo con el resto de dispositivos conectados a internet, nos va a permitir la conexión con otros sistemas como centralitas telefónicas (PBX ), dispositivos del hogar (televisión, vídeo…) o entre Femtonodos que trabajen de manera coordinada en entornos empresariales.

Existe un mundo de diferentes capacidades ofrecidas por este enlace convergente:

Integración con la red de transmisión de datos o “local breakout”. Permite a los sistemas de Femtonodos desviar su tráfico de voz y dato sobre Internet sin necesidad de utilizar la arquitectura de red propia del operador móvil.

Interconexión entre Femtonodos. Permitiría, entre otras cosas la coordinación entre grupos de Femtonodos para permitir traspasos entre ellas, de forma análoga a los traspasos que se realizan entre las diferentes estaciones base en el exterior.

 Interconexión PBX. Permitiría activar la conexión entre dispositivos móviles con una centralita analógica tradicional, utilizando los servicios que la misma ofreciera en una empresa, como marcación por extensión, conexiones entre diferentes sedes de la misma empresa…

En un mundo en búsqueda continua de mayor rapidez, eficacia y calidad de las comunicaciones móviles los Femtonodos, son sin duda alguna un paso adelante. No solo consiguen mejorar, con un coste muy bajo, la cobertura en áreas sensiblemente problemáticas, sino que nos abre un Nuevo Mundo de posibilidades de utilización del terminal móvil como un dispositivo multi-servicio tanto en el hogar cómo en entornos empresariales.

Los Femtonodos, podrían cambiar, a corto plazo la industria de telefonía móvil. Los operadores pueden pensar en construir una nueva generación de redes con un coste inferior y una arquitectura de red que permitiera la utilización de internet como medio de comunicación, abriendo un mundo de posibilidades y servicios novedosos para el usuario final basados en las transacciones hacia la red local, la integración con sistemas de telefonía fijas o las comunicaciones entre los Femtonodos.

Autor: Carlos Juan Díaz

El Consejo de la Unión Europea (Consejo de Ministros) ha propuesto un conjunto de nuevas normas que establecen penas más severas para los denominados delitos cibernéticos (los ataques masivos de denegación de servicio están de moda y grupos como Anonymous, cada día están más presentes en los medios de comunicación). Estas normas están pendientes de ser ratificadas por el Parlamento Europeo para convertirse en oficiales.

Aunque no queda muy claro cómo se procederá a identificar y luego procesar a los atacantes (se pretende crear, a nivel europeo, una unidad especializada en cibercrimen dependiente de la Europol), las sanciones ya están definidas:

• Todo aquello que pueda considerarse delito cibernético tendría una pena de prisión de al menos dos años (incluso en grado de tentativa).
• Se introducen sanciones específicas para los desarrolladores y distribuidores de malware, al igual que para aquellos que se dediquen al robo de contraseñas.
• Los creadores/administradores de botnets se enfrentarán a penas superiores a 3 años (ataques cometidos utilizando un número significativo de los sistemas).
• Para ataques organizados que causen daños graves a sistemas de terceros, se proponen penas a partir de 5 años (aquí encajarían a la perfección las acciones de protesta (ataques) perpetradas por Anonymous).
• Del mismo modo la intercepción ilegal de comunicaciones se convertirá en un delito penal. 

Las normas también tienen como objetivo mejorar la cooperación entre los países de la UE, mecanismos de comunicación de incidentes entre sus miembros (soporte 24/7 y capacidad de respuesta urgente a consultas). Del mismo modo los Estados miembros estarán obligados a recoger datos estadísticos ‘básicos’ sobre los delitos cibernéticos.

Las nuevas normas actualizarán la legislación vigente, (basada en los acuerdos adoptados a finales de 2004 en la Convención de Budapest). 

El documento completo podéis encontrarlo en:

http://www.consilium.europa.eu/uedocs/cms_data/docs/pressdata/en/jha/122516.pdf (Cybercrime – Attacks against IT systems)

Autor: Luis Cucala

Después de tanto tiempo hablando del llamado “Wi-Fi offloading”, parece que está tomando fuerza una nueva tendencia que podríamos llamar “femto offloading”; que consiste en descargar la capa macro de 3G mediante femtonodos.

En 2010 O2 UK puso en marcha una iniciativa que se ha traducido en una oferta comercial llamada “O2 Wifi”.

Básicamente consiste en que se instalan femtonodos que incluyen Wi-Fi en sitios públicos, como restaurantes de comida rápida, bancos, centros comerciales. El atractivo para el pequeño negocio donde se instala el equipo es la posibilidad de ofrecer Wi-Fi gratuito a sus clientes, y para los operadores la ventaja está en disponer de emplazamientos gratuitos donde dar cobertura 3G en interiores, descargando además a la capa macro.

Esto supone una ventaja considerable con respecto a la situación anterior, donde O2 UK pagaba a operadores de red Wi-Fi, como por ejemplo The Cloud, por permitir que nuestros clientes se conectaran a sus puntos de acceso, y además tenía que pagar al dueño de cada local donde se instalaba un femtonodo o una micro. Con la nueva estrategia, el dueño del local no cobra porque le instalemos un equipo que de cobertura 3G, porque a cambio ofrecemos la conectividad Wi-Fi que quiere para sus clientes. Todos contentos.

La tendencia se generaliza. El operador coreano SK Telecom planea instalar este año 10.000 femtos HSPA+ con Wi-Fi en lugares públicos. La noticia está aquí. El despliegue recibe el nombre de Data Femto, está orientado solo a datos, y se basa en equipos de un fabricante coreano llamado Contela, que emplea chipsets de IP Wireless. El despliegue que proponen es en este caso para entornos de alto tráfico, de modo que cada femtonodo puede soportar hasta 16 conexiones simultáneas, y la conectividad Wi-Fi se incorpora para complementar la capacidad del femtonodo.

De esta forma, la red de femtonodos descarga de tráfico a la capa macro 3G, y Wi-Fi se emplea para descargar a los femtonodos del tráfico menos crítico.

Autor: Marcos Reyes

Nodejs surge como una forma de sacar valor a la experiencia actual en lenguajes de scripting (en este caso javascript) en el lado servidor. Los perfiles de los desarrolladores Web suelen estar alejados de los problemas típicos que aparecen en los servicios de backend (sobre todo en cuanto a concurrencia y mejores practicas para el acceso a recursos compartidos y/o de entrada salida). Y por otra parte han incrementado la experiencia en programación asíncrona y orientada a eventos.Nodejs simplifica hasta el extremo este tipo de tareas, proponiendo un modelo de ejecución y programación “cerrado” y fácilmente inteligible que potencia la realización de servicios “eficientes” sin necesidad de tener en cuenta la complejidad habitual de este tipo de sistemas. Podría decirse que con Nodejs es difícil hacer las cosas mal.

En el lado negativo tenemos muchas funciones anidadas y clousures, así como una programación orientada a eventos que puede dificultar la inteligibilidad del código en algunos casos, pero que no dejan de ser buenas herramientas para definir el comportamiento de un servidor.Por supuesto NodeJs y su motor Javascript (V8) no son la opción más interesante para realizar procesamientos complejos de la información. No es tecnología para multiplicar matrices. Aunque el rendimiento de la V8 y sus mecanismos de optimización (JIT) proporcionan un rendimiento en ejecución más que aceptable para el dominio en el que NodeJs esta centrado: entornos en los que se necesita un intermediario que obtenga y proporcione datos presentes en otros sistemas (servir contenidos, acceder a una base de datos, hacer de proxy a servicios…). También se encuentra especialmente indicado para proporcionar datos en modo streaming sobre una misma conexión cliente. En realidad este es el escenario más común con el que nos encontramos en nuestros backend de servicios.

Modelo de ejecución

Desde el punto de vista del programador cada proceso servidor Nodejs cuenta con un único thread para servir todas las peticiones de los clientes (permitiendo N servidores diferentes asociados a dicho proceso). Todo se serializa en este punto, bajo un único bucle de eventos, evitando los problemas de la programación multithread. Ya no tenemos que preocuparnos de proteger memoria compartida o de problemas de carreras, minimizando tanto tiempos de desarrollo como la aparición de errores. Hay que tener en cuenta que servir una nueva petición supone muy poco esfuerzo para el proceso NodeJs, siendo una tarea mucho más ligera que crear un nuevo thread de petición tal y como harían gran parte los servidores multithread al uso.
Conviene remarcar que un fallo en la lógica de servicio de dicho thread (por ejemplo un memory-leak) puede hacer que el proceso NodeJs se “pare” dejando de servir todo tipo de peticiones. NodeJs ayuda a que esto no ocurra (gracias a su modelo de programación y a warnings que nos advierten de posibles problemas), pero conviene ser cuidadoso en este punto.
Respecto a los servidores que pre-crean sus threads de petición en el arranque (P. ej Cherokee) las diferencias no son tan obvias. Si se desea paralelismo a este nivel, deberían lanzarse N procesos -shared nothing- NodeJS junto con algún mecanismo de distribución de carga. Un mecanismo bastante versátil en la era Cloud y que puede considerarse muy interesante frente a un modelo multithread con memoria compartida.

Internamente NodeJs posee un pool de threads autogestionado. Sobre este pool, en general, se lanzan todas las tareas que requieren algún tipo de entrada salida (invocación a servicios, acceso al SO…) o todas aquellas que tareas que se consideren bloqueantes. Es decir NodeJs es monothread para el programador (y para el flujo de servicio principal), pero no lo es en ejecución. Todas las llamadas que impliquen una cierta espera son invocadas de forma asíncrona, proporcionando bien un manejador de callback, bien un patrón de suscripción a eventos. A partir de este punto es el pool de threads interno el que se encarga de la ejecución de la tarea, emitiendo el evento correspondiente cuando esta finalice (o ante cualquier otro supuesto que requiera nuestra intervención). Los bloqueos de espera en el thread principal son por tanto eliminados por construcción, tenemos solo un thread, pero en general siempre esta listo para servir trabajo (se supone que un proceso NodeJs puede servir sin problemas unos 10.000 clientes simultáneos), con una carga mínima en el sistema por cada nueva petición.

Fragmento Servidor

var http = require(’http’),

io = require(’socket.io’),

url = require(’url’);

console.log(’starting websocketserver’);

server = http.createServer().listen(8081);

var socket = io.listen(server);

socket.on(’connection‘, function(client){

console.log(’new client:’+client.sessionId);

client.broadcast(’New client connected:’+client.sessionId);

client.on(’message‘, function(msg){

switch(msg.type)

{

case ‘newuser’:

var err = createUser(msg.text, client.sessionId);

if (err==0) client.send(’Already registered’);

else client.send(msg.text+’ Is your new Nick Name’);

break;

default:

var userid = getUser(client.sessionId);

if (userid!=null){

//All but sender

client.broadcast(’<strong>’+userid+’</strong>->’+msg.text);

//Sender only

client.send(’<-’+msg.text);

}

else client.send(’<-YOU MUST STABLISH A NICK-NAME’);

}

});

client.on(’disconnect‘, function(){

console.log(’disconected:’+client.sessionId);

deleteUser(client.sessionId);

});

});

//(…) +=aux functions)

Fragmento CLIENTE

<script>

(…)

var socket = new io.Socket(SERVERADDR, SERVERPORT);

var nick=null;

socket.on(’connect’, function(){

var board = document.getElementById(’board’);

board.innerHTML = board.innerHTML + ‘</br>You are connected to chat’;

});

socket.connect();

socket.on(’message’, onMessage);

var board = document.getElementById(’board’);

function onMessage(message){

board.innerHTML = board.innerHTML + ‘</br>’ + message.text;

}

function sendbroadcastmsg (text){

var msg = new Object(); msg.type=’broadcast’;

msg.text=text; socket.send(msg);

return false;

}

function sendnewuser(name){

var msg = new Object();

msg.type=’newuser’;

msg.text=name;

socket.send(msg);

nick = name;

}

</script>

 Autor: Rafael Valdavida

Como los medios de comunicación han dejado  patente a lo largo de los últimos meses es el momento del IPv6. El espacio de direccionamiento de IPv4 se acaba, hay que buscar una solución e IPv6 parece ser que es lo primero que se le viene a la cabeza a todo el mundo. De hecho los últimos (y no tan últimos) productos tecnológicos incorporan ya soporte para IPv6. Un claro ejemplo es el Windows 7. Su pila IPv6 está activada por defecto y de forma preferente. Es decir, si ha de elegir entre IPv4 e IPv6 elegirá esta última.

Desde el punto de vista tecnológico IPv6 no es simplemente una solución para la escasez de espacio de direccionamiento. Se trae bajo el brazo su correspondiente juego de particularidades y un buen conjunto de protocolos adicionales (cabeceras de extensión, ICMPv6, NDP,  MLD, IPSec, ….). Para un potencial atacante cada una de las particularidades y características de esos protocolos es un campo abonado para el florecimiento de nuevas vulnerabilidades que pueden permitir todo tipo de acción maliciosa.

Centrémonos en UNA funcionalidad de UNO de esos protocolos. Una que por su relevancia y cercanía al usuario puede tener un mayor peso en la implementación de la solución IPv6. El protocolo NDP (Neighbor Discovery Protocol) se encarga, mediante la utilización de cinco tipos de mensajes ICMPv6, de proporcionar una serie de funcionalidades básicas. Entre ellas se encuentra la resolución de direcciones (identificar para una dirección IP dada qué dirección MAC le corresponde). Parece algo bastante básico para el funcionamiento de todo el tinglado.

En su definición, el protocolo NDP no especifica la necesidad de autentificación por parte de los participantes, lo que viene a significar que:

• Cualquiera puede enviar cualquier mensaje (y estamos hablando de mensajes básicos para la configuración y el funcionamiento de la red).
• Es muy difícil (¿imposible?) distinguir si la información de un mensaje dado proviene de quien se supone que debe provenir.

De hecho existe una tabla resumen sobre los posibles ataques a los que resulta susceptible el discutido protocolo NDP:

Es posible que la tabla requiera un poco más de explicación (qué son todos esos acrónimos y ‘palabras raras’) pero de por sí resulta muy ilustrativa. Incluso se puede adivinar que algunos de los problemas presentados no tienen, de momento, una solución clara (última columna).

En general, a lo largo de toda la especificación de IPv6, cada vez que surgen cuestiones sobre la seguridad la solución se redirige al uso de IPSec. No es este lugar para discutir las bondades o deficiencias de IPSec. Baste con decir que para el entorno del NDP, a día de hoy, IPSec no es una solución viable. Requiere no solo configuraciones engorrosas de claves privadas y públicas si no también resolver cuestiones sobre intercambios de claves (IKE). Bajo estas circunstancias nos encontramos con situaciones de vulnerabilidad bastante comunes. Por ejemplo, cualquier Windows 7, en su instalación por defecto, está preparado para funcionar bajo IPv6 y por tanto soporta el protocolo NDP de forma automática. Sin embargo en el proceso de instalación del sistema operativo o de su conexión a la red no se realiza ningún tipo de activación y configuración de IPSec.

Llegados a este punto yo diría que un posible atacante no solo dispone de un campo abonado. El campo ha florecido. Veamos un ejemplo de cómo un usuario malicioso puede aprovecharse de la situación descrita.

‘Man In The Middle’ en IPv6

El entorno considerado consta de los siguientes elementos:

• Red local IPv6
• Equipos A y B legítimos
• Equipo Z malicioso

En IPv6, como en IPv4, cuando el equipo ”A” quiere comunicarse con el “B” necesita saber la dirección de capa de enlace (MAC) de dicho equipo “B”. Para obtenerla , “A” envía a la red un mensaje ICMPv6 del tipo “Neighbour Solicitation” a una dirección IPv6 multicast (dirección en la que escuchan todos los nodos de la red) con el formato “ff02::1:ffXX:YYZZ”. Donde XXYYZZ se corresponde con los últimos tres bytes de la dirección IPv6 con la que desea comunicarse. El elemento “B” contestaría hacia “A” con un mensaje ICMPv6 del tipo “Neighbour Advertisement” donde “B” envía toda la información de capa de enlace necesaria para que “A” se comunique con “B”.

Conociendo este comportamiento, y con todo lo anterior dicho sobre la carencia de autentificación, “Z” solo necesitaría enviar mensajes ICMPv6 de tipo “Neighbour Advertisement” indicando:

• a “A” que la dirección IPv6 de “B” se corresponde con la dirección MAC de “Z”
• a “B” que la dirección IPv6 de “A” se corresponde con la dirección MAC de “Z”

Nada impide que “Z” pueda enviar este tipo de mensajes (los mensajes “Neighbour Advertisement” pueden ser enviados espontáneamente para indicar cambios en la configuración local o nuevas incorporaciones) y tras la recepción de estos mensajes “A” y  “B” almacenarán la información fraudulenta en sus cachés y comenzarán a utilizarla. Como resultado toda la información enviada de “B” hacia “A” y de “A” hacia “B” pasará por “Z” que podrá:

1. Acceder a la información intercambiada
2. Modificar la información intercambiada
3. Interrumpir la comunicación

Acabamos de replicar el ataque de envenenamiento de caché, típico de la tecnología IPv4, en IPv6 y sin más complejidad que la generación de dos paquetes IPv6 manipulados. La herramienta scapy, de libre acceso, ofrece toda la funcionalidad requerida. La solución, hoy por hoy no es sencilla, la opción sería proporcionar mecanismos de autentificación. Estaríamos hablando de configurar IPSec o una segunda posibilidad de más fácil aplicación y desarrollada para este problema que es el SEND (SEcure Neighbour Discovery). Pero eso ya es tema para otro/os artículos.

Autor: Ignacio Berberana

Un paso más en la historia de Wi-Fi. Se ha iniciado ya la votación en IEEE de la versión 1.0 de la nueva modificación del estándar 802.11  (bueno, de una de las nuevas modificaciones), la denominada 802.11ac, que pretende soportar tasas binarias próximas a 1 Gbit/s en frecuencias menores de 6 GHz. Lo que se está votando es si la aprobación del estándar se pasa a una nueva fase que se denomina votación de los ‘espónsores’ (quizás sería más correcto hablar de promotores). Es decir, si el resultado de la votación es positivo, se da por concluido el trabajo inicial del grupo de trabajo, en el que pueden votar todas las personas que cumplan con los requisitos necesarios para hacerlo (relacionados con la asistencia a las reuniones y el hecho de haber ejercido le derecho al voto en votaciones anteriores), y se pasa a una fase en la que votan compañías que se comprometen a apoyar al estándar resultante (para estar incluido en la lista de ‘espónsores’ hay que pagar una cuota a IEEE). En esta ronda de votaciones, si se vota que no se aprueba el estándar, hay que indicar también qué es lo que habría que cambiar en el mismo para votar positivamente a su aprobación. Si el grupo de trabajo decidiera no aprobar remitir el borrador a los ‘espónsores’, debería seguir trabajando para producir una nueva versión aceptable. El plazo de votación, que hasta hace poco se realizaba mediante carta (cosas de IEEE), finaliza el 26 de junio.

¿Quiere esto decir que estamos próximos a la aprobación definitiva del estándar? No necesariamente. En el caso de 802.11n, por ejemplo, pasaron más de tres años desde que se aprobó la versión 1.0 en el grupo de trabaja TGn (mayo de 2006) hasta que se aprobó su publicación por un comité denominado RevCom (septiembre de 2009), último paso en el proceso de producción del estándar.

Previsiblemente en el caso de 11ac los plazos serán más reducidos. Después de todo, las modificaciones propuestas no son fundamentales: MIMO de mayor orden (hasta 8×8 – frente a 4×4 en 11n), agregación de canales (80 y 160 MHz – un máximo de 40 MHz en 11n) y modulaciones más complejas (hasta 256QAM, lo que permite transmitir 8 bits por hercio – 64 QAM en 11n). Es decir, más de lo mismo. Las principales novedades son el uso de los denominados códigos cortos (que pueden ser más efectivos para datos que requieren una latencia baja) y el soporte a MIMO multiusuario (que se basa en asignar los mismos recursos a dos usuarios espacialmente separados mediante el uso de antenas directivas).

En paralelo, se está desarrollando otra versión del estándar, la 802.11ad, que está diseñada para operar en la banda sin licencia de 60 GHz y que, por tanto, tiene un rango de cobertura más reducido (normalmente limitado a la habitación en la que esté instalado el punto de acceso) pero puede soportar hasta 7 Gbit/s (teóricamente). En este caso se está votando si se remite a los ‘espónsores’ la versión 3.0 del borrador de la misma.

Y sí, IEEE ha agotado todas las letras disponibles para numerar las modificaciones del estándar y por eso en las nuevas se utilizan dos. Por cierto, el uso de minúsculas indica que se trata de una modificación de un estándar existente, mientras que si la letra es mayúscula indica que se trata de un estándar independiente.