Ahora que he organizado minimamente alguna tarea de esas que uno tiene siempre pendiente y necesita retocar... Una vez instalado, puesto en producción y comprobado el rendimiento de un servidor en FreeBSD, llegamos a la administración del mismo y los -siempre buenos- advisories de seguridad.

Oh! un advisory

Hace un par de días se puede leer en Security Advisories de FreeBSD un correo indicando un potencial rollback de ssl 2.0. ¿Qúe significa esto?, ni idea... por la descripción del correo parece ser que en un entorno ideal (SSL_OP_MSIE_SSLV2_RSA_PADDING activado en servidor), un atacante puede hacer que tanto cliente como servidor usen SSLv2 en vez de SSLv3 con los consiguientes riesgos.



Si seguimos leyendo podemos observar que las ramas afectadas son practicamente todas:

Affects:        All FreeBSD releases.
Corrected:      2005-10-11 11:52:46 UTC (RELENG_6, 6.0-STABLE)
                2005-10-11 11:53:03 UTC (RELENG_6_0, 6.0-RELEASE)
                2005-10-11 11:52:01 UTC (RELENG_5, 5.4-STABLE)
                2005-10-11 11:52:28 UTC (RELENG_5_4, 5.4-RELEASE-p8)
                2005-10-11 11:52:13 UTC (RELENG_5_3, 5.3-RELEASE-p23)
                2005-10-11 11:50:50 UTC (RELENG_4, 4.11-STABLE)
                2005-10-11 11:51:45 UTC (RELENG_4_11, 4.11-RELEASE-p13)
                2005-10-11 11:51:20 UTC (RELENG_4_10, 4.10-RELEASE-p19)

Los pasos oficiales

Por lo que si hemos efectuado una instalación previa a esas horas, debemos de actualizar nuestro sistema siguiendo los pasos que se describen en el mismo correo: 1.- Nos bajamos parche y signature comprobando con una herramienta PGP que los archivos sean los correctos. 2.- Parcheamos en /usr/src los fuentes del sistema. 3.- Recompilamos todo como indica este documento. Gran inconveniente de tener un servidor remoto y en producción: el reinicio.

La solución "extra"

Cada administrador puede valorar el riesgo de este advisory, con esta entrada no pretendo destacarlo por ninguna razón, simplemente es tomado como ejemplo práctico para el uso de freebsd-update remotamente.

Tenemos la otra solución, que es a lo que iba: freebsd-update. Sencillo, con bajar los parches binarios y luego instalarlos será suficiente:

# freebsd-update fetch
Fetching updates signature...
Fetching updates...
Fetching hash list signature...
Fetching hash list...
Examining local system...
Fetching updates...
/usr/lib/libssl.a...
/usr/lib/libssl.so.3...
Updates fetched

To install these updates, run: "/usr/local/sbin/freebsd-update install"

Dont forget to rebuild any statically linked ports
to use the updated libraries after you install them.

# freebsd-update install
Backing up /usr/lib/libssl.a...
Installing new /usr/lib/libssl.a...
Backing up /usr/lib/libssl.so.3...
Installing new /usr/lib/libssl.so.3...

Ahora reiniciamos todos los servicios que puedan servirse de esta librería para cargar el nuevo binario (Apache, SSH...) y el sistema estaría parcheado y listo para seguir en producción.

Finalmente, r0sk dice...

Como opinión personal, -hablando siempre dentro de un entorno de servidor remoto y en producción-, la opción de freebsd-update (como ya había comentado anteriormente) es la que más me convence a la hora de actualizar este tipo de fallos. Pero como dicen en nosequé película de humor: Aleluya aleluya, cada uno con la suya.