For a server-ish machine, disabling module autoloading is fairly straightforward: set &#x2F;proc&#x2F;sys&#x2F;kernel&#x2F;modprobe to &#x2F;bin&#x2F;false. (You can also do something fancier like <a href="https:&#x2F;&#x2F;scripts.mit.edu&#x2F;trac&#x2F;browser&#x2F;trunk&#x2F;server&#x2F;fedora&#x2F;config&#x2F;etc&#x2F;scripts&#x2F;modprobe" rel="nofollow">https:&#x2F;&#x2F;scripts.mit.edu&#x2F;trac&#x2F;browser&#x2F;trunk&#x2F;server&#x2F;fedora&#x2F;con...</a> to report what the process is.)<p>This is also useful to disable modprobing obscure networking protocols just by an unprivileged process calling socket(SOCK_STREAM, AF_FULLOFBUGS, 0), which was a fruitful source of exploits at least a few years back.<p>However, for most server machines, if an attacker can plug a malicious USB device into your machine, something has already gone very wrong. (And for a good chunk of servers these days, they don&#x27;t even have USB because they&#x27;re VMs.) The primary threat model for this sort of thing seems to be laptops that are briefly left unattended and locked, or &quot;Hey, can I charge my phone off your laptop.&quot;<p>For the unattended-and-locked case, perhaps you could block module autoloading until the user has logged back in. It&#x27;s roughly similar to the approach Apple takes with Thunderbolt, I believe.