La plupart des intrusions réussies sur des serveurs ne passent pas par des exploits sophistiqués mais par une vulnérabilité dont le correctif est sorti il y a des mois. La raison n’est généralement pas la paresse : mettre à jour à la main sur un serveur en production fait peur, parce qu’apt upgrade redémarre parfois ce qu’on ne lui avait pas demandé. Les mises à jour automatiques règlent la question, mais elles ont mauvaise réputation — méritée exactement dans la mesure où on les configure à la hâte.

Voyons une configuration où les correctifs de sécurité arrivent seuls et où la version de PHP ne change pas pendant la nuit.

Installation

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Le dialogue crée /etc/apt/apt.conf.d/20auto-upgrades. Vérifiez ce qui en est sorti :

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

Les uns signifient « quotidiennement ». Tout cela est déclenché par une minuterie systemd, et non par le cron classique :

systemctl list-timers | grep apt

L’essentiel : la sécurité seulement

Le fichier principal est /etc/apt/apt.conf.d/50unattended-upgrades. Il contient une liste Allowed-Origins (sous Debian, Origins-Pattern), et par défaut seul le dépôt de sécurité y est activé. Laissez-le ainsi.

La tentation de décommenter la ligne avec -updates — « que tout se mette à jour » — est forte. Ne le faites pas : le dépôt des mises à jour apporte de nouvelles versions et pas seulement des correctifs, et c’est précisément de là que viennent les surprises nocturnes. Sécurité et fraîcheur sont deux tâches différentes, et la seconde se fait mieux à la main, quand vous êtes au clavier.

Si un paquet ne doit pas être mis à jour automatiquement, il existe une liste noire :

Unattended-Upgrade::Package-Blacklist {
    "mariadb-server";
    "php8.3-fpm";
};

Servez-vous-en sciemment : chaque ligne y signifie « ce paquet, je le mets à jour moi-même » — et cette promesse devra être tenue.

Les redémarrages

La ligne clé :

Unattended-Upgrade::Automatic-Reboot "false";

Laisser false est juste pour un serveur hébergeant un site : un redémarrage sans préavis à trois heures du matin est pire qu’un correctif reporté d’un jour. Mais cette décision a une seconde moitié obligatoire, et c’est elle qu’on oublie.

Quand le noyau, libc ou openssl sont mis à jour, le système crée le fichier /var/run/reboot-required. Tant que le redémarrage n’a pas eu lieu, la version corrigée est sur le disque tandis que l’ancienne tourne en mémoire — la vulnérabilité n’a donc nullement disparu, même si le paquet compte pour mis à jour. Vérifiez-le explicitement :

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Le second fichier énumère ce qui a rendu le redémarrage nécessaire. La règle est simple : dès que vous voyez l’indicateur, planifiez une fenêtre dans les un ou deux jours qui viennent, et non « un jour ».

Les bibliothèques sont un cas à part. openssl est mis à jour tandis que nginx et PHP-FPM continuent de tourner avec l’ancienne version en mémoire, et aucun indicateur de redémarrage n’apparaît. Qui a besoin d’un redémarrage, needrestart le montre :

sudo apt install needrestart
sudo needrestart -b

Mettez-le seulement en mode « afficher, ne pas demander » — sinon il commencera à poser des questions au milieu d’une installation non interactive et la bloquera. Pour cela, déposez dans /etc/needrestart/conf.d/ un fichier contenant la ligne $nrconf{restart} = 'l';.

Vérifier que cela fonctionne

Un essai sans installation :

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

La sortie montre quels paquets correspondent aux règles et lesquels ont été écartés, et pourquoi. Ce qui s’est réellement passé est dans les journaux :

sudo tail -50 /var/log/unattended-upgrades/unattended-upgrades.log

Combien de mises à jour attendent en ce moment :

apt list --upgradable 2>/dev/null | grep -i security

Cette dernière commande est la plus utile de toutes. Des mises à jour automatiques configurées ont l’habitude de casser en silence : plus de place sur /boot, un dépôt qui a changé de clé, une minuterie désactivée après une modification manuelle. En apparence tout va bien, et les correctifs ne s’installent plus depuis des mois.

La place sur /boot

Un classique : les anciens noyaux ne sont pas supprimés, la partition /boot se remplit, l’installation d’un nouveau noyau échoue, et les mises à jour s’arrêtent dans leur ensemble. Tous les quelques mois, un coup d’œil vaut la peine :

df -h /boot
sudo apt autoremove --purge

Ou activez le nettoyage automatique dans ce même 50unattended-upgrades : Remove-Unused-Kernel-Packages "true" et Remove-Unused-Dependencies "true".

Ce qui reste à l’humain

Les mises à jour automatiques enlèvent la routine, pas la surveillance. Deux questions auxquelles vous devriez pouvoir répondre à tout moment : combien de mises à jour de sécurité attendent, et si l’indicateur de redémarrage est levé. Les deux réponses tiennent chacune en une ligne sur une page, et tout l’intérêt est que cette ligne vous saute aux yeux d’elle-même, et non à votre initiative une fois par trimestre.