Archivo del Autor: Jorge Suárez de Lis

Acerca de Jorge Suárez de Lis

Linux, software libre. Hago desarrollo web, también. Me gusta el melón fuera de temporada. Hago radio imitando a Mark Shuttleworth.

Hemos sufrido un ataque de fuerza bruta en WordPress

wordpress-265132_1280Ayer algunos habéis notado que los dominios proxectos.citius.usc.es, demos.citius.usc.es y persoal.citius.usc.es no funcionaban, y eso fue debido a que recibimos el aviso de que el servidor estaba infectado con un botnet.

Ya hemos sufrido algo parecido en el pasado en ese mismo servidor. En esta ocasión, no ha sido por una vulnerabilidad sino por un ataque de fuerza bruta en uno de los WordPress instalados en el servidor para un proyecto.

Tras comprobar los logs y restaurar una copia de seguridad previa al desastre, hemos comprobado que las medidas que tomamos en febrero mitigaron los efectos (el bot no era capaz de lanzarse a sí mismo y requería una petición HTTP para lanzarse cada poco tiempo), pero aún así no se pudo prevenir la infección ni su funcionamiento por completo.

Qué ha pasado

El 4 de noviembre, a las 6 de la madrugada, recibimos durante 4 horas un total de 2411 peticiones de intento de identificación en uno de los blogs, hasta que finalmente el robot pudo entrar, cambiar las contraseñas de dicho WordPress y modificar un tema usando el editor incorporado, cambiando archivos legítimos por otros que permitían a su vez infectar la máquina con más malware.

Actualización: Es cierto que con tan solo 2411 peticiones es difícil hacer un ataque de fuerza bruta, a no ser que la contraseña sea muy débil. Por desgracia, no guardamos información del tamaño de los bytes enviados ni recibidos para poder detectar si se trata de un ataque tipo BREACH o similar, aunque también es posible.

Qué podemos hacer para evitarlo

Hay varias recomendaciones que los usuarios de WordPress pueden seguir para evitar estos ataques de fuerza bruta. Hemos recomendado a todos ellos que las apliquen.

No obstante, también hemos implementado medidas adicionales de seguridad:

Hemos habilitado, en ese servidor, una revisión constante de ClamAV, un antivirus que es capaz de detectar este tipo de exploits, para que nos informe en cuanto detecte algún archivo sospechoso. En esta ocasión, ClamAV ha sido capaz de detectar los archivos, y de haber estado funcionando este sistema, lo habríamos detectado mucho antes.

También hemos instalado fail2ban, una solución que gestiona una lista negra del sistema (el archivo deny.hosts) en base a determinadas reglas que se pueden definir arbitrariamente. Por ejemplo, se puede hacer que compruebe intentos de conexión a logins de WordPress reiterados. Una vez en la lista negra en la que se mantendrá durante un tiempo prudencial, el servidor web rechazará cualquier conexión desde esa IP. Hasta ahora utilizábamos otras soluciones que no permitían definir este tipo de reglas y tan solo eran capaces de bloquear intentos de login fallidos en servicios conocidos.

Actualización: No lo comentamos originalmente, pero también aplicamos algunas medidas de seguridad adicionales. Desde luego, es cierto que parece una posibilidad que esto no se trate de un simple ataque de fuerza bruta, sino de un ataque tipo BREACH (u otros derivados de técnicas de compresión y SSL), por lo que hemos tomado también las medidas recomendadas para mitigar dichos ataques. En cualquier caso, bloqueando peticiones reiteradas a páginas de login, este tipo de ataques tampoco serían posibles.

Con estas mejoras, esperamos poder mitigar este tipo de ataques y poder responder más rápido ante posibles problemas de este tipo en un futuro.

Todo era alegría en Bash hasta que Shellshock

El jueves de la semana pasada salió a la luz un fallo de seguridad que afecta a Bash, el intérprete de comandos detrás de muchos sistemas con Linux y Mac OS X.

El bug se produce porque, a la hora de definir variables de entorno, utilizando una sintaxis determinada se consigue ejecutar código que a su vez se almacena dentro de la variable, algo que lógicamente no debería estar permitido. Veamos un ejemplo:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Con este comando se ejecuta una nueva shell de Bash, pasándole una definición de una variable que contiene un método que no hace nada y un comando justo después de la definición, que se ejecuta justo cuando la variable se define.

Algunas televisiones partidarias de shells alternativas piensan que Bash es un bug en sí mismo

Algunas televisiones partidarias de shells alternativas piensan que Bash es un bug en sí mismo. Fuente: @crazybob

Este bug permite realizar varios ataques ya probados: escalada de privilegios de un usuario normal, ejecución de comandos en shells de SSH restringidas… ¿Un user agent de un navegador llamado () { :;}; rm -rf /? ¿Por qué no?. Las consecuencias podrían ser desastrosas.

Como pasó en la época del Heartbleed y OpenSSL, mucha gente ha centrado ahora su mirada en Bash y se han encontrado nuevos fallos de seguridad relacionados y no relacionados. En los servidores (y equipos de escritorio que administramos) del centro, Bash se actualiza regularmente con las actualizaciones de seguridad de las distribuciones, que ya han publicado varias versiones nuevas que van corrigiendo todos estos fallos.

En la Wikipedia van sintetizando toda la nueva información que va surgiendo, con enlaces a las fuentes interesantes, así que recomendamos echar un vistazo a su artículo si queréis más información sobre este tema. La página ShellShocker.net también resume toda la información y ofrece recursos para probar los sistemas y parchear Bash de forma manual, muy útil para sistemas antiguos.

Actualización de Gitlab a la versión 7.2

Acabamos de actualizar la instalación de Gitlab del centro a la última versión disponible. En esta ocasión, hemos pasado de la versión 6.8 a la 7.2. Las principales novedades son estas:

Gitlab

  • Se pueden asignar colores a las etiquetas del gestor de issues (7.2).
  • Se pueden agrupar los repositorios con el mismo milestone, de forma que es más sencillo trabajar con las milestones en proyectos que utilizan varios repositorios (7.1).
  • Nueva página de login (7.1).
  • Al gestionar milestones, se puede cambiar el estado de los issues arrastrando y soltando en su columna correspondiente (7.0).
  • Hay algunos cambios sutiles de permisos en los roles developer y master (7.0).

Gitlab publica una nueva versión cada mes y en el CiTIUS actualizamos Gitlab con frecuencia, especialmente si hay algún problema de seguridad que se solucione con una actualización.

El sistema de integración continua Gitlab CI no se actualiza con tanta frecuencia. La última versión data de mayo de 2014 y desde que lanzamos el servicio no ha salido ninguna versión nueva.

Trabajando en la terminal de forma más productiva (II)

Hace un par de semanas mostramos algunas alternativas para trabajar en la terminal de forma más productiva en la primera parte de esta entrada (ojo también a los comentarios). Hoy hablaremos de terminales y de alternativas a aplicaciones tradicionales para terminal.

Terminales para todos los gustos

Hoy en día hay emuladores de todo tipo. La mayoría disponen de pestañas, integran opciones de historial y colores. Pero hay distintas características que pueden ayudar a mejorar la productividad.

Guake y Yakuake son dos opciones muy populares de terminales tipo Quake, llamadas así porque, como la terminal de debug del videojuego Quake (1996), se deslizan desde la parte superior de la pantalla.

Terminator permite dividir la terminal en varios tiles y escribir en todas (o solo en algunas) a la vez. Se pueden reordenar, dividir, minimizar… Terminator es una opción muy cómoda para realizar la misma tarea en varias máquinas. Además, soporta múltiples atajos de teclado y tiene un sistema de plugins para añadir funcionalidad adicional.

Captura de pantalla de 2014-05-16 17:44:46

Final Term es un concepto de terminal más moderno, que tiene funciones muy interesantes como autocompletado utilizando un menú contextual, reconocimiento semántico de la salida de los programas. Reconoce la salida de los comandos más habituales y muestra opciones, permite contraer la salida de los comandos…

text-menu

Alternativas a las utilidades clásicas de terminal

Las utilidades como ps o top son ampliamente conocidas por estar presentes en prácticamente todos los sistemas basados en GNU/Linux, pero existen otras alternativas interesantes que, en muchas ocasiones, son mucho más productivas.

La utilidad htop es una versión mejorada de top. Soporta color, muestra la información de carga de cada core por separado y permite navegar por los procesos utilizando el teclado para realizar acciones sobre esos procesos, como enviarles señales o modificar su niceness.

En lugar de df se puede utilizar la herramienta pydf, que muestra de forma algo más gráfica el espacio disponible en cada punto de montaje, usando colores y gráficos de barras.

Captura de pantalla de 2014-05-17 18:56:17

Dstat hace las veces de vmstat, iostat, netstat e ifstat, también con salida a color. Tiene alguna funcionalidad adicional, como permitir mostrar mediciones por procesador, punto de montaje o interfaz de red.

Ncdu acerca la utilidad du a alternativas de escritorio más completas, mostrando el espacio utilizado de forma gráfica. Permite también borrar archivos y directorios moviéndose con el teclado.

¿Conocéis más utilidades del estilo? ¿Qué aplicación de terminal es vuestra favorita? Te animamos a compartirlo con todos en los comentarios de la entrada.

Heartbleed en el CiTIUS y recomendaciones de seguridad

heartbleedA estas alturas todo el mundo estará al tanto de uno de los agujeros de seguridad más graves, por lo menos en cuanto a su impacto, que ha afectado a Internet en los últimos años: Heartbleed.

El problema es que ha estado presente durante más de un año y hasta que ha sido desvelado, cualquiera que tuviera de su conocimiento ha podido usarlo para obtener datos muy sensibles, como los certificados de servidores, cookies de sesión o contraseñas de usuarios, y es prácticamente imposible saber si ha sido así o no.

Lamentablemente, los servidores web y VPN del CiTIUS estaban afectados por dicho fallo de seguridad.

Fuimos rápidos parcheando el problema en ambos servicios, la misma mañana del 8 de abril, pocas horas después de que se hiciera público. Es poco probable que atacantes malintencionados, más allá de aquellos privilegiados que tuvieran el conocimiento antes del bombazo mediático, recuperasen datos sensibles. Y es difícil de creer que pudiésemos ser objetivo de los ataques de alguien así.

En nuestro caso, el disponer de un servidor Nginx que distribuye las peticiones hacia otros servidores internos a modo de pasarela ha jugado a nuestro favor: Ha permitido parchear el problema con mayor rapidez. En el improbable caso de que alguien consiguiese explotar el problema a tiempo, tan solo podría obtener datos en la memoria de ese servidor pasarela (aunque es cierto que al pasar todas las peticiones por allí, son muchos, pero son menos).

Recomendaciones para usuarios del Cloud IAAS

Algunas de las plantillas disponibles en el cloud IAAS están afectadas por este fallo de seguridad, por lo que los usuarios que hayan desplegado servicios que estén utilizando OpenSSL deben asegurarse de que el paquete OpenSSL está actualizado. Las versiones vulnerables son todas las de la rama 1.0.1 hasta la 1.0.1f. La versión 1.0.1g es la que incluye el parche de seguridad. En las próximas horas actualizaremos las plantillas para que las nuevas máquinas virtuales desplegadas no tengan este problema.

Recomendaciones de seguridad generales

Todos los usuarios deberían cambiar ahora todas sus contraseñas más sensibles, especialmente si las comparten entre varios servicios. Mashable ha publicado un listado de servicios afectados. Se debe comprobar antes si el servicio aún está afectado por el problema, aunque a estas alturas es poco probable.

En el caso de las cuentas del CiTIUS, recomendamos cambiarlas a través de este formulario a aquellos que se hayan identificado en la página web del centro desde el lunes por la tarde hasta que se parchearon los servidores, el martes a primera hora.

Hasta donde sabemos, los servidores de la USC no estaban funcionando con la versión de OpenSSL afectada, por lo que las cuentas de la USC no corren ningún peligro.

Es importante que todo el mundo comprenda que, aunque no sean tan mediáticos o tan graves, problemas de seguridad que pueden llevar a un robo de información sensible no son nada infrecuentes. Por ello, os damos una recomendaciones generales de seguridad que ayudarán a mantener a salvo vuestras credenciales y otros datos importantes:

  • Utilizar contraseñas diferentes en cada servicio, especialmente en aquellos que manejen o contengan información sensible, como el correo electrónico, servicios de banca, etc.
  • Utilizar contraseñas fuertes, que sean suficientemente largas, compuestas por símbolos y combinaciones de letras mayúsculas y minúsculas y que no tengan un significado que pueda llevar a su adivinación (acrónimos, fechas, diminutivos, palabras reales, etc.).
  • Tener la costumbre de cambiar las contraseñas cada cierto tiempo, una buena práctica es hacerlo de forma anual.
  • Mantener los sistemas y todo el software actualizados, especialmente en aquellos dispositivos que se utilizan para realizar compras, conectarse a banca electrónica, etc.
  • Evitar, si es posible, utilizar puntos de conexión a Internet públicos, especialmente si son abiertos, como los disponibles en aeropuertos, estaciones de autobuses o algunas cafeterías.

Más información:

Servidor comprometido no centro

Este luns recibimos unha chamada da Área TIC da Universidade, xa que detectaran ataques de forza bruta contra sitios web WordPress de Internet dirixidos dende un dos nosos servidores.

A IP correspondía non cun servidor, senon cunha rede virtual na que hai dez servidores, que son os que proven servizos web, así que houbo que identificar a máquina pola nosa parte. Tampouco foi moito problema, xa que tiñamos sospeitas de onde podía estar o problema: no servidor virtual onde se atopan as páxinas persoais, de proxectos e de eventos.

Efectivamente, despois de apagar esa máquina os ataques cesaron por completo, polo que procedemos a illala da rede para analizar o que estaba pasando.

Seguindo as mesmas sospeitas que nos levaron a apagar a máquina, comezamos por analizar os logs de acceso de Apache, para localizar execucións de scripts que non deberan estar aí.

10.1.98.xxx - - [16/Feb/2014:22:44:22 +0100] "POST /xxx/wp-content/themes/project-ar2-master/stylegreen.php HTTP/1.0" 200 5551 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100102 Firefox/16.0"
10.1.98.xxx - - [16/Feb/2014:22:44:22 +0100] "POST /xxx/wp-content/themes/project-ar2-master/stylegreen.php HTTP/1.0" 200 5551 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100102 Firefox/16.0"
10.1.98.xxx - - [16/Feb/2014:22:44:23 +0100] "POST /xxx/wp-content/themes/project-ar2-master/stylegreen.php HTTP/1.0" 200 8422 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100102 Firefox/16.0"
10.1.98.xxx - - [16/Feb/2014:23:18:50 +0100] "GET /xxx/wp-content/themes/project-ar2-master/flotch-style.php HTTP/1.0" 200 324 "http://pinglard.com/pinglord/lordos.php?t=4" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"
10.1.98.xxx - - [16/Feb/2014:23:41:24 +0100] "GET /xxx/wp-content/uploads/function_php.php HTTP/1.0" 500 642 "http://hennexxx.com/the-henxxx/hennexxxtuff.php?t=4" "Opera/9.80 (Windows NT 6.1; WOW64; U; ru) Presto/2.10.289 Version/12.00"

Aclaramos que as xxx varias son para tapar as vergoñas. En calquera caso vemos como, tras executar peticións POST a un script pertencente a un tema de WordPress chamado Project-Ar2, fai unha chamada a un arquivo chamado /xxx/wp-content/uploads/function_php.php que, loxicamente, non debera estar aí.

Este arquivo tratábase dun botnet, moi similar ó que denuncian nesta bitácora. Só que en lugar de tratarse dun plugin falso, o script subiuse usando un exploit dun tema de WordPress.

Esquema que ilustra o funcionamento dun botnet, pertencente á Wikipedia (cc-by-sa Tom-b)

Esquema que ilustra o funcionamento dun botnet, pertencente á Wikipedia (cc-by-sa Tom-b)

Ó citado botnet non lle basta con executarse subindo un código PHP ó servidor, xa que normalmente estes scripts execútanse nun entorno no que están moi limitados en tempo de execución e en permisos. O script en si o que fai é intentar saír deste entorno. No noso caso conseguiuno, engadíndose ó crontab do usuario que executaba PHP. Unha vez executado, o primeiro que fai é borrarse do crontab para non deixar rastro.

Aínda así, executar un binario tampouco é doado, porque é habitual que as particións onde pode escribir ese usuario non teñan permisos de execución, así que o que fixo foi escribir unha biblioteca compartida que reimplementaba algunha función elemental co código malicioso, e executar calquera binario do sistema usando a técnica do LD_PRELOAD.

Determinar que fixo exactamente no sistema non é doado, pero todos os indicios apuntan a que non conseguiu gañar acceso de superusuario, e que de feito parece que nin sequera o chegou a intentar.

Tras pedir as pertinentes desculpas e rematar o análise, volvimos a poñer o servidor en marcha.

Este problema podería haberse evitado, por suposto. Bastaría con ter deshabilitado o cron nos usuarios que executan PHP, ou non permitir o uso de funcións de PHP coma system ou shell_exec, ou usar open_basedir para negar a PHP abrir ou executar arquivos fora da ruta que sirve os arquivos PHP.

Por suposto, aplicamos inmediatamente todas as recomendacións que nos fixemos a nos mesmos, que se unen ó uso do módulo suphp e outras boas prácticas máis básicas que xa viñamos empregando.

Como curiosidade, moitos de vos notastes este luns coma Google pedía un captcha ó utilizar os seus servizos dende o centro. Efectivamente, foi por culpa disto.

Sistema de recirculación do aire para o CPD

Xa falamos este inverno dos problemas que tiñamos co aire frío, xa que o sistema de aire acondicionado non quenta o aire de entrada e, cando no exterior as temperaturas baixan moito, os equipos reciben ese aire frío directamente e apáganse.

Afortunadamente, xa está instalado e operativo o sistema de recirculación do aire, que engade un sistema de comportas e unha conexión entre a entrada e a saída do aire.

fotoaire

Os tubos que van para arriba forman parte doutro sistema de reaproveitamento do calor residual, para regular a temperatura doutros sistemas de aire acondicionado do centro.

Este sistema computerizado, manexa variables como a temperatura externa, a hora do día e a temperatura interna para decidir a posición das comportas que permiten ou non o refluxo do aire de saída cara ó sistema de aire acondicionado.

chart4

Nesta gráfica podemos atopar xa unha comparativa do antes e o despois, coas temperaturas de entrada de aire no clúster de computación. A liña verde corresponde á última semana completa de novembro, mentres que a liña azul á primeira semana completa de febreiro, xa co novo sistema funcionando. As temperaturas de entrada de aire siguen variando, pero en menor medida.

Tamén é certo que xa non vai tanto frío como nesas datas. En calquera caso, a Oficina de Xestión de Infraestruturas da Universidade está traballando aínda para calibrar este sistema, que é bastante complexo.

Actualizado (4/4/2014): Despois duns axuntes, esta é a gráfica actual de temperatura de entrada de aire da última semana:Temperaturas da última semanaComo se pode observar, o sistema consegue unha temperatura de entrada moi estable, que ronda os 16-17ºC, mellorando por moito a situación presentada no post orixinal.

La directiva europea sobre cookies y su aplicación en España

Desde hace un año aproximadamente, hemos visto cómo Internet se ha ido llenando de popups solicitando el consentimiento para el almacenamiento de cookies. Son, en su mayoría, pequeñas molestias que casi todos los usuarios ignoran porque no las entienden, pero son necesarias para cumplir la legislación vigente.

Empecemos analizando la propia legislación. En el año 2009 la Unión Europea publicó la Directiva 2009/136/CE, en la que se especifica en su punto 66, que:

Puede que haya terceros que deseen almacenar informa­ción sobre el equipo de un usuario o acceder a informa­ción ya almacenada, con distintos fines, que van desde los fines legítimos (como algunos tipos de cookies) hasta aque­llos que suponen una intrusión injustificada en la esfera privada (como los programas espía o los virus). Resulta, por tanto, capital que los usuarios reciban una información clara y completa cuando realicen una acción que pueda dar lugar a dicho almacenamiento u obtención de acceso. El modo en que se facilite la información y se ofrezca el dere­cho de negativa debe ser el más sencillo posible para el usuario. Las excepciones a la obligación de facilitar infor­mación y proponer el derecho de negativa deben limitarse a aquellas situaciones en las que el almacenamiento técnico o el acceso sean estrictamente necesarios con el fin legí­timo de permitir el uso de un servicio específico solicitado específicamente por el abonado o usuario. Cuando sea téc­nicamente posible y eficaz, de conformidad con las dispo­siciones pertinentes de la Directiva 95/46/CE, el consentimiento del usuario para aceptar el tratamiento de los datos puede facilitarse mediante el uso de los parámetros adecuados del navegador o de otra aplicación. La apli­cación de estos requisitos debe ganar en eficacia gracias a las competencias reforzadas concedidas a las autoridades nacionales.

En marzo de 2012, el Real Decreto 13/2012 modificó el artículo 22.2 de la Ley de la Sociedad de Servicios de la Información (LSSICE) para adecuarse a la directiva europea, y lo dejó con la siguiente redacción:

Los prestadores de servicios podrán utilizar dispositivos de almacenamiento y recuperación de datos en equipos terminales de los destinatarios, a condición de que los mismos hayan dado su consentimiento después de que se les haya facilitado información clara y completa sobre su utilización, en particular, sobre los fines del tratamiento de los datos, con arreglo a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

Cuando sea técnicamente posible y eficaz, el consentimiento del destinatario para aceptar el tratamiento de los datos podrá facilitarse mediante el uso de los parámetros adecuados del navegador o de otras aplicaciones, siempre que aquél deba proceder a su configuración durante su instalación o actualización mediante una acción expresa a tal efecto.

Lo anterior no impedirá el posible almacenamiento o acceso de índole técnica al solo fin de efectuar la transmisión de una comunicación por una red de comunicaciones electrónicas o, en la medida que resulte estrictamente necesario, para la prestación de un servicio de la sociedad de la información expresamente solicitado por el destinatario.

Aún cuando no se habla de cookies, la definición que da el texto las engloba sin lugar a dudas. Pero con una redacción tan técnica y, al mismo tiempo, tan poco concreta, cuesta imaginar cómo hemos llegado a la situación actual.

La respuesta la encontramos en la Guía sobre el uso de las cookies, publicada por la Agencia Española de Protección de Datos en abril de 2013. En ella, se detalla a partir de la redacción de la ley de qué se debe informar, cuándo y cómo.

Guía sobre el uso de las cookies

Siendo la Agencia Española de Protección de Datos un organismo con competencias para emitir sanciones administrativas con respecto al incumplimiento de la LSSICE, y sobretodo después de que en agosto de 2013 emitieran una primera sanción ejemplar, la gente empezó a preocuparse por seguir las directrices de dicha guía, muchas veces de forma apresurada.

En la guía, de 25 páginas, se establece un procedimiento para informar sobre el uso de cookies de forma adecuada y razonable, mediante lo que denominan capas: una primera que sería el famoso popup, y una segunda que sería una página con una explicación más pormenorizada. Ese es el modelo que siguen prácticamente la totalidad de las páginas web.

En realidad, no todas las cookies están sujetas a esta ley y la AEPD ha definido cuáles quedan exentas exactamente: Cookies de «entrada del usuario», de autenticación o identificación de usuario (únicamente de sesión), de seguridad del usuario, de sesión de reproductor multimedia, de sesión para equilibrar la carga, de personalización de la interfaz de usuario y de plugin para intercambiar contenidos sociales. Algunos nombres son un poco raros, pero se definen en el documento. Quedarían exentas pues, cookies donde se almacena el idioma y otras preferencias de navegación, o cookies donde se almacene un token de sesión.

Normalmente las páginas web incluyen contenido de terceros que sí crean cookies, como botones de redes sociales o reproductores multimedia (YouTube). En ese caso, es necesario informar del uso que esos terceros hacen de las cookies, aún cuando no se tiene el control sobre los posibles cambios que hagan estos terceros en sus políticas de privacidad. Por ello, la guía propone lo siguiente:

Cuando se instalen cookies de terceros se deberían incluir en los contratos que se celebren entre los editores y los terceros, una o varias cláusulas en las que se asegure que se ofrecerá a los usuarios la información requerida y que se articulará la forma a través de cual se pueda obtener un consentimiento válido para la utilización de las cookies.

Es decir, las redes sociales, Google y demás proveedores de estos contenidos que crean cookies deberían incluir en sus términos de uso una aclaración sobre el uso de estas cookies, que sea inmutable o que notifique si cambia algo en la política de privacidad respecto a las cookies.

Es entendible el objetivo de la ley: proteger los datos personales de los usuarios, intentando evitar que, mediante el uso de cookies, se hagan cosas como rastrear comportamientos sin el consentimiento expreso. Sin embargo, esta ley y la correspondiente guía de la AEPD fallan, porque:

  1. No limitan ni aclaran cómo informar correctamente y de forma asumible y eficaz el uso de cookies por parte de terceros para rastrear comportamientos, el gran (¿y único?) problema de las cookies.
  2. Los mecanismos creados para informar al usuario son ineficaces, porque aún suponiendo que sea de su interés, los usuarios no entienden el mensaje y se presenta de forma molesta.

Dice la ley, tomándolo prestado de la directiva europea, que «cuando sea técnicamente posible y eficaz, el consentimiento del destinatario para aceptar el tratamiento de los datos podrá facilitarse mediante el uso de los parámetros adecuados del navegador o de otras aplicaciones». De hecho los navegadores pueden informar sobre la creación de cookies, pero este mecanismo no permite cumplir los requisitos de la ley, porque no se puede incluir junto con las cookies toda la información que la ley requiere.

Sin embargo, debería ser este el camino a seguir: extender el mecanismo de creación de cookies de forma que se permita incluir información adicional sobre qué contiene la cookie y para qué se utiliza. De esta forma, sería el navegador el encargado de interpretar esta información y mostrar al usuario lo que está ocurriendo realmente, si es que quiere verlo.

Quizás, algún día, los navegadores mejoren estos mecanismos y los adopten, pero mientras tanto hay que aguantarse.

Firefox y los certificados expedidos por RedIRIS

Tanto la Universidad como el CiTIUS utilizan el Servicio de Certificados de RedIRIS para servidores, que les provee certificados de forma gratuíta expedidos por TERENA a través del TERENA Certificate System.

TERENA es una organización europea cuyo objetivo es el desarrollo de infraestructuras en educación e investigación. En cuanto a su servicio, es una autoridad certificadora intermedia que obtiene los certificados de Comodo, una autoridad certificadora que sí es de primer nivel.

Aunque la mayoría de los navegadores contienen los certificados de las autoridades Comodo y TERENA, hay un navegador ampliamente utilizado que se resiste a incluír el certificado intermedio de Terena, Firefox.

Todo esto se resume en que al entrar con Firefox en una página segura que utilice un certificado expedido por RedIRIS, aparecerá una advertencia porque el navegador desconoce el certificado de TERENA, y por lo tanto no puede validar el certificado del servidor.

Firefox 26 mostrando una advertencia de certificado en la página web del CiTIUS

Afortunadamente, este problema se puede solventar incluyendo junto al certificado del servidor, el certificado de la propia autoridad intermedia, algo que ya se hacía para la página de la USC y ahora también para la del CiTIUS.

¿Por qué ocurre esto?

Comprobar la identidad de un sitio web es fundamental en una conexión segura, y para ello los servidores envían un certificado firmado por una autoridad certificadora. Los navegadores, habitualmente conocen y confían en estas autoridades.

Firefox, al no incluír a TERENA entre las autoridades certificadoras confiables, no puede verificar la identidad de los sitios web que envíen certificados expedidos por ellos.

Sin embargo, TERENA es una autoridad certificadora de segundo nivel, lo que significa que ejerce de intermediaria entre los usuarios finales de los certificados (o incluso autoridades de nivel inferior) y una autoridad certificadora de primer nivel, en este caso Comodo. Firefox sí incluye el certificado a Comodo entre las autoridades certificadoras confiables.

Al configurar el servidor para que envíe el certificado emitido por TERENA, más el certificado que identifica a la propia TERENA, Firefox puede identificar a TERENA como autoridad certificadora confiable, y a su vez comprobar la identidad del certificado emitido.

Preparándose para el invierno más frío

Dice la prensa que este será el invierno más frío de los últimos 100 años, o de los últimos 60 años dependiendo de la fuente. En cualquier caso, parece que este será un invierno complicado.

Este fin de semana hemos sufrido una caída del servicio por culpa del frío –la primera de este año. Concretamente, -1,5ºC de frío según el histórico de Meteogalicia.

Mientras esperamos que se arreglen ciertos problemas burocráticos para la instalación de una solución definitiva, hacemos lo que podemos. El año pasado comenzamos tapando la ventilación manualmente en las zonas más afectadas como primera medida, y más tarde acordamos con los servicios de la universidad un apagado automático de la ventilación por la noche.

Este año todavía no nos hemos atrevido a solicitar ese apagado automático, porque si bien a los servidores no les hace ningún bien escupirles aire a -1,5ºC, dejarlos sin ningún tipo de ventilación puede ser también peligroso, por lo que tenemos que asegurarnos que el invierno ha llegado de verdad.

Vale, y a estas alturas creo que todos estamos de acuerdo en que ha llegado.

Por supuesto, sabiendo que este problema existía, este año nos hemos preparado replicando los servicios más esenciales en servidores que están situados más lejos de la ventilación.

Como curiosidad, esta es una lectura de la temperatura del aire de una sonda situada en la entrada de aire de uno de los servidores afectados, durante los dos últimos meses.

Lectura de temperaturas de los 2 últimos meses

Menudo mes de noviembre. En la lectura de la última semana puede verse mucho mejor el problema de este fin de semana. Al bajar de 4º, el servidor en cuestión se apaga (y como ese, muchos otros).

Lectura de temperaturas de última semana