日志审计与溯源的基本功

安全事件发生后，要回答"谁、什么时候、从哪进来、干了什么"，靠的不是记忆，是日志。日志平时没人看，出事那天它就是唯一的目击者，而目击者得先活着、留得全。 一、先留够这几种日志 Linux 主机上，登录痕迹在 /var/log/secure（CentOS）或 /var/log/auth.log（Ubuntu），记录每次 SSH 的成功与失败；操作痕迹看系统日志和 shell 历史；Web 侧是 Nginx 的 access.log 与 error.log，能看到异常请求路径和来源；数据库有自己的错误日志与慢查询日志；云控制台的关键操作也应有操作记录可查。这几样凑齐，主机与应用两条线的来龙去脉才拼得出来，缺哪样，哪段就是空白。应用自己打的关键日志也别忽略：登录、改密、支付、改权限这些动作在代码里埋点输出，格式统一带账号名，比事后从零散信息里拼凑强得多。 二、时间线怎么还原 溯源的核心动作是把零散日志按时间排齐。先用 last 看登录记录，再用 grep 'Accepted' /var/log/auth.log 找出成功登录的来源地址；带时间范围切 Web 日志，journalctl --since "2026-10-01 00:00" --until "2026-10-01 12:00" 一条命令就能取出指定时段。把登录、提权、文件改动、异常请求四个序列对齐到一张时间轴上，攻击路径基本就浮出来了。前提是时间同步：NTP 不开，几台机器各说各话，时间线本身就是错的。翻日志时同时留意攻击者的痕迹：多出来的陌生账号、crontab 里新增的条目、authorized_keys 里不认识的公钥，都是时间线上的关键节点。 三、保存期限与集中存放 日志留在本机有个致命弱点：攻击者得手后第一件事往往是清日志。把各机器日志用 rsyslog 实时转发到独立的日志服务器，本机被清，远端还在。日志内容至少带齐时间、来源地址、账号、动作四列，少了字段，后面想做分析也拼不出来。保存期限上，合规场景普遍要求不少于六个月，条件允许存一年更稳。磁盘成本要算，但一次事故的溯源价值，远超这点空间钱。 日志审计不神秘，留得全、存得远、看得懂，三条做到，溯源就有了底气。平时随手翻翻日志的习惯，比出事后通宵排查值钱得多。