Désactiver des modules noyau inutiles sous Linux

Chaque module noyau chargeable est une surface d'attaque potentielle : un système de fichiers exotique (cramfs, udf, hfs) ou un protocole réseau rare (dccp, sctp) que vous n'utilisez jamais peut servir de vecteur, soit par un montage malveillant, soit via une CVE dans du code peu audité. Ce guide montre comment désactiver durablement ces modules avec modprobe.d, en évitant le piège classique du blacklist qui ne suffit pas. L'approche suit les recommandations des CIS Benchmarks.

Ce que vous allez apprendre

Lister et inspecter les modules noyau chargeables
Désactiver un module de façon fiable avec install et blacklist
Comprendre pourquoi blacklist seul laisse passer un chargement explicite
Rendre la désactivation persistante au démarrage (initramfs)
Éviter de casser un module légitime (squashfs, usb-storage)

Pourquoi désactiver des modules

Le noyau Linux charge ses pilotes à la demande. Sur un serveur, la plupart ne servent jamais : pilotes de systèmes de fichiers anciens, protocoles réseau de niche, formats d'archives. Chaque module présent est pourtant du code exécutable dans le noyau, donc :

une vulnérabilité dans dccp ou sctp (historiquement source de CVE d'élévation de privilèges) devient exploitable même si vous n'utilisez pas ces protocoles ;
un attaquant peut monter un système de fichiers piégé (cramfs, udf) pour déclencher un bug du parseur.

Désactiver ce qui ne sert pas réduit la surface sans rien retirer aux services en place. C'est la recommandation R10 (« Désactiver le chargement des modules noyau ») d'ANSSI-BP-028 v2.0, et l'objet des sections 1.1.1 (systèmes de fichiers) et 3.2 (protocoles réseau) des CIS Benchmarks.

Prérequis

Un serveur Linux (Debian, Ubuntu, RHEL, AlmaLinux, Rocky) ou une VM
Un accès root (ou sudo)
Idéalement une VM de test : un module désactivé par erreur peut empêcher un montage ou un boot

Lister et inspecter les modules

Avant de désactiver, regardez ce qui est chargé et ce qui est chargeable :

# Modules actuellement charges
lsmod

# Le module existe-t-il pour ce noyau ?
modinfo -n udf

# Simuler le chargement sans le faire (voir ce que modprobe ferait)
modprobe -n -v udf

Un module absent (modinfo échoue) est soit compilé en dur dans le noyau, soit indisponible : rien à désactiver dans ce cas.

Le piège : blacklist ne suffit pas

C'est l'erreur la plus répandue. La directive blacklist empêche seulement le chargement automatique (par alias ou détection matérielle), mais laisse passer un modprobe explicite. Démonstration sur dccp :

# 1. Le module se charge normalement
modprobe dccp
lsmod | grep dccp        # dccp est charge
modprobe -r dccp

# 2. On ajoute SEULEMENT blacklist
echo "blacklist dccp" > /etc/modprobe.d/test.conf
modprobe dccp
lsmod | grep dccp        # dccp est ENCORE charge !

Avec blacklist seul, modprobe dccp charge quand même le module. Un attaquant qui a déjà un accès peut donc l'activer. La parade est la directive install <module> /bin/false, qui remplace le chargement par une commande qui échoue :

printf "install dccp /bin/false\nblacklist dccp\n" > /etc/modprobe.d/test.conf
modprobe dccp

modprobe: ERROR: ... Error running install command '/bin/false' for module dccp: retcode 1
modprobe: ERROR: could not insert 'dccp': Invalid argument

Le module est réellement bloqué. Retenez la règle : deux directives par module, install ... /bin/false et blacklist.

Désactiver les modules

Regroupez les modules à neutraliser dans un fichier dédié de /etc/modprobe.d/.

Créer le fichier de durcissement

# Systemes de fichiers rares (CIS 1.1)
install cramfs /bin/false
blacklist cramfs
install freevxfs /bin/false
blacklist freevxfs
install jffs2 /bin/false
blacklist jffs2
install hfs /bin/false
blacklist hfs
install hfsplus /bin/false
blacklist hfsplus
install udf /bin/false
blacklist udf

# Protocoles reseau rares (CIS 3.4)
install dccp /bin/false
blacklist dccp
install sctp /bin/false
blacklist sctp
install rds /bin/false
blacklist rds
install tipc /bin/false
blacklist tipc

Décharger les modules déjà chargés (si besoin)

modprobe.d empêche les futurs chargements mais ne décharge pas un module déjà actif. Déchargez-le explicitement, ou prévoyez un redémarrage :
Fenêtre de terminal
```
sudo modprobe -r dccp
```

Aucun rechargement de service n'est nécessaire : modprobe relit /etc/modprobe.d/ à chaque appel.

Rendre la désactivation persistante au boot

Certains modules peuvent être chargés très tôt au démarrage, depuis l'initramfs (l'image mémoire initiale). Pour que vos règles s'y appliquent aussi, régénérez l'initramfs :

Debian / Ubuntu
RHEL / AlmaLinux / Rocky

sudo update-initramfs -u

sudo dracut -f

Le fichier /etc/modprobe.d/ est, lui, déjà persistant : il est relu à chaque boot. La régénération de l'initramfs ne concerne que les modules susceptibles d'être chargés avant le montage de la racine.

Vérifier

Tentez de charger quelques modules ciblés : ils doivent être refusés.

for m in udf sctp tipc; do
  modprobe $m 2>/dev/null
  lsmod | grep -qw "$m" && echo "$m : NON bloque" || echo "$m : bloque"
done

udf : bloque
sctp : bloque
tipc : bloque

Vérifiez au passage qu'un module légitime reste utilisable (par exemple le système de fichiers de la racine) :

lsmod | grep -w ext4

Sécurité et points de vigilance

Ne touchez pas à squashfs : il est utilisé par les snaps et les AppImage. Le blacklister casse ces applications.
usb-storage est listé par CIS, mais le désactiver empêche les clés USB. Ne le neutralisez que sur un serveur sans accès physique légitime.
Vérifiez l'usage réel avant de désactiver : un lsmod régulier et la connaissance de vos services évitent de couper un module nécessaire (RAID, chiffrement, réseau).
Tracez les tentatives : couplez ce durcissement avec auditd, qui journalise les appels init_module et delete_module.

Dépannage

Symptôme	Cause probable	Solution
`modprobe <mod>` charge encore le module	Seul `blacklist` est posé	Ajouter `install <mod> /bin/false`
Le module reste chargé après la config	Il était déjà actif	`modprobe -r <mod>` ou redémarrer
Le module revient après reboot	Chargé depuis l'initramfs	Régénérer l'initramfs (`update-initramfs -u` / `dracut -f`)
`permission denied` sur `modprobe`	Exécution dans un conteneur	Appliquer sur l'hôte ou une VM
Une clé USB ne monte plus	`usb-storage` désactivé	Retirer sa ligne du fichier `modprobe.d`

À retenir

Chaque module chargeable est une surface d'attaque ; désactivez ce qui ne sert pas
blacklist seul ne bloque pas un modprobe explicite : ajoutez install <mod> /bin/false
Regroupez les règles dans /etc/modprobe.d/ (relu à chaque modprobe)
Régénérez l'initramfs pour couvrir les chargements tôt au boot
Cibles CIS : systèmes de fichiers rares (1.1) et protocoles réseau rares (3.4)
Épargnez squashfs (snaps) et réfléchissez à usb-storage (clés USB)

Prochaines étapes

Tracer avec auditd Journaliser les chargements de modules (init_module) pour détecter une tentative de contournement.

Durcir le noyau avec sysctl Compléter la réduction de surface par les paramètres noyau et réseau.

CIS Benchmarks Le référentiel d'où viennent ces listes de modules à désactiver.

Auditer avec Lynis Vérifier automatiquement quels modules et durcissements manquent encore.