Renforcez la sécurité de votre Ubuntu : bonnes pratiques pour 2026

Principaux enseignements

• Ubuntu est livré avec des fonctionnalités de sécurité intégrées fiables : AppArmor, UFW et unattended-upgrades. Cependant, les paramètres par défaut ne vous protègent que si vous les configurez et les mettez à jour régulièrement.
• La plupart des failles de sécurité sur Ubuntu s'expliquent par trois facteurs : des noyaux non mis à jour, des pratiques SSH peu rigoureuses et l'utilisation d'une version LTS au-delà de sa fin de vie sans plan de transition.
• La correction du noyau à chaud vous permet d'appliquer des correctifs critiques au noyau sans avoir à planifier de redémarrage, ce qui est particulièrement important pour les charges de travail fonctionnant 24 heures sur 24 et 7 jours sur 7, où les temps d'arrêt ont un coût élevé.
• Le chiffrement des disques, la surveillance de l'intégrité des fichiers et la journalisation des audits sont souvent négligés dans les configurations de base, mais ils font toute la différence en cas de problème.

Ubuntu équipe une grande partie des serveurs Linux dans le monde, et c'est précisément en raison de cette popularité qu'il convient de prendre au sérieux la sécurité d'Ubuntu. Les pirates s'attaquent là où se trouvent leurs cibles. La bonne nouvelle : Ubuntu offre d'emblée une base solide. La moins bonne nouvelle : cette base repose sur le fait que vous allez effectivement le configurer, l'actualiser régulièrement et avoir un plan prêt pour le moment où une version LTS arrivera en fin de support.

Ce guide vous présente les mesures de protection dont vous disposez déjà, les endroits où les menaces réelles ont tendance à se manifester, ainsi que quelques bonnes pratiques qui font réellement la différence.

Qu'est-ce qu'Ubuntu ?

Ubuntu est une distribution Linux dérivée de Debian, gérée par Canonical, dont la première version a été lancée en 2004. Elle figure aujourd’hui parmi les systèmes d’exploitation pour serveurs les plus répandus au monde. Open source et gratuite, elle se décline en deux versions principales : les versions à support à long terme (LTS), qui bénéficient d’un support de sécurité standard pendant cinq ans, et les versions intermédiaires, publiées tous les six mois, dont chacune est prise en charge pendant neuf mois.

Pourquoi les utilisateurs d'Ubuntu devraient-ils se préoccuper de la sécurité ?

Car Ubuntu est omniprésent. Charges de travail dans le cloud, serveurs de conteneurs, ordinateurs portables de développeurs, appareils en périphérie. Le rapport 2026 Open Source Landscape Report de TuxCare a révélé que plus de la moitié des utilisateurs de Linux en entreprise utilisent Ubuntu en production – plus que toute autre distribution. Cette concentration en fait une cible constante et de grande valeur.

Le rapport DBIR 2026 de Verizon révèle que l'exploitation de vulnérabilités est désormais le vecteur d'accès initial le plus courant dans les violations de données, avec un taux de 31 % – soit une hausse de 55 % par rapport à l'année précédente – et qu'elle dépasse pour la première fois le vol d'identifiants. Pour les serveurs Linux, les CVE non corrigées constituent la voie d'accès la plus directe.

Le risque s'aggrave rapidement si vous continuez à utiliser votre version au-delà de la période de support standard. Les signalements de CVE à la base de données nationale sur les vulnérabilités du NIST ont augmenté de 263 % entre 2020 et 2025, avec près de 42 000 CVE enregistrés pour la seule année 2025 – et le NIST lui-même a averti que ce volume continuait de croître. Un hôte Ubuntu en fin de vie (EOL) cesse de recevoir des correctifs pour pratiquement toutes ces vulnérabilités. L'écart entre la « publication d'un CVE » et la « mise à jour de votre système » est déjà suffisamment important sur les versions prises en charge ; sur une version non prise en charge, il ne se comble jamais.

Principales fonctionnalités de sécurité d'Ubuntu

Les paramètres par défaut d'Ubuntu ne sont pas mauvais. Ils sont simplement incomplets. Voici ce qui est fourni, ce qui est activé par défaut et ce que chaque option vous apporte concrètement.

Démarrage sécurisé

Le démarrage sécurisé (Secure Boot) met en place une chaîne de confiance pendant le processus de démarrage, garantissant que seuls des logiciels signés et fiables sont chargés avant que les mécanismes de sécurité du système d'exploitation n'entrent en action. Sous Ubuntu, tous les binaires de démarrage précompilés sont signés avec le certificat UEFI de Canonical. C'est important car un chargeur d'amorçage ou un micrologiciel compromis peut donner à un attaquant un accès au niveau du noyau avant qu'AppArmor, UFW ou tout autre contrôle n'ait eu le temps d'intervenir. La plupart des instances cloud et des déploiements bare-metal modernes disposent de Secure Boot – il vaut mieux vérifier qu'il est bien activé plutôt que de supposer qu'il l'est.

AppArmor

AppArmor est le système de contrôle d'accès obligatoire (MAC) d'Ubuntu, activé par défaut. Il limite ce que chaque programme peut lire, écrire ou exécuter, indépendamment des droits d'accès aux fichiers, en s'appuyant sur des profils chargés pour chaque binaire. Ubuntu fournit des profils pour les services à haut risque tels que CUPS, MySQL et Firefox.

Comparé à SELinux, AppArmor permet de rédiger plus facilement des règles, ce qui explique en partie pourquoi Canonical l'a choisi. Cela dit, la plupart des équipes ne créent jamais de profil personnalisé au-delà de celui fourni par défaut, ce qui laisse de nombreuses possibilités inexploitées.

Ubuntu 24.04 a également introduit des restrictions au niveau des espaces de noms des utilisateurs non privilégiés, qui limitent les actions que les processus peuvent effectuer au sein d'espaces de noms isolés sans droits élevés. Il s'agit d'un contrôle au niveau du noyau qui réduit la surface d'attaque pour les évasions de conteneurs et les contournements de sandbox ; cette fonctionnalité est activée par défaut et il est recommandé de la laisser activée.

Mises à jour automatiques

Le unattended-upgrades Le paquet récupère automatiquement les mises à jour de sécurité depuis les archives d'Ubuntu sans intervention manuelle. Lors d'une nouvelle installation sur un serveur, il est activé uniquement pour le « security pocket », ce qui correspond au bon paramètre par défaut.

Si vous le remplacez sans réfléchir, ou si vous le désactivez parce qu'un redémarrage a un jour causé une panne en production, vous aurez en fait désactivé le mécanisme de contrôle automatisé le plus efficace de la machine.

Il est important de comprendre comment Ubuntu gère les correctifs de sécurité : plutôt que de vous pousser vers la dernière version en amont d'un paquet, l'équipe de sécurité d'Ubuntu utilise le « backporting de sécurité », c'est-à-dire qu'elle applique le correctif spécifique à la version déjà présente dans votre distribution. C'est pourquoi la commande « apt upgrade » sous Ubuntu 22.04 ne vous fournira pas soudainement une version complètement différente d'OpenSSL ; elle vous fournira la même version, mais avec la faille corrigée.

Faites particulièrement attention aux paquets provenant du dépôt « universe » : contrairement au dépôt « main », qui est géré et mis à jour en matière de sécurité directement par Canonical, les paquets du dépôt « universe » sont gérés par la communauté et ne bénéficient pas toujours de correctifs de sécurité en temps opportun.

Cookies UFW et SYN

Uncomplicated Firewall (UFW) est l'interface par défaut d'iptables/nftables, et Ubuntu active par défaut les cookies SYN TCP au niveau du noyau afin de contrer les attaques par inondation SYN. À eux seuls, les cookies SYN ne remplacent pas un pare-feu, et UFW ne remplace pas les contrôles au niveau du réseau, mais ensemble, ils gèrent une grande partie du trafic de fond sans nécessiter de configuration particulière.

Livepatch

Canonical Livepatch applique un sous-ensemble de correctifs de sécurité du noyau sans redémarrer l'hôte. C'est utile, mais son champ d'application est plus restreint que ne le laisse entendre le marketing. Il ne couvre que les noyaux LTS pris en charge, se concentre sur les CVE de gravité élevée et critique, et n'intervient absolument pas sur les bibliothèques de l'espace utilisateur.

Retour à la réalité : Livepatch n'est pas une solution complète de correction du noyau. Elle couvre un ensemble défini de CVE du noyau sur les noyaux LTS pris en charge, et rien en dehors du noyau. Les équipes exécutant des charges de travail renforcées 24 h/24 et 7 j/7 finissent souvent par la compléter (ou la remplacer purement et simplement) par une solution telle que KernelCare, qui couvre un ensemble plus large de CVE, LibCare étendant également la correction en direct aux bibliothèques partagées. Consultez l'analyse de TuxCare sur les limites de Livepatch pour plus de détails.

Chiffrement de disque LUKS

Ubuntu prend en charge le chiffrement complet du disque via LUKS (Linux Unified Key Setup), et le moment le plus simple pour l'activer est lors de l'installation. Le programme d'installation d'Ubuntu propose une option intitulée « Chiffrer la nouvelle installation d'Ubuntu » qui permet de configurer un volume LVM chiffré. Une fois cette option activée, l'intégralité du disque devient illisible sans le mot de passe, ce qui est particulièrement important en cas de vol physique ou lors de la mise hors service du matériel.

Une mise en garde importante que les administrateurs système ont parfois tendance à négliger : LUKS protège les données au repos. Une fois le système démarré et le disque déverrouillé, le chiffrement ne permet pas d'empêcher un attaquant qui se trouve déjà sur le système d'agir. C'est pourquoi le chiffrement du disque ne remplace pas la mise à jour régulière du noyau et de l'espace utilisateur. Un système doté d'un disque chiffré mais dont le noyau n'est pas mis à jour reste entièrement vulnérable en mémoire. Ces deux mesures de sécurité répondent à des modèles de menace différents, et les deux sont indispensables.

Si vous n'avez pas chiffré le système lors de l'installation, cryptsetup permet de chiffrer des partitions ou des volumes individuels a posteriori, même si cette opération est plus complexe que lors de la configuration initiale. La documentation de la communauté Ubuntu décrit cette procédure en détail.

Menaces courantes pour la sécurité des systèmes Ubuntu

Ubuntu est constamment pris pour cible. Les menaces ci-dessous sont celles qui apparaissent réellement dans les rapports d'incidents, et non des risques théoriques.

Vulnérabilités CVE non corrigées dans le noyau et l'espace utilisateur

Les vulnérabilités CVE du noyau font la une, mais la plupart des compromissions d'Ubuntu passent par des composants de l'espace utilisateur non corrigés : OpenSSL, glibc, sudo, polkit, CUPS. La chaîne d'exécution de code à distance CUPS de 2024 en est un exemple typique. Elle était présente dans les installations par défaut de toutes les versions d'Ubuntu et ne nécessitait rien de plus qu'une accessibilité réseau pour être exploitée. Consultez l'analyse de TuxCare sur les vulnérabilités de CUPS pour obtenir des détails techniques.

Attaques par force brute et attaques visant les identifiants SSH

Tout serveur Ubuntu dont le port 22 est ouvert sur Internet commence à enregistrer des tentatives de force brute quelques minutes seulement après sa mise en ligne. Ces attaques sont rudimentaires, automatisées et incessantes ; il leur suffit de réussir une seule fois face à un mot de passe faible ou à une clé qui a fuité.

Configuration incorrecte ou versions obsolètes de Python et des bibliothèques

Les archives d'Ubuntu contiennent une multitude de paquets Python, et les interpréteurs obsolètes constituent une source courante de vulnérabilités (CVE). Une équipe qui utilise encore Python 3.8 en production se retrouvera, d'ici 2026, à utiliser un interpréteur dont la prise en charge aura déjà pris fin en amont. TuxCare a analysé en détail le paysage des vulnérabilités Python sur Ubuntu si vous souhaitez en comprendre l'ampleur.

Fonctionnement au-delà de la fin de vie

Ubuntu LTS bénéficie d'un support standard pendant cinq ans. Passé ce délai, les correctifs de sécurité ne sont plus fournis, sauf si vous utilisez Ubuntu Pro – qui inclut le service ESM (Expanded Security Maintenance) et prolonge la couverture jusqu'à dix ans à compter de la date de sortie initiale – ou une solution équivalente proposée par un tiers. De nombreux parcs informatiques de production fonctionnent encore sous Ubuntu 18.04 ou une version antérieure, et ces serveurs accumulent des vulnérabilités CVE non corrigées chaque semaine où ils restent en ligne.

Élévation des privilèges via des composants vulnérables

L'escalade locale des privilèges via des failles de sudo, de polkit ou du noyau est un problème récurrent sur Ubuntu depuis des années. Ces attaques partent généralement d'un point d'ancrage initial aux privilèges limités (un utilisateur d'application web compromis, par exemple) et peuvent permettre d'obtenir les droits root en quelques minutes. TuxCare tient à jour un registre des vulnérabilités récentes d'Ubuntu qu'il est utile de consulter régulièrement.

Bonnes pratiques pour renforcer la sécurité d'Ubuntu

Ce qui rend un serveur Ubuntu difficile à pirater, c'est surtout un travail sans grand intérêt et répétitif. Les mesures décrites ci-dessous offrent le meilleur rapport effort-efficacité.

Réduire le nombre de paquets installés

Chaque paquet installé sur votre système est un code susceptible de comporter des vulnérabilités. Un spouleur d'impression que vous avez oublié, un outil de développement laissé de côté, un service fourni avec un autre logiciel… N'importe lequel de ces éléments peut receler une vulnérabilité CVE dont vous n'avez jamais entendu parler, simplement parce que vous ne les suivez pas. La solution est fastidieuse, mais efficace : allégez la liste des paquets.

Commencez par faire l'inventaire de ce qui est réellement installé :

apt list --installed 2>/dev/null | less

Vérifiez ce que fait réellement votre serveur. S'agit-il d'un serveur web ? Dans ce cas, il n'a pas besoin d'outils Bluetooth ni de CUPS. S'agit-il d'un serveur de base de données ? Il n'a probablement pas besoin d'un agent de transfert de courrier. Supprimez ce dont vous n'avez pas besoin :

sudo apt remove --purge <package-name>

À suivre :

sudo apt autoremove

Pendant que vous y êtes, vérifiez quels services sont à l'écoute sur le réseau :

ss -tlnp

Tout élément de cette liste qui n'a pas sa place mérite d'être examiné. Désactivez les services inutilisés à l'aide de sudo systemctl disable --now <service>. Moins votre système est sollicité, moins il y a de failles à exploiter.

Appliquez les correctifs sans hésiter – et ne vous fiez pas aveuglément aux paramètres par défaut

Vérifiez que la commande « unattended-upgrades » est bien en cours d'exécution (systemctl status unattended-upgrades) et en sortant de la poche de sécurité.

Si vous gérez des charges de travail fonctionnant 24 heures sur 24, 7 jours sur 7, pour lesquelles les redémarrages sont coûteux, c'est l'une des rares solutions qui permet de résoudre ce problème de manière efficace. KernelCare fournit des correctifs du noyau en temps réel sous Ubuntu sans nécessiter de redémarrage et couvre un ensemble de CVE plus large que Livepatch.

Il est également conseillé d'exécuter régulièrement la commande `ubuntu-security-status` : elle vous fournit une liste claire des paquets installés qui bénéficient du support standard, de ceux qui nécessitent Ubuntu Pro/ESM, et de ceux pour lesquels des mises à jour de sécurité sont en attente.

Sécuriser SSH

Désactiver la connexion en tant qu'utilisateur root (PermitRootLogin no), désactiver complètement l'authentification par mot de passe (PasswordAuthentication no), et nécessitent une authentification par clé.

Si vous ne pouvez pas mettre en place une liste blanche d'adresses IP (ce qui est courant dans les environnements avec des adresses IP dynamiques ou pour les télétravailleurs sans VPN), l'authentification à deux facteurs sur SSH vaut largement le temps nécessaire à sa configuration. Le paquet libpam-google-authenticator permet d'ajouter une authentification à deux facteurs (2FA) basée sur le protocole TOTP à la connexion SSH en environ 15 minutes. Même en cas de fuite de la clé privée, un attaquant aurait toujours besoin du code à rotation. Cela ne remplace pas l'authentification par clé seule, mais ajoute une couche de sécurité significative pour les scénarios d'accès à haut risque.

Conseil de pro : Exécutez régulièrement lastb pour passer en revue les tentatives de connexion infructueuses. Des milliers de tentatives visant les comptes root ou admin provenant d'un seul ASN ne constituent pas vraiment une attaque. Il s'agit simplement de bruit de fond. La solution consiste à fermer la porte à l'aide d'une authentification par clé uniquement et d'une liste blanche d'adresses IP, et non à traquer chaque adresse IP individuellement.

Activer la journalisation d'audit et la surveiller

Installez auditd et configurez des règles pour les événements importants : modifications de fichiers dans /etc, exécutions de sudo, création de nouveaux utilisateurs, chargement de modules du noyau. Les journaux que vous ne lisez pas ne servent à rien. Transférez-les vers un serveur de journaux central ou une plateforme SIEM. L'objectif n'est pas de faire semblant de respecter les normes, mais de détecter les événements d'authentification suspects avant qu'ils ne se transforment en violation de sécurité.

Associez auditd à un outil de surveillance de l'intégrité des fichiers tel qu'AIDE (Advanced Intrusion Detection Environment). Alors qu'auditd consigne les événements, AIDE détecte les modifications. Il établit une base de référence de votre système de fichiers (hachages de fichiers, droits d'accès, propriété) et signale les écarts lorsque vous effectuez une vérification. C'est particulièrement utile pour détecter les activités post-compromission qui ne génèrent pas d'événements de journalisation évidents : un binaire discrètement remplacé, une bibliothèque modifiée, une tâche cron ajoutée. Exécutez sudo aideinit pour établir la base de référence après une installation propre, puis planifiez des vérifications régulières via cron. Tout comme la surveillance des journaux, cela n'est utile que si quelqu'un examine réellement les résultats.

Si votre environnement est soumis à des exigences de conformité, les référentiels CIS et les STIG de la DISA proposent tous deux des profils de renforcement de sécurité spécifiques à Ubuntu qui correspondent directement aux mesures de contrôle mentionnées ci-dessus ; ils constituent une liste de contrôle structurée utile plutôt que de devoir partir de zéro.

Préparez votre fin de vie avant qu'elle n'arrive

Chaque version LTS d'Ubuntu a une date de fin de vie (EOL) officiellement annoncée. Vous disposez de trois options concrètes : effectuer une mise à niveau directe vers la prochaine version LTS, migrer vos charges de travail vers une version prise en charge, ou souscrire à un support étendu. L'option « ne rien faire » devient la solution par défaut lorsque les équipes manquent de temps, et c'est sans aucun doute la pire.

Les mises à niveau sur site ne sont pas toujours possibles. Applications héritées, dépendances des modules du noyau, intergiciels certifiés : tous ces éléments peuvent empêcher une mise à niveau sans heurts. C'est précisément pour ce type de situation que le service « Endless Lifecycle Support » de TuxCare a été conçu. Il fournit des correctifs de sécurité continus pour Ubuntu 16.04, 18.04 et 20.04 aussi longtemps que vous en avez réellement besoin, et pas seulement jusqu'à la date de fin de vie (EOL) fixée par le fournisseur.

C'est une option plus courante qu'on ne le pense. L'enquête menée par TuxCare en 2026 a révélé que les organisations confrontées à des logiciels en fin de vie (EOL) étaient presque à parts égales entre celles qui optaient pour la migration et celles qui choisissaient d'acheter un support de cycle de vie prolongé (ELS) – 41,7 % dans chaque cas. Pour de nombreuses équipes, l'ELS n'est pas une solution de secours, mais bien la stratégie privilégiée.

Voici un scénario qui se produit plus souvent qu’on ne le pense. Une équipe prévoit une mise à niveau d’Ubuntu 18.04 vers 22.04 six mois avant la fin de vie du produit, se heurte à un problème de compatibilité de module du noyau avec un appareil d’un fournisseur, et finit par continuer à utiliser la version 18.04, qui n’est plus prise en charge, pendant encore un an, le temps que le service des achats trouve une solution. La couverture ELS est précisément conçue pour ce genre de situation.

Ressources sur la sécurité sous Ubuntu

Quelques sites à consulter régulièrement pour se tenir au courant.

Avis de sécurité d'Ubuntu

Le flux « Ubuntu Security Notices » est la source officielle de Canonical pour les avis CVE concernant les paquets Ubuntu, avec des informations sur les rétroportages et les niveaux de gravité. Abonnez-vous via RSS ou la liste de diffusion. Ces avis sont gérés par l'équipe de sécurité d'Ubuntu, le groupe dédié de Canonical chargé d'évaluer les vulnérabilités et de publier des correctifs de sécurité pour toutes les versions d'Ubuntu.

Catalogue des vulnérabilités connues ayant fait l'objet d'exploits de la CISA

Le catalogue KEV de la CISA recense les vulnérabilités CVE activement exploitées dans la nature. Le comparer aux versions de vos paquets Ubuntu est un moyen rapide de déterminer les correctifs à appliquer en priorité. Si une entrée du catalogue KEV correspond à un paquet installé, celui-ci doit être traité en priorité.

r/Ubuntu et r/linuxadmin

Ces deux subreddits mettent en avant des discussions concrètes sur la sécurisation, des analyses rétrospectives et des pièges pour les administrateurs système plus rapidement que la plupart des blogs des fournisseurs. Le rapport signal/bruit varie, mais le ton est sincère.

Suivi des vulnérabilités CVE de TuxCare

Si vous utilisez des versions prises en charge par ELS, telles qu’Ubuntu 16.04, 18.04 ou 20.04, nous vous recommandons d’ajouter le TuxCare CVE Tracker à vos favoris. Cet outil vous permet de filtrer les vulnérabilités par niveau de gravité, produit, composant et statut de correction sur l’ensemble des systèmes en fin de vie pris en charge par TuxCare et leurs chaînes de dépendances. Vous pouvez ainsi identifier précisément les failles exposées et savoir quand une solution corrective est disponible. Vous pouvez également vous abonner pour être averti lorsque le statut d'un CVE ou d'un correctif change, ce qui est bien plus pratique que de surveiller manuellement les flux d'avis de sécurité pour plusieurs produits en fin de vie.

Sécurisez vos systèmes Ubuntu avec TuxCare

Le renforcement de la sécurité d'Ubuntu n'est pas un projet ponctuel. Il s'agit d'un cycle de mise à jour, d'un verrouillage du protocole SSH, d'un plan de sortie de fin de vie et d'une habitude de vérifier les paramètres par défaut plutôt que de s'y fier aveuglément.

En ce qui concerne plus particulièrement les correctifs du noyau et la prise en charge après la fin de vie (EOL), les solutions KernelCare et Endless Lifecycle Support de TuxCare comblent les lacunes laissées par les offres standard de Canonical. KernelCare gère les correctifs du noyau sans redémarrage avec une couverture CVE plus étendue que Livepatch. ELS assure la couverture des versions Ubuntu 16.04, 18.04 et 20.04 avec des correctifs de sécurité aussi longtemps que nécessaire, au-delà de toute période de support définie par Canonical.

Résumé

Nom de l'article

Renforcez la sécurité de votre Ubuntu : bonnes pratiques pour 2026

Description

Découvrez pourquoi la sécurité sous Ubuntu est importante et comment les utilisateurs peuvent protéger leurs systèmes.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur