谁在内核里动手脚
加载与卸载内核模块属于最敏感的系统行为：合法场景只有驱动加载、文件系统与网络功能模块这类明确操作，其余时间出现模块动作通常意味着有人在内核层部署了东西，比如内核态后门与 rootkit。审计要覆盖三条路径：init_module 与较新的 finit_module（现代内核加载模块走这条），delete_module（卸载），以及 kexec_load（用新内核直接替换运行中的内核）。
基本信息
| 加固项 | 内核模块行为审计 |
|---|---|
| 适用平台 | Linux（auditd、内核审计子系统） |
| 权限要求 | root |
| 达标判据 | 模块加载卸载活动有记录且可查询 |
| 覆盖系统调用 | init_module、finit_module、delete_module、kexec_load |
典型使用场景
- 安全事件排查中寻找内核态持久化痕迹
- 等保“安全审计”条款要求对重要行为记录
- 服务器加固后建立模块加载正常基线
- 排查性能异常：确认没有异常模块抢占资源
- 配合文件完整性检查，交叉验证内核未被改动
审计规则与查询
审计规则与查询
# 规则（写入 /etc/audit/rules.d/ 后 augenrules --load）
# -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules
# -a always,exit -F arch=b64 -S kexec_load -k modules
ausearch -k modules --start today | head -30 # 今天的模块相关事件
aureport -m modules --summary 2>/dev/null # 汇总视图
aureport -k modules 2>/dev/null | grep -E 'finit_module|init_module|delete_module' | head交叉验证
交叉验证
lsmod | head -20 # 当前已加载模块，与审计记录对照
modinfo <模块名> | head -10 # 模块来源与签名信息
ausearch -k modules -i | grep -i 'comm=' | sort | uniq -c | sort -rn | head # 谁在加载模块
modprobe --show-depends <模块名> # 确认是否是正常依赖加载记录项与含义
| 系统调用 | 含义 | 风险判断 |
|---|---|---|
| init_module | 加载模块（传统路径） | 非变更窗口出现需核查来源 |
| finit_module | 加载模块（现代内核常用路径） | 容易被只盯 init_module 的人漏掉 |
| delete_module | 卸载模块 | 卸载安全模块或过滤驱动是异常信号 |
| kexec_load | 加载替换内核 | 正常运维极少使用，出现即高危 |
| proctitle 与 comm | 执行者进程信息 | 用于定位是哪个工具或脚本触发的 |
加载内核模块等于获得内核级权限：出现非变更窗口的模块记录应当立即排查，重点看是谁触发的、模块文件从哪里来、是否带签名，以及同期有没有文件被替换。若确认是恶意模块，处置顺序是隔离主机、保留内存与磁盘证据、再做重建评估。
内核自身在启动与运行中也会正常加载模块（如网络、存储相关），因此必须先建立基线：记录正常启动阶段的模块加载清单，之后比对新增项。没有基线的告警只会带来大量误报，最终让人忽略这条规则的价值。