Archivo de la etiqueta: web

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.

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.

Alternative PHP Cache

Alternative PHP Code es un módulo de PHP que almacena la salida del compilador de bytecode de PHP en memoria compartida, de forma que reduce el tiempo de análisis y acceso a disco de cargas posteriores.

Este módulo convierte a PHP en algo similar a lo que hacen los intérpretes de otros lenguajes como Python por ejemplo. Python guarda este bytecode en archivos con la extensión pyc para luego reutilizarlo, en lugar de analizar y compilar cada archivo de código fuente cada vez.

Los tiempos de carga de aplicaciones como Drupal se mejoran considerablemente, algo que ya se puede notar ahora mismo en la página web del centro.

Para probarlo, hemos utilizado ab, una herramienta de benchmarking incluída con el paquete apache2-utils.

grafica_php-apc_1

Esta prueba muestra el tiempo medio de la petición del documento principal de tres páginas interiores diferentes del CiTIUS desde la red interna del centro. Se han hecho un total de 100 peticiones por prueba.

El tiempo de carga incluye todo el intervalo de tiempo desde que se solicita el documento hasta que se recibe completo. En los tres casos se aprecia una mejora notable usando PHP con el módulo de APC, con tiempos que en ningún caso alcanzan los 60ms, comparado con PHP sin el módulo, con tiempos que no bajan nunca de los 120ms.

grafica_php-apc_2

Haciendo la misma prueba desde un servidor localizado en otro país, estas diferencias no son tan notables porque APC solo influye en el tiempo en que PHP tarda en compilar el documento, y en este caso aparecen otros tiempos más constantes entre ambas pruebas, causados por la conexión en si. Con todo ello, se aprecian claramente las mejoras de velocidad, que rondan el 30%.

Experiencias con SPDY y PageSpeed

Desde hace unas semanas, las páginas web del centro se sirven con una nueva versión del servidor Nginx con soporte para el nuevo protocolo SPDY y con el módulo PageSpeed activado.

Convencido por las pocas pero vistosas pruebas visuales y el whitepaper que publicó al respecto el artífice de dicho protolo, Google, esperaba poder obtener unas mejoras apreciables en los tiempos de carga de las páginas gracias al protocolo SPDY, pero no fue así.

Podéis leer pruebas de rendimiento más realistas en este paper de Microsoft en el que desmitifican el whitepaper de Google, intentando mejorar los tiempos de carga de HTTP sin recurrir a SPDY. Por ejemplo, con el módulo PageSpeed para Apache, también desarrollado por Google, o activando el HTTP pipelining en el navegador, que viene desactivado por defecto.

En esta tesis de la Aalto University se compara HTTP con SPDY en conexiones móviles (de muy alta latencia), sin hacer hincapié en otros métodos de mejorar los tiempos de carga, y en algunos escenarios alcanza una mejora de tiempo de carga de hasta el 20%, aunque no es lo habitual, y normalmente no alcanza el 10%.

La experiencia de estas semanas nos ha demostrado que, en general, en conexiones con menor latencia la mejora no es apreciable. Además, la implementación de SPDY de Nginx 1.4.1 funciona bien hasta que en algún momento deja de hacerlo y empieza a servir imágenes y otros recursos a medias. Por lo tanto, hemos deshabilitado el soporte de SPDY por ahora a la espera de una solución.

PageSpeed, por su parte, es un módulo bastante complejo, no es «activar y punto» sino que contiene una serie de filtros que se pueden activar o desactivar y configurar. Ofrece muchas posibilidades, entre las más interesantes:

  • Caché de recursos en memoria, a través de memcached.
  • Caché en archivos.
  • Optimizar el HTML, el CSS y el JavaScript comprimiéndolos y juntándolos en el menor número de archivos posible. Estos filtros deben utilizarse con cuidado, porque pueden romper algunas páginas.
  • Hacer Domain Sharding y otras optimizaciones pensadas para que HTTP o SPDY funcionen mejor.

En nuestro caso, estamos siendo bastante conservadores con los filtros de PageSpeed para intentar no romper nada y ya obtenemos una mejora considerable en el rendimiento, teniendo en cuenta además que nuestras páginas web se sirven desde otros servidores a través de Nginx actuando como un reverse proxy.