USBGuard无法有效防御BadUSB，因其仅校验设备身份而非行为；BadUSB伪装为HID（class 03）或CDC（class 02）设备，而USBGuard默认放行此类接口，必须结合内核authorized控制、udev硬绑定（vendor/product/serial）及白名单策略构建纵深防护。
USBGuard 本身不能防 BadUSB 类设备——它只管“设备身份”，不管“设备行为”。BadUSB 本质是伪装成键盘、网卡或 HID 设备的恶意固件，接口类是 03（HID）或 02（CDC），根本不在 USBGuard 默认拦截范围内。真要防，得靠组合策略：USBGuard 白名单 + 内核级接口授权控制 + udev 行为拦截。
为什么 USBGuard 的 allow with-interface 规则对 BadUSB 几乎无效
BadUSB 设备在系统眼里就是一台标准 USB 键盘或以太网适配器，它的 bInterfaceClass 是 03 或 02，而 USBGuard 默认策略里几乎从不 block 这两类——否则你连键盘鼠标都用不了。生成策略时 usbguard generate-policy 会把当前插着的键盘、鼠标全放行，后续同类设备（包括 BadUSB）只要接口匹配就自动过检。
- USBGuard 规则匹配的是设备描述符（vendor/product/id、interface class/subclass/protocol），不是运行时行为
- BadUSB 固件可任意伪造 vendor/product，甚至复刻你公司采购的某款键盘的完整 descriptor
-
allow with-interface equals {03:*:*}这种规则等于给所有 HID 设备开绿灯，风险极高
必须配合内核级 authorized 控制，否则 USBGuard 形同虚设
USBGuard 只负责“是否允许设备初始化”，但内核默认一接入就自动 authorized=1，设备驱动立刻加载。真正能掐断 BadUSB 启动链的，是把 /sys/bus/usb/devices/*/authorized 全部设为 0，再由白名单逻辑按需打开。
- 开机即锁：在
/etc/rc.local或 systemd service 中执行：for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done - 只放行可信设备：用 udev rule 检查
idVendor+idProduct+bInterfaceClass，三者全匹配才写echo 1 > /sys$DEVPATH/authorized - 避免只靠 interface class：BadUSB 常用
{03:01:01}（HID Keyboard），但你公司的键盘也是这个值；必须绑定物理设备指纹（如 serial、port number）
如何用 udev + authorized 实现 BadUSB 级别防护
单纯靠 USBGuard 规则无法区分“真键盘”和“BadUSB 键盘”，必须下沉到 udev 层，结合端口路径（DEVPATH）和序列号（SERIAL）做硬绑定。以下是一个生产可用的 udev rule 示例：
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTRS{serial}=="1234567890ABCD", \
SUBSYSTEM=="usb", ACTION=="add", \
PROGRAM="/bin/sh -c 'echo 1 > /sys$DEVPATH/authorized'", \
GOTO="usb_allow_end"
SUBSYSTEM=="usb", ACTION=="add", \
PROGRAM="/bin/sh -c 'echo 0 > /sys$DEVPATH/authorized'"
LABEL="usb_allow_end"
- 这条规则只允许 Logitech 键盘（vendor/product）且序列号为
1234567890ABCD的设备被授权；其他所有 USB 设备（含 BadUSB）一律authorized=0 -
ATTRS{serial}比ATTRS{idVendor}更难伪造，需物理接触设备才能读取 - 不要用
ENV{UDISKS_IGNORE}="1"—— 它只影响挂载，对 HID 类设备完全无效
USBGuard 仍有必要，但角色是“二次校验”而非“第一道门”
把 USBGuard 当作白名单的“审计日志层”更合理：它不阻止设备接入，而是记录每次授权决策，并提供 runtime 管控入口（如临时 block-device）。真实防护链应是：内核 authorized=0 → udev 白名单放行 → USBGuard 记录+动态干预。
- 启动后立即执行：
usbguard set-parameter RuleSetReloadPolicy "always"，确保策略变更实时生效 - 禁用自动策略生成：
usbguard set-parameter GeneratePolicyOnStartup false，防止重启后覆盖人工规则 - 关键点：
usbguard list-devices显示的id字段是运行时 hash，不是 vendor/product，不能用于静态规则；要用usbguard read-descriptor提取原始 descriptor 做比对
真正难防的不是 BadUSB 设备本身，而是管理员把 authorized_default=1 当成便利开关，或者用 with-interface 匹配太宽泛的规则。安全水位线不在工具，而在是否切断了“设备一插就干活”的默认路径。
