确定异常开始时间,核心是找到“站点行为第一次偏离正常基线”的时间点,而不是发现告警或收到通知的时间。百度网站安全检测的异常提示往往滞后于实际篡改,所以要用站内日志、文件时间戳、百度搜索资源平台反馈、第三方监控四条证据链交叉比对,取最早且能互相印证的那个时刻作为异常开始时间。
很多人把下面三个时间当成同一个,结果排查方向全错:
判断标准很简单:如果某个时间点之前的所有证据都正常、之后都异常,它才可能是异常开始时间。只有一个来源支持的时间,只能算候选。
查什么:定位到疑似被篡改页面或目录的访问记录,重点看POST请求、异常User-Agent、陌生IP、非管理时段的批量访问。
怎么查:在服务器或日志平台按URL路径过滤,把时间范围拉到异常提示出现前若干天,按时间正序排列,找第一次出现可疑请求的时刻。
结果说明什么:如果某条可疑请求之后紧接着出现文件修改或页面内容变化,这个请求时间就是异常开始时间的有力候选。若日志已被清理或未开启,此项无法作为证据,需要靠其他来源。
查什么:被篡改文件的mtime(最后修改时间)、CMS后台的修订记录、代码仓库的提交历史。
怎么查:用ls -l --time-style=full-iso或文件管理器查看修改时间;有Git的站点执行git log --follow 文件路径看每次提交时间;CMS则查文章或模板的修订历史。
结果说明什么:文件修改时间直接指向写入动作发生的时刻,是最接近“异常开始时间”的证据。但要注意:批量同步、备份还原、部署也会更新mtime,需要结合提交内容判断是正常操作还是恶意写入。若mtime被攻击者回拨,此项不可信,需与日志交叉验证。
查什么:百度搜索资源平台的安全检测提示、抓取异常、死链或内容变更记录,以及百度快照的更新时间。
怎么查:登录搜索资源平台,查看安全类提示的首次出现日期;对比快照内容与当前页面内容,记录快照抓取时间。
结果说明什么:百度侧时间只能证明“百度在某时刻已抓到异常内容”,它是异常开始时间的上界,即异常一定不晚于这个时间。它无法给出精确起点,因为抓取本身有周期。把它当作区间的一端,而不是答案。
查什么:可用性监控、页面内容监控、站内搜索或UV/PV曲线的突变点。
怎么查:调出异常提示前一到两周的监控图表,找流量、跳出率、状态码或页面哈希第一次明显偏离基线的时刻。
结果说明什么:监控曲线突变通常与异常发生时间接近,但流量波动也可能由活动、外链或季节因素引起。第三方估算流量、搜索引擎报告与站内统计口径不同,不能混用同一套基线。只有排除其他解释后,突变点才能作为候选时间。
把上面四项得到的时间列成一条时间轴,按以下规则判断:
假设某页面在周一被百度提示风险,日志显示周日凌晨有一次陌生IP的POST请求,文件mtime也是周日凌晨,快照时间是上周五。那么异常开始时间应定为周日凌晨,而不是周一。这里的日期仅为举例说明推理方式,不是真实项目数据。
确定时间后,下一步是围绕这个时间点前后各查一段日志和操作记录,找出在该时刻有权限、有动作的人或进程,从而定位是账号泄露、插件漏洞还是服务器入侵。