日志分析与溯源：把攻击时间线还原出来

很多应急做到”清完病毒、恢复业务”就停了，但真正值钱的是溯源：攻击者什么时候进来的、从哪进的、动了什么、数据有没有被拖走、现在还有没有残留。这些问题，答案几乎全在日志里。

日志分析就是把散落在各处的记录（系统、Web、安全设备、网络）拼成一条攻击时间线。这篇讲清怎么做。

本文分析方法仅用于你自有或已授权系统的安全溯源。日志属敏感数据，分析时注意合规与权限。

第一步：先收集所有相关日志

别只盯一台机器。一次入侵往往跨多源，至少收集：

系统日志：Linux 的 /var/log/{auth,syslog,messages}、Windows 安全/系统日志。
Web 日志：Nginx/Apache/IIS 的 access 与 error 日志。
应用日志：数据库慢查询、业务审计日志。
安全设备日志：防火墙、WAF、IDS/IPS、堡垒机、VPN 的告警与会话。
网络流量：关键时段的抓包（pcap）、NetFlow。

收集时带时间戳和来源标注，统一时区（建议 UTC 或北京时间明确标注），避免时间线错乱。

第二步：以”时间锚点”建立主线

找几个确定的时间点作为锚：

首次出现爆破失败的时间（大量 4625 / Failed password）。
Webshell 文件创建时间（stat 结果）。
首次外联 C2 的连接时间（ss/netstat 记录或防火墙告警）。
业务最早发现异常的时间。

以这些锚点为中心，向前追”怎么进来的”、向后追”进来后干了什么”。

第三步：Linux 与 Windows 日志关键字段

# Linux：认证日志里的爆破与成功登录
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn
grep "Accepted password" /var/log/auth.log
# 看某个时间段的全部认证事件
sed -n '/Jul 10 03:1[0-9]/p' /var/log/auth.log

Windows 侧重点（事件查看器或 wevtutil 导出）：

4625 登录失败（爆破）、4624 登录成功（看登录类型 3=网络、10=远程桌面）。
4720 新建账户、4732 加入管理员组。
4688 进程创建（若开启命令行审计，能看到执行的命令）。
1102 安全日志被清空（攻击者销毁证据的典型动作！）。

一旦发现 1102（日志被清），说明攻击者有意毁证，更要依赖外发的日志副本（SIEM/独立日志服务器）来还原。

第四步：Web 日志的时间线还原

把可疑 IP 的请求按时间排序，能还原完整攻击链：

# 某 IP 的全部请求，按时间
grep "192.0.2.10" access.log | sort -t'[' -k2
# 看攻击前后的状态码变化（探测 404 → 利用 200 → 传马）
awk '$9!=404' access.log | grep "192.0.2.10"

典型链条：404 扫描 → 200 利用成功 → POST 上传 → 200 访问 shell → 外联。把这条链画出来，就是事件的”故事线”。

第五步：跨源关联（SIEM 思路）

单看一份日志看不全。关联分析才能串起全貌，例如：

防火墙告警”来自 IP X 的暴力破解” + WAF”X 触发 SQLi 规则” + Web 日志”X 访问了 shell.php” → 锁定 X 是攻击者，且入口是 SQLi。
VPN 日志”账号 A 在 03:00 异地登录” + 主机日志”A 随后执行了 whoami” → 账号 A 被盗用并横向。

这正是 SIEM（安全信息和事件管理）的价值：把多源日志归一化、关联规则，自动把碎片拼成事件。应急人员即便没有 SIEM，也可以用 Excel/时间线工具手动关联。

第六步：时间线工具

log2timeline / Plaso：自动从多源（文件系统、注册表、日志）提取时间线，再用 Timesketch 可视化协作分析。
Elastic Stack / Splunk：把日志集中，用查询与仪表盘做关联。
手动法：把各源关键事件按时间贴进一个表格，人工排序列出”时间—来源—事件—影响”。

常见误区

只看一台机器日志：攻击者早横向到其他主机，单源还原不出全貌。
忽略日志被清（1102）信号：没及时转向外部副本，导致溯源断片。
时区不统一：各设备时间不一致，时间线错乱，因果关系判断错。
只收集不关联：日志堆了一堆，却没串成链条，等于没分析。

进阶：用时间线还原”数据是否泄露”

溯源的终极问题常是”数据有没有被拖走”。可这样判断：

看数据库是否有异常大量 SELECT、非业务时段导出、备份被拷走。
看 Web 日志里是否有批量遍历接口（如 id=1,2,3... 拖数据）。
看出口流量是否有大体积外传（NetFlow/pcap）。
结合业务库记录的最后修改/导出时间，圈定”可能泄露的数据范围”，作为通报与合规上报依据。

自测题

为什么应急溯源要收集”多源”日志，而不只看一台机器？
Windows 事件 1102 代表什么？它给溯源什么警示？
“时间锚点”在还原攻击链中起什么作用？
怎么判断”数据是否被拖走”这一终极问题？

实战要点与深度解析

日志分析里最容易被忽视的，是日志本身的完整性与可信度。如果攻击者已经拿到 root/管理员，他完全可以 rm 掉日志、用 auditd 的 -e 0 暂停审计、或清空 Windows 安全日志（事件 1102）。所以”日志说没异常”不等于”真的没异常”——你要先确认日志在关键时间段是否连续、有没有被截断的痕迹。这就是为什么前面反复强调”日志异地、实时外发”：当本机日志不可信时，SIEM/独立日志服务器上的副本才是真相来源。

再谈一个高级技巧：用”正常基线”反找异常，而不只盯告警。很多攻击手法没有现成告警规则（比如攻击者用合法凭据慢悠悠地拖数据，单看每条都”正常”）。这时要靠”基线偏差”：比如某运维账户平时只在工作时间登录，突然凌晨三点从境外 IP 登录并批量下载；某数据库平时日增几 MB，某天突然导出几 GB。这些”偏离日常”的模式，比单条告警更能抓出”低调的坏人”。这也就是 UEBA（用户行为分析）的思路。

关于 时间线的”锚点”选取，有个常见误区：只拿”发现时间”当起点。但发现时间往往远晚于实际入侵时间（攻击者可能潜伏了数周）。更可靠的是找”最早的可疑痕迹”——比如 Web 日志里第一次出现漏洞利用特征、EDR 里第一次异常进程、防火墙第一次出现陌生外联。以这些”最早异常”为锚，向前追”怎么进来的”、向后追”潜伏期间干了什么”，时间线才完整。

还有一个跨源关联的现实难点：各设备时间不同步。防火墙记的 03:14、主机记的 03:14、WAF 记的 03:14 如果因为 NTP 没配而差了几分钟甚至几小时，你拼出的时间线就是错乱的，因果关系判断也会错。所以”全网约统一时间源（NTP）“不是运维小事，而是溯源准确性的前提。很多单位溯源翻车，根子就在时间没对齐。

最后提醒：日志留存周期要满足合规与调查需要。等保要求安全日志留存不少于六个月；而一次潜伏数月的 APT 攻击，六个月可能都不够。留存周期太短，等你想溯源时日志已被轮转删除，真相彻底消失。留存策略要按”最坏情况（长潜伏）“来设计，而非按磁盘省着来。

进阶速记与误区辨析

日志分析里也有几组容易让人得出错误结论的情况，专门辨析。

第一组，日志说没事与真的没事。如果本机日志在关键时间段出现了不连续的痕迹，或者干脆被清空了，那日志显示没异常反而说明日志本身不可信。判断之前要先确认日志在那一时间段是否完整，不能只看结论不看证据链。

第二组，单条告警与组合事件。孤立地看，一次失败的登录、一次奇怪的请求都像是噪声。但把它们按时间排在一起，扫描之后跟着利用成功、利用之后跟着外联，链条一出来就是真实的入侵。分析要习惯做关联，而不是盯着单条看。

第三组，正常基线与异常偏离。很多低调的坏人每一步单看都合规，只有放到他平时的行为基线里才显出反常，比如从不出境的账户突然在凌晨从境外登录并批量下载。这类要靠偏离日常的偏差来抓，而不是只靠现成的告警规则。

第四组，设备时间与真实时间。各设备的安全日志如果时间没有对齐，拼出来的时间线就是错乱的，因果关系也会判断错。所以全网约统一时间源这件事，表面是运维小事，实际是溯源准确性的前提。

速记收尾：日志先看完整性、单条要凑成链条、异常看偏离基线、时间必须对齐源。四句话对应四个分析时最容易踩的坑。

这一篇你该记住的

溯源靠日志：系统、Web、应用、安全设备、网络流量都要收，统一时区。
用确定时间点（爆破、shell 创建、C2 外联）作锚，向前追入口、向后追影响。
Linux 看 auth 日志爆破/成功；Windows 看 4625/4624/4720/4732/4688，尤其 1102 日志被清=毁证信号。
Web 日志按 IP 排序可还原”扫描→利用→传马→外联”链条。
跨源关联（SIEM 思路）才能串起全貌；工具用 Plaso/Timesketch、Elastic、Splunk。
终极问题”数据是否泄露”：看异常 SELECT、批量遍历、出口大流量。

下一篇我们看具体 恶意代码与病毒处置（挖矿、勒索、木马）。

网络安全