恶意代码检测怎样记录改动前后的基线：先固定可比对的文件与进程快照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /21f7c729630d.html
📄
恶意代码检测怎样记录改动前后的基线：先固定可比对的文件与进程快照
记录改动前后的基线，核心是让“改动前”和“改动后”两份证据能一一对应。做法是在确认环境相对干净时，先采集文件哈希、关键目录清单、进程与网络连接、计划任务和启动项，存到只读介质或独立主机；执行任何排查、清理或更新后，用同一套采集命令再采一次，逐项对比差异。时间和人手有限时，最先要固定的是文件哈希清单和进程快照，因为它们最容易在清理过程中被覆盖或删除，一旦丢失就无法还原改动前的状态。
准备阶段：确定采集范围和存放位置
基线不是越全越好，而是覆盖恶意代码常落脚的位置。建议至少包含：系统关键目录、Web 根目录、临时目录、用户启动目录、计划任务、服务与启动项、当前进程及监听端口。采集前先确定存证位置，不要放在被检测主机上，否则清理时可能一并被改或被删。可以用外接存储、内网文件服务器，或先算好哈希再上传。
采集命令要固定下来，写成一个脚本或一份清单，前后两次使用完全相同的命令和参数。例如在 Linux 上，文件哈希可以用：
find /var/www /tmp /etc/cron* -type f -exec sha256sum {} \; > baseline_files.txt
进程与网络连接可以用：
ps aux > baseline_ps.txt
ss -tulnp > baseline_net.txt
Windows 环境可用 Get-FileHash 递归计算指定目录，用 Get-Process 和 Get-NetTCPConnection 记录进程与连接。命令本身不重要，重要的是前后一致，并且记录采集时间、主机名、采集人。
实施阶段：改动前后用同一口径采集
改动前采集应尽量在业务低峰进行，减少文件被正常写入干扰。采集完成后立即计算整份清单的哈希，例如对 baseline_files.txt 再算一次 SHA-256，作为基线文件的“封条”。这样即使清单本身被篡改，也能发现。
改动后采集分两种时机：一种是在执行清理或修复动作之前，先采一次“改动前最新状态”，用于确认当前实际存在什么；另一种是在清理完成后采一次“改动后状态”，用于验证清理是否彻底。两次都要沿用同一命令、同一路径范围、同一排序方式，否则对比会出现大量无意义差异。
如果时间和人手有限，优先保证文件哈希和进程快照两项完整，其余项可以后补。原因很直接：文件被删除后哈希无法重建，进程重启后原进程信息消失，而计划任务、启动项即使漏采一次，通常还能从系统日志或注册表备份中部分还原。
验证阶段：对比差异并判断改动性质
对比时不要只看“有没有差异”，要看差异落在哪里、属于哪一类。可以按以下检查项逐条过：
- 新增文件：出现在 Web 目录、临时目录或启动目录的可执行文件，需要重点确认来源。
- 文件哈希变化：同一路径内容被改写，可能是正常更新，也可能是被植入。
- 进程变化：新增非常规进程、父进程异常、监听端口增加，需要结合命令行和启动时间判断。
- 计划任务与启动项变化：新增项指向脚本或临时目录，通常比系统自带项更值得追查。
- 网络连接变化：出现外连地址或非常规监听端口，需要结合进程确认。
判断结果要区分“可能原因”和“已经定位的原因”。例如发现某文件哈希变化，可能是正常补丁、配置调整，也可能是恶意改写；只有结合变更记录、文件时间、内容特征和进程行为，才能说已经定位。不要仅凭一项差异就下结论。
验证时还应保留对比输出，例如用 diff baseline_files.txt after_files.txt 生成差异文件，并记录每一条差异的处置结论：确认正常、确认恶意、待观察。这样后续复查有据可依。
维护阶段：让基线可复用而不是一次性
基线不是采一次就结束。系统更新、业务发布、配置调整都会产生合法改动，如果长期不更新基线，下一次对比会充满噪声。建议在每次已知的合法变更后，重新采集并标注版本和日期，保留旧基线至少一个周期，便于回溯。
维护时注意三点：基线文件本身要有访问控制，避免被篡改；采集脚本要纳入版本管理，确保口径不漂移；对比结果要有统一存放位置，方便交接。对于人手有限的场景，可以把采集脚本设为定时任务，但定时采集只能作为补充，关键节点仍需人工确认后再采。
下一步，先写一份只包含文件哈希和进程快照的最小采集脚本，在一台测试机上跑通，确认前后两次输出格式一致，再把它用到需要检测的主机上。
