SSH on Zero Day Notes

记一次 SSH 暴力破解触发 fail2ban 自动封禁的处置

Tue, 16 Dec 2025 17:58:32 +0000

一、问题背景

我司有一台面向公网的跳板/运维服务器 bastion01（CentOS 7.9，内核 3.10，公网 IP 203.xx.xx.30），用于 SSH 接入内网资产，对外开放 22 端口。为防范暴破，早年已部署 fail2ban 0.11，对 SSHD 的 sshd jail 配置为 5 分钟内失败 5 次即 ban 600 秒。同时系统启用 firewalld 作为底层防火墙。该服务器承载约 30 名运维人员的日常登录，平时流量平稳。

2025-12-16 下午 17:40 左右，我收到 Zabbix 告警：bastion01 的 CPU 软中断（si）与 sshd 进程数异常升高，同时 fail2ban 的 ban 动作日志出现频率激增。作为当班安全运维，我登录研判，确认为一次规模化 SSH 暴力破解攻击。

二、故障现象

fail2ban 日志（/var/log/fail2ban.log）在 17:38 起密集出现封禁记录：

2025-12-16 17:38:12 bastion01 fail2ban.actions[812]: NOTICE [sshd] Ban 193.xx.xx.22
2025-12-16 17:38:55 bastion01 fail2ban.actions[812]: NOTICE [sshd] Ban 45.xx.xx.91
2025-12-16 17:39:31 bastion01 fail2ban.actions[812]: NOTICE [sshd] Ban 218.xx.xx.170
... (17:38-17:58 共 Ban 412 个 IP)

系统侧现象：

journalctl -u sshd 显示海量 Failed password for invalid user 与 Failed password for root，每秒数十次。
iptables -L f2b-sshd -n -v 中 fail2ban 自动生成的链已积累数百条 DROP 规则，单链接近上限。
CPU 中 si（软中断）占用达 35%，sshd 子进程堆积到 200+，last 显示无成功暴破登录（说明账号侧暂未失守，但服务被"噪声"拖慢）。

直观判断：服务器正遭受来自大量境外 IP 的分布式 SSH 暴破，fail2ban 在自动封禁，但规则膨胀已影响性能。

三、排查过程

第一步：量化攻击规模与来源。

统计 /var/log/secure 中的失败登录来源与尝试账号：

grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head
#   412 193.xx.xx.22
#   388 45.xx.xx.91
#   351 218.xx.xx.170
#   ... (Top 来源为俄罗斯/巴西/越南 ASN)
grep "Failed password" /var/log/secure | awk '{print $9}' | sort | uniq -c | sort -rn | head
#   root       2981
#   admin       1102
#   test        883
#   oracle      540

确认攻击者主要爆破 root 及常见弱账号名，且使用分布式 IP 池以规避单 IP 封禁阈值。

第二步：确认是否已有成功入侵。

检查成功登录记录与异常会话：

last -ai | head
# 仅见到 30 名已知运维的公网/办公网 IP，无境外成功登录
grep "Accepted password" /var/log/secure | grep -vE "58.xx.xx.10|10.20" | wc -l
# 0  (无异常成功登录)

同时核查 authorized_keys 与 /etc/passwd 有无新增可疑账号，未发现后门。结论：攻击被拦截在认证阶段，尚未得手。

第三步：评估 fail2ban 自身压力。

iptables -L f2b-sshd -n | wc -l
# 470  (规则接近 iptables 单链 500 条经验上限，匹配性能下降)
systemctl status fail2ban | grep -i memory
# 内存占用较平日上涨 3 倍 (规则表过大)

确认 fail2ban 虽在正常工作，但 ban 列表无上限增长已造成性能劣化，需要临时减负。

四、解决方案

1. 临时减压（止血）：

缩短 ban 时长并限制单链规模，避免规则堆积拖垮性能：将 bantime 临时调为 3600 秒、并启用 maxmatches 去重。
对攻击最密集的 3 个 ASN 段在 firewalld 上做整体封锁（比逐 IP 高效）：

1
2
3

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=193.xx.xx.0/24 reject'
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=45.xx.xx.0/24 reject'
firewall-cmd --reload

重启 fail2ban 以清空过度膨胀的 ban 列表：systemctl restart fail2ban。

2. 加固 SSH 防护（治本）：

编辑 /etc/ssh/sshd_config 并 systemctl restart sshd：

PermitRootLogin no
PasswordAuthentication no        # 全面改用密钥登录
MaxAuthTries 3
LoginGraceTime 20
AllowUsers ops1 ops2 ops3        # 显式白名单

为 30 名运维统一签发 ED25519 密钥并禁用口令，从根本上消除口令暴破面。

3. 收口网络暴露面：

通过边界防火墙将 22 端口仅对运维办公网段（58.xx.xx.10/24）与 VPN 网段开放，公网不再直接暴露；保留 fail2ban 作为纵深防御的最后一道。

处置后 18:10 观测，失败登录归零，sshd 进程数回落到个位数，CPU si 恢复正常。

五、根因分析

暴露面过大：bastion01 的 22 端口直接对公网全开，等于把认证入口暴露在全球暴破僵尸网络面前，这是事件发生的根本原因。
口令认证脆弱：即便有 fail2ban，口令登录仍给攻击者留下"试错"空间；分布式 IP 池还能稀释单 IP 失败计数，绕过敏感阈值。
fail2ban 配置粗放：bantime 与规则上限未设防，攻击洪峰下 ban 列表无限膨胀，反而成为新的性能负担，属于"防御机制被攻击放大"的次生问题。
root 可登录：PermitRootLogin yes 直接给攻击者明确的爆破目标用户名。

六、预防措施

最小化暴露：所有公网 SSH 仅对受信网段/VPN 开放，非必要不暴露 22；可改用非标准端口 + 端口敲门（port knocking）进一步降低被扫概率。
密钥优先：推行 PasswordAuthentication no + ED25519/RSA 密钥 + 可选硬件 Key（FIDO2），口令暴破从根上失效。
精细化 fail2ban：设置 bantime.increment = true 递增封禁、maxretry 收紧、maxmatches 限制规则数，并配合 ipset 而非纯 iptables 链以承载大规模封禁。
部署防暴破纵深：前置 fail2ban 之外，可叠加 Cloudflare/网关层的 WAF 与速率限制，或在堡垒机启用 MFA（TOTP）。
常态化监控：将 fail2ban 的 ban 速率、sshd 失败计数接入 Zabbix/Grafana 看板，设置"单位时间内 ban 数突增"的主动告警，先于性能劣化被发现。

七、总结

这次事件是公网 SSH 暴露面被分布式暴破的典型案例。fail2ban 在认证层成功拦截了全部入侵尝试、未让任何境外 IP 登录得手，证明了它在"最后一道防线"上的价值；但它也用自身规则膨胀的副作用提醒我们：防御机制本身需要被正确调参，否则在攻击洪峰下会变成新的瓶颈。真正的解决之道不在"封得更狠"，而在"暴露得更小"——把 22 端口收进受信网段、用密钥替代口令，让暴破连"试错的机会"都没有。安全运维的常态，就是用一层层收敛的攻击面，把麻烦挡在门外头。

记一次堡垒机 SSH 超时致运维无法紧急操作的排查

Wed, 21 Feb 2024 15:30:00 +0000

问题背景

公司内网部署了一台 JumpServer 堡垒机，所有运维人员通过该堡垒机 SSH 跳转到生产服务器。堡垒机配置了完整的会话审计（录像 + 日志），日均登录次数约 200 次。

故障现象

下午 3:10，线上 Redis 集群发生主从切换异常，需要紧急登录服务器切换 VIP。运维人员通过堡垒机 SSH 登录目标服务器时，发现从输入 ssh 命令到出现密码提示，卡顿了 30 秒以上，登录过程极度缓慢。多位运维人员同时遇到相同问题，严重拖慢了故障处理进度。

登录行为在 putty 的表现：Connecting to 10.x.x.x... 长时间停留在该状态，且无任何超时报错。

排查过程

第一步：网络连通性检查

首先排查是否是网络问题：

1
2

$ ping 10.x.x.x -c 10              # 延迟正常，<1ms
$ telnet 10.x.x.x 22                # 端口秒开，排除TCP握手问题

网络层面一切正常，问题锁定在堡垒机本身或 SSH 服务端。

第二步：堡垒机资源检查

1
2

$ top                                # CPU idle >95%，Memory available >4GB
$ iostat -x 1                       # 磁盘IO await <5ms，无异常

堡垒机本身资源非常充裕，不是性能瓶颈。

第三步：SSH 客户端详细调试

使用 ssh -vvv 查看详细交互过程：

$ ssh -vvv user@10.x.x.x
...
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
# <--- 此处卡顿30秒 --->
Last login: Wed Feb 21 15:28:00 2024 from 10.x.x.y

卡顿发生在认证成功后、进入交互会话之前——此时 SSH 守护进程会做两件事：更新登录日志（wtmp/lastlog）和PAM 会话模块初始化。

第四步：wtmp 锁定

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda1        20G   19G     0 100% /var

/var 分区 100% 占满。进一步排查：

1
2
3

$ ls -lhS /var/log/jumpserver/ | head -5
-rw------- 1 jumpserver jumpserver 8.2G Feb 21 15:28 session_replay_20240221.log
-rw------- 1 jumpserver jumpserver 5.1G Feb 20 23:59 session_replay_20240220.log

堡垒机的会话审计录像日志堆积了超过 15GB，而 /var/log/wtmp 也受分区满载影响无法写入：

1
2
3

$ tail -f /var/log/secure | grep wtmp
Feb 21 15:12:34 bastion sshd[4823]: pam_lastlog(sshd:session): \
  unable to open /var/log/wtmp: No space left on device

pam_lastlog.so 在尝试写入 wtmp 时阻塞，导致 SSH 会话建立被严重拖慢。

解决方案

紧急处理：

1
2
3

# 临时关闭 pam_lastlog 模块
sed -i 's/^session.*pam_lastlog.so/#&/' /etc/pam.d/sshd
systemctl restart sshd

重启 sshd 后，登录速度恢复正常（<2秒）。

清理旧审计日志：

1
2

find /var/log/jumpserver/ -name "*.log" -mtime +7 -exec gzip {} \;
find /var/log/jumpserver/ -name "*.log.gz" -mtime +30 -delete

配置日志轮转：创建 /etc/logrotate.d/jumpserver 并配置按天轮转、保留 30 天。

根因分析

直接原因：JumpServer 的会话审计录像日志未做轮转和清理，占满 /var 分区，导致 pam_lastlog.so 在尝试更新 wtmp 时长时间阻塞。

深层原因：堡垒机初始部署时未规划日志分区隔离——/var 分区与系统盘共享 20GB 空间，且未配置任何 logrotate 策略。对于每天产生数百 MB 审计录像的堡垒机来说，20GB 很快就会被耗尽。

预防措施

磁盘分区隔离：堡垒机单独挂载一块大容量磁盘用于审计日志存储
配置 logrotate：审计日志按天轮转，保留 30 天，超过后自动删除
磁盘容量监控：/var 分区使用率 >80% 时触发告警
pam_lastlog 优化：将 silent 参数添加到 pam_lastlog.so 行，避免因 wtmp 写入失败阻塞登录
定期巡检：每月检查堡垒机的磁盘和日志状态

总结

堡垒机作为运维入口，其稳定性直接关系到故障应急效率。/var 分区满了看似是小问题，但在 SSH 登录这种场景下会被放大为严重的业务影响。任何时候，关键基础设施的磁盘分区和日志轮转都应该在部署时做好规划，而不是等到故障爆发再救火。