Conferencias FIST – Madrid Febrero 2009

Para aquellos de vosotros que no lo conozcáis, deciros que las conferencias FIST (First Improvised Security Testing) se vienen celebrando desde hace ya prácticamente 5 años. Estas conferencias están totalmente abiertas a la participación de cualquier persona interesada en la seguridad informática y el pentesting, tanto a la hora de asistir, como a la hora de participar como ponente. Si estás interesado en asistir a la próxima edición de las conferencias FIST de Madrid o Barcelona, lo mejor es que visites la web, te suscribas a la lista, y estés atento a la próxima convocatoria.

Una vez realizada esta pequeña introducción, para poneros en antecedentes, me gustaría comentaros mis impresiones respecto a la última edición celebrada en Madrid, el pasado jueves día 19 de febrero.

Las conferencias fueron brevemente presentadas por Gonzálo Alvarez Marañón, quién dió paso inmediatamente a Vicente Aceituno, quien en calidad de actual presidente de ISSA España, nos hizo una introducción a la asociación, sus objetivos, como entrar a formar parte de ella, etc.

La primera conferencia técnica llegó de la mano de Alejandro Martín, de Informática64, quien con su presentación titulada “La jungla de las redes Wi-Fi” realizó un repaso a las diferentes técnicas de segurización de redes inalámbricas (WEP, WPA, WPA2, filtrados MAC, autenticación 802.1x, etc.) y presentó una herramienta que han estado desarrollando, orientada al usuario final, para evaluar el nivel de seguridad de la red inalámbrica a la que el usuario está conectado. Me pareció una idea interesante, han desarrollado una métrica para cuantificar cómo de segura es uan red inalámbrica, en base al tipo de cifrado usado, lo robusta que es la clave de cifrado, el tipo de autenticación, si se realiza algún tipo de filtrado, etc. De esta forma, el usuario final, a la hora de conectarse a través de una red inalámbrica ajena, como por ejemplo desde un aeropuerto, un hotel o un hotspot público, sabrá qué grado de confianza debe tener en la red, y qué mecanismos adicionales de seguridad debe usar para acceder de forma segura a los recursos remotos. La herramienta se llama Mummy, aún no la han liberado y le falta por pulir algunos detalles. Espero que liberen el código y abran el desarrollo a la comunidad, de esta forma seguro que se convierte en una herramienta muy útil incluso para unos primeros pasos de una auditoría. La pena es que parece que está desarrollada únicamente para Windows. Si la liberan como código abierto quizás sería buena idea trasladar la idea a otros entornos, como Unix y OSX.

La segunda charla, que en mi opinión fue magnífica, corrió a cargo de Alberto Moreno. En su presentación Alberto se centró en la seguridad de Bluetooth, demostrando en la práctica como con software y hardware al alcance de cualquiera se puede capturar tráfico bluetooth, romper la clave de asociación de dos dispositivos, hacer un spoofing de uno de ellos y acceder a información sensible (agenda de contactos, calendario, fotos, aplicaciones, etc.) en el dispositivo remoto. La parte de sniffing me resultó especialmente interesante, ya que el dispositivo usado por Alberto no fue un USRP con GNU Radio, sino un adaptador Bluetooth USB Zaapa totalmente normal, de los que podemos encontrar en cualquier tienda, que ha sido reflasheado con el firmware de un sniffer Bluetooth comercial. La particularidad de este adaptador, y otros que hay en el mercado, es que hace uso de un chipset concreto, el BlueCore de Cambridge Silicon Radio, con una memoria flash externa que puede ser reescrita con el firmware del sniffer. Si das con uno de estos adaptadores, puedes hacerte tu propio sniffer Bluetooth por 20 euros. Si estáis interesados en este tema, no dejéis de visitar su blog, es una verdadera enciclopedia sobre seguridad Bluetooth.

Y para terminar la tarde, una presentación realmente amena (a pesar de lo duro de la temática) por parte de David Carrasco. La presentación de David era sobre Microsoft NAP (Network Access Protection), es decir, los mecanismos disponibles en una red Windows para autenticar y autorizar a un cliente de la red, y tomar medidas de aislamiento en caso de que no cumpla con las políticas impuestas por el administrador. Una charla muy interesante, tanto por el tema tratado como por la forma de tratarlo, ya que David nos fué guiando a lo largo de varias películas por todos conocidas para ir explicando los conceptos de NAP y cómo se implementan en una red Microsoft. Por cierto, buenísimos los 3 trailers con los que explicó los diferentes tipos de usuario en una red ;)

Cuando el video de la charla esté en youtube os recomiendo que lo veáis, al igual por supuesto que el resto de las charlas. Por el momento podéis disfrutar de las transparencias de las ediciones anteriores.

En conclusión, una magnífica tarde disfrutando de unas magníficas charlas dadas por unos ponentes de primera. Es de agradecer el esfuerzo e interés que los organizadores de FIST ponen en cada una de las convocatorias. Muchas gracias desde aquí por ello.

CACert Signing Party

En un par de días, el próximo miércoles 14 de enero, tendrá lugar en el Medialab-Prado de Madrid una signing party organizada por la comunidad CACert. El objetivo de este tipo de reuniones es certificar presencialmente la identiddad de los propietarios de claves para de esta forma ir aumentando la red de confianza.

Para los que no lo conozcan, CACert es una CA gratuita, gestionada por la comunidad en vez de por una entidad pública, como podria ser la FNMT o por una empresa privada, como podría ser Verisign.

Estas signing parties, como la que he comentado del próximo miércoles, tienen el objetivo de darle validez a tu clave, ya que la identidad del propietario es comprobada presencialmente, por los denominados “notarios” al tener que presentar un par de documentos de identidad (por ejemplo, DNI y pasaporte).

Una vez que tu identidad ha sido validada, te conviertes en un usuario “de confianza” de la red de confianza de CACert. De esta forma, con el tiempo, puedes actuar como “notario” validando la identidad de otros usuarios.

Desde luego, este mecanismo de validación de identidades tiene numerosas ventajas desde el punto de vista del usuario que va a hacer uso de la clave pública de alguien para enviarle información privada, ya que si confia en el anillo de confianza de CACert, podrá hacer uso de la clave confiando en que pertenece al legítimo propietario.

Por otro lado, un certificado SSL validado de esta forma siempre será mucho mejor que un certificado auto-firmado, donde no se ha pasado ningún mecanismo de validación. La única pega, en este aspecto, es que los certificados raíz de CACert no han sido incorporados aún a los navegadores de uso común, es decir, Firefox, Safari, Opera, etc. La inclusión del certificado raíz de CACert en Mozilla no parece tarea sencilla y el cumplir con los requisitos de Mozilla puede llevar varios años, aunque entiendo que terminará siendo incluido, con lo que desde ese momento un certificado de este tipo será perfectamente válido y mucho mejor que un certificado auto-firmado.

Seguridad en aplicaciones web

Hace un par de semanas publiqué una entrada comentando mis impresiones sobre las II Jornadas STIC CCN-CERT.

De todas las presentaciones que hubo, merece atención especial la que ofreció Gonzalo Alvarez sobre seguridad en aplicaciones web.

Para todos aquellos que no asistieron a estas jornadas, ni han tenido la oportunidad de ver alguna presentación similar de Gonzalo en los los FIST o en alguna otra jornada/reunión de temática similar, les dejo los enlaces al video de la presentación:

Kill’em all TCP DoS

Last week a new hot topic arose in many security related blogs, podcasts and forums. A “new” and “devastating” DoS attack against TCP was revealed in a interview to two security researchers, Jack C. Louis and Robert E. Lee, both of them from Outpost24, who talked about their research in this podcast.

OK, a new “massive-destruction-bug”, one more to the list… do you remember when I wrote about the OpenSSL, BGP and DNS bugs? (in spanish).

The technical details that they have released are few and ambiguous, there were some confusion in many forums where people thought that it was a problem related with the Syn Cookies implementation, but it isn’t. They talked about Syn Cookies not in the server side but in the client side, as a way to establish a lot of connections without exhausting local resources.

Where’s the problem then? seemingly they were performing a massive scan and pentesting work with their UnicornScan tool when they found out that several hosts stuck, hanged even rebooted after the TCP connection was established in several “creative ways”.

Mainly it seems that one of those “creative ways” is the use a TCP window of 0, this means from the server point of view,  that the client hasn’t enough resources (buffers) to receive data so the server waits until the retry timeout finish, send an ACK TCP segment to the client and waits for the answer to check if the window has been increased, in other words, if the client has now buffers to receive data.

It seems that if you establish several connections to a server that have an open TCP port, set a window of 0 in the initial negotiation during the three-way-handshake, and always answer to the ACK of the server with a window of 0, the server may end up using all the available resources, or maybe is just a matter of filling up the established connection table with never ending connections due to the 0 size TCP window.

From the client side, this work can be done with a minimum resource consumption as the connections are established through a TCP/IP stack in userland, and not the kernel one, here is when sockstress tool do the trick, besides that very few packets/bandwidth are needed to force the server to go to this state.

Maybe the problem is related to huge timeouts when a connection is in TIME_WAIT state, or with SACK before FIN state… Well I don’t know, there’re a lot of strange combinations that can end in a closed socket but with the related resources not correctly freed.

Neither a detailed technical explanation nor the sockstress tool has been released yet, so this is only a personal interpretation of what I have readed and listened. I guess that we’ll have to wait one more week to T2 Conference to learn more about all this mother-of-all-DoS thing. Some people is a bit skeptical about all this thing, just have to read Fyodor’s great post about all this topic.

Even though researchers assert that all network stacks (Windows, Linux, Solaris) are vulnerable to this bad client behaviour, no attack has been publicly reported to date. Hype? marketing to attract people to the conference? We’ll see in a week.

“The Grid” la red de datos del LHC

Hoy, a las 07:30 GMT, se ha puesto en marcha el LHC (Large Hadron Collider). Inicialmente, las pruebas de hoy van orientadas a comprobar que no hay ningún problema en los 27 Km que conforman el acelerador de partículas. El objetivo de hoy es conseguir que las partículas den una vuelta completa de forma estable, comprobando cada uno de los elementos que intervienen durante todo el recorrido.

Cuando toda la instalación se haya validado, lo cual podría ser dentro de unas semanas, comenzarán las primeras colisiones y la obtención de datos gracias a los cuatro grandes detectores que se encuentran a lo largo del recorrido:

Hay otros dos experimentos, TOTEM que comparte detector con el experimento CMS, y LHCf que comparte el detector ATLAS.

Pero, no voy a dedicar este post al LHC desde el punto de vista de los avances que habrá en el campo de la física gracias a estos experimentos que en él se realicen, ni a niguno de los polémicos aspectos de su puesta en marcha (fin del mundo, amenazas de muerte a científicos…).

Voy a dedicar este post a The Grid, la red de datos que se ha creado, en paralelo al LHC, para poder distribuir, almacenar y procesar la ingente cantidad de datos que se generan diariamente en el CERN en base a los experimentos realizados en el LHC.

La motivación principal en el diseño y despliegue de The Grid era disponer de una red de datos que uniera a los centros de investigación y académicos con el CERN, de tal forma que pudieran acceder y utilizar los datos generados a partir de los experimentos que se realicen. La cantidad de datos es ingente, se calcula que los experimentos asociados al LHC generarán alrededor de 15 petabytes de datos anualmente, y que los datos deberán estar accesibles durante los próximos 15 años, que es el periodo de vida previsto para el LHC.

La Internet actual no ofrecía ni la conectividad ni la capacidad necesaria para poder distribuir los datos a través de las conexiones existentes, así que se decidió la creación de una red paralela, diseñada en varias capas, e interconectada a partir de enlaces de fibra dedicados. Así nació, hace cinco años, el Worldwide LHC Computing Grid.

La red está estructurada, de forma jerárquica, en varias capas o niveles:

La capacidad de cálculo necesaria para analizar los datos que se generen por los experimentos del LHC se estimó en el año 2.006 en aproximadamente unas 100.000 CPUs atendiendo a la potencia de cálculo de hace un par de años.

El centralizar esta potencia de cálculo en data center del CERN se vió totalmente inviable, por lo que se optó por una arquitectura de cálculo distribuida. La gestión de los servicios de cálculo se realiza en base a la colaboración de varios organismos que cuentan con infraestructuras de computación grid. En concreto se trata de EGEE, OSG y Globus Alliance.

EGEE (Enabling Grids for E-sciencE) es un proyecto fundado por la Comisión Europea para proveer a los científicos de una infraestructura de cálculo disponible permanentemente, en base a infraestructuras grid de menor tamaño que se unan al proyecto, y que pueden tener caracter local o regional. Actualmente forman parte de este grid 250 organismos repartidos por 50 paises, proporcionando 68.000 núcleos de CPU y 20 petabytes de almacenamiento al proyecto.

OSG (Open Science Grid) consorcio de universidades y centros de investigación localizados en América del Norte, América del Sur y Asia. El proyecto está financiado por el NSF (National Science Foundation) y por la oficina de Ciencia del DoE (Department of Energy) de Estados Unidos.

Globus Alliance aúna los esfuerzos de varias universidades y laboratorios de investigación para el desarrollo de tecnologías grid open-source.

La integración dentro del GRID se haría a través del middleware oficial, que por el momento es el middleware gLite, evolución del middleware desarrollado para el proyecto EGEE y que ha incorporado funciones de otros proyectos como el LCG y el VDT.

Por otro lado, a través del CERN OpenLab, las empresas pueden probar nuevas tecnologías aplicables a la computación grid en el marco del LCG. Es una relación por la cual las empresas obtienen un campo de pruebas dentro de los proyectos del CERN, y a su vez el CERN obtiene tecnología de última generación.

Intrusiones en repositorios de software

¿Cuál es la forma más sencilla de meter una “puerta trasera” en miles de servidores?. Pues como le diría Obi Wan al joven padawan: “use the source Luke“. Es decir, si el punto de origen de distribución del software es vulnerado, los paquetes modificados serán distribuidos e instalados en miles de servidores.

Terminábamos la semana pasada con la noticia de que precisamente ésto es lo que había ocurrido en Red Hat, tal y como se anunciaba oficialmente el pasado viernes.

Por el momento no se han desvelado los detalles de cómo se realizó la intrusión en sus sistemas, pero el resultado sí es conocido, el intruso generó nuevos paquetes firmados de OpenSSH dentro del repositorio oficial de RHEL:

Haciendo esto quería asegurarse el acceso a todos aquellos servidores que instalasen estos paquetes relativos a SSH, ya sea mediante modificaciones al cliente que podrían tener como objetivo el desvelar las claves privadas generadas o el ejecutar de forma encubierta comandos en los servidores accedidos, o bien mediante modificaciones al servidor, orientadas a dejar directamente una puerta trasera que permitiera el acceso.

En cualquier caso, lo que le permitió realizar dichas modificaciones a los paquetes oficiales de la distribución, es la obtención de la clave con la que firmar sus paquetes para que éstos puedan ser validados sin problemas por aquellos sistemas que los fuesen a instalar.

Es decir, se vulneró el sistema de cifrado basado en clave pública, lo que implica que el atacante consiguió acceso a la clave privada (de alguna forma se tuvo que desvelar la passphrase con la que debiera estar protegida) con la que se firman los paquetes que posteriormente son validados por la clave pública de la distro.

Según afirma Red Hat, los paquetes falsos no se han distribuido a través de RHN (Red Hat Network) y es recomendable detectar su presencia mediante este script que comprueba la firma MD5 de los paquetes instalados susceptibles de haber sido falsificados.

Y por si esto no fuera suficiente, se anuncia, prácticamente al mismo tiempo, que varios de los servidores de Fedora también han sido vulnerados. De nuevo, el objetivo del ataque es el servidor usado para generar la firma de los paquetes, aunque en esta ocasión parece ser que el atacante no consiguió saltarse la passphrase para obtener el codiciado acceso a la clave privada con la que firmar los paquetes de la distro. Las claves han sido regeneradas, como es normal.

Si hacemos un poco de historia, podremos ver que atacar los servidores de proyectos, lejos de ser algo excepcional se está convirtiendo en algo habitual. Recordemos: ataque a un servidor de Debian en julio de 2006, ataque al servidor de wordpress en marzo de 2007, ataque a varios servidores de Ubuntu en agosto de 2.007.

Algunas reflexiones personales sobre el asunto:

El culebrón del DNS

Recién finalizadas tanto la BlackHat como la Defon de este año, me gustaría comentar brevemente el “culebrón” del DNS, que realmente ha dado muchisimo juego durante estos últimos meses, y que tiene como colofón la charla de Dan Kaminsky en ambas convenciones sobre este tema.

Kaminsky descubrió un problema de envenenamiento de caché DNS a principios de este año. Dada la gravedad del asunto, ya que podría afectar potencialmente a la mayoria de DNS presentes en Internet, en marzo se reune con los principales fabricantes e ISPs para exponerles la vulnerabilidad y que tomen las medidas necesarias para solventarlo. Comienza un proceso de parcheo de servidores DNS. A principios de julio Kaminsky hace pública la vulnerabilidad y se generan los avisos de seguridad correspondientes.

Kaminsky pide a la comunidad de expertos en seguridad que no adelanten detalles, al menos hasta que él haga público oficialmente el fallo durante el mes de agosto, en el BlackHat y la Defcon. Esta ventana de 1 mes entre la publicación oficial del fallo y la explicación técnica detallada que Dan promete para el BlackHat tiene el objetivo de dar algo de tiempo para que se realice el parcheo de todos los servidores vulnerables presentes en Internet antes de que se publiquen exploits.

Parte de la comunidad critica durametne a Kaminsky y le acusan de orquestar todo este tema para publicitarse… no hay que olvidar que Dan Kaminsky tiene una gran parte de showman y algo así le viene fenomenal para publicitarse y aparecer en la BlackHat y la Defcon como el principal ponente. Prueba de ello es que en su aparición en la Defcon consiguió reunir a más de 1.000 personas en su charla y no me extrañaría que en diciembre, este tema del DNS aún le siga dando juego para su participación en el CCC de este año.

Al poco de hacerse pública la vulnerabilidad, empezaron a aparecer explicaciones técnicas en muchos blogs, siendo algunas hipótesis realmente acertadas y detalladas, lo que permitía la generación de exploits sin ningún problema a poco que se entendiese de qué iba el asunto y se tuviesen ciertas habilidades de programación.

En un par de semanas ya había un par de módulos (DNS BailiWicked Host Attack y DNS BailiWicked Domain Attack) del framework Metasploit que comprobaban y explotaban el fallo. No se había agotado el tiempo de 1 mes marcado por Kaminsky antes de su aparición en la BlackHat. Surge la polémica y se reabre el eterno debate del full disclosure. Hay que tener en cuenta una cosa… que un fallo de seguridad no se haga público o que sus detalles técnicos no salgan a la luz, no significa que no haya exploits “in the wild“.

Llega agosto, se celebra la BlackHat y la Defcon. Kaminsky hace su multitudinaria aparición y hace la tan esperada presentación.

Y ahora, lo divertido… ;)

Supongamos que queremos envenenar la caché de ns.victima.es para meterle un RR que asocie la dirección IP 1.2.3.4 al nombre www.banco.es

Generamos múltiples consultas por nombres dentro del dominio banco.es del tipo 001.banco.es, 002.banco.es, 003.banco.es … 999.banco.es y se las enviamos a ns.victima.es

ns.victima.es comenzará el proceso de resolución necesario para obtener la respuesta a esas consultas, que para todas y cada una de ellas será un NXDOMAIN desde ns.banco.es, que es el servidor DNS autorizado para el dominio banco.es, ya que el nombre consultado es desconocido para él.

A nosotros nos interesa hacernos pasar por ns.banco.es y que nuestra respuesta llegue antes del NXDOMAIN para que sea introducida en la caché del servidor ns.victima.es

Para que nuestra respuesta sea aceptada, el TXID debe ser el mismo que el que generó ns.victima.es para la consulta. Nosotros no sabemos cuál es, pero podemos enviarle un número considerable de respuestas, cada una de ellas con un TXID y sentarnos a ver qué pasa ya que la probabilidad juega a nuestro favor.

Si alguna de nuestras múltiples respuestas a una de las múltiples consultas, que hemos forzado a ns.victima.es a realizar, tiene el TXID correcto, el RR de respuesta será aceptado y cacheado durante el tiempo que se indique en el TTL. Lo que se va a enviar en estas respuestas son registros NS, es decir, referencias a los DNS que pueden resolver el nombre por el que se pregunta. En resumen, lo que aparentemente ns.banco.es le está diciendo a ns.victima.es es lo siguiente: “me has preguntado por 137.banco.es y yo no sé cuál es su dirección IP, pero quién lo sabe y a quién tienes que preguntar es www.banco.es cuya dirección IP es 1.2.3.4″.

Cuando ns.victima.es recibe esta respuesta de quien aparentemente es ns.banco.es y que es a quien ha preguntado, y la acepta porque el TXID es correcto, automáticamente cachea la asociación www.banco.es/1.2.3.4

Los administradores de ns.victima.es hacen bien su trabajo, y no permiten consultas recursivas a sus DNS desde Internet. ¿Son vulnerables?. La respuesta es sí. Desde luego, si desde Internet podemos forzar a un DNS a generar una consulta porque permita recursividad, nos están poniendo las cosas muy fáciles. Pero eso no implica que no se pueda “forzar” a un DNS a generar ciertas consultas, ya que cualquier usuario que navegue por una web en donde haya un recurso que requiera esa resolución, generará una consulta a su DNS, la recepción de una conexión SMTP en donde se indique ese dominio en el HELO o en el MAIL FROM provocará una consulta… hay muchas formas de generar ese tipo de consultas de forma indirecta.

La solución a este tipo de escenario es complicada desde el punto de vista de que se está explotando una característica propia del diseño del protocolo DNS. El cómo explotarlo se ve simplificado por el hecho de que el único impedimento entre la aceptación de una respuesta falsificada o una real es un TXID que tiene “unicamente” 65.536 posibles valores. El puerto origen suele ser fijo (53) o secuencial, por lo que es trivial de predecir y no añade complejidad de cara al atacante.

Una mejora es usar puertos origen aleatorios en las consultas. De esta forma no hay que “predecir” únicamente el TXID sino también el puerto origen.

Por otro lado el servidor de DNS puede ser capaz de detectar ataques de este tipo, detectando la llegada de numerosas respuestas con puerto origen y TXID incorrectos para una consulta generada. No es algo que pase desapercibido.

Interesante también el saber que hay en desarrollo un RFC para reforzar la seguridad de DNS en este sentido, actualmente es un draft y su lectura es muy interesante, nos llega de la mano de Bert Hubert el autor de PowerDNS.

Proyecto Ibercivis

En mi anterior post comenté brevemente mi motivación a la hora de publicar en el blog información relativa a computación distribuida voluntaria y realicé una pequeña introducción al tema. En este post paso a comentar el proyecto Ibercivis, como ejemplo práctico de aplicación de todos esos conceptos a una plataforma de computación usada por los investigadores españoles en áreas como el estudio de nuevos materiales, la búsqueda de fármacos más eficaces o el estudio de nuevas fuentes de energía limpias e inagotables.

En el siguiente post que escriba sobre este interesante tema me centraré en BOINC, el middleware que se ha convertido en el estándar de facto para Desktop Grid Computing, e intentaré sintetizar cómo crear tu propia plataforma de computación basada en BOINC, ya que al fin y al cabo es lo que quiero proponer como proyecto de innovación dentro de mi centro de trabajo, para que lo evalúen como alternativa computacional para los problemas que se consideren como de paralelismo débilmente acoplado.

Pero por el momento, conozcamos el proyecto Zivis e Ibercivis…

Ibercivis es un proyecto de computación distribuida voluntaria (también referenciado a veces como computación ciudadana), de caracter científico, basado en el middleware BOINC que se encuentra activo desde el pasado mes de abril. Pero empecemos por el principio, Ibercivis nace como evolución del proyecto Zivis, así que conozcamos en primer lugar qué es Zivis.

Zivis se presentó en sociedad un año antes que Ibercivis, en abril de 2.007. El coordinador del proyecto, Alfonso Tarancón, contó con el apoyo del Ayuntamiento de Zaragoza, del BIFI (Instituto de Biocomputación y Física de Sistemas Complejos) y del LNF (Laboratorio Nacional de Fusión) e inicialmente nació con un carácter muy local, cuyo ámbito iba a ser principalmente la provincia de Zaragoza en particular y el resto del territorio español en general, aunque lógicamente ponerle fronteras a un proyecto de computación distribuida en Internet no tiene mucho sentido, y en la práctica hubo participantes de otros paises de Europa y del continente americano. Zivis estuvo activo, exclusivamente, durante un mes y medio, cediendo capacidad de cálculo para el desarrollo del reactor de fusión ITER. Durante este tiempo tuvo el rendimiento equivalente de un supercomputador de 800 CPUs, generando 800.000 horas de cálculo y ahorrando de este modo casi 1 año de trabajo a los investigadores con los recursos disponibles del CIEMAT. Si los investigadores del CIEMAT hubieran tenido acceso a Mare Nostrum, hubieran hecho en 3 días lo que con Zivis hicieron en mes y medio, pero el superordenador español está tan demandado y su utilización tan restringida que es mucho más factible hacer uso de un superordenador virtual como lo fue Zivis y actualmente lo es IberCivis.

Inicialmente Zivis se marcó los siguientes objetivos:

Los resultados obtenidos, en únicamente 1 mes y medio, fueron más allá de lo esperado:

A modo de resumen, un buen reportaje que se emitió en su día sobre Civis es el del programa de divulgación “A Ciencia Cierta” de TVE, en donde entrevistan a Alfonso Tarancón, director del proyecto.

Un año después del fantástico éxito de Zivis, nace IberCivis. Un proyecto de ámbito nacional (aunque la participación está abierta a cualquier voluntario de todo el mundo), que cuenta como director, una vez más, a Alfonso Tarancón y en donde se incorporan dos nuevos proyectos en los que participar además del de fusión que sirvió como experiencia piloto en Zivis.

A fecha de hoy, la plataforma de computación Ibercivis permite la participación en tres proyectos:

En el siguiente video se explica perfectamente la filosofía de trabajo que hay detrás de Ibercivis y los proyectos en los que se puede participar hoy día.

Los resultados de Ibercivis parecen buenos de acuerdo a las estadísticas que se pueden consultar en boincstats. A fecha de hoy estos son algunos de los datos más relevantes:

Para seguir al día la evolución de Ibercivis, lo mejor es visitar su blog o el blog de investigadores y por su puesto unirse al proyecto. Si os animáis podemos crear un equipo y ceder algunos ciclos de CPU ;)

Computación Voluntaria Distribuida

Hoy, hablando con un compañero del trabajo, me he enterado de una cosa que nunca me habría imaginado que se hiciera en donde me gano la vida actualmente. Parece ser que una vez al año se conceden premios a aquellos proyectos que por su innovación o eficacia supongan un avance para el Departamento de Informática en el que actualmente trabajo. Hay que decir que la organización en la que me encuentro no es precisamente una empresa tecnológica, por lo que su negocio no es la tecnología. Para ellos la tecnología no es más que una herramienta, un medio, de conseguir su objetivo, que no es de caracter tecnológico sino de caracter económico/fiscal.

Al enterarme de que había la posibilidad de presentar una propuesta de innovación tecnológica me ha dado el subidón, ya que me ha parecido la oportunidad de hacer algo interesante durante este mes de agosto de cara a poder presentarlo a partir de septiembre una vez se abra el plazo de presentación de propuestas y me vaya enterando de cuáles son las condiciones en las que se deben presentar estas propuestas.

Ahora bien, la organización para la que trabajo podriamos decir que es “demasiado conservadora” en el sentido de que su prioridad es el negocio, y como suele ser bastante habitual en organizaciones con esta filosofía de “si funciona no lo toques”, cuanto mas clásica y estable sea la infraestructura tecnológica que sustenta el negocio mejor, experimentos pocos y además observados con lupa, reticencia y en muchos casos, hasta rechazo :(

Esto hace que sea bastante escéptico en cómo puedan evaluarse realmente las propuestas que se hagan, en cualquier caso… me parece un ejercicio interesante el desarrollar la propuesta, así que aunque no sirva de nada dentro de mi organización… hacerlo lo voy a hacer ;)

Aprovechando este mini-proyecto que me he marcado he pensado que podría ser interesante ir publicando en el blog piezas de información que vaya desarrollando para el documento que voy a presentar como propuesta, además de que precisamente va a ser sobre un tema que queríamos tratar con cierta profundidad en el podcast… por tanto, de una forma u otra… I’ll have fun with it! que a fin de cuentas es lo que importa, ¿no? ;)

¿Y qué es lo que voy a proponer?… la organización en la que trabajo es bastante grande, estamos hablando de 30.000 puestos de trabajo con PC relativamente potentes que durante la jornada de trabajo estándar de 8 horas están totalmente infrautilizados, y luego se encuentran 16 horas completamente ociosos. Es un escenario ideal para proponer una solución de computación grid basada en BOINC, creando un superordenador virtual que complemente la capacidad de cálculo que actualmente se concentra en servidores pSeries de IBM para un conjunto de aplicaciones muy concretas que hay en mi organización basadas en redes neuronales y cálculos masivos con datos extraidos de un datawarehouse.

De todas formas, sobre el escenario concreto en el que se encuentra mi organización hablaré en algún post futuro, por el momento introduzcamos el escenario tecnológico en el que se desarrollará mi propuesta. Ni que decir tiene que cualquier comentario es bien recibido :)

Computación voluntaria distribuida… ¿y eso qué es?

Puede definirse como una plataforma de computación distribuida donde los recursos hardware de cálculo y/o almacenamiento son provistos, de forma voluntaria por el público general, quienes destinan parte de los recursos disponibles en sus ordenadores personales conectados a Internet a proyectos de investigación concretos, normalmente de carácter científico o académico.

Un detalle importante vinculado al concepto de voluntariedad es que los participantes permanecen anónimos, y se establece una relación de mutua confianza entre el usuario que destina parte de sus recursos personales al objetivo del proyecto que ha sido declarado oficialmente y el coordinador del proyecto que confía en que los resultados obtenidos del usuario no han sido manipulados maliciosamente.

El proyecto GIMPS (Great Internet Mersenne Prime Search) es considerado como uno de los primeros proyectos de computación voluntaría, y se remonta al año 1.995. Posteriormente se hicieron relativamente famosos otros proyectos como los de cracking de algoritmos criptográficos de distributed.net en 1.997 o el proyecto SETI@Home en 1.999, el cual dió pie al desarrollo de BOINC (Berkeley Open Infraestructure for Network Computing). Actualmente hay toda una variedad de proyectos de computación distribuida en donde participar.

El escenario actual en donde cada vez hay más dispositivos conectados a Internet, donde las conexiones permanentes de banda ancha son el modelo de conectividad residencial predominante, donde los equipos informáticos y de ocio tienen capacidades de proceso cada vez mayores y que exceden en mucho lo necesitado realmente por el usuario. Con todo esto, el modelo voluntario de computación distribuida tiene gran sentido hoy día, ya que se dan los factores necesarios para su éxito.

Vamos a analizar con algo más de detalle algunos de estos factores.

Creciente número de individuos conectados a Internet. Según los últimos datos publicados por el Instituto Nacional de Estadística relativos al pasado año 2.007, casi el 45% de los hogares españoles se encuentra conectado a Internet, de los cuales el 39% lo hace a través de un enlace de banda ancha. Si hablamos de cifras concretas, estaríamos barajando unas cifras de alrededor de 6.5 millones de viviendas conectadas a Internet, siendo hoy día unos 15 millones de personas las que se pueden considerar usuarios frecuentes de Internet.

Capacidad de cálculo y conectividad. Tomando la cifra de 6.5 millones de viviendas conectadas a Internet como referencia y, suponiendo según los datos estadísticos del INE, que aproximadamente unos 6 millones lo hacen usando banda ancha (ADSL, cable, etc.), nos encontramos con 6 millones de potenciales colaboradores en proyectos de computación voluntaria, ya que son usuarios con, al menos, un ordenador personal, conectado a Internet por banda ancha, y con la posibilidad de estar on-line y activo 24 horas. Lógicamente, lo que no se puede esperar es que estos 6 millones de hogares conectados cuenten con lo último en tecnología y que la dedicación de sus equipos a computación voluntaria sea del 100%. Supongamos un escenario realista-pesimista :) en el cual los equipos caseros con los que podemos contar tienen alrededor de 5 años de antiguedad, lo que nos daría un parque de equipos similares al Pentium 4 de 3.2 GHz con rendimientos alrededor de los 9.000 MIPS y los 6.000 MFLOPS. Si fuésemos optimistas nos imaginaríamos un escenario donde los participantes tienen Quad-Core de Intel a 3 Ghz dando cada uno aproximadamente 50 GFLOPS… o si ya dejamos volar la imaginación podemos pensar en PC equipados con tarjetas gráficas que ofrecen GPUs capaces de proporcionar 100 GFLOPS ;)

Supongamos que los usuarios de estos ordenadores personales, dejan sus equipos encendidos las 24 horas, y se puede contar con una franja horaria de alrededor de 8 horas (quizás en horario nocturno) en la cual el usuario no hace uso interactivo de su PC, y lo dedica a labores de computación voluntaria. Nuestro hipotético escenario daría como resultado un super-ordenador virtual de 36 PetaFLOPS disponible durante 8 horas al día.

Teniendo en cuenta que la supercomputadora más potente del mundo (según el TOP500 y su lista del pasado mes de junio) actualmente es el Roadrunner de IBM ofreciendo un rendimiento de 1 PetaFLOP, una plataforma de computación voluntaria de este tipo, aún siendo dependiente de la participación voluntaria e impredecible de usuarios particulares, es una opción realmente interesante para aquellos proyectos científicos que necesiten del procesamiento masivo de grandes cantidades de información.

Esta es precisamente la filosofía que hay por detrás del proyecto IberCivis, que se presentó en sociedad hace unos meses y de la cual hablaré más en detalle en un futuro post. Hay que tener en cuenta que desde el punto de vista presupuestario, el cubrir las necesidades de cálculo en base a una plataforma de computación voluntaria “gratis”, evita cargar el coste de esta infraestructura a los presupuestos de los proyectos, los cuales ya de por sí arrancan con presupuestos limitados y en muchos casos insuficientes, en clara contraposición con el modelo clásico en el que hay que cargar al presupuesto del proyecto lo que cuesta el tiempo de cálculo en superordenadores privados o institucionales.

Por otro lado, el promover este tipo de plataformas realiza una tarea de divulgación científica importante de cara al público general, que puede participar activamente en los proyectos científicos y ser parte de los avances conseguidos por ellos.

Computación Voluntaria vs Computación Grid

El rasgo diferenciador más claro es el anonimato o no de los participantes. En un modelo de computación voluntaría, los participantes son completamente anónimos y no son auditables. En un modelo de “Desktop Grid Computing” dentro de una organización (o dominio), los equipos/usuarios participantes no son anónimos, están inventariados, son gestionables y son auditables. Los recursos que se dedican para crear la infraestructura de computación son recursos corporativos y la topología es conocida, por lo que puede adoptarse un modelo “push” (comunicación hacia el cliente) en contraposición con el modelo “pull” (comunicación desde el cliente) necesario en un modelo de computación voluntaria en el que el cliente pueden estar detrás de firewalls y otros elementos de red que impidan una comunicación directa hacia el cliente. Dentro de un modelo de computación grid también se pueden establecer relaciones entre diferentes organizaciones, para solicitar y hacer uso de los recursos de computación de los que disponga cada organización.

Superordenador vs Grid

Según datos de la lista elaborada en junio de la Top500 Supercomputing Sites el actual número 1 con un total de 1,026 petaflops es el ordenador Roadrunner, desarrollado por IBM para el Laboratorio Nacional de Los Alamos del Departamento de Energia de los EEUU. El Roadrunner está formado por servidores Blade IBM QS22 interconectados por Infiniband, mezcla 12.960 procesadores IBM PowerXCell 8i con 6.480 AMD Opteron dual-core, corre Fedora Linux y hace uso del middleware de computación distribuida xCat.

En contraposición a este “número uno” tenemos otro “número uno”, el superordenador virtual que da pie al proyecto Folding@Home, uno de los proyectos actualmente activos que cuenta con mayor número de participantes. El proyecto FaH superó el petaflop en septiembre de 2.007 gracias a la liberación del cliente para Sony PS3, esto supuso un incremento considerable en la capacidad de cálculo, al incorporar los poderosos procesadores Cell de las PS3 de los nuevos voluntarios que se unieron al proyecto. Hasta ese momento el proyecto contaba con alrededor de 250.000 CPUs activas, la incorporación de usuarios con PS3 supuso un importante incremento de usuarios y un salto inmediato a rendimientos superiores a petaflops. Actualmente, otro nuevo salto de rendimiento se ha producido con la liberación del cliente para GPUs de tarjetas gráficas. Esto ha supuesto la incorporación de 4.000 GPUs aportando alrededor de 450 teraflops de proceso, lo que supone para el proyecto, un rendimiento global de 2.52 Petaflops, según los últimos datos de junio.

← Previous Page