…es difícil disfrutar de tu trabajo cuando nadie te estima por hacerlo.
En estos últimos días hemos escuchado mucho acerca de este bug, que afecta a la librería de OpenSSL, el cual permite leer partes de la memoria del proceso, hasta 64k, tanto en el cliente como en el servidor, dependiendo del punto de vista del atacante.
Para verlo de forma más clara, los amigos de xkcd, nos los explican en una de sus ilustraciones:
Aunque esos 64 Kb nos parezcan poca cosa, para un atacante puede resultar muy beneficioso, ya que esos datos aleatorios pueden contener información sensible de una sesión actual.
Ante tal situación, debemos protegernos en ambos frentes:
- Equipos Administrados
- Contraseñas
Equipos Administrados
Como SysAdmins, nuestro trabajo es estar atento a este tipo de fallos y solucionarlos rápidamente. Como lo hemos mencionado hasta el cansancio, en las Leyes del SysAdmin.
Una de las formas más rápidas de informarse acerca del fallo, es a través de la página oficial del mismo: heartbleed.com
Si tenemos equipos sobre Internet, existe un sitio que nos puede verificar el status del bug en nuestro sitio: Heartbleed test
En el caso de servidores internos, Red Hat proporciona una solución tanto para sus sistemas empresariales, así como los comunitarios:
- Red Hat [ https://access.redhat.com/site/solutions/781793 ]
- Fedora [ http://fedoramagazine.org/update-on-cve-2014-0160-aka-heartbleed/ ]
Como un recopilatorio de toda la información importante en la evolución del bug, pueden darse una vuelta por este post, que esta en constante actualización.
Contraseñas
En el caso particular de nuestras contraseñas, es muy recomendable que las cambiemos lo antes posible, y que revisemos, mediante las herramientas provistas en el punto anterior, si el sitio donde iniciamos sesión es vulnerable en este sentido.
Para los sitios más comunes [redes sociales], existe una infografía de gran ayuda para saber de manera rápida, en que sitios debemos cambiar la contraseña cuanto antes:
Aunque como los mismos amigos de xkcd nos explican en otra de sus ilustraciones, no todo esta perdido:
Uno de los puntos a favor de esta situación, es que es una prueba del trabajo colaborativo que existe, al ser una solución OpenSource: cuando fue descubierta se empezó a trabajar, primero, en la difusión de la falla, después en la solución, para más tarde, tener un paquete listo con el parche correspondiente.
Aún así, existen varias lecciones que deberíamos, al menos, tomar en cuenta. Les recomiendo ampliamente esta reflexión de nuestros buenos amigos de /etc/cron.d [ uno de mis blogs preferidos 🙂 ].
Espero les sirva.
