Debian stable sur serveur, mises à jour de sécurité et rétroportages

Debian stable ne promet pas des logiciels récents : elle promet qu’un serveur se comportera demain comme aujourd’hui, les failles en moins. Cette page décrit le cycle de vie qui tient cette promesse (suites, correctifs rétroportés, mises à jour automatiques, rétroportages, montée de version) et les endroits précis où elle s’arrête. Le durcissement n’est pas traité ici : il a sa page, durcissement et minimisation de la surface, et son pas-à-pas, la checklist de durcissement d’un serveur Linux avant la mise en production.

→ Lire l’explication complète de la marmotte

Ce que stable signifie chez Debian : gel des versions et correctifs rétroportés

« Stable » ne veut pas dire « ne plante pas ». Le mot désigne un gel : une fois la version publiée, chaque paquet garde sa version amont jusqu’à la fin de vie. Seuls passent les correctifs ciblés (failles et bogues graves). Quand une faille tombe, l’équipe sécurité ne livre pas la nouvelle version du logiciel : elle extrait le correctif et l’applique sur la version gelée. C’est le rétroportage de correctif, à ne pas confondre avec la suite backports décrite plus bas.

La trace visible est dans le numéro de version. La partie amont ne bouge pas, seule la révision Debian avance, avec un suffixe du type +deb13u1, puis u2, et ainsi de suite.

Le compromis central est là, et il s’assume :

Ce qu’on gagne : une mise à jour de sécurité ne change ni le comportement, ni le format de configuration, ni les interfaces. C’est la seule raison pour laquelle on peut l’installer sans personne devant l’écran.
Ce qu’on paie : des logiciels qui ont l’âge de la version plus celui du gel, et une dépendance entière à la capacité de l’équipe sécurité à rétroporter. Plus le code amont diverge, plus l’exercice devient acrobatique.

Pour certains logiciels, l’acrobatie est impossible, et Debian fait alors exception à sa propre règle : les navigateurs suivent les versions ESR (Extended Support Release) de l’amont, le noyau suit une série amont à support long et avance aux versions ponctuelles, quelques bases de données reçoivent les versions mineures amont. Les notes de publication listent ces exceptions, ainsi que les écosystèmes au suivi limité (les paquets Go et Rust, liés statiquement, en font partie). Autre limite de périmètre : le suivi de l’équipe sécurité vaut pour la section main, pas pour contrib ni non-free. Le paquet debian-security-support fournit check-support-status, qui liste les paquets installés dont le suivi est limité ou terminé.

Les scanners de vulnérabilités qui lisent le mauvais numéro

Un scanner qui lit la version amont et la compare aux plages de la NVD (National Vulnerability Database) déclare vulnérable un paquet corrigé depuis des mois. Le rapport de plusieurs centaines de failles « critiques » sur une machine à jour est un genre littéraire à part entière. La source de vérité est le Debian Security Tracker (https://security-tracker.debian.org/), qui donne l’état de chaque CVE (Common Vulnerabilities and Exposures) par paquet et par version de Debian, ainsi que les flux OVAL (Open Vulnerability and Assessment Language) publiés par le projet. Un scanner qui ne consomme pas ces données produit du bruit, pas un inventaire.

Le piège inverse existe. Le tracker connaît des états comme no-dsa, postponed ou ignored : la faille est réelle, jugée mineure, et sera corrigée à une version ponctuelle, ou jamais. Sans DSA (Debian Security Advisory), aucun avis n’est émis. « À jour » ne signifie donc pas « zéro CVE ouverte », et c’est une décision documentée du projet, pas un oubli.

Suites et dépôts Debian : stable, security, updates, backports, testing

Une suite est un ensemble cohérent de paquets, désigné par un rôle (stable) ou par un nom de code (trixie pour Debian 13). Dans les sources APT (Advanced Package Tool), on écrit toujours le nom de code. Écrire stable, c’est lier la machine à un rôle qui change de titulaire le jour de la publication suivante : selon la version d’APT et la façon dont il est lancé, elle s’arrête sur une erreur de changement de dépôt ou elle part vers la version majeure suivante. Dans les deux cas, personne ne l’a décidé.

Suite	Contenu	Suivi sécurité	Place sur un serveur
`trixie` (stable)	la version publiée, modifiée aux seules versions ponctuelles	via la suite de sécurité	socle
`trixie-security`	correctifs publiés dès qu’ils sont prêts	équipe sécurité	obligatoire
`trixie-updates`	ce qui ne peut pas attendre la version ponctuelle (fuseaux horaires, signatures antivirus, régressions urgentes)	sans objet	à activer
`trixie-backports`	paquets de testing recompilés pour stable	le mainteneur du rétroportage, au mieux	par exception, paquet par paquet
`testing`	la future stable	aucun suivi dédié, correctifs par migration depuis unstable	non
`unstable` (sid)	point d’entrée des nouvelles versions	les mainteneurs	non

Sur testing, un correctif attend sa migration depuis unstable, et une transition de bibliothèque peut la bloquer plusieurs semaines. C’est aussi là qu’arrivent les mauvaises surprises amont : la porte dérobée insérée dans xz en 2024 a atteint unstable et testing, jamais stable. Mettre testing en production, c’est se porter volontaire comme testeur sans avoir signé nulle part. C’est d’ailleurs le régime choisi par Kali Linux, qui suit la branche de test de Debian en continu : un parfait outillage d’audit, et un socle de serveur à proscrire pour la même raison.

Cycle de vie d’une version : oldstable, LTS et ELTS

Le schéma suivant se lit de haut en bas : à chaque flèche, l’acteur qui assure les correctifs change, et le périmètre couvert rétrécit.

Les ordres de grandeur : une version majeure tous les deux ans environ, trois ans de suivi complet par l’équipe sécurité (dont la dernière année en oldstable), puis le relais LTS (Long Term Support) jusqu’à cinq ans. LTS n’est pas assuré par l’équipe sécurité mais par une équipe distincte, faite de bénévoles et de contributeurs rémunérés par des sponsors. Elle couvre un sous-ensemble d’architectures et exclut certains paquets ; ses avis sont des DLA (Debian LTS Advisory) et ses correctifs continuent d’arriver par la suite de sécurité, sans toucher aux sources. ELTS (Extended Long Term Support) va plus loin encore, mais c’est une offre commerciale de Freexian, hors projet Debian, servie par un dépôt distinct, et dont le périmètre de paquets dépend de ce que les clients financent.

Les dates exactes par version se lisent sur https://www.debian.org/releases/ et https://wiki.debian.org/LTS, pas dans un tableur recopié il y a trois ans.

La position à tenir : LTS est un amortisseur, pas un plan. Une montée de version se programme dans l’année qui suit la publication de la nouvelle stable, pendant que l’ancienne bénéficie encore du suivi complet.

Versions ponctuelles

Tous les deux mois environ, Debian publie une version ponctuelle (13.1, 13.2). Elle regroupe les correctifs de sécurité déjà diffusés et y ajoute des corrections de bogues graves, dont une partie des failles classées no-dsa. Ce n’est pas une nouvelle version à installer : une machine qui suit la suite stable et sa suite de sécurité y arrive par une mise à niveau ordinaire. Le numéro ne sert qu’à dater les images d’installation.

Chaîne de confiance d’APT : fichiers Release signés, clés, deb822 et Signed-By

APT ne fait pas confiance au miroir, il fait confiance à une signature. Le schéma montre la chaîne : un seul maillon est signé, tous les autres sont tenus par des empreintes SHA-256 (Secure Hash Algorithm).

Conséquences directes :

Les .deb ne sont pas signés individuellement. Un paquet téléchargé à la main et installé par dpkg -i ne bénéficie d’aucune vérification.
Le rejeu est borné, pas partout. Les suites de sécurité et -updates portent un champ Valid-Until : un miroir qui ressert un vieil index finit par être refusé. La suite stable principale n’en porte pas. Ce contrôle dépend de l’horloge locale, d’où l’intérêt d’une synchronisation NTP (Network Time Protocol) fiable.
Le transport compte quand même. HTTP (HyperText Transfer Protocol) en clair ne permet pas de modifier un paquet, mais permet d’observer ce qui est installé, de bloquer les mises à jour, et expose le code d’APT lui-même à l’attaquant en position d’interception (CVE-2019-3462 a permis l’exécution de code par ce chemin). Le miroir deb.debian.org répond en HTTPS, pour l’archive principale comme pour la suite de sécurité : autant s’en servir.
La signature authentifie l’archive, pas la compilation. Que le binaire corresponde au source relève de la compilation reproductible.

Côté clés : celles de Debian arrivent par le paquet debian-archive-keyring et se renouvellent avec lui. Pour un dépôt tiers, la clé va dans /etc/apt/keyrings/ et le dépôt la désigne par Signed-By. L’ancienne méthode (apt-key, supprimée à partir de Debian 13, ou un dépôt dans /etc/apt/trusted.gpg.d/) accorde une confiance globale : n’importe quelle clé du trousseau peut alors signer n’importe quel dépôt, y compris un faux security.debian.org. Le format deb822 (fichiers .sources, un champ par ligne) rend Signed-By lisible ; apt modernize-sources convertit l’ancien format sur les versions récentes d’APT.

Ce que Signed-By ne fait pas : empêcher un dépôt tiers légitime de publier un paquet nommé comme un paquet Debian avec un numéro de version supérieur. Ajouter un dépôt revient à donner root à son éditeur, les scripts d’installation s’exécutant avec tous les droits. La parade est l’épinglage, traité plus bas.

unattended-upgrades et needrestart : ce qui s’installe, ce qui redémarre

Prérequis : les paquets unattended-upgrades, needrestart et debian-security-support, des sources écrites avec le nom de code, une sortie réseau vers les miroirs (ou un miroir interne), une horloge juste et un canal pour les comptes rendus (courriel ou collecte de journaux). Deux minuteries systemd, à délai aléatoire, déclenchent le téléchargement des index puis l’installation.

Origines autorisées

unattended-upgrades n’installe que ce qui vient d’une origine listée dans Unattended-Upgrade::Origins-Pattern. Par défaut sur Debian : la suite stable et sa suite de sécurité, désignées par nom de code. Trois absences méritent d’être connues :

-updates est commenté dans la configuration par défaut ; à décommenter.
Les backports n’y sont pas. Un paquet pris en backports ne reçoit donc aucune mise à jour automatique tant que l’origine Debian Backports n’est pas ajoutée.
Les dépôts tiers n’y sont pas. Le moteur de conteneurs ou la base de données installés depuis le dépôt de leur éditeur restent figés pendant que le tableau de bord affiche fièrement « mises à jour automatiques : activées ».

Deux cas de blocage silencieux s’y ajoutent. Un paquet dont un fichier de configuration a été modifié localement, et dont la mise à jour poserait une question, est mis de côté : la faille reste, une ligne dans /var/log/unattended-upgrades/ le signale, personne ne la lit. Même sort pour une mise à jour qui exigerait de supprimer un autre paquet.

Redémarrage automatique et needrestart

Installer un correctif ne corrige rien tant que l’ancien code tourne en mémoire. Deux mécanismes s’en occupent, et aucun n’est actif par défaut dans le sens qu’on espère.

Le redémarrage de la machine : l’installation d’un noyau dépose le fichier /run/reboot-required. Unattended-Upgrade::Automatic-Reboot vaut false par défaut ; à true, la machine redémarre, immédiatement ou à l’heure fixée par Automatic-Reboot-Time. Debian ne fournit pas de flux officiel de correctifs noyau à chaud : un noyau corrigé exige un redémarrage, point.

Le redémarrage des services : needrestart repère les processus qui utilisent encore une bibliothèque remplacée. Son mode par défaut est interactif : sans terminal, le résultat dépend de l’interface de configuration disponible, ce qui n’est pas une politique. Il faut le fixer explicitement en mode automatique ($nrconf{restart} = 'a').

Même ainsi, voici ce qui n’est pas redémarré tout seul :

le noyau et le microcode du processeur (redémarrage machine uniquement) ;
les services de la liste d’exclusion de needrestart : bus système, gestion des sessions, services réseau, gestionnaires d’affichage ;
les processus des conteneurs et les machines virtuelles en cours d’exécution ;
les sessions utilisateur et tout ce qui a été lancé à la main hors systemd.

La recommandation : mises à jour automatiques sur stable, sécurité et updates, partout, sans exception « parce que cette machine est sensible » (c’est précisément celle qui doit être corrigée). Redémarrage automatique là où une redondance existe ; redémarrage orchestré là où elle n’existe pas. Dans les deux cas, un reboot-required qui traîne est une alerte, pas un état.

Exemple : trajet d’un correctif de sécurité jusqu’au serveur

Le schéma suit un correctif depuis le signalement jusqu’au processus relancé. Chaque condition entre crochets est un endroit où le trajet peut s’arrêter sans bruit.

La moitié haute appartient à Debian et fonctionne sans qu’on s’en occupe. La moitié basse appartient à l’exploitant, et c’est là que se trouvent toutes les conditions. Un correctif publié en quelques heures peut ainsi rester inactif des mois sur une machine où le paquet est installé, le service jamais relancé et le noyau jamais redémarré. La date à superviser n’est pas celle de l’installation, mais celle où le dernier processus concerné a redémarré.

Rétroportages et dépôts tiers : suivi sécurité et épinglage APT

La suite backports contient des paquets pris dans testing et recompilés pour stable. Elle répond à un besoin précis : une version plus récente d’un logiciel, ou un noyau qui reconnaît un matériel trop neuf. Elle a un prix précis aussi : l’équipe sécurité ne la suit pas. Un correctif y arrive quand il a atteint testing et que le mainteneur du rétroportage a refait le travail, au mieux de ses disponibilités.

L’épinglage par défaut protège contre l’accident. Le fichier Release de backports porte NotAutomatic: yes et ButAutomaticUpgrades: yes, ce qui donne une priorité de 100 : rien n’en est installé sans demande explicite (apt install -t trixie-backports paquet), mais un paquet déjà pris là continue d’y suivre ses mises à jour. Les repères : 500 pour une source ordinaire, 990 pour la suite cible, 100 pour ce qui est installé, au-delà de 1000 pour autoriser un retour en arrière, négatif pour interdire.

La règle : backports par exception, paquet nommé, raison écrite. Un serveur dont la moitié des paquets vient de backports est un serveur en testing qui n’ose pas le dire.

Pour un dépôt tiers, l’épinglage se configure à la main. L’extrait suivant limite un dépôt d’éditeur au seul paquet attendu :

# /etc/apt/sources.list.d/editeur.sources (format deb822)
Types: deb
URIs: https://paquets.example.org/debian
Suites: trixie
Components: main
Signed-By: /etc/apt/keyrings/editeur.gpg

# /etc/apt/preferences.d/editeur
# Priorité 1 : ce dépôt ne remplace aucun paquet déjà installé
Package: *
Pin: origin paquets.example.org
Pin-Priority: 1

# Seul le paquet attendu suit normalement ses mises à jour
Package: agent-editeur
Pin: origin paquets.example.org
Pin-Priority: 500

apt policy agent-editeur puis apt policy libc6 permettent de vérifier le résultat : le premier doit avoir son candidat chez l’éditeur, le second jamais.

Montée de version majeure Debian

unattended-upgrades ne change jamais de version majeure : ses origines suivent le nom de code. La montée est un acte décidé, et Debian la prend au sérieux, puisque la mise à niveau en place depuis la version précédente fait partie des critères de publication. Deux contraintes fermes : on ne saute pas de version (de N à N+1, jamais N+2), et on lit les notes de publication, qui listent les changements incompatibles.

Les étapes qui comptent :

amener la machine à la dernière version ponctuelle de sa version actuelle ;
inventorier ce qui ne vient pas de Debian (apt list '?narrow(?installed, ?not(?origin(Debian)))') et les paquets retenus (apt-mark showhold) ;
désactiver dépôts tiers et backports, puis changer le nom de code dans les sources ;
mise à niveau en deux temps (apt upgrade --without-new-pkgs, puis apt full-upgrade), redémarrage ;
purger les paquets obsolètes, réactiver les dépôts tiers sur la nouvelle version.

L’étape 5 est celle qu’on oublie. Un paquet retiré de la nouvelle version reste installé, fonctionne, et ne recevra plus jamais de correctif. Autre casse classique : les dépôts tiers dont la clé ou les algorithmes de signature ne satisfont plus la politique, plus stricte, de la nouvelle version d’APT.

En place ou reconstruction ? Le choix dépend d’une seule question : l’état de la machine est-il reproductible depuis du code (image, gestion de configuration) ? Si oui, reconstruire sur la nouvelle version et basculer : on repart sans sédiments. Si non, la mise à niveau en place est fiable, à condition d’avoir un instantané ou une sauvegarde restaurable avant de commencer, car le retour arrière n’existe pas.

Ce que la branche stable ne garantit pas

Les logiciels hors dépôts. Tout ce qui arrive par un gestionnaire de paquets de langage, un script téléchargé ou un binaire copié à la main échappe au cycle. Les binaires liés statiquement embarquent en plus leurs bibliothèques vulnérables : mettre à jour la bibliothèque système n’y change rien.
Les conteneurs. Une image embarque ses propres bibliothèques ; la mise à jour de l’hôte ne les touche pas. Seul le noyau est partagé (voir isolation des conteneurs). Il faut reconstruire et redéployer les images, avec leur propre cycle : voir images de base et confiance héritée.
Le firmware. La section non-free-firmware livre le microcode du processeur et les blobs de périphériques. Le firmware UEFI (Unified Extensible Firmware Interface) et celui du BMC (Baseboard Management Controller) n’en font pas partie : voir sécurité du firmware et du BMC.
Le noyau non redémarré. Installé n’est pas exécuté. Tant que la version en cours diffère de la version installée, la machine tourne sur l’ancien noyau, failles comprises.
La configuration. Une mise à jour conserve les fichiers modifiés. Les réglages par défaut plus stricts d’une nouvelle version ne s’appliquent pas à une configuration héritée.
Les failles non corrigées. Les états no-dsa et les paquets au suivi limité restent ouverts sur une machine parfaitement à jour.

Conditions d’exploitation : supervision, étalement, retour arrière

Supervision. Les indicateurs à collecter : date du dernier passage réussi d’unattended-upgrades, âge du fichier reboot-required, paquets retenus ou mis de côté, sortie de check-support-status, erreurs d’apt update (signature, validité dépassée), espace libre sur /boot. Un /boot plein bloque l’installation du noyau suivant et laisse dpkg dans un état à réparer à la main ; Remove-Unused-Kernel-Packages limite le risque.

Étalement. Les minuteries ont un délai aléatoire, pas Automatic-Reboot-Time. Un cluster à quorum dont tous les membres redémarrent à la même minute est une panne planifiée avec beaucoup de soin. Décaler les heures par groupe, ou confier les redémarrages à un orchestrateur qui en libère un à la fois. Un miroir interne promu par étapes ajoute un sas (quelques machines d’abord, le reste ensuite), au prix d’un délai sur les correctifs : à borner en jours, pas en trimestres.

Clés et secrets. Les clés de Debian se renouvellent par paquet. Celles des dépôts tiers expirent sans prévenir : leur date d’expiration se supervise comme un certificat. Les identifiants d’un dépôt privé vont dans /etc/apt/auth.conf.d/, lisibles par root seul, jamais dans l’URI.

Retour arrière. APT ne rétrograde pas de lui-même. Les anciennes versions restent disponibles sur snapshot.debian.org pour réinstaller une révision précise. Pour une montée majeure, seul l’instantané ou la sauvegarde restaurée (et testée) fait office de retour arrière.

🐝 Ce qui arrive si on s’en passe

Sans mises à jour automatiques, la fenêtre d’exposition devient un délai humain, alors que chaque avis de sécurité publie en même temps le correctif et, par différence avec la révision précédente, l’emplacement de la faille. Sans nom de code dans les sources, le jour d’une publication majeure transforme une mise à jour de routine en migration, ou en arrêt des mises à jour, que personne n’a décidé. Sans suivi du cycle de vie, une machine sort du support en silence : APT annonce zéro paquet à mettre à jour, ce qui se lit comme une bonne nouvelle et signifie l’inverse. Sans épinglage, la liste des paquets installés ne dit plus qui a fourni quoi, et l’analyse après incident commence par de l’archéologie.

🦫 Explication de la marmotte 🍫

Debian publie une nouvelle grande version tous les deux ans environ. À partir de ce jour, les logiciels qu’elle contient ne changent plus de version : on ne leur ajoute aucune nouveauté. Quand une faille est découverte dans l’un d’eux, une équipe de Debian répare uniquement le morceau fautif et publie le logiciel réparé sur un serveur réservé aux réparations de sécurité. Chaque publication porte une signature numérique, un calcul que seul Debian peut produire et que n’importe quelle machine peut vérifier. Le serveur vérifie cette signature avant d’installer quoi que ce soit ; si elle est fausse ou trop ancienne, il refuse. Un programme lancé chaque jour télécharge et installe ces réparations sans intervention humaine. Mais installer ne suffit pas : un logiciel déjà en marche continue d’utiliser l’ancienne version tant qu’il n’a pas été relancé, et le cœur du système exige un redémarrage complet de la machine. Si personne ne redémarre, la faille reste ouverte alors que tout semble à jour. Les réparations durent environ trois ans, puis une autre équipe prend le relais jusqu’à cinq ans, avec une couverture réduite. Ensuite, il faut passer à la grande version suivante, sinon plus rien n’est réparé. Enfin, tout ce qui a été installé en dehors des sources de Debian n’est réparé par personne automatiquement : il faut le suivre à part.

Pages voisines

La citent

Debian stable sur serveur, mises à jour de sécurité et rétroportages

Elle cite

: les deux pages se citent l’une l’autre.

Debian stable sur serveur, mises à jour de sécurité et rétroportages

Debian stable sur serveur, mises à jour de sécurité et rétroportages

Ce que stable signifie chez Debian : gel des versions et correctifs rétroportés

Les scanners de vulnérabilités qui lisent le mauvais numéro

Suites et dépôts Debian : stable, security, updates, backports, testing

Cycle de vie d’une version : oldstable, LTS et ELTS

Versions ponctuelles

Chaîne de confiance d’APT : fichiers Release signés, clés, deb822 et Signed-By

unattended-upgrades et needrestart : ce qui s’installe, ce qui redémarre

Origines autorisées

Redémarrage automatique et needrestart

Exemple : trajet d’un correctif de sécurité jusqu’au serveur

Rétroportages et dépôts tiers : suivi sécurité et épinglage APT

Montée de version majeure Debian

Ce que la branche stable ne garantit pas

Conditions d’exploitation : supervision, étalement, retour arrière

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines