Ubuntu 24.04 : unattended-upgrades est-il activé ?

Pourquoi les mises à jour de sécurité automatiques valent la peine d’être configurées

Un serveur qui n’est pas corrigé est la cible la plus facile sur Internet. La plupart des compromissions de petits serveurs ne reposent pas sur une méthode sophistiquée : elles exploitent un bug connu dans un ancien paquet que le propriétaire n’a jamais mis à jour. Ubuntu fournit un outil qui comble automatiquement cette lacune : unattended-upgrades installe les mises à jour de sécurité selon un calendrier, sans que vous ayez à vous connecter. C’est la mesure de sécurité la plus simple à mettre en place sur un VPS et, sur Ubuntu, sa configuration ne prend que quelques minutes.

L’outil reste volontairement conservateur. Par défaut, il applique uniquement les mises à jour de sécurité, et non toutes les mises à niveau de paquets, car un correctif de sécurité présente peu de risques et mérite d’être installé sans vérification, tandis qu’une mise à niveau fonctionnelle peut modifier un comportement dont vous dépendez. Ce réglage convient à la plupart des serveurs. Ce guide le conserve et présente les quelques paramètres qui méritent d’être modifiés.

Étape 1 : l’installer et l’activer

Sur Ubuntu 24.04, le paquet est souvent présent, mais pas toujours activé. Installez-le et activez-le :

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

L’invite dpkg-reconfigure pose une seule question, à laquelle vous devez répondre par oui ou par non : voulez-vous télécharger et installer automatiquement les mises à jour stables ? Répondez oui. Le fichier qui active la tâche quotidienne est alors écrit :

cat /etc/apt/apt.conf.d/20auto-upgrades

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

La première ligne actualise quotidiennement la liste des paquets ; la seconde exécute quotidiennement la mise à niveau automatique. Avec 1 dans les deux cas, la machine recherche et applique chaque jour les mises à jour de sécurité, au moyen d’un timer systemd, sans autre intervention de votre part.

Étape 2 : décider ce qui est appliqué automatiquement

La stratégie est définie dans /etc/apt/apt.conf.d/50unattended-upgrades. Ouvrez ce fichier et recherchez le bloc Allowed-Origins vers le début :

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";
};

Les lignes -security sont celles qui comptent et elles sont activées par défaut. Il s’agit de la stratégie conservatrice : les mises à jour de sécurité sont appliquées automatiquement, tandis que les mises à jour fonctionnelles ordinaires restent à votre charge. Vous pouvez ajouter la ligne d’origine "${distro_id}:${distro_codename}-updates" pour appliquer automatiquement toutes les mises à jour. Toutefois, pour un serveur qui héberge un service important, appliquer automatiquement uniquement les correctifs de sécurité reste le choix le plus sûr. Conservez la configuration fournie par défaut, sauf raison précise de faire autrement.

Étape 3 : gérer les redémarrages

Certaines mises à jour, notamment celles du kernel ou d’une bibliothèque système, ne prennent pleinement effet qu’après un redémarrage. unattended-upgrades ne redémarrera pas votre serveur sans instruction explicite. Un kernel corrigé peut donc rester inutilisé jusqu’au prochain redémarrage. Décidez de la méthode à utiliser et configurez-la explicitement dans 50unattended-upgrades :

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

Cette configuration redémarre le serveur à quatre heures du matin, uniquement lorsqu’une mise à jour l’exige. Sur un VPS unique sans cluster vers lequel basculer le service, un bref redémarrage tôt le matin est généralement un compromis acceptable pour bénéficier des correctifs du kernel. Si votre serveur exécute un service qui ne doit jamais redémarrer de manière inattendue, laissez cette option désactivée et prenez l’habitude de redémarrer vous-même après avoir vérifié /var/run/reboot-required.

Étape 4 : vérifier que cela fonctionne

N’attendez pas un jour pour vérifier que la tâche s’exécute. Lancez une simulation qui affiche exactement ce qui serait appliqué, sans rien modifier :

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

La sortie liste les paquets pris en compte et leurs origines. Vous pouvez ainsi vérifier la stratégie appliquée. Après la première exécution réelle de la tâche, son journal se trouve ici :

cat /var/log/unattended-upgrades/unattended-upgrades.log

Ce journal permet de répondre à la question « mon serveur applique-t-il réellement ses correctifs ? ». S’il indique que des paquets de sécurité sont installés selon un calendrier, la tâche fonctionne.

À quel endroit cela s’intègre

Les mises à jour automatiques constituent une couche de protection d’un serveur renforcé, pas une solution complète. Elles empêchent les bugs connus de rester présents, mais ne contrôlent ni les personnes autorisées à se connecter ni les services exposés. Associez-les à un renforcement de SSH avec authentification par clé uniquement afin d’empêcher les attaques par force brute, à un pare-feu UFW en refus par défaut pour limiter l’accès à ce que vous autorisez, et à des utilisateurs de service non privilégiés afin qu’une application compromise ne puisse pas prendre le contrôle de toute la machine. Les applications que vous hébergez possèdent également leurs propres secrets. Si cette machine exécute un coffre-fort de mots de passe auto-hébergé, une configuration renforcée de Vaultwarden protège le jeton d’administration et le fichier de sauvegarde, que les mises à jour de apt ne peuvent pas protéger. Les correctifs comblent les failles que vous connaissez ; les autres couches limitent les dommages causés par celles que vous ne connaissez pas.

FAQ

unattended-upgrades applique-t-il toutes les mises à jour ou uniquement celles de sécurité ?

Par défaut, uniquement les mises à jour de sécurité. Le bloc Allowed-Origins dans /etc/apt/apt.conf.d/50unattended-upgrades active les origines -security et vous laisse appliquer manuellement les mises à jour fonctionnelles ordinaires. C’est volontaire : les correctifs de sécurité présentent peu de risques et méritent d’être installés automatiquement, tandis que les mises à niveau fonctionnelles peuvent modifier le comportement du système. La plupart des serveurs doivent donc conserver la configuration conservatrice par défaut.

Les mises à jour automatiques redémarreront-elles mon serveur ?

Uniquement si vous le demandez. Définissez Unattended-Upgrade::Automatic-Reboot "true" ainsi qu’un Automatic-Reboot-Time dans la configuration. Le serveur redémarrera à cette heure lorsqu’une mise à jour l’exige, par exemple après un correctif du kernel. Si cette option reste désactivée, un kernel corrigé attendra votre prochain redémarrage ; consultez /var/run/reboot-required pour savoir si un redémarrage est en attente.

Comment vérifier que les mises à jour automatiques s’exécutent réellement ?

Exécutez sudo unattended-upgrade --dry-run --debug pour voir ce qui serait appliqué immédiatement, sans rien modifier, et consultez /var/log/unattended-upgrades/unattended-upgrades.log pour l’historique des exécutions. Chaque installation automatique est également enregistrée dans /var/log/apt/history.log. Si le journal indique que des paquets de sécurité sont installés quotidiennement, le timer fonctionne. Si la simulation affiche No packages found that can be upgraded unattended, soit tous les paquets sont déjà à jour, soit les origines autorisées sont trop limitées pour correspondre au dépôt de sécurité.

unattended-upgrades suffit-il à sécuriser mon serveur ?

Non, mais c’est une couche nécessaire. Il empêche les vulnérabilités connues de rester non corrigées, ce qui bloque le type de compromission le plus courant. En revanche, il ne contrôle ni les accès ni l’exposition des services. Associez-le au renforcement de SSH, à un pare-feu en refus par défaut et à des utilisateurs de service appliquant le principe du moindre privilège pour obtenir un serveur réellement difficile à compromettre.