很多人买了阿里云ECS，先把服务跑起来，防火墙想起来的时候往往已经出事了。数据库端口被扫、服务器被挖矿，这类问题多半是从一条没删干净的规则开始的。阿里云防火墙配置大致分两层：每台实例自带的安全组，以及覆盖整个账号的云防火墙。两层各管一块，配好了基本够用。
先分清两种防火墙
安全组挂在实例网卡上，按端口、协议和来源IP决定放行还是拒绝。它免费，生效快，是每台服务器的第一道门。
云防火墙管的是互联网边界的流量，也能管VPC之间的访问。它可以统一下发访问控制策略，还能识别外连到恶意地址的行为。资产多、服务器分散的团队用它省事；只有一两台个人站点的话，安全组基本够用，不必为此多付一层成本。
第一步：配置安全组
进入ECS控制台，找到实例绑定的安全组，添加入方向规则。思路很简单：只放行业务需要的端口，来源尽量写到具体IP段，别图省事直接填0.0.0.0/0。
- 网站服务：TCP 80、443，来源0.0.0.0/0，这是对公网开放的部分。
- 远程登录：Linux填TCP 22，Windows填3389，来源只写办公室或家里的固定IP。动态IP的话，至少限制在运营商的常用网段内，并定期复查。
- 数据库和缓存：MySQL 3306、Redis 6379不对公网开放，只允许同一安全组内的应用服务器访问。
- 其余入方向规则全部删除，依靠默认拒绝兜底。
第二步：配置云防火墙
开通云防火墙后，先到资产列表确认哪些公网IP已经纳入防护。没有纳入的IP需要手动加进防护范围，否则后面配的策略对它不生效。这一步最容易被忽略，配置完看着没问题，实际有台机器根本没在保护里。
然后在访问控制页面新增策略，通常会这样安排：
- 出方向：阻断已知挖矿、恶意域名和常见矿池端口的外连。服务器突然往境外高位端口大量发包，多半就是这类问题。
- 入方向：开启入侵防御，对SQL注入、暴力破解这类攻击做拦截和告警。
- 策略顺序：拦截类规则要放在放行类规则前面，否则宽松的放行规则会先匹配上，拦截就形同虚设。
新策略建议先用“观察”或“告警”模式跑一两天，翻看日志里有没有误伤业务的记录。比如支付回调、第三方接口这类平时不显眼的请求，最容易被误判。确认没问题再切到“阻断”。
案例：一个小团队的实际修复
某电商团队有三台ECS，一台跑网站，一台跑订单服务，一台放MySQL。上线半个月后，运维发现数据库流量不对劲。查看安全组才发现3306对0.0.0.0/0开放了，是调试时临时加的，后来忘了删。
他们做了三件事。第一，删掉3306的公网规则，只允许订单服务器所在的安全组访问。第二，在云防火墙里看到其中一台服务器持续往境外矿池发起连接，于是加了出方向阻断，再排查服务器上被植入的脚本。第三，把运维的远程登录IP改成固定办公网段，22端口不再对全网开放。整个处理大约两个小时，之后三周没有再出现类似流量。
容易踩的坑
- 安全组是有状态的。放行入站之后，对应的出站回包会自动放行，不用为回包再配一条规则。
- 规则改完，用另一台机器实际连一下端口，别只看控制台上的显示。控制台显示放行，不代表链路真的通。
- 临时放开的端口，记得在规则描述里写清用途和到期时间，最好设个日历提醒。否则临时规则很容易变成长期漏洞。
- 控制台的菜单名称和功能会随版本调整，具体操作以阿里云官方文档为准。
