Web 日志与文件时间
Web 入侵通常留下两类互不相同的痕迹：访问日志里的请求记录，与网站目录里被写入或改动的文件。把两者按同一时间窗对齐，才能把「哪个请求写下了哪个文件」这条链路闭合。日志侧看请求时间与状态码，文件侧看 mtime 与 ctime。
基本信息
| 日志侧 | Nginx access.log、Apache access.log、应用自身日志 |
|---|---|
| 关注字段 | 客户端 IP、时间、方法、URL、状态码、响应字节数 |
| 文件侧 | 上传目录、临时目录内文件的 mtime 与 ctime |
| 时区要求 | 日志时间与文件系统时间使用同一时区 |
| 常用命令 | grep、awk、find -newermt、stat |
| 前置确认 | 日志格式由配置决定，解析前先确认格式定义 |
典型使用场景
- 定位 Web 上传落地的具体文件
- 排查 webshell 的首次写入时刻
- 核对被篡改页面所处的改动窗口
- 区分扫描行为与真实利用请求
- 为内容篡改类事件建立完整链路
最小示例
最小示例
grep -E 'POST .*\.(php|jsp|asp)' /var/log/nginx/access.log | tail -5
find /var/www/html -type f -newermt '2026-01-02 03:00' ! -newermt '2026-01-02 06:00'
stat -c '%n mtime=%y ctime=%z' /var/www/html/upload/app.php
awk '{print $4, $9}' /var/log/nginx/access.log | tail -20
wc -l /var/log/nginx/access.log # 记录日志覆盖的行数范围
sha256sum /var/log/nginx/access.log # 解析前先固化哈希两侧观察项
| 侧别与字段 | 含义 | 说明 |
|---|---|---|
| 日志时间 | 请求发生时刻 | 需与文件时间处于同一时区 |
| 状态码 | 请求结果 | 200 配合上传路径最值得关注 |
| URL 与查询串 | 请求目标 | 含编码或危险扩展名要单独列出 |
| 响应字节数 | 返回内容长度 | 异常小可能是探测而非利用 |
| 文件 mtime | 内容写入时刻 | 应落在可疑请求之后数秒内 |
| 文件 ctime | 元数据变更时刻 | 新建文件的 ctime 与 mtime 通常接近 |
find 的时间窗要与日志时间窗对齐，命中文件与请求逐条对应才能形成闭环；单侧证据只能说明可能性，不能直接下结论。
反向代理与 CDN 场景下真实客户端 IP 记在额外请求头字段里，access.log 中的地址可能是代理地址，解析前先确认代理配置。
被篡改的文件若被刻意恢复过时间戳，mtime 与内容实际改动就会不一致，需要借助备份哈希与防护设备日志交叉确认。
不要用访问 webshell 地址的方式来验证：该请求会写入新日志，还可能触发载荷动作，直接污染现场。