Linux怎么配置USBGuard防止外部恶意物理BadUSB设备接入-LINUX-PHP中文网

USBGuard无法有效防御BadUSB，因其仅校验设备身份而非行为；BadUSB伪装为HID（class 03）或CDC（class 02）设备，而USBGuard默认放行此类接口，必须结合内核authorized控制、udev硬绑定（vendor/product/serial）及白名单策略构建纵深防护。

linux怎么配置usbguard防止外部恶意物理badusb设备接入

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 示例：

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

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 匹配太宽泛的规则。安全水位线不在工具，而在是否切断了“设备一插就干活”的默认路径。