红队 / 蓝队：用 AI 自动生成攻击场景并评估防御效果——从“安全演练”到“可计算的网络对抗系统”

引言：从“经验驱动”到“算力驱动”的安全革命

在可编程网络与 IaC（基础设施即代码）深度普及的今天，网络架构的复杂程度早已超越了人力静态审计的极限。然而，我们对网络安全的验证，却仍旧依赖于每年一两次、高度依赖专家经验的“红蓝对抗演练”。

这种模式下，安全是**“离散的事件”，而非“连续的属性”**。

当网络配置可以在分钟级发生变更时，我们需要一套能够与网络工程流水线对齐、可计算、且具备自我进化能力的对抗系统。本文将深度探讨如何利用 AI 建立一套自动化红蓝对抗闭环，将安全演练从一种“部门级活动”，转化为网络系统内生的“免疫工程”。

1、为什么传统网络安全演练，在工程层面是“不可持续的”

在大多数企业里，“红队 / 蓝队演练”这件事，本质上仍停留在事件型、安全部门主导的活动：

• 一年做一两次
• 攻击路径靠人设计
• 防御效果靠专家复盘
• 结论停留在 PPT，而不是配置

从网络工程视角看，这种模式有三个根本问题。

1.1 攻击路径是“经验产物”，不可复用、不可覆盖

传统红队攻击链通常是：

• 基于专家经验
• 参考过往漏洞或某次事故
• 手工拼接成 1–2 条“看起来合理”的路径

但网络是一个状态空间极大的系统：

• VLAN / VRF / Zone 的组合
• ACL / FW / IPS 的交叉作用
• 东西向 + 南北向流量叠加
• 真实拓扑与文档永远不一致

结果就是：

演练覆盖的是“人能想到的攻击”，而不是“网络真实暴露的攻击面”。

1.2 防御评估是“定性描述”，而不是工程指标

你经常会看到这样的结论：

• “防火墙规则需要优化”
• “日志告警不够及时”
• “部分攻击未被检测到”

但作为网络工程师，你真正需要的是：

• 哪一条规则未命中
• 哪一个 Flow 采样点缺失
• 哪一类攻击在拓扑中存在系统性盲区

没有量化，就无法自动化，更无法持续改进。

1.3 攻防演练与网络配置系统是割裂的

最致命的一点是：

演练的结论，几乎从不直接进入网络配置系统。

• 没有 diff
• 没有回滚策略
• 没有验证流水线

这意味着：下一次演练，很可能还会暴露同样的问题。

2、工程目标：把“攻防演练”变成一个可计算系统

在这一篇里，我们讨论的不是“AI 能不能打攻击”，而是一个工程问题：

能否把红队 / 蓝队演练，变成一个
可生成、可评估、可回放、可演进的网络系统？

为了做到这一点，必须明确几个设计目标。

2.1 攻击不是“自由生成”，而是“受约束的推理”

AI 在这里不能像写小说一样生成攻击步骤，它必须被严格约束：

• 攻击行为来自已知技术库
  • MITRE ATT&CK
  • 厂商漏洞库
  • CCIE / HCIE Security 实验模型
• 攻击路径必须：
  • 满足拓扑可达性
  • 满足协议与策略约束
  • 能被流量、日志观测到

换句话说：

AI 的工作不是“创造攻击”，而是在真实网络约束下组合攻击链。

2.2 防御评估必须输出“工程指标”

蓝队侧的输出，不是“感觉安全性提升了”，而是：

• 检测覆盖率
• 告警延迟
• 误报 / 漏报比
• 受影响的网络路径

这些指标必须：

• 可重复计算
• 可对比
• 可作为自动化决策输入

2.3 攻防结果必须能反向驱动配置演进

最终目标是这一句：

一次攻防演练，应该直接产生“可执行的网络改进建议”。

不是建议文档，而是：

• ACL / FW / IPS 的 diff
• Telemetry / Flow 的补点建议
• 策略顺序或粒度的调整

3、整体架构：一个“AI 驱动的攻防演练流水线”

在工程实现上，我们可以把整个系统拆成五个阶段：

网络状态输入

   ↓

攻击面建模（Attack Surface Model）

   ↓

攻击路径生成（AI 推理）

   ↓

防御检测评估（日志 / Flow / Telemetry）

   ↓

配置改进建议与验证

这一篇，我们先把前半部分（红队侧）彻底讲清楚。

4、红队侧第一步：网络攻击面的工程建模

AI 不能直接“看网络”，你必须先把网络变成一个可推理的模型。

4.1 最小攻击面模型（Minimal Attack Surface Model）

在工程实践中，我通常抽象四类核心对象：

Node        ：设备 / 主机 / 服务

Edge        ：可达路径（L2/L3/L4/L7）

Policy      ：ACL / FW / IPS / NAT / Zone

Capability  ：攻击与防御能力

示意结构（简化）：

class NetworkNode:

    def __init__(self, name, role, zone, criticality=1.0):

        self.name = name

        self.role = role # e.g., "JumpServer", "DB", "UserPC"

        self.zone = zone

        self.criticality = criticality # 影响风险评分的权重

        self.vulnerabilities = [] # 存储 CVE 编号、弱口令风险等

        self.services = [] # 运行的服务及版本


class NetworkEdge:

    def __init__(self, src, dst, protocol, port):

        self.src = src

        self.dst = dst

        self.protocol = protocol

        self.port = port


class SecurityPolicy:

    def __init__(self, rule_id, src_zone, dst_zone, action):

        self.rule_id = rule_id

        self.src_zone = src_zone

        self.dst_zone = dst_zone

        self.action = action

这些对象并不复杂，但它们有一个关键作用：

把“网络是否能被攻击”这个问题，从经验判断，变成图可达性问题。

4.2 攻击能力的结构化表达

攻击并不是一句“扫描端口”，而是具备前置条件的动作。

例如：

{

  "technique": "Lateral Movement via SMB",

  "requirements": {

    "protocol": "TCP",

    "port": 445,

    "auth": "weak_or_reused_credentials"

  },

  "observable": {

    "flow": true,

    "log": ["Windows Event 4624"]

  }

}

这一步非常重要，因为它决定了后续：

• AI 能否判断攻击是否“可行”
• 蓝队是否理论上能检测到

5、AI 在红队侧真正做的事：攻击路径推理

到这里，AI 才真正登场。

5.1 输入给 AI 的，不是“让它想攻击”，而是一个约束问题

一个典型的 Prompt（示意）是这样的：

你是一个网络安全推理引擎。

已知：

1. 网络拓扑节点与可达路径如下：

   - VLAN10 → FW → VLAN30

   - VLAN30 → Core → Internet

2. 安全策略：

   - FW 允许 TCP/443

   - FW 拒绝 TCP/445

3. 可用攻击技术：

   - HTTPS Command & Control

   - DNS Tunneling

   - SMB Lateral Movement（需 TCP/445）


问题：

在不违反策略的前提下，生成从 VLAN10 到 Internet 的攻击路径，并说明每一步可观测点。

必须遵循以下逻辑顺序：

    拓扑层（L3）：Src 是否能 Ping 通 Dst？
    策略层（L4）：Firewall 是否允许该 Port？
    技术层（L7）：在该协议上是否存在可利用的技术（如 HTTPS 上的 C2）？

AI 的输出不是随意的步骤，而是受限于：

• 策略是否允许
• 拓扑是否可达
• 攻击前置条件是否满足

“AI 输出的每一步攻击必须附带 Validation_Rule。例如：如果攻击步骤是横向移动，则必须引用拓扑模型中的 NetworkEdge 实例。”

5.2 攻击路径输出（伪示例）

攻击路径 A：
1. VLAN10 主机 → FW → Internet

   - 使用 HTTPS C2 通道（TCP/443）

   - 可观测：FW session log，NetFlow

2. 通过 DNS Tunneling 维持通信

   - 可观测：DNS 查询频率异常

注意这里：

• SMB 横向移动 被自动排除
• 原因不是“AI 觉得不安全”，而是策略不可达

这正是 AI 推理的价值所在。

5.3再来一个prompt

角色设定：你是一个高级网络安全推理引擎，擅长基于图论和 MITRE ATT&CK 框架进行路径分析。

任务约束：

    物理约束：如果 NetworkEdge 中不存在 protocol 和 port 的放行，禁止生成该路径。
    前置依赖：执行动作 B 必须先满足动作 A 的结果（如：必须先通过漏洞获得 User 权限，才能进行横向移动）。
    可观测性声明：每一步必须标注其产生的流量特征（Flow）、日志（Log）或遥测信号（Telemetry）。

输入数据（JSON 格式）：

    Topology: {节点、链路、ACL 规则}
    Vulnerabilities: {节点已知漏洞、开放服务}
    Threat_Model: {攻击目标，如：获取 DB 权限}

推理步骤： Step 1: 分析源到目的地的三层（L3）连通性。 Step 2: 匹配四层（L4）策略，剔除被拒绝的端口路径。 Step 3: 在可用路径上匹配 MITRE 技术，验证漏洞的可利用性。

输出格式要求： 必须返回一个结构化的攻击链列表，包含 path_id, technique, viability_score (0-1), 以及 observables。

6、从“单一路径”到“攻击覆盖率”

工程上，我们不会只生成一条攻击路径。

6.1 攻击场景的参数化扩展

AI 可以在约束条件内，生成一组变体：

• 不同协议
• 不同时间窗口
• 不同源节点

场景族 B：

- HTTPS C2 + 低频心跳

- HTTPS C2 + 突发流量

- DNS Tunneling + 随机子域

这些并不是“新攻击”，而是：

对同一攻击面的不同覆盖方式。

6.2 输出结果的工程形式

最终红队侧输出的，不是“报告”，而是一份可执行攻击清单：

{

  "scenario_id": "C2-HTTPS-LOWFREQ",

  "path": ["VLAN10", "FW", "Internet"],

  "expected_observable": {

    "flow": true,

    "fw_log": true,

    "dns_log": false

  }

}

这份结构化结果，将直接作为下一阶段——蓝队评估系统的输入。

7、蓝队的工程现实：不是“能不能拦住”，而是“拦在哪、慢在哪”

在多数企业里，蓝队的工作被简化成一个问题：

这次攻击有没有被拦住？

但对网络工程而言，这个问题几乎没有工程价值。

因为真正决定系统安全性的，从来不是“有没有一次成功拦截”，而是：

• 是否存在结构性盲区
• 检测是否依赖偶然条件
• 告警是否来得足够早
• 防御动作是否可自动复现

所以在攻防演练系统中，蓝队的首要目标不是“防住”，而是把防御能力变成可计算对象。

8、蓝队评估的最小输入：攻击场景 + 可观测声明

从 Part 1 输出的攻击清单中，蓝队拿到的并不是“攻击脚本”，而是这样一份结构化描述：

{

  "scenario_id": "C2-HTTPS-LOWFREQ",

  "path": ["VLAN10", "FW", "Internet"],

  "expected_observable": {

    "flow": true,

    "fw_log": true,

    "dns_log": false

  }

}

这一步非常关键，因为它意味着：

蓝队评估的不是“有没有日志”，而是“是否满足预期可观测性”。

换句话说：
如果一个攻击理论上可被观测，但现实中没看到，那就是防御失败。

9、防御评估的核心对象：Detection Point（检测点）

在工程上，我通常把蓝队的检测能力抽象成一组 Detection Point。

9.1 Detection Point 的定义

class DetectionPoint:

    def __init__(self, name, source, signal_type, latency_threshold):

        self.name = name

        self.source = source          # FW / IDS / Flow / Syslog / Telemetry

        self.signal_type = signal_type

        self.latency_threshold = latency_threshold

示例：

fw_session_log = DetectionPoint(

    name="FW_SESSION_LOG",

    source="firewall",

    signal_type="session",

    latency_threshold=2.0  # 秒

)

这些检测点本质上是：

• 日志
• 流量采样
• 遥测指标
• 行为告警

但在系统中，它们被统一为可评估节点。

10、第一个工程指标：检测覆盖率（Detection Coverage）

10.1 定义

在理论可观测的攻击步骤中，实际被检测到的比例。

公式可以非常朴素：

Detection Coverage = Detected Steps / Observable Steps

10.2 示例计算

假设一个攻击场景包含 4 个理论可观测步骤：

步骤	理论可观测	实际检测
HTTPS 会话建立	是	是
C2 心跳	是	否
DNS 隧道	否	-
长连接维持	是	是

则：

Coverage = 2 / 3 ≈ 66.7%

这个指标的意义在于：

它直接暴露“你以为你能看到，但实际上看不到”的部分。

11、第二个工程指标：检测延迟（Detection Latency）

11.1 为什么延迟比“有没有告警”更重要

很多攻击最终都会被发现，问题是：

• 30 秒后发现
• 30 分钟后发现
• 3 天后发现

在真实入侵中，这三者的结果完全不同。

11.2 延迟计算模型

latency = detection_timestamp - attack_start_timestamp

然后与 Detection Point 中定义的阈值对比：

if latency > dp.latency_threshold:

    mark_as_delayed(dp)

输出可以非常直接：

C2-HTTPS-LOWFREQ：

- FW session log：1.2s（合格）

- Flow anomaly：18s（超时）

- DNS log：未检测

11.3检测鸿沟分析

不仅计算 Coverage，还要识别“虽然有日志，但无法触发告警”的情况。

• Impact: 受影响节点的 criticality。
• Probability: 攻击路径的复杂度。
• 优化目标：通过提升 DetectionCoverage 和降低 Latency 来压低整体风险分。

12、第三个工程指标：误报 / 漏报的结构性分析

传统安全系统常见一个问题：

为了提高检测率，把阈值调得很低。

结果是：

• 告警数量爆炸
• 工程师开始忽略告警
• 真正的攻击被淹没

12.1 用 AI 做告警语义归并

这里 AI 的价值不在“发现攻击”，而在理解告警含义。

示意流程：

原始告警 → 向量化 → 相似度聚类 → 语义合并

简单示例（伪代码）：

alerts = embed_alerts(raw_alerts)

clusters = cluster(alerts, threshold=0.85)

结果可能是：

原始告警：327 条

语义事件：5 个

这一步直接决定了蓝队是否可持续运作。

13、一个完整的企业级攻防演练案例（简化版）

13.1 网络背景

• VLAN10：办公终端
• VLAN30：服务器区
• 出口防火墙：允许 TCP/443
• 已部署：
  • 防火墙日志
  • NetFlow
  • DNS 日志（仅出口）

13.2 红队生成的攻击场景

{

  "scenario_id": "C2-HTTPS-BURST",

  "expected_observable": {

    "flow": true,

    "fw_log": true,

    "dns_log": false

  }

}

13.3 蓝队评估结果

指标	结果
覆盖率	66%
平均延迟	14s
漏检点	HTTPS 心跳阶段
根因	Flow 采样粒度过低

13.4 AI 给出的配置改进建议

建议：

1. 提高 VLAN10 → FW 的 Flow 采样率

2. 对长连接 TCP/443 增加 session 行为分析

注意，这里不是“建议加强监控”，而是具体到配置动作。

14、从评估到演进：把攻防演练接入配置流水线

这一步，才是整个系统的闭环。

14.1 改进建议的工程输出形式

# 示例：针对检测盲区的自动化建议

improvement_action:

  type: TELEMETRY_ENHANCEMENT

  target_device: "Core-Switch-01"

  action: "INCREASE_NETFLOW_SAMPLING"

  parameters:

    interface: "VLAN10_Gateway"

    old_rate: 4096

    new_rate: 512

  logic: "Detected potential C2 burst traffic bypass in Scenario C2-HTTPS-BURST"

14.2 验证方式

• 沙箱回放攻击场景
• 重新计算覆盖率 / 延迟
• 只要指标改善，才允许进入生产

15、为什么“演练”必须进入网络工程流水线

到目前为止，我们已经解决了三个问题：

• 攻击是可生成的
• 防御是可量化的
• 改进是可配置化的

但如果这些能力停留在离线系统里，那么它仍然只是一个“高级演练工具”，而不是工程体系的一部分。

真正的分水岭在这里：

攻防演练是否能像配置校验、回归测试一样，成为“每次变更前的必经步骤”？

16、攻防演练在网络 CI/CD 中的真实位置

在成熟的网络工程体系中，一次变更至少会经过：

配置生成

→ 静态校验

→ 拓扑 / 策略仿真

→ 回归测试

→ 发布

AI 攻防演练应当插入的位置，并不是最前，也不是最后，而是这里：

拓扑 / 策略仿真

→ 攻防演练（Near-term）

→ 回归测试

16.1 为什么是 Near-term 攻防，而不是“全量攻击”

原因很现实：

• 你不是在“评估企业是否绝对安全”
• 你是在判断：这一次变更，是否引入了新的攻击面

所以攻击范围必须被约束为：

• 与本次变更路径相关
• 与本次变更策略相关
• 与本次变更对象相关

这正是 Near-term 的含义。

16.2负反馈阻断

明确流水线的“熔断（Kill-switch）”条件：

1. 如果在仿真环境中，新增变更导致“核心资产路径”的 Detection Coverage 下降超过 15%，或者 Risk Score 突破阈值，流水线必须强制失败（Hard Fail），严禁进入生产环境。

17、一次真实的流水线执行示例

17.1 变更背景

• 新增一条策略：
  • VLAN20 → Internet 允许 TCP/443
• 目的：
  • 支持新 SaaS 服务

17.2 流水线自动触发的攻防检查

Step 1：拓扑 / 策略差异分析

Step 2：识别新增可达路径

Step 3：生成 Near-term 攻击场景

Step 4：蓝队评估

Step 5：给出风险评分

17.3 AI 生成的 Near-term 攻击关注点

{

  "change_context": "ALLOW_VLAN20_HTTPS",

  "derived_risks": [

    "HTTPS C2 新出口",

    "长连接绕过传统 DNS 监控"

  ]

}

18、风险评分不是“打分”，而是决策信号

在工程上，风险评分不是用来吓人的，而是用来自动决策的。

18.1 一个可用的评分模型（示意）

risk_score = (

    exposure_weight * new_attack_surface +

    detection_gap_weight * (1 - coverage) +

    latency_weight * avg_latency

)

输出不是“高 / 中 / 低”，而是：

Risk Score = 0.73

Policy Threshold = 0.6

→ 阻断自动发布，要求补充防御配置

19、AI × AI 对抗：为什么一定会失控

当很多人第一次听到“用 AI 做红队 / 蓝队”时，都会有一个下意识反应：

那会不会变成 AI 攻 AI、无限升级？

答案是：如果你不做工程约束，一定会。

20、三种必然失控的模式（反模式）

20.1 反模式一：无约束攻击生成

• 攻击不基于真实拓扑
• 攻击不考虑观测点
• 攻击目标是“突破系统”

结果：

红队 AI 会生成永远无法验证的攻击。

20.2 反模式二：蓝队无限加规则

• 每次检测不到，就加规则
• 不考虑误报
• 不考虑运维成本

结果：

防御系统变成不可维护的噪声机器。

20.3 反模式三：让 AI 自行“博弈优化”

• 红队 AI 提升成功率
• 蓝队 AI 提升检测率
• 没有工程边界

结果：

系统开始优化“数学指标”，而不是“网络安全”。

21、工程解法：把 AI 关进“网络物理规则”里

真正可落地的体系，必须遵守三条硬约束。

21.1 攻击只能来自已知技术库

• MITRE
• 厂商公告
• 实验室验证过的攻击模型

AI 不允许发明攻击。

21.2 防御只能作用于真实配置点

• 规则
• 采样
• 日志
• 遥测

不允许“虚拟防御能力”。

21.3 所有优化必须可回滚

任何一次 AI 建议的防御调整，必须满足：

可解释

可 diff

可回滚

否则，它就不应该进入生产。

22、这套体系真正适合谁，不适合谁

22.1 非常适合的场景

• 大中型企业网络
• 多区域 / 多出口
• 防火墙 / SD-WAN / 云边界并存
• 已有 NetFlow / Telemetry 基础

22.2 明确不适合的场景

• 小型网络
• 靠单台防火墙“兜底”
• 没有日志 / 流量基础
• 希望“一套 AI 自动防一切”

23、你真正建立的，不是红蓝对抗，而是“自我免疫系统”

走到这里，可以把整篇第 28 篇用一句话收束：

这不是一套“对抗系统”，而是一套网络的自我免疫机制。

• 攻击不是为了入侵
• 防御不是为了炫技
• 演练不是为了报告

而是为了让网络：

• 知道自己暴露在哪里
• 知道自己反应有多慢
• 知道如何在下一次变更中变得更好

结语：安全是网络演进的“性能指标”，而非“补丁”

当我们把红蓝对抗拆解为可计算的攻击路径、可量化的检测指标以及自动化的配置闭环时，我们实际上完成了一场安全观的范式转移。

在这种新范式下，安全性不再是一个“有没有漏洞”的二元论命题，而是一个类似于带宽、时延、丢包率的工程性能指标。通过 AI 驱动的自动化评估，我们能够量化每一行 ACL、每一次路由变更带来的风险分值。

未来的网络，将不再是一个等待被攻击的静态靶场，而是一个在 AI 持续对抗中自我修补、自我增强的动态生命体。这种从“事后复盘”到“实时免疫”的进化，正是网络工程通往高可靠性未来的必经之路。

（文：陈涉川）

2025年12月24日