Auditoría de sistemas UNIX. Parte 3. El nivel de parche

El nivel de parche de una máquina nos debe ofrecer información suficiente para saber cuál es el último bundle de parches instalados. Empleo la palabra bundle y no conjunto de, o ramillete porque en la literatura es habitual hablar de bundle, y por tanto, así os irá sonando más este concepto.

En los sistemas UNIX es frecuente que, al igual que pasa en otras arquitecturas, de vez en cuando el fabricante recopile muchos parches individuales y los unifique en un sólo paquete. Esta unificación es lo que se llama un bundle de parches. Casi todos los sistemas UNIX son ofrecidos por fabricantes consolidados, y entre las obligaciones que tienen para con los clientes está en suministrar este tipo de paquetes, así como ofrecer soporte en su despliegue.

Los parches no tienen por qué ser de seguridad: muchas veces cubrirán deficiencias de rendimiento, u ofrecerán funcionalidades nuevas al usuario.

Es importante notar que no siempre es necesario que nuestro sistema contenga siempre el último bundle disponible. Es más, en sistemas de producción real es hasta desaconsejable, siempre que la máquina tenga una exposición a terceros nula o muy controlada, ir por detrás en una o dos actualizaciones. Esto responde a la necesidad de que las máquinas sean estables, y que el tiempo que transcurre entre la liberación de un bundle y su instalación nos permita evaluar el impacto de las actualizaciones en el sistema. Lo hemos dicho muchas veces, pero dejadme que insista que la instalación de parches de cualquier tipo requiere una gestión de los mismos, y que parchear un sistema en producción real sin evaluar seria y profundamente el impacto de las parches es suicida y desaconsejable.

El nivel de parche es un indicador mediante el cual podemos conocer, tal y como hemos dicho, cuál es el último ramillete de actualizaciones instalado. Eso no quita que haya componentes individuales actualizados por fuera del bundle, con lo que es el auditor el que, partiendo del nivel de parche, evaluará los servicios actualizados y no actualizados para cada caso particular.

Ejemplo práctico

Vimos ayer que tras ejecutar un uname -a en una máquina SunOS, el resultado era:

SunOS tape 5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Fire-280R

Marcamos en negrita el nivel de parche, tal y como vimos ayer. Si nos referimos a nuestra primera lección, aquella en la que hablamos sobre la Piedra Rosetta UNIX, vemos que hay otra manera de invocar el nivel de parche: utilizando el comando Solaris showrev. Esta manera es además, la correcta y más completa, ya que arroja resultados adicionales. Así, por ejemplo, si ejecutamos un showrev -p, tendremos que:

Patch: 101242-11 Obsoletes: Packages:
Patch: 105216-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105393-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105518-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105621-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu, SUNWarc
Patch: 105665-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105401-08 Obsoletes: 105524-01 Requires: Incompatibles: Packages: SUNWcsu, SUNWarc, SUNWnisu
Patch: 105216-03 Obsoletes: Requires: 105401-07 Incompatibles: Packages: SUNWcsu
Patch: 105615-03 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105621-02 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu, SUNWarc
Patch: 105667-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105686-02 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 106033-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
Patch: 105401-13 Obsoletes: 105524-01 Requires: Incompatibles: Packages: SUNWcsu, SUNWcsr, SUNWarc, SUNWnisu
Patch: 106301-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu

La estructura informa del número de parche, de los parches a los que convierte en obsoletos, los parches que se requieren, cuáles se tornan en incompatibles y también se citarán para cada caso, los nombres de los paquetes.

Ahora toca preguntarle al fabricante en qué situación estamos. En el caso de Solaris, la fuente más fidedigna es Sun Solve, en la que buscaremos información sobre el nivel de parche aparecido en el uname y el showrev, en este caso, 108528-19

Status: OBSOLETE

Patch Id: 108528-19
Keywords: security DNLC kaio cPCI pcf8574 ssre pcipsy I2C devlinks RCM RSAMPI
Summary: Obsoleted by: 108528-20 SunOS 5.8: kernel update patch
Date: Feb/21/2003
Installation Requirements: None
Solaris Release: 8
Sun OS Release: 5.8
Unbundled Product:
Unbundled Release:
Xref: This patch available for x86 as patch 108529
Topic:
SunOS 5.8: kernel update patch
Relevant Architecture: sparc

Concluiremos nuestro análisis averiguando cuál es el cluster de parches que recomienda el fabricante. En este caso, para arquitecturas SPARC, y siendo SunOS 5.8, tenemos que el último parche para este sistema fue puesto a disposición del público el pasado 16 de diciembre de 2006, mientras que el que tenemos instalado data de febrero de 2003. Existe una desactualización muy manifiesta.

Es recomendable tomar los 5 o 10 últimos parches más recientes (los de numeración mayor) que se muestran en showrev -p y analizarlos uno a uno, sin tener en cuenta el bundle. Nosotros sólo analizaremos el primero, que si os fijáis más arriba, es 106033-01. Volvemos a Sun Solve y tenemos que se trata de un parche individual de tareas automatizadas CRON, también obsoleto.

Status: OBSOLETE

Patch Id: 106033-01
Keywords: cron y2000
Summary: OBSOLETED by 105621
Date: Mar/02/98
Installation Requirements:
Solaris Release: 2.6
Sun OS Release: 5.6
Unbundled Product:
Unbundled Release:
Xref:
Topic:
SunOS 5.6: /usr/sbin/cron patch

Haremos lo mismo con los últimos 10 parches que localicemos y valoraremos si el nivel de parche global (bundle) así como el de los parches individuales es acorde o no a lo que recomienda el fabricante. Será labor posterior para el auditor, si realiza tareas consultivas, analizar si la desviación respecto a la actualización recomendable supone o no un problema.

Si en vez de un Solaris tenemos un NCR Unix, el comando será pkginfo -l. Para HP-UX, ejecutaremos un swlist -l. Para un Tru64, ejecutaremos la secuencia:

dupatch -track -type kit
dupatch -track -type patch
setld -i | grep patchname
sizer -vB

El resto de equivalencias está, como siempre, en la Piedra Rosetta UNIX.

Resumen

El nivel de parche define el estado de actualización global de una máquina UNIX. La auditoría debe contemplar, además de ese estado global, un muestreo de los últimos parches individuales instalados, para dictaminar el grado de obsolescencia del sistema.

Un sistema que no posea el último paquete de parches disponible instalado no tiene por qué representar un problema. En entornos de producción real se valora muchas veces más la disponibilidad y la integridad que la seguridad, con lo que no siempre debe ser éste último parámetro el que obligue a que se tenga que someter o no una actualización al sistema. Cada caso requiere un estudio pormenorizado.

Las actualizaciones en sistemas UNIX de producción real son complejas, arriesgadas, costosas y suelen provocar un daño importante en caso de fallo. No deben hacerse sin un estudio de impacto previo, siendo recomendable el asesoramiento directo del fabricante en la mayoría de los casos.