一次真实的日志入侵检测复盘
早上 8 点，运维群里弹出一句「官网打不开了」。
多数人的第一反应是重启服务。这次先忍住了——因为现场一旦被重启销毁，后面就只能靠猜。
先看现象，不猜原因
登录机器，按这三步收集证据：
- 看负载：确认是不是被打满了
- 看最近日志：定位第一个报错的时间点
- 看登录记录：确认有没有人从外面进来过
排查的第一步永远是取证，不是恢复。重启能解决 90% 的故障，也会销毁 100% 的证据。
一个容易踩的坑
如果登录记录里出现来源为境外的 pts/0 会话，基本可以确认是弱口令爆破打穿了。统计一下失败次数的分布：
bashgrep "Failed password" /var/log/auth.log \
| awk '{print $11}' \
| sort | uniq -c | sort -rn | head
输出会直接把攻击源排在最前面，比自己肉眼翻日志快得多。
处置顺序
拿到 IP 之后不要急着封。先确认这个 IP 有没有登录成功过：
javascript// 按会话粒度对齐登录成功与失败记录
const suspects = events
.filter((e) => e.type === 'auth')
.reduce((acc, e) => {
acc[e.ip] = acc[e.ip] || { ok: 0, fail: 0 }
acc[e.ip][e.result === 'ok' ? 'ok' : 'fail'] += 1
return acc
}, {})
const breached = Object.entries(suspects).filter(([, v]) => v.ok > 0)
console.log('已打穿来源：', breached)
本次复盘结果
| 时间 | 来源 IP | 判定 | 处置 |
|---|---|---|---|
| 08:12 | 45.207.x.x | 爆破成功 | 封禁 + 改密 + 轮换密钥 |
| 08:19 | 103.44.x.x | 持续尝试中 | 加入黑名单 |
| 09:03 | 154.219.x.x | 正常运维登录 | 放行 |
加固清单
- 关闭密码登录，只保留密钥认证
- 装 fail2ban，光改默认端口没有用
- 定期 审计
authorized_keys，删除离职人员的公钥 - 给关键操作留审计日志，
靠记性靠日志
最后一句：安全是一个过程，不是一次配置。
参考 基准检查清单。