Cómo activar las actualizaciones automáticas de seguridad en Ubuntu

Firewall configurado, SSH con llave, fail2ban funcionando — y un servidor que nadie actualiza hace ocho meses. Es el estado más común de un VPS olvidado: la defensa perimetral está bien, pero openssl o el kernel arrastran fallos ya corregidos y públicos. El caso clásico es la filtración de Equifax en 2017, en la que el parche de Apache Struts existía meses antes de la intrusión. En Ubuntu, el paquete unattended-upgrades lo resuelve instalando solo los parches de seguridad.

¿Qué es unattended-upgrades?

¿Qué hace unattended-upgrades en Ubuntu?

Es un servicio de APT que descarga e instala actualizaciones automáticamente, en segundo plano, desde una lista de repositorios que tú autorizas — por defecto, solo los de seguridad. Se ejecuta mediante temporizadores de systemd (apt-daily y apt-daily-upgrade), así que no depende de un cron manual.

En instalaciones recientes de Ubuntu suele venir instalado y activo, pero varía según la imagen (VPS de proveedor, minimal, derivadas). Compruébalo antes de suponerlo.

Paso 1: instálalo y actívalo

sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

El último comando abre una pantalla que pregunta si debe instalar actualizaciones automáticamente. Responde Sí. Escribe el archivo /etc/apt/apt.conf.d/20auto-upgrades:

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

Los valores significan "cada 1 día": actualizar la lista de paquetes y ejecutar unattended-upgrade.

Paso 2: elige qué se actualiza automáticamente

La configuración principal está en /etc/apt/apt.conf.d/50unattended-upgrades. Ábrelo con sudo nano y busca el bloque Allowed-Origins:

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 que empiezan con // están desactivadas. Lo habitual es dejar activo solo -security (y los canales ESM, si usas Ubuntu Pro). Mantener -updates comentado es la opción conservadora: trae correcciones de errores que no son de seguridad y tienen más probabilidad de cambiar el comportamiento. Nunca habilites -proposed en un servidor.

¿Una actualización automática puede romper el servidor?

Puede, pero el riesgo es mucho menor con solo el canal de seguridad, porque esos parches son pequeños y buscan corregir el fallo sin cambiar funcionalidad. Aun así, en producción crítica, mantén una copia de seguridad y prueba en un entorno de pruebas. La regla 3-2-1 de copias de seguridad también vale aquí.

Paso 3: define el reinicio automático

Los parches de kernel y de bibliotecas como glibc solo surten efecto tras reiniciar. Cuando hace falta, el sistema crea el archivo /var/run/reboot-required. Para que unattended-upgrades se encargue en un horario de poco movimiento, ajusta en el mismo archivo:

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

Así el servidor solo se reinicia si es necesario, a las 3 h de la zona horaria del servidor, y omite el reinicio si hay un usuario conectado. Si no puedes aceptar ninguna interrupción, deja Automatic-Reboot "false" y programa una ventana de mantenimiento manual, revisando el archivo reboot-required cada semana.

Dos opciones útiles en el mismo archivo:

Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Mail "[email protected]";

La primera limpia dependencias sobrantes. La segunda envía un informe por correo, pero solo funciona si el servidor tiene un MTA configurado (como postfix o msmtp).

Paso 4: prueba sin aplicar nada

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

--dry-run simula la ejecución y muestra qué paquetes se actualizarían, sin instalarlos. En modo debug ves qué orígenes se aceptaron. Si aparece algo como "Packages that will be upgraded", la configuración funciona. Para comprobar que los temporizadores están activos:

systemctl list-timers apt-daily.timer apt-daily-upgrade.timer

Paso 5: revisa los registros

sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
ls /var/run/reboot-required

El registro muestra cada ejecución, con los paquetes instalados y los errores. Si ls dice que el archivo no existe, no hay reinicio pendiente. Un servidor que mantiene ese archivo durante semanas tiene parches instalados pero aún no activos en el kernel en ejecución.

Lo que unattended-upgrades no cubre

• Software fuera de APT: binarios descargados a mano, imágenes Docker, paquetes pip/npm y snaps siguen otra lógica de actualización.
• Contenedores: el host se actualiza, pero las imágenes de los contenedores hay que reconstruirlas.
• Servicios que necesitan reinicio: sin reiniciar, un demonio puede seguir usando la biblioteca antigua en memoria. El paquete needrestart ayuda a listar qué reiniciar.
• Configuración insegura: un parche no corrige una contraseña débil ni un puerto abierto sin motivo. Para eso, mira el tutorial del firewall UFW y la guía de fail2ban contra fuerza bruta.

La lección de fondo

Muchas intrusiones no usan un fallo nuevo: usan un fallo con corrección publicada que nadie instaló. Automatizar el parche de seguridad quita esa decisión del esfuerzo humano y la pone en una rutina que corre sola. Es el punto más barato de la lista de hardening y vale tanto como un SSH bien configurado.

Si quieres profundizar en lo que pasa cuando el parche no se instala, lee cómo protegerte del ransomware.

Fuentes consultadas

• Páginas de manual de unattended-upgrade y comentarios del archivo 50unattended-upgrades (paquete Debian/Ubuntu)
• Documentación de Ubuntu Server sobre actualizaciones automáticas