配置 Auditd 监控存储设备加载与移除事件-linux运维-PHP中文网

要监控存储设备的加载与移除事件，本质是捕获内核对块设备的挂载（mount）和卸载（umount2）动作，以及底层设备探测（如scsi、usb子系统触发的模块加载），需配置auditd规则监控mount、umount2、init_module和delete_module系统调用，并通过ausearch按关键字检索日志以识别异常行为。

配置 auditd 监控存储设备加载与移除事件

要监控存储设备的加载与移除事件，本质是捕获内核对块设备的挂载（mount）和卸载（umount2）动作，以及底层设备探测（如 SCSI、USB 子系统触发的模块加载）。auditd 不直接监听“U 盘插拔”这类物理事件，而是通过审计相关系统调用和内核模块行为，实现对存储设备接入与使用的可追溯记录。

重点监控 mount 和 umount2 系统调用
所有合法或恶意的挂载操作最终都经由这两个系统调用完成。这是最稳定、最难绕过的切入点：

-a always,exit -F arch=b64 -S mount -F success=1 -k storage_mount
-a always,exit -F arch=b64 -S umount2 -F success=1 -k storage_umount
✅ 仅记录成功执行的操作，避免失败尝试干扰日志；
✅ 使用 -k 统一打标，便于后续按 storage_mount 或 storage_umount 检索；
✅ 若为 32 位系统，将 b64 替换为 b32。

补充监控 USB/SCSI 设备相关的内核模块加载
U 盘、移动硬盘等外部存储往往依赖 usb-storage、uas、sd_mod 等模块。Rootkit 可能通过动态加载恶意模块接管设备，因此需同步审计模块行为：

-a always,exit -F arch=b64 -S init_module -k usb_storage_load
-a always,exit -F arch=b64 -S delete_module -k usb_storage_unload
⚠️ 这些规则能捕获非常规路径加载（如从 /tmp/evil.ko 加载），配合 exe 和 cwd 字段可识别可疑来源。

持久化配置并验证生效
把上述规则写入 /etc/audit/rules.d/storage.rules：

echo '-a always,exit -F arch=b64 -S mount -F success=1 -k storage_mount' | sudo tee /etc/audit/rules.d/storage.rules  
echo '-a always,exit -F arch=b64 -S umount2 -F success=1 -k storage_umount' | sudo tee -a /etc/audit/rules.d/storage.rules  
echo '-a always,exit -F arch=b64 -S init_module -k usb_storage_load' | sudo tee -a /etc/audit/rules.d/storage.rules  
echo '-a always,exit -F arch=b64 -S delete_module -k usb_storage_unload' | sudo tee -a /etc/audit/rules.d/storage.rules  
sudo augenrules --load

执行后运行 sudo auditctl -l | grep -E "(storage|usb_storage)"，应看到全部四条规则已加载。

快速定位真实存储接入行为
日志存于 /var/log/audit/audit.log，使用 ausearch 提取关键线索：

查今日所有挂载：sudo ausearch -m mount -ts today -i -k storage_mount
查挂载点含 /media/ 或 /mnt/ 的记录：sudo ausearch -m mount -i | grep -E "(media|mnt)/"
查设备路径是否为外部特征：sudo ausearch -m mount -i | grep -E "dev/(sd|nvme|sr)[a-z][0-9]*"
关联用户与进程：sudo ausearch -m mount -ts recent -i | awk '/uid=|comm=/ {print}'

结合上下文判断是否异常
单条挂载日志价值有限，需交叉验证：

挂载者 auid 是否为运维账号？若为 4294967295（未设置审计 ID），或 uid=0 但无对应工单，即属高风险；
comm= 是否为 udisksd、gnome-shell 等桌面服务？还是 sh、python3、空值？后者高度可疑；
exe= 路径是否指向 /usr/bin/udisks2 或 /bin/mount？若为 /tmp/.X11-unix/evil，基本可判定为恶意接入；
是否存在紧邻的 init_module 日志且 cwd="/dev/shm"？说明可能正在注入驱动级后门。

不复杂但容易忽略