You spend all morning hardening a hardened host, removing unnecessary packages and locking down ports, only to realize the kernel is still happily auto-loading modules every time you plug in a USB device or touch a random network socket. It is the classic ghost in the machine. You think you have a clean attack surface, but a sneaky alias in modules.alias is pulling in drivers you never authorized.

How the kernel tricks you into loading drivers

The kernel uses a mechanism called request_module, which calls out to userspace whenever a hardware device is detected or a protocol family is needed. Udev sees the event and triggers modprobe. Most admins ignore this because it usually just works. But if you are shipping specialized nodes where you want to minimize the risk of malicious or buggy drivers triggering, relying on default behavior is a mistake.

echo 'install usb-storage /bin/false' > /etc/modprobe.d/no-usb-storage.conf

• The install directive overrides the default modprobe behavior by running a fake command instead of loading the module
• Files in /etc/modprobe.d/ are processed alphabetically so name them with care
• Blacklisting just prevents modprobe from loading a module but install directives are much harder to bypass

When you use the install directive, you are effectively telling the kernel that the module is installed but does nothing. This bit me in prod once when I assumed a module wasn’t loaded because it didn’t show up in lsmod, but it had actually been requested by a hidden dependency. Always verify what the kernel thinks is happening by checking the state of the modprobe configuration.

Next time you are auditing your kernel footprint, run lsmod and pipe it to something that tracks what you actually need. If you find modules that you did not explicitly load, track them back to their source in /lib/modules/$(uname -r)/modules.alias. Once you see the pattern, it becomes pretty obvious what needs to be pruned.