必须捕获init_module和finit_module系统调用而非insmod/modprobe命令，通过双架构auditd规则监控、结合comm/exe/cwd/auid等字段识别可疑行为，并关联openat/sig=0/modules_disabled等事件构建攻击链，再配合强制签名与modules_disabled禁用实现纵深防御。
要真正监控内核模块加载行为，不能只盯着 insmod 或 modprobe 命令，必须捕获底层系统调用——init_module 和 finit_module。auditd 从内核入口处记录这些调用，绕过用户态工具（如 lsmod）可能被 Rootkit 篡改的风险，提供源头可信的审计证据。
配置双架构系统调用监控规则
攻击者常利用不同架构接口绕过检测，因此规则需覆盖 x86_64 和 i386：
- 编辑
/etc/audit/rules.d/module-load.rules，写入以下两行： -a always,exit -F arch=b64 -S init_module,finit_module -k lkm_load-a always,exit -F arch=b32 -S init_module,finit_module -k lkm_load- 执行
sudo augenrules --load加载规则（自动合并并重启 auditd） - 验证：运行
sudo auditctl -l | grep lkm_load，应看到两条规则生效
识别可疑加载行为的关键字段
日志位于 /var/log/audit/audit.log，重点关注组合特征而非单一项：
-
comm 值异常：如
sh、python3、perl或空值，而非modprobe、insmod -
exe 路径非常规：指向
/tmp/、/dev/shm/、/var/tmp/或非标准 bin 目录 -
cwd 为临时目录：例如
cwd="/tmp"，说明模块很可能在内存中构造或规避文件扫描 -
auid 为
4294967295（未登录上下文），或uid=0但无对应运维操作记录
结合上下文构建行为链
单次模块加载不等于恶意，需关联前后事件确认意图：
- 查来源：运行
ausearch -m SYSCALL -sc openat -f '.*\.ko$' --start recent，确认 .ko 文件是否来自可疑路径 - 查签名：执行
ausearch -m SYSCALL -sc init_module | grep "sig=0"，识别未签名模块 - 查防御干扰：检查是否紧随加载后修改
/proc/sys/kernel/modules_disabled或/proc/sys/kernel/kptr_restrict - 查权限异常：匹配
auid!=uid且uid=0的事件，提示提权后隐蔽加载
配套加固增强实效性
auditd 提供可观测性，但阻断需系统级策略协同：
- 启用强制模块签名：确保内核编译时开启
CONFIG_MODULE_SIG_FORCE=y，并部署可信密钥 - 运行时禁用加载（临时）：
echo 1 > /proc/sys/kernel/modules_disabled - 永久禁用（需重启）：在
/etc/sysctl.conf中添加kernel.modules_disabled = 1 - 限制模块路径：在
/etc/modprobe.d/中对高危模块设置install <name> /bin/false
