Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Ubuntu incluye por defecto sólidas funciones de seguridad integradas: AppArmor, UFW y unattended-upgrades; sin embargo, la configuración predeterminada solo te protege si las configuras y mantienes de forma activa.
- La mayoría de los problemas de seguridad en Ubuntu se reducen a tres factores: núcleos sin parches, prácticas de seguridad deficientes en SSH y el uso de una versión LTS más allá de su fin de vida útil sin un plan definido.
- La aplicación de parches al núcleo en tiempo real permite aplicar correcciones críticas al núcleo sin necesidad de programar un reinicio, lo cual resulta fundamental para las cargas de trabajo que funcionan las 24 horas del día, los 7 días de la semana, en las que el tiempo de inactividad tiene un alto coste.
- El cifrado de discos, la supervisión de la integridad de los archivos y el registro de auditoría suelen omitirse en las configuraciones básicas, pero marcan una gran diferencia cuando surge algún problema.
Ubuntu se ejecuta en una gran parte de los servidores Linux del mundo, y esa popularidad es precisamente la razón por la que conviene tomarse en serio la seguridad de Ubuntu. Los atacantes van donde están sus objetivos. La buena noticia: Ubuntu te ofrece una base sólida desde el primer momento. La noticia no tan buena: esa base da por hecho que realmente lo configurarás, lo mantendrás actualizado y tendrás un plan preparado para cuando una versión LTS deje de recibir soporte.
Esta guía repasa las medidas de protección de las que ya dispones, dónde suelen surgir las amenazas reales y las pocas prácticas que realmente marcan la diferencia.
¿Qué es Ubuntu?
Ubuntu es una distribución de Linux basada en Debian y mantenida por Canonical, lanzada por primera vez en 2004. Hoy en día es uno de los sistemas operativos para servidores más utilizados del mundo. Es de código abierto, de uso gratuito, y se ofrece en dos modalidades principales: las versiones de soporte a largo plazo (LTS), que cuentan con cinco años de soporte de seguridad estándar, y las versiones intermedias, que se lanzan cada seis meses y cuentan con nueve meses de soporte.
¿Por qué deberían los usuarios de Ubuntu preocuparse por la seguridad?
Porque Ubuntu está en todas partes. Cargas de trabajo en la nube, servidores de contenedores, portátiles de desarrolladores, dispositivos periféricos. El informe «2026 Open Source Landscape Report» de TuxCare reveló que más de la mitad de los usuarios empresariales de Linux utilizan Ubuntu en entornos de producción, más que cualquier otra distribución. Esa concentración lo convierte en un objetivo constante y de gran valor.
El informe DBIR de Verizon de 2026 reveló que el aprovechamiento de vulnerabilidades es ahora el vector de acceso inicial más común en las filtraciones de datos, con un 31 % —un aumento del 55 % respecto al año anterior— y superando por primera vez al robo de credenciales. En el caso de los servidores Linux, las vulnerabilidades CVE sin parchear constituyen la vía de acceso más directa.
El riesgo se agrava rápidamente si sigues utilizando tu versión más allá del periodo de soporte estándar. Las notificaciones de CVE a la Base de Datos Nacional de Vulnerabilidades del NIST aumentaron un 263 % entre 2020 y 2025, con casi 42 000 CVE registradas solo en 2025, y el propio NIST ha advertido de que el volumen sigue creciendo. Un host de Ubuntu al final de su vida útil (EOL) deja de recibir correcciones para prácticamente todas ellas. La brecha entre la «publicación del CVE» y la «aplicación del parche en su sistema» ya es lo suficientemente amplia en las versiones con soporte; en una sin soporte, nunca se cierra.
Características clave de seguridad de Ubuntu
Las configuraciones predeterminadas de Ubuntu no están mal. Simplemente están incompletas. A continuación te explicamos qué viene incluido, qué está activado de forma predeterminada y qué te ofrece realmente cada opción.
Arranque seguro
El arranque seguro (Secure Boot) impone una cadena de confianza durante el proceso de arranque, garantizando que solo se cargue software firmado y de confianza antes de que se activen los mecanismos de seguridad del sistema operativo. En Ubuntu, todos los binarios de arranque precompilados están firmados con el certificado UEFI de Canonical. Esto es importante porque un gestor de arranque o un firmware comprometido puede proporcionar a un atacante acceso a nivel del núcleo antes de que AppArmor, UFW o cualquier otro control tenga la oportunidad de hacer algo. La mayoría de las instancias en la nube y las implementaciones modernas en hardware físico disponen de Arranque seguro; vale la pena verificar que esté realmente habilitado en lugar de darlo por sentado.
AppArmor
AppArmor es el marco de control de acceso obligatorio (MAC) de Ubuntu, que viene activado de fábrica. Limita lo que cada programa puede leer, escribir o ejecutar, independientemente de los permisos de los archivos, y funciona a partir de perfiles que se cargan para cada binario. Ubuntu incluye perfiles para servicios de alto riesgo como CUPS, MySQL y Firefox.
En comparación con SELinux, es más fácil crear reglas para AppArmor, lo cual es uno de los motivos por los que Canonical lo eligió. Dicho esto, la mayoría de los equipos nunca crean un perfil personalizado más allá del que viene por defecto, lo que deja sin aprovechar un gran potencial de protección.
Ubuntu 24.04 también introdujo restricciones de espacios de nombres para usuarios sin privilegios, que limitan lo que los procesos pueden hacer dentro de espacios de nombres aislados sin permisos elevados. Se trata de un control a nivel del núcleo que reduce la superficie de ataque frente a fugas de contenedores y eludir el entorno de pruebas; está habilitado de forma predeterminada y conviene mantenerlo activado.
Actualizaciones automáticas
En unattended-upgrades El paquete descarga automáticamente las actualizaciones de seguridad de los repositorios de Ubuntu sin necesidad de intervención manual. En una instalación nueva del servidor, solo está habilitado para el paquete de seguridad, lo cual es la configuración predeterminada adecuada.
Si lo anulas sin pensar, o lo desactivas porque una vez un reinicio provocó un fallo en el entorno de producción, habrás desactivado de hecho el control automatizado más eficaz del sistema.
Hay algo que conviene tener en cuenta sobre cómo gestiona Ubuntu las correcciones de seguridad: en lugar de obligarte a actualizar a la última versión del desarrollador de un paquete, el equipo de seguridad de Ubuntu recurre al «backporting» de seguridad, es decir, aplica la corrección específica a la versión que ya tienes instalada. Por eso, al ejecutar «apt upgrade» en Ubuntu 22.04 no obtendrás de repente una versión completamente diferente de OpenSSL, sino que te quedará la misma versión, pero con la vulnerabilidad ya corregida.
Presta especial atención a los paquetes extraídos del repositorio «universe»: a diferencia del repositorio «main», que es mantenido y actualizado con parches de seguridad directamente por Canonical, los paquetes de «universe» son mantenidos por la comunidad y no siempre reciben las correcciones de seguridad a tiempo.
Cookies de UFW y SYN
Uncomplicated Firewall (UFW) es la interfaz predeterminada para iptables/nftables, y Ubuntu habilita las «cookies» TCP SYN en el núcleo de forma predeterminada para mitigar los ataques de inundación SYN. Las «cookies» SYN por sí solas no sustituyen a un cortafuegos, y UFW no sustituye a los controles a nivel de red, pero juntos gestionan gran parte del tráfico de fondo sin necesidad de prestarles mucha atención.
Livepatch
Canonical Livepatch aplica un subconjunto de correcciones de seguridad del núcleo sin necesidad de reiniciar el sistema. Es útil, pero su alcance es más limitado de lo que sugiere la publicidad. Solo cubre los núcleos LTS compatibles, se centra en vulnerabilidades CVE de gravedad alta y crítica, y no afecta en absoluto a las bibliotecas del espacio de usuario.
Una visión realista: Livepatch no es una solución integral de aplicación de parches al kernel. Cubre un conjunto definido de CVE del kernel en los kernels LTS compatibles, y nada fuera del kernel. Los equipos que ejecutan cargas de trabajo reforzadas las 24 horas del día, los 7 días de la semana, a menudo terminan complementándolo (o sustituyéndolo por completo) con algo como KernelCare, que cubre un conjunto más amplio de CVE, y con LibCare, que amplía la aplicación de parches en tiempo real también a las bibliotecas compartidas. Consulte el desglose de TuxCare sobre las limitaciones de Livepatch para obtener más detalles.
Cifrado de disco LUKS
Ubuntu admite el cifrado completo del disco mediante LUKS (Linux Unified Key Setup), y el momento más sencillo para activarlo es durante la instalación. El instalador de Ubuntu ofrece la opción «Cifrar la nueva instalación de Ubuntu», que configura un volumen LVM cifrado. Una vez activado, el disco completo resulta ilegible sin la contraseña, lo cual resulta importante en caso de robo físico o al dar de baja el hardware.
Hay una salvedad importante que los administradores de sistemas a veces pasan por alto: LUKS protege los datos en reposo. Una vez que el sistema se ha iniciado y el disco está desbloqueado, el cifrado no sirve para detener a un atacante que ya se encuentre dentro del sistema. Por eso, el cifrado de disco no sustituye a la aplicación de parches en el núcleo y el espacio de usuario. Un sistema con un disco cifrado pero con un núcleo sin parches sigue siendo totalmente vulnerable a los ataques en memoria. Estas dos medidas abordan modelos de amenaza diferentes, y ambas son necesarias.
Si no cifraste el sistema durante la instalación, cryptsetup te permite cifrar particiones o volúmenes concretos a posteriori, aunque es un proceso más complicado que hacerlo durante la instalación. La documentación de la comunidad de Ubuntu explica el proceso con detalle.
Amenazas de seguridad habituales en los sistemas Ubuntu
Ubuntu es objeto de ataques constantes. Las amenazas que se enumeran a continuación son las que realmente aparecen en los informes de incidentes, no riesgos teóricos.
Vulnerabilidades CVE sin parchear en el núcleo y el espacio de usuario
Las vulnerabilidades CVE del núcleo acaparan los titulares, pero la mayoría de las intrusiones en Ubuntu se producen a través de componentes del espacio de usuario sin parchear: OpenSSL, glibc, sudo, polkit, CUPS. La cadena de ejecución remota de código de CUPS de 2024 es un ejemplo de libro. Estaba presente en las instalaciones predeterminadas de todas las versiones de Ubuntu y solo se necesitaba acceso a la red para explotarla. Consulte el informe de TuxCare sobre las vulnerabilidades de CUPS para obtener un análisis técnico detallado.
Ataques de fuerza bruta y contra credenciales en SSH
Cualquier servidor Ubuntu con el puerto 22 abierto a Internet empieza a registrar intentos de ataque por fuerza bruta a los pocos minutos de conectarse a la red. Estos ataques son rudimentarios, automatizados e implacables, y solo necesitan tener éxito una vez ante una contraseña débil o una clave filtrada.
Python y las pilas de bibliotecas mal configuradas u obsoletas
Los repositorios de Ubuntu contienen una gran cantidad de paquetes de Python, y los intérpretes obsoletos son una fuente habitual de vulnerabilidades CVE. Un equipo que siga utilizando Python 3.8 en producción estará, para 2026, ejecutando un intérprete que ya habrá alcanzado el fin de su ciclo de vida (EOL) en el código fuente original. TuxCare ha analizado en profundidad el panorama de las vulnerabilidades de Python en Ubuntu, por si quieres comprender su alcance.
Funcionamiento más allá del final de la vida útil
Ubuntu LTS cuenta con cinco años de soporte estándar. Transcurrido ese tiempo, dejan de publicarse parches de seguridad, a menos que se utilice Ubuntu Pro —que incluye el servicio de mantenimiento de seguridad ampliado (ESM) y amplía la cobertura hasta diez años a partir de la fecha de lanzamiento original— o un servicio equivalente de terceros. Muchas infraestructuras de producción siguen funcionando con Ubuntu 18.04 o versiones anteriores, y esos servidores acumulan vulnerabilidades CVE sin parchear cada semana que permanecen en línea.
Escalada de privilegios a través de componentes vulnerables
La escalada de privilegios a nivel local a través de fallos en sudo, polkit o el núcleo ha sido un tema recurrente en Ubuntu desde hace años. Por lo general, estas vulnerabilidades parten de un punto de acceso inicial con privilegios reducidos (por ejemplo, una cuenta de usuario de una aplicación web comprometida) y pueden convertir ese acceso en uno de root en cuestión de minutos. TuxCare mantiene un registro actualizado de las vulnerabilidades recientes de Ubuntu que conviene revisar periódicamente.
Buenas prácticas para mejorar la seguridad de Ubuntu
La mayor parte de lo que hace que un servidor Ubuntu sea difícil de comprometer consiste en un trabajo realmente poco glamuroso y repetitivo. Las prácticas que se indican a continuación son las que ofrecen un mayor rendimiento en relación con el esfuerzo invertido.
Reducir al mínimo los paquetes instalados
Cada paquete instalado en tu sistema es código que puede contener vulnerabilidades. Una cola de impresión que se te había olvidado, una herramienta de desarrollo que quedó por ahí, un servicio que venía incluido con otro programa… Cualquiera de ellos puede contener un CVE del que nunca te enteras porque no los estás controlando. La solución es aburrida, pero eficaz: reduce la lista de paquetes.
Empieza por comprobar qué es lo que está realmente instalado:
apt list --installed 2>/dev/null | less
Comprueba qué es lo que realmente hace tu servidor. ¿Es un servidor web? Entonces no necesita utilidades de Bluetooth ni CUPS. ¿Es un servidor de bases de datos? Probablemente no necesite tener en marcha un agente de transferencia de correo. Elimina lo que no necesites:
sudo apt remove --purge <package-name>
Continúa con:
sudo apt autoremove
Ya que estás, comprueba qué dispositivos están a la escucha en la red:
ss -tlnp
Cualquier elemento de esa lista que no deba estar ahí merece la pena investigarlo. Desactiva los servicios que no se utilicen con sudo systemctl disable --now <service>. Cuanto menos esté en funcionamiento tu sistema, menos puntos vulnerables habrá que explotar.
Aplica los parches con frecuencia, y no te fíes ciegamente de los valores predeterminados
Comprueba que «unattended-upgrades» se esté ejecutando realmente (systemctl status unattended-upgrades) y sacándolo del bolsillo de seguridad.
Si gestionas cargas de trabajo que funcionan las 24 horas del día, los 7 días de la semana, y en las que los reinicios suponen un coste elevado, esta es una de las pocas soluciones que resuelve el problema de forma eficaz. KernelCare aplica parches al núcleo en tiempo real en Ubuntu sin necesidad de reiniciar el sistema y cubre un conjunto de CVE más amplio que Livepatch.
También conviene ejecutar «ubuntu-security-status» periódicamente, ya que ofrece un desglose claro de qué paquetes instalados están cubiertos por el soporte estándar, cuáles requieren Ubuntu Pro/ESM y cuáles tienen actualizaciones de seguridad pendientes.
Bloquear SSH
Desactivar el inicio de sesión como root (PermitRootLogin no), desactivar por completo la autenticación mediante contraseña (PasswordAuthentication no), y requieren una autenticación basada en claves.
Si no puedes aplicar una lista de direcciones IP permitidas (algo habitual en entornos con direcciones IP dinámicas o con trabajadores remotos sin VPN), merece la pena dedicar tiempo a configurar la autenticación de dos factores en SSH. El paquete libpam-google-authenticator añade la autenticación de dos factores basada en TOTP al inicio de sesión de SSH con unos 15 minutos de trabajo. Incluso si se filtra una clave privada, un atacante seguirá necesitando el código rotativo. No sustituye a la autenticación solo con clave, pero añade una capa significativa para situaciones de acceso de mayor riesgo.
Consejo profesional: Ejecuta lastb periódicamente para revisar los intentos fallidos de inicio de sesión. Miles de intentos contra root o admin desde un único ASN no constituyen realmente un ataque. Solo es ruido de fondo. La solución es cerrar la puerta con autenticación solo por clave y una lista de IP permitidas, no perseguir IP individuales.
Habilitar el registro de auditoría y supervisarlo
Instala auditd y configura reglas para los eventos que realmente importan: cambios en los archivos de /etc, ejecuciones de sudo, creación de nuevos usuarios y carga de módulos del núcleo. Los registros que no se leen no sirven para nada. Envíalos a un servidor de registros central o a un SIEM. El objetivo no es cumplir con las normas por cumplir; se trata de detectar cualquier evento de autenticación sospechoso antes de que se convierta en una brecha de seguridad.
Combina auditd con un monitor de integridad de archivos como AIDE (Advanced Intrusion Detection Environment). Mientras que auditd registra lo que ha ocurrido, AIDE detecta lo que ha cambiado. Crea una base de datos de referencia de tu sistema de archivos —hashes de archivos, permisos, propiedad— y señala las desviaciones cuando se ejecuta una comprobación. Resulta especialmente útil para detectar actividades posteriores a un ataque que no generan eventos de registro evidentes: un binario sustituido discretamente, una biblioteca modificada, una tarea cron añadida. Ejecute sudo aideinit para crear la base de referencia tras una instalación limpia y, a continuación, programe comprobaciones periódicas mediante cron. Al igual que la supervisión de registros, solo es útil si alguien revisa realmente los resultados.
Si tu entorno tiene requisitos de cumplimiento normativo, tanto los CIS Benchmarks como las DISA STIG ofrecen perfiles de refuerzo específicos para Ubuntu que se ajustan directamente a los controles mencionados anteriormente; resultan útiles como lista de verificación estructurada, en lugar de tener que empezar desde cero.
|
Buenas prácticas |
Esfuerzo |
Se cierra la brecha en la cobertura |
|
Actualizaciones de seguridad automáticas |
Bajo |
Las vulnerabilidades CVE más conocidas en el espacio de usuario |
|
Aplicación de parches al núcleo en tiempo real |
Bajo-medio |
Vulnerabilidades CVE del núcleo sin necesidad de reiniciar el sistema |
|
Autenticación solo con clave SSH + fail2ban |
Bajo |
Fuerza bruta, relleno de credenciales |
|
auditd + registros centralizados |
Medio |
Detección de actividades posteriores a la intrusión |
|
Plan de salida de EOL (actualización o ELS) |
Alta |
Todo, con el tiempo |
Planifica el final de tu vida antes de que llegue
Cada versión LTS de Ubuntu tiene una fecha de fin de vida útil (EOL) publicada. Tienes tres opciones reales: actualizar directamente a la siguiente versión LTS, migrar las cargas de trabajo a una versión compatible o contratar soporte técnico ampliado. La opción de «no hacer nada» se convierte en la opción por defecto cuando a los equipos se les acaba el tiempo, y sin duda es la peor.
Las actualizaciones in situ no siempre son viables. Las aplicaciones heredadas, las dependencias de los módulos del núcleo o el middleware certificado: cualquiera de estos factores puede impedir una actualización limpia. Esa es precisamente la situación para la que se ha diseñado el servicio «Endless Lifecycle Support» de TuxCare. Este servicio proporciona parches de seguridad continuos para Ubuntu 16.04, 18.04 y 20.04 durante todo el tiempo que realmente los necesites, y no solo hasta la fecha de fin de vida útil (EOL) establecida por el proveedor.
Es una opción más habitual de lo que la gente cree. La encuesta de TuxCare de 2026 reveló que las organizaciones que se enfrentaban al fin de la vida útil (EOL) de su software se dividían casi a partes iguales entre migrar y adquirir soporte de ciclo de vida ampliado (ELS): un 41,7 % en cada caso. Para muchos equipos, el ELS no es un plan de contingencia, sino el plan.
He aquí un patrón que se repite más a menudo de lo que cabría esperar. Un equipo planifica una actualización de Ubuntu 18.04 a 22.04 seis meses antes del fin de la vida útil (EOL), se encuentra con un problema de compatibilidad de un módulo del núcleo con un dispositivo de un proveedor y acaba utilizando la versión 18.04 sin soporte técnico durante un año más, mientras el departamento de compras resuelve el problema. La cobertura ELS está pensada precisamente para esta situación.
Recursos sobre seguridad en Ubuntu
Algunos sitios que vale la pena visitar con regularidad para estar al día.
Avisos de seguridad de Ubuntu
El canal de avisos de seguridad de Ubuntu es la fuente oficial de Canonical para los avisos CVE que afectan a los paquetes de Ubuntu, con detalles sobre la retrocompatibilidad y las clasificaciones de gravedad. Suscríbete a través de RSS o de la lista de correo. Los avisos son gestionados por el Equipo de Seguridad de Ubuntu, el grupo específico de Canonical encargado de clasificar las vulnerabilidades y publicar correcciones de seguridad en todas las versiones de Ubuntu.
Catálogo de vulnerabilidades explotadas de la CISA
El catálogo KEV de la CISA recoge los CVE que se están explotando activamente en la red. Compararlo con las versiones de tus paquetes de Ubuntu es una forma rápida de priorizar qué parches instalar primero. Si una entrada del KEV afecta a un paquete instalado, esa debe ser tu máxima prioridad.
r/Ubuntu y r/linuxadmin
Ambos subreddits sacan a la luz debates sobre medidas de seguridad en el mundo real, análisis a posteriori y problemas a los que se enfrentan los administradores de sistemas con mayor rapidez que la mayoría de los blogs de los proveedores. La relación señal-ruido varía, pero el tono es sincero.
Rastreador de CVE de TuxCare
Si utilizas alguna versión cubierta por ELS, como Ubuntu 16.04, 18.04 o 20.04, te conviene añadir a tus favoritos el TuxCare CVE Tracker. Te permite filtrar las vulnerabilidades por gravedad, producto, componente y estado de la corrección en todos los sistemas fuera de ciclo de vida compatibles con TuxCare y sus cadenas de dependencias, de modo que puedas ver exactamente qué está expuesto y cuándo estará disponible la solución. También puedes suscribirte para recibir notificaciones cuando cambie el estado de un CVE o de una corrección, lo que es mucho mejor que estar pendiente manualmente de los avisos de múltiples productos al final de su vida útil.
Protege tus sistemas Ubuntu con TuxCare
El refuerzo de la seguridad en Ubuntu no es un proyecto puntual. Se trata de un ciclo de aplicación de parches, un refuerzo de la seguridad de SSH, un plan de retirada al final de la vida útil y el hábito de verificar los ajustes predeterminados en lugar de darlos por buenos.
En lo que respecta específicamente a la aplicación de parches al núcleo y a la cobertura tras el fin de vida útil, KernelCare y Endless Lifecycle Support de TuxCare cubren las carencias que dejan las ofertas estándar de Canonical. KernelCare gestiona la aplicación de parches al kernel sin necesidad de reiniciar, con una cobertura de CVE más amplia que Livepatch. ELS mantiene a Ubuntu 16.04, 18.04 y 20.04 protegidos con parches de seguridad durante todo el tiempo que sea necesario, más allá de cualquier plazo de soporte definido por Canonical.
