云服务器防火墙：这3条规则别乱开

云服务器防火墙设成「默认全拒」的人不多，设成「能通就行」的一大片。机器开出来第一件事，测网站能不能打开、SSH 连不连得上，通了就继续干活，规则从此没人再看第二眼。这不算懒，是压根没人提醒过——放行一条规则的成本是零，收回去的成本可能是停机半小时。下面这三条，是我这些年见过最常被随手打开的，代价往往要等出事那天才显出来。

云服务器防火墙最容易开错的三个位置

先把前提说清楚：防火墙本身不背锅。规则是人写的，写宽了它老老实实照做，一点都不带犹豫的。麻烦在于多数人只知道自己动过「安全组」，不知道系统里还有一层 iptables、firewalld 或者 ufw，两层各管各的，改了一层以为收工了，另一层还敞着。

还有一种情况是接手别人的机器。规则列表拉下来几十条，来源全是 0.0.0.0/0，没有备注没有日期，谁也不敢删，就这么一直挂着。所以下面讲的三条，你对照着自己那边看一眼就行，不用急着全改。

22 和 3389 写成 0.0.0.0/0，钥匙插在门上

Linux 的 22、Windows 的 3389，这两条对全网开放是最常见的默认写法。扫描和爆破脚本是 7×24 在跑的，没人盯你的机器不代表没人试。改法其实不复杂：来源限制成自己办公的固定 IP，或者先过跳板机、走内网，实在要移动办公，那就换非默认端口加密钥登录，把密码登录关掉。

顺带提一句，换端口只能减少噪音，挡不住真想进来的人，密钥和来源白名单才是硬菜。还有那种「我先开一会儿，配完就删」的，十分钟变十个月，我见过不止一次。

数据库端口放出去，是最顺手的那个错

3306、6379、27017 这几个，出事概率一点不比 SSH 低。场景都差不多：本地连不上，图省事直接在规则里加一条 0.0.0.0/0，测通了，然后就忘了。Redis 没设密码被人写进定时任务、MySQL 弱口令被拖库，这些不是都市传说。

规矩也就一条：数据库端口只对内网地址放行，外部要访问就走 SSH 隧道或者跳板机。确实需要直连的，加白名单，固定出口 IP。别拿「就测试一下」当理由拖到下周，拖着拖着就成常态了。

那条 any/any 的兜底规则最坑

规则是有顺序的，多数平台从上往下匹配，命中就停。你在最上面放一条「协议全部、端口全部、来源全部」的允许，下面写再多精细的拒绝都是白写。这种规则通常是排查网络问题时临时加的，问题解决了，规则留着，日子一长就成了隐形后门。

看到来源 0.0.0.0/0、协议 all、端口 all 这一条，先问自己一句：现在还需不需要它。需要的话，能不能缩到具体端口、具体来源。缩不了，至少记个到期时间。

改规则之前，先给自己留条退路

在远程会话里改 SSH 端口、调默认策略，然后重启服务——新规则要是把你自己也挡在外面，下一次就进不去了。稳妥点的顺序是：先把控制台自带的 VNC 或远程连接确认能登上，配置改动前打个快照，或者临时保留一条只对自己 IP 放行的 22 规则，等新规则验证没问题再删掉。

还有个常见坑：云平台安全组放行了新端口，系统里的 firewalld 没放，或者反过来。折腾半天以为是网络问题，其实是两层只改了一层。改完从外部实际连一次，别只看配置文件。

规则别只加不删，顺手起个名

过几个月再看那堆规则，没有备注根本分不清哪条干嘛用的。加的时候花十秒写清楚：给谁用、为什么开、什么时候该收。临时口子记个日期，回头清理。这不算洁癖，是给未来的自己省事——真出问题的时候，你需要的是一眼能读懂的列表，不是考古。

防火墙不是唯一那道门

规则收窄了也别觉得万事大吉。服务自己的鉴权、弱口令、过期的组件版本，这些防火墙一样管不了。该关的端口关掉，该改的默认密码改掉，登录日志偶尔翻一翻，比堆一堆规则实在。

回头扫一眼你的规则列表，能做到这几件事就差不多了：22 和 3389 不对全网开放；数据库端口只对内网；没有 any/any 的兜底允许；每条规则都能说出用途；改之前有快照或者带外通道。五条里中三条以上，说明你的云服务器防火墙至少不是敞着的。剩下的慢慢磨，别一次全改，改完自己进不去才是真麻烦。