Le noyau Linux corrige désormais plus de 1 500 CVE par version majeure, et les projections pour Linux 7.3 approchent les 2 000 CVE par release. Cette inflation, portée par les outils d’analyse de code assistés par IA, change radicalement la donne pour les administrateurs système. Protéger un système Linux ne se résume plus à activer un pare-feu et lancer un apt upgrade hebdomadaire : c’est un travail de tri, de priorisation et d’architecture défensive continue.
Triage des CVE du noyau Linux : gérer l’avalanche de correctifs
Entre les versions 6.9 et 6.19 du noyau, le rythme tournait autour de 500 CVE corrigées par release. Depuis Linux 7.0, ce volume a doublé, puis triplé. Les mainteneurs eux-mêmes déclarent être « completely overwhelmed » par le flux de rapports générés via des outils automatisés.
Pour un administrateur, cela signifie que le patching systématique de chaque CVE est devenu irréaliste sans outillage de priorisation. Appliquer tous les correctifs en aveugle revient à redémarrer les services en continu, avec un risque de régression fonctionnelle sur des charges de production.
Un score CVSS brut de 7.5 sur une vulnérabilité réseau n’a pas le même impact sur un serveur isolé derrière un réseau privé que sur une machine exposée en DMZ. Une approche par score CVSS contextuel permet de hiérarchiser les correctifs réellement critiques.
Les outils comme KernelCare (live patching sans redémarrage) ou les flux OVAL fournis par les distributions filtrent les CVE applicables à votre configuration réelle. Les ressources consacrées à la sécurité sur Hebdo Linux complètent utilement cette veille technique.
Configuration SSH et contrôle des accès privilégiés sous Linux
SSH reste le vecteur d’attaque le plus ciblé sur les serveurs Linux exposés. La configuration par défaut d’OpenSSH sur la majorité des distributions est fonctionnelle, pas sécurisée.
Paramètres sshd_config à verrouiller en priorité
- PermitRootLogin no et désactivation de l’authentification par mot de passe (PasswordAuthentication no) : seule l’authentification par clé Ed25519 ou ECDSA devrait être autorisée sur un serveur de production
- Restriction des algorithmes de chiffrement aux suites modernes via KexAlgorithms et Ciphers, en excluant explicitement diffie-hellman-group1-sha1 et CBC
- Activation de AllowUsers ou AllowGroups pour limiter l’accès SSH à une liste nominative de comptes, plutôt que de s’appuyer uniquement sur le pare-feu
- MaxAuthTries fixé à 3 et LoginGraceTime réduit à 30 secondes pour limiter la fenêtre de brute-force
Gestion de l’escalade de privilèges avec sudo
La configuration sudoers mérite autant d’attention que SSH. Un fichier sudoers trop permissif annule toute politique de moindre privilège. On observe encore régulièrement des configurations où un compte applicatif dispose de ALL=(ALL) NOPASSWD: ALL, ce qui revient à lui accorder un accès root permanent.
La bonne pratique consiste à créer des alias de commandes ciblés (Cmnd_Alias) pour chaque rôle applicatif, et à journaliser chaque invocation sudo via syslog. Couplé à auditd, cela fournit une traçabilité complète des actions privilégiées.
Réduction de la surface d’attaque réseau sur un serveur Linux
Chaque port ouvert et chaque service actif représente un point d’entrée potentiel. La réduction de surface d’attaque commence par un inventaire rigoureux.
La commande ss -tulnp (qui remplace netstat) liste les sockets en écoute avec le processus associé. Sur un serveur web typique, seuls les ports 22, 80 et 443 devraient apparaître. Tout service supplémentaire (postfix, cups, avahi-daemon, rpcbind) doit être désactivé via systemctl disable si non requis, puis masqué avec systemctl mask pour empêcher une réactivation accidentelle.
Pour le filtrage réseau, nftables a remplacé iptables comme framework par défaut sur les noyaux récents. Sa syntaxe déclarative par ensembles (sets) et cartes (maps) simplifie la gestion des règles à grande échelle. Une politique par défaut en drop sur les chaînes input et forward, avec ouverture explicite des flux nécessaires, reste la base.
Audit et journalisation : auditd, journald et détection d’intrusion Linux
Sans journalisation centralisée, toute compromission reste invisible jusqu’à ce que les dégâts soient constatés. Le framework audit du noyau Linux (auditd) permet de surveiller les appels système critiques avec une granularité fine.
Les règles à configurer en priorité concernent la surveillance des modifications sur /etc/passwd, /etc/shadow, /etc/sudoers et les fichiers de configuration SSH. Une règle auditctl du type -w /etc/shadow -p wa -k shadow_changes journalise toute écriture ou modification d’attributs sur le fichier.
Pour la détection d’intrusion au niveau fichier, AIDE (Advanced Intrusion Detection Environment) génère une empreinte cryptographique de l’arborescence système. Toute modification non autorisée d’un binaire ou d’un fichier de configuration déclenche une alerte lors du prochain scan. Un scan quotidien via cron avec envoi du rapport par canal chiffré constitue un minimum viable.
Journald, couplé à une agrégation distante (via systemd-journal-remote ou un collecteur comme rsyslog vers un SIEM), permet de corréler les événements entre plusieurs serveurs. Un attaquant qui compromet une machine tentera de purger les logs locaux. L’envoi des journaux vers un serveur tiers rend cette purge inefficace.
Cyber Resilience Act et conformité des systèmes Linux en Europe
Le Cyber Resilience Act (CRA) impose aux éditeurs de logiciels commerciaux, y compris ceux intégrant des composants open source, des obligations de suivi des vulnérabilités et de fourniture de correctifs sur toute la durée de vie du produit. Les premières obligations de reporting entrent en vigueur en septembre 2026.
Pour les équipes qui déploient Linux en environnement professionnel, le CRA signifie concrètement que la traçabilité des composants (SBOM, Software Bill of Materials) et la capacité à démontrer un processus de gestion des correctifs deviennent des exigences réglementaires, pas uniquement des bonnes pratiques. Les distributions majeures ont commencé à fournir des SBOM exploitables, mais la responsabilité de conformité reste portée par l’entité qui met le produit sur le marché européen.
La combinaison d’un noyau qui génère près de 2 000 CVE par release et d’un cadre réglementaire qui exige une gestion documentée de chaque vulnérabilité rend les outils de live patching et d’automatisation du triage non plus optionnels, mais structurellement nécessaires pour toute infrastructure Linux en production.