La necesidad de reiniciar retrasa la aplicación de parches en el kernel y hace que no cumpla la normativa

Parchear el kernel es un trabajo interminable. ¿Por qué? Porque Linux es el rey de los sistemas operativos. Pero es muy, muy complicado. La rama maestra del repositorio git del núcleo de Linux contiene más de 20.000.000 de líneas de código escrito por humanos. Esta complejidad hace que las vulnerabilidades sean inevitables. Cada año se producen cientos, algunas de ellas muy graves.

¿Cómo se combaten estas vulnerabilidades? Mediante la aplicación constante de parches al núcleo. Los proveedores de Linux proporcionan constantemente actualizaciones parciales del kernel. Algunos parches modifican una sola línea de código, mientras que otros añaden comprobaciones que faltan o cambian estructuras de datos o funciones. 

La cuestión es la siguiente: ahora mismo, para el 99% de las organizaciones, la aplicación de parches en el núcleo sólo puede hacerse de una manera: reiniciando los servidores. 

Pero los administradores de sistemas son (comprensiblemente) muy reacios a realizar este reinicio hasta que es absolutamente necesario. El reinicio puede ser un proceso lento y laborioso. Para minimizar el impacto negativo sobre los servicios en hora punta, suele hacerse a última hora de la noche, a menudo los fines de semana. Mientras se reinician los servidores, los sitios web que albergan se caen; los mensajes de error sustituyen a los sitios web bonitos y funcionales. E incluso después del reinicio, el rendimiento puede tardar en estabilizarse. A veces, los entornos nunca vuelven a funcionar correctamente después de un reinicio.

Debido a todo esto, los administradores de sistemas retrasan el reinicio y, por tanto, retrasan la aplicación de parches al kernel. Tienden a esperar hasta que los lanzamientos de parches se han acumulado hasta el punto en que ya no pueden ser ignorados. Agrupan las correcciones, lo que significa que las primeras pueden estar disponibles durante mucho tiempo antes de que se apliquen realmente. A veces, el intervalo entre la publicación del parche y su aplicación puede ser de semanas o incluso meses. 

Pero no realizar todos los parches del kernel lo antes posible es buscarse problemas. 

• En primer lugar, es peligroso. En un entorno de código abierto, en cuanto una vulnerabilidad del kernel se hace pública, pasa a ser de dominio público . Esto significa que los operadores de Linux la conocen, pero también los malos actores: hackers y otros atacantes digitales. Esto es doblemente cierto cuando es práctica común en la comunidad de ciberseguridad combinar el anuncio de una vulnerabilidad con la publicación de un estudio de caso detallado. Estos estudios de casos son muy útiles para quienes trabajan en seguridad; pero son igual de útiles para los hackers.
• En segundo lugar, retrasar la aplicación de parches en el kernel expone a las organizaciones al riesgo de incumplimiento. Las pólizas de seguro de errores y omisiones (E&O) de la mayoría de las empresas, y las cláusulas de sus contratos SLA, definen el cumplimiento de las mejores prácticas. Por lo general, según las mejores prácticas del sector, este periodo no supera el mes. Las presiones del reinicio hacen que las organizaciones tarden (mucho) más de un mes, por lo que incumplen sus pólizas de seguros. 

Reiniciar es un quebradero de cabeza, por eso la gente lo pospone todo lo que puede. Pero: si no tienes que reiniciar, no tienes por qué retrasar el parcheado del kernel. ¿Cuál es la solución? Parcheo del kernel en vivo, sin reinicio.

Con KernelCare, cuando hay un nuevo parche disponible para el núcleo activo, el agente lo descarga y lo aplica de inmediato. Con este sistema, las actualizaciones del kernel se aplican lo más rápidamente posible, protegiéndole de los malos actores y manteniendo su cumplimiento. Esto sucede sin que el kernel esté inactivo ni se interrumpa su funcionamiento. 

Pero en KernelCare tenemos 300.000 servidores que no han necesitado reiniciarse para aplicar parches al núcleo en cuatro años. KernelCare es sencillo, se instala en cinco minutos y se ejecuta en segundo plano sin que nadie tenga que pensar en ello.

Para obtener toda la información sobre por qué reiniciar sus servidores le hace inseguro y no cumple la normativa, y por qué es cuestión de tiempo que lo descubra por las malas, lea nuestro informe completo aquí.

Continúe leyendo:

Peligro de las vulnerabilidades del núcleo e importancia de los parches activos