blacklist module_name 单独使用不保险，因其仅对显式 modprobe 调用生效，无法阻止 udev 自动加载、依赖触发或 initramfs 预加载；真正可靠的是配合 install module_name /bin/false，并确保配置在 /etc/modprobe.d/*.conf 中、执行 update-initramfs -u 或 dracut --force 更新 initramfs。
单纯写 blacklist module_name 几乎总会在生产环境失效——它拦不住 udev 自动加载、拦不住依赖触发、也拦不住模块已被预加载的情况。
为什么 blacklist 单独用不保险
modprobe 的 blacklist 只在 modprobe xxx 命令被显式调用时起作用。但现实中，USB 设备插入后由 udev 规则自动执行 modprobe usb-storage；某个网络模块可能被 nft 间接依赖而触发加载；甚至 initramfs 阶段就已把模块拉进内存。这些场景下，blacklist 完全不生效。
更关键的是：配置文件权限不对、后缀不是 .conf、或模块本身是 built-in（编译进内核而非 .ko 文件），都会让整条黑名单“静默失败”。
install module_name /bin/false 才是真正可靠的禁用方式
这条指令会覆盖所有加载路径——包括 modprobe 直接调用、依赖链触发、udev 自动加载。只要系统尝试加载该模块，就会执行 /bin/false 并立即返回失败。
- 必须和
blacklist成对出现，例如禁用usb-storage：
blacklist usb-storage install usb-storage /bin/false
- 不要对核心总线模块使用此法，比如
usbcore或pci_core，否则整个子系统瘫痪 - 若要禁用一整类模块（如所有 USB 存储驱动），需对
usb-storage、uas、ums-realtek等逐个加这两行 - 配置文件必须放在
/etc/modprobe.d/下，且以.conf结尾（如/etc/modprobe.d/usb-security.conf）
验证是否真生效的三个硬性检查点
改完配置别急着 reboot，先做这三件事，缺一不可：
- 运行
modprobe -n -v usb-storage：输出必须含install /bin/false，而不是insmod /lib/modules/... - 插上对应设备（如 U 盘），立刻执行
dmesg | tail -10：不能出现usb-storage、scsi add-single-device等 probe 日志 - 执行
lsmod | grep usb-storage：无任何输出；如果之前加载过，得先sudo modprobe -r usb-storage再查
注意：update-initramfs -u（Debian/Ubuntu）或 dracut --force（RHEL/CentOS）必须执行，否则新配置进不了 initramfs，重启后照样加载。
容易被忽略的兼容性陷阱
有些模块名字看着像，实际是别名或自动加载的变体。比如禁用蓝牙，只写 blacklist bluetooth 不够，因为 btusb、btrtl、bcm20702 可能绕过它。正确做法是查依赖：modinfo -F depends btusb，再对每个依赖模块补上 install xxx /bin/false。
另一个隐形坑：VPS 环境中，KVM 虚拟机可能通过 virtio-pci 加载存储模块，此时禁用 usb-storage 没意义，但禁用 firewire-core 或 floppy 就很必要——它们完全无用且 CVE 高发。
最后提醒：黑名单不是万能解药。CVE-2024-1086 这类漏洞，光靠禁用模块只能缓解，升级内核或打补丁才是根本。黑名单只是你安全加固链条里最前端、最可控的一环。
