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 : Installer et activer le paquet

Sur Ubuntu Server 24.04, le paquet est installé et activé par défaut. La documentation serveur d’Ubuntu indique que unattended-upgrades est installé par défaut et que l’installation automatique des mises à jour de sécurité est activée juste après l’installation. Lors de l’installation, la question d’activation posée par le paquet propose oui par défaut. Sauf réponse explicite négative, la tâche quotidienne est donc déjà active. Une image de fournisseur personnalisée ou allégée peut toutefois se comporter différemment. Vérifiez sa configuration au lieu de la supposer. Ces commandes sont sans risque dans les deux cas : elles installent le paquet s’il est absent et reposent la question qui l’active :

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

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

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. Lorsque les deux paramètres sont définis sur 1, la machine recherche et installe chaque jour les mises à jour de sécurité, au moyen d’un timer systemd, sans autre intervention de votre part.

Étape 2 : Déterminez ce qui est appliqué automatiquement

La règle se trouve 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 règle prudente : les mises à jour de sécurité sont installées automatiquement, tandis que les mises à jour fonctionnelles ordinaires restent à appliquer manuellement, quand vous le décidez. Vous pouvez décommenter la ligne "${distro_id}:${distro_codename}-updates" dans le même bloc pour installer aussi automatiquement les mises à jour stables courantes d’Ubuntu. La règle s’applique alors uniquement à l’archive -updates d’Ubuntu, pas à tous les dépôts ni à tous les PPA présents sur la machine. Les contrôles habituels restent applicables : l’outil retient tout paquet qui provoquerait une demande concernant un fichier de configuration et n’installe rien si ses dépendances ne peuvent pas provenir d’une source autorisée. Pour un serveur qui héberge un service important, installer automatiquement uniquement les correctifs de sécurité est le choix le plus sûr par défaut. Conservez la configuration fournie, sauf si vous avez une raison précise de la modifier.

É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.