Actualizaciones automáticas

Módulo 4: Software y actualizaciones · Tiempo de lectura: 10 minutos

Objetivo de aprendizaje: Tras esta lección, usted podrá activar y comprobar las actualizaciones de seguridad automáticas, sabrá qué ocurre automáticamente y qué no, y sabrá cuándo hace falta un reinicio.

Conceptos clave: unattended-upgrades, 20auto-upgrades, 50unattended-upgrades, Origins-Pattern y Allowed-Origins, temporizadores apt-daily, needrestart, /var/run/reboot-required, Automatic-Reboot, actualización del kernel, dnf-automatic

¿Por qué de forma automática?

Las vulnerabilidades de seguridad se descubren, se corrigen y después se explotan activamente, a menudo en cuestión de días. Un servidor que usted actualiza una vez al mes queda, por tanto, expuesto de media durante semanas a vulnerabilidades conocidas. El NCSC neerlandés considera la instalación puntual de actualizaciones uno de los principios básicos de la resiliencia digital: "Actualizar y aplicar parches al software a tiempo ayuda a corregir vulnerabilidades con rapidez."

Aun así, "todo automático" tampoco es buena idea. Una nueva versión de un programa puede comportarse de forma distinta a la anterior, y un servidor que se reinicia solo en plena jornada puede afectar a sus visitantes. El término medio habitual en Debian y Ubuntu es:

• actualizaciones de seguridad automáticas, cada día;
• otras actualizaciones y actualizaciones de versión, a mano, en el momento que usted elija, con una instantánea previa;
• reinicios planificados, en un momento tranquilo, y controlados.

El programa que se encarga de esto se llama unattended-upgrades.

Activar unattended-upgrades

En Ubuntu Server, unattended-upgrades viene instalado de serie y las actualizaciones de seguridad automáticas están activas desde la instalación. En Debian también está presente en muchas instalaciones e imágenes, pero no siempre. Compruébelo y actívelo:

anna@web1:~$ sudo apt install unattended-upgrades
anna@web1:~$ sudo dpkg-reconfigure -plow unattended-upgrades

El segundo comando pregunta "Automatically download and install stable updates?" (¿descargar e instalar automáticamente las actualizaciones estables?). Elija Yes. Esto escribe el archivo /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

El 1 significa: cada día. Con 0 lo desactiva. El trabajo en sí lo inician dos temporizadores de systemd (lección 6.3), que puede consultar así:

anna@web1:~$ systemctl list-timers 'apt*'
NEXT                        LEFT     LAST                        PASSED  UNIT                    ACTIVATES
Tue 2026-11-10 06:24:11 CET 9h left  Mon 2026-11-09 06:41:03 CET 14h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Tue 2026-11-10 08:02:47 CET 11h left Mon 2026-11-09 19:12:30 CET 1h ago  apt-daily.timer         apt-daily.service

apt-daily descarga las listas (como apt update), apt-daily-upgrade instala las actualizaciones. Las horas tienen un margen aleatorio, para que no todos los servidores del mundo carguen a la vez los repositorios de paquetes.

¿Qué se instala automáticamente?

Eso se indica en /etc/apt/apt.conf.d/50unattended-upgrades. En Debian el bloque se llama Unattended-Upgrade::Origins-Pattern, en Ubuntu Unattended-Upgrade::Allowed-Origins. De forma predeterminada están activados el repositorio de seguridad y el repositorio estable de su versión, y el repositorio -updates está desactivado. En Ubuntu tiene este aspecto:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Las líneas precedidas de // están desactivadas. Para un primer servidor, déjelo así. No modifique este archivo directamente, porque una versión posterior del paquete podría querer sustituirlo. Debian recomienda poner sus propios cambios en un archivo aparte, por ejemplo /etc/apt/apt.conf.d/52unattended-upgrades-local; los archivos posteriores tienen prioridad sobre los anteriores.

Los paquetes de repositorios adicionales (Docker, Caddy, PostgreSQL del propio fabricante) no se actualizan automáticamente de forma predeterminada. Es una decisión deliberada: esos los sigue usted mismo (lección 9.4), o añade el repositorio a mano a la lista si confía en el fabricante y conoce las consecuencias.

Algunos ajustes que conviene configurar a menudo:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailReport "only-on-error";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Automatic-Reboot "false";

Mail solo funciona si el servidor puede enviar correo (un pequeño relay, lección 8.3). Si no es posible, omítalo y utilice la monitorización de la lección 8.3.

Comprobar que funciona

Un automatismo que se detiene sin avisar es más peligroso que no tener ninguno, porque usted cree que está protegido. Por eso, compruebe tres cosas.

1. Una ejecución de prueba. Muestra lo que ocurriría, sin cambiar nada:

anna@web1:~$ sudo unattended-upgrade --dry-run --debug
...
Allowed origins are: origin=Debian,codename=trixie,label=Debian, origin=Debian,codename=trixie-security,label=Debian-Security, ...
Packages that will be upgraded: libssl3t64 openssh-server

2. El registro. Cada ejecución escribe en /var/log/unattended-upgrades/unattended-upgrades.log:

anna@web1:~$ sudo tail -n 5 /var/log/unattended-upgrades/unattended-upgrades.log
2026-11-09 06:41:15,201 INFO Packages that will be upgraded: openssh-server
2026-11-09 06:41:15,202 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2026-11-09 06:41:29,874 INFO All upgrades installed

3. Lo que sigue pendiente. apt list --upgradable (lección 4.1) no debería mostrar, tras una noche, ningún paquete de -security. Si siguen apareciendo varios días seguidos, algo falla: un disco lleno, un bloqueo por un apt manual que se ha quedado colgado o un paquete que hace una pregunta.

Reiniciar: servicios y kernel

Un programa actualizado en el disco no es lo mismo que un programa actualizado en la memoria. Si OpenSSH lleva tres semanas en marcha, sigue ejecutando el código antiguo hasta que el servicio se reinicie.

• Servicios: el programa needrestart comprueba tras una actualización qué servicios siguen usando bibliotecas antiguas. En Ubuntu 24.04 y posteriores, unattended-upgrades reinicia esos servicios automáticamente a través de needrestart de forma predeterminada. En Debian, needrestart es un paquete aparte (apt install needrestart) que le pregunta de forma interactiva qué servicios deben reiniciarse.
• El kernel: un kernel nuevo solo entra en funcionamiento tras reiniciar todo el servidor. Debian y Ubuntu crean entonces el archivo /var/run/reboot-required:

anna@web1:~$ cat /var/run/reboot-required
*** System restart required ***
anna@web1:~$ cat /var/run/reboot-required.pkgs
linux-image-6.12.57+deb13-amd64

Tiene dos opciones. O reinicia usted mismo, por ejemplo cada semana en un momento fijo tras comprobar si existe el archivo. O deja que lo haga unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

El valor predeterminado es false. Actívelo solo si está seguro de que todo vuelve a arrancar por sí solo tras un reinicio: servicios con enable (lección 6.1), contenedores con una política restart: (lección 9.3) y una monitorización que le avise si no es así (lección 8.3). Pruébelo primero una vez a mano: sudo reboot, y compruebe que todo vuelve.

Ubuntu ofrece además, a través de Ubuntu Pro, Livepatch, que aplica algunas correcciones del kernel sin reiniciar. Es un complemento, no un sustituto: incluso con Livepatch tendrá que reiniciar de vez en cuando.

Lo que no hace de forma automática

• Actualizaciones de versión (de Debian 12 a 13, de Ubuntu 24.04 a 26.04): siempre a mano, con un plan (lección 4.3).
• Versiones principales de sus propias aplicaciones (una nueva versión principal de una base de datos, de un CMS): siempre a mano, tras una copia de seguridad y tras leer las notas de la versión.
• Contenedores: unattended-upgrades no los actualiza. Una imagen de 2024 sigue siendo la imagen de 2024 hasta que usted ejecute docker compose pull (lección 9.4).

En AlmaLinux y Rocky Linux

Allí la herramienta se llama dnf-automatic. Se instala con dnf install dnf-automatic. En /etc/dnf/automatic.conf establezca upgrade_type = security y apply_updates = yes, y active el temporizador con systemctl enable --now dnf-automatic.timer. En las distribuciones tipo RHEL, un reinicio por el kernel es igual de necesario que en Debian; dnf needs-restarting -r le indica si es el caso.

En la práctica

En WebOké, un VPS funciona igual que en otros proveedores: lo que se actualiza dentro del servidor lo gestiona usted. El proveedor actualiza el hardware y la plataforma de virtualización, no su sistema operativo. Antes de una actualización importante manual, cree una instantánea en el panel de su proveedor; para las actualizaciones de seguridad automáticas diarias no es necesario.

Resumen

• Active las actualizaciones de seguridad automáticas con unattended-upgrades (Ubuntu: activadas de serie; Debian: compruébelo con dpkg-reconfigure -plow unattended-upgrades).
• De forma predeterminada solo se actualizan automáticamente el repositorio de seguridad y el repositorio estable de la versión; los repositorios adicionales, no.
• Compruébelo con una ejecución de prueba, el registro en /var/log/unattended-upgrades/ y apt list --upgradable.
• Los servicios deben reiniciarse tras una actualización (needrestart), el kernel requiere reiniciar el servidor (/var/run/reboot-required).
• Las actualizaciones de versión, las versiones principales de aplicaciones y los contenedores se actualizan a mano.

Cuestionario

Ejercicio

Ejercicio O4.2: Activar y comprobar las actualizaciones automáticas. Active unattended-upgrades en su propio servidor (o compruebe que está activo), haga una ejecución de prueba y revise el registro y los temporizadores. Rellene la lista de comprobación y responda: ¿qué repositorios se actualizan automáticamente en su servidor?, ¿cuándo fue la última ejecución?, ¿hay ahora un reinicio pendiente?, y ¿cómo va a reiniciar usted (manualmente en un momento fijo o de forma automática, y por qué)?

Para saber más

• Proteger su VPS: los primeros cinco minutos
• Debian Wiki, actualizaciones automáticas (UnattendedUpgrades): https://wiki.debian.org/PeriodicUpdates
• NCSC neerlandés (fuente en neerlandés), principio básico 3: proteger sistemas, aplicaciones y dispositivos: https://www.ncsc.nl/basisprincipes/basisprincipe-3-bescherm-systemen-applicaties-en-apparaten
• Documentación de Ubuntu Server, Automatic updates: https://ubuntu.com/server/docs/how-to/software/automatic-updates/