auditd通过监控init_module和delete_module系统调用审计内核模块加载与卸载，需配置双架构规则并关联执行者信息，辅以modprobe参数或模块目录监控提升溯源能力。
在 Linux 系统中，auditd 可以通过监控内核模块相关的系统调用（如 init_module、delete_module）来审计模块的动态加载与卸载行为。关键在于捕获触发这些操作的系统调用，并关联到具体执行者（用户、进程、路径等）。
配置 auditd 规则监控模块操作
auditd 本身不直接识别“加载模块”这个语义动作，而是依赖对底层系统调用的跟踪。需添加规则监听以下两个核心系统调用：
-
init_module：用于将模块代码载入内核（对应
insmod、modprobe） -
delete_module：用于从内核移除模块（对应
rmmod、modprobe -r）
在 /etc/audit/rules.d/modules.rules 中添加：
-a always,exit -F arch=b32 -S init_module,delete_module -k module_change
注意：同时指定 b64 和 b32 是为了兼容多架构（如 x86_64 上运行 32 位程序）。保存后执行 sudo augenrules --load 或重启 auditd 使规则生效。
确认规则已加载并测试触发
运行 sudo auditctl -l | grep module_change 查看规则是否在运行时列表中。然后手动触发一次模块操作，例如：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
sudo rmmod dummy
再用 sudo ausearch -k module_change -i 查看审计日志。输出中会包含：comm=modprobe（命令名）、exe=/usr/bin/modprobe（可执行路径）、uid、auid、pid（用户身份与进程信息），以及 syscall=init_module 或 delete_module 字段。
增强审计粒度：关联模块文件路径（可选）
默认情况下，init_module 系统调用不直接记录被加载模块的磁盘路径（.ko 文件），因为模块内容通常由用户空间程序（如 modprobe）读取后传入内核。若需追踪具体加载了哪个文件，建议结合以下方式：
- 监控
modprobe进程的参数：用auditctl -a always,exit -F path=/usr/bin/modprobe -F perm=x -k modprobe_exec - 或启用
auditctl -w /lib/modules/ -p wa -k kernel_modules监控模块目录的写入与访问（适用于预编译模块更新场景） - 更可靠的方式是配合
syslog或journald：modprobe 默认会记录加载行为到系统日志（journalctl -t modprobe），可与 audit 日志交叉验证
分析与告警建议
审计日志中重点关注非预期用户（如普通用户 UID ≠ 0）、非标准路径（如 /tmp/*.ko）、或敏感模块（如 nf_nat_ftp、iptable_nat、或 rootkit 常用模块名）。可编写简单脚本定期扫描：
生产环境建议将含 module_change 的日志转发至 SIEM 系统，并对 root 权限外的模块操作设置告警。
