很多人买了阿里云服务器，第一件事是装系统、部署服务，等网站上线才发现外网端口几乎全开着。远程登录端口被扫描，数据库暴露在公网上，半夜收到异常流量告警。这些情况多数出在防火墙配置上。
这篇文章先理清阿里云服务器防火墙由哪几层组成，再用一个实际案例说明安全组怎么收紧，最后补充日常维护的做法。
阿里云防火墙的三层结构
配置前要先分清各层的职责，否则很容易在错误的地方改规则。
- 安全组：挂在ECS实例上的虚拟防火墙，控制实例的入方向和出方向流量。它是有状态的，放行的入站连接，回包会自动放行。
- 网络ACL：作用在VPC交换机层面的访问控制。规则无状态，入站和出站要分别配置，适合做子网级别的粗粒度隔离。
- 操作系统防火墙：如Linux上的firewalld、iptables或ufw，以及Windows自带的防火墙，是服务器内部的最后一道关口。
对大多数中小团队来说，日常打交道最多的是安全组。规则直观，改动即时生效，出了问题也好排查，所以下面的内容以安全组为主。
安全组怎么配
进入ECS控制台，找到实例所属的安全组，添加入方向规则时要填协议类型、端口范围、授权对象和优先级。
授权对象是最容易出错的一项。它可以是单个IP，可以是CIDR网段（例如203.0.113.0/24），也可以是另一个安全组。不少人图省事直接填0.0.0.0/0，等于全网都能访问这个端口。80和443对外开放是正常需求，但22（SSH）、3306（MySQL）、6379（Redis）如果也这样设，风险就很高。填之前先问一句：这个端口需要谁访问？能写成具体IP或安全组，就不要写全网。
优先级取值1到100，数字越小优先级越高，多条规则冲突时按优先级匹配。建议把精确的拒绝规则放在较高优先级，宽泛的放行规则放在后面，避免宽规则把本该拦住的流量放进来。
一个真实场景：从端口全开到收紧
某电商团队的运营小王接手了一台用于活动页面的阿里云ECS。前任同事调试时把安全组入方向规则全部设成了0.0.0.0/0，包括22和3306端口。小王没有察觉，活动上线两周后，服务器CPU长期占用偏高，登录日志里出现大量失败的SSH尝试。排查时发现数据库也被扫描过，好在数据库设置了强密码，没有造成数据泄露。
小王分三步处理。第一步，把22端口的授权对象改成公司固定办公网的出口IP，只允许这一个网段登录。第二步，删除3306端口的公网入站规则，数据库只接受同一VPC内应用服务器的访问，授权对象改为应用服务器所在的安全组。第三步，在服务器上启用firewalld，只放行必需的80和443端口，同时关闭密码登录，改用密钥登录。
改完之后，异常登录尝试明显减少。这件事的教训是，规则放宽之后很难被马上察觉，定期审计要比出事后补救可靠得多。
云防火墙适合什么场景
实例数量少时，手工维护安全组问题不大。实例多了，规则分散在不同安全组里，遗漏和不一致就会慢慢出现。这时可以考虑阿里云的云防火墙服务。它从互联网边界统一管理出入流量，支持基于域名和IP的访问控制策略，并能识别和拦截部分异常外连与已知威胁。
两者分工比较清楚：安全组负责实例级别的精细控制，云防火墙负责边界上的统一策略和威胁检测。先把安全组收紧，再按需要加上云防火墙，比指望某一层解决所有问题更稳妥。
日常维护的几条做法
- 远程管理端口（22、3389）不要对公网全开。优先固定办公网出口IP，或通过堡垒机访问，办公网IP变动时记得同步更新规则。
- 数据库、缓存、消息队列这类内部服务，只允许应用所在的安全组访问。上线前用外网端口扫描一次，确认它们没有暴露。
- 定期审计每个安全组的规则，删除已经不用的临时规则。每条规则加上备注，写清用途和负责人，半年后再看也知道它为什么存在。
- 开启操作日志和云监控，对异常流量和连续登录失败设置告警，告警要有人负责响应。
- 修改规则前先导出或记录当前配置，出问题时可以按记录快速回滚。
防火墙需要跟着业务一起调整。人员变动、新服务上线，规则都要重新看一遍。把最小权限原则落实到每一条规则上，很多常见问题都能在出事前避开。
