Entre bastidores en KernelCare: cómo probamos los parches antes de publicarlos

Las pruebas son esenciales para cualquier actualización de software, incluidos los parches, pero lo son aún más cuando los cambios se realizan en infraestructuras críticas que alimentan servicios que afectan a los ingresos. La publicación de actualizaciones de seguridad que no se prueban a fondo puede provocar fallos en el núcleo, reinicios del sistema operativo, fallos en el sistema o en el nivel de servicio; algunas de estas consecuencias son críticas y otras simplemente desagradables, pero todas ellas pueden perjudicar a su empresa y a los acuerdos de nivel de servicio. KernelCare cuenta con un estricto proceso de pruebas por el que debe pasar cada parche antes de desplegarse en producción, y este artículo detalla cómo garantizamos la fiabilidad y el tiempo de actividad de la infraestructura del cliente tras el despliegue de los parches.

Contenido:

1. Los retrasos en los parches son arriesgados
2. Desarrollo y pruebas de KernelCare
3. Los cuatro tipos de pruebas de KernelCare
4. Conclusión

Los retrasos en los parches son arriesgados

Es esencial que todo el software, incluido el núcleo de Linux, se parchee cuando los desarrolladores publiquen una actualización de seguridad. Es aún más importante parchear lo antes posible cuando se publica una vulnerabilidad con un código de explotación. Cuanto más tiempo se permita que los servidores permanezcan sin parchear, mayor será el riesgo de convertirse en la próxima víctima de una violación de datos. No es infrecuente que los administradores prueben y esperen a una fecha programada antes de parchear. En ese plazo, un atacante podría escanear el servidor, encontrar la vulnerabilidad y aprovecharse de ella.

Dejar la gestión de parches en manos de KernelCare alivia gran parte de la carga de trabajo de los administradores, pero nuestros clientes necesitan tener la seguridad de que se realizan las pruebas adecuadas antes de permitir que un tercero realice la implantación en infraestructuras críticas. Las soluciones de aplicación de parches de KernelCare se someten a rigurosas pruebas antes de su despliegue en los servidores de nuestros clientes. Nuestras pruebas alivian gran parte de la carga administrativa de las grandes organizaciones, de modo que ya no es necesario disponer de varias máquinas con los distintos sistemas operativos de proveedores instalados para garantizar una experiencia de aplicación de parches limpia y sin errores.

Desarrollo y pruebas de KernelCare

Un código con errores puede causar varios problemas, incluida la introducción de nuevas vulnerabilidades. Un ejemplo de por qué es tan importante probar los parches antes de su despliegue es el descubrimiento de una vulnerabilidad trivialmente explotable introducida en mayo de 2020. El parche denominado Huawei Kernel Self Protection se suponía que ofrecía una serie de opciones para reforzar la seguridad del kernel de Linux. En lugar de ello, abría el sistema operativo a posibles puertas traseras, no ofrecía programación a nivel de amenaza y permitía la divulgación de la memoria del núcleo. Como el parche fue probado, el equipo de Linux pudo impedir que debilitara la seguridad del núcleo. Este es un ejemplo de por qué es fundamental probar los parches antes de instalarlos, y KernelCare realiza varios tipos de pruebas antes de desplegarlos en nuestros servidores cliente.

Para ayudar a nuestros clientes a comprender las pruebas de alto nivel que exigimos a nuestros equipos, hemos detallado el proceso a continuación.

1. Aprovisionamos un servidor físico bare-metal o una máquina virtual con el sistema operativo de destino. Si el parche para un CVE (Common Vulnerability Exposures) específico es para un componente de hardware concreto (por ejemplo, una vulnerabilidad de la CPU), aprovisionamos el componente de hardware correspondiente en el servidor. En el caso de una máquina virtual basada en kernel (KVM), aprovisionaremos las máquinas virtuales anidadas y las características de hardware necesarias.
2. Extraemos del proveedor el núcleo que se utilizará para las pruebas y lo instalamos en nuestro servidor de pruebas aprovisionado.
3. Reinicie el servidor con el núcleo recién instalado.
4. Instalamos KernelCare del mismo modo que lo haría un cliente. Publicamos las instrucciones aquí.
5. Ejecute el comando de aplicación de parches KernelCare ($ /usr/bin/kcarectl -update).
6. Carga los módulos del kernel creados para el parche.
7. Validar y probar todas las funcionalidades modificadas del módulo. 
8. Si se dispone de código de explotación, lo utilizamos para reproducirlo en el servidor y comprobar que los parches corrigen la vulnerabilidad.
9. Ejecute nuestras cuatro pruebas (véase más abajo).
10. Si los parches superan nuestras pruebas, los desplegamos en producción.
11. Si las pruebas no tienen éxito, analizamos los registros para encontrar la causa del fallo, corregimos el problema y volvemos a repetir estos pasos hasta que los parches superan nuestras pruebas.

Los cuatro tipos de pruebas de KernelCare

Las pruebas exhaustivas son fundamentales para el éxito de las implantaciones, y sabemos que los errores afectan a nuestros clientes. Tenemos cuatro pruebas que se ejecutan simultáneamente en cada núcleo para garantizar que los parches no causen problemas críticos. 

Antes de desplegar cualquier parche, se somete a las siguientes pruebas automatizadas en función de la rapidez con que necesitemos estos parches en producción y del nivel crítico de la vulnerabilidad:

1. Aplicamos nuestros parches al núcleo en ejecución y luego lo desparchamos para probar las reversiones. Este proceso dura unos 10 minutos por núcleo.
2. Aplicamos nuestros parches y, a continuación, realizamos un subconjunto de pruebas del conjunto de pruebas del Linux Test Project (LTP) que añaden cierta carga al sistema operativo. Esta prueba dura unos 15 minutos por núcleo.
3. Lo mismo que 2. pero con el conjunto completo de pruebas LTP. Esta prueba es un proceso minucioso de 4 horas por núcleo que incluye:
1. Prueba de estrés del sistema de archivos
2. Prueba de E/S de almacenamiento
3. Prueba de resistencia de gestión de memoria
4. Prueba de esfuerzo de la CIP
5. Prueba del programador
6. Comanda las pruebas de verificación funcional
7. Pruebas de verificación funcional de llamada al sistema
8. etc
4. LTP extra. Esta prueba es una prueba de alta carga con parcheado y desparcheado continuo durante toda la prueba. Esta prueba dura 4 horas por núcleo.

Conclusión

Para ofrecer a nuestros clientes un servicio de parches estable y fiable -en el que puedan confiar e incluso olvidar que existe en sus servidores-, probamos cada parche en cada núcleo afectado durante al menos 4 horas/núcleo y sólo publicamos parches cuando estamos 100% seguros de que no perturbarán sus operaciones. Con KernelCarelos administradores no sólo pueden parchear sus sistemas sin necesidad de reiniciar, sino que también saben que estos parches se prueban exhaustivamente antes de su instalación.