Appliquer les mises à jour de sécurité sous Linux

Les mises à jour de sécurité corrigent des vulnérabilités connues (CVE) dans le noyau, les bibliothèques et les services installés. Sur un serveur exposé, les appliquer vite est la première ligne de défense. Chaque distribution fournit de quoi cibler uniquement ces correctifs, sans emporter les montées de version fonctionnelles.

Ce guide montre les commandes qui fonctionnent, et démonte deux recettes très répandues qui ne patchent rien du tout tout en donnant au lecteur l'impression d'avoir sécurisé sa machine. C'est pire qu'une absence de correctif : c'est un correctif imaginaire.

Ce que vous allez apprendre

• Distinguer les mises à jour de sécurité des mises à jour classiques
• Lister les correctifs de sécurité disponibles sur Debian/Ubuntu et sur RHEL
• Appliquer uniquement les correctifs de sécurité, avec des commandes vérifiées
• Configurer les mises à jour automatiques sans qu'elles fassent plus que prévu
• Vérifier qu'un correctif est bien installé, et si un redémarrage s'impose
• Reconnaître les deux commandes qui ne patchent rien malgré les apparences

Dans quel contexte ?

Les mises à jour de sécurité sont critiques dans toute infrastructure :

• Un CVE critique est publié pour OpenSSL ou le noyau, il faut corriger dans les heures qui suivent.
• Votre serveur web est exposé sur Internet, chaque paquet obsolète élargit la surface d'attaque.
• La conformité impose un délai maximal de patching (30 jours pour les référentiels CIS ou ANSSI).
• Vous gérez une flotte de serveurs et devez automatiser sans risquer une régression.
• Avant un audit, vous devez prouver que le système est à jour sur les CVE critiques.

LFCS / RHCSA

La gestion des mises à jour est un objectif des deux certifications. Vous devez savoir appliquer les correctifs de sécurité et vérifier l'état de patch d'un système.

Mises à jour classiques et mises à jour de sécurité

Type	Contenu	Risque de régression	Urgence
Sécurité	Correctifs CVE, patches ciblés	Faible (changements minimaux)	Haute
Bugfix	Corrections de bugs fonctionnels	Moyen	Moyenne
Feature	Nouvelles fonctionnalités, montées de version	Élevé	Basse

Glissez pour voir

En production, la stratégie tient en une phrase : appliquer la sécurité automatiquement, et planifier le reste dans une fenêtre de maintenance.

Un quatrième cas échappe complètement à ce tableau : la montée de version majeure de la distribution, par exemple de Debian 12 à Debian 13. Ce n'est pas une mise à jour, c'est une migration, avec ses préparatifs et ses pièges (le nom des interfaces réseau peut changer, /etc/sysctl.conf cesse d'être lu, une base MariaDB mal arrêtée devient irrécupérable). Elle ne s'automatise pas : voyez Debian 13 « Trixie ».

Sur Debian et Ubuntu

Lister les correctifs de sécurité disponibles

Commencez par rafraîchir le catalogue des paquets. Cette commande ne modifie rien sur le système :

sudo apt update

Pour voir ce qui relève de la sécurité, on filtre sur l'origine du paquet, car c'est elle qui porte l'information :

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

libssl3t64/noble-security 3.0.13-0ubuntu3.6 amd64 [upgradable from: 3.0.13-0ubuntu3.4]
openssl/noble-security 3.0.13-0ubuntu3.6 amd64 [upgradable from: 3.0.13-0ubuntu3.4]

Le suffixe -security dans le nom de la suite (noble-security, bookworm-security) est ce qui distingue un correctif de sécurité d'une mise à jour ordinaire.

Ce filtre marche par chance, ne vous y fiez pas seul

grep -i security ne comprend rien à APT : il cherche une chaîne de caractères. Il fonctionne parce que le nom du dépôt de sécurité contient le mot, et il échouera sur un dépôt nommé autrement, ou vous renverra une ligne non pertinente qui contient « security » par hasard. C'est un aperçu, pas une source de vérité. La source de vérité, c'est unattended-upgrades --dry-run, décrit plus bas.

La commande qui ne patche rien

Voici la recette que l'on trouve partout, et sur ce site même jusqu'à cette relecture :

# NE FAITES PAS CELA : cette commande n'installe rien
sudo apt-get upgrade -y -o Dir::Etc::SourceList=/etc/apt/sources.list \
  -o Dir::Etc::SourceParts=/dev/null

L'idée semble maligne : restreindre APT au seul sources.list en neutralisant le reste. Elle ne fonctionne pas, et le lab le prouve. Sur une Ubuntu 24.04, en simulation :

apt-get -s upgrade                                    -> 7 paquets à installer
apt-get -s upgrade -o Dir::Etc::SourceList=...        -> 0 paquet à installer

Sept mises à jour disponibles, zéro appliquée. La raison est que depuis Ubuntu 24.04 et Debian 12, les dépôts ont migré vers le format deb822 : les vraies sources vivent dans /etc/apt/sources.list.d/ubuntu.sources, et /etc/apt/sources.list ne contient plus que des commentaires. La commande pointe donc un fichier vide, et SourceParts=/dev/null exclut le fichier qui compte. APT ne voit plus aucun dépôt, et n'a donc rien à installer.

Le pire n'est pas qu'elle échoue, c'est qu'elle échoue en silence : elle retourne 0, n'affiche aucune erreur, et vous laissez le serveur en croyant l'avoir patché.

La méthode qui fonctionne

Le seul outil qui sait vraiment ce qu'est une mise à jour de sécurité sur Debian et Ubuntu, c'est unattended-upgrades. Il lit l'origine des paquets, pas leur nom.

sudo apt install unattended-upgrades
sudo unattended-upgrades --dry-run -v

Allowed origins are: o=Ubuntu,a=noble, o=Ubuntu,a=noble-security,
  o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-security
Packages that will be upgraded: gzip libncursesw6 libtinfo6 ncurses-base
  ncurses-bin perl-base tar

Retirez --dry-run pour appliquer réellement. Mais lisez d'abord la ligne Allowed origins : elle contient un piège.

Par défaut, unattended-upgrades ne se limite PAS à la sécurité

Regardez la sortie ci-dessus, relevée sur une Ubuntu 24.04 vierge : les origines autorisées incluent a=noble, c'est-à-dire toutes les mises à jour de la distribution, et pas seulement noble-security. La configuration livrée par défaut contient ces deux lignes :

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
};

Autrement dit, l'outil que vous installez « pour la sécurité » appliquera aussi les mises à jour ordinaires, avec leur risque de régression. Sur un serveur de production, commentez la première ligne pour ne garder que -security.

Configurer les mises à jour automatiques

1. Installer le paquet. apt-listchanges est utile pour recevoir le détail de ce qui a changé.

   sudo apt install unattended-upgrades apt-listchanges

2. Restreindre aux correctifs de sécurité. C'est l'étape que la plupart des tutoriels sautent, et c'est la plus importante.

   sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

   Unattended-Upgrade::Allowed-Origins {
   //      "${distro_id}:${distro_codename}";          // commenté : pas le fonctionnel
           "${distro_id}:${distro_codename}-security";
   };
   
   Unattended-Upgrade::Automatic-Reboot "false";
   Unattended-Upgrade::Mail "admin@example.com";
   Unattended-Upgrade::Remove-Unused-Dependencies "true";

   Option	Recommandation en production
   Allowed-Origins	uniquement -security, la ligne du dépôt principal commentée
   Automatic-Reboot	false : le redémarrage se planifie, il ne se subit pas
   Mail	une adresse réellement lue, sinon l'automatisation est aveugle
   Remove-Unused-Dependencies	true pour éviter l'accumulation de paquets orphelins

   Glissez pour voir

3. Activer le service. Sans cette commande, la configuration existe mais rien ne l'exécute.

   sudo dpkg-reconfigure -plow unattended-upgrades

4. Vérifier que le résultat correspond à l'intention. C'est la seule preuve qui vaille : la liste des origines ne doit plus contenir que celles en -security.

   sudo unattended-upgrades --dry-run -v | grep "Allowed origins"
   systemctl status apt-daily-upgrade.timer

Vérifier ce qui a été appliqué

grep " upgrade " /var/log/apt/history.log | tail -5
sudo tail -20 /var/log/unattended-upgrades/unattended-upgrades.log

Le premier fichier journalise toutes les opérations APT, le second uniquement celles de l'automate. Comparer les deux révèle les mises à jour appliquées à la main, hors procédure.

Sur RHEL, Rocky et AlmaLinux

Lister les correctifs de sécurité

DNF, lui, comprend nativement la notion de correctif de sécurité, parce que Red Hat publie des avis (errata) qui lient un paquet à un CVE :

sudo dnf updateinfo list security

RLSA-2026:19224 Important/Sec. vim-minimal-2:8.2.2637-26.el9_8.4.x86_64
RLSA-2026:22717 Moderate/Sec.  vim-minimal-2:8.2.2637-26.el9_8.5.x86_64
RLSA-2026:28209 Moderate/Sec.  vim-minimal-2:8.2.2637-26.el9_8.6.x86_64

Chaque ligne porte un identifiant d'avis (RHSA chez Red Hat, RLSA chez Rocky) et une sévérité. C'est cette métadonnée qui rend le ciblage possible, et fiable.

Appliquer uniquement les correctifs de sécurité

sudo dnf update --security

Pour ne traiter que le plus urgent, filtrez par sévérité :

sudo dnf update --security --sec-severity=Critical

Sévérité	Quand appliquer
Critical	immédiatement, sans attendre la fenêtre de maintenance
Important	sous 48 heures
Moderate	fenêtre de maintenance planifiée
Low	prochaine maintenance

Glissez pour voir

Sur Fedora, dnf --security ne corrige rien

Cette section parle de RHEL et de ses dérivés, pas de Fedora, et la nuance n'est pas cosmétique. Fedora ne publie pas d'avis de sécurité exploitables par DNF. Sur une Fedora 41, alors que des mises à jour existent :

$ dnf check-update --security
No security updates needed, but 2 update(s) available

$ dnf updateinfo list security
No advisory found matching the requested name: "security"

Deux mises à jour disponibles, aucune vue comme relevant de la sécurité. Un dnf update --security sur Fedora ne fait donc rien, et retourne 0 : encore un correctif imaginaire. Sur Fedora, appliquez simplement dnf update : le modèle de la distribution est la mise à jour continue, pas le patch ciblé.

Automatiser avec dnf-automatic

1. Installer l'automate.

   sudo dnf install dnf-automatic

2. Le restreindre à la sécurité, dans /etc/dnf/automatic.conf :

   [commands]
   upgrade_type = security
   apply_updates = yes
   
   [emitters]
   emit_via = email,stdio
   
   [email]
   email_from = root@localhost
   email_to = admin@example.com

   La clé est upgrade_type = security : sa valeur par défaut est default, qui applique tout.

3. Activer le timer, sans quoi la configuration reste lettre morte.

   sudo systemctl enable --now dnf-automatic.timer
   systemctl status dnf-automatic.timer

Vérifier ce qui a été appliqué

sudo dnf history list
sudo dnf history info last

dnf history est plus riche que son équivalent APT : chaque transaction est annulable avec dnf history undo <id>, ce qui offre un vrai rollback après une mise à jour malheureuse.

Vérifier l'état de patch d'un système

Un paquet précis est-il à jour ?

Debian/Ubuntu

apt-cache policy openssl

openssl:
  Installed: 3.0.13-0ubuntu3.6
  Candidate: 3.0.13-0ubuntu3.6

Si Installed égale Candidate, le paquet est à jour.

RHEL/Rocky

dnf list --installed openssl
dnf check-update openssl

Si check-update ne renvoie rien et sort en code 0, le paquet est à jour. Un code 100 signifie qu'une mise à jour existe.

Faut-il redémarrer ?

Un correctif du noyau, de la glibc ou de systemd ne prend effet qu'après un redémarrage. La méthode diffère selon la famille.

Debian/Ubuntu

[ -f /run/reboot-required ] && cat /run/reboot-required.pkgs

Le fichier n'existe que si un paquet a demandé un redémarrage, et le second nomme les coupables. Utilisez bien /run/ : /var/run n'est qu'un lien symbolique hérité du passé.

RHEL/Rocky

sudo dnf install dnf-utils     # needs-restarting n'est PAS livré par défaut
sudo needs-restarting -r

needs-restarting -r répond directement si un redémarrage est nécessaire. Vérifié en conteneur : la commande n'existe pas sur une Rocky 9 vierge, et il n'y a aucun fichier /run/reboot-required sur RHEL. C'est un réflexe Debian qui ne se transpose pas.

Le noyau installé n'est pas le noyau qui tourne

Après une mise à jour du noyau, uname -r continue d'afficher l'ancien tant que la machine n'a pas redémarré. Comparez toujours le noyau actif avec le noyau installé (rpm -q kernel ou dpkg -l 'linux-image-*'). Un serveur « à jour » qui tourne encore sur un noyau vulnérable est un cas classique d'audit raté.

Politique de mise à jour en production

Environnement	Sécurité	Fonctionnel	Redémarrage
Dev / Test	automatique, immédiat	automatique	automatique
Staging	automatique, immédiat	hebdomadaire	planifié
Production	automatique, sécurité seule	fenêtre de maintenance, après validation en staging	fenêtre de maintenance

Glissez pour voir

La règle qui tient en production : la sécurité s'automatise, le fonctionnel se planifie, le redémarrage se décide. Les trois sont des décisions distinctes, et les confondre est la source la plus fréquente d'incident lié aux mises à jour.

Trois garde-fous complètent le dispositif. Recevez les rapports par courriel, et lisez-les : une automatisation dont personne ne lit la sortie est une automatisation aveugle. Testez le fonctionnel en staging avant la production. Et ne repoussez pas indéfiniment les redémarrages : un correctif de noyau non appliqué ne protège de rien.

Dépannage

La plupart des problèmes viennent d'une commande qui échoue en silence, ou d'un automate configuré mais jamais déclenché. Le tableau part du symptôme visible.

Symptôme	Cause probable	Solution
apt update échoue sur une clé	Clé de dépôt expirée ou absente	Poser la clé dans /etc/apt/keyrings/ et la déclarer avec Signed-By:. apt-key n'existe plus depuis Debian 12.
La commande « sécurité seulement » n'installe rien	sources.list est vide (format deb822)	Passer par unattended-upgrades, seul outil qui lit l'origine des paquets
dnf update --security ne fait rien sur Fedora	Fedora ne publie pas d'avis de sécurité	Utiliser dnf update tout court
needs-restarting: command not found	Paquet absent par défaut sur RHEL	dnf install dnf-utils
unattended-upgrades applique aussi le fonctionnel	La ligne ${distro_codename} est active par défaut	La commenter dans 50unattended-upgrades
L'automate ne s'exécute jamais	Timer non activé	systemctl enable --now apt-daily-upgrade.timer (ou dnf-automatic.timer)
Mise à jour bloquée par un conflit	Paquet retenu ou dépendance cassée	apt --fix-broken install, ou dnf distro-sync
Transaction interrompue	Coupure pendant l'opération	dpkg --configure -a, ou dnf history redo last

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Les mises à jour de sécurité corrigent des CVE : prioritaires, et à faible risque de régression.
• Deux recettes très répandues ne patchent rien, en silence et en retournant 0 : la commande APT avec Dir::Etc::SourceList (le sources.list est vide en deb822), et dnf --security sur Fedora (qui ne publie aucun avis de sécurité).
• Sur Debian et Ubuntu, le seul outil qui distingue vraiment la sécurité est unattended-upgrades : il lit l'origine des paquets, pas leur nom.
• Sa configuration par défaut ne se limite pas à la sécurité : la ligne ${distro_codename} autorise aussi le fonctionnel. Commentez-la en production.
• Sur RHEL et ses dérivés, dnf update --security fonctionne parce que Red Hat publie des avis liant paquet et CVE. --sec-severity=Critical cible l'urgence.
• needs-restarting n'est pas installé par défaut sur RHEL (dnf-utils), et /run/reboot-required n'existe pas : c'est un réflexe Debian.
• Après un correctif de noyau, uname -r affiche encore l'ancien tant qu'on n'a pas redémarré. Un serveur à jour qui tourne sur un noyau vulnérable est un audit raté.
• En production : la sécurité s'automatise, le fonctionnel se planifie, le redémarrage se décide.

Pour aller plus loin

• Administrer les paquets avec APT : le format deb822, les clés dans /etc/apt/keyrings/ et les dépôts tiers.
• Gérer les paquets avec DNF : historique des transactions, modules et rollback.
• Debian 13 « Trixie » : ce qu'une montée de version majeure change, et pourquoi elle ne s'automatise pas.
• Durcir SSH : réduire l'exposition de l'accès distant, qui reste la première porte visée.

×

📖 Voir la documentation →