亚马逊云免实名 AWS亚马逊云防火墙优先级规则

各位在AWS上摸爬滚打的兄弟姐妹们，有没有过这种时刻——凌晨两点，咖啡凉透，监控告警狂跳，你手抖着点开Network Firewall控制台，确认自己清清楚楚写了条规则：拒绝所有去往192.168.5.100的ICMP，结果抓包一看，ping还是啪啪响，像在对你冷笑？

别急着删账号，也别怀疑人生——大概率不是你写错了，而是你被AWS Network Firewall那套「表面佛系、内里倔强」的优先级规则给温柔背刺了。

今天咱不念AWS官方文档（那玩意儿读三遍能治失眠），就坐办公室茶水间小马扎上，边啃饼干边把「防火墙优先级」这事掰开揉碎讲明白。保真，带梗，不绕弯。

一、先说个反直觉事实：AWS Network Firewall根本没“单条规则排序”这回事

你脑子里可能还存着传统防火墙的幻觉：规则从上到下一条条比，匹配就执行，不匹配就往下走，最后一行写个deny any any收尾，稳如老狗。

错！AWS Network Firewall压根不这么玩。它不按“第1条、第2条”编号执行，而是按规则组（Rule Group）类型 + 内部评估逻辑 + 状态跟踪阶段三重嵌套来决定谁先说话、谁后闭嘴。

你可以把它想象成一家火锅店：锅底分清汤、麻辣、番茄三口锅（对应STATEFUL/STATELESS/TPS规则组），每口锅里食材（规则）自己内部商量谁先烫熟，但三口锅之间，老板（Firewall引擎）有固定上菜顺序——清汤锅永远最先端上来，番茄锅垫底，麻辣锅……咳，看心情（其实是看配置优先级）。而你写的每条规则，只是某一口锅里的毛肚或金针菇，不是整桌宴席的主厨。

二、三大规则组：谁先动筷子？

1. Stateful Rule Groups（有状态规则组）——火锅店的“老主顾”，认人不认单
它记住连接状态：SYN来了记一笔，ACK回了打勾，FIN发了结账。规则基于source/destination port, protocol, application等维度，还能用Suricata规则语法写高级拦截（比如“检测HTTP User-Agent含sqlmap”）。
✅ 优先级：最高，最先评估入站/出站流量。
⚠️ 注意：它只处理已建立连接或新建连接的首包（SYN），后续包靠状态表直接放行/拒绝，根本不查规则——所以你改了规则，得等连接超时或重启才生效。别在生产环境改完就刷网页验证，那叫自我欺骗。

2. Stateless Rule Groups（无状态规则组）——门口保安，只看工牌不问去哪
不记状态，每个包独立判断。适合做快速兜底：比如“所有去10.0.0.0/8的UDP包一律DROP”。
✅ 优先级：中等，stateful之后、TPS之前。
⚠️ 注意：它支持priority字段（数字越小越优先），但这仅限于同一规则组内！跨规则组？不存在的。A规则组里priority=1的规则，永远干不过B规则组里priority=999的规则——因为B组压根排在A组后面执行。

3. TLS Inspection & TPS（Traffic Profiling Service）规则组——火锅店的“食材溯源员”，专盯加密流量
这是AWS新推的“高阶玩法”，用于解密TLS流量做深度检测（需配合证书部署）。
✅ 优先级：最低，最后才上场。
⚠️ 警告：启用TPS等于给防火墙加了个CPU黑洞，非刚需别开；且它只对TLS握手阶段的ClientHello有效，真加密数据流它也看不透——别幻想它能查微信聊天记录，它连微信用的是什么协议都懒得猜。

三、真正决定“谁赢”的，是这仨隐藏BOSS

BOSS①：规则组绑定位置
你在Firewall Policy里把Stateful规则组绑在INSIDE_TO_OUTSIDE方向，它就只管出站流量；绑在OUTSIDE_TO_INSIDE，才管入站。写了一堆阻断外网访问RDS的规则，却绑在出站方向？恭喜，规则在度假。

BOSS②：规则动作的“霸道程度”
同属一个Stateful规则组，drop永远碾压pass和forward_to_sns。哪怕pass规则写在前面，只要后面有drop匹配同一连接，结果就是：滴——连接终止。这不是“先到先得”，这是“后到者封神”。

BOSS③：Suricata规则里的flow:established等关键字
写规则时加了flow:to_server;，它只管客户端发包；加了flow:from_server;，只管服务端回包。你写了个“阻断恶意域名解析响应”，却忘了加from_server，那DNS响应包早溜进VPC了——而你还在日志里虔诚等待“BLOCKED”字样。

四、实战避坑指南（血泪版）

• 亚马逊云免实名 坑1：“我测试时通，上线就挂”→ 检查VPC Flow Logs！别信CloudWatch指标，它只统计“被拒绝的包数”，而stateful规则对已建立连接的后续包根本不计数。Flow Logs里找REJECT或ACCEPT字段，才是真相。
• 坑2：“写了deny all，还是有流量进来”→ Network Firewall默认策略是DEFAULT_ACTION = ALLOW！它不像本地iptables默认DROP。想兜底？得手动在Stateful规则组末尾加一条drop tcp any any -> any any (msg:"Block all";)，还得确保它没被更上面的pass规则提前放行。
• 坑3：“改了规则，流量没变”→ 记住：Stateful规则组修改后，必须点击“Deploy changes”（不是保存！），且旧连接不受影响。建议搭配aws network-firewall update-firewall-policy命令强制刷新，或者——最粗暴有效：重启Firewall（别笑，我们组真这么干过，十分钟换两小时排查）。

五、终极心法：画张图，比敲一百行CLI管用

下次配置前，拿张纸画三列：

1. 左列写流量方向（IN/OUT）
2. 中列按执行顺序写规则组类型（Stateful → Stateless → TPS）
3. 右列在每组里标出你的关键规则+动作（DROP/PASS）

然后模拟一个包：它先过哪组？匹配哪条？动作是什么？要不要继续往下走？——画完你就悟了：原来不是规则没生效，是你把它安排在了“火锅店打烊后”。

最后送句大实话：AWS Network Firewall不是万能盾牌，它是把需要你亲手调校的瑞士军刀。它的优先级逻辑不难，难的是放下“我写了就该管用”的执念，学会跟它的脾气共处。

毕竟，云上没有银弹，只有按时交社保的运维人，和永远在更新的AWS文档PDF。

（P.S. 如果看完这篇你还被优先级搞懵……欢迎私信，我请你喝杯冰美式，咱们一起远程连Console，边debug边吐槽。前提是你得备好截图，以及——足够的耐心。）