Auditer les périphériques USB et bloquer les indésirables (scriptable)

Modèle de menace : pourquoi l’USB représente un risque en production

L’USB n’est pas « juste un port ». C’est un bus avec alimentation, hotplug, multiples classes de périphériques et une longue histoire
d’hypothèses « faire confiance au périphérique, que peut-on faire d’autre ? ». Ça passe sur un portable de dev. C’est imprudent sur un
serveur qui contient des identifiants, des données clients ou tout ce que vous seriez gêné d’expliquer devant un comité d’audit.

Les modes d’échec opérationnels les plus courants ne nécessitent pas un malware de blockbuster :

• Exfiltration de données : un stockage de masse USB se monte, quelqu’un copie quelques répertoires, la journée est fichue.
• Injection de frappes : un périphérique se présente comme clavier (HID) et tape des commandes plus vite qu’un humain ne cligne des yeux.
• Pivot réseau : un gadget « USB Ethernet » apparaît et crée une nouvelle interface réseau avec DHCP.
• Instabilité des services : un pilote se lie à un nouveau périphérique série USB et modifie les chemins /dev ou les noms udev.
• Surprises de la chaîne d’approvisionnement : périphérique identique en apparence, mais IDs USB différents, firmware différent, comportement différent.

Votre travail n’est pas de « bloquer l’USB ». Votre travail est de décider ce que l’USB est autorisé à faire sur cette catégorie d’hôtes,
puis de l’appliquer avec des outils qui ne reposent pas sur l’espoir.

Une citation pour rester lucide : « L’espoir n’est pas une stratégie. » — James Cameron.

Faits et contexte qui influencent les décisions

Quelques points courts et concrets qui comptent quand vous concevez une politique au lieu de débattre sur Slack :

1. Le stockage de masse USB existe depuis des décennies et est devenu omniprésent parce que c’était d’une simplicité extrême : présenter un périphérique bloc, laisser l’OS le monter.
2. HID (claviers/souris) est « de confiance par défaut » dans la plupart des environnements parce que l’ergonomie l’a emporté sur la sécurité à l’époque des PC.
3. Les périphériques USB composites sont normaux : un même appareil physique peut exposer plusieurs fonctions (HID + stockage + série). C’est pratique pour les stations d’accueil, pratique aussi pour les attaquants.
4. Les IDs Vendor/Product ne sont pas une authentification : ce sont des identifiants, et le firmware peut mentir. Ils sont utiles pour la politique, pas comme preuve de fiabilité.
5. Les adaptateurs série USB ont créé tout un écosystème de dépendances opérationnelles (accès console, UPS, contrôle PDU). Tout bloquer casse le travail réel.
6. « BadUSB » a forcé l’industrie à admettre le problème du firmware : le firmware peut reprogrammer le périphérique et présenter d’autres classes, même s’il ressemble à une clé.
7. Linux considère « un nouveau périphérique est apparu » comme une tempête d’événements : règles udev, generators systemd, networkd, automounts de bureau—beaucoup d’acteurs réagissent.
8. Les serveurs ont discrètement des dépendances USB : watchdogs matériels, dongles de licence, KVMs et médias virtuels BMC apparaissent tous comme des choses USB.
9. Les docks USB-C modernes sont des usines de fonctions : stockage, Ethernet, audio, affichage, saisie—votre politique doit être explicite sur ce qui est acceptable.

Si ces faits vous rendent mal à l’aise, tant mieux. C’est la bonne base.

Procédure de diagnostic rapide

Quand quelque chose lié à l’USB est « bizarre » (montages mystérieux, nouvelles interfaces, noms de périphériques instables), ne commencez pas par
une politique théorique. Commencez par une séquence de triage rapide qui réduit le périmètre.

Première étape : quel événement vient d’avoir lieu ?

• Vérifiez le kernel/journal pour les événements de hotplug et les liaisons de pilotes.
• Identifiez la classe de périphérique (stockage/HID/réseau/série).
• Confirmez si le système a monté ou configuré quelque chose automatiquement.

Deuxième étape : quel périphérique est-ce, exactement ?

• Obtenez les IDs vendor/product, le numéro de série (s’il existe) et le chemin du port physique.
• Vérifiez s’il s’agit d’un périphérique composite exposant plusieurs interfaces.
• Cartographiez du périphérique USB vers le nœud de périphérique bloc (le cas échéant) et vers les montages de système de fichiers.

Troisième étape : quel plan de contrôle avez-vous ?

• Si vous utilisez usbguard, vérifiez les journaux de politique et l’état du périphérique.
• Sinon, décidez s’il faut bloquer via le module noyau (mass storage), des règles udev ou un verrouillage physique des ports.
• Appliquez un blocage temporaire réversible, puis rédigez la règle permanente en testant.

Le goulot d’étranglement n’est généralement pas « l’USB ». C’est votre observabilité de l’USB. Corrigez cela en premier, puis appliquez la politique.

Fondamentaux de l’audit : ce qui est branché et ce que c’est réellement

Auditer l’USB sous Linux consiste à construire une chaîne de preuve :
événement kernel → ID USB → classe d’interface → pilote → nœud de périphérique → comportement système.
Si vous ne pouvez pas tracer cette chaîne pour un périphérique, vous ne le contrôlez pas.

Aussi : ne vous fiez pas au « nom » du périphérique affiché par les outils de bureau. En production, vous devez vous soucier d’identifiants stables
(chemin du port, numéro de série, IDs vendor/product) et du pilote noyau qui s’y est lié.

Blague #1 : les périphériques USB sont comme des stagiaires—certains sont brillants, mais vous ne devriez quand même pas les laisser gérer la paie sans surveillance.

Tâches pratiques (commandes, sorties, décisions)

Voici des tâches réelles que vous pouvez exécuter sur un hôte Linux. Chaque tâche inclut :
une commande, une sortie d’exemple, ce que signifie la sortie et la décision que vous prenez à partir de celle-ci.
Supposez que vous êtes root ou que vous avez sudo quand nécessaire.

Task 1: List all USB devices (coarse inventory)

cr0x@server:~$ lsusb
Bus 002 Device 003: ID 0781:5581 SanDisk Corp. Ultra
Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ce que cela signifie : Les IDs Vendor:Product montrent l’identité du périphérique telle que rapportée par le firmware. Les root hubs sont normaux.

Décision : Tout ce qui n’est pas un root hub doit être justifié. Un SanDisk de stockage sur un serveur ? C’est une conversation de politique.

Task 2: Get verbose details for a suspicious device

cr0x@server:~$ lsusb -d 0781:5581 -v | sed -n '1,80p'
Bus 002 Device 003: ID 0781:5581 SanDisk Corp. Ultra
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5581 Ultra
  iManufacturer           1 SanDisk
  iProduct                2 Ultra
  iSerial                 3 4C530001230101234567
  bNumConfigurations      1

Ce que cela signifie : Vous avez un numéro de série (idéal pour une liste d’autorisation) et l’appareil ne déclare pas une classe unique au niveau du device (c’est courant).

Décision : Capturez le numéro de série et le chemin du port. Si vous autorisez le stockage, autorisez uniquement des numéros de série spécifiques.

Task 3: Watch live USB hotplug events (who touched the box?)

cr0x@server:~$ sudo udevadm monitor --udev --kernel
monitor will print the received events for:
KERNEL - the kernel uevent
UDEV - the udev event

KERNEL[24812.531129] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
UDEV  [24812.612204] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
KERNEL[24812.713001] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0 (usb)
UDEV  [24812.714983] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0 (usb)

Ce que cela signifie : Vous obtenez le chemin du port physique (comme 1-2) et les événements d’interface (1-2:1.0).

Décision : Utilisez le chemin du port pour construire une politique « ce port de rack est autorisé » lorsque les numéros de série ne sont pas fiables.

Task 4: Identify the driver that bound to a USB interface

cr0x@server:~$ readlink -f /sys/bus/usb/devices/1-2:1.0/driver
/sys/bus/usb/drivers/usb-storage

Ce que cela signifie : Le pilote usb-storage est utilisé, donc cet appareil peut présenter un stockage en bloc.

Décision : Si l’hôte ne doit jamais accepter de stockage amovible, prévoyez de bloquer usb-storage globalement ou via usbguard/udev.

Task 5: Map USB storage to a block device node

cr0x@server:~$ lsblk -o NAME,TYPE,TRAN,SIZE,MODEL,SERIAL,MOUNTPOINT
NAME   TYPE TRAN  SIZE MODEL            SERIAL               MOUNTPOINT
sda    disk sata  1.8T INTEL SSDSC2BX   BTTV1234001
└─sda1 part       1.8T                                  /
sdb    disk usb  14.9G Ultra            4C530001230101234567
└─sdb1 part usb  14.9G                                  /media/usb

Ce que cela signifie : TRAN=usb confirme le transport. Vous savez maintenant quel périphérique bloc démonter et effacer, si nécessaire.

Décision : Si ce montage est inattendu, démontez immédiatement, puis bloquez la récidive. Inventoriez ce qui a été copié si vous effectuez une réponse à incident.

Task 6: See recent kernel messages for USB and storage behavior

cr0x@server:~$ sudo journalctl -k -n 80 | egrep -i 'usb|scsi|uas|storage|hid'
Feb 05 10:41:12 server kernel: usb 1-2: new SuperSpeed USB device number 5 using xhci_hcd
Feb 05 10:41:12 server kernel: usb 1-2: New USB device found, idVendor=0781, idProduct=5581
Feb 05 10:41:12 server kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
Feb 05 10:41:12 server kernel: scsi host6: usb-storage 1-2:1.0
Feb 05 10:41:13 server kernel: scsi 6:0:0:0: Direct-Access     SanDisk  Ultra            1.00 PQ: 0 ANSI: 6
Feb 05 10:41:13 server kernel: sd 6:0:0:0: [sdb] 31260672 512-byte logical blocks: (16.0 GB/14.9 GiB)

Ce que cela signifie : Cela confirme la séquence d’énumération et le fait que le stockage a été reconnu comme un disque SCSI.

Décision : Si vous construisez une piste d’audit, archivez ces événements avec des horodatages. Si vous empêchez la récidive, bloquez par classe/pilote.

Task 7: Inspect USB device attributes via udev (for stable matching)

cr0x@server:~$ udevadm info -q property -n /dev/sdb | egrep 'ID_VENDOR_ID|ID_MODEL_ID|ID_SERIAL_SHORT|ID_BUS|ID_USB_DRIVER'
ID_BUS=usb
ID_VENDOR_ID=0781
ID_MODEL_ID=5581
ID_SERIAL_SHORT=4C530001230101234567
ID_USB_DRIVER=usb-storage

Ce que cela signifie : Ces propriétés sont ce que vous pouvez faire correspondre dans des règles udev. Le numéro de série est le plus robuste ici.

Décision : Décidez d’appliquer la politique par numéro de série (préféré), vendor/product (acceptable pour des appareils connus fixes), ou chemin du port (dernier recours).

Task 8: Check for USB network interfaces that shouldn’t exist

cr0x@server:~$ ip -br link | egrep 'enx|usb|wl|ww'
enx00e04c680001    UP             02:11:22:33:44:55

Ce que cela signifie : Les interfaces nommées enx* sont souvent des cartes réseau USB (nommage dérivé de MAC).

Décision : Si l’hôte n’est pas censé gagner de connectivité réseau via USB, bloquez la classe de périphérique ou refusez explicitement ce VID:PID dans la politique.

Task 9: Identify a USB NIC’s origin and USB IDs

cr0x@server:~$ udevadm info -q all -n /sys/class/net/enx00e04c680001 | egrep 'ID_VENDOR_ID|ID_MODEL_ID|DEVPATH|ID_NET_DRIVER' | head
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/enx00e04c680001
E: ID_VENDOR_ID=0bda
E: ID_MODEL_ID=8153
E: ID_NET_DRIVER=r8152

Ce que cela signifie : Il s’agit d’une carte réseau Realtek USB pilotée par r8152, située au chemin de port 1-3.

Décision : Pour les serveurs, par défaut refusez les NICs USB sauf si vous avez un cas d’usage documenté (kiosk/boîtes edge exceptées).

Task 10: Detect USB Human Interface Devices (HID) presence

cr0x@server:~$ grep -H . /sys/bus/usb/devices/*/bInterfaceClass 2>/dev/null | head
/sys/bus/usb/devices/1-2:1.0/bInterfaceClass:08
/sys/bus/usb/devices/1-4:1.0/bInterfaceClass:03

Ce que cela signifie : La classe d’interface 08 est le stockage de masse, 03 est HID. C’est un moyen rapide de repérer les types sans parser lsusb.

Décision : Si un serveur a soudainement un HID, considérez-le comme suspect à moins que ce soit un KVM connu ou un dongle console.

Task 11: Temporarily disable USB mass storage (quick containment)

cr0x@server:~$ sudo modprobe -r usb_storage
cr0x@server:~$ lsmod | grep -E '^usb_storage\b' || echo "usb_storage unloaded"
usb_storage unloaded

Ce que cela signifie : Retirer le module empêche de nouveaux périphériques de stockage USB de se lier. Les périphériques montés existants peuvent rester jusqu’à démontage.

Décision : Utilisez ceci comme frein d’urgence lors d’une intervention. Pour la permanence, utilisez une blacklist modprobe et/ou une politique usbguard.

Task 12: Permanently prevent usb-storage from loading (server baseline)

cr0x@server:~$ printf "blacklist usb_storage\ninstall usb_storage /bin/false\n" | sudo tee /etc/modprobe.d/usb-storage.conf
blacklist usb_storage
install usb_storage /bin/false
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64

Ce que cela signifie : Mettre en blacklist réduit les chargements accidentels ; install ... /bin/false est le « non » ferme. Mettre à jour l’initramfs garantit que le démarrage précoce le respecte.

Décision : Faites cela sur les hôtes où le stockage USB n’est jamais requis. Ne le faites pas aveuglément sur des hôtes dépendant des médias virtuels BMC pour la récupération.

Task 13: Audit automount behavior (the silent accomplice)

cr0x@server:~$ systemctl is-enabled udisks2.service 2>/dev/null || true
enabled
cr0x@server:~$ systemctl status udisks2.service --no-pager | sed -n '1,8p'
● udisks2.service - Disk Manager
     Loaded: loaded (/lib/systemd/system/udisks2.service; enabled; preset: enabled)
     Active: active (running)

Ce que cela signifie : Sur des serveurs, udisks2 est généralement inutile et peut faciliter des workflows d’automount (surtout dans des environnements de type bureau).

Décision : Pour les images serveur, désactivez ce dont vous n’avez pas besoin. Si vous avez besoin d’udisks2 (rare), compensez avec une politique USB plus stricte.

Task 14: Install and enable usbguard (policy engine)

cr0x@server:~$ sudo apt-get update
cr0x@server:~$ sudo apt-get install -y usbguard
cr0x@server:~$ sudo systemctl enable --now usbguard.service
Created symlink /etc/systemd/system/multi-user.target.wants/usbguard.service → /lib/systemd/system/usbguard.service.

Ce que cela signifie : usbguard peut appliquer une politique allow/deny par périphérique, incluant la classe et les détails d’interface.

Décision : Utilisez usbguard quand vous avez besoin d’un contrôle fin (par ex. autoriser un UPS HID mais refuser le stockage). Si vous avez juste besoin de « pas de stockage USB », les contrôles de module noyau peuvent être plus simples.

Task 15: Generate a baseline allowlist policy with usbguard

cr0x@server:~$ sudo usbguard generate-policy
allow id 1d6b:0002 serial "" name "xHCI Host Controller" hash "..."
allow id 046d:c534 serial "" name "Unifying Receiver" with-interface 03:01:02 hash "..."
allow id 0bda:8153 serial "" name "RTL8153 Gigabit Ethernet Adapter" with-interface ff:ff:ff hash "..."

Ce que cela signifie : usbguard voit ce qui est actuellement connecté et émet des règles. Il peut inclure des hubs/controllers ; c’est normal.

Décision : Relisez avant déploiement. Si le baseline a été généré pendant un incident, vous venez d’ériger le périphérique de l’attaquant en « autorisé ». Générez à partir d’un état connu propre.

Task 16: Enforce default-deny and allow only known devices (usbguard config)

cr0x@server:~$ sudo sed -i 's/^ImplicitPolicyTarget=.*/ImplicitPolicyTarget=block/' /etc/usbguard/usbguard-daemon.conf
cr0x@server:~$ sudo install -m 0600 /dev/null /etc/usbguard/rules.conf
cr0x@server:~$ sudo bash -lc 'usbguard generate-policy > /etc/usbguard/rules.conf'
cr0x@server:~$ sudo systemctl restart usbguard.service

Ce que cela signifie : La politique par défaut bloque les périphériques sauf règles explicites. Le fichier rules devient la liste d’autorisation.

Décision : Le défaut-deny est le seul réglage qui s’échelonne. Autorisez ensuite explicitement ce dont vous avez besoin—idéalement par numéro de série, interface et port quand c’est possible.

Task 17: Observe usbguard decisions in real time

cr0x@server:~$ sudo usbguard watch
device-present id 0781:5581 serial "4C530001230101234567" name "Ultra" hash "..." via-port "1-2" with-interface 08:06:50
device-policy id 0781:5581 serial "4C530001230101234567" target block

Ce que cela signifie : Le périphérique est apparu et a été bloqué. L’interface 08:06:50 est le stockage de masse (SCSI transparent, Bulk-Only ou similaire).

Décision : Si le blocage est attendu, vous avez terminé. Si vous avez cassé un workflow légitime, créez une règle d’autorisation étroite, pas une exception large.

Task 18: Create a usbguard allow rule for a specific serial and interface

cr0x@server:~$ sudo bash -lc 'printf "%s\n" \
"allow id 051d:0002 serial \"\" name \"American Power Conversion\" with-interface 03:00:00" \
>> /etc/usbguard/rules.conf'
cr0x@server:~$ sudo systemctl reload usbguard.service || sudo systemctl restart usbguard.service

Ce que cela signifie : Cet exemple autorise une interface HID de type UPS (pas le stockage). Le triple d’interface importe : il évite les surprises « même périphérique expose aussi du stockage ».

Décision : Incluez toujours with-interface sauf si vous autorisez un hub/controller. Rendre la règle précise vaut mieux que de jouer au malin.

Task 19: Block a specific VID:PID via udev (surgical, but limited)

cr0x@server:~$ cat | sudo tee /etc/udev/rules.d/90-usb-block-sandisk.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0781", ATTR{idProduct}=="5581", ATTR{authorized}="0"
cr0x@server:~$ sudo udevadm control --reload-rules
cr0x@server:~$ sudo udevadm trigger --subsystem-match=usb

Ce que cela signifie : Mettre authorized=0 demande au noyau de désautoriser le périphérique. Cela peut bien fonctionner, mais le comportement varie selon les types et le timing.

Décision : Utilisez udev comme outil tactique. Pour une politique de flotte avec audit, préférez usbguard.

Task 20: Confirm a block device is gone and mounts are clean

cr0x@server:~$ mount | grep -E '/media/usb|/run/media' || echo "no removable mounts"
no removable mounts
cr0x@server:~$ lsblk -o NAME,TRAN,SIZE,MOUNTPOINT | egrep 'usb|^sdb' || echo "no usb block devices"
no usb block devices

Ce que cela signifie : Aucun montage restant et aucun disque avec transport USB.

Décision : Ne déclarez la contention terminée qu’après vérification des deux. Bloquer sans démonter, c’est comment on obtient des incidents à moitié résolus.

Stratégies de blocage : brutale, précise et adaptée à la flotte

Stratégie A : Désactiver le stockage de masse USB au niveau du module noyau

C’est le gros marteau. C’est merveilleusement efficace pour « les serveurs n’acceptent jamais les clés USB ».
C’est aussi indiscriminé : cela bloque tout le stockage USB, y compris les workflows de récupération légitimes qui utilisent des médias virtuels.

Quand l’utiliser :

• Serveurs à usage général dans un datacenter contrôlé où la récupération manuelle utilise d’autres mécanismes.
• Environnements soumis à conformité où le stockage amovible est catégoriquement interdit.

Quand ne pas l’utiliser :

• Déploiements distants/edge où la récupération sur site dépend des médias USB.
• Systèmes qui reposent sur du stockage USB comme composant prévu (certains appliances le font).

Stratégie B : usbguard default-deny + allowlist

C’est l’approche adulte : politique explicite, journalisation et chemin gérable vers les exceptions.
usbguard peut autoriser un périphérique HID d’onduleur tout en refusant le stockage et en refusant les interfaces inconnues sur le même appareil.

Si vous opérez une flotte, usbguard vous donne aussi un artefact de politique que vous pouvez relire comme du code.
Ce n’est pas un luxe. C’est comment vous survivez aux audits sans mentir.

Stratégie C : Blocage basé sur udev (rapide et local)

Les règles udev peuvent désautoriser des périphériques ou empêcher certains comportements. Elles sont utiles pour des refus ciblés et pour des systèmes
où vous ne pouvez pas introduire un nouveau démon. Le compromis est la complexité et les cas limites : le timing compte, les attributs varient,
et vous le déboguerez au pire moment.

Stratégie D : Attaquer la surface d’automount

Même si un périphérique de stockage USB est détecté, il n’a pas à se monter. Pour les serveurs non-bureautiques, retirer les agents d’automount
est une bonne hygiène. Cela n’empêchera pas l’injection de frappes ou les NICs USB, mais réduit la classe d’incidents « oups ça s’est monté ».

Stratégie E : Contrôles physiques et firmware (la partie que tout le monde oublie)

Si vous pouvez désactiver les ports USB externes dans le BIOS/UEFI, faites-le sur les systèmes qui n’en ont jamais besoin.
Si vous pouvez verrouiller les ports avec des bloqueurs physiques, faites-le sur les machines en espaces semi-publics.
La politique logicielle est nécessaire ; elle n’est pas toujours suffisante.

Blague #2 : Le seul port USB vraiment sécurisé est celui rempli d’époxy—mais les Facilities trouvent ça bizarre.

Trois mini-récits d’entreprise venus du terrain

1) Incident causé par une mauvaise hypothèse : « C’est juste un clavier »

Une entreprise de taille moyenne exploitait un ensemble de jump hosts Linux utilisés par les ingénieurs pour l’accès en production. Les hôtes étaient verrouillés :
pas de compilateurs, sudo strict, MFA pour SSH. L’équipe se sentait en sécurité, ce qui est généralement le premier symptôme.

Pendant une fenêtre de maintenance, un sous-traitant avait besoin d’un accès console car un jump host avait des problèmes réseau. Quelqu’un a branché
un « clavier de rechange » tiré d’un tiroir. L’hypothèse était simple : les claviers sont des périphériques inertes ; ils ne peuvent pas faire grand-chose à part taper.

Le clavier n’était pas inerte. Il s’est énuméré comme périphérique HID et a injecté une courte séquence de commandes dans la console.
Rien de cinématographique—juste un one-liner curl-to-shell qui a récupéré un script depuis un hôte interne et l’a exécuté.
Le script a ajouté un utilisateur avec des clés SSH et est parti. C’était rapide, discret, et il n’avait pas besoin d’élévation de privilège parce que la session console
était déjà privilégiée pour le dépannage.

Le post-mortem a été douloureux parce que les « contrôles de sécurité » étaient tous centrés sur le réseau. L’USB n’était pas dans le modèle de menace.
L’équipe a fini par implémenter une politique USB default-deny sur ces hôtes : n’autoriser que le VID:PID connu du KVM et bloquer tout le reste.
Ils ont aussi appris à ne plus garder des périphériques mystérieux dans des tiroirs. L’inventaire n’est pas glamour, mais le matériel surprise, c’est comment on se fait compromettre.

La partie la plus embarrassante : il n’y avait pas de signatures de malware à trouver, pas de chaîne d’exploit sophistiquée. Juste l’hypothèse que « HID est sûr ».
Ce ne l’était pas.

2) Optimisation qui s’est retournée contre eux : « Autorisons tous les hubs et docks »

Une autre organisation a standardisé des docks USB-C pour leurs laptops d’astreinte. L’intention était bonne : moins d’adaptateurs, échanges de postes plus simples,
moins de temps perdu à chercher le bon dongle. Ils ont écrit une politique usbguard autorisant largement les vendors de docks et leurs hubs.

La politique semblait propre : autoriser ces vendor IDs, autoriser ces hubs, autoriser cette fonction Ethernet. Elle a même passé un pilote.
Puis la réalité a frappé. Les docks ne sont pas stables et mono-fonction. Les mises à jour firmware ont changé les IDs reportés. Des unités de remplacement venaient d’autres lots.
La politique a commencé à bloquer des docks légitimes et à autoriser des interfaces surprenantes.

Le retour de bâton a été subtil : un dock autorisé exposait une interface de stockage utilisée pour « l’installation de drivers » sous Windows.
Sur Linux, elle apparaissait comme un petit disque en lecture seule. Rien ne se montait automatiquement sur l’image laptop durcie, mais des développeurs l’ont monté « pour voir ».
Le disque contenait des scripts et des binaires. Quelqu’un en a lancé un. Ce n’était pas un malware, juste un outil de dépannage du vendor,
mais il a modifié des paramètres réseau système et a cassé le routage VPN.

L’incident n’était pas une compromission. C’était pire à un autre niveau : cela a coupé la connectivité d’astreinte en plein incident de production.
L’équipe a revu la politique pour autoriser l’Ethernet et l’affichage des docks mais refuser explicitement les interfaces de stockage, même sur des appareils « autorisés ».
La leçon : une optimisation qui élargit la confiance est une optimisation qui finira par vous facturer sa propre commodité.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Inventaire USB baseline en tant que code »

Une société de services financiers exploitait une flotte mixte : serveurs en datacenters, appareils edge dans des agences, et quelques kiosks.
Ils avaient une règle simple et ennuyeuse : chaque classe d’hôte avait une politique USB documentée, versionnée dans la gestion de configuration.
Pas une page wiki. De vrais fichiers de politique.

Sur un appareil edge, un opérateur a signalé « une clé USB ne marche plus ». Cette formulation est toujours suspecte :
soit vous l’avez intentionnellement bloquée (et elle fonctionne comme prévu), soit vous avez involontairement bloqué un périphérique légitime (et vous avez cassé quelque chose).

Ils ont vérifié les logs usbguard et ont vu un nouveau périphérique apparaître : même vendor et product que le modem USB « approuvé », mais un autre serial et une interface supplémentaire.
La politique baseline autorisait la classe d’interface connue du modem et exigeait une correspondance de serial. Le nouveau périphérique a donc été bloqué par défaut.
La plainte de l’opérateur était la cloche d’alarme, pas le problème.

Il s’est avéré que le modem avait été remplacé par un sous-traitant par une unité moins chère qui reportait des IDs semblables mais exposait une interface de stockage.
L’interface de stockage contenait un outil d’autorun pour Windows. L’entreprise ne se préoccupait pas d’autorun Windows ; elle se préoccupait de l’existence d’une interface de stockage inattendue sur un périphérique réseau.
Ils ont rejeté le matériel, mis à jour les exigences fournisseurs et sont passés à autre chose.

Le salut n’a pas été un produit de sécurité magique. Ce fut la pratique ennuyeuse de : inventaire baseline, allowlist explicite et logs qui rendent la décision évidente.
Quand vous pouvez répondre « qu’est-ce qui a changé ? » en quelques minutes, vous dormez mieux.

Erreurs fréquentes (symptômes → cause racine → fix)

Mistake 1: “We blocked USB storage, but drives still show up sometimes.”

Symptômes : Certaines clés USB se montent ; d’autres non. Le comportement varie selon le kernel ou le périphérique.

Cause racine : Vous avez bloqué usb_storage mais le périphérique utilise uas (USB Attached SCSI) ou un autre chemin, ou votre initramfs charge encore des modules en début de boot.

Fix : Vérifiez les modules chargés pour usb_storage et uas ; mettez à jour l’initramfs ; envisagez un blocage basé sur la classe via usbguard pour les interfaces de stockage.

Mistake 2: “We allowlisted by vendor ID, now attackers can spoof us.”

Symptômes : La politique dit « autoriser le vendor X » et vous vous sentez en sécurité. Vous ne devriez pas.

Cause racine : VID:PID n’est pas une authentification. Le firmware peut présenter ces IDs. Aussi, des appareils légitimes peuvent changer d’IDs selon les révisions.

Fix : Préférez le numéro de série + contraintes d’interface. Si le serial manque, liez la politique aux chemins de ports physiques sur du matériel fixe, et appliquez un default-deny.

Mistake 3: “usbguard blocked our UPS and the box powered off during maintenance.”

Symptômes : Les événements d’alimentation ne sont pas remontés ; les hooks d’arrêt ne se déclenchent pas ; le monitoring perd le contact avec l’UPS.

Cause racine : L’UPS était un périphérique HID USB et votre politique default-deny ne l’autorisait pas, ou il était autorisé sans le détail d’interface requis.

Fix : Ajoutez une règle d’autorisation pour l’UPS avec la classe d’interface spécifique. Testez en débranchant/rebranchant pendant une fenêtre de maintenance et confirmez que le monitoring le voit.

Mistake 4: “We blocked everything and now remote recovery is impossible.”

Symptômes : Vous ne pouvez plus utiliser les médias virtuels BMC ; l’ISO de secours ne s’attache pas ; les mains à distance ne peuvent pas booter un média de récupération.

Cause racine : Vous avez refusé globalement le stockage USB, mais votre gestion hors bande présente des médias virtuels comme du stockage USB à l’OS.

Fix : Créez une exception par classe d’hôte : autorisez le stockage USB uniquement pour des dispositifs BMC virtual media (VID:PID/port spécifiques) ou seulement en mode « break-glass » avec contrôle de changement.

Mistake 5: “We wrote a udev rule, but it doesn’t trigger.”

Symptômes : Vous branchez le périphérique et rien ne se passe ; la règle semble ignorée.

Cause racine : Le matching est mauvais (SUBSYSTEM vs SUBSYSTEMS), les attributs n’existent pas à ce nœud device, ou l’ordre des règles entre en conflit.

Fix : Utilisez udevadm info -a -p sur le chemin du périphérique pour trouver les attributs corrects ; vérifiez le nom et l’ordre du fichier de règle ; surveillez avec udevadm monitor.

Mistake 6: “We blocked new devices, but old sessions keep working.”

Symptômes : Vous appliquez une politique mais un périphérique déjà connecté fonctionne toujours.

Cause racine : L’application s’effectue à la connexion ; les montages/pilotes existants restent liés.

Fix : Démontrez les systèmes de fichiers, coupez les interfaces, et débranchez/rebranchez physiquement si nécessaire. Validez avec lsblk et ip link.

Listes de contrôle / plan étape par étape

Checklist A: Build a USB inventory you can defend

1. Exécutez lsusb sur un hôte connu propre et capturez la sortie dans votre repo de config ou un export CMDB.
   Les périphériques dans l’état « normal » ne devraient pas être un mystère.
2. Pour chaque périphérique non-root-hub, enregistrez : VID:PID, numéro de série (si présent), classes d’interface et chemin de port (depuis udevadm monitor ou sysfs).
3. Pour le stockage USB ou les NICs, cartographiez vers les nœuds OS (lsblk, ip link) et documentez s’ils sont autorisés pour cette classe d’hôte.
4. Décidez vos classes d’hôtes : serveurs datacenter, jump hosts, postes développeurs, kiosks, appliances edge. La même politique pour tous est paresseuse et erronée.

Checklist B: Choose your enforcement layer (don’t over-engineer)

1. Si la règle est « pas de stockage USB jamais » : refusez via config modprobe (et mettez à jour l’initramfs). Simple et fort.
2. Si vous avez besoin d’exceptions (UPS, console série, Ethernet dock spécifique) : déployez usbguard et utilisez un allowlist par défaut-deny.
3. Si vous avez besoin d’un blocage tactique aujourd’hui : utilisez des règles d’autorisation udev pour un VID:PID spécifique pendant que vous construisez la politique adéquate.
4. Si l’automount existe : retirez/désactivez-le sur les serveurs. Ne donnez pas de piste libre au stockage USB.

Checklist C: Rollout plan that won’t brick your fleet

1. Commencez en mode observation : déployez usbguard mais logguez les décisions ; ne bloquez pas encore si vous n’êtes pas sûr. Passez ensuite en block quand vous avez la politique.
2. Pilotez sur un petit ensemble d’hôtes par classe, incluant les cas bizarres (ceux avec UPS, dongles série, KVMs).
3. Validez les workflows opérationnels : récupération distante, accès console, monitoring UPS, gestion hors-bande.
4. Ajoutez une procédure break-glass : une dérogation temporaire de politique avec contrôle de changement strict et rollback clair.
5. Faites de la politique USB un artefact revu en CI. Si ce n’est pas relu, elle dérivera jusqu’à échouer.

Checklist D: Incident response when a rogue USB device is found

1. Capturez les logs : événements journalctl -k autour de l’heure d’insertion, plus la sortie usbguard watch si disponible.
2. Identifiez ce qui s’est énuméré : stockage/HID/réseau/série.
3. Contenez : démontez le stockage, désactivez les interfaces, déchargez les modules si nécessaire, et retirez physiquement le périphérique.
4. Évaluez : vérifiez l’historique des shells et les logs sudo pour des commandes injectées si HID est suspecté ; vérifiez les modifications réseau si un NIC USB est apparu.
5. Prévenez la récidive : écrivez des règles deny explicites ; puis rédigez l’allowlist pour les périphériques requis.

FAQ

1) Should I just disable all USB ports in BIOS/UEFI?

Sur les serveurs qui n’ont jamais besoin d’entrée locale et disposent d’une gestion hors-bande fiable, oui. C’est net.
Mais beaucoup d’environnements ont encore besoin d’USB pour les KVMs, le monitoring UPS ou la récupération break-glass. Ne faites pas l’autruche.

2) Is blocking usb_storage enough to stop USB drives?

Souvent, mais pas toujours. Certains périphériques se lient via UAS, et le chargement de modules en début de boot peut contourner une politique appliquée trop tard.
Vérifiez avec lsmod, les logs kernel, et en branchant un périphérique test après reboot.

3) Why not just block mounting and leave devices alone?

Parce que le stockage n’est pas le seul risque. Le HID peut injecter des commandes, et les NICs USB peuvent créer de nouveaux chemins réseau.
« Pas d’automount » est une bonne hygiène ; ce n’est pas une politique de sécurité USB complète.

4) Is usbguard safe to deploy broadly?

Oui, si vous le traitez comme une politique de pare-feu : commencez par l’observation, générez la politique depuis un état propre connu,
et déployez par classe d’hôte. La version dangereuse est d’activer default-deny sur une machine que vous ne comprenez pas totalement.

5) What’s the most reliable identifier to allowlist?

Les numéros de série sont les meilleurs quand ils existent et sont stables. Ensuite vient le chemin du port sur du matériel fixe.
VID:PID est utile mais insuffisant seul.

6) How do I handle USB devices that legitimately change IDs after firmware updates?

Prévoyez-le : traitez les mises à jour de firmware comme tout autre changement pouvant affecter la politique.
Utilisez des contraintes d’interface et, si possible, autorisez par numéro de série plutôt que seulement VID:PID.
Gardez un environnement de staging pour observer les nouveaux IDs avant le déploiement en production.

7) What about “USB condom” data blockers?

Ils peuvent réduire le risque pour des scénarios charge-only, principalement sur appareils mobiles. Sur serveurs, ce n’est pas une stratégie.
Vos contrôles doivent être applicables par politique et auditable, pas dépendre d’un adaptateur correct utilisé sous pression.

8) Can I block only new USB devices but keep existing ones working?

Oui, conceptuellement : default-deny pour les nouveaux périphériques tout en allowlistant les périphériques déjà connus.
Dans la pratique, testez les reboots et la ré-énumération car « existant » devient souvent « nouveau » après un redémarrage.

9) How do I audit USB usage across a fleet?

Collectez lsusb, lsblk (transport USB), et les logs usbguard centralement. Traitez la sortie comme des données d’inventaire.
La clé est la cohérence : mêmes commandes, même parsing, runs planifiés et alertes sur dérive.

Conclusion : prochaines étapes à déployer

L’USB est un problème de fiabilité qui porte un masque de sécurité. La solution n’est pas une commande unique ; c’est une politique que vous pouvez expliquer, implémenter et auditer.
Commencez par apprendre ce qui est réellement connecté, puis décidez ce que chaque classe d’hôte doit permettre, et appliquez-le avec la couche la plus simple qui répond au besoin.

1. Aujourd’hui : Exécutez les tâches d’audit sur un hôte représentatif par classe. Capturez le baseline.
2. Cette semaine : Désactivez les services d’automount sur les serveurs et ajoutez des étapes de confinement d’urgence à votre runbook d’incident.
3. Ce mois : Déployez usbguard là où vous avez besoin d’exceptions ; sinon bloquez le stockage USB au niveau module noyau. Déployez avec pilotes et contrôle de changement.
4. En continu : Traitez la politique USB comme une politique de pare-feu—revue, versionnée et testée après changements hardware/firmware.

L’objectif est un USB ennuyeux. L’ennui est stable, sécurisé et agréablement sans histoire. La production aime l’absence d’histoires.