用于进攻性网络安全的智能体 AI——内网与 PCI 分段测试

数据智能老司机
0 阅读30分钟

本章聚焦于内网分段（internal network segmentation） 在实践中如何被测试，尤其是在受 PCI-DSS 要求约束的环境中。

以我为 PCI 合规组织做渗透测试的经验来看，分段（segmentation） 是最常被错误配置的控制项之一。很多团队以为边界是有效的，直到一次真实测试把问题暴露出来。我们不会把分段仅仅当作架构或合规驱动的概念来讨论，而是从进攻性安全视角出发，检验分段控制在更贴近真实的内网攻击场景下到底能撑到什么程度。

通过具体示例以及用 n8n 构建的轻量自动化工作流，本章展示了如何让分段测试变得结构化、可重复、可落地，而无需引入不必要的复杂度。目标是帮助你理解的不仅是“分段是否存在”，更是“在真实条件下，它是否真的限制了横向移动（lateral movement）”。

我们将从 PCI-DSS 的基础概念入手，解释为什么分段的意义不止于合规。随后，我们会走一遍传统分段测试的做法：使用 Nmap，并针对 TCP SYN 扫描、TCP CONNECT 扫描、UDP 扫描进行参数调优。最后，我们会在 n8n 中构建一个 agentic 工作流，通过自然语言交互自动化完成连通性验证、跨网段扫描与结果解读。

本章将覆盖以下主题：

  • 什么是 PCI、什么是分段、以及为什么它重要？
  • 手工分段测试——传统方法
  • 用 agentic AI 构建内网映射工作流

技术要求（Technical requirements）

要跟随本章示例，你需要准备以下内容：

  • n8n： 1.123.0 或更高版本，通过 Docker 自托管
  • Nmap： 7.80 或更高版本，以支持完整扫描参数
  • expect： 安装在你的渗透测试机器上，用于 SSH 自动化（Debian/Ubuntu 上执行 apt install expect）
  • SSH 访问： 能连接到 CDE 与非 CDE 网段中指定渗透测试设备的凭据
  • 网络访问： 能够从渗透测试设备向目标子网发起扫描

本章使用的完整 n8n 工作流模板与 system prompts 已放在本书 GitHub 仓库中。要获取仓库链接，请按前言中 Download the example code files 一节的步骤操作。

什么是 PCI、什么是分段、以及为什么它重要？（What is PCI, what is segmentation, and why does it matter?）

当我们在进攻性安全语境下讨论内网测试时，一个不可避免会被提及、同时也最受监管且最广为人知的标准之一，就是 PCI-DSS（Payment Card Industry Data Security Standard，支付卡行业数据安全标准） 。从根本上说，PCI-DSS 的存在是为了保护持卡人数据的机密性与完整性。任何处理、传输或存储此类数据的组织，都必须实施严格控制：包括网络如何设计、访问如何授予、以及分段边界如何维护。在所有这些要求中，分段扮演着一个独特且重要的角色，因为它不仅是技术防护手段，也是缩小合规范围（scope）的方式。如果一家公司能够有效证明其持卡人数据环境（CDE，cardholder data environment）与企业其余基础设施相互隔离，那么审计范围内的系统数量会显著下降。这会直接转化为更低的审计成本，以及更少系统接受审查，使分段既是安全控制，也是业务激励。以我的经验，通过正确的分段，我见过组织将 PCI 范围缩小超过 60%，把原本可能需要 6 个月的审计变成一个可控的 2 个月过程。

CDE 本质上是 PCI 合规的核心：它是直接处理持卡人信息的一组系统、数据库与应用。按定义，这个环境必须被保护以防未授权访问，并与不需要与其连通的系统隔离。逻辑很简单：通往 CDE 的路径越少，攻击者（无论是外部入侵者还是已在内网的攻击者）就越难 pivot 进去。但概念虽直观，实践上要维持“滴水不漏”的分段却是 PCI 最具挑战的部分之一。防火墙、VLAN、访问控制列表（ACL）等技术控制需要协同工作，而哪怕只漏掉一条规则，也可能造成暴露。我在项目中亲自发现过这样的防火墙规则：多年前为了临时例外而加的放行一直没删，等于把整个分段策略直接作废。从攻击者视角看，分段边界是高价值目标：突破它就能访问最敏感的数据；从防守者视角看，分段验证是一场持续的“信任但验证（trust but verify）”。

不过，分段不应被当成一个“纯 PCI 问题”。PCI 提供了一个知名框架便于讨论，但分段原则的适用范围远超支付场景。分段的核心是管理横向移动——对手在内网从一个被攻陷主机移动到另一个主机的能力。几乎所有重大数据泄露事件中，初始入侵本身并非灾难；真正让它升级为危机的，是攻击者能够一路穿越内网，直到抵达“皇冠上的宝石（crown-jewel）”系统。无论这个系统是银行的域控、医院的病患数据库，还是科技公司的源码仓库，逻辑都一样：分段控制应该阻断——或至少显著拖慢——入侵者的移动。

这也是为什么即便组织没有正式的 PCI 义务，也应该把分段视为一种通用的内网防御策略。在本地机房网络中，这可能体现为把生产服务器与办公桌面隔离、隔离管理子网、或实施严格的东西向防火墙规则。在云环境中，它通常体现为 VPC 隔离、严格收敛的安全组、或服务间通信限制。无论基础设施模型如何，目标都是降低入侵的爆炸半径（blast radius）。分段弱时，一个被攻陷系统可能级联影响几十个系统；分段强时，攻击者被迫花更多时间、制造更多噪声、消耗更多 exploit，从而提高防守方的检测概率。

在前面的章节里，尤其是在讨论攻击面管理（ASM）时，我们强调了组织必须识别并管理外部暴露面。外部视角很关键，但它只是故事的一半。一旦攻击者通过钓鱼、凭据泄露或未修补服务跨过边界，问题就变成：有哪些边界能阻止他们抵达皇冠资产？ 这时，分段不再只是合规勾选项，而是基础韧性措施。本章将构建的工作流会同时反映两种视角：如何在 PCI 语境下验证分段，以及如何把这些方法泛化为自适应、由智能体驱动的内网安全保证测试。

在建立了监管背景与分段角色之后，下一步就是理解分段在实践中到底如何被测试。在引入自动化或智能体驱动方法之前，我们先看一看现实环境中传统分段测试是怎么做的。

手工分段测试——传统方法（Manual segmentation testing – traditional approaches）

在理解 agentic AI 能带来什么之前，回顾当下手工分段测试如何执行非常重要。这个过程看上去很简单：我们验证 CDE 外的系统能否到达 CDE 内的系统；只要任何连接是可能的，分段就失败了。但实践上，这种验证繁琐、缓慢且容易出错，测试人员必须依赖扫描工具、手工 pivot 以及对大量数据集的谨慎解读。

在一次传统的 PCI 分段测试项目中，测试人员会拿到两类关键信息：一份构成 CDE 的 in-scope 系统列表，以及一组需要作为测试起点的源子网（source subnets）。这些子网代表企业网络中本不应访问 CDE 的区域。为执行扫描，测试人员通常会在每个子网内被提供一台系统。有时可直接访问；有时要通过渗透测试跳板机（jump box）进行 pivot。无论哪种方式，测试人员都需要复现一个真实攻击者在“错误的网络位置”拿到落点后会做的事：探测边界，看是否存在通往敏感系统的裂缝。

接下来开始扫描。首选工具通常是 Nmap——不是因为它是唯一选项，而是因为它提供了合规级测试所需的灵活性与粒度。在 PCI 环境中，分段测试的目的，是证明 CDE 外系统无法对 CDE 内建立未授权的网络连接，不论协议或端口为何。

因此目标不是发现暴露服务，而是证明不存在任何非预期的访问路径。通常你需要验证完整 TCP 与 UDP 端口范围，从 0 到 65535，确保所有端口要么被分段控制明确阻断，要么作为批准设计的一部分被有意允许。

这本身是个巨大的任务。若用默认 Nmap profile 对每个 CDE 系统扫全端口，可能需要数小时甚至数天。现实中这意味着你必须放弃默认 timing 与 retry 设置，改用刻意调优的扫描参数：优先保证完成时间，同时仍对分段边界提供足够信心。

为了让全端口扫描在实践中可行，测试人员会非常激进地调参：缩短初始与最大往返超时（RTT timeouts）、降低重试次数、提高最小探测速率（min probe rates）、设置 host timeout 来切掉拖太久的扫描。在某些情况下，如果防火墙阻断 SYN 扫描但允许合法连接尝试，就从 SYN scan 切换到 CONNECT scan。UDP 由于众所周知地慢且响应不稳定，重试次数可能直接降到 0，只为在可接受时间窗内完成。目标不是优雅，而是效率：确保扫描完成，同时不牺牲到足以动摇结果可信度的程度。

当分段边界被定义后，我们通过受控网络测试来验证它们。下面小节给出我们在 PCI 分段评估中实际使用的 TCP 与 UDP 扫描方式示例。

TCP 端口扫描（SYN）（TCP port scan (SYN)）

这是验证 TCP 分段边界的默认方法。SYN 扫描可以在不建立完整连接的情况下高效识别可达 TCP 端口，适合大型 CDE。下面参数在扫描速度与合规验证所需准确性之间做了平衡，通常用于防火墙与网络控制允许半开连接尝试的环境：

nmap -sS -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 1 --host-timeout 8m --min-rate 5000 -oA acme-pci-seg-test-tcp-syn -iL targets.txt

备选 TCP 端口扫描（TCP connect scan）（Alternative TCP port scan (TCP connect scan)）

在一些环境中，即使允许合法 TCP 连接，SYN 扫描也可能被防火墙阻断或严重过滤。此时 CONNECT scan 是一个可靠替代方案：它使用操作系统网络栈完成完整 TCP 握手。虽然比 SYN 扫描慢，但在限制更强的网络里往往结果更清晰。下面命令展示了一个为分段测试调优的 CONNECT scan：

nmap -sT -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 1 --host-timeout 8m --min-rate 5000 -oA acme-pci-seg-test-tcp-con -iL targets.txt

UDP 端口扫描（SYN）（UDP port scan (SYN)）

UDP 分段测试更具挑战：协议无连接、响应行为不一致。结果是 UDP 扫描通常优先追求速度与可执行性，而不是穷尽式服务识别。下面配置将重试最小化，并用激进 timing 来在可接受窗口内完成，同时仍能识别非预期 UDP 暴露，从而验证分段控制是否有效限制了进入 CDE 的 UDP 流量：

nmap -sU -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 0 --host-timeout 10m --min-rate 5000 -oA acme-pci-seg-test-udp -iL targets.txt

扫描完成后，原始输出仍只是工作的一半。PCI 分段测试要求把结果转化为结构化格式，通常是电子表格。每一行代表一个 CDE 系统，每一列代表一个源子网。在每个单元格中，测试人员记录观测到的扫描结果：例如 closed ports、filtered ports、或无响应。

干净的分段边界意味着每个单元格都可以基于“没有任何可达端口”的结果被标记为 Compliant。如果某主机在任何端口上有响应，哪怕只有一个端口，该单元格都必须标记为 Non-Compliant。例如，一个系统从办公网段能响应 22 端口，或从生产网段能响应 3389 端口，都表示分段失败——与暴露服务本身是否加固无关。

这种矩阵式报告对审计员与评估方很有用，但也暴露了手工分段测试的局限。第一，手工过程依赖在大环境里耗时的扫描，而从多个源子网执行扫描会把工作量成倍放大。

第二，过程很脆弱：跨网络 pivot 需要细致配置，容易被误配或失效，导致结果不完整或不一致。第三，手工分段测试高度依赖人类判断：解读大量扫描输出并准确映射到合规表格非常枯燥，错误很常见。漏掉一个端口，或把某个单元格误分类，都可能制造一种虚假的信心：以为分段边界完好，实际上并非如此。

这种手工方式同样无法捕捉现代网络的动态性：防火墙规则会变、云路由会漂移、新系统会不断加入。每年一次甚至每季度一次的分段测试只能提供一个时间快照。从攻击者角度，这个快照毫无意义；他们只在乎能否抓住某个瞬间的薄弱点。从合规角度，这也让组织暴露在审计间隙的漂移风险之下。

尽管传统手工分段测试多年来为 PCI 合规提供了一个基线，但它的局限显然要求一种新方法：一种能够规模化、能够适应、并能持续运行且不把测试人员淹没在 raw data 里的方法。这就是 agentic AI 进入视野的地方——不是为了取代扫描的技术严谨性，而是为了编排它、解释它，并把它延伸为有意义的情报。

手工分段测试的挑战凸显了对更结构化、更可重复方法的需求。本节接下来将介绍如何用 agentic AI 构建内网映射工作流来弥补这些缺口。

用 agentic AI 构建内网映射工作流（Building internal mapping workflows with agentic AI）

要超越手工分段测试的局限，我们需要把这个过程看成不仅仅是“跑扫描”。真正具有变革意义的，是把它当作一个工作流：一组被协调起来的动作序列，由一个 AI 智能体引导——它不仅执行技术步骤，还能在运行时实时解释并结构化结果。

我们用三步来构建这个工作流。第一步，检查整体架构，并用 system prompt 配置 AI 智能体，定义它如何与工具和人类操作者交互。第二步，实现支撑性的工具工作流，包括 Nmap 扫描组件与 SSH 连接检查器。第三步，通过 chat 界面执行一次完整分段测试，把智能体如何收集信息、运行扫描、并汇报结果展示出来。

第 1 步 —— 工作流架构与智能体配置（Step 1 – Workflow architecture and agent configuration）

在这一步，我们引入高层工作流架构，并通过 system prompt 定义 AI 智能体的行为。system prompt 就像一份运行手册（operational playbook）：告诉智能体何时调用特定工具、如何向用户收集信息、以及在把数据传给扫描工作流时使用什么格式。

下面的工作流代表 agentic 内网映射过程的最终形态。它展示了 AI 智能体如何协调扫描工具、通过记忆保留上下文，并把分段边界作为一个持续工作流的一部分来推理：

image.png

图 5.1 —— 完整工作流（Figure 5.1 – Complete workflow）

在这个语境下，面向 PCI 分段测试的 agentic 方法可以拆解为两个协同工作的工作流：

  • PCI-DSS 分段工作流（PCI-DSS segmentation workflow）： 中心编排层，AI 智能体在此管理人类测试人员与技术工具之间的交互。我们在这里定义 system prompt：它告诉智能体如何使用工具、以及何时让人类进入环路（human in the loop）。例如，智能体可以被指示：当用户提供目标子网时使用 Nmap 工具；或只有在确认扫描数据已被规范化之后才生成合规报告。system prompt 成为智能体的“操作 playbook”，确保它遵循结构化方法，而不是盲目即兴发挥。
  • Nmap 工具工作流（Nmap tool workflow）： 扫描组件，负责在目标环境中执行 TCP 与 UDP 的全端口扫掠（sweeps）。这个工作流可以动态调参：如果防火墙阻断 SYN 扫描，智能体可以切换到 CONNECT 扫描；如果网络时延高，也可以增大超时。它与手工执行的不同点在于：智能体能基于前一次扫描的反馈即时调整参数，而无需等待人类测试人员手动改配置、再重新跑命令。

我们之前看到的示意图说明了这些部分如何拼在一起：AI 智能体处于中心，连接一个记忆层（用于跟踪先前交互）与一个扫描工具（Nmap）。人类直接与智能体交互——不是写命令，而是用自然语言描述意图。system prompt 定义交战规则（rules of engagement）：智能体该如何处理这些指令、如何编排任务顺序、以及如何把结果呈现回测试者。某种意义上，智能体既是协作者，也是编排者，连接人类判断与机器执行。

这个设计与“只是把 Nmap 自动化”有本质区别。真正的力量在于工作流如何互锁：PCI-DSS 分段工作流提供高层编排，Nmap 工作流执行定向扫描，分段报告工作流把 raw 结果转化为可行动情报。它们合在一起，交付了手工测试做不到的东西：可规模化、可重复、可持续验证，同时又不丢失人类测试者对过程的掌控能力。

下面是控制 AI 智能体在 PCI 分段测试中行为的 system prompt。该 prompt 定义了智能体如何收集分段信息、验证网络边界，并编排跨分段扫描：

{{ $now.format('yyyy-MM-dd').toDateTime() }}

You are a helpful assistant about performing PCI DSS segmentation and internal network scanning and providing reports.

- Human should provide the segment names as "CDE" and "Non-CDE"
- You're going to ask subnets belongs to these segments
- Ask from human to provide subnets for each of the segments and ask for the additional segments if the human has or not.
- Each segment should belong "CDE" or "Non-CDE" network.
- Each pentest device must be used to perform cross-segment port scans targeting the subnets of the segment to which it does not belong (i.e., the Non-CDE device scans CDE subnets and the CDE device scans Non-CDE subnets)."
- When confirmed segments now ask for the pen-test devices for the segments. Pen-test devices should 2 different servers for the "CDE" and "Non-CDE" network. You can't accept more than one pen-test device for "CDE" and "Non-CDE" network.
- Once you get the pen-test devices information now ask for the SSH credentials and check connection with using
"Segment_Connection_Check_Tool" for each pen-test device. You should confirm the access for the pen-tests devices for "CDE" and "Non-CDE" network. You should connect the pen-test devices via SSH with using "root" user.
- If the human doesn't ask for to running PCI DSS segmentation tests and provides only 1 pentest host and a ranges of subnet you can use that pentest host to perform port scanning to that subnet.
- You must send the information to use "Segment_Connection_Check_Tool" as following;

"""
{
  "username": "",
  "IP": 123,
  "credential": ""
}
"""

- Once you get the all information from the human. You can run "NMAP_Tool" with the code as given below;

TCP Port Scan (SYN) - Default
nmap -sS -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 1 --host-timeout 8m --min-rate 5000 -oA acme-pci-seg-test-tcp-syn <<IP Range for Segment>>

TCP Port Scan (CONNECT) - Use if SYN scan fails or is blocked
nmap -sT -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 1 --host-timeout 8m --min-rate 5000 -oA acme-pci-seg-test-tcp-con <<IP Range for Segment>>

UDP Port Scan - Use when requested for comprehensive testing
nmap -sU -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 0 --host-timeout 10m --min-rate 5000 -oA acme-pci-seg-test-udp <<IP Range for Segment>>

You need to provide the nmap command in "portScan" field in the JSON format given below;

"""
{
  "portScan": ""
}
"""

如 system prompt 所示，我们给智能体提供了详细的运行指令：每个工具的用途与预期用法、何时调用特定工具的决策逻辑、以及这些工具应以什么格式运行。这个结构确保智能体不会即兴发挥或依赖假设；它遵循一套可预测、由预定义逻辑支撑的工作流。它生成的每条命令、做出的每个决定，都能回溯到这段 prompt。它不仅是行为指南，更像一份严格的执行协议（execution protocol）。

到这里，我们已经建立了 agentic 工作流的基础：架构已就位，AI 智能体也清楚如何与用户交互、收集分段信息，并判断何时调用工具。但它还不能真正执行扫描或连通性检查；这些需要底层工具工作流先实现。下一步，我们来构建这些工具。

第 2 步 —— 构建工具工作流（Step 2 – Building the tool workflow）

在这一步，我们实现 AI 智能体依赖的两个工具工作流：用于执行端口扫描的 NMAP_Tool，以及用于验证渗透测试设备 SSH 连通性的 Segment_Connection_Check_Tool。每个工作流都被设计为模块化、无状态的组件：从智能体接收参数，输出结果供后续解释。

为支持它验证指定渗透测试机器的连通性并在分段网络上执行全端口扫描，我们为智能体定义了两个工具：一个用于连接测试（Segment_Connection_Check_Tool），一个用于端口扫描（NMAP_Tool）。如前面讨论，每个工具都在更大的 agentic AI 编排框架中以“专用工作流”的形式实现。这种模块化设计不仅促进复用，也让调试与优化更简单：每个工具都能独立调参、监控与升级，而不需要改动整体分段逻辑。

这些工具作为即插即用组件运行在智能体控制之下。当用户提供所需输入（例如 IP、凭据、子网）时，智能体知道该调用哪个工具、如何封装请求、以及应期待怎样的返回。这种编排保证端到端可靠性，减少人工交接，并让内部验证能够在不断变化的网络拓扑上持续进行。

当我们观察 AI 智能体如何与 NMAP_Tool 交互时（尤其从下面的执行快照中），可以清楚看到：工具从智能体直接接收关键参数，例如 username、IP、credential，以及实际 query string。这些输入不是硬编码或静态赋值，而是从智能体与人类操作者的对话上下文中动态提取。这体现了 agentic AI 的一个关键优势：它能从自然语言对话中解析人类意图，并把意图翻译成精确的技术执行。无论人类给的是高层指令（例如“从 jump box 扫 non-CDE 子网”），还是直接指定 IP 段，智能体都能解释输入、映射到正确 schema，并自动、一致地派发扫描任务，而无需人类直接操作 raw 工具。

这种“AI 作为人类指令与机器执行之间的智能中介”的动态流，正是它超越传统脚本/自动化的地方。它让复杂内网中分段测试变得安全、可审计、且完全可复现，同时保留测试人员实时引导或覆盖决策的能力。

下图展示了 NMAP_Tool 工作流的结构：这是一个专门为 AI 智能体代执行端口扫描任务而设计的专用工作流：

image.png

图 5.2 —— NMAP_Tool 工作流配置与执行（Figure 5.2 – NMAP_Tool workflow configuration and execution）

可以看到，该工作流刻意保持极简：只包含一个 Execute Command 节点。这个设计选择体现了 Nmap 本身的简单与强大：只要参数正确，Nmap 就能独立完成复杂扫描，无需在工作流内部再堆叠额外编排逻辑。

在工具层面，我们的目标不是复刻编排逻辑，而是尽可能可靠、直接地执行扫描。下面工作流展示了 Nmap 扫描组件如何被有意保持最小化，并专注于命令执行：

image.png

图 5.3 —— NMAP_Tool 工作流结构（Figure 5.3 – NMAP_Tool workflow structure）

该工作流的目的，是作为一个无状态的执行容器。智能体会提供完整的 Nmap 命令字符串（基于上下文决定 SYN 还是 CONNECT、是否需要 UDP），然后把该字符串直接传给 Execute Command 节点执行。该节点在指定渗透测试机器上运行命令、捕获输出，并把结果回传给主智能体工作流，用于进一步解释或格式化。

把 Nmap 执行隔离成独立工作流，我们获得了模块化与韧性：如果明天你要替换 Nmap，或切换到 masscan 以获得更快扫描速度，你只需要改一个工作流，而不是改整个系统。AI 智能体也无需关心底层进程处理或 shell 交互细节；它把任务下放给工具工作流，自身聚焦编排与推理。这种关注点分离（separation of concerns）是关键架构决策，让系统能在未来扩展扫描逻辑（例如集成 masscan 或按历史结果动态调 flag）时保持干净演进：你只需在工具工作流里改动，不必修改智能体逻辑或 system prompt。

Execute Command 节点里展示的脚本，是一个简单但强力的脚本，用于在分段测试期间自动化基于 SSH 的命令执行。该脚本会从 AI 智能体动态接收参数：目标 username、IP、password，以及分段查询命令（segmentation query），这些参数由智能体从人类指令上下文解析出来。

下图展示了 Execute Command 节点中配置的 expect 脚本，以及执行时解析后的输出：

image.png

图 5.4 —— Execute Command 节点中的 SSH 自动化脚本（Figure 5.4 – SSH automation script in the Execute Command node）

该脚本的主要目的，是在无需人工登录或交互的情况下，建立到指定内网机器的 SSH 连接，并执行一个与分段验证相关的命令（例如对另一个子网做 traceroute 或 ping）。它通过 expect 自动输入密码，从而绕过交互式提示，确保任务能在工作流中自治运行。这对验证分段边界、判断 jump server 或安全网关能否到达受限网段非常有用，同时无需人类介入。它轻量、灵活、可复用，适用于多种内网评估场景。

当两个工具工作流都实现后，智能体就具备了验证 SSH 连通性以及在远程系统上执行 Nmap 扫描的能力。模块化设计确保每个工具独立运行，并可在不影响整体工作流逻辑的情况下升级。现在组件已齐备，剩下的就是让它们一起跑起来。下一步，我们将通过 chat 界面发起一次完整分段测试。

第 3 步 —— 执行分段测试（Step 3 – Executing segmentation tests）

在这一步，我们把工作流跑起来。通过 chat 界面，我们给智能体提供子网定义、渗透测试设备凭据，以及分段分类。智能体验证连通性、构造合适的 Nmap 命令，跨 CDE 与 non-CDE 网段执行扫描，并总结结果；同时在执行关键动作前，会向用户请求确认。

回到主工作流后，我们可以通过聊天机器人界面与 AI 智能体交互，启动 PCI-DSS 分段流程。

开始时，我们给智能体一个简单但信息密集的 prompt：定义分段测试范围，并包含连接渗透测试设备所需的访问凭据。初始 prompt 如下：

CDE Internal Network (10.1.1.0/24) 
CDE DMZ Network (10.1.2.0/24) 
Corporate Network (10.2.1.0/24)

that's all i have

cde 10.1.1.137 non-cde 10.2.1.135 each pen-test device connection details are root password: alpinelinux

通过这一条消息，我们就给 AI 智能体提供了开始分段验证任务所需的全部关键组件：

  • PCI-DSS 评估涉及的三个关键网段
  • 位于 CDE 与 non-CDE 区域中的具体渗透测试设备
  • root 访问凭据，使智能体能 SSH 登录并发起必要连通性测试

此时智能体不需要进一步澄清；它会解析子网标注、提取测试系统 IP、识别分段边界，并判断需要触发哪些工具来验证连通性。这展示了 agentic 自动化的核心优势：即便是内网分段验证这样的复杂安全工作流，也能通过自然语言输入触发并编排，无需手工工具串联或数据准备。

工作流执行后，AI 智能体的响应会显示在界面的 chat 输出面板中。在这个例子里，智能体通过如下信息确认连通性：

It seems that the connection to both pen-test devices was successful.

这确认智能体之前已经尝试 SSH 登录 CDE 与 non-CDE 测试系统并成功。由于先前已成功，当前执行中工作流没有调用 Segment_Connection_Check_Tool；该步骤被跳过，因为智能体已经“知道”设备可访问。这种行为体现了智能体的记忆能力，以及它能基于已观测结果动态调整流程执行路径。

在右侧的 AI Agent 节点日志中，我们可以检查发送给 NMAP_Tool 的输入 query 以及对应输出。输入 JSON 显示智能体从用户 chat 消息中正确提取了 username、IP 与凭据，并据此构造了针对 10.1.1.0/24 网段的自定义 Nmap 命令。输出日志确认扫描已执行，并包含标准 Nmap 输出，显示对 255 台主机完成了 host discovery、ARP ping 与 DNS resolution。

值得注意的是，NMAP_Tool 被调用了两次。正如预期，这是因为分段验证要求双向测试：每台渗透测试设备都必须尝试扫描对方网段，以验证隔离规则是否正确生效。此例中发生的是：

  • CDE 设备（10.1.1.137）扫描 non-CDE 与 DMZ 网段
  • non-CDE 设备（10.2.1.135）扫描 CDE 与 DMZ 网段

这种自动化的双向扫描方式确保覆盖网段间潜在横向移动路径，对 PCI-DSS 合规非常关键。

在下面截图中，我们看到 AI 智能体在执行可能带来扰动的动作前，采取了谨慎且确认式的方式：

image.png

图 5.5 —— 等待用户批准的 TCP SYN 扫描命令（Figure 5.5 – TCP SYN scan commands awaiting user approval）

在从初始用户消息解析出子网与凭据后，智能体为 CDE 与 Non-CDE 两个网段准备了相应 Nmap 扫描命令，并回传给用户审阅。

这一行为突出内网测试中“安全自动化”的关键点：明确的用户确认。智能体不会盲跑扫描，而是先列出它将要执行的确切 Nmap 命令，并询问：Shall I proceed with the NMAP scanning for both segments?

它提出的扫描命令采用一致格式，并针对内网 PCI 分段测试优化。这些 flags 在保证速度的同时尽量不牺牲准确性——在多个子网上扫上千端口时，这种平衡至关重要：

nmap -sS -v -p- -Pn --initial-rtt-timeout 200ms --max-rtt-timeout 500ms --max-retries 1 --host-timeout 8m --min-rate 5000 -oA acme-pci-seg-test-tcp-syn -iL 10.1.1.0/24

该命令用于在所有端口（-p-）上执行完整 TCP SYN 扫描（-sS），并通过激进的 timing 参数（--min-rate、--max-retries、--host-timeout）加速，同时避免过多误报。输出通过 -oA 以 Nmap 支持的多种格式保存，目标从 -iL 的输入列表读取（包含子网内所有主机）。

通过提供透明度并等待用户批准，智能体确保关键网络操作仍在人类监督之下。这种行为模式在 PCI-DSS 这类受监管环境中尤为重要，因为未授权或过度激进的扫描可能扰动敏感系统或触发合规违规。

当用户只回复一个简单的 yes，智能体就会用指定渗透测试系统上的正确凭据执行扫描，并自动捕获与汇报结果。

在用户确认 Nmap 扫描后，AI 智能体会在两个网段上发起 TCP 端口扫描：CDE（10.1.1.0/24）与 non-CDE（10.2.1.0/24）。

如下所示，一旦扫描完成，AI 智能体会给出结构良好的结果摘要。结果清晰表明：

  • CDE 网段扫描（10.1.1.0/24）：

    • 扫描主机总数：256

    • 存活主机数：10

    • 发现开放端口：

      • 10.1.1.131：22（SSH）、3306（MySQL）、3389（RDP）、5432（PostgreSQL）等
      • 10.1.1.132：22（SSH）、8080（HTTP Proxy）、8443（HTTPS Alt）、9001、9002 等

  • Non-CDE 网段扫描（10.2.1.0/24）：

    • 开放端口摘要：在多台主机上发现了 22（SSH）、80（HTTP）等端口

重要的是，智能体最终结论认为：按 PCI-DSS 要求，这些网络被正确分段。扫描在两个网段上都成功完成，没有出现技术性错误。

总结（Summary）

在本章中，我们走完了内网与 PCI 分段测试的端到端流程。我们首先回顾了传统上如何通过手工扫描与基于电子表格的报告来验证分段，以及这种方法的局限性。随后，我们引入了一个 agentic 工作流：它能自动化扫描、保留上下文，并按 PCI 分段要求解释结果。该示例展示了如何把扫描执行、验证与解读视为一个被协调起来的单一工作流，而不是一堆彼此割裂的手工步骤。

在下一章中，我们将超越 n8n，引入 Model Context Protocol（MCP） ，并使用 TypeScript 与 Playwright 构建一个基于代码的安全扫描工具包，用于 Web 应用测试。

avatar
文章
阅读
粉丝