问题背景

公司安全部门推动「所有服务器运维必须走堡垒机 + 审计」已半年，堡垒机（JumpServer）已上线并接管 60% 服务器。但在一次例行安全巡检中，安全团队用 ssh root@10.8.0.0/16 -o PreferredAuthentications=password 在内网批量扫到 47 台服务器仍允许 root 密码登录，其中 19 台存在 authorized_keys 含「运维跳板机」公钥，可免密直达。

进一步发现：

• 3 台核心 MySQL / Redis 集群主节点允许 deploy 用户免密跳板，私钥散落在多台跳板历史镜像中
• 堡垒机策略组只覆盖了「新上架」服务器，老系统（2019 年前）因「历史原因」被标记为「临时直连」
• /var/log/secure 和堡垒机审计日志完全脱钩，root 直登无任何记录

这意味着堡垒机上线只是「部分接管」，真实攻击面仍暴露在直连与免密跳板上。

故障现象

1. root 直登可达：内网任意机器可直接 ssh root@prod-db-01，无需 MFA、无堡垒机审批
2. 免密跳板横行：老跳板机（10.0.3.45）保存了 8 台核心服务器的 deploy 用户私钥，可直接跳板进生产
3. 审计完全缺失：堡垒机 audit log 只记录了「通过堡垒机」的操作，直连/免密跳板零记录；安全部门月报「堡垒机覆盖率 92%」实为假象
4. 特权账号基线失控：deploy、app、monitor 等功能账号密码在多台机器上复用，root 密码甚至写在 Wiki「内部运维手册」公开页面

一次例行漏洞扫描触发了 127 条高危告警（「允许 root 登录」「存在免密跳板」「特权账号基线缺失」）。

排查过程

第一步：确认暴露面

用 nmap + ssh-audit 扫全网：

1
2
3
4
5

nmap -p 22 --open 10.0.0.0/8 -oG - | awk '/22\/open/ {print $2}' | \
while read ip; do
  echo "=== $ip ==="
  ssh -o BatchMode=yes -o ConnectTimeout=3 root@$ip "whoami;lastlog|head -3"
done

结果：47 台允许 root 密码登录，19 台可免密（authorized_keys 含跳板公钥）。

第二步：溯源免密跳板

在老跳板机 10.0.3.45 上发现：

1
2
3

ls -l ~/.ssh/
-rw------- 1 ops ops 1679 Aug 12  2023 id_rsa_prod
-rw-r--r-- 1 ops ops  398 Aug 12  2023 id_rsa_prod.pub

~/.ssh/config 里写满了 Host 别名：

1
2
3
4

Host prod-db-01
  HostName 10.8.2.11
  User deploy
  IdentityFile ~/.ssh/id_rsa_prod

这些私钥散落在 5 台历史跳板机 + 3 台运维笔记本中。

第三步：检查堡垒机策略

登录 JumpServer 控制台：

• 资产组「生产-数据库」只包含 12 台新 MySQL，缺 3 台老集群
• 「允许直连」标签被打在 31 台服务器上，审批流被跳过
• 堡垒机与服务器之间无「定期对账」机制，新增服务器不自动入堡垒机

第四步：审计日志脱钩

堡垒机只记录「通过堡垒机登录」的操作：

1

{"session_id":"xxx","user":"zhangsan","asset":"prod-web-01","action":"login","timestamp":"2026-08-28T09:12:00Z"}

而直连 root 的操作完全无痕：

1
2

last root
root     pts/0      10.8.1.55    Wed Aug 27 23:45 still logged in

/var/log/secure 里全是直登记录，堡垒机 audit log 完全看不到。

解决方案

1. 紧急止血（2 小时内）

• 所有允许 root 密码登录的服务器，立即改 PermitRootLogin prohibit-password，root 密码轮换
• 所有 authorized_keys 含跳板公钥的条目删除，私钥从跳板机/笔记本上清零
• 临时在核心交换机 ACL 阻断「非堡垒机 IP → 生产网 22 端口」，强制所有运维走堡垒机

2. 堡垒机策略全量覆盖（3 天）

• 把所有服务器（含老系统）导入 JumpServer，统一用「生产」「预发」「测试」三套资产组
• 所有功能账号（deploy/app/monitor）密码由堡垒机托管，禁止明文存储
• 堡垒机审批流强制开启「双人复核」（高权限操作需第二人确认）

3. 免密跳板清零 + 凭据收口

• 所有历史跳板机 ~/.ssh/ 目录清空，/etc/ssh/ssh_config 里的 Host 别名删除
• 核心服务器的 authorized_keys 只保留堡垒机公钥，禁用 PermitRootLogin、AllowUsers 只允许堡垒机跳板用户
• 所有特权账号密码统一由堡垒机托管 + 定期轮换（90 天）

4. 审计全链路打通（1 周）

• 堡垒机 audit log + 服务器 /var/log/secure + auditd 三层日志集中到 ELK
• 堡垒机「会话回放」功能全开，高权限操作 180 天留存
• 安全部门每月「堡垒机覆盖率」报表改为「真实覆盖率 = 已入堡垒机服务器数 / 全量服务器数」，禁止用「允许直连」标签美化数据

5. 上线门禁固化

• 新服务器入网 CheckList 增加「已入堡垒机 + 审批流已配置」硬门禁
• 老系统「临时直连」标签每月清理一次，超过 30 天未整改的自动阻断 22 端口
• 堡垒机与 CMDB（iTop）打通，服务器下架时自动从堡垒机移除

根因分析

1. 历史包袱未清零：堡垒机上线只接管了「新系统」，老系统因「历史原因」被打「允许直连」标签，标签永不清
2. 免密跳板文化根深蒂固：运维团队习惯「跳板机 → 目标服务器免密」，堡垒机只是「多加一层」，私钥仍散落
3. 审计与基线双缺失：堡垒机只管「自己管辖」的机器，直连/免密跳板零审计；特权账号基线从未建立
4. KPI 作假：安全部门「堡垒机覆盖率 92%」是用「允许直连」标签把分母做小，真实覆盖率只有 60%

预防措施

1. 堡垒机全量覆盖 + 定期对账

   • 每月 1 号跑脚本比对 CMDB 全量服务器 vs 堡垒机资产，差异自动告警 + 工单
   • 禁止「允许直连」标签，历史标签每月清理

2. 免密跳板零容忍

   • 所有服务器 authorized_keys 只保留堡垒机公钥，私钥统一由堡垒机托管
   • 跳板机 ~/.ssh/ 目录定期扫描，出现非堡垒机公钥立即告警

3. 特权账号基线 + 定期轮换

   • root/deploy/app/monitor 等账号密码全部托管堡垒机，90 天强制轮换
   • 禁用 root 密码登录，PermitRootLogin prohibit-password

4. 审计全链路 + 异常告警

   • 堡垒机 audit log + 服务器 secure/auditd 集中 ELK
   • 检测到「非堡垒机 IP 登录生产网 22 端口」立即告警 + 封禁 30 分钟

5. 上线门禁 + 季度复盘

   • 新服务器入网必须「已入堡垒机 + 审批流已配置」才能放行
   • 每季度复盘「堡垒机真实覆盖率」「免密跳板残留数」「特权账号轮换 compliance」

总结

堡垒机上线只是「工具落地」，真正难点是「把历史包袱清零 + 把文化改过来 + 把基线建起来」。本次事件暴露了「部分接管 = 零接管」的残酷现实——只要有一台服务器允许 root 直登或免密跳板，整个堡垒机体系就形同虚设。

关键教训：

• 堡垒机覆盖率必须「全量真实覆盖」，禁止用「允许直连」标签美化数据
• 免密跳板是「定时炸弹」，必须清零 + 私钥托管
• 特权账号基线 + 定期轮换是底线，审计全链路是保障

下阶段计划：把「堡垒机全量覆盖 + 免密跳板清零 + 特权账号基线」做成 Checklist，强制每季度复盘一次，避免历史包袱再次堆积。