前阵子有个做小程序的朋友来找我，说服务器部署好了却怎么也连不上。折腾了一下午，他在阿里云控制台里把安全组直接改成了“允许所有端口、所有来源”，连上了，心里松了口气。两天后他发现服务器CPU常年压在90%以上，机器上多了一个陌生进程，已经在替别人挖矿。
这种事并不少见。连不上时先全开再说，是很多人的本能反应。但在阿里云上开放所有端口，等于把服务器的门敞开，公网上任何人都能来敲。
开放所有端口具体指什么
ECS能不能被外部访问，主要看安全组规则。所谓开放所有端口，通常是在入方向加一条规则：端口范围设为全部（-1/-1 或 1-65535），授权对象填 0.0.0.0/0，意味着全网任何IP都能访问。
规则本身一看就懂，麻烦在后果。SSH的22端口、远程桌面的3389、MySQL的3306、Redis的6379，全都直接暴露在公网上。
为什么会有人这么做
原因大多很朴素：
- 服务访问不了，不确定是哪个端口没开，干脆全开排查。
- 对安全组不熟，觉得多开几个端口应该没什么影响。
- 临时测试一下，之后忘了关，规则就一直留着。
最后一种最危险。“临时”二字说出口很容易，真要记得回头关掉，却没那么容易。
全开之后会发生什么
公网上一直有自动化扫描程序在找开放端口。服务器一旦全开，被探测到往往只是几分钟到几小时的事。常见的后果有几类：
- 弱密码被爆破：SSH或远程桌面如果密码简单，很快会被暴力破解。
- 数据库裸奔：MySQL、Redis没有强认证的话，数据可能被直接下载、删除或改写。
- 挖矿程序：机器失守后，常被植入挖矿程序占满CPU，账单也会跟着涨。
- 横向渗透：一台机器被攻破，攻击者可能借此摸进同一VPC里的其他资源。
还要注意一点：云厂商提供的是基础设施和安全能力，系统账号、密码和应用配置仍然需要使用者自己把关。安全组放行得再精细，弱密码照样是漏洞。
更稳妥的做法：只开需要的端口，并限定来源
其实排查连接问题用不着全开。思路很简单：只开业务真正需要的端口，并尽量限定来源IP。
- 先在服务器上用
ss -tlnp或netstat -tlnp确认服务实际监听的端口，很多时候问题只是端口写错了。 - 只为该端口添加入方向规则。网站一般只需要放行 80 和 443。
- SSH端口不要对 0.0.0.0/0 开放，改成只允许办公网或固定运维IP访问。
- 数据库和Redis这类内部服务，只对应用服务器所在的内网网段开放，不要暴露到公网。
- 每条规则都写清楚用途和负责人。半年后没人记得为什么会有这条规则，备注就是最好的线索。
另外可以开通阿里云安全中心，定期看风险项和异常登录告警。这样出问题时能及时发现，不用等到账单异常才反应过来。
已经全开了，怎么补救
- 马上把“全部端口、0.0.0.0/0”的规则改成只放行必要端口，不确定用途的直接删除。
- 检查登录记录，确认有没有陌生IP登录成功过。
- 查看进程列表和定时任务，重点留意CPU占用异常的进程。
- 修改服务器账号密码，关闭密码登录，改用密钥认证。
- 如果数据敏感，或者已经确认被入侵，先备份重要数据，再重装系统，从干净环境恢复服务。
回到开头那位朋友，他最后的做法就是关掉全开规则、重装系统、换成密钥登录，并把数据库只开给内网。前后折腾了一个周末。当初花十分钟把安全组配对，本来能省下这些时间。
所以遇到访问不通，先看日志和安全组规则，找到具体端口，精确放行。全开只是把问题推迟，代价可能更大。
