出事之后查什么：日志留存与审计的最小方案

被入侵后最常见的困境是：日志只有 7 天，攻击发生在一个月前。

日志策略要回答三个问题：留什么、留多久、怎么保证没被改过。

先说结论

认证与关键操作日志至少留 90 天，异地集中存储，开启完整性校验。

• 认证日志与 sudo 操作必留
• Web 访问日志保留 30-90 天
• 集中到独立日志服务器或对象存储
• 关键日志做哈希链或写入 WORM 存储

漏洞是怎么产生的

攻击者入侵后第一件事往往是清日志。所以日志必须在「被攻陷的机器之外」还有一份。

留存周期取决于合规与业务，但 90 天是个合理的下限。

修复与验证

修复不是改一行代码，而是四件事一起做：

• 确认关键日志：auth.log、nginx access/error、数据库审计、应用错误
• 配置 logrotate 与远端转发（rsyslog/vector）
• 开启 auditd 监控关键文件与提权操作
• 对日志做时间同步，保证跨机可关联
• 设置异常告警：登录失败激增、非工作时间 sudo

攻击面与检测点

按影响面排序，先修影响最大的：

几个容易踩的坑

下面这些是最常见的错误做法：

• 日志只存本机：被入侵后一起没
• 不校时：跨机日志无法对齐
• 审计规则过宽：日志量爆炸反而没人看
• 只收集不告警：出事仍是事后才发现

写在最后

日志是「事后能力」，但它的成本很低，收益在关键时刻才体现。

安全不是一次加固，是持续的假设：假设输入不可信、假设边界会破、假设有人会看错。