← Toutes les règles
SOCLE-CLD-MOD-022// Kernel modulesmoyenneruntime effectif

Désactiver le chargement du pilote de stockage USB via modprobe

Garantit que le module noyau usb_storage n'est pas chargé et qu'il est mis en liste noire afin que les périphériques de stockage de masse USB ne puissent pas être montés.

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 4 normes

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.

Pourquoi cette règle

Les périphériques de stockage USB tels que les clés peuvent servir à introduire des logiciels malveillants ou à exfiltrer des données, en contournant totalement les contrôles réseau. Mettre le module usb_storage en liste noire empêche le système de monter les supports de masse USB, fermant un vecteur d'attaque physique majeur pour le vol de données et la diffusion de logiciels malveillants.

Ce que vérifie Pavois

Pavois interroge l'état effectif du module, pas les fichiers de configuration : il vérifie que usb_storage est absent du noyau en cours d'exécution et que modprobe refuse de le charger. Une analyse basée uniquement sur les fichiers passerait même si le module s'était déjà chargé automatiquement à l'instant où une clé USB a été branchée ; inspecter le noyau vivant détecte un module actif et tout drop-in qui le réactive.

describe kernel_module('usb_storage') do
  it { should_not be_loaded }
  it { should be_disabled }
end

Comment vérifier qu’elle est appliquée

  • lsmod | grep usb_storage ne doit rien renvoyer.
  • modprobe -n -v usb_storage doit afficher install /bin/true.
  • grep -r usb_storage /etc/modprobe.d/ doit montrer blacklist usb_storage et install usb_storage /bin/true.
  • Brancher une clé USB ne doit PAS créer de nouveau périphérique bloc (lsblk inchangé).

Inspecter et investiguer

  • dmesg | grep -i usb-storage et journalctl -k | grep usb_storage montrent les tentatives de chargement à l'insertion d'un support.
  • lsmod et modprobe -n -v usb_storage reflètent l'état réel.

Remédiation

Le plan de durcissement de Pavois utilise la ressource kernel_module pour mettre usb_storage en liste noire : il écrit un drop-in modprobe qui blackliste le module et redirige son chargement vers /bin/true, puis le décharge s'il est actif. Un redémarrage est requis pour purger un module utilisé. Appliquez avec pavois harden apply.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

actionblacklist
nameusb_storage
reboot_requiredtrue
resourcekernel_module
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Désactive TOUT le stockage de masse USB, les disques externes, clés USB et lecteurs de cartes USB ne se monteront plus. Attention : ne pas appliquer aux postes de travail ou aux hôtes dépendant de supports USB pour les sauvegardes, installations ou transferts de données, et assurez-vous de ne pas démarrer/récupérer depuis une clé USB. Les claviers/souris USB ne sont pas affectés (pilote différent). Vérifiez les besoins opérationnels avec lsblk et findmnt avant d'appliquer.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS1.1.1.9, 3.4.2, 1.1.1.8, 1.1.1.10directper OS, see the benchmark tablehaute
NIST3.1.21, CM-6(a), CM-7(a), CM-7(b), MP-7support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS3.4.2support4.0.1moyenne
DISA STIGUBTU-22-291010, UBTU-24-300039directper OS STIG releasehaute

Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.

Sources & références