ClickCease ¿Reiniciar o no reiniciar? Esa es la cuestión para muchos administradores de sistemas - TuxCare

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

¿Reiniciar o no reiniciar? Esa es la cuestión para muchos administradores de sistemas

12 de noviembre de 2020 - Equipo de RRPP de TuxCare

¿Reiniciar o no reiniciar? Esa es la cuestión para muchos administradores de sistemas.Un ciclo de reinicio del servidor es un nombre genérico que se da al proceso de reiniciar una flota de servidores en una organización. Esto puede deberse a varios factores, pero a menudo se debe a que los parches y las actualizaciones requieren un reinicio, ya que se dirigen a un componente crítico del sistema operativo o a alguna biblioteca compartida que utilizan varios componentes o programas. El número de servidores que habrá que reiniciar influye directamente en la duración de la operación y en el riesgo asociado. Cuantos más servidores haya que actualizar, más difícil será el proceso de planificación y ejecución.

Para ofrecer a las empresas una forma de gestionar estas actualizaciones de seguridad sin reiniciar, se creó el parcheado en vivo. La principal ventaja de este método es que no requiere reiniciar el sistema, lo que reduce en un 60% las tareas típicas del ciclo de aplicación de parches. Aún así, muchas empresas siguen trabajando con ciclos de reinicio en lugar del método live patching. ¿Hay alguna razón para ello? Aquí examinaremos el problema.

Contenido:

  1. Riesgo de actualizar. Riesgo de no actualizar:
    Equifax: Un cuento con moraleja
    ¿El Live Patching ralentiza los sistemas?
  2. Reiniciar frente a no reiniciar
  3. El ganador: Trayectoria sin reinicio
  4. Conclusión

 

Riesgos de la actualización. Riesgos de no actualizar.

Riesgos de la actualización. Riesgos de no actualizar.

Cuando actualizas tu Kernel, siempre hay nuevos riesgos potenciales que conlleva, que es una de las razones por las que algunos pueden no haber adoptado todavía las actualizaciones de parches en vivo. Si sus servidores ya son estables, tienen una velocidad decente y no necesitan nuevas funcionalidades, puede que no quieran arriesgarse al tiempo de inactividad del servidor necesario para aplicar los parches. Aunque estas puedan parecer razones perfectamente razonables para no aplicar un parche, hay una razón por la que debería hacerlo, incluso si tiene una o más de estas razones: la seguridad.

En cuanto se anuncia un nuevo parche para el Kernel, los hackers empiezan a buscar formas de explotar la vulnerabilidad que se está parcheando. Si nunca actualizas ese parche, siempre dejarás una puerta trasera abierta para que los hackers entren en tus sistemas. Esta es precisamente la razón por la que todavía encontramos hackers explotando la vulnerabilidad HeartBleed hoy en día, a pesar de que el parche para solucionarlo se publicó en 2014. Es una de las vulnerabilidades más devastadoras y, sin embargo, algunos sistemas todavía no han aplicado el parche para quitar esta puerta trasera a los hackers.

 

Equifax: Un cuento con moraleja

Equifax: Un cuento con moraleja

Según una encuesta de Ponemon, el 60% de los encuestados afirman que una o más de las infracciones que sufrieron sus organizaciones el año pasado se debieron a una vulnerabilidad conocida que tiene un parche para solucionarla; sin embargo, nunca aplicaron el parche. Aproximadamente el 88% afirma que, antes de poder aplicar un parche, tienen que coordinarse con otros departamentos de su organización, lo que puede retrasar la aplicación del parche hasta 12 días. Cuanto mayor sea el retraso, más tiempo tendrán los piratas informáticos para encontrar la puerta trasera de su sistema.

La brecha de Equifax 2017 es un buen ejemplo de una vulnerabilidad que tenía un parche que no se aplicó. Equifax conocía la vulnerabilidad Apache Struts (CVE-2017-5638), pero no parcheó el sistema. El CEO de Equifax en ese momento dijo que no habían encontrado la vulnerabilidad en sus escaneos del sistema, por lo que el parche no se había aplicado como se suponía que debía hacerse. Al no aplicarse el parche, 145,5 millones de estadounidenses sufrieron el robo de sus datos. Si hubieran utilizado un sistema de parcheo en tiempo real, esta filtración de datos podría haberse evitado.

 

¿El Live Patching ralentiza los sistemas?

¿El Live Patching ralentiza los sistemas?

Algunos pueden optar por no cambiar a live patching porque creen que las actualizaciones en directo ralentizarán sus sistemas. ralentizarán sus sistemase incluso una pequeña ralentización puede acarrear problemas a una organización. Hay varias cosas que pueden ralentizar un sistema, incluidas las propias vulnerabilidades y el uso de parches temporales en lugar de persistentes.

Con la aplicación temporal de parches, las actualizaciones se aplican al servidor, pero hay que reiniciarlo para aplicar los parches por completo. Además, los parches se apilan unos sobre otros y pueden empezar a ralentizar el sistema por sí solos. Con la aplicación persistente de parches en vivo, todo se hace sin necesidad de reiniciar ni ralentizar el sistema.

 

Reiniciar frente a no reiniciar

Reiniciar frente a no reiniciar

Para comparar el parcheado en vivo y el parcheado regular con reinicios, debemos tener en cuenta varios aspectos, ya que la comparación cambia en función del tipo de sistema que estemos analizando.

Servidores físicos: En el caso de los servidores físicos, una operación de reinicio siempre tarda al menos unos minutos en producirse debido a la operación de autocomprobación de encendido (POST) que se realiza para comprobar los componentes de hardware. En este caso, siempre es más rápido y eficaz realizar la aplicación de parches en vivo, ya que se tarda menos tiempo y la disponibilidad del servicio es mayor. Este es el caso típico en el que la aplicación de parches en vivo con KernelCare Enterprise es siempre mejor en todos los aspectos.

Servidores virtualizados gruesos: Para los servidores virtualizados gruesos, el tiempo de reinicio es un factor menor, pero también implica cierto tiempo de inactividad al realizar parches y reinicios regulares. Esto tiene un efecto dominó en otros sistemas, afecta a la redundancia de los servicios prestados, requiere una ventana de mantenimiento y tiene más impacto que la aplicación de parches en vivo.

Servidores virtualizados delgados: En los sistemas virtualizados delgados, es donde las cosas podrían estar más equilibradas, porque reiniciar un contenedor es lo mismo que destruirlo y recrearlo, y ese es el caso de uso óptimo para los contenedores. Sin embargo, un contenedor comparte el kernel con el host donde se está ejecutando, por lo que parchear en vivo el kernel del host con KernelCare Enterprise significa que automáticamente parchea también los contenedores. Esto es mejor porque elimina la necesidad de desmontar el contenedor y volver a crearlo, por muy rápido o lento que sea.

Comparar servidores Tabla

Cuando se realiza esta operación en varios servidores, hay que hacerlo de forma que se mantenga la disponibilidad del servicio, y esto es más fácil de hacer si se dispone de muchos servidores. Esto significa que las organizaciones más grandes pueden hacerlo de forma más eficiente que las pequeñas, porque tienen más servidores redundantes. Aun así, incluso en el mejor de los casos de contar con servicios totalmente en contenedores, la aplicación de parches en vivo en los servidores anfitriones tiene menos impacto que la recreación de los contenedores con versiones actualizadas.

 

El ganador: Parchear sin reiniciar

El ganador: Parchear sin reiniciar

Como vimos con la brecha de Equifax y la continua explotación de la vulnerabilidad HeartBleed seis años después, la única forma de evitar brechas es aplicar parches rápidamente. Sin embargo, el tiempo de inactividad necesario para reiniciar un sistema puede dejarlo potencialmente vulnerable. La única solución es un sistema de aplicación de parches en vivo que no requiera un reinicio.

 

Conclusión

Cuando un sistema tiene 1.000 o más servidores, puede ser un reto mantenerlos todos actualizados por su cuenta, especialmente si tiene que coordinar el tiempo de inactividad entre departamentos. KernelCare Enterprise ofrece la aplicación de parches en tiempo real sin necesidad de reiniciar el sistema, por lo que nunca tendrá tiempo de inactividad y no dejará su sistema expuesto a vulnerabilidades sin parchear. Mantenga los servidores Enterprise siempre actualizados y protegidos frente a las filtraciones de datos con KernelCare Enterprise.

Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare 

 

 

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín