出方向为什么也要管
安全组是有状态的双向规则集合：入方向放行后，这条连接的回包自动放行，但由实例主动发起的新连接由出方向规则决定。多数云厂商出方向默认全部允许，好处是省事，代价是实例一旦被入侵（Web 应用 RCE、依赖投毒、挖矿脚本），回连 C2 与外传数据都不受阻拦。收窄出方向的思路不是「拦住入侵」，而是「限制入侵成功之后还能做什么」。
基本信息
| 默认状态 | 出方向全部允许，规则量大时很容易漏放 |
|---|---|
| 有状态特性 | 已建立的连接回包自动放行，收窄出方向不会断掉入方向进来的会话 |
| 实施顺序 | 先用流日志观测真实外联 1-2 周，再按需放行，最后收尾 |
| 放行清单 | 内网段、软件源 80/443、VPC DNS 53、监控上报、对象存储 Endpoint |
| 组合手段 | 安全组 + NAT 网关 + 云防火墙，逐层收窄而非一次到位 |
典型使用场景
- 等保与合规要求落实最小权限出网，需要可审计的放行依据
- 安全事件处置：临时收窄出方向，掐断已确认失陷实例的外联通道
- 数据库与中间件子网：只允许向内网和备份目标出网，不允许直连公网
- 成本与合规审计：把出网统一到 NAT 网关后，流量和日志有集中落点
- 容器集群：节点需要拉镜像与更新软件源，收窄前必须把镜像仓库地址列入白名单
出方向收窄思路
出方向收窄思路
允许：10.0.0.0/8 内网全通 # 内网互访与数据库访问
允许：TCP 80/443 → 软件源、镜像仓库、对象存储 Endpoint # 更新与拉取
允许：UDP/TCP 53 → 本 VPC 内 DNS 地址 # 以本 VPC DNS 实际地址为准
允许：TCP 监控端口 → 监控与日志服务网段 # Agent 上报
拒绝：其余流量（默认拒绝收尾，注意规则优先级） # 先观测再收，一次只收一段收窄前后对照
| 维度 | 收窄前 | 收窄后 |
|---|---|---|
| 外联通道 | 任意目标任意端口，无清单 | 只放业务必需目标，有据可查 |
| 失陷后影响 | C2 回连与外传畅通 | 外联被限制，外传窗口显著变小 |
| 故障排查 | 出问题先怀疑业务代码 | 先怀疑漏放，需要有清单和日志 |
| 变更风险 | 改出方向基本不影响业务 | 改错会直接导致更新、上报、备份失败 |
最怕漏放业务依赖：先跑流日志观察一到两周真实外联，再分批收窄，每批只动一段并保留快速回滚路径。漏掉软件源会让 yum/apt 与镜像拉取整体失败，表现为「服务器还在跑但什么也装不上」。
规则语义各家不同：AWS 安全组只能配置允许规则，其余隐式拒绝；阿里云等厂商支持拒绝规则且拒绝优先于允许匹配。跨云照搬规则前先确认目标厂商是否支持拒绝语义，否则收尾规则会写不出来。