AWS分销商 AWS亚马逊云服务器安全防火墙设置
别再让云服务器在互联网上‘裸泳’了
想象一下：你花了几百块租了一台AWS EC2实例，装好网站、搭好数据库，兴奋地敲下curl http://your-ip——页面秒开。但下一秒，你突然想起：这台机器的22端口（SSH）、3306端口（MySQL）、甚至8080端口（测试后台）……是不是正对着整个互联网咧嘴笑？没有锁门，没有窗帘，连个保安都没请——它不是云服务器，是云靶场。
很多人以为“买了云服务=自带安全”，结果某天收到AWS Abuse Team邮件：“检测到您的实例正在发起DDoS反射攻击”，或者发现MySQL日志里全是来自巴西、尼日利亚、哈萨克斯坦的暴力破解记录……这时候才翻文档，手抖着删安全组规则，像在拆一颗没说明书的炸弹。
其实，AWS早给你配好了两把‘数字门锁’：安全组（Security Group）和网络ACL（NACL）。它们不是可选项，是你云服务器真正的第一道、第二道、也是最关键的两道防线。今天不讲概念堆砌，只聊怎么用、怎么防、怎么踩坑后爬出来。
先搞清：安全组 ≠ 防火墙软件，它是‘状态化访问控制列表’
别被名字骗了。安全组（Security Group）不是你在Windows里右键打开的那个“Windows Defender 防火墙”。它不装在你的EC2系统里，也不吃CPU、不占内存——它运行在AWS底层网络层，是虚拟的、无状态感知的（等等，不对！它其实是有状态的！这点90%教程都讲反了）。
关键真相：安全组是有状态的入站/出站规则集合。你允许入站SSH（TCP 22），系统会自动放行对应的出站响应流量——你不用、也不能手动加一条“允许出站22”。同理，你开了入站HTTP（80），浏览器能连上，返回包自动放行。这就是“有状态”的魔法。
所以，安全组规则只需专注两件事：
✅ 入站（Inbound）：谁（IP/安全组）能通过哪个协议+端口连进来？
✅ 出站（Outbound）：这台机器自己能主动连出去哪儿？（默认全放行，但生产环境建议收紧）
实战：三步建一个‘靠谱’安全组
- 最小权限起步：新建安全组时，AWS默认给入站全拒绝、出站全允许。别手贱点“全部开放”！保持它干净。
- 只开必需端口：比如Web服务器，加一条：类型=HTTP，协议=TCP，端口=80，源=0.0.0.0/0（或更优：CloudFront IP段/ALB安全组）；再加一条HTTPS（443）。管理端口？千万别写0.0.0.0/0！用公司办公IP段（如218.76.123.45/32），或配SSH证书+跳板机。
- 出站也管住：删掉默认的“0.0.0.0/0”，改成：类型=All traffic，目标=你的RDS安全组ID（sg-xxxxxx）；再加一条DNS（UDP 53）指向AmazonProvidedDNS（169.254.169.253）——没它，yum update都会卡死。
网络ACL：安全组的‘冷面双胞胎’，但脾气完全相反
如果说安全组是“每台EC2的贴身保镖”，那网络ACL（Network ACL）就是子网门口的“值班武警”——它不认人，只认IP和端口，且无状态、按序匹配、显式拒绝。
举个栗子🌰：
你设了两条入站规则：#100 允许 80端口 from 0.0.0.0/0；#200 拒绝所有（隐式最后一条）。看起来没问题？错！如果某条#150规则写着“拒绝来自1.2.3.4的22端口”，它就会生效——因为ACL按编号从小到大执行，遇到第一条匹配就停，不管后面有没有“允许”。
更坑的是：ACL出入站规则完全独立，且必须显式写拒绝。它不会像安全组那样“默认拒绝”，而是“默认允许”（除非你手动加#1000规则拒绝0.0.0.0/0）。
什么情况下必须用ACL？
- 需要基于IP黑名单封掉某几个恶意段（如/24黑产IP）；
- 多层子网架构中，隔离开发/测试/生产子网间的横向流量；
- 满足等保/金融合规要求，强制实现“网络层双重过滤”。
⚠️ 记住：ACL是子网级的，改了会影响该子网下所有实例。调错可能全网失联——操作前务必留好堡垒机连接，或用Session Manager应急。
高频翻车现场：那些年我们写错的规则
❌ ‘22端口放开，方便我随时连’——然后凌晨三点被扫号脚本盯上
解决方案：禁用密码登录，强制使用SSH密钥；将22端口源IP锁定为公司出口IP或跳板机安全组；或直接关闭22，改用SSM Session Manager（免密、审计、无需开放端口）。
❌ ‘数据库和Web在同一台EC2，干脆安全组互相全通’
风险：一旦Web层被挂马，攻击者直接拖库。正确姿势：Web服务器安全组只允许出站连RDS安全组（sg-rds-prod）；RDS安全组入站只接受该Web安全组ID——用安全组ID代替IP，自动适配弹性IP/扩容实例。
❌ ‘我把出站全放开，反正不影响入站’
错！出站全开=你的服务器能主动连矿池、C2服务器、恶意域名。曾有客户因出站不限制，实例沦为肉鸡发垃圾邮件，导致EIP被Gmail拉黑，整套邮件系统瘫痪3小时。
上线前必查：你的防火墙健康自检清单
- 🔍 入站规则中，是否有任何一条源为
0.0.0.0/0且协议非80/443？如有，立刻改！ - AWS分销商 🔍 是否存在重复、冗余或已失效的规则？（比如旧测试IP还在白名单里）
- 🔍 出站规则是否收紧？至少限制：仅允许访问RDS、S3 VPC Endpoint、必要API网关、打Log的CloudWatch端点。
- 🔍 安全组是否绑定到所有相关资源？（Elastic Load Balancer、RDS、ElastiCache也要单独配）
- 🔍 是否开启VPC Flow Logs？它能帮你回溯“谁在什么时候连了哪个端口”，比日志更底层、更真实。
最后送你一句AWS老司机忠告
安全组不是“设一次就高枕无忧”的装饰品。它得随业务变：新接口上线要开新端口，第三方对接要加新IP段，团队扩张要更新办公IP……建议每月花15分钟做一次规则巡检，把它写进你的发布Checklist。毕竟，在云上，最贵的不是实例费，是被黑之后重搭环境、赔客户、补漏洞、写事故报告的那三天时间。
下次再看到控制台里那个灰扑扑的“Security Groups”菜单，别划走。点进去，删掉那条写着“Anywhere”的22端口规则——你离一个真正靠谱的云环境，只差这一次点击。
