泄露自查系统一跑，问题全在日志里

跑完泄露自查系统，报告一片绿，这大概是运维最不该放松的时刻。工具给你的是结论，日志给你的是过程。结论可以靠规则拼出来，过程拼不了。我见过不止一次自查通过、过段时间才出事的场面，回头翻日志，痕迹明明白白躺在那儿，只是当时没人往下多翻两页。

泄露自查系统比对的是规则，日志留下的是经过

这类工具的思路都差不多：拿一批已知特征去比对——弱口令、默认后台路径、目录列表开着、某个组件版本存在已知问题、敏感文件能不能直接下载。覆盖面取决于规则库，规则库又取决于别人踩过的坑，所以它天生滞后。日志不判断对错，它只把发生过的事情按时间排好。谁在几点几分试了多少次登录、哪个地址把 /admin 从头扫到尾，它都记着，只是不给结论。自查是筛子，日志是底片，这两样东西互相替代不了。

认证日志最容易被一眼带过

Linux 上登录记录一般在 /var/log/secure（Debian 系是 /var/log/auth.log），失败记录用 lastb 也能拉出来。多数人扫一眼今天有没有异常的成功登录就收工。值得看的是失败和成功的配比：某个来源连续失败一大片，紧接着冒出一条成功，这条成功就是关键。Windows 那边对应安全日志里的 4625 和 4624 事件，思路一样。刷屏不烦人，刷屏本身就是信号。

还有一个常被漏掉的地方是账号本身的状态。离职几个月的账号还在，外包给的临时账号没停，几个人共用一个运维账号，这些在日志里表现为同一个账号在不同城市、不同时间段登录，看着不像攻击，实际比攻击更难查。谁干的说不清，这就是问题。

访问日志里不合群的那几条请求

nginx 的 access.log 一行一条，枯燥，但异常都藏在不像人的地方。正常用户有前后路径关系，先首页、再栏目、再详情；扫描器没有，它从 / 直接跳到 /backup.zip 再跳到登录页，节奏还特别均匀。UA 一栏也能看出东西，一批请求共用同一个少见 UA 或者干脆空着，正常流量里很少成规模出现。状态码同理，401 和 403 集中压在同一条路径上，多半有人在猜路径、猜口令。这些用 grep、awk 排一排就能看出来，不需要多高级的设备。

反向代理后面的日志，IP 可能全是假的

站点前面挂了 CDN 或者反向代理，access.log 里的来源地址经常是一串回源 IP，真实访客落在 X-Forwarded-For 或者 X-Real-IP 里。这时候按 IP 去封、去统计，结论全是错的。要么在 nginx 里配好 realip 模块、把代理段信任起来，要么换个字段分析。这一步不做，后面的自查基本是在看假数据。另外 200 状态码也别太信，有些探测请求服务端就是回 200，页面内容才是判断依据。

日志自己也会坏掉

这个坑踩过不止一次。logrotate 按时切、按时删，等你回头找那段记录，它刚好被转走或者压没了。时区也常出岔子，应用按 UTC 写、系统按本地时间写，两边差几个小时，时间线上拼不出完整的事。日志级别调得太高，可疑操作只落下一行 info 甚至什么都不落。所以自查开始前该问的不是有没有问题，是日志够不够用、留得够不够久、时间对不对得上。保留多久没有统一答案，按业务敏感程度和合规要求定，拿不准就以服务商说明或者等保测评的要求为准。

数据库审计和应用错误日志，藏得最深

数据库审计日志如果开了，能看到谁在什么时间查了哪张表、导出了多少行。有一类泄露根本不是被攻破，是账号被拿去正常登录、正常导出，访问日志干干净净，痕迹只在审计日志里。应用错误日志也别只当 bug 库看，报错里带出来的库名、表名、内网地址、堆栈路径，对想找入口的人来说就是地图。这些不该原样返回给前端，也不该随手贴到公开的 issue 里。

查完先止血，报告最后写

顺序别弄反。查出来问题，先做能立刻做的：弱口令改掉、用不到的后台和端口关掉、可疑会话踢下线、可疑账号停用、该轮换的密码排上。然后才是留档和影响范围评估，报告放最后。见过反着来的，先截图发群里讨论半天，讨论完密码都还没改。

日志本身也是敏感数据

这事有点黑色幽默。为了查泄露把日志打包，里头全是用户 ID、手机号、内网地址、库名，然后用聊天工具传来传去，传给三拨人。查泄露的过程变成新的泄露。要么先脱敏，要么只给时间窗内的片段，要么放到受控的机器上让人来看，看完就清。日志该按敏感数据管，不该按临时文件管。

最后给几条能立刻用上的：日志保留期写进运维记录；机器上把时间同步开着；认证日志每周有人翻一次；访问日志抽几天看看异常路径和异常 UA；数据库审计确认是开着的；自查报告不能代替日志复核。泄露自查系统跑一遍大概一小时，翻日志是长期的活，但它回答的是到底发生过什么，这个问题工具答不了。