Por qué automatizar los parches de seguridad
El ciclo de vida de una vulnerabilidad es corto. Entre la publicación de un CVE crítico y los primeros intentos de explotación masiva, la ventana se mide ahora en horas. Para una agencia que administra diez, veinte o cincuenta VPS, esperar una intervención manual programada cada semana equivale a ofrecer varios días de exposición en cada máquina.
La normativa refuerza esta exigencia. El Cyber Resilience Act europeo obliga a los operadores de productos conectados a demostrar una política de parches documentada y aplicada. Para las agencias que alojan aplicaciones de clientes, la ausencia de trazabilidad de los parches puede comprometer su responsabilidad contractual en caso de incidente.
El argumento técnico es sencillo: la mayoría de los compromisos de servidores Linux explotan vulnerabilidades para las que existe un parche disponible desde hace más de 30 días. La herramienta unattended-upgrades, incluida en los repositorios de Debian y Ubuntu, instala automáticamente los parches de seguridad de los repositorios oficiales — sin tocar las actualizaciones de versión mayor ni los paquetes que ha excluido explícitamente.
Beneficios concretos para las agencias que gestionan una flota de clientes
- Tiempo de corrección reducido: los parches de seguridad se aplican en pocas horas tras su publicación en los repositorios estables, sin ticket de mantenimiento.
- Trazabilidad automática: cada instalación queda registrada en
/var/log/unattended-upgrades/, consultable en cualquier momento para una auditoría o informe de cliente. - Alcance controlado: por defecto solo se aplican las actualizaciones etiquetadas como
security— las actualizaciones de versión permanecen bajo control manual. - Carga operativa reducida: una flota de 50 VPS ya no requiere 50 conexiones SSH semanales para ejecutar
apt upgrade. - Cumplimiento documentable: la política se define en un archivo de configuración versionable y reproducible con Ansible o cualquier herramienta de gestión de configuración.
- Notificaciones dirigidas: los errores de instalación o los reinicios necesarios pueden desencadenar un correo, sin saturar al equipo con informes rutinarios.
Cómo funciona unattended-upgrades
unattended-upgrades es un demonio de Debian/Ubuntu que se ejecuta mediante un temporizador systemd (o cron en sistemas más antiguos). Consulta los repositorios APT configurados, filtra los paquetes según los orígenes permitidos definidos en su configuración, luego instala las actualizaciones sin interacción del usuario.
La lógica de filtrado se basa en los archivos Release de APT. Cada repositorio expone metadatos (Origin, Suite, Codename) que unattended-upgrades compara con su lista blanca. Por defecto en Ubuntu, solo están habilitados los orígenes ${distro_id}:${distro_codename}-security — lo que corresponde exactamente a los archivos de seguridad oficiales de Canonical, sin incluir actualizaciones de backports ni paquetes de terceros.
El proceso se ejecuta en tres fases: actualización de la caché APT, resolución de dependencias para los paquetes elegibles, instalación con registro detallado. En caso de error (conflicto de dependencias, paquete bloqueado, espacio en disco insuficiente), la instalación se detiene y se puede enviar una notificación según la configuración.
Requisitos previos
La configuración descrita en este artículo se aplica a Debian 11/12 y Ubuntu 22.04/24.04 LTS. Los sistemas más antiguos (Debian 10, Ubuntu 20.04) son compatibles pero su soporte oficial está próximo a su fin — se recomienda migrar antes de invertir en su configuración.
Acceso requerido: conexión SSH con derechos root o cuenta con sudo. No se necesitan dependencias externas para el funcionamiento básico; la configuración SMTP es opcional y solo interviene para las notificaciones por correo.
Si gestiona su flota con Ansible, los pasos descritos a continuación pueden reproducirse directamente en un rol dedicado — la estructura de los archivos de configuración es estable entre las versiones principales de Debian y Ubuntu.
Instalar y configurar unattended-upgrades
Instalar el paquete
En Debian y Ubuntu, el paquete está disponible en los repositorios estándar:
apt-get update apt-get install -y unattended-upgrades apt-listchangesEl paquete
apt-listchangeses opcional pero recomendado: permite incluir el resumen de cambios en las notificaciones por correo.Configurar los orígenes permitidos
Edite
/etc/apt/apt.conf.d/50unattended-upgrades. La secciónUnattended-Upgrade::Allowed-Originscontrola qué repositorios son elegibles. En Ubuntu 22.04, la configuración mínima recomendada:Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; "${distro_id}ESMApps:${distro_codename}-apps-security"; "${distro_id}ESM:${distro_codename}-infra-security"; };En Debian 12, reemplace con:
Unattended-Upgrade::Allowed-Origins { "Debian:${distro_codename}-security"; };Para excluir paquetes sensibles (por ejemplo un núcleo personalizado o una versión fijada de PHP):
Unattended-Upgrade::Package-Blacklist { "linux-image"; "php8.2-fpm"; };Activar el temporizador periódico
El archivo
/etc/apt/apt.conf.d/20auto-upgradescontrola la frecuencia de ejecución. Créelo o verifique su contenido:APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "7";El valor
"1"significa ejecución diaria. En Ubuntu, el servicioapt-daily-upgrade.timerse habilita automáticamente tras esta configuración. Verifique su estado:systemctl status apt-daily-upgrade.timerVerificar los registros
Los registros de instalación se escriben en
/var/log/unattended-upgrades/. El archivo principal:tail -50 /var/log/unattended-upgrades/unattended-upgrades.logUna línea de éxito tiene este aspecto:
2026-09-25 04:12:31,847 INFO Packages that will be upgraded: libssl3 openssl 2026-09-25 04:12:45,021 INFO Package libssl3 upgraded to 3.0.2-0ubuntu1.17En caso de fallo, el archivo
unattended-upgrades-dpkg.logconserva la salida completa dedpkgpara el diagnóstico.Probar la ejecución bajo demanda
Para desencadenar una ejecución inmediata sin esperar al temporizador y verificar que la configuración es operativa:
unattended-upgrade --dry-run --debug 2>&1 | head -60La opción
--dry-runsimula la instalación sin realizar cambios. Elimínela para una ejecución real:unattended-upgrade -vSi la salida muestra
No packages found that can be upgraded unattended, el sistema está actualizado o no hay ningún paquete elegible pendiente — este es el resultado esperado en un servidor aprovisionado recientemente.
Configurar las notificaciones por correo
Las notificaciones por correo permiten al equipo recibir una alerta cuando una actualización falla o cuando se requiere un reinicio. No envían nada en caso de éxito silencioso — lo que evita saturar la bandeja de entrada con informes diarios.
En /etc/apt/apt.conf.d/50unattended-upgrades, habilite la opción:
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "only-on-error";El valor only-on-error (recomendado) solo envía un correo en caso de error. El valor on-change envía un correo con cada instalación. El valor always envía un correo incluso cuando no se instala nada — evítelo en una flota de varias decenas de máquinas.
Para que el envío funcione, el servidor debe disponer de un MTA local capaz de reenviar correos. En un VPS mínimo, postfix en modo satellite es la opción más ligera:
apt-get install -y postfix
# Seleccione "Satellite system" en el asistente
# Introduzca el relay SMTP de su proveedor o infraestructuraAlternativamente, msmtp puede servir como relay hacia un servicio transaccional (Mailgun, Postmark, SendGrid) sin instalar un MTA completo.
Monitorizar los reinicios necesarios con needrestart
Algunos parches de seguridad — en particular los del kernel, la libc o OpenSSL — requieren un reinicio para estar completamente activos. La herramienta needrestart detecta los servicios y procesos que todavía usan las versiones antiguas en memoria.
Instálela con:
apt-get install -y needrestartTras cada actualización, needrestart lista los servicios que deben reiniciarse. En modo automático ($nrconf{restart} = 'a'; en /etc/needrestart/needrestart.conf), reinicia los servicios afectados sin intervención. Para los kernels, nunca reinicia la máquina automáticamente sin configuración explícita — este es el comportamiento esperado en un VPS de producción.
Combine needrestart con las notificaciones de unattended-upgrades: un correo indicando que se requiere un reinicio permite al equipo planificar la intervención en el momento adecuado, sin urgencia pero sin dilación.
Reinicio automático para parches del kernel
El reinicio automático tras un parche del kernel es la decisión más delicada en una política de actualizaciones. Garantiza que la corrección esté activa inmediatamente, pero interrumpe los servicios en ejecución — lo que puede ser inaceptable para ciertas cargas de trabajo.
En /etc/apt/apt.conf.d/50unattended-upgrades, las opciones pertinentes:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";Automatic-Reboot-Time programa el reinicio en una hora de baja actividad. Automatic-Reboot-WithUsers "false" impide el reinicio si hay una sesión de usuario abierta.
Precauciones imprescindibles antes de activar esta opción:
- Verifique que sus servicios se reinician automáticamente al arrancar (systemctl is-enabled <service>).
- Pruebe el tiempo de reinicio completo en un servidor de staging antes de desplegar en producción.
- Si su aplicación requiere un orden de arranque específico, documente y pruebe ese escenario.
- Para una flota multi-VPS, escalone los horarios de reinicio — vea la sección siguiente.
Actualizaciones manuales vs automáticas: comparativa
Desplace la tabla
| Criterio | Actualización manual | Actualización automática (unattended-upgrades) |
|---|---|---|
| Tiempo de aplicación | Depende del calendario de mantenimiento — normalmente 3 a 7 días | Pocas horas tras la publicación en los repositorios estables |
| Trazabilidad | Depende del rigor de las notas de mantenimiento | Registro con marca de tiempo automática en `/var/log/unattended-upgrades/` |
| Riesgo de regresión | Controlado: cada actualización se valida antes de aplicarse | Bajo en parches de seguridad estables, mitigado por la lista negra |
| Carga operativa | Alta en una flota de más de 5 VPS | Despreciable una vez desplegada la configuración |
| Parches del kernel activos | Inmediato si se programa el reinicio | Requiere configurar el reinicio automático o intervención manual |
| Cobertura de CVE críticos | Insuficiente si el ciclo es semanal | Óptima — los parches se aplican en la ventana más estrecha posible |
| Cumplimiento documentable | Difícil de probar sin herramientas adicionales | Archivos de registro y configuración versionables y auditables |
Desplegar y gestionar unattended-upgrades en una flota multi-VPS
La configuración descrita hasta ahora se aplica a un único servidor. Para una flota de decenas de VPS de clientes, la reproducibilidad y la coordinación se convierten en retos por derecho propio.
Automatizar con Ansible
Un rol Ansible sencillo es suficiente para desplegar la configuración en toda la flota en pocos minutos. Almacene los archivos 50unattended-upgrades y 20auto-upgrades en templates/ y haga configurables las opciones de reinicio mediante variables de inventario:
- name: Desplegar unattended-upgrades
hosts: vps_clients
become: true
tasks:
- name: Instalar unattended-upgrades
apt:
name: [unattended-upgrades, apt-listchanges]
state: present
update_cache: true
- name: Desplegar la configuración
template:
src: 50unattended-upgrades.j2
dest: /etc/apt/apt.conf.d/50unattended-upgrades
owner: root
mode: '0644'
- name: Desplegar apt-periodic
copy:
src: 20auto-upgrades
dest: /etc/apt/apt.conf.d/20auto-upgrades
owner: root
mode: '0644'Escalonar los reinicios
Si el reinicio automático está habilitado, no configure la misma hora en todos sus servidores. Un reinicio simultáneo de 30 VPS puede generar una carga de reconexión inusual en su infraestructura y complicar el diagnóstico en caso de problemas. Distribuya los horarios en una ventana de dos horas usando una variable Ansible por grupo o por servidor.
Probar en staging antes de la flota de producción
Para las configuraciones que habilitan el reinicio automático o modifican la lista negra de paquetes, valide primero en un servidor de staging representativo. Un VPS a 99 DH/mes dedicado a pruebas de configuración evita propagar un error de configuración a toda la flota.
Centralizar las alertas
En lugar de recibir correos individuales de cada servidor, configure un alias de correo que agregue las alertas en un canal de supervisión único. Si su infraestructura ya utiliza un agregador de registros (Loki, OpenSearch), los archivos de registro de unattended-upgrades pueden enviarse allí mediante un agente ligero para una vista centralizada de la flota.
Para profundizar en la seguridad de sus VPS, consulte nuestra checklist de hardening Linux y nuestra comparativa CrowdSec vs Fail2ban. Si también gestiona aplicaciones self-hosted, la rutina de parches para aplicaciones self-hosted complementa este enfoque con las capas de aplicación.
