Block USB Mass Storage on Linux Endpoints

What the USB storage blocker does

This Automox Worklet™ blocks USB mass storage on Linux endpoints by disabling the usb-storage kernel module. The Worklet writes a modprobe configuration file at /etc/modprobe.d/usb-storage.conf that instructs the kernel to ignore the module on load, then unloads the module from the running kernel with modprobe -r usb-storage. After remediation, a USB flash drive plugged into the endpoint will not enumerate as a block device and the kernel will not mount it.

The configuration file uses the install usb-storage /bin/true directive, which tells modprobe to substitute a no-op when something requests the module. This is more durable than a simple blacklist line because it also blocks indirect loads triggered by udev rules, kmod auto-loading, or another module declaring usb-storage as a soft dependency. The Worklet leaves the uas (USB Attached SCSI) module alone by default; pair this Worklet with a uas-disabling policy when the threat model requires it.

The evaluation phase inspects both the live kernel state (lsmod | grep usb-storage) and the contents of /etc/modprobe.d/. Endpoints already hardened exit 0 without writing to the kernel or the configuration directory. Endpoints that drift back to the unblocked state after a kernel package update, a dracut rebuild, or an admin removing the conf file get the configuration written back and the module unloaded on the next remediation pass.

Why block USB mass storage on Linux endpoints

USB storage is one of the oldest and quietest data exfiltration paths on a managed endpoint. A laptop or shared workstation with usb-storage enabled lets anyone with physical access copy gigabytes of files to a thumb drive in under a minute, with no agent telemetry and no DLP signal. The same channel is the vector for BadUSB attacks, where a malicious device announces itself as a recognized storage class to deliver an autorun payload or a HID injection script.

USB mass storage on a Linux endpoint is a CIS Level 2 finding on RHEL, Debian, and Ubuntu, and a single re-enabled module is enough to become the answer to a forensic question after an incident. Apply this Worklet through the Linux hardening policy that covers your servers, workstations, and developer laptops so the install usb-storage /bin/true line lands in /etc/modprobe.d/ and the module is unloaded from the running kernel on first pass. A recurring evaluation reasserts the control after kernel upgrades, image refreshes, or a debug session that loaded the module by hand. The check maps directly to CIS Linux Benchmark 1.1.10 and NIST 800-53 MP-7.

How USB storage blocking works

1. Evaluation phase: The Worklet checks two states. First, it runs lsmod | grep -q usb_storage to see whether the module is currently loaded. Second, it grep -Rs the /etc/modprobe.d/ directory for a line matching install usb-storage /bin/true or blacklist usb-storage. If the module is loaded or the blacklist entry is missing, the endpoint is flagged for remediation.

2. Remediation phase: The remediation script writes /etc/modprobe.d/usb-storage.conf containing install usb-storage /bin/true, then runs modprobe -r usb-storage to unload the module from the live kernel. If unload fails because the module is in use by a mounted device, the script reports the offending device path in stderr and exits non-zero so the admin can unmount and rerun.

USB storage blocking requirements

• Linux endpoint running a modern kernel (3.x or later) with modprobe and the standard /etc/modprobe.d/ load path

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• No currently-mounted USB storage at remediation time; the script refuses to forcibly detach a mounted device to avoid filesystem corruption

• Awareness from operations that local USB backup drives, encrypted USB authentication tokens (some YubiKeys present a storage interface), and external USB optical drives will also stop working after remediation

• An accompanying Worklet to disable the uas (USB Attached SCSI) module if the threat model requires blocking USB 3.x storage paths as well

Expected USB storage state after remediation

After successful remediation, the file /etc/modprobe.d/usb-storage.conf exists with the install usb-storage /bin/true directive, and lsmod | grep usb_storage returns no rows. Plugging a USB flash drive into the endpoint produces a kernel log entry recording the new device, but no /dev/sd* node appears and no mount fires. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again.

Validate by plugging a known USB flash drive into a remediated endpoint and running journalctl -k --since '5 minutes ago' to confirm the kernel sees the device but never loads usb-storage. For audit evidence, capture the contents of /etc/modprobe.d/usb-storage.conf, the output of lsmod, and the corresponding journalctl excerpt; keep them with the policy run identifier in your SIEM. The block survives reboots because the modprobe configuration is read at every module-load event; the only way to undo it is to remove the conf file, which the Worklet detects and restores on the next evaluation.