需手动添加 auditd 规则监控 init_module 和 delete_module 系统调用，并确保内核启用 CONFIG_MODULES=y、CONFIG_AUDIT=y；永久规则写入 /etc/audit/rules.d/，用 augenrules --load 加载，可用 ausearch -m MODULE_LOAD -i 查看日志。
要在 Linux 中使用 auditd 记录系统模块加载（如 insmod、modprobe、rmmod）的审计事件，核心是监控内核模块相关的系统调用和关键路径。默认 audit 规则不包含模块操作，需手动添加规则并确保内核支持。
确认 auditd 正在运行且内核支持模块审计
模块加载本质是内核行为，依赖 CONFIG_MODULE_UNLOAD 和 CONFIG_AUDIT 等内核配置。多数发行版默认启用，但建议验证：
- 检查 auditd 服务状态：
sudo systemctl status auditd，未运行则启动：sudo systemctl start auditd && sudo systemctl enable auditd - 确认内核支持模块审计：
zcat /proc/config.gz | grep -i "CONFIG_MODULE\|CONFIG_AUDIT"（若无/proc/config.gz，可查/boot/config-$(uname -r)），确保CONFIG_MODULES=y、CONFIG_AUDIT=y、CONFIG_AUDIT_SYSCALLS=y - 检查是否已加载
audit模块：lsmod | grep audit；若无，尝试sudo modprobe audit（部分内核已内置）
添加监控模块加载/卸载的 audit 规则
模块操作主要通过以下系统调用实现：init_module（加载）、delete_module（卸载）。需为这两个系统调用添加 audit 规则：
- 临时添加（重启后失效）：
sudo auditctl -a always,exit -F arch=b64 -S init_module,delete_module -k module_change
（若为 32 位系统，将b64改为b32） - 永久生效：将上述规则写入
/etc/audit/rules.d/module.rules文件（例如）：-a always,exit -F arch=b64 -S init_module,delete_module -k module_change
然后重载规则：sudo augenrules --load或sudo service auditd restart - 可选增强：监控
modprobe和insmod等用户态工具的执行：-w /sbin/modprobe -p x -k module_tool-w /sbin/insmod -p x -k module_tool-w /sbin/rmmod -p x -k module_tool
验证规则是否生效并查看日志
添加规则后，触发一次模块操作（如 sudo modprobe dummy，再 sudo rmmod dummy），然后检查审计日志：
- 实时查看匹配事件：
sudo ausearch -k module_change | aureport -f -i - 查看原始审计记录：
sudo ausearch -m MODULE_LOAD -i（MODULE_LOAD是内核生成的专用事件类型，比过滤系统调用更精准） - 完整日志位置：
/var/log/audit/audit.log，可用grep "module" /var/log/audit/audit.log快速筛选 - 典型日志字段含义：
comm="modprobe"表示调用进程，name="/lib/modules/.../dummy.ko"是模块路径，success=yes表示成功，pid和auid可追溯操作者
注意事项与常见问题
模块审计虽有效，但有几点需留意：
-
内核模块签名限制：若启用了
CONFIG_MODULE_SIG且强制校验，未签名模块无法加载，audit 仍会记录失败事件（success=no） -
容器环境限制：在容器中加载模块通常被禁止（需
CAP_SYS_MODULE+ 特定 seccomp 配置），audit 规则在宿主机上仍可捕获，但容器内调用可能直接被拒绝 -
避免重复规则：不要同时用
-S init_module和-m MODULE_LOAD监控同一行为，后者更语义化且由内核直接生成 - 性能影响极小：模块加载本身频率低，audit 开销可忽略；无需担心持续性能损耗
