冲突时的固定排查顺序
文件系统时间与日志时间对不上，是时间线分析中的常见情形。多数情况下它不是造假，而是换算错误、语义误读或延迟写入造成的。遇到冲突按固定顺序排查：先校验两侧的时区与时钟偏移是否已修正，再确认时间戳语义（写入、元数据变更还是审计记录），然后找同刻的其他来源交叉验证，最后如果仍然冲突，就在报告里如实标注两种读数与各自依据。
四步排查顺序
- 第 1 步：确认两侧时区与时钟偏移是否已修正，别把换算问题当成造假
- 第 2 步：确认时间戳语义——是内容写入、元数据变更还是审计记录
- 第 3 步：找同一时刻的其他来源交叉验证（认证日志、审计日志、流量）
- 第 4 步：仍冲突则在报告中如实标注两种读数与依据，不下单边结论
交叉抽样
交叉抽样
# 在日志侧定位同一时刻的原始行
grep -n '2026-01-02 03:22:10' /var/log/auth.log
# 在文件系统侧读取同一事件的元数据（镜像上按分区偏移读取）
istat -o 2048 -z UTC /evidence/disk.dd 12845 | grep -iE 'modified|accessed|changed|created'
# 换一个来源再核：审计或会话记录
grep -n '03:22:10' /var/log/audit/audit.log 2>/dev/null | head
# 记录两条读数与各自依据，作为报告的冲突说明常见冲突成因与判读
| 成因 | 表现 | 处理方式 |
|---|---|---|
| 时区未换算 | 差值恰好是整数小时 | 先确认两侧时区元数据，再统一换算 |
| 时钟偏移 | 差值为几十秒到几分钟且随时间变化 | 测量偏移量后分段修正，保留修正记录 |
| 时间戳语义误读 | 把访问时间当作写入时间解释 | 回到四类时间语义重新对照 |
| 延迟写入与缓存 | 日志时间早于文件时间，差值为秒级 | 属于正常现象，用其他来源确认顺序 |
| 虚拟化与快照 | 同一时段出现重复或倒退的时间 | 查询宿主与快照操作记录后再判定 |
冲突不等于造假。虚拟化、快照恢复、文件系统的延迟写入与挂载参数都可能造成看似矛盾的组合，先排除这些常见成因再考虑篡改。
处理冲突时始终保留两种读数与各自依据。把其中一侧直接改写成另一侧，虽然让报告看起来自洽，却抹掉了冲突本身这条线索。