用 Bedrock AI 自动检测 Network Firewall 规则冲突：改完规则 2 分钟收到邮件告警

用 Bedrock AI 自动检测 Network Firewall 规则冲突：改完规则 2 分钟收到邮件告警

上周出了个事故——有人改了一条 Network Firewall 规则，结果把另一个 Rule Group 里的放行策略覆盖了。排查花了半天，最后发现是两条规则的 CIDR 范围有重叠。

问题在于 Network Firewall 本身没有规则冲突检测能力。你在一个 Rule Group 里写了 pass，另一个 Rule Group 里写了 drop，如果 IP 范围重叠，它不会告诉你。

直到生产环境的流量被误拦了才发现。

这篇介绍一个方案：用 EventBridge + Lambda + Bedrock 搭一套自动冲突检测，改完规则点 Save，2 分钟内收到邮件告诉你有没有冲突、严不严重、怎么改。

典型的冲突场景

先看三种常见的坑：

Rule Group A	Rule Group B	冲突类型	风险
pass icmp 10.1.1.0/24	drop icmp 10.1.0.0/16	CIDR 子集重叠	中
pass ip 1.1.1.1 → any	drop ip 1.1.1.1 → any	IP 策略冲突	高
ALLOWLIST .google.com	DENYLIST .google.com	域名策略冲突	高

第一种特别隐蔽——10.1.1.0/24 是 10.1.0.0/16 的子集，两条规则分属不同 Rule Group，优先级不同，最终行为取决于 STRICT_ORDER 模式下谁先匹配。

这种东西人工审查很难发现，尤其是 Suricata 规则、IP ACL、Domain List 三种格式混在一起的时候。

方案架构

整个链路是纯事件驱动，没有常驻服务：

用户修改 Rule Group → Save
    ↓
CloudTrail 记录 UpdateRuleGroup API
    ↓
EventBridge 匹配事件 → 触发 Lambda
    ↓
Lambda 执行：
  1. 获取所有 Rule Group 规则
  2. 查询哪些 Rule Group 已关联 Policy
  3. 代码做冲突检测（CIDR/端口/域名计算）
  4. 调用 Bedrock AI 分析冲突含义
  5. 生成 SVG 可视化图 → 存 S3
  6. 有冲突 → SNS 发邮件

核心设计原则：代码负责"发现冲突"，AI 负责"解释冲突"。

CIDR 是否重叠、端口是否重叠——这些确定性计算交给代码，准确又快。

但"这个冲突是有意的分层策略还是配置错误"、"风险多大"、"怎么改"——这些需要理解业务语义，交给 AI。

用到的服务

服务	角色
Network Firewall	被监控对象
CloudTrail	记录 API 调用
EventBridge	事件路由
Lambda	冲突检测引擎
Bedrock (Nova Pro)	AI 分析
S3	存放报告和 SVG 图
SNS	邮件通知

全 Serverless，按需计费。没冲突就不花钱。

冲突检测的核心逻辑

检测维度：

1. 协议匹配——相同协议或一方为 ip（全协议）
2. 源 IP 重叠——CIDR 子网计算 + 变量语义（$EXTERNAL_NET ≠ RFC1918）
3. 目标 IP 重叠
4. 端口范围重叠
5. 深度匹配条件——http.host、域名等
6. 动作冲突——只有动作不同（pass vs drop）才报冲突

关键的 CIDR 重叠检测代码：

import ipaddress

RFC1918_NETWORKS = [
    ipaddress.ip_network('10.0.0.0/8'),
    ipaddress.ip_network('172.16.0.0/12'),
    ipaddress.ip_network('192.168.0.0/16'),
]

def cidr_overlaps(cidr1, cidr2):
    """检查两个 CIDR 是否重叠，理解 Suricata 变量语义"""
    cidr1_lower = cidr1.lower()
    cidr2_lower = cidr2.lower()
    
    # 两个都是 any → 完全相同
    if cidr1_lower == 'any' and cidr2_lower == 'any':
        return 'exact'
    
    # $EXTERNAL_NET vs RFC1918 → 公网和私网不重叠
    if cidr1 == '$EXTERNAL_NET' or cidr2 == '$EXTERNAL_NET':
        other = cidr2 if cidr1 == '$EXTERNAL_NET' else cidr1
        if is_rfc1918(other):
            return 'none'
        return 'possible'
    
    # 标准 CIDR 计算
    net1 = ipaddress.ip_network(cidr1, strict=False)
    net2 = ipaddress.ip_network(cidr2, strict=False)
    
    if net1 == net2:
        return 'exact'
    elif net1.subnet_of(net2):
        return 'subset'
    elif net2.subnet_of(net1):
        return 'superset'
    elif net1.overlaps(net2):
        return 'partial'
    else:
        return 'none'

这里有个重要细节：$EXTERNAL_NET 通常定义为"非 RFC1918"（即公网），所以 $EXTERNAL_NET vs 10.1.1.0/24 不算重叠。不处理这个语义会产生大量误报。

AI 分析的 Prompt 设计

代码发现冲突后，把冲突信息喂给 Bedrock Nova Pro，让它做三件事：

1. 意图分析——判断是有意的分层设计还是配置错误
2. 风险评估——评估业务影响
3. 修复建议——给出调整方向（不输出具体语法，避免误导）

举个例子，AI 看到这样的冲突：

• Rule Group A（优先级高）：pass icmp 10.1.1.0/24
• Rule Group B（优先级低）：drop icmp 10.1.0.0/16

AI 的分析：

"这是 CIDR_SUBSET_OVERLAP 类型冲突。在 STRICT_ORDER 模式下，10.1.1.0/24 的 ICMP 流量先命中 Rule A 被放行，10.1.0.0/16 中其他子网的流量落到 Rule B 被拒绝。这种'大范围拒绝 + 小范围例外'模式通常是有意设计的分层策略，风险中等。"

AI 理解了优先级语义，不会把所有冲突都标红。

EventBridge 事件规则

{
  "source": ["aws.network-firewall"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["network-firewall.amazonaws.com"],
    "eventName": ["UpdateRuleGroup", "CreateRuleGroup"]
  }
}

只监听 Rule Group 的创建和修改，其他操作不触发。

Lambda 核心流程

import boto3
import json

nfw_client = boto3.client('network-firewall')
bedrock = boto3.client('bedrock-runtime')

def lambda_handler(event, context):
    # 1. 获取所有 Rule Group
    rule_groups = get_all_rule_groups()
    
    # 2. 过滤出已关联 Policy 的
    active_groups = filter_active_groups(rule_groups)
    
    # 3. 逐对比较，找冲突
    conflicts = detect_conflicts(active_groups)
    
    if not conflicts:
        return {"statusCode": 200, "body": "No conflicts"}
    
    # 4. 调用 Bedrock 分析
    ai_analysis = analyze_with_bedrock(conflicts)
    
    # 5. 生成 SVG 可视化 → 存 S3
    svg_url = generate_visualization(conflicts)
    
    # 6. 发邮件
    send_notification(conflicts, ai_analysis, svg_url)
    
    return {"statusCode": 200, "body": f"Found {len(conflicts)} conflicts"}

部署方式

整套方案用 CloudFormation 一键部署：

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  ConflictDetectionFunction:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: python3.12
      Timeout: 300
      MemorySize: 512
      Environment:
        Variables:
          BEDROCK_MODEL_ID: amazon.nova-pro-v1:0
          SNS_TOPIC_ARN: !Ref AlertTopic
          S3_BUCKET: !Ref ReportBucket

  EventRule:
    Type: AWS::Events::Rule
    Properties:
      EventPattern:
        source: ["aws.network-firewall"]
        detail-type: ["AWS API Call via CloudTrail"]
        detail:
          eventName: ["UpdateRuleGroup", "CreateRuleGroup"]
      Targets:
        - Arn: !GetAtt ConflictDetectionFunction.Arn
          Id: ConflictDetector

  ReportBucket:
    Type: AWS::S3::Bucket
    Properties:
      LifecycleConfiguration:
        Rules:
          - ExpirationInDays: 90
            Status: Enabled

  AlertTopic:
    Type: AWS::SNS::Topic

报告 S3 自动 90 天过期，不会无限积累。

实测效果

三种冲突场景测试结果：

场景	检测结果	耗时	邮件
Suricata CIDR 子集重叠	✅ 正确识别	~90秒	✅
IP ACL 完全重叠	✅ 标记高风险	~80秒	✅
Domain List ALLOW/DENY 冲突	✅ 标记高风险	~85秒	✅
无冲突修改	✅ 静默不告警	~30秒	❌（不打扰）

从点 Save 到收到邮件，全程 1-2 分钟。邮件里包含：

• 冲突摘要
• AI 的意图分析 + 风险评估 + 修复建议
• S3 链接指向 SVG 可视化图

几个设计决策

为什么不直接让 AI 做 CIDR 计算？

试过。AI 在 CIDR 子网计算上偶尔会犯错（特别是子集关系），用 Python 的 ipaddress 模块绝对准确。代码做确定性计算，AI 做需要推理的部分——分工明确，误报率低。

为什么只检测已关联 Policy 的 Rule Group？

没关联 Policy 的 Rule Group 还没生效，检测了也没意义。减少噪音。

为什么用 Nova Pro 而不是 Claude？

这个场景输入输出都不大（几百行规则文本 + 分析报告），Nova Pro 够用且成本更低。如果规则量特别大（上千条），可以换 Claude Sonnet。

总结

核心思路：

1. 纯事件驱动——改规则才触发，没有轮询开销
2. 代码做发现，AI 做解释——各干各的活
3. 有冲突才告警，无冲突不打扰
4. Serverless 架构——不改规则就零成本

对于管理多个 Rule Group 的团队，这套方案能在冲突进入生产之前就抓住它。比事后排查半天强多了。

---

素材来源：亚马逊云科技官方博客 — Network Firewall 部署小指南（六）利用 Bedrock AI 实现规则冲突检测
相关服务：AWS Network Firewall | Amazon Bedrock