Los empleados deciden en qué idioma publican sus entradas.
Puedes encontrar más contenidos seleccionando el idioma inglés en el enlace superior.

Notification Server

Autores: Fernando Rodríguez Sela, Guillermo Lopez Leal, Ignacio Eliseo Barandalla Torregrosa.

Introducción

Hoy en día las aplicaciones móviles recuperan información de múltiples sitios y de manera asíncrona. Los desarrolladores tienen dos caminos para recuperar esta información:

  •   Polling: Periódicamente solicitar la información al servidor.
  •   Push: El servidor envía la información al cliente cuando la información requerida está disponible.

El primer método esta totalmente desaconsejado debido a la gran cantidad de conexiones que se realizan al servidor sin necesidad, ya que la información no está disponible y se pierde tiempo y recursos.

Es por ello que los métodos de recuperación de información de tipo PUSH son ampliamente utilizados, sin embargo el cómo funcionan actualmente las plataformas PUSH hacen un uso indebido de la radio móvil consumiendo gran cantidad de batería y recursos del usuario.

En este artículo se pretende explicar cómo se gestiona este tipo de mensajería en la actualidad, los problemas que tienen las actuales soluciones y finalmente cómo Telefónica Digital, dentro del marco del desarrollo del sistema operativo Firefox OS, ha diseñado una nueva solución más amigable con la red y con un bajo consumo de batería en los terminales móviles.

Estado del arte

Históricamente las operadoras móviles ofrecían (y ofrecen) mecanismos REALES de notificaciones PUSH, también conocidos como WAP PUSH. La tecnología WAP PUSH permite “despertar” las aplicaciones cuando se requiere alguna acción de las mismas por parte del lado servidor (sin interacción por parte del usuario). El envío de mensajes WAP PUSH se realiza en el dominio de circuitos, el mismo utilizado para la voz y los mensajes cortos SMS, y es por ello que el usuario no necesita establecer una conexión de datos para que este tipo de mensajes funcione correctamente.

La solución de WAP PUSH funciona muy bien cuando el usuario se encuentra registrado en la red móvil, pero si se encuentra sin cobertura y conectado a Internet por WiFi no puede recibir este tipo de mensajes y si a esto le sumamos que los mensajes PUSH conllevan un coste económico (básicamente se trata de un mensaje corto SMS) ha provocado que los grandes sistemas operativos para teléfonos inteligentes (iOS de Apple y Android de Google) hayan implementado una solución paralela que funcionase independientemente de la red móvil a la que pertenece el usuario y que pueda funcionar sin problemas cuando se encuentran utilizando redes WiFi.

Problemas de las soluciones actuales

Estas soluciones alternativas se basan en un servidor público accesible desde Internet mediante el cual se canalizan toda la mensajería PUSH para los terminales móviles y actúan de intermediario entre las plataformas de las aplicaciones y los terminales móviles.

Estas nuevas plataformas de mensajería PUSH tienen una importante barrera que superar ya que los terminales móviles suelen encontrarse en redes privadas (no accesibles desde Internet) y cuya comunicación es gestionada a través de servidores NAT y firewalls que impiden el acceso directo al teléfono desde el servidor, debido a esto, los sistemas operativos abren una conexión permanente (no la cierran) con estos servidores propietarios y utilizando este canal de comunicación reciben las notificaciones PUSH cuando los servidores de terceros se la envían a la plataforma de mensajería.

Tanto Apple como Google han utilizado esta solución alternativa que obliga al teléfono a mantener una conexión abierta de forma permanente con el servidor y para evitar que esta conexión sea cerrada, ya sea por los propios temporizadores de TCP como los temporizadores de los servidores NAT que tienen que atravesar para llegar al servidor, se envían pequeños paquetes de datos, conocidos como keep-alive, que no contienen nada de valor y sólo sirven para indicar que algún dato está atravesando la conexión.

Esta solución tiene varios problemas:

  •   El tener que mantener conexiones abiertas en los routers intermedios reducen notablemente el rendimiento de estos provocando grandes problemas de escalabilidad en las redes móviles, piense que España podemos estar hablando de unos 15+ millones de teléfonos inteligentes (smartphones) conectados a Internet.
  •   Tormentas de señalización: Las redes celulares utilizan gran cantidad de mensajes de señalización para poder gestionar la ubicación del terminal, su estado, establecer nuevas comunicaciones,… Cada vez que se envía un paquete de datos, se generan una serie de mensajes de señalización. La gran cantidad de terminales móviles avanzados que se encuentran hoy en día en nuestras redes producen un efecto de sobrecarga en la señalización que deteriora la calidad de servicio ofrecida por las operadoras móviles.
  •   Por otro lado, estas soluciones, que a primera vista son válidas en redes “tradicionales”, ya sean cableadas como redes WiFi domésticas, no son válidas en un entorno de red móvil celular, ya que el funcionamiento de los MODEM radio que llevan los teléfonos están diseñados para bajar su consumo energético cuando no tienen nada que transmitir, sin embargo, estas soluciones PUSH usadas por los sistemas operativos más expandidos, tienen la obligación de enviar mensajes de keep-alive y por tanto evitan que el teléfono pueda alcanzar este estado de reposo, o bajo consumo energético.

El efecto co-lateral de estas soluciones es que las baterías de los terminales son consumidas a una gran velocidad para realizar tareas realmente redundantes (enviar pequeños mensajes para evitar que sus conexiones sean cerradas).

Estos problemas se ven aún más empeorados cuando vemos que muchas aplicaciones (populares todas ellas) hacen sus propias conexiones sin utilizar las ofrecidas por los sistemas operativos con lo que están multiplicando los problemas por cada aplicación.

¿Qué sucede en la red móvil?

Como comentamos anteriormente, las redes móviles funcionan de forma distinta a cómo se desenvuelve, por ejemplo, una red WiFi y el diseñar este tipo de soluciones para ser utilizadas en una red celular sin considerar primero cómo funciona dicha red, nos lleva a los problemas con los que nos enfrentamos hoy.

Para entender bien el problema, debemos tener en cuenta los distintos estados en los que puede estar el modem radio del terminal:

En la especificación de la 3GPP TS 23.060, podemos ver todo lo relacionado con los estados de la capa GMM (GPRS Mobility Management) correspondiente al dominio de conmutación de paquetes en terminales móviles. En la especificación  3GPP TS 25.331 se puede consultar la información relativa a la capa RRC (Radio Resource Control) donde se definen los estados a nivel radio.

Juntando los estados radio y GPRS podemos saber en que estado está el terminal.

NOTA: Por simplificar, en la siguiente tabla consideramos que no hay actividad en el dominio de circuitos, esto es, no hay llamadas de voz:

GMM

RRC

 
Estado 2G Estado 3G

3G

Descripción del estado
READY PMM-CONNECTED Cell_DCH El teléfono está transmitiendo o recibiendo datos usando un canal dedicado o un canal compartido HSPA.

Los temporizadores de Cell_DCH son muy cortos, de manera que si no hay nada que transmitir o no estamos recibiendo datos durante los últimos segundos, el temporizador nos llevará a Cell_FACH.

Este temporizador se conoce como T1 y puede variar entre 5 y 20 segundos.

Cell_FACH El teléfono ha estado transmitiendo o recibiendo datos hace unos segundos y debido a la inactividad (> T1) se ha movido a del estado Cell_DCH al estado Cell_FACH.

Si la inactividad continua durante T2 segundos, RRM ordenará al teléfono a moverse al estado Cell_PCH, URA_PCH o Radio Idle.

También es posible que el teléfono se encuentre transmitiendo o recibiendo pequeñas cantidades de datos, como pings, keep-alives, actualizaciones de celda…

Normalmente el temporizador T2 es de alrededor de 30 segundos.

Cell_PCH o URA_PCH El teléfono ha estado en Cell_FACH hace unos segundos y debido a su inactividad (superior a T2) el RRM lo ha movido de Cell_FACH a Cell_PCH o URA_PCH.

Sin embargo, la conexión de señalización permanece aún disponible a pesar de que no se van a enviar datos ahora.

Se mantiene establecida de forma que si en cualquier momento necesita ser utilizada no se tenga que restablecer nuevamente.

STANDBY PMM-IDLE Cell_PCH o URA_PCH El teléfono no está transmitiendo datos y la conexión de señalización se ha borrado, de todas formas, el contexto PDP continúa activo, por tanto dispone de una dirección IP válida.

Por esta razón es uno de los estados más interesantes dónde mantener un teléfono móvil el mayor tiempo posible ya que el consumo de batería es reducido pero su dirección IP se mantiene disponible para poder recibir información de la red.

En este estado no se gastan recursos: ni de red, ni batería, tráfico… Aún así puede transmitir o recibir información en cualquier momento.

Tan pronto como el enlace de datos necesite ser establecido, bien por el teléfono o bien por un servidor de la red, éste puede ser reestablecido cambiando el estado de la radio de Cell_PCH o URA_PCH a Cell_FACH o Cell_DCH. Este cambio lleva menos de medio segundo y consume muy poca señalización.

RRC IDLE Este caso es el mismo que el anterior con la salvedad que la radio está en modo Idle.

Cuando el teléfono está en Cell_PCH o URA_PCH sin ninguna actividad durante más del tiempo establecido por T3, El RRM moverá a la radio de *_PCH a Idle.

Reestablecer el enlace radio desde este estado puede llevar más de 2 segundos y muchísima señalización.

IDLE PMM-DETACHED RRC IDLE El teléfono no está transmitiendo datos y no hay establecida ninguna conexión de señalización y tampoco tiene abierto ningún contexto PDP.

En este estado, el terminal no dispone de dirección IP.

Si un teléfono tiene un contexto PDP, probablemente sea automáticamente cerrado después de unas 24 horas de no recibir ni transmitir información.

El consumo de batería en cada uno de estos estados es el que sigue:

  •   RRC Idle – 1 unidad relativa de consumo de batería.
  •   Cell_PCH – menos de 2 unidades relativas
  •   URA_PCH – menor que Cell_PCH en escenarios de movilidad e igual en escenarios dónde no hay movilidad
  •   Cell_FACH – 40 veces el consumo de IDLE.
  •   Cell_DCH – 100 veces el consumo de IDLE.

Como fácilmente se puede apreciar, las soluciones anteriormente comentadas y sus correspondientes mensajes de keep-alive evitan que el terminal pueda estar mucho tiempo en el estado IDLE de bajo consumo de batería.

La solución propuesta por Telefónica

Con todos estos problemas sobre la mesa y con la intención de hacer un sistema operativo con nuevas e innovadoras soluciones, Telefónica Digital en colaboración con Mozilla ha diseñado un nuevo sistema de notificaciones que evita el tener que mantener conexiones abiertas dentro de la red móvil.

Esta nueva solución, implementada y distribuida íntegramente con código abierto, define no sólo el cómo el servidor de notificaciones se debe comunicar con los terminales, sino también, los distintos APIs que se tienen que utilizar para comunicarse con el mismo.

Para solventar los problemas previamente mencionados, esta solución es capaz de mantener dos canales de comunicación con los terminales móviles, de manera que cuando estos se encuentran en una red no gestionada por la operadora, por ejemplo, en la WiFi doméstica del usuario, se mantiene la conexión abierta, al igual que se hace en las otras soluciones mencionadas, con el uso de WebSockets, sin embargo cuando el terminal se encuentra dentro de una red gestionada por la operadora, la conexión basada en WebSocket es cerrada por parte del servidor el cuál “despertará” al teléfono cuando éste tenga mensajes para él.

Para despertar el teléfono, la plataforma de notificaciones se basa en una solución simple a la par de elegante:

  •   Sabemos que en el momento que el terminal móvil establece una conexión de datos estableciendo un contexto PDP, su dirección IP (ya sea pública o privada) es mantenida por los servidores de la operadora (GGSN) y no por el terminal móvil, por lo que aunque este último entre en un modo de bajo consumo, su dirección IP no se pierde.
  •   Cuando el terminal se encuentra en IDLE pero con una conexión de datos establecida y la red tiene datos que enviarle (el GGSN ha recibido un paquete TCP o UDP para la IP del terminal) envía un mensaje de señalización conocido como PAGING utilizado para “despertar” al teléfono y sacarlo del modo IDLE. Este mensaje de PAGING es similar al utilizado por la red móvil para notificar al terminal que tiene que atender una llamada de circuitos (voz, SMS, …)
  •   Aprovechándonos de este modo de funcionamiento, la única pieza que nos faltaba para terminar el puzzle era poder enviar un mensaje directo al teléfono, pero al estar dentro de la red móvil (con direccionamiento privado) era necesario tener un servidor dentro de cada una de las redes móviles.

Pues bien, esta solución utiliza precisamente esto, un servidor de WakeUp dentro de la red móvil que enviará un mensaje UDP a la IP del teléfono. El teléfono al recibir este mensaje será “despertado” por la red y el teléfono procederá a conectarse al servidor de notificaciones utilizando la conexión basada en WebSocket para recuperar los mensajes pendientes.

 

Algunos ejemplos de aplicaciones actuales

Por razones obvias no podemos citar los nombres de las aplicaciones que os vamos a enseñar así como los modelos de terminales sobre los que se ha probado. Lo que si podemos decir es que se trata de aplicaciones muy populares, probablemente en su teléfono las tenga instaladas, y los terminales usados son también los más populares del mercado, con los sistemas operativos más usados en la actualidad.

Las siguientes gráficas podremos ver el consumo de datos que hacen estas aplicaciones cuando se encuentran en reposo, es decir, sin hacer nada en particular. Los colores indican distintos terminales.

Se puede observar que mientras que algunas aplicaciones hacen pequeños envíos puntuales, otras están transmitiendo de manera contínua.

Este estudio ha sido realizado por: Telefónica – NSN Smartphones lab

Como podemos observar, las aplicaciones intentan mantener su conexión  mediante “pings” realizados durante intervalos relativamente estables de tiempo. Mientras que la primera gráfica muestra una aplicación que manda mensajes cada 10 minutos, la segunda y la última hace que se envíen mensajes prácticamente de forma continuada, haciendo que el teléfono esté siempre en el estado máximo de la red, gastando recursos para simplemente decir “sigo vivo”.

Así, con nuestra solución, estos “pings” regulares se eliminarían completamente, haciéndose sólo cuando una notificación es recibida por el teléfono, mejorando el uso de la red, bajando la señalización, y además haciendo que la batería de los dispositivos de los usuarios dure más debido a estar en estados más relajados de la red.

Rápido, abierto e inteligente: Por qué Firefox OS cambia las reglas del juego

Autor: Carlos Domingo, Director de Desarrollo de Productos e Innovación de Telefónica Digital

Posteado originalmente en  Telefonica Digital blog

El lanzamiento de Mozilla’s Firefox OS es otro gran paso adelante – para los smartphones, para HTML5 y para llevar las maravillas de la movilidad al mundo entero y no solo a unos pocos privilegiados. Ya en el pasado Mobile World Congress presentamos la tecnología que estamos realizando con Mozilla en esta área, sobre todo porque estamos orgullosos de haber jugado un papel en lo que nosotros creemos que será una opción útil y convincente para los usuarios.

Basándose en HTML5, Mozilla ha creado una plataforma basada en tecnología open source que funciona incluso en los dispositivos asequibles pero que permite una experiencia de la máxima calidad.

Firefox OS combina HTML5 con un kernel Linux, permitiendo que cada función de un teléfono móvil sea desarrollada como una web app y corra utilizando una versión especial del web browser de Firefox.

Hacer una llamada, mandar un mensaje, tomar una foto será realizado mediante una app HTML5.

El resultado es una mejor experiencia y prestaciones incluso en los modelos de bajo precio. Y esto es crucial si vamos a poner smartphones en las manos de más y más clientes en el mundo en desarrollo. Como Brasil donde la tasa de penetración actual de smartphone es aproximadamente del 14% y solamente un pequeño porcentaje de personas tienen el dinero para comprar smartphones de gama alta de las marcas más importantes. Sin embargo, hay dispositivos Android por 100 dólares pero que usan versiones antiguas del sistema operativo que rápidamente quedan desfasadas y donde las prestaciones no son buenas.

Firefox OS puede proporcionar una mejor experiencia en ese rango de precios. Esa es la razón por la que somos tan entusiastas al llevar estos dispositivos a mercados como Brasil.

Los primeros datos que conocemos de Firefox OS son muy positivos con una gran apoyo de operadores y fabricantes de dispositivos. Además, el carácter abierto de la arquitectura es un buen presagio para conseguir el apoyo de los desarrolladores. La historia de la tecnología  sugiere que ser abierto y ofrecer valor son ingredientes comunes para conseguir el éxito. Así lo ha demostrado Mozilla dirigiendo la innovación en la navegación web con Firefox.

Ese es el porqué nos sentimos muy optimistas sobre las perspectivas de Firefox OS.

Lifewear “Mobilized lifestyle with wearables”

Autores: Fernando Goicolea, Jose Luis González

Los usuarios de nuevas tecnologías necesitan interactuar a diario con diversas interfaces de control proporcionadas por los distintos fabricantes de dispositivos electrónicos de uso diario como electrodomésticos, dispositivos multimedia o teléfonos móviles. Un buen número de usuarios reales de estas interfaces de control calificarían la interacción con las mismas como poco natural o muy compleja.

El proyecto LifeWear, “Mobilized Lifestyle with Wearables” se basa en la idea de que las interacciones entre personas y dispositivos electrónicos deben ser naturales, sin interfaces externas complejas, y propone mejorar la calidad de vida de las personas mediante la utilización de sensores y dispositivos integrados en la ropa.

LifeWear pretende cubrir un amplio abanico de necesidades entre los usuarios actuales o futuros de dispositivos electrónicos. Uno de los mayores retos del proyecto es desarrollar el uso de la monitorización fisiológica moderna con el objetivo de conocer en tiempo real distintos parámetros sobre el estado de las personas, como el pulso o la temperatura, y en su caso poder llevar a cabo diversas acciones como avisar a las emergencias sanitarias ante un problema de salud importante.

Por otro lado, el proyecto busca ir más allá de la telemedicina y la teleasistencia. Es posible desarrollar sistemas y dispositivos integrados en la ropa que permitan aprender las acciones del usuario en distintas situaciones. Concretamente se explora la posibilidad de utilizar estos dispositivos integrados en la ropa “wearables” en actividades como el entrenamiento deportivo o situaciones de trabajo con un riesgo importante, como en las que se ven involucrados bomberos o mineros por ejemplo. El abanico de posibilidades es muy amplio.

A lo largo del proyecto se llevarán a cabo investigaciones en últimas tecnologías sobre los siguientes campos: dispositivos y sensores integrables en la ropa, interacción Hombre-Maquina (Human Machine Interaction) y Hombre-Computador (Human Computer Interaction), aprendizaje de máquinas, computación ubicua centrada en la personalización, así como privacidad e interacción fluida. Los resultados del proyecto tendrán un gran impacto en la normalización de las tecnologías especializadas en sistemas que se puedan llevar puestos, así como en nuevos métodos de HMI y HCI, aplicables a un amplio abanico de dispositivos, como teléfonos móviles, equipos médicos o sistemas de domótica.

Los resultados de estas investigaciones serán difundidos por toda Europa por medio de las Universidades e Institutos de Investigación participantes en el proyecto.

El proyecto LifeWear reúne a más de 30 socios de distintos países entre los que se encuentra Telefónica PDI, constituyendo un consorcio internacional bajo el amparo de la oficina ITEA2 y el Subprograma Avanza de Competitividad (I+D+i).

El Área de Seguridad de PDI participa en el congreso de seguridad RootedCON 2012

Autor: Francisco Jesús Gómez

Un año más, y ya van 3, se ha celebrado en Madrid la RootedCON y el Área de Seguridad de PDI participó en el congreso.

¿Qué es la #RootedCON? Vamos a intentar situar estas jóvenes conferencias que se han convertido en solo tres sesiones en un referente a nivel nacional.

 

La RootedCON nace el año 2010 y en la web podemos leer:

Rooted CON nació con el propósito de promover el intercambio de conocimiento entre los miembros de la comunidad de seguridad, en particular reivindicando la enorme capacidad de los profesionales hispanoparlantes.

Una de las primeras premisas fue mantener de forma rígida el principio de neutralidad que ha caracterizado cada una de sus ediciones. En Rooted CON pudieron, pueden y podrán hablar y presentar sus ideas los miembros de la comunidad de seguridad, estudiantes, profesionales, empresas, aficionados, fuerzas del estado, hackers y, por qué no, artistas y académicos.

Otra de las premisas es evitar la censura. Mientras se ciñan a los límites de la legalidad, los contenidos no serán nunca censurados y se presentarán con la  profesionalidad y el rigor necesarios; sabemos que nuestros ponentes son profesionales serios, cuyos contenidos merecen ser tratados con todo el respeto.

Y, por supuesto, dos premisas que en realidad son una misma: promover el conocimiento técnico y asegurarnos de que, en todo momento, haya diversión y se disfrute en un ambiente de animación e intercambio.

Una vez estamos situados, vamos a intentar resumir lo más destacado del evento, sin entrar en el detalle de todas y cada una de las charlas. Por supuesto esto solamente son unas pinceladas, os recomendamos ver cada una de las charlas cuando la organización las publique en la web del congreso [www.rootedcon.es].

DIA 1

Comenzó la primera jornada de la tercera edición de la RootedCON con una ponencia de la mano de AlientVault. Se trata de una ponencia de un patrocinador, pero esto no fue óbice para asistir a un charla técnica y de calidad (al menos así nos pareció a nosotros).

Nos presentaron una de las iniciativas que han nacido hace poco del “Lab” de AlientVault. Se trata de un sistema de reputación abierto. Mediante una serie de comprobaciones, alimentan una base de datos de reputación de IPs que actualizan cada hora y que está disponible para quien quiera utilizarla. Entre sus objetivos futuros está ofrecer un servicio, con acceso en tiempo real, para realizar consultas sobre la base de datos sin necesidad de descargárselas.

De este primer día, además de esta primera charla, destacamos el trabajo realizado por Yago Jesús en relación a la situación que vivimos actualmente en cuanto a la gestión de los certificados digitales y en concreto a la oscuridad que rodea a las entidades certificadoras.

Nos presentó una aplicación realmente práctica que nos permite (en Windows) eliminar de nuestro almacén de CAs todas aquellas que no deberíamos necesitar nunca, por ejemplo una CA de Ucrania.

También por la tarde, “Epsylon“, nos mostró las funcionalidades de la herramienta XSSer e hizo hincapié en la necesidad de elevar el nivel de riesgo de los ataques XSS (Cross Site Scripting)… ¿cómo lo hizo? De forma muy sencilla y eficaz, mostrando primero un video con la herramienta mencionada realizando un escaneo masivo en internet y después mostrando algunos resultados positivos en páginas Web con cierto nombre, como por ejemplo portales gubernamentales.

Además de esto, pudimos ver Ingeniería social, Forense a bajo coste y la mala implementación del cliente de mensajería de Google (XMPP).

DIA 2

Llegamos al segundo día y comenzamos con una atropellada charla de Gerardo García Peña, pero muy interesante. El contenido de las trasparencias y la bibliografía (Seis trasparencias) puede servir de referencia para documentarse sobre la Denegación de servicio.

El día fue especialmente “fuerte”, pudimos ver como crear una red de maquinas comprometidas para navegar de forma anónima… o para lo que se quiera. Esta charla la realizó Jaime Peñalba en colaboración con personal de la Guardia Civil (Unidad telemática).

Pero antes de acabar el día Chema Alonso y Manu “the sur” nos mostraron una botnet basada en JavaScript (con ayuda de caché de tu navegador) con la que monitorizaron usuarios en busca de mafias y “chicos malos”. El tercer día Chema y Manu se convirtieron en el cazador cazado!

Además de esto, pudimos ver Hooking en Windows, Hardware Hacking y seguridad domótica.

DIA 3

Llegamos al tercer día y por supuesto las cosas no serían diferentes. La gente de Taddong comenzaron mostrando nuevos ataques basados en estación base falsa (sobre 2G). Las demos que realizan son siempre entretenidas, pocas veces se ve en acción una estación base falsa (sobre todo por el coste que tiene montar el entorno… con su jaula de Faraday incluida).

Después de ver técnicas para realizar ‘reversing’ sobre binarios que han sido “protegidos”, analizar la seguridad que los aviones no tripulados (presentes en el espacio aéreo de cualquier ciudad) o analizar ataques sobre plataformas Android, asistimos a las dos últimas charlas ya con cansancio acumulado… pero con ganas de descubrir las últimas sorpresas.

Antes de ver en acción a Raúl Siles, Manu Quintans y Frank Ruiz nos mostraron su trabajo realizado a la hora de monitorizar y tomar el control.

Para concluir, Raúl Siles liberó en directo una nueva versión de ZAP Proxy con soporte para realizar pruebas con el DNI electrónico. Es decir, poder realizar test de intrusión sobre aplicativos con este soporte. Y además de esto José Antonio Guasch se encargó de revisar el nivel de seguridad de los clientes pesados que interactúan con el DNIe y mostrar sus debilidades.

Por nuestra parte completamos el trabajo expuesto en la edición anterior tratando el tema de la fuga de información (data-leak) desde un Host infectado (perteneciente a una botnet, por ejemplo) utilizando el protocolo DNS. Al igual que en la distribución (mostrada en la edición de 2011), hemos mantenido nuestra filosofía de utilizar en la medida de los posible los servidores DNS del Host, utilizar registros utilizados en la navegación Web (Tipo A y CNAME normalmente) y siempre mantener un tamaño de paquete por debajo del límite permitido por los estándares.

Como parte del trabajo que se ha realizado, en paralelo, liberaremos un laboratorio sobre el que trabajar y poder realizar pruebas que faciliten la detección de esta amenaza en entorno empresariales y de cliente.

 

Hemos subido el PDF de la presentación que realizamos a SlideShare con algunas modificación en base al feedback recibido en las conferencias.

http://www.slideshare.net/ffranz/rootedcon2012-dns-a-botnet-dialect-carlos-diaz-francisco-j-gomez

Probando Internet para realizar compras

Autor: Javier Carbonell

Dados los ratios de crecimiento en la utilización de Internet para la realización de actividades productivas, parece que algo importante hubiera sucedido en el mundo de Internet durante el último año que ha empujado a los usuarios a lanzarse a utilizar este tipo de aplicaciones. Sin embargo, el año 2011 ha sido un año caracterizado por la crisis en cuanto a la situación económica y por el crecimiento de la Banda Ancha Móvil en lo relativo a las TIC, y no parece que estas características sean elementos suficientes que puedan explicar por si solas este crecimiento.

En principio merece la pena la pena destacar dos aspectos a considerar para matizar este crecimiento, por una parte en ciertos casos se partía de ratios de penetración pequeños por lo que incrementos absolutos no excesivamente grandes han supuesto crecimientos en porcentaje bastante elevados; por otra parte, a diferencia con otros informes que hay en el mercado, nosotros recogemos los usuarios esporádicos de los servicios. En otras palabras tenemos en cuenta aquellos usuarios que se han acercado a un determinado servicio porque alguien les ha animado, o simplemente porque han visto publicidad y quieren ver de qué va esto…,  total nada se pierde por probar.

Profundizando y ampliando los datos del SIE2011, observamos que conviven diferentes patrones de crecimiento en la utilización de Internet para realizar actividades.  Estos patrones dependen del grado de madurez de los servicios. Así, la figura 1 muestra dos patrones muy diferentes, uno de una actividad muy consolidada en el uso de Internet como es “Utilización de Internet para organizar un viaje” y otro de otra actividad también consolidada aunque no tan madura como es “Utilización de Internet para realizar compras”

Figura 1: Crecimiento en el uso de las actividades “organizar un viaje” y “realizar compras” según intensidad de uso.

Como se observa son dos patrones de crecimiento casi opuestos. En el caso de “Organizar un viaje”, la actividad está muy consolidada y el crecimiento se produce principalmente basada en los usuarios más asiduos, con grandes crecimientos entre los que utilizan siempre o generalmente Internet para realizar esta actividad, e incluso se produce un descenso en el número de usuarios esporádicos. Opuesto es el caso de los que utilizan Internet para realizar compras, donde aunque todos los segmentos crecen, la mayor parte del crecimiento se centra en el grupo de los usuarios esporádicos que se han animado a probar el servicio.

Sin duda alguna siempre hay una primera vez para todo, y antes de ser un usuario fiel, e incluso un seguidor radical de algo, siempre se pasa esa primera cita en la que el escepticismo es la nota dominante. Si uno se queda con buen sabor de boca, lo normal es que el acontecimiento se vuelva a repetir y vaya cobrando más fuerza, en el caso de no ser así la tendencia será a no volver. Desde este punto de vista, el año 2011 ha sido un año de “prueba” para muchos usuarios respecto al comercio electrónico, esperemos que se hayan llevado una grata impresión y el próximo año se consoliden como usuario asiduos, la respuesta en el SIE2012.