公网 ECS 创建两小时被爆破近 500 次：加固顺序错了，比不加固更危险

看到一份真实的公网 ECS 暴露记录：4 台华为云 ECS 创建于 14:12，到 16:05 时单台机器的 Failed password 记录已经达到 483 条，平均每 14 秒一次爆破尝试，攻击来源集中在两个网段、多个 IP 分布式发起，尝试的用户名几乎全是 root/admin/ubuntu 这类字典。这个数据本身不新鲜，但它引出了一个更值得警惕的问题：很多团队在应急加固时的操作顺序，会导致把自己锁在门外，而机器仍在被爆破。

一、 公网 SSH 的暴露窗口比想象中短

这条记录里，机器从创建到被爆破尝试只经过了十几分钟。攻击者的扫描是 7×24 不间断的自动化行为，不存在“刚创建的机器暂时安全”的窗口期。因此安全组的 SSH 规则不应该在创建实例时“先开 0.0.0.0/0 方便调试，回头再收”，而应该从第一秒就是最小范围：只允许管理网段或堡垒机 IP。

二、 防火墙加固的自锁陷阱

那份记录中有一个非常典型的事故：加固脚本里用 UFW 配置了 ufw default deny incoming，然后 ufw allow from 192.168.0.0/24 to any port 22，只放行了 VPC 内网到 22 端口。但运维人员是从公网 IP 连接的，规则生效的瞬间，SSH 连接被切断，机器失联。

这个事故的教训不是“别用 UFW”，而是加固操作必须有带外兜底。在启用任何可能切断当前管理连接的防火墙规则之前，确认三条路径至少有一条可用：云控制台的 VNC/远程登录、同 VPC 内另一台可 SSH 的跳板机、或者安全组本身作为第二层兜底（即使 UFW 锁了，安全组还可以临时放开）。那份记录里最终是靠同 VPC 的其他机器内网跳转恢复的。

三、 正确的加固顺序：从外到内，从网络到主机

基于这个案例，公网 ECS 的加固顺序应该是：

1. 安全组先行。 在实例创建时就把 SSH 限制到管理 IP 段，Web 端口只放行必要的来源。安全组是网络边界，它的变更不会切断已经建立的连接（除非显式拒绝），相对安全。

2. SSH 密钥登录替代密码。 在安全组收窄之后、防火墙规则变更之前，先把密钥登录配好并验证可用。PasswordAuthentication no 生效后，爆破尝试会直接失败，攻击面大幅缩小。

3. 主机防火墙作为纵深，但变更前确认管理路径。 UFW/firewalld 的规则变更要在密钥登录已经验证可用的前提下进行，并且分批执行，不要多台并行。第一台变更后验证 SSH 仍可用，再推后续机器。

4. fail2ban 或类似工具做动态封禁。 在 SSH 密钥化之后，爆破尝试虽然无法成功，但日志量和连接开销仍然存在。fail2ban 可以做一层动态过滤，减少无效连接对 SSH 服务的压力。

四、 总结

公网 ECS 的安全加固，核心不是“配了多少条规则”，而是规则生效的顺序是否保证你还能进去。安全组收窄 → 密钥登录验证 → 主机防火墙分批变更 → 动态封禁，这个顺序的每一步都以“管理通道仍然可用”为前提。那份记录里 483 次爆破是外部威胁，而防火墙自锁是自己制造的更大风险。