Bug de SSL y gestión de parcheado de Sistemas Operativos

Bueno como todos probablemente hayáis leído, ha aparecido un bug de OpenSSL que podría permitir el robo de información, que en otras condiciones estaría protegida por el cifrado SSL/TLS.

Voy a dividir el post en 2 partes, la primera la técnica:

Se puede encontrar más información en http://heartbleed.com/ y puedes ver si un sitio está afectado usando https://code.google.com/p/go/downloads/list También hay una herramienta online, pero no es muy buena idea usarla: https://gist.github.com/janl/10107626

El bug se resolvió de forma muy rápida, por ejemplo en Red Hat no pasaron ni 24 horas:
https://rhn.redhat.com/errata/RHSA-2014-0376.html

Y por ejemplo en Red Hat, no afectaba a ninguna de las versiones de RHEL 5, y en RHEL 6 solo afectaba a la ultima versión la 6.5.
https://access.redhat.com/site/solutions/781793

El problema se soluciona actualizando simplemente el paquete openssl, y después de hacerlo hay que tener en cuenta que hay que reiniciar todos aquellos servicios que estén usando la versión antigua, se puede comprobar usando el comando:
“lsof -n | grep ssl | grep DEL”

Ahora la parte menos técnica:

En Linux (Red Hat, Debian, Ubuntu…) había un fix en apenas 24 horas, que hubiera pasado si fuera un sofware privativo, como Microsoft o Apple? Pues nunca sabremos la respuesta, pero tenemos ejemplos pasados de retrasos en problemas parecidos:
http://www.forbes.com/sites/andygreenberg/2014/02/25/apple-patches-its-gotofail-security-bug-for-osx-after-four-days-of-heckling/
http://microsoft-news.com/microsoft-finally-fixes-the-svchost-bug-in-windows-xp-after-years/

Ojo, estoy totalmente desconectado del mundo privativo, así que no sé si los ejemplos que pongo son algo aislado, pero por los titulares que suelo leer, creo que no.

Otro tema a tener en cuenta que comentaba https://twitter.com/pantulis/ aquí https://twitter.com/pantulis/status/453508912327974912 era la problemática de que los clientes valoren el mantenimiento y de la plataforma/sistema operativo, que está alrededor de una solución.

Desde mi experiencia como administrador de sistemas y como consultor: Nadie lo valora hasta que tienen un problema, por eso hace años que cuando algún familiar o conocido me pregunta por temas de hosting o similar, siempre les oriento hacia soluciones de hosting compartido, en las que pagas a una empresa para que (al menos supuestamente) se encargue de todo este mantenimiento.

Además, por desgracia, esto también pasa no solo de cara a clientes que solo ven en la tecnología un medio para su negocio, hay empresas de tecnología que ni siquiera tienen definido ciclos de vida de sus soluciones, ni definidas políticas de parcheado.

Por último como comentario “corporativo”, para entender como Red Hat entiende los ciclos de vida del Sistema Operativo:

Red Hat no diferencia entre versiones “menores”, es decir, para Red Hat, solo existe RHEL 6, lo de RHEL 6.1, 6.2, etcétera son sólo imágenes iso que se sacan cada cierto tiempo, cuando se saca alguna actualización, que pueden ser de seguridad, arreglo de fallo o nueva funcionalidad, pues se incorpora directamente en el canal (repositorio) de RHEL 6, pero no a las isos que siguen siendo las mismas.

Para la gestión del software del sistema operativo Red Hat ofrece, Red Hat Network Satellite, con este producto, entre otras muchísimas cosas, lo que dispones es de un “Canal” (algo parecido a un repositorio) que se sincroniza con Red Hat Network para tener las ultimas versiones de todos los paquetes RPM. Hasta aquí nada nuevo, la ventaja es que además permite “clonar” estos canales para adaptarlos al ciclo de vida de la empresa, que puede ser por versiones menores, o cualquier otro criterio. Además desde la interfaz web o mediante la API, podríamos actualizar sistemas o grupos de sistemas en base a muchos criterios:
– Cambios de versión (la que haya definido el cliente)
– Aplicar sólo actualizaciones de seguridad
– Aplicar sólo actualizaciones relativas a una(s) errata(s)

Permite también obtener informes para ver las erratas pendientes de aplicar a estos sistemas y un largo etcétera de utilidades para la gestión del ciclo de vida de los sistemas.

Pero incluso si solo dispusieramos de repositorios RPM, y aunque tuvieramos que hacerlo uno a uno en cada sistema, mediante yum también podríamos:
– Comprobar si un sistema está afectado o no por una determinada errata o alerta de seguridad
– Aplicar sólo actualizaciones de seguridad
– Aplicar sólo actualizaciones relativas a una(s) errata(s)

Y por supuesto en el resto de distribuciones Linux seguro que hay alternativas parecidas para hacer lo mismo, en definitiva, que es un problema más de estrategia corporativa y de mentalidad que técnico, y por desgracia no se valora el trabajo “en la sombra” de los administradores de sistemas.

Leave a Reply

Your email address will not be published. Required fields are marked *