入侵时间线取证要回答三个问题：攻击者什么时候进来、动了哪些文件、留下了什么痕迹。文件系统的 MACB 时间、登录记录、Web 访问日志分散在不同位置，靠人工翻查极易错漏，也无法在报告里形成闭环。Plaso（log2timeline）与 mactime 的作用就是把多源时间戳归一化成一条按 UTC 排序的超级时间线，让「webshell 落地」与「首次被访问」之间的先后关系一目了然。下面是一套从镜像到结论的完整流程。
适用场景
- 主机确认被入侵，需要还原入口时间与横向移动路径；
- 监管或客户要求提交带哈希的证据链与可复核的分析过程；
- 日志被清理过，只能靠文件系统时间戳反推操作序列；
- 需要判断某个可疑文件是攻击者投放的，还是运维正常更新。
- 需要向非技术管理层解释事故经过，时间线是最直观的表达方式。
时间线分析不能替代内存取证和日志分析，三者互补：内存看进程与网络连接，日志看请求内容，时间线看「什么时候发生了什么」。取证顺序上应先采集易失数据，再关机做磁盘镜像。
前置条件
- 一台干净的取证分析机，安装 Sleuth Kit 与 Plaso，不要在被入侵主机上跑分析工具；
- 镜像存储空间不小于源盘容量，建议留 1.5 倍余量；
- 全程记录操作时间与命令，用于形成证据链；
- 统一使用 UTC，避免本地时区与日志时区混用导致结论偏移。
原理说明
Linux 的 ext4 为每个文件维护四个时间：mtime（内容修改）、atime（访问）、ctime（inode 元数据变更）、btime（创建，需 statx 支持）。攻击者可以用 touch 伪造 mtime 和 atime，但 ctime 无法通过常规命令修改，这是识别时间戳篡改的主要依据。NTFS 则同时存在 $STANDARD_INFORMATION 与 $FILE_NAME 两套时间，前者可被改写、后者较难，两套时间不一致即为篡改信号。
Plaso 的价值在于「归一化」：它把文件系统、syslog、wtmp、bash_history、Web 日志、浏览器记录等几十种来源解析成统一字段（时间、来源、描述），输出一条可直接排序的 CSV。mactime 则更轻量，只处理 bodyfile，适合快速定位某个目录的变更序列。
操作步骤
第一步：镜像与完整性存证
先记录系统时间与磁盘标识，再制作镜像。哈希值必须在镜像完成后立刻计算并另存，后续每一步都以它为准。
date -u
sudo fdisk -l /dev/sda
sudo mkdir -p /evidence
sudo dd if=/dev/sda of=/evidence/host01.dd bs=4M conv=noerror,sync status=progress
cd /evidence
sha256sum host01.dd | tee host01.dd.sha256
ls -l --time-style=full-iso /evidence第二步：只读挂载
用 --read-only 与 --partscan 挂载，文件系统层再加 ro,noload，确保分析过程不写回镜像、不重放日志。
挂载后先用 ls /mnt/evidence 确认根目录结构完整，分区选错会让后续所有分析结论作废。
sudo losetup --find --show --partscan --read-only /evidence/host01.dd
# 输出类似 /dev/loop0，分区为 /dev/loop0p1
sudo mkdir -p /mnt/evidence
sudo mount -o ro,noload /dev/loop0p1 /mnt/evidence
mount | grep evidence第三步：用 fls 采集 bodyfile
bodyfile 是 mactime 的输入格式，包含路径、inode、权限与四个时间戳。-m / 指定挂载点前缀，保证路径可读。
sudo fls -r -m / /dev/loop0p1 > /evidence/bodyfile.txt
wc -l /evidence/bodyfile.txt
head -3 /evidence/bodyfile.txt
# 没有 Sleuth Kit 时可用 find 兜底，但拿不到已删除文件
sudo find /mnt/evidence -xdev -printf '%p|%i|%M|%u|%g|%s|%A@|%T@|%C@\n' > /evidence/bodyfile_alt.txt第四步：mactime 生成可读时间线
-d 输出 ISO8601 便于排序，-z UTC 强制时区，-y 补全只有月日的记录年份。生成后按时间正序排列，攻击链自然浮现。
mactime -b /evidence/bodyfile.txt -d -z UTC -y 2026 > /evidence/timeline.csv
sort -t, -k1,1 /evidence/timeline.csv > /evidence/timeline_sorted.csv
# 只看 Web 目录在案发窗口内的变更
grep "/var/www/html" /evidence/timeline_sorted.csv | grep "2026-10-0" | head -40第五步：Plaso 全量归一化
Plaso 处理耗时与镜像大小成正比，先用 --workers 并行，再按时间窗过滤输出，避免生成几十 GB 的 CSV。
sudo pip3 install plaso
log2timeline.py --workers 4 --timezone UTC \
--storage-file /evidence/host01.plaso /evidence/host01.dd
psort.py -o l2tcsv -w /evidence/host01.csv /evidence/host01.plaso \
"date > '2026-10-01 00:00:00' AND date < '2026-10-08 00:00:00'"
wc -l /evidence/host01.csv容器环境更省事，注意把证据目录挂载为只读：
docker run --rm -v /evidence:/evidence:ro log2timeline/plaso \
log2timeline.py /evidence/out/host01.plaso /evidence/host01.dd第六步：关键节点关联
单看时间线只是流水账，必须把文件落地时间与访问日志对上。以下面这条链为例：上传目录出现新的 php 文件 → 3 分钟后 access.log 出现对该文件的 POST → 20 分钟后 crontab 被修改。
# 1. 可疑文件落地时间
grep -E "uploads/.*\.php" /evidence/timeline_sorted.csv | head -20
# 2. 该文件的首次访问
sudo grep -n "shell.php" /mnt/evidence/var/log/nginx/access.log | head -5
# 3. 计划任务与启动项是否被动过
stat -c '%n mtime=%y ctime=%z' /mnt/evidence/var/spool/cron/root
stat -c '%n mtime=%y ctime=%z' /mnt/evidence/etc/crontab
# 4. 登录记录与命令历史
sudo utmpdump /mnt/evidence/var/log/wtmp 2>/dev/null | tail -20
sudo tail -50 /mnt/evidence/root/.bash_history把上述结果整理成表格，每行包含时间（UTC）、来源、事件、证据路径，就是报告的骨架。
配置验证
- 用
stat -c '%y %z' 文件抽查两三个文件，时间应与时间线中对应行一致； sha256sum -c /evidence/host01.dd.sha256校验镜像未被改动；- 确认全流程输出均为 UTC：
mactime -z UTC、Plaso--timezone UTC、分析机timedatectl显示 UTC； - 时间线行数与
fls条目数量级相符，若相差悬殊说明过滤条件写错。
常见问题
Q1：攻击者用 timestomp 改过 mtime，时间线还能信吗？
能，但要换证据。优先看 ctime：touch -d 只能改 atime 与 mtime，改 ctime 需要直接操作 inode，普通权限做不到。其次看 atime 与 mtime 的倒挂（atime 早于 mtime 说明被重置），再看 NTFS 下两套时间是否一致。最后用外部证据交叉验证：Web 日志的请求时间、wtmp 的登录时间、包捕获时间，这三者攻击者通常改不动。
Q2：镜像 2TB，log2timeline 跑了两天还没结束怎么办？
先缩小范围再全量。用 --file-filter 只解析关键路径（/var/www、/tmp、/etc、/root），配合 --workers 提升并行度，并确认镜像放在 SSD 上。如果只需要文件系统时间，直接用 fls 加 mactime 即可，几分钟就能出结果，不必上 Plaso。
Q3：分析机内存不够，psort 处理时被 OOM 杀掉？
psort 默认会把事件批量载入内存做排序。加上 --buffer-size 降低单批事件数，或用 -o dynamic 输出到 Elasticsearch 这类外部存储。极端情况下按天切分时间窗，分多次导出后合并，内存占用能降一个数量级。
总结
入侵时间线取证的可信度来自三点：镜像哈希可校验、时间统一为 UTC、每个结论都能指回具体证据行。工具选择上，快速定位用 fls 加 mactime，需要多源关联再上 Plaso。分析时不要把时间线当成结论，它只是把「谁在什么时候动了什么」摆到一起，真正的判断仍要结合访问日志、登录记录与业务上下文。全程只读、全程留痕，报告才站得住。