TuxCare ELS: seguir utilizando versiones antiguas de Linux de forma controlada

Qué aporta TuxCare a ELS

Cuando finaliza el mantenimiento regular de una distribución de Linux, no es seguro que un servidor siga recibiendo actualizaciones de seguridad a través de las fuentes de paquetes habituales. Esto resulta especialmente problemático cuando una aplicación especializada sigue dependiendo del entorno anterior. El soporte ampliado puede proporcionar tiempo para una transición controlada, sin tener que revertir el fin del soporte técnico habitual.

TuxCare Asistencia técnica durante todo el ciclo de vida del producto for OS ofrece actualizaciones de seguridad y correcciones de errores seleccionadas para distribuciones antiguas compatibles. Según el fabricante, la oferta incluye el núcleo y una selección de paquetes importantes que varía en función de la distribución. No instala ninguna nueva versión principal de Linux: el servidor mantiene la versión de distribución que tenía anteriormente y recibe mantenimiento adicional para los componentes cubiertos.

Para la empresa, esto puede suponer una importante solución provisional: en lugar de tener que cambiar inmediatamente una aplicación incompatible, se puede preparar la migración mientras se instalan las correcciones de seguridad disponibles para los paquetes cubiertos. Sin embargo, es imprescindible que los paquetes realmente necesarios, la arquitectura y la oferta elegida sean compatibles entre sí.

El Cubierta para paquetes No debe equipararse con la seguridad de todo el servidor. Una aplicación instalada por uno mismo, una extensión o un servicio procedente de otra fuente de paquetes puede quedar fuera del ámbito del sistema operativo. Además, los errores de configuración y los servicios a los que se puede acceder innecesariamente no desaparecen con una suscripción; siguen debiendo revisarse y protegerse.

El nivel de gravedad también es relevante en el caso de los paquetes cubiertos: TuxCare prevé correcciones de seguridad para riesgos altos y críticos a partir de un CVSS de 7. En el caso de los riesgos medios, con un CVSS entre 4,0 y 6,9, según el proveedor, se pueden considerar parches si no hay medidas de mitigación disponibles y existe suficiente demanda por parte de los clientes. TuxCare se reserva además el derecho a ofrecer una medida de mitigación en lugar de una corrección directa del código. Por lo tanto, que un paquete esté cubierto no significa que se vaya a corregir todas las vulnerabilidades conocidas que contenga.

Por lo tanto, lo decisivo no es solo si la distribución figura en una lista de soporte. Para Seguridad en Linux identifica qué componentes se utilizan en el servidor concreto, si hay parches disponibles y si estos están realmente instalados. ELS complementa el proceso de aplicación de parches, pero no sustituye ni al inventario ni a un plan de migración.

Comprobar la cobertura y el inventario de servidores

Antes de elegir TuxCare ELS, hay que... Inventario del servidor. Anota la distribución y la versión exacta, la arquitectura y el núcleo en ejecución. Documenta también las fuentes de paquetes configuradas y los servicios accesibles públicamente o desde otras redes. De este modo, se puede comparar la lista del fabricante con el sistema real, en lugar de limitarse a marcar el nombre de la distribución.

En el caso de un servidor web antiguo, por ejemplo, el inventario debe incluir el paquete del servidor web, las bibliotecas criptográficas, el entorno de ejecución de PHP y las extensiones de PHP necesarias. Anota en cada caso de dónde procede el paquete y qué versión está instalada. Una extensión procedente de un repositorio externo puede tener condiciones de mantenimiento diferentes a las de un paquete de la distribución original.

Compara estos componentes uno por uno con la lista actual de paquetes de la distribución en cuestión. Comprueba también la arquitectura y las condiciones de la oferta prevista. El hecho de que una distribución sea compatible no significa que ELS for OS cubra automáticamente todos los paquetes instalados en ella o todas las versiones de un entorno de ejecución. Incluso en el caso de los paquetes cubiertos, el tratamiento de las vulnerabilidades concretas depende, entre otras cosas, de su gravedad.

Es muy fácil pasar por alto los programas compilados por uno mismo y los entornos de ejecución instalados por separado. Una imagen de contenedor también incluye sus propios componentes: el mantenimiento del sistema operativo anfitrión no garantiza que los paquetes de la imagen estén actualizados. Para estos componentes, necesitas una comprobación específica y un proceso de actualización propio.

ELS para OS y ELS para aplicaciones Son ofertas independientes. La posibilidad de mantener una versión antigua de PHP mediante una oferta adicional depende, entre otras cosas, de la versión, el formato del paquete, la arquitectura y la forma de adquisición. En el artículo sobre CloudLinux Alt-PHP y sus aspectos de seguridad; por lo tanto, esto no está cubierto por una suscripción al sistema operativo de TuxCare.

Clasificar correctamente los plazos de asistencia técnica

La fecha de finalización del soporte solo tiene sentido si se considera junto con la fase de mantenimiento correspondiente. El fin del mantenimiento habitual no siempre implica que todas las ofertas de pago o complementarias finalicen al mismo tiempo. Por lo tanto, para tomar una decisión, debes tener en cuenta tanto el periodo como los paquetes, las arquitecturas y las condiciones contractuales que están cubiertos.

La documentación de TuxCare disponible actualmente indica, para los sistemas operativos compatibles, un tiempo de ejecución garantizado de ELS de 25 años a partir de la fecha de finalización del soporte técnico inicial indicada en cada caso. A modo de ejemplo, menciona el 30 de junio de 2049 para CentOS 7 y el 31 de mayo de 2048 para Ubuntu 18.04. Se trata de datos facilitados por el proveedor sobre el periodo de soporte técnico, no de una garantía para todas las aplicaciones instaladas.

En el caso de Ubuntu 18.04, Canonical distingue varias fases: el soporte estándar finalizó en mayo de 2023; Ubuntu Pro seguirá disponible hasta mayo de 2028. El resumen actual indica mayo de 2033 como fecha límite para la cobertura adicional de versiones heredadas. Estas ofertas no se pueden comparar únicamente en función de sus fechas de finalización, ya que también hay que tener en cuenta el alcance del paquete, la arquitectura y las condiciones del contrato para cada servidor concreto.

Por ejemplo, en el caso de un servidor web de Ubuntu, comprueba si los paquetes necesarios están realmente incluidos en el nivel de mantenimiento seleccionado y cómo se integran las actualizaciones en el proceso operativo actual. Un plazo más largo no sirve de mucho si un tiempo de actividad crítico o una ampliación quedan fuera del alcance acordado.

Los plazos mencionados se basan en páginas web dinámicas de los fabricantes, según el estado de las fuentes consultadas a fecha de 4 de noviembre de 2026. No es posible verificar de forma retroactiva en todos los casos si toda la información actual ya estaba vigente en esa fecha de referencia. Por lo tanto, comprueba de nuevo los plazos y las listas de paquetes antes de la publicación o de la formalización del contrato y ten en cuenta el Estado de las consultas Sin duda. Ni siquiera un compromiso de soporte a largo plazo garantiza que el servidor sea seguro en su conjunto.

Configuración práctica de un servidor CentOS 7

Supongamos que un servidor web con CentOS 7 tiene que seguir ejecutando temporalmente una aplicación especializada más antigua. Antes de que TuxCare ELS Al seleccionarlo, se registra el estado real del sistema y las dependencias de la aplicación. Lo decisivo no es solo si CentOS 7 es compatible, sino si se incluyen los componentes necesarios para la arquitectura existente.

Puedes ejecutar los siguientes comandos en el servidor desde un shell. Estos comandos muestran el identificador de la distribución, la arquitectura del equipo y la versión del kernel en ejecución; no modifican ni los paquetes ni las fuentes de los paquetes. Anota los resultados en el inventario del servidor y compáralos con la guía actual de CentOS 7.

cat /etc/os-release
uname -m
uname -r

Completa esto Inventario del servidor las fuentes de paquetes configuradas, las versiones de paquetes instaladas y los servicios accesibles públicamente. En el caso de un servidor web, esto incluye, en particular, el paquete del servidor web, las bibliotecas de cifrado, el entorno de ejecución de PHP y las extensiones. Anota también qué componentes proceden de fuentes externas o se han compilado por tu cuenta; no deben considerarse parte de la cobertura del sistema operativo sin haber sido comprobados.

Para CentOS 7, TuxCare indica como requisitos una clave de licencia válida, acceso de root y conexiones HTTPS. Además, la guía distingue según la arquitectura: para aarch64 e i686 describe la cobertura del espacio de usuario, mientras que el parcheo en vivo del núcleo solo se describe para x86_64. Esta restricción se aplica a la guía de CentOS 7 y no puede extrapolarse de forma general a otras distribuciones.

A continuación, comprueba cada paquete necesario para la aplicación específica con la lista actual y aclara las lagunas restantes con el proveedor correspondiente. Un kernel compatible y en funcionamiento tampoco garantiza por sí solo que la aplicación esté cubierta ni que todas las actualizaciones disponibles estén instaladas y activas.

Configurar el repositorio e implementar las actualizaciones

Planifica la instalación como un sistema controlado Cadena de control: En primer lugar, la licencia, la arquitectura y los paquetes necesarios deben ser compatibles. A continuación, comprueba si el servidor puede acceder a través de HTTPS a los destinos necesarios para su distribución. Para el registro y la configuración del repositorio, utiliza las instrucciones originales y actualizadas específicas de la distribución, ya que los requisitos y las direcciones de destino pueden cambiar.

En el caso de CentOS 7, TuxCare describe cómo registrar el sistema, añadir el repositorio de paquetes y una clave PGP. El repositorio permite, a continuación, obtener los paquetes adecuados; sin embargo, no instala automáticamente todas las actualizaciones disponibles. Tras la configuración, comprueba si el repositorio se ha integrado correctamente y si el gestor de paquetes ofrece las actualizaciones correspondientes.

Es necesario tener en cuenta en la planificación la existencia de un proxy o de reglas restrictivas del cortafuegos de salida. En el caso de varios sistemas, podría considerarse la posibilidad de utilizar un servidor espejo local, previa consulta con TuxCare. No copies ciegamente las direcciones de destino de una sección general de preguntas frecuentes: compáralas antes de su publicación con las instrucciones actuales de la distribución elegida y la ruta de funcionamiento prevista.

Prueba primero las actualizaciones disponibles en un entorno de prueba lo más similar posible a la aplicación de negocio. Comprueba el inicio de la aplicación, los procesos empresariales importantes y las interfaces. A continuación, se lleva a cabo la autorización operativa y la instalación en el sistema productivo; documenta las versiones de los paquetes, la fecha y el resultado, en lugar de dar por concluido el proceso únicamente con la activación satisfactoria en el repositorio.

Si una actualización esperada aún no está disponible, comprueba también el Estado de la implementación. TuxCare distribuye las actualizaciones de forma escalonada para varias plataformas; tras su publicación en el repositorio estable, esto puede tardar hasta 14 días más. En caso necesario, el proveedor describe una solución alternativa: utilízala únicamente siguiendo las instrucciones actuales para la distribución correspondiente y la versión concreta, así como tras la autorización operativa. La duración del despliegue no implica un plazo total garantizado para un parche.

Además, ten preparada una vía de contingencia y un intervalo de tiempo adecuado para el mantenimiento. Las claves de licencia no deben incluirse en comandos de ejemplo publicados, tickets o registros sin proteger. Para el registro concreto, debes seguir las instrucciones actuales del fabricante y facilitar los datos de acceso únicamente a través de los procedimientos previstos para ello.

Comparación de alternativas de mantenimiento

La elección entre TuxCare ELS y un servicio de mantenimiento ampliado del fabricante depende del inventario real de paquetes y de las condiciones del contrato. La tabla ofrece ejemplos para la preselección, no una garantía general para todas las arquitecturas o todos los paquetes. La fecha de referencia de la investigación es el 4 de noviembre de 2026; los datos dinámicos del fabricante y las listas de paquetes deben volver a verificarse antes de su publicación.

En el caso de Ubuntu 18.04, el soporte estándar finalizó en mayo de 2023. Canonical indica que el soporte para Ubuntu Pro se prolongará hasta mayo de 2028 y, en su resumen actual sobre la cobertura adicional para versiones heredadas, hasta mayo de 2033. TuxCare indica actualmente el 31 de mayo de 2048 como fecha de finalización del ELS para Ubuntu 18.04. Estas fechas se refieren a diferentes ofertas; una fecha de finalización posterior no implica automáticamente la cobertura adecuada del paquete.

Por eso, compara el Alcance del mantenimiento para cada paquete necesario y la arquitectura que se utilice realmente. En el caso de Ubuntu, son especialmente relevantes los componentes «Main» y «Universe», así como las condiciones para «Pro» y un posible complemento «Legacy». Anota también cómo se pueden verificar las correcciones CVE disponibles y si los procesos de aprobación y actualización existentes se ajustan a la oferta.

En ambos ejemplos, el destino de la migración sigue siendo una decisión de planificación, no una característica del contrato de mantenimiento. Si la aplicación especializada aún no es compatible con una plataforma soportada, una alternativa de mantenimiento adecuada puede proporcionar tiempo para realizar pruebas. Si ninguna de las ofertas cubre una dependencia crítica, esta laguna debe tratarse por separado antes de que sea responsable continuar con el funcionamiento.

Comprobar los avisos CVE y las adaptaciones a versiones anteriores

Si, tras una actualización, un escáner sigue detectando una vulnerabilidad, comprueba primero la distribución y la versión exactas, así como el nombre, la arquitectura y la versión instalada del paquete afectado. Averigua también de qué fuente de paquetes procede. Un resultado relativo a un paquete de la distribución no puede extrapolarse sin más a una aplicación compilada por uno mismo o a un paquete procedente de un repositorio externo.

La razón de las aparentes contradicciones puede ser un Retroportación ser: En este caso, se incorpora una corrección de seguridad a una versión anterior, sin que su número de versión «upstream» visible coincida con el de la última publicación. Por lo tanto, un número de versión anterior por sí solo no demuestra ni que el paquete sea vulnerable, ni que el aviso del escáner sea necesariamente erróneo.

Compara el CVE concreto y la versión del paquete instalado con la información correspondiente a tu distribución en el rastreador de CVE de TuxCare. „In Testing“ significa que aún se está probando una corrección; en „In Rollout“, se distribuye a través de los repositorios de Rollout. Por el contrario, „Released“ indica que ya está disponible para todos los usuarios. Incluso en ese caso, debes comprobar si realmente se ha instalado la versión adecuada; „Not Vulnerable“ significa que la versión de TuxCare no se ve afectada.

Si falta una actualización esperada en el gestor de paquetes, comprueba, además de la fuente del paquete y la versión, el Estado de la implementación. En el caso de varias plataformas, la distribución escalonada tras la publicación en el repositorio estable puede tardar hasta 14 días adicionales. Solo se podrá aplicar una posible solución alternativa si se sigue la documentación original vigente relativa a la distribución y la versión, y se cuenta con la autorización operativa para incorporarla al proceso; esto no garantiza un plazo total de aplicación del parche.

A continuación, examina la base de datos y el análisis del escáner. TuxCare proporciona datos OVAL para una serie de productos ELS; debes comprobar por ti mismo si tu herramienta utiliza los datos adecuados para el sistema concreto y los interpreta correctamente. Documenta la versión del paquete, el estado del CVE y la fecha y hora del análisis. Si la comparación sigue sin estar clara, sigue tratando el hallazgo como pendiente y acláralo con los servicios especializados competentes o con el proveedor.

Planificar la aplicación de parches y los reinicios

La configuración de un repositorio es el punto de partida del proceso de aplicación de parches, no su final. Establece quién se encargará de comprobar periódicamente si hay actualizaciones disponibles, quién autorizará su instalación y cómo se detectarán las actualizaciones fallidas. Para ello, compara las versiones de los paquetes realmente instalados con las actualizaciones disponibles y registra las discrepancias para cada sistema.

Siempre que sea posible, prueba primero las actualizaciones en un sistema de pruebas similar que cuente con la misma aplicación y las fuentes de paquetes pertinentes. Comprueba especialmente el inicio, el inicio de sesión y las interfaces importantes de la aplicación especializada. Solo tras la aprobación operativa debes implementar los paquetes de forma controlada; el resultado y los posibles errores deben incluirse en el informe de instalación.

Además, ten en cuenta la posibilidad de que se produzcan cambios Ventana de mantenimiento. Incluso tras una actualización de paquetes realizada con éxito, los procesos en ejecución pueden seguir utilizando bibliotecas antiguas hasta que se reinicien. Es posible que las aplicaciones también deban reiniciarse; en caso de cambios en el núcleo, puede ser necesario reiniciar el sistema. Tras el reinicio, comprueba tanto el funcionamiento de los servicios como el estado esperado de los paquetes y del sistema.

KernelCare Live Patching es un producto complementario y debe distinguirse de las actualizaciones periódicas de paquetes de ELS. Puede aplicar correcciones compatibles del núcleo sin interrumpir el funcionamiento del sistema, pero no sustituye ni a todas las actualizaciones ni a todos los reinicios de servicios o del sistema. Comprueba el producto, la distribución y la arquitectura: para CentOS 7, TuxCare documenta el parcheo en vivo del kernel solo para x86_64. En el artículo sobre KernelCare Patch Feed.

La edición de uname -r Muestra el kernel actual, pero no el estado completo de las actualizaciones del servidor. Por ejemplo, un paquete de kernel instalado puede no activarse hasta después de reiniciar el sistema; por el contrario, el resultado no indica si las bibliotecas y las aplicaciones se han actualizado y reiniciado.

Elegir entre una solución provisional o la migración

Para determinar si TuxCare ELS es suficiente para un servidor concreto, hay que tener en cuenta sus componentes y riesgos reales. Compara los paquetes necesarios con la cobertura disponible e identifica las brechas existentes en las aplicaciones, los entornos de ejecución y el software de terceros. ELS for OS cubre una selección que depende de la distribución; el soporte del sistema operativo no implica el mantenimiento de todas las aplicaciones que se ejecutan en él.

Comprueba también si quedan vulnerabilidades CVE en los paquetes cubiertos. Según TuxCare, los riesgos medios solo se tienen en cuenta para un parche si se cumplen requisitos adicionales; además, el proveedor puede ofrecer una medida de mitigación en lugar de una corrección directa del código. Por lo tanto, evalúa para cada vulnerabilidad concreta si hay disponible una corrección o una medida de mitigación y si los riesgos restantes son aceptables para tu empresa.

Una solución provisional puede resultar adecuada si, por el momento, una aplicación especializada sigue vinculada a la plataforma antigua y los riesgos restantes son controlables. Sin embargo, compara también las opciones de mantenimiento que ofrecen los fabricantes: en el caso de Ubuntu 18.04, dependiendo del alcance necesario, se pueden considerar como alternativas Ubuntu Pro y, en su caso, el complemento Legacy. Comprueba los paquetes, la arquitectura y las condiciones del contrato, en lugar de limitarte a la fecha de vencimiento correspondiente.

En el caso de un servicio accesible al público con una aplicación desactualizada o un periodo de vigencia sin cubrir, el ELS por sí solo puede resultar insuficiente. Por lo tanto, limita el acceso a las redes y servicios que realmente se necesiten, elimina las autorizaciones innecesarias y controla los accesos administrativos. Esto Limitación de la red Reduce la superficie de ataque, pero no sustituye a las actualizaciones de seguridad que faltan.

Limita la duración de la continuidad del servicio y establece un objetivo de migración con los responsables y una fecha verificable. Planifica pruebas de las aplicaciones en la plataforma de destino, la transferencia de datos y la comprobación de todas las interfaces relevantes. Un plan de contingencia debe establecer en qué condiciones se interrumpirá la migración y cómo se volverá al funcionamiento anterior.

Revisa el plan periódicamente teniendo en cuenta las nuevas vulnerabilidades de los paquetes, los cambios en las dependencias de los fabricantes y los costes operativos. Si los componentes necesarios ya no se pueden mantener o no es posible limitar suficientemente los accesos necesarios, es posible que no baste con una simple prórroga del mantenimiento del sistema operativo. En ese caso, habrá que volver a evaluar la migración, la sustitución de la aplicación o el cierre controlado del servicio.