Unattended-upgrades : mises à jour auto Ubuntu

Pourquoi les mises à jour de sécurité automatiques valent la peine

Un serveur qui n'est pas mis à jour est la cible la plus facile de tout l'internet. La plupart des compromissions de petits serveurs n'ont rien de subtil : ce sont un bug connu dans un paquet ancien que le propriétaire n'a jamais mis à jour. Ubuntu fournit un outil qui comble cet écart tout seul : unattended-upgrades installe les mises à jour de sécurité automatiquement, selon un planning, sans que vous ayez à vous connecter. C'est le gain de sécurité le moins coûteux disponible sur un VPS, et sur Ubuntu il ne demande que quelques minutes de configuration.

L'outil est délibérément prudent. Par défaut, il n'applique que les mises à jour de sécurité, pas chaque montée de version de paquet, car un correctif de sécurité présente peu de risque et mérite d'être pris sans examen, tandis qu'une mise à niveau de fonctionnalité peut modifier un comportement sur lequel vous comptiez. Ce réglage par défaut est le bon pour la plupart des serveurs, et ce guide le conserve tout en vous montrant les quelques paramètres qui valent la peine d'être changés.

Étape 1 : installer et activer l'outil

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 par oui ou non : faut-il télécharger et installer les mises à jour stables automatiquement. 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 rafraîchit la liste des paquets chaque jour ; la seconde exécute la mise à jour automatique chaque jour. Toutes deux réglées à 1 signifient que la machine recherche et applique les mises à jour de sécurité tous les jours, via un timer systemd, sans aucune autre action de votre part.

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

La politique se trouve dans /etc/apt/apt.conf.d/50unattended-upgrades. Ouvrez ce fichier et regardez le bloc Allowed-Origins près du 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. C'est la politique prudente : les mises à jour de sécurité entrent, les mises à jour de fonctionnalité ordinaires vous sont laissées à appliquer à la main quand vous le choisissez. Vous pouvez ajouter la ligne d'origine "${distro_id}:${distro_codename}-updates" pour appliquer automatiquement toutes les mises à jour, mais pour un serveur qui héberge quelque chose qui vous tient à cœur, ne prendre automatiquement que les correctifs de sécurité est le réglage par défaut le plus sûr. Laissez-le tel qu'il est livré, sauf raison précise de faire autrement.

Étape 3 : gérer les redémarrages

Certaines mises à jour, un noyau ou une bibliothèque centrale, ne prennent pleinement effet qu'après un redémarrage. unattended-upgrades ne redémarrera pas votre serveur sauf si vous le lui demandez, ce qui veut dire qu'un noyau corrigé peut rester inutilisé jusqu'à ce que vous redémarriez par hasard. Décidez comment vous voulez gérer cela, et réglez-le explicitement dans 50unattended-upgrades :

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

Cela redémarre le serveur à quatre heures du matin quand, et seulement quand, une mise à jour l'exige. Sur un VPS unique sans cluster vers lequel basculer, un bref redémarrage en début de matinée est en général le bon compromis pour rester à jour sur les correctifs du noyau. Si votre serveur fait tourner quelque chose qui ne doit jamais redémarrer à l'improviste, laissez le redémarrage désactivé et prenez l'habitude de redémarrer vous-même après avoir vérifié /var/run/reboot-required.

Étape 4 : prouver que ça fonctionne

N'attendez pas une journée pour savoir si la tâche s'exécute. Lancez un essai à blanc qui montre exactement ce qui serait appliqué, sans rien changer :

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

La sortie liste les paquets qu'il considère et les origines dont ils proviennent, de sorte que vous pouvez voir la politique à l'œuvre. Une fois que la vraie tâche s'est exécutée au moins une fois, sa trace se trouve ici :

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

Ce journal est la réponse à la question « mon serveur se met-il vraiment à jour tout seul ». S'il montre des paquets de sécurité installés selon un planning, la tâche fonctionne.

Où cela s'inscrit

Les mises à jour automatiques sont une couche d'un serveur renforcé, pas l'ensemble. Elles empêchent les bugs connus de s'attarder, mais elles ne font rien contre qui peut se connecter ou ce qui est exposé. Associez-les à un renforcement SSH par clé uniquement pour que la porte d'entrée ne puisse pas être forcée par force brute, à un pare-feu UFW en refus par défaut pour que seul ce que vous choisissez soit joignable, et à des comptes de service non privilégiés pour qu'une application compromise ne puisse pas prendre toute la machine. La mise à jour ferme les trous que vous connaissez ; les autres couches limitent les dégâts de ceux que vous ignorez.

FAQ

unattended-upgrades applique-t-il toutes les mises à jour ou seulement 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 laisse les mises à jour de fonctionnalité ordinaires à appliquer à la main. C'est délibéré : les correctifs de sécurité présentent peu de risque et méritent d'être pris automatiquement, tandis que les mises à niveau de fonctionnalité peuvent modifier le comportement, donc la plupart des serveurs devraient garder le réglage par défaut prudent.

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

Seulement si vous le leur demandez. Définissez Unattended-Upgrade::Automatic-Reboot "true" et un Automatic-Reboot-Time dans la configuration, et le serveur redémarre à cette heure lorsqu'une mise à jour l'exige, par exemple après un correctif du noyau. Laissé désactivé, un noyau corrigé attend que vous redémarriez vous-même ; vérifiez /var/run/reboot-required pour savoir quand un redémarrage est en attente.

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

Lancez sudo unattended-upgrade --dry-run --debug pour voir ce qui serait appliqué à l'instant, sans rien changer, et lisez /var/log/unattended-upgrades/unattended-upgrades.log pour la trace des exécutions passées ; chaque installation automatique atterrit aussi dans /var/log/apt/history.log. Si le journal montre des paquets de sécurité installés selon un planning quotidien, le timer fonctionne. Si l'essai à blanc affiche No packages found that can be upgraded unattended, soit tout est déjà à jour, soit vos origines autorisées sont trop étroites pour correspondre au dépôt de sécurité.

unattended-upgrades suffit-il à garder mon serveur sécurisé ?

Non, mais c'est une couche nécessaire. Il empêche les vulnérabilités connues de s'attarder sans correctif, ce qui stoppe le type de compromission le plus courant, mais il ne contrôle ni l'accès ni l'exposition. Combinez-le avec un renforcement SSH, un pare-feu en refus par défaut et des comptes de service à privilège minimal pour un serveur véritablement difficile à pénétrer.