Comment mettre à jour FreeBSD : base et packages

Comment FreeBSD gère les mises à jour de sécurité

FreeBSD gère les mises à jour de sécurité avec deux outils distincts, car un serveur FreeBSD se compose de deux entités séparées. Le système de base, c'est-à-dire le noyau et l'espace utilisateur fournis avec la version, est corrigé avec freebsd-update. Tout ce que vous avez installé par-dessus constitue un paquet, et les paquets sont corrigés avec pkg. Si vous n'en exécutez qu'un seul, la moitié de la machine reste sans correctifs, et rien sur le serveur ne vous en informera.

SSD Nodes ne propose pas d'images FreeBSD. Nos offres utilisent Linux. Cet article est néanmoins présent car le public est identique : les administrateurs de nos serveurs Ubuntu et Debian utilisent aussi FreeBSD pour un pare-feu ou sur une machine héritée. Le modèle de mise à jour scindé est ce qui surprend souvent un administrateur Linux, c'est donc le point important à documenter. Chaque commande, format d'avis et date de support ci-dessous a été vérifié par rapport à la page de sécurité de FreeBSD et aux pages de manuel du projet en août 2026.

Une remarque avant les commandes. FreeBSD n'installe pas sudo dans le système de base. Tout ce qui est décrit ici nécessite les privilèges root. Utilisez su -, ou installez d'abord sudo ou doas via les paquets.

Le système de base et les paquets sont des univers distincts

Sur Ubuntu, apt gère l'intégralité de la machine. Le noyau, openssl, nginx et vos propres outils arrivent sous forme de fichiers .deb via un seul outil, et apt upgrade met à jour l'ensemble simultanément.

FreeBSD sépare ces deux éléments. Le système de base est construit et versionné comme une unité unique : 15.1-RELEASE-p3 est un numéro unique couvrant le noyau, la bibliothèque C, sshd et la copie d'OpenSSL située dans /usr/lib. Rien de tout cela ne provient de pkg. Tout le reste réside sous /usr/local, arrive sous forme de paquet binaire construit depuis l'arborescence des ports, et possède sa propre version.

Ainsi, une machine peut contenir deux copies d'OpenSSL : la copie système dans /usr/lib, corrigée uniquement par freebsd-update, et la copie paquet dans /usr/local/lib, corrigée uniquement par pkg. La copie utilisée par un programme dépend de celle avec laquelle il a été lié ; les logiciels installés via les paquets utilisent généralement la copie paquet. Corriger l'une n'a aucun effet sur l'autre.

Trois commandes permettent de connaître l'état de votre système :

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u affiche le niveau de correctif de l'espace utilisateur installé. freebsd-version -k affiche le niveau de correctif du noyau installé, et freebsd-version(1) explique explicitement pourquoi cela diffère de uname : « si un nouveau noyau a été installé mais que le système n'a pas encore redémarré, freebsd-version affichera la version et le niveau de correctif du nouveau noyau ». uname -r affiche le noyau actuellement en cours d'exécution. Il existe également freebsd-version -r, qui affiche le noyau actif mais n'est « pas affecté par les variables d'environnement », ce qui est important au sein d'une jail où UNAME_r est souvent défini sur une autre valeur.

Avis de sécurité et notes d'errata

L'équipe de sécurité de FreeBSD publie deux types d'avis, qui ont des significations distinctes.

Un avis de sécurité (Security Advisory) concerne une vulnérabilité dans le système de base. L'identifiant se présente sous la forme FreeBSD-SA-26:55.elf : les lettres SA, l'année sur deux chiffres, un numéro séquentiel pour cette année, puis le composant affecté. FreeBSD-SA-26:52.if_wg et FreeBSD-SA-26:50.kqueue ont toutes deux été publiées le 2026-07-29. La liste complète est disponible sur la page des avis FreeBSD.

Une note d'errata (Errata Notice) traite d'un problème de correction ou de stabilité nécessitant une mise à jour sur une branche de version, sans impact sur la sécurité. Le format est identique, avec EN à la place de SA : FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Une mise à jour des données de fuseau horaire en est l'exemple classique. Personne ne peut vous attaquer avec des données de fuseau horaire obsolètes, mais vos horodatages seront erronés tant que vous n'aurez pas appliqué le correctif. Les errata sont listés sur la page des notes d'errata FreeBSD.

Les deux types d'avis sont signés avec la clé PGP (Pretty Good Privacy) du responsable de la sécurité, archivés sur security.FreeBSD.org, et tous deux sont transmis à votre machine par freebsd-update.

Voici le point qui surprend souvent les administrateurs Linux. Aucun de ces avis ne couvre les paquets. La page de sécurité le précise clairement : les problèmes dans la FreeBSD Ports Collection « sont traités séparément dans le document FreeBSD VuXML ». Une faille distante dans le paquet nginx ne recevra jamais de numéro SA. Si vous ne surveillez que le flux des avis de sécurité, vous ne serez jamais informé de ces vulnérabilités.

Comment être informé d'une mise à jour de sécurité FreeBSD ?

La liste à rejoindre est freebsd-security-notifications. Elle est modérée, à faible volume, et diffuse les avis de sécurité ainsi que les notes d'errata. Abonnez-vous sur lists.freebsd.org.

freebsd-announce est également modérée et diffuse les avis ainsi que les annonces de releases ; c'est donc la liste adaptée si vous souhaitez centraliser toutes les informations. freebsd-security est la liste de discussion. Sa lecture est utile, mais ce n'est pas là que vous apprendrez la nécessité d'appliquer un correctif.

Toutes ces listes concernent uniquement le système de base. Les vulnérabilités des paquets ne sont jamais notifiées par e-mail. Vous devez les identifier en exécutant une commande.

pkg audit et la base de données associée

VuXML, le Vulnerabilities and Exposures Markup Language, est le registre du projet FreeBSD pour les problèmes de sécurité concernant les ports et les paquets. Chaque entrée nomme le paquet affecté, les plages de versions vulnérables, les identifiants CVE (Common Vulnerabilities and Exposures) et une courte description. L'ensemble est consultable sur l'index VuXML, trié par paquet, par CVE ou par date.

pkg audit est l'outil qui le lit :

pkg audit -F

-F récupère une copie récente de la base de données avant de procéder à la vérification. Utilisez-le à chaque fois. Sans -F, vous comparez les paquets avec la copie déjà présente sur la machine, qui peut être obsolète depuis des mois ; un résultat sain ne signifie donc rien. La commande compare chaque version de paquet installé avec chaque entrée VuXML, affiche chaque correspondance avec ses numéros CVE et un lien vers la page VuXML, puis se termine par une ligne indiquant le nombre de problèmes trouvés dans le nombre de paquets installés.

Deux autres flags issus de pkg-audit(8) méritent d'être connus. pkg audit -r « affiche également les paquets qui dépendent de paquets vulnérables et qui sont donc potentiellement vulnérables eux aussi », ce qui permet de comprendre qu'une bibliothèque vulnérable est critique parce que six éléments installés y sont liés. pkg audit -R affiche le même résultat au format JSON ou dans un autre format lisible par une machine, ce qui est utile pour alimenter une sonde de monitoring.

Le paquet pkg installe un script périodique dans /usr/local/etc/periodic/security/410.pkg-audit. Il s'exécute dans le cadre de la vérification de sécurité quotidienne et envoie le résultat par mail à root. Confirmez son activation avec une ligne dans /etc/periodic.conf :

daily_status_security_pkgaudit_enable="YES"

Ce mail quotidien est ce qui se rapproche le plus, sous FreeBSD, de l'habitude des unattended-upgrades sur Ubuntu, et la différence est fondamentale : unattended-upgrades installe le correctif pendant votre sommeil, tandis que pkg audit vous informe seulement qu'un correctif est nécessaire. pkg audit génère des rapports. Il ne patch jamais. Rien sur un système FreeBSD standard n'installe de mise à jour de sécurité sans votre intervention.

Correction d'un paquet vulnérable

pkg update
pkg upgrade

Il n'existe pas de dépôt dédié uniquement à la sécurité dans les dépôts de paquets FreeBSD. Ubuntu peut extraire des mises à jour depuis noble-security uniquement et laisser tous les autres paquets en l'état. FreeBSD n'a pas d'équivalent, donc corriger un paquet vulnérable implique d'installer la version actuellement proposée par le dépôt, ainsi que toutes les dépendances qui l'accompagnent. Planifiez la mise à jour des paquets comme un changement à part entière, et non comme une tâche de fond.

La branche de dépôt que vous utilisez détermine la rapidité avec laquelle un correctif vous parvient. La branche par défaut est la branche trimestrielle (quarterly), que le manuel décrit comme offrant « une expérience plus prévisible et stable » en n'acceptant que les mises à jour sans nouvelles fonctionnalités. La branche « latest » intègre la version la plus récente de chaque paquet. Ainsi, lorsque pkg audit -F signale un paquet comme vulnérable et que pkg upgrade indique qu'il n'y a rien à faire, c'est que le correctif n'est pas encore arrivé sur votre branche ; c'est le mécanisme à l'origine de cette confusion.

Pour basculer une machine sur la branche « latest », copiez le fichier de dépôt fourni avec le système et modifiez cette copie :

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Remplacez quarterly par latest dans la ligne url de la copie, puis exécutez pkg update -f pour récupérer le nouveau catalogue. Copiez le fichier plutôt que de taper le nom du dépôt de mémoire : le nom contenu dans /etc/pkg/FreeBSD.conf est celui que votre système utilise réellement, et un fichier situé sous /usr/local/etc/pkg/repos ne remplace que le dépôt dont le nom correspond exactement.

Application des correctifs du système de base

freebsd-update fetch
freebsd-update install

fetch télécharge les correctifs pour votre version actuelle et affiche la liste des fichiers qui seront modifiés. Lorsqu'il n'y a rien à faire, il affiche No updates needed to update system to 15.1-RELEASE-p3. et se termine. Lorsqu'il y a des modifications, il vous indique à la fin d'exécuter la commande d'installation. Rien n'est appliqué tant que vous n'exécutez pas freebsd-update install, donc fetch peut être exécuté sans risque à tout moment.

freebsd-update(8) fournit des mises à jour binaires pour les versions ALPHA, BETA, RC et RELEASE, mais pas pour les versions PRERELEASE, STABLE ou CURRENT. Si vous suivez stable/15, vous compilez depuis les sources et cet outil ne vous concerne pas.

Automatisez le téléchargement et gardez l'installation manuelle. Voici la ligne du manuel pour /etc/crontab :

@daily                                  root    freebsd-update cron

freebsd-update cron attend une durée aléatoire comprise entre 1 et 3600 secondes, puis télécharge les mises à jour exactement comme le fait fetch, et envoie un e-mail à root lorsqu'une mise à jour est en attente. L'attente aléatoire permet d'éviter que toutes les machines FreeBSD sur Internet ne sollicitent les miroirs de mise à jour à la même seconde.

Deux éléments dans la sortie déroutent souvent les utilisateurs. src component not installed, skipped est normal sur un serveur sans arborescence source, ce n'est pas une erreur. L'ensemble des composants est contrôlé par une ligne Components dans /etc/freebsd-update.conf, et les choix sont src, world et kernel.

Si une installation se passe mal, freebsd-update rollback désinstalle les mises à jour les plus récemment installées. Sur une racine ZFS, vous pouvez faire mieux en créant d'abord un environnement de démarrage (boot environment) :

bectl create pre-patch
freebsd-update fetch install

Si le système corrigé ne démarre pas, sélectionnez l'ancien environnement de démarrage dans le menu du chargeur (loader) pour revenir à l'état initial. Cette porte de sortie est l'une des raisons pratiques de l'utilisation de ZFS comme système de fichiers racine, et cela ne consomme quasiment aucun espace disque tant que les deux environnements ne divergent pas.

Ma version de FreeBSD est-elle toujours supportée ?

Chaque version est supportée pendant une période fixe, publiée sous forme de tableau des branches sur la page de sécurité. En août 2026, ce tableau indique :

• releng/15.1, qui correspond à 15.1-RELEASE, jusqu'au 31 mars 2027
• releng/15.0, qui correspond à 15.0-RELEASE, jusqu'au 30 septembre 2026
• releng/14.4, qui correspond à 14.4-RELEASE, jusqu'au 31 décembre 2026
• stable/15 jusqu'au 31 décembre 2029
• stable/14 jusqu'au 30 novembre 2028

Les versions mineures (point releases) bénéficient de fenêtres de support courtes. 15.0-RELEASE arrive à échéance environ sept semaines après la rédaction de cet article, car la sortie de 15.1 a déclenché le compte à rebours. Les branches stables durent plusieurs années ; ce sont des branches sources que freebsd-update ne distribue pas.

Vérifiez votre version avec freebsd-version -u et comparez-la au tableau. freebsd-update vous avertit également. À l'approche de la date, fetch affiche :

WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

Une fois la date passée, l'avertissement devient WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE.. Une version non supportée continue de fonctionner. Elle ne reçoit plus de bulletins de sécurité, ce qui signifie que la prochaine vulnérabilité du système de base restera présente indéfiniment.

La mise à niveau vers une version supérieure s'effectue avec freebsd-update -r 15.1-RELEASE upgrade, puis freebsd-update install, suivi d'un redémarrage, puis freebsd-update install une seconde fois, puis pkg-static upgrade -f pour réinstaller tous les paquets en fonction des nouvelles bibliothèques, et enfin un dernier freebsd-update install. Le manuel précise qu'il peut n'y avoir que deux phases d'installation au lieu de trois, selon que les numéros de version des bibliothèques ont été incrémentés ou non. Prévoyez une fenêtre de maintenance et consultez le guide de configuration d'un serveur FreeBSD 15 avant de commencer.

Redémarrage ou simple redémarrage du service ?

FreeBSD répond à cette question par une simple comparaison :

freebsd-version -k
uname -r

freebsd-version -k est le noyau sur le disque. uname -r est le noyau en mémoire. Des chaînes différentes signifient qu'un nouveau noyau est installé et que vous ne l'utilisez pas ; il faut donc redémarrer. Des chaînes identiques signifient que le correctif n'a pas touché au noyau et qu'un redémarrage ne vous apportera rien.

Pour un correctif de l'espace utilisateur (userland), redémarrez tout ce qui utilise le code corrigé. Un correctif appliqué à la bibliothèque OpenSSL de base dans /usr/lib n'a aucun effet sur un sshd lancé il y a trois semaines, car celui-ci a toujours l'ancienne bibliothèque mappée dans son espace d'adressage. Le fichier sur le disque est nouveau. Le processus en cours d'exécution ne l'est pas.

service sshd restart

La même règle s'applique aux paquets. pkg upgrade remplace le binaire sur le disque alors que le processus en cours maintient l'ancien ouvert ; service nginx restart est donc l'étape qui rend le correctif effectif.

Le système de base ne possède pas d'équivalent au needrestart de Debian, donc rien ne vous avertit et aucune liste n'est tenue. Soit vous suivez quels services sont liés à quelle bibliothèque corrigée, soit vous redémarrez après chaque correctif touchant aux bibliothèques système. Sur un serveur dont la configuration est sous contrôle de version, le redémarrage est une opération de routine, et il est bien moins coûteux que de croire que vous êtes protégé alors que ce n'est pas le cas.

Mise à jour d'une machine utilisant des jails

Une jail partage le noyau de l'hôte. Une alerte de sécurité concernant le noyau est donc un problème propre à l'hôte, dont héritent toutes les jails présentes sur la machine. Mettez à jour l'hôte et redémarrez-le : la partie noyau est alors corrigée pour l'ensemble des jails. L'espace utilisateur (userland) à l'intérieur de chaque jail constitue une installation distincte avec son propre niveau de correctifs, et freebsd-version -j <jail> permet de le vérifier depuis l'hôte. Les paquets installés dans une jail sont également indépendants, et pkg -j <jail> audit -F permet de les auditer sans avoir à entrer dans la jail. Cette séparation entre un noyau partagé et un espace utilisateur cloisonné constitue la différence structurelle fondamentale qui définit comment les jails se comparent aux conteneurs Docker.

La traduction Ubuntu

Chaque habitude sous FreeBSD possède son équivalent, vous pouvez donc transposer vos routines dans les deux sens.

• Correctifs du système de base : freebsd-update fetch puis freebsd-update install. Sous Ubuntu, apt update && apt upgrade, qui couvre à la fois le système de base et le reste en une seule opération.
• Logiciels tiers : pkg update && pkg upgrade sous FreeBSD. Sous Ubuntu, à nouveau apt.
• Vérification des vulnérabilités connues : pkg audit -F sous FreeBSD. Sous Ubuntu 24.04, la commande la plus proche est pro security-status, qui affiche les mises à jour de sécurité pour les paquets installés, y compris le contenu de l'Expanded Security Maintenance.
• Installation automatique : unattended-upgrades sous Ubuntu applique les mises à jour de sécurité pour vous. FreeBSD ne propose rien d'équivalent, donc freebsd-update cron télécharge et envoie par mail les alertes pendant que vous effectuez l'installation manuellement.
• Flux d'avis de sécurité : freebsd-security-notifications contient les éléments FreeBSD-SA et FreeBSD-EN. ubuntu-security-announce contient les Ubuntu Security Notices.
• Base de données des vulnérabilités : VuXML pour les ports et paquets FreeBSD. Le tracker CVE d'Ubuntu pour les paquets Ubuntu.
• Vérification de redémarrage : freebsd-version -k face à uname -r sous FreeBSD. La présence de /var/run/reboot-required sous Ubuntu.
• Fenêtre de support : le tableau des branches sur la page de sécurité de FreeBSD. Le calendrier des releases et pro security-status sous Ubuntu.

La routine sous-jacente est identique sur les deux systèmes : abonnez-vous au flux, exécutez l'audit selon un calendrier, puis décidez quoi installer et quand redémarrer. FreeBSD vous oblige simplement à formuler la seconde partie explicitement, car il ne le fera pas pour vous. La comparaison plus large entre Linux et FreeBSD en tant que plateforme serveur couvre les autres changements lors du transfert d'une charge de travail entre ces deux systèmes.

FAQ

Est-ce que freebsd-update met aussi à jour mes paquets ?

Non. freebsd-update ne concerne que le système de base, c'est-à-dire le noyau et l'espace utilisateur fournis avec la release. Les logiciels installés via /usr/local proviennent des paquets et sont mis à jour avec pkg upgrade. Exécutez pkg audit -F pour identifier les paquets installés ayant des vulnérabilités connues, car les avis de sécurité du système de base ne les mentionnent jamais et les listes de diffusion de sécurité ne les annoncent pas.

Comment savoir si une mise à jour FreeBSD nécessite un redémarrage ?

Comparez freebsd-version -k et uname -r. La première commande affiche le noyau présent sur le disque, y compris celui qui vient d'être écrit mais pas encore chargé. La seconde affiche le noyau en cours d'exécution. Si les chaînes diffèrent, un redémarrage est nécessaire. Si elles sont identiques, le correctif ne concernait que l'espace utilisateur ; redémarrez alors les services affectés, par exemple avec service sshd restart, car un processus actif conserve l'ancienne bibliothèque en mémoire jusqu'à son redémarrage.

Quelle est la différence entre un Security Advisory et un Errata Notice ?

Un Security Advisory, comme FreeBSD-SA-26:55.elf, corrige une vulnérabilité de sécurité dans le système de base. Un Errata Notice, comme FreeBSD-EN-26:18.tzdata, corrige un problème de fonctionnement ou de stabilité sans impact sur la sécurité, comme des données de fuseau horaire obsolètes. Les deux suivent le format année, deux-points, numéro de séquence, composant. Tous deux sont signés par le Security Officer et diffusés par freebsd-update, et aucun ne couvre les logiciels installés depuis les ports ou les paquets.

Existe-t-il un équivalent à unattended-upgrades pour FreeBSD ?

Pas dans le système de base. freebsd-update cron télécharge les correctifs en attente pour le système de base et envoie un mail à root, mais ne les installe jamais. Le script périodique installé par pkg exécute pkg audit quotidiennement et envoie le résultat par mail, sans rien mettre à jour. L'installation automatique est une procédure que vous devez mettre en place vous-même via une tâche cron. Comme une mise à jour de paquet FreeBSD installe la version la plus récente plutôt qu'un simple correctif de sécurité, la plupart des administrateurs lisent le mail et effectuent l'installation manuellement.

Comment vérifier si ma version de FreeBSD est toujours supportée ?

Exécutez freebsd-version -u pour connaître votre version de l'espace utilisateur, puis comparez-la avec le tableau des branches supportées sur la page de sécurité de FreeBSD. Les versions mineures ont une durée de vie courte : en août 2026, la version 15.0-RELEASE expire le 30 septembre 2026, tandis que la 15.1-RELEASE est supportée jusqu'au 31 mars 2027. freebsd-update fetch vous avertit à l'approche de la date limite, et une fois celle-ci dépassée, il affiche une ligne indiquant que la release A DÉPASSÉ SA DATE DE FIN DE VIE. Après ce point, aucun avis de sécurité ne vous concerne plus.