Por qué debería automatizar las actualizaciones del núcleo de Linux

El software es complejo y cambia constantemente. Los errores son inevitables. Antes de la era de Internet, los errores eran fallos que había que corregir. Ahora son oportunidades, una de las formas que tienen los hackers de acceder sin autorización a los sistemas. La industria de la ciberseguridad se nutre de esta amenaza. Sus productos "defienden" y "protegen", pero no pueden tapar una simple laguna de seguridad: la explotación de vulnerabilidades que persisten en sistemas operativos y aplicaciones obsoletos y sin parches.

Este artículo repasa los antecedentes de este problema y ofrece consejos para solucionarlo utilizando paquetes de actualización desatendida para Ubuntu, Red Hat y Fedora, y soluciones de parcheado en vivo de KernelCare, Kgraft, Ksplice y Livepatch.

Cambio con esteroides

Hay una crisis silenciosa en el desarrollo de software.

Las cosas nunca han ido tan bien para los programadores. Su trabajo llega a tanta gente en casi todos los ámbitos de la vida. Las oportunidades para los programadores son estratosféricas y las posibilidades para nosotros, los usuarios, alucinantes.

Paradójicamente, para los programadores las cosas nunca han sido tan difíciles. La presión sobre ellos para que aprendan y hagan cosas nuevas nunca ha sido mayor. Mucho antes de cortar una sola línea de código, pasan horas leyendo y aprendiendo lenguajes, releyendo y volviendo a aprender cuando cambian las API y los comportamientos. Los lenguajes tienen incluso su propio "hit parade" mensual (www.tiobe.com), y los programadores que se presentan a los gigantes tecnológicos necesitan al menos seis idiomas en su currículum para tener posibilidades de entrevista. Atrás quedaron los días en que se conseguía un trabajo con un K&R y una hoja de trucos de SQL fotocopiada.

Ya no hay héroes

Y ya no hay héroes. Ahora, todos trabajan en equipo y se basan en el trabajo de los equipos. Sus miembros están lejos y son flexibles, están conectados y son entusiastas, pero pocos se conocen en persona. A partir de ellos, el código fluye en cascada hacia otros equipos que lo prueban, lo amplían y hacen todo lo posible por romperlo.

Todo esto lleva su tiempo, pero no hay tiempo, porque usted y yo estamos esperando lo nuevo, la siguiente iteración, la última actualización. Lo recibimos en forma de código que viene fusionado en una gran bola de chicle de esfuerzo humano concentrado llamada versión. Es el producto de mucha gente escribiendo código en muchos lenguajes. Es el cambio con esteroides, y el premio es el progreso.

Continúe leyendo: Facilitar el cumplimiento con una gestión de parches más rápida

Lo bueno, lo malo y lo adorable

Cómo la complejidad del software se convierte en riesgo.

En primer lugar, convengamos en que el progreso es bueno. Si el progreso es bueno, el cambio también lo es. Pero el cambio significa riesgo, y eso no es bueno, porque el código que siempre cambia tiene un mayor riesgo de errores. Antes de la era de Internet, los errores eran sólo errores. Aunque los riesgos acechaban en errores no intencionados y no detectados, había un límite a su alcance y efecto. En la era de Internet, ya no hay límites.

Con la explosión de la interconectividad entre aplicaciones, los fallos ya no son un mero inconveniente. Se han convertido en una oportunidad para una especie de programadores cuyo talento iguala al de los que hacen el código. Se trata de programadores que intentan romper el código. Tienen varios nombres y trabajan con varios fines. El nombre más popular es hackers, y sus objetivos, múltiples.

Veo tres tipos de hackers: los buenos, los malos y los mimosos. Los buenos son la comunidad investigadora activa, que sondea constantemente software nuevo y antiguo en busca de vulnerabilidades. Los mimosos lo hacen por diversión y emoción, por reputación y educación. Los malos lo hacen por todas estas razones, pero sobre todo por dinero, o su equivalente, los datos.

El punto ciego de la ciberseguridad

El software obsoleto es una laguna de ciberseguridad.

La ciberseguridad es un sector amplio y en expansión. Hay una plétora de productos entre los que elegir, y todos ayudan en cierta medida a proteger los sistemas informáticos de infiltraciones y explotaciones ilegales. Estos productos tienen escáneres de malware y virus, cortafuegos de varios tipos, verificadores de inicio de sesión y contraseñas y rastreadores de datos, diferentes componentes, cada uno diseñado para defenderse contra un método diferente, o vector, de ataque.

Pero tienen un punto ciego. Ni siquiera el producto de seguridad más sofisticado puede proteger totalmente un sistema que no está actualizado. Debería ser sencillo mantener el software siempre actualizado, pero no lo hacemos. Lo demuestran los numerosos incidentes registrados de sistemas comprometidos por vulnerabilidades en software obsoleto.

Así que preguntémonos: "¿Por qué se desactualizan los sistemas?".

La respuesta más obvia es porque se lo permitimos. Instalar y actualizar sistemas lleva tiempo y esfuerzo. Hay que programar tiempos de inactividad, iniciar sesión, ejecutar comandos o utilizar una interfaz gráfica de usuario. Es engorroso y aburrido. Puede que tengamos que repetirlo muchas veces al año en decenas o incluso cientos de servidores.

La tarea es más fácil con herramientas de gestión de la configuración de servidores. Así, todos los servidores se actualizan al mismo tiempo. Pero las buenas cuestan dinero y las gratuitas requieren tiempo de aprendizaje. Podemos programarlo, pero eso requiere conocimientos de programación que algunos no tenemos.

La perspectiva Linux

Linux no puede autoactualizarse como otros sistemas operativos.

Hasta ahora, todo lo dicho se aplica a la mayoría de las plataformas informáticas contemporáneas, convencionales y no móviles. Quiero centrarme ahora en un subconjunto de ellas, la comunidad de servidores Linux. Linux ha evolucionado de forma diferente a otros sistemas operativos. Comenzó como un hobby, basándose en MINIX. Creció gracias al esfuerzo de la comunidad, en su mayoría no comercial. A medida que aumentaba el número de plataformas Linux activas, también lo hacía su atractivo para la comunidad de hackers. Otro atractivo fue la popularidad de Linux como plataforma de alojamiento barata y flexible. A los hackers les encanta: Un único servidor suele alojar cientos de sitios web, y un sitio pirateado puede convertirse en una puerta de acceso a otros sitios del mismo servidor.

Linux cuenta con una gran reserva de software libre y bien respaldado, y una gran cantidad de distribuciones activas, tales son los beneficios del desarrollo de la comunidad de código abierto. Las desventajas son que las características evolucionan lentamente, posiblemente debido al fenómeno de diseño por comitéposiblemente porque la mayoría de los desarrolladores que contribuyen trabajan a cambio de nada.

Por ejemplo, Linux aún carece de una herramienta de gestión de software completamente integrada, automática y autoactualizable, aunque hay formas de hacerlo, algunas de las cuales veremos más adelante. Incluso con ellas, el núcleo del sistema no puede actualizarse automáticamente sin reiniciar.

Y aquí vemos otra razón por la que los sistemas se desactualizan con tanta facilidad: el afán por evitar tiempos de inactividad. Los administradores de servidores pueden decidir dar prioridad a sus usuarios activos y aplicaciones críticas, y posponer la instalación de parches que requieren un reinicio del sistema.

El susurro de un paranoico

Pero de todas las razones, hay una que los administradores de sistemas prefieren no decir en voz alta. Es el miedo a que el servidor no vuelva a arrancar, a que un parche rompa algo. No siempre se reconoce porque huele a paranoia y es imposible de probar.

Creo que es una preocupación legítima. Al fin y al cabo, un parche del kernel es un cambio en el núcleo del sistema operativo. Existen parches mal escritos y no es raro que los parches rompan o cambien sutilmente un sistema. Ya se trate de un cambio en el rendimiento o en la funcionalidad, para la mayoría de los administradores que se ocupan de los sistemas vivos, ninguno de los dos es aceptable.

Cerrar la brecha de seguridad de Linux

La seguridad mejora al automatizar las actualizaciones de Linux.

Usted mismo puede actualizar automáticamente las aplicaciones y los núcleos de Linux combinando un programa de programación, como croncon el mantenedor de paquetes de su plataforma, como por ejemplo yum, apto dnf. Algunos proveedores de Linux lo han hecho creando paquetes que hacen actualización desatendida para usted. Y como todo en Linux, cada sabor lo hace de manera diferente.

• Debian y Ubuntu tienen la unattended-upgrades paquete.
• Fedora tiene dnf-automatic para actualizaciones automáticas.
• Red Hat ofrece yum-cron (sólo disponible a través del canal complementario, es decir, de pago).

Sin embargo, cualquiera que los utilice sin reconfigurar los ajustes es probable que reciba una descarga como ésta en algún momento:

The computer needs to restart to finish installing updates.

Esto se debe a que, a diferencia de las aplicaciones, las actualizaciones desatendidas no significan que puedas instalar actualizaciones del kernel sin reiniciar.

Y ahí está la laguna de seguridad. Nadie quiere reiniciar arbitrariamente servidores que están en uso activo. Por eso los kernels suelen excluirse en las configuraciones de actualización desatendida. Pero los kernels obsoletos son kernels vulnerables, y los kernels vulnerables son propensos a ser explotados.

Related post: 5 malas razones para actualizar tu kernel

Eslabones perdidos y lagunas

La respuesta a este dilema es el live patching. Es una forma de mantener los kernels actualizados a los últimos parches de seguridad sin necesidad de sufrir un reinicio o tolerar tiempos de inactividad. Es el eslabón perdido en la automatización completa de su estrategia de actualización del sistema Linux.

Al igual que ocurre con las actualizaciones desatendidas, cada proveedor de Linux hace el live patching de forma diferente. Además, hacerlo gratis no es fácil; el live patching se volvió demasiado útil para evitar su comercialización.

Para Ubuntu, el servicio Livepatch de Canonical instalará los parches de seguridad del núcleo de Linux sin reiniciar. Red Hat lanzó Kpatch, y SUSE Kgraft, ambos con el mismo propósito, y los dos proveedores solo se pusieron en acción cuando Oracle compró Ksplice, solo para retirar el soporte a todo lo que no fueran sus propias versiones. Un improbable salvador surgió en 2014 cuando KernelCare se unió al mercado, apoyando a todos los principales proveedores, y núcleos tan antiguos como 2.6.18.

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

Conclusión

Automatice las actualizaciones de Linux por razones de seguridad, no de comodidad.

Linux se beneficia y sufre por la forma en que se desarrolla. Ninguna preocupación por la ciberseguridad puede resolver el problema de las vulnerabilidades sin parches.

Aunque existen soluciones para la actualización automática de aplicaciones, el kernel sigue siendo el punto débil: una actualización del mismo casi siempre implica un reinicio.

La aplicación de parches en vivo llena el vacío existente en las estrategias de actualización automática. Debería considerarlo una parte esencial de su estrategia de seguridad de servidores Linux, no solo una comodidad.