rootkit 处置的判据
rootkit 的处置核心是判据而不是工具：落到内核层的污染（恶意模块、系统调用 hook、netfilter 规则劫持）无法在现场可靠清除，也无法证明已清除干净。这类情况的重装优先级高于清理。
什么情况可以现场清
纯应用层的常规木马、单一 webshell、持久化点数量有限且路径清晰的场景，可以按标准顺序清理。判断依据来自实际检查记录，而不是「感觉没那么严重」。
基本信息
| 内核态迹象 | lsmod 陌生模块、内核 taint 非 0、dmesg 异常 |
|---|---|
| 隐藏手法 | 劫持系统调用、隐藏进程与文件、篡改工具输出 |
| 应用级 | 普通木马与 webshell，可按清除流程处理 |
| 标准顺序 | 保全数据与证据→重装→加固→恢复业务 |
| 验证手段 | 干净介质上的离线扫描与镜像分析 |
| 适用平台 | Linux 为主，Windows 内核驱动同理 |
典型使用场景
- 发现可疑内核模块后判断能否现场清理
- 排查 lsmod 与 dmesg 中的异常条目
- 评估是否触发重装流程并给出书面依据
- 清理后验证系统是否仍有异常行为
- 复盘时说明清理范围与残留风险
检查内核态迹象
检查内核态迹象
lsmod | head -n 30 # 不认识的模块逐个核对
cat /proc/sys/kernel/tainted # 非 0 表示内核已加载非自由/异常代码
dmesg | grep -iE 'taint|module|rootkit' | tail -n 20
cat /proc/modules | wc -l
ls -la /lib/modules/$(uname -r)/ | head
strings /lib/modules/$(uname -r)/modules.dep | head -n 20输出逐列读法
| 输出项 | 含义 | 正常/异常 |
|---|---|---|
| tainted 值 | 内核污染标志位 | 非 0 时需能对应到明确的商业或调试模块 |
| lsmod 列表 | 已加载模块 | 出现与业务无关的网络或隐藏类模块需重点核查 |
| dmesg 尾部 | 内核日志 | 出现模块加载失败与异常提示需结合加载时间 |
| 模块文件时间 | 驱动文件修改时间 | 与入侵时间窗重合的模块文件是高价值线索 |
现场清理的结论要写清范围，例如「已清除可见的若干持久化点」：没有人能保证未发现的内核后门已经消失，报告口径要如实。
再判断是否已被绕过
再判断是否已被绕过
ps -ef | wc -l # 与 /proc 目录数量对比
ls /proc | grep -c '^[0-9]' # 与 ps 输出数量不一致即为隐藏迹象
cat /proc/net/tcp | wc -l # 与 ss 输出对比
which ls cat ps netstat; ls -l /usr/bin/ls决定重装后的必做项
- 重置全部相关凭据与密钥，撤销旧授权公钥
- 从可信介质重装并只恢复确认干净的数据
- 重新配置最小暴露面的网络策略
- 把遗留风险与后续观察期写入事件报告