[{"data":1,"prerenderedAt":183},["ShallowReactive",2],{"seo-verification":3,"blog-actualizaciones-seguridad-vps-debian-ubuntu-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-actualizaciones-seguridad-vps-debian-ubuntu-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":123,"ctaBody":124,"ctaButton":125,"ctaUrl":126,"relatedPosts":127},382,"actualizaciones-seguridad-vps-debian-ubuntu",{"fr":12,"en":13,"ar":14,"es":10},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","vps-automatic-security-updates-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","Actualizaciones de seguridad automáticas en VPS Debian\u002FUbuntu","Configure unattended-upgrades en sus VPS Debian\u002FUbuntu para automatizar los parches de seguridad y reducir la superficie de ataque en su flota de clientes.",10,0,false,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg","Un VPS expuesto en internet sin una política de actualización es una superficie de ataque abierta. Las vulnerabilidades críticas se explotan en cuestión de horas tras la publicación de un CVE, mucho antes de que cualquier intervención manual sea posible. Configurar **unattended-upgrades** en cada servidor Debian o Ubuntu de su flota es la medida más sencilla para reducir mecánicamente esa ventana de exposición, sin renunciar al control sobre lo que se aplica.",[35,39,49,52,55,74,77,81,84,120],{"type":36,"title":37,"body":38},"h2","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.\n\nLa 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.\n\nEl 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.",{"type":40,"title":41,"items":42},"ul","Beneficios concretos para las agencias que gestionan una flota de clientes",[43,44,45,46,47,48],"**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 `\u002Fvar\u002Flog\u002Funattended-upgrades\u002F`, 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.",{"type":36,"title":50,"body":51},"Cómo funciona unattended-upgrades","`unattended-upgrades` es un demonio de Debian\u002FUbuntu 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.\n\nLa 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.\n\nEl 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.",{"type":36,"title":53,"body":54},"Requisitos previos","La configuración descrita en este artículo se aplica a **Debian 11\u002F12** y **Ubuntu 22.04\u002F24.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.\n\nAcceso 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.\n\nSi 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.",{"type":56,"title":57,"steps":58},"steps","Instalar y configurar unattended-upgrades",[59,62,65,68,71],{"title":60,"body":61},"Instalar el paquete","En Debian y Ubuntu, el paquete está disponible en los repositorios estándar:\n\n```bash\napt-get update\napt-get install -y unattended-upgrades apt-listchanges\n```\n\nEl paquete `apt-listchanges` es opcional pero recomendado: permite incluir el resumen de cambios en las notificaciones por correo.",{"title":63,"body":64},"Configurar los orígenes permitidos","Edite `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades`. La sección `Unattended-Upgrade::Allowed-Origins` controla qué repositorios son elegibles. En Ubuntu 22.04, la configuración mínima recomendada:\n\n```\nUnattended-Upgrade::Allowed-Origins {\n    \"${distro_id}:${distro_codename}-security\";\n    \"${distro_id}ESMApps:${distro_codename}-apps-security\";\n    \"${distro_id}ESM:${distro_codename}-infra-security\";\n};\n```\n\nEn Debian 12, reemplace con:\n\n```\nUnattended-Upgrade::Allowed-Origins {\n    \"Debian:${distro_codename}-security\";\n};\n```\n\nPara excluir paquetes sensibles (por ejemplo un núcleo personalizado o una versión fijada de PHP):\n\n```\nUnattended-Upgrade::Package-Blacklist {\n    \"linux-image\";\n    \"php8.2-fpm\";\n};\n```",{"title":66,"body":67},"Activar el temporizador periódico","El archivo `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F20auto-upgrades` controla la frecuencia de ejecución. Créelo o verifique su contenido:\n\n```\nAPT::Periodic::Update-Package-Lists \"1\";\nAPT::Periodic::Unattended-Upgrade \"1\";\nAPT::Periodic::AutocleanInterval \"7\";\n```\n\nEl valor `\"1\"` significa ejecución diaria. En Ubuntu, el servicio `apt-daily-upgrade.timer` se habilita automáticamente tras esta configuración. Verifique su estado:\n\n```bash\nsystemctl status apt-daily-upgrade.timer\n```",{"title":69,"body":70},"Verificar los registros","Los registros de instalación se escriben en `\u002Fvar\u002Flog\u002Funattended-upgrades\u002F`. El archivo principal:\n\n```bash\ntail -50 \u002Fvar\u002Flog\u002Funattended-upgrades\u002Funattended-upgrades.log\n```\n\nUna línea de éxito tiene este aspecto:\n\n```\n2026-09-25 04:12:31,847 INFO Packages that will be upgraded: libssl3 openssl\n2026-09-25 04:12:45,021 INFO Package libssl3 upgraded to 3.0.2-0ubuntu1.17\n```\n\nEn caso de fallo, el archivo `unattended-upgrades-dpkg.log` conserva la salida completa de `dpkg` para el diagnóstico.",{"title":72,"body":73},"Probar la ejecución bajo demanda","Para desencadenar una ejecución inmediata sin esperar al temporizador y verificar que la configuración es operativa:\n\n```bash\nunattended-upgrade --dry-run --debug 2>&1 | head -60\n```\n\nLa opción `--dry-run` simula la instalación sin realizar cambios. Elimínela para una ejecución real:\n\n```bash\nunattended-upgrade -v\n```\n\nSi 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.",{"type":36,"title":75,"body":76},"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.\n\nEn `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades`, habilite la opción:\n\n```\nUnattended-Upgrade::Mail \"ops@su-agencia.com\";\nUnattended-Upgrade::MailReport \"only-on-error\";\n```\n\nEl 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.\n\nPara 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:\n\n```bash\napt-get install -y postfix\n# Seleccione \"Satellite system\" en el asistente\n# Introduzca el relay SMTP de su proveedor o infraestructura\n```\n\nAlternativamente, `msmtp` puede servir como relay hacia un servicio transaccional (Mailgun, Postmark, SendGrid) sin instalar un MTA completo.",{"type":78,"title":79,"body":80},"tip","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.\n\nInstálela con:\n\n```bash\napt-get install -y needrestart\n```\n\nTras cada actualización, `needrestart` lista los servicios que deben reiniciarse. En modo automático (`$nrconf{restart} = 'a';` en `\u002Fetc\u002Fneedrestart\u002Fneedrestart.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.\n\nCombine `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.",{"type":36,"title":82,"body":83},"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.\n\nEn `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades`, las opciones pertinentes:\n\n```\nUnattended-Upgrade::Automatic-Reboot \"true\";\nUnattended-Upgrade::Automatic-Reboot-WithUsers \"false\";\nUnattended-Upgrade::Automatic-Reboot-Time \"03:00\";\n```\n\n`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.\n\n**Precauciones imprescindibles antes de activar esta opción**:\n- Verifique que sus servicios se reinician automáticamente al arrancar (`systemctl is-enabled \u003Cservice>`).\n- Pruebe el tiempo de reinicio completo en un servidor de staging antes de desplegar en producción.\n- Si su aplicación requiere un orden de arranque específico, documente y pruebe ese escenario.\n- Para una flota multi-VPS, escalone los horarios de reinicio — vea la sección siguiente.",{"type":85,"title":86,"headers":87,"rows":91},"comparison","Actualizaciones manuales vs automáticas: comparativa",[88,89,90],"Criterio","Actualización manual","Actualización automática (unattended-upgrades)",[92,96,100,104,108,112,116],[93,94,95],"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",[97,98,99],"Trazabilidad","Depende del rigor de las notas de mantenimiento","Registro con marca de tiempo automática en `\u002Fvar\u002Flog\u002Funattended-upgrades\u002F`",[101,102,103],"Riesgo de regresión","Controlado: cada actualización se valida antes de aplicarse","Bajo en parches de seguridad estables, mitigado por la lista negra",[105,106,107],"Carga operativa","Alta en una flota de más de 5 VPS","Despreciable una vez desplegada la configuración",[109,110,111],"Parches del kernel activos","Inmediato si se programa el reinicio","Requiere configurar el reinicio automático o intervención manual",[113,114,115],"Cobertura de CVE críticos","Insuficiente si el ciclo es semanal","Óptima — los parches se aplican en la ventana más estrecha posible",[117,118,119],"Cumplimiento documentable","Difícil de probar sin herramientas adicionales","Archivos de registro y configuración versionables y auditables",{"type":36,"title":121,"body":122},"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.\n\n**Automatizar con Ansible**\n\nUn 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\u002F` y haga configurables las opciones de reinicio mediante variables de inventario:\n\n```yaml\n- name: Desplegar unattended-upgrades\n  hosts: vps_clients\n  become: true\n  tasks:\n    - name: Instalar unattended-upgrades\n      apt:\n        name: [unattended-upgrades, apt-listchanges]\n        state: present\n        update_cache: true\n    - name: Desplegar la configuración\n      template:\n        src: 50unattended-upgrades.j2\n        dest: \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades\n        owner: root\n        mode: '0644'\n    - name: Desplegar apt-periodic\n      copy:\n        src: 20auto-upgrades\n        dest: \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F20auto-upgrades\n        owner: root\n        mode: '0644'\n```\n\n**Escalonar los reinicios**\n\nSi 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.\n\n**Probar en staging antes de la flota de producción**\n\nPara 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\u002Fmes dedicado a pruebas de configuración evita propagar un error de configuración a toda la flota.\n\n**Centralizar las alertas**\n\nEn 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.\n\nPara profundizar en la seguridad de sus VPS, consulte nuestra \u003Ca href=\"\u002Fblog\u002Flinux-hardening-vps-checklist\">checklist de hardening Linux\u003C\u002Fa> y nuestra comparativa \u003Ca href=\"\u002Fblog\u002Fcrowdsec-vs-fail2ban-securite-vps\">CrowdSec vs Fail2ban\u003C\u002Fa>. Si también gestiona aplicaciones self-hosted, la \u003Ca href=\"\u002Fblog\u002Froutine-correctifs-apps-self-hosted\">rutina de parches para aplicaciones self-hosted\u003C\u002Fa> complementa este enfoque con las capas de aplicación.","Gestione una flota de VPS de clientes sin fricciones","ServOrbit.com ofrece VPS gestionados desde 99 DH\u002Fmes, con aprovisionamiento automatizado y panel centralizado para agencias y revendedores.","Gestionar mi flota de VPS","\u002Fsolutions\u002Fagences",[128,145,168],{"id":129,"slug":130,"slugs":131,"title":135,"excerpt":136,"readTime":137,"views":138,"isPinned":19,"publishedAt":139,"updatedAt":140,"category":141,"categories":142,"featuredImage":30,"bgImage":31,"posterImage":144,"relatedSolution":30},317,"hardening-linux-vps-checklist-para-agencias-tras-la-entrega",{"fr":132,"en":133,"ar":134,"es":130},"linux-hardening-vps-checklist","linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","Hardening Linux VPS : checklist para agencias tras la entrega","Checklist de hardening Linux reproducible para agencias: auditd, sudo, clave SSH, UFW, fail2ban y desactivación de root — con trazabilidad por cliente.",11,1,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[143],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":146,"slug":147,"slugs":148,"title":152,"excerpt":153,"readTime":154,"views":155,"isPinned":19,"publishedAt":156,"updatedAt":157,"category":158,"categories":163,"featuredImage":30,"bgImage":31,"posterImage":165,"relatedSolution":166},348,"crowdsec-vs-fail2ban-cual-elegir-para-tu-vps",{"fr":149,"en":150,"ar":151,"es":147},"crowdsec-vs-fail2ban-securite-vps","crowdsec-vs-fail2ban-which-to-choose-for-your-vps","crowdsec-مقابل-fail2ban-ايهما-تختار-لخادمك","CrowdSec vs Fail2ban: cuál elegir para proteger tu VPS","¿CrowdSec o Fail2ban en tu VPS Linux? Comparativa por caso de uso: lista de bloqueo comunitaria o simplicidad local — el árbol de decisión para elegir.",7,3,"2026-09-11T00:00:00+00:00","2026-09-11T11:34:13+00:00",{"id":159,"name":160,"slug":161,"color":162,"icon":161},5,"Comparativas","comparatif","bg-info\u002F10 text-info",[164],{"id":159,"name":160,"slug":161,"color":162,"icon":161},"\u002Fblog\u002Fcovers\u002Fcrowdsec-vs-fail2ban-securite-vps-poster.svg",{"categorySlug":167,"appSlug":30},"ciberseguridad-bastion",{"id":169,"slug":170,"slugs":171,"title":175,"excerpt":176,"readTime":177,"views":138,"isPinned":19,"publishedAt":178,"updatedAt":140,"category":179,"categories":180,"featuredImage":30,"bgImage":31,"posterImage":182,"relatedSolution":30},224,"apps-self-hosted-rutina-de-parches",{"fr":172,"en":173,"ar":174,"es":170},"routine-correctifs-apps-self-hosted","self-hosted-apps-the-patching-routine","التطبيقات-المستضافة-ذاتيا-روتين-التصحيحات","Aplicaciones self-hosted: la rutina de parches","Inventario, avisos de seguridad, ventana de parcheo, copia de seguridad y verificación: la rutina que falta en la mayoría de los parques self-hosted.",4,"2026-08-05T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[181],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",1790693288174]