分析一次 SSH 暴力破解日志：从 fail2ban 说起

周一 07:42，邮件里躺着 fail2ban 的汇总：过去十二小时 ban 了二十三个 IP，jail 名称是 sshd。没有磁盘告警，没有「Accepted password」类成功登录，不算紧急事件。我还是把当天的 auth.log 和 fail2ban 日志拷到分析机，当作一次小型取证练习——公网 22 上到底在发生什么，现有控制有没有挡住该挡的东西。

告警原文与我首先排除的东西

告警正文只有计数和 jail，没有攻击者意图说明。我先排除三件「更吓人」的可能：是否出现非常用账号的成功登录、是否有 session opened 后紧跟异常 sudo、是否同一来源在短时间内横扫其它端口（需要和防火墙或 web 日志交叉）。

grep -E 'Accepted (password|publickey)' /var/log/auth.log | grep -v 'cron'
grep 'Failed password' /var/log/auth.log | wc -l
zgrep -h 'Ban' /var/log/fail2ban.log* | tail -n 50

结果：成功登录只有我自己的密钥会话，时间与办公习惯吻合；失败次数上千；fail2ban 的 Ban/Unban 呈波浪，符合「扫一段换下一家」的自动化节奏。结论第一步写在笔记本上：无失陷迹象，属于背景噪声升高，值得画像，不必深夜改生产。

从 Failed 行还原扫描画像

失败记录高度模板化。用户名侧：root、admin、ubuntu、test、oracle、postgres 轮换，偶尔夹杂字典里的常见名。来源 IP 多落在云主机段，地理分布散，单 IP 生命周期短——试几十次被 ban，再换出口。几乎没有针对我真实用户名的持续猜解。

grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
grep 'Invalid user' /var/log/auth.log \
  | awk '{print $8}' | sort | uniq -c | sort -nr | head

这幅画像说明多数是互联网上的无差别扫描，不是有人点名要我家 NAS。危险并不因此为零：若仍开着密码登录且密码弱，总有撞上的统计可能；若私钥被盗，日志会完全换一张脸——出现成功的 publickey、异常来源、登录后立刻翻文件。本次样本里没有后者。

时间分布上，夜间 UTC 忙碌、上午相对少，和全球僵尸网络作息一致。没有「只在我上班时间打、且用户名越来越准」的升级曲线。

对照当时的控制面

取证时机器上已经生效的控制包括：sshd 仅公钥、密码与 root 密码登录关闭、fail2ban 的 sshd jail、ufw 默认拒绝入站仅放必要口。对照日志：没有成功爆破，磁盘代价主要是日志量；fail2ban 把重复来源暂禁后，同一 IP 的连续失败被截断，噪声下降。

对「背景辐射」这套够用。不够用的威胁模型是另一张表：sshd 0-day、密钥从笔记本泄漏、或应用层别的口子。SSH 加固从来不能替代系统更新和暴露面收缩。fail2ban 是降噪与拖延，不是访问控制的根。

同一批 IP 有没有打别的门

我抽了 ban 列表里频次最高的五个 IP，去 web 访问日志和路由器连接跟踪里搜。其中两个在相近时间戳打过 80/443 的路径扫描（常见 PHP 管理入口、.env 探测）；另外三个只在 22 上出现。说明部分来源是「全端口或常见端口横扫」的脚本，部分是专用 SSH 字典机器人。对家庭栈的含义是：web 反代与 SSH 的防护要分开设计，不能假设「SSH 加固完就全身免疫」。

处置与收口，而不是只写观后感

当天没有做戏剧性的紧急变更。我做了四件可回滚的事：确认 PasswordAuthentication no 仍在生效；把 fail2ban 的 bantime 与 findtime 调到更符合这台机器噪声水平；在笔记里记下「正常噪声基线」——每天 ban 数十个 IP、用户名高度模板化、无真实用户名定向；启动把管理 SSH 收进 WireGuard 的计划，公网安全组最终关掉 22。

收进隧道后的第二周，auth.log 安静得不习惯。那才是我想要的稳态：告警邮件变少，不是因为视而不见，而是监听面本身消失了。