Actualizaciones de seguridad automáticas en Linux con unattended-upgrades y dnf-automatic

La mayoría de los servidores Linux de una empresa deberían instalar las actualizaciones de seguridad automáticamente. En Debian y Ubuntu esa tarea corresponde a unattended-upgrades; en Red Hat Enterprise Linux y AlmaLinux, a dnf-automatic. Bien configuradas, aplican los parches de seguridad a diario, le envían por correo lo que cambió, reinician los servicios afectados y reinician el servidor solo dentro del horario que usted elija. Lo que suele fallar son dos cosas: servidores que no deberían actualizarse solos (bases de datos y aplicaciones con versión fija) y servidores donde todos suponen que las actualizaciones funcionan cuando dejaron de ejecutarse hace semanas. Esta guía cubre ambas, con comandos para Debian 12/13, Ubuntu 24.04 y RHEL/AlmaLinux 9 y 10.

Por qué automatizar las actualizaciones de seguridad

Aplicar parches es el control rutinario más eficaz que tiene, y también el más fácil de olvidar. Las actualizaciones automáticas de seguridad cierran la brecha entre la publicación de un parche y el momento en que alguien se acuerda de entrar al servidor. Las nuevas funciones y los cambios de versión mayor siguen necesitando a una persona, pero los parches de seguridad rutinarios de OpenSSL, la biblioteca de C, SSH o el kernel no deberían esperar a la próxima reunión de mantenimiento. Si todavía está construyendo lo básico, empiece por nuestra guía de fundamentos para proteger servidores Linux.

Debian y Ubuntu: unattended-upgrades

Ubuntu Server instala y activa unattended-upgrades de forma predeterminada para las actualizaciones de seguridad. En Debian, instálelo y actívelo:

sudo apt update
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

El último comando crea /etc/apt/apt.conf.d/20auto-upgrades, que debe contener:

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

Elija qué actualizaciones se instalan

Los orígenes permitidos están en /etc/apt/apt.conf.d/50unattended-upgrades.

• Ubuntu permite de forma predeterminada ${distro_id}:${distro_codename}-security y los repositorios de seguridad ESM de Ubuntu Pro; -updates está comentado. Es un valor predeterminado razonable, solo de seguridad.
• Debian 12 y 13 permiten tres orígenes de forma predeterminada: el archivo de seguridad (label=Debian-Security) y también la versión principal (label=Debian), que entrega las actualizaciones de las versiones puntuales de stable. Si quiere solo parches de seguridad, comente la línea que termina en label=Debian"; y conserve las dos líneas Debian-Security.

Informes por correo y limpieza

Ponga su configuración en un archivo aparte para que las actualizaciones del paquete no la sobrescriban, por ejemplo /etc/apt/apt.conf.d/52unattended-upgrades-local:

Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

MailReport acepta always, only-on-error u on-change. El correo solo funciona si el servidor puede enviarlo: instale un paquete que proporcione mailx (como bsd-mailx) y configure un relé hacia su proveedor de correo. Pruébelo antes de confiar en él.

Reinicios automáticos dentro de un horario

Las actualizaciones del kernel y de la biblioteca de C solo surten efecto completo tras un reinicio. unattended-upgrades puede reiniciar por usted cuando existe /var/run/reboot-required:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

Las actualizaciones en sí se ejecutan desde el temporizador de systemd apt-daily-upgrade.timer. Compruebe cuándo se activa y muévalo si hace falta:

systemctl list-timers 'apt-daily*'
sudo systemctl edit apt-daily-upgrade.timer

En el archivo de reemplazo, borre y vuelva a definir el horario:

[Timer]
OnCalendar=
OnCalendar=*-*-* 02:00
RandomizedDelaySec=30m

Reinicio de servicios con needrestart

Actualizar una biblioteca no ayuda a un proceso en ejecución que todavía tiene cargada la copia anterior. needrestart encuentra esos procesos y reinicia sus servicios. Desde Ubuntu 24.04 LTS reinicia automáticamente los servicios afectados de forma predeterminada, también durante las actualizaciones desatendidas. En Debian es opcional (sudo apt install needrestart) y, cuando se ejecuta de forma no interactiva con su modo predeterminado, solo muestra lo que necesita reinicio.

Para excluir un servicio que prefiere reiniciar usted mismo, como PostgreSQL, agregue un archivo en /etc/needrestart/conf.d/, por ejemplo zz-local.conf:

$nrconf{override_rc}->{qr(^postgresql)} = 0;

Ejecute sudo needrestart -r l en cualquier momento para ver qué falta por reiniciar.

Pruebe antes de confiar

sudo unattended-upgrade --dry-run --debug

Los registros se guardan en /var/log/unattended-upgrades/, y las acciones de paquetes en /var/log/dpkg.log.

RHEL y AlmaLinux 9 y 10: dnf-automatic

RHEL 9 y 10 y sus recompilaciones, como AlmaLinux, usan DNF 4, que incluye dnf-automatic:

sudo dnf install dnf-automatic

Edite /etc/dnf/automatic.conf:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = when-needed

[emitters]
emit_via = email,motd

[email]
email_from = [email protected]
email_to = [email protected]
email_host = localhost

• upgrade_type = security instala solo las actualizaciones que tienen un aviso de seguridad. Depende de que el repositorio publique metadatos de avisos (updateinfo), como hacen RHEL y AlmaLinux. Vea lo que está pendiente con sudo dnf updateinfo list --security.
• reboot = when-needed reinicia solo cuando una actualización lo requiere, como un kernel nuevo o systemd. El reboot_command predeterminado espera cinco minutos y avisa a los usuarios conectados. La opción reboot está disponible en los paquetes actuales de RHEL 9 y 10; si su servidor no la acepta, actualice primero dnf.
• emit_via controla los informes. El correo, de nuevo, necesita un relé local que funcione.

Luego active el temporizador que sigue su archivo de configuración:

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'

También existen dnf-automatic-notifyonly.timer, dnf-automatic-download.timer y dnf-automatic-install.timer, que reemplazan el comportamiento del archivo de configuración. Active solo uno. Para cambiar el horario, use sudo systemctl edit dnf-automatic.timer como se mostró antes. Para saber si hay un reinicio pendiente, ejecute sudo dnf needs-restarting -r. (En Fedora 41 y posteriores, DNF5 lo reemplaza con su propio complemento automático, así que consulte la documentación de Fedora).

Parches del kernel en vivo (live patching)

El live patching aplica correcciones de vulnerabilidades graves del kernel al kernel en ejecución sin reiniciar. Reduce los reinicios; no los elimina.

• Ubuntu: Livepatch forma parte de Ubuntu Pro. En una máquina LTS vinculada, actívelo con sudo pro enable livepatch. Canonical solo parchea CVE del kernel de gravedad alta y crítica, y solo para kernels compatibles durante un período limitado, así que igual debe instalar kernels nuevos y reiniciar con regularidad.
• RHEL: Red Hat distribuye los parches en vivo como paquetes kpatch-patch para los kernels compatibles. Instale el complemento de DNF y suscríbase automáticamente con sudo dnf install kpatch-dnf y sudo dnf kpatch auto.
• Debian y AlmaLinux: el live patching está disponible mediante servicios comerciales de terceros. Evalúelos como a cualquier otro proveedor.

Cuándo no actualizar automáticamente

La automatización es lo predeterminado, no una regla para todos los servidores.

• Bases de datos: una actualización de seguridad de PostgreSQL, MariaDB o MySQL reinicia la base de datos. Muchas empresas prefieren aplicarlas en una ventana de mantenimiento después de una copia de seguridad. Exclúyalas del reinicio de servicios (como se mostró) o reténgalas y aplíquelas según un calendario.
• Aplicaciones con versión fija: si un proveedor certifica una versión específica, reténgala. En Debian/Ubuntu, sudo apt-mark hold <paquete> (unattended-upgrades respeta las retenciones). En RHEL/AlmaLinux, instale python3-dnf-plugin-versionlock y ejecute sudo dnf versionlock add <paquete>.
• Clústeres y pares redundantes: escalone los temporizadores para que los dos nodos nunca se reinicien a la vez.
• Hipervisores y servidores de almacenamiento: un reinicio apaga todas las máquinas virtuales. Aplíqueles parches según un calendario, después de mover o apagar las cargas de trabajo, y mantenga copias de seguridad probadas.
• Servidores con módulos del kernel externos: un kernel nuevo puede romper un controlador que se compila por separado. Pruébelos primero en una máquina de pruebas.

Un paquete retenido es una tarea manual que usted se comprometió a hacer. Póngala en el calendario y regístrela en su política de parches.

Asegúrese de que las actualizaciones se ejecutaron

Un temporizador que falló en silencio hace meses se ve exactamente igual que uno que funciona. Verifique, y luego automatice la verificación:

En Debian y Ubuntu:

systemctl status apt-daily-upgrade.timer
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
ls /var/run/reboot-required 2>/dev/null && echo "Reinicio pendiente"

En RHEL y AlmaLinux:

systemctl status dnf-automatic.timer
sudo journalctl -u dnf-automatic.service --since "7 days ago"
sudo dnf history list | head
sudo dnf needs-restarting -r

Después, configure su monitoreo para que avise cuando:

• haya actualizaciones de seguridad pendientes por más de unos pocos días,
• un reinicio lleve pendiente más tiempo del que permite su política,
• el servicio de actualización haya fallado o no haya llegado el correo de informe a tiempo,
• un disco esté casi lleno (una causa común de que las actualizaciones se detengan).

Revise los correos de actualización cada semana; también son su evidencia para auditorías y cuestionarios de seguros cibernéticos.

Si quiere configurar, escalonar y monitorear los parches automáticos de sus servidores Linux, solicite una evaluación de TI gratuita. Core Florida IT administra y actualiza servidores empresariales para compañías de Miami-Dade y todo el sur de Florida con nuestros servicios de instalación y reparación de servidores y soporte de TI administrado.

Fuentes

• Debian Wiki: UnattendedUpgrades
• Documentación de Ubuntu Server: Automatic updates
• Ubuntu Discourse: needrestart changes in Ubuntu 24.04, service restarts
• Documentación de DNF: DNF Automatic
• Red Hat: Managing software with the DNF tool (RHEL 9): Updating RHEL 9 content
• Ubuntu Pro Client: How to manage Livepatch