Hostease 公网服务器防火墙基线复盘：放行 SSH 不等于放开风险

公网服务器防火墙怎么设，才既能解决暴露 SSH（安全外壳协议）的问题，又不会把自己挡在机器外面？这个问题在 WHT 论坛里很常见，尤其是新服务器刚交付、准备上线网站或迁移业务时，很多人第一反应是“先把 22 端口限制掉”。方向没错，但如果没有回滚窗口、没有控制台通道、没有先验证当前连接来源，放行 SSH（安全外壳协议）不等于放开风险，误封 SSH（安全外壳协议）也不等于安全加固成功。

这篇复盘以公网服务器的日常运维场景为例，讨论一套更稳妥的防火墙基线：先确认登录路径，再收紧来源，再记录验证命令，最后才做持久化。文章不虚构官方配置参数，只从 Linux 常见防火墙工具、运维流程和故障回滚角度，给出可以落地的检查顺序。相关阅读可参考 WHT 上的 香港 VPS（虚拟专用服务器）安全配置清单，本文重点放在“别把 SSH（安全外壳协议）入口锁死”这一件事上。

一、先确认 SSH 入口到底从哪里来

很多误封并不是防火墙本身“太严格”，而是运维者没有先看清自己的连接路径。最常见的情况有三种：家里宽带公网地址变了、办公室出口走了 NAT（网络地址转换），或者你在跳板机后面操作，结果只放行了自己的本机地址。SSH（安全外壳协议）最怕的不是“默认开放”，而是“按错对象开放”。

建议先做三件事：
1. 先在当前会话里记录 who am i、w、ss -tnp | grep :22 的结果，确认自己是通过哪条链路连进来的。
2. 如果是云服务器（弹性计算主机），优先保留一条控制台或救援模式路径，不要只依赖现有 SSH（安全外壳协议）会话。
3. 如果有堡垒机或跳板机，先确认出口 IP 再写规则，不要拿笔记本内网地址直接当白名单。

这样做的目的不是复杂化流程，而是避免把“临时来源”误当成“长期来源”。一旦白名单写错，防火墙就会把正确的人挡在门外。

二、把防火墙规则拆成“放行、限制、验证”三层

一套好用的基线，往往不是把所有安全策略都堆进一条命令，而是分层处理。第一层只负责让你回得去，第二层负责限制暴露面，第三层负责验证是否真的生效。

举个常见思路：
– 放行层：仅允许管理来源访问 22 端口，其他来源默认拒绝。
– 限制层：对 SSH（安全外壳协议）增加速率限制，避免暴力尝试拖垮认证日志。
– 验证层：在改规则前开一个新终端，先测试 ssh -p 22 user@server 是否仍可达，再提交持久化配置。

很多人会忽略第三层，结果是规则看似写进去了，实际却因为顺序错误、链路优先级冲突或者默认策略问题，导致自己先被锁死。尤其在多防火墙组合场景里，系统级规则和云侧安全组之间如果顺序理解错了，就容易出现“本地放行了，云侧还拦着”或“云侧放行了，本地又拦住”的双重错觉。类似的基础选型和运维边界，也可以参考 购买指南栏目 中的相关讨论。

三、把回滚动作写在改动前，而不是事故后

真正成熟的防火墙基线，不是“永不出错”，而是“出错时能迅速退回”。因此，改 SSH（安全外壳协议）规则前最好先准备回滚动作，例如保留旧规则备份、保留一个未关闭的终端窗口、确认云控制台登录可用，或者先在临时规则里加入超时自动回退。

如果你用的是命令行防火墙，建议遵循这个顺序：
– 先导出当前规则快照。
– 再追加新规则，而不是直接覆盖。
– 再开一个独立窗口做连通性验证。
– 最后再做持久化。

这套顺序的价值很朴素：只要新规则有问题，你至少还有一个退路。没有回滚，就不是加固，而是赌博。

四、适合公网服务器的最小安全基线

如果是面向公开业务的服务器，建议把目标设成“最小可用暴露面”，而不是“把所有门都打开后再慢慢关”。一个可执行的最小基线通常包括：
– 只允许固定管理来源访问 SSH（安全外壳协议）。
– 禁止直接暴露数据库端口给公网。
– 只开放业务必须的 80/443 端口。
– 定期检查新增来源规则是否还在使用。
– 把异常登录尝试和规则变更记录下来，方便回溯。

对于这类公网服务器使用场景，很多用户真正需要的是“稳、可回滚、能解释”的配置，而不是一套看上去很硬但一改就断的脚本。尤其在团队协作中，后续接手的人如果看不懂规则来源，往往会为了图省事直接删掉，前面的安全工作就白做了。

五、怎么判断自己有没有误封自己

判断是否误封，不一定要等到完全失联才发现。更稳妥的做法，是在提交规则前就做一次双通道验证：一个会话保留不动，另一个会话模拟新连接。如果新会话能连上、旧会话仍然存活，说明这次变更大概率是安全的。

如果已经出现连接异常，可以按这个顺序排查：
1. 先检查云侧安全组是否已同步。
2. 再检查本机防火墙默认策略。
3. 然后核对 SSH（安全外壳协议）端口是否被改写。
4. 最后回看白名单来源 IP 是否仍然正确。

总结：安全加固的目标是可控，不是封死

防火墙基线的真正价值，不是把 SSH（安全外壳协议）关得越死越好，而是让你在收紧入口的同时，仍然保有回滚和验证能力。对于公网服务器来说，最怕的是“看起来很安全，实际上自己也进不去”。所以更稳妥的做法，是先确认来源、再收紧规则、再验证连通、最后才固化配置。

如果你正在为新服务器做第一次加固，建议先从最小白名单和回滚通道开始，再逐步收紧；如果你已经有现成规则，也可以考虑先做一次审计，把不再使用的来源和临时放行项清理掉。对于网站上线后的综合排障，可继续阅读 海外 VPS（虚拟专用服务器）常见技术问题汇总。这样做，通常比一次性把所有端口都改得更激进要安全得多。

建议你下一步先在测试环境复现一遍整个变更流程，确认能随时回退后，再把同样的步骤应用到生产机。