☰
用图论解析网络攻击路径:建模、算法与落地实践
2026/10/18 2:08:35 网站建设 项目流程

提到“基于图论的网络攻击路径分析”,很多人第一反应是学术论文里才有的概念。但我在实际安全评估中,用这套方法解决过非常具体的问题:某企业准备攻防演练前,安全负责人问我,假设最边缘的一台办公终端已经被攻破,攻击者最多能走到哪一步。按传统思路,得打开漏洞扫描报告、翻网络分区、查账号权限表,靠人工一层层拼线索,费时且容易漏。那一次我换了种方式——把资产和权限状态当作节点,把可利用的关系当作边,把“从初始失陷点到核心目标”的全部可能路线变成一张可计算的图。路径结果清楚摆出来后,问题一下就变了性质。

这篇文章写给谁?红队想规划更高效的进攻路线,蓝队想做攻击面收敛,风险管理团队想用结构化方式论证安全投入。我会从思路转变、图模型搭建、核心算法、完整案例、落地踩坑五个方面展开,争取让没有图论基础的读者也能上手。

1. 为什么“漏洞列表思维”解决不了路径问题

1.1 单点漏洞评分与多步攻击之间隔着信息差

传统风险评估最常见的产出,是一张主机漏洞列表:每台机器列出一串CVE编号和CVSS分数,然后按分数从高到低排序,分高的优先修。这种做法在小规模环境勉强能用,但在稍复杂的网络里会立刻失效。

原因很简单:攻击不是单点的。攻击者通常不会只停留在攻破的第一台机器上,而是以它为跳板继续横向移动,最终目标可能是核心数据库、备份系统或者域控。而多步攻击的可行性,根本没法从任何一张单机漏洞表里读出来。一台机器上的中危漏洞,如果恰好是通往核心区的唯一跳板,实际风险可能远超一台隔离区服务器上的高危漏洞;反过来,一台高危漏洞扎堆的机器如果深度隔离、外部不可达,它的真实危害反而有限。

这就好比修路:只看每个路段的坑有多深,不看看路段之间的连通关系,你很难判断哪条路线最危险、该优先封哪条路。漏洞列表思维解决了“单点有没有毛病”的问题,却没回答“攻击者能不能利用这些毛病一路走到核心目标”的问题。

1.2 攻击图的核心思想:把可能性空间变成可计算的结构

图论的介入,恰好补上这个缺口。把网络中的资产抽象成节点,把攻击者能够从一个节点推进到另一个节点的条件抽象成边,整个网络就变成了一张有向图。在这张图上,攻击路径的定义非常清晰:从初始失陷节点出发,沿着边逐步推进,最终到达目标节点的一条节点-边交替序列。

这种图在安全领域一般叫攻击图。它的本质不是预测“某次攻击一定会怎么走”,而是把“如果初始条件成立,攻击者理论上能触达哪些位置、有多少种走法”这件事完整地表达出来。有了这种表达,后续的分析才有计算基础:哪条路径代价最小、哪些节点处于枢纽位置、切断哪些节点能让所有路径断开。

这里顺便区分一个常见概念:攻击树。攻击树以最终目标为根,把达成目标的子步骤拆成分支,结构清晰,适合描述单一目标的分解,但表达多起点、多目标、状态依赖和环路时非常吃力。攻击图更像导航软件里的路网,支持任意起点和终点,天然适合探索性分析。在实际项目中,我通常把两者结合:用攻击树梳理某个具体目标的分解步骤,用攻击图做全网的路径推演。这个思路上的转变,是后面所有技术操作的前提。

2. 图模型怎么搭:节点、边、权重决定分析质量

2.1 节点不止是IP:资产、权限状态与数据对象

很多初次接触这个方法的工程师,会把“节点”简单等同于IP地址列表。这个理解在实际建模中会出问题。一台服务器可能同时跑着Web服务、运维后台和数据库实例,攻击者拿到的可能是应用权限、普通用户权限或root权限,这些状态完全不是同一回事。

更合理的做法是,把节点定义为“资产实例 + 攻击者已获得的状态”。举例来说,“服务器A上的普通用户权限”和“服务器A上的root权限”应视为两个不同节点,两者之间通过一条“权限提升”的边连接。这样做的好处非常明显:攻击路径的语义不再是模糊的“机器A到机器B”,而是清晰的“攻击者从机器A的普通权限,提升到机器A的管理员权限,再横向移动到机器B”。

同样,目标的定义也要细化。如果目标是“核心数据库中的敏感数据”,那就应该把“数据库服务端口可达”和“数据库数据对象可读”分别建模。节点粒度越贴近权限和数据的真实状态,路径分析的结果越有决策价值。

2.2 边的可信度比边的数量更重要

建立边的依据通常来自几类证据。第一类是网络可达性:防火墙规则、ACL策略、路由信息;第二类是漏洞可利用性:某个服务的版本存在已知漏洞且攻击者能从特定位置触达;第三类是信任关系:共享账号、免密登录、域信任关系;第四类是凭证泄露情况:某台机器上存储的账号密码可以被用来登录另一台机器。

这里我要特别强调一条经验:宁可边少一条,不要边多一条。虚假的边会让最短路径分析得出完全错误的结果。比如靠经验猜测“这台机器可能可以连那台机器”,就把它加进图里,算法会理所当然地把它当作一条可行边,计算出来的“最优路径”可能在实际环境中根本走不通。

所以在我的建模流程里,每一条边都要能追溯到具体证据:端口扫描结果、漏洞扫描报告、配置信息或账号权限表。拿不准的边先不加入主图,标记为“待验证边”,等实测确认后再合并。这个习惯初期会让建模慢一些,但后期能省掉大量排查错误路径的时间。

2.3 权重设计:从CVSS到“成功率和检测代价”

边的权重决定了路径分析的结果偏向。最短路径算法里的“最短”,在攻击路径分析里的含义是“综合代价最低”。代价可以是攻击难度、时间成本、被检测概率,也可以是这些因素的组合。

我常用的权重设计参考表如下:

影响因子参考维度典型打分范围说明
漏洞可利用性CVSS分数、公开利用成熟度3-8成熟利用加分,理论性漏洞减分
攻击复杂度前置条件多少、环境要求1-5前置条件越多,代价越高
时间成本预期完成该步所需时间1-5越久越容易被发现或被阻断
被检测概率当前安全监控覆盖情况1-10监控越严,得分越高,越难走

权重没有银弹。红队视角下,权重应偏向“成功率”和“时间成本”;蓝队视角下,权重应偏向“被检测概率”和“影响范围”。同一个模型,换一个分析目标,权重表基本要重新校准。这一点后面会在案例里具体演示。

2.4 数据来源与自动化构建

图模型的数据来源,日常主要靠这么几类:端口和服务扫描结果用于确认网络可达性,漏洞扫描报告用于确认可利用边,配置管理数据库(CMDB)提供资产归属和网络分区,账号权限表和域信任关系提供横向移动边,防火墙策略文档提供区与区之间的访问控制关系。

把这些数据统一解析成结构化格式后,我习惯用Python加载进图分析库,比如NetworkX,构建有向图对象。整个过程可以写脚本半自动化,但不要完全依赖自动化输出。我的经验是,至少要对关键边做一次人工抽验,抽验比例看环境复杂度,一般20%左右。数据质量永远是这个方法的生命线,模型再漂亮,数据是脏的,输出就是误导。

3. 从图里能读出什么:最短路径、关键节点与最小切断集

3.1 最短攻击路径:攻击者最省事的路线

建好带权有向图后,第一件该做的事就是算最短攻击路径。如果图是无权的,用广度优先搜索就够了;如果带权重,用Dijkstra算法;如果图的规模很大并且有明确的终点,可以上A*算法加速。

用NetworkX做这件事情非常直观,核心代码就几行:

import networkx as nx G = nx.DiGraph() # 添加节点和带权边,weight表示综合攻击代价 G.add_edge("办公终端", "文件服务器", weight=4) G.add_edge("文件服务器", "Web服务器", weight=6) # ... # 计算从初始失陷点到目标节点的最低代价路径 path = nx.shortest_path(G, source="办公终端", target="数据库服务器", weight="cost")

最短路径的实战含义很直接:对红队来说,这是投入产出比最高的路线;对蓝队来说,这是最应该优先封堵的路线。但我必须提醒一个细节:不要让任何一条边出现权重为0的情况,否则算法会对“零代价跳转”产生错觉。我给所有边设置一个最小基线,比如1,保证路径计算符合直觉。

3.2 关键节点识别:介数中心性、割点与防线选择

找到一条最短路径还不够,因为攻击者不会只走一条路。更重要的分析,是找出整个攻击图里的咽喉节点——那些一旦被切断,大量路径会同时中断的位置。

两个图论指标在这里非常实用。第一个是介数中心性,衡量有多少条最短路径经过某个节点。介数高的节点,是网络中的交通枢纽,攻击者在不同路径间切换时大概率要经过它。第二个是割点,指删除后会导致整个图不再连通的节点。割点是天然的防御支点,因为它是某些区域之间不可绕行的唯一通道。

实际应用中我会把这两个指标结合起来看。下面是一个示意:

节点介数中心性是否为割点决策建议
运维跳板机0.82是优先做加固,部署强认证和监控
DMZ区Web服务器0.45否作为漏洞修复重点,优先级中
办公文件服务器0.31否收敛共享权限,控制外发

这里有条很重要的经验:关键节点不等于漏洞最多的节点。漏洞多但位置偏僻的节点,未必值得优先投入;漏洞少但处于图结构咽喉位置的节点,反而是真正的要害。这也是图论分析比单纯漏洞评分高明的根本原因。

3.3 环路:攻击者的“复活点”和持久化温床

分析有向图时,另一个值得高度关注的拓扑特征是环路,也就是强连通分量。所谓强连通分量,是指分量内的任意两个节点之间都存在互相可达的路径。网络里出现这种情况,通常意味着攻击者进入这个分量后,可以在内部反复横跳,利用各节点之间的信任关系持续存活。

一旦攻击者切入这样一个环路,清除工作会非常被动:你以为已经把它从机器A赶出去了,它可能又从机器B的凭证重新攻回A。这类环路的典型成因是大量主机之间配置了免密登录或共享同一个高权限账号,安全团队在建设时图省事,后期就变成了横向移动的温床。

针对环路,我在项目中的处理方式非常明确:先把强连通分量识别出来,把它当作一个整体来看待,在这个分量的出口和入口单独设置流量监控,同时逐步消除分量内部的无限信任关系。环路不拆,防住单点路径意义不大。

3.4 多路径覆盖与最小切断集:防御资源的数学优化

现实中,只封堵一条最短路径是远远不够的。攻击者一旦发现首选路线被切断,会立刻尝试第二条、第三条。所以更稳健的分析,是计算多条可选路径,比如用Yen算法求前k条最短路径,或者枚举所有可达路径。

在此基础上,防御视角最有价值的问题变成:最少需要切断哪些节点或哪些边,才能让攻击者无论怎么换路都到不了目标?这就是最小切断集或最小顶点覆盖问题。严格求最优解是NP难的,但网络规模只要不超过几百个节点,用整数规划或启发式算法都能在可接受时间内得到近似解。

这个分析的输出直接对应预算分配:与其在十个漏洞上平均撒网,不如把资源集中到最小切断集里的几个节点上。一次在某企业项目的实践中,图论分析给出的结论是修复三个咽喉节点,效果远好于修复二十个高分漏洞,这就是数学优化的威力。

4. 一次内网攻击路径推演的完整案例

4.1 模拟环境:三个区域六个节点

为了不让方法论悬在空中,我搭建了一个简化但足够说明问题的模拟环境。网络分为三个区域:办公区、DMZ区和核心数据区。初始假设是办公区的一台终端已经失陷,目标是判断能否到达核心数据库。

节点定义如下:

节点资产攻击者状态区域
办公终端员工工作电脑普通用户权限办公区(初始攻击点)
文件服务器内部文件共享普通用户权限办公区
Web服务器对外业务系统应用权限DMZ区
运维跳板机运维管理入口运维权限DMZ区
数据库服务器核心业务数据库root权限核心数据区(最终目标)
域控服务器域控域管权限核心数据区

4.2 节点和边怎么定义、权重怎么拍

建模时先把攻击路径上的关键边确认好:办公终端通过共享目录弱口令到达文件服务器;文件服务器因Web服务端口对办公区开放且存在已知漏洞,可推进到Web服务器;Web服务器的运维后台存在弱口令,可推进到运维跳板机;运维跳板机上保存了数据库账号和域管凭证,可分别推进到数据库服务器和域控服务器。

权重根据攻击复杂度和被检测概率综合确定。漏洞利用成熟、动作隐蔽的边给低权重,代价大、容易被发现的边给高权重:

边依据综合权重
办公终端 → 文件服务器弱口令,操作简单4
文件服务器 → Web服务器已知漏洞,需要构造请求6
Web服务器 → 运维跳板机后台弱口令,动作较隐蔽5
运维跳板机 → 数据库服务器凭证直接可用,目标明确3
运维跳板机 → 域控服务器凭证存在但域管动作检测严8

4.3 计算结果:最短路径、关键节点、最小切断集

把上述节点和边代入图计算后,结果非常清晰。最短攻击路径是:办公终端 → 文件服务器 → Web服务器 → 运维跳板机 → 数据库服务器,综合代价18。另一条高价值备选路径是:办公终端 → 文件服务器 → Web服务器 → 运维跳板机 → 域控服务器,综合代价23,虽然权重更高,但一旦得手影响更大。

关键节点分析显示,运维跳板机的介数中心性远高于其他节点,并且是全图唯一的割点。这意味着无论是走向数据库还是域控,攻击者几乎别无选择地要经过它。最小切断集的计算结果也支持这个判断:只要切断运维跳板机这个节点,或切断Web服务器到运维跳板机这条边,整张攻击图立刻失去到达核心区的路径。

这个结论和传统漏洞扫描报告的优先级形成了有趣的冲突。漏洞扫描报告会把Web服务器的高危漏洞排在最前面,建议优先修复,但图论分析指出,运维跳板机才是真正的结构咽喉。修复Web服务器的漏洞固然有价值,但如果不处理运维跳板机,攻击者换个漏洞照样能打进来。决策层要的是一个全局最优解,不是一串孤立的高分漏洞。

4.4 红队验证与报告呈现:图论结果不能替代实测

在真实项目中,图论分析的结果必须要经过实测验证。我通常会把图论给出的最优路径交给红队作为重点测试范围,而不是当作既成事实。红队按照最短路径实际走一遍,能验证边的真实性、权重的合理性,也能发现建模时遗漏的隐藏路径。

验证完成后,报告呈现用图可视化效果最好。把节点按安全区域分色,重点路径用醒目颜色标出,关键节点放大标注,决策层一眼就能看清“攻击者是怎么走到核心区的”“该在哪里设卡”。我在实践中发现,两张图胜过十页文字——一张现状攻击图,一张加固后的收敛图,安全投入的理由会非常直观。也因此,图论结果更适合定位边界和指引测试方向,而不是替代真正的渗透测试。

5. 落地时最容易翻车的五个环节

5.1 数据不全怎么办:先小步跑通再补数据

落地时最常见的困境,是数据不全:防火墙策略文档过时、CMDB里的资产清单不完整、扫描器覆盖不到某些网段。很多团队卡在这一步,觉得数据不到位模型就没法做,于是一直等数据,最后不了了之。

我的建议恰恰相反:先圈定一个很小的业务范围,哪怕只有十几个节点,手工把边确认清楚,把模型跑通一次,看看输出长什么样。小模型的价值在于帮你验证边定义、权重逻辑和分析流程,而不是追求覆盖整个公司。跑通后再逐步扩大范围、逐步自动化,远比一步到位可靠。

5.2 权重是“拍脑袋”吗:评审机制与历史校准

权重设置最容易被质疑“凭感觉”。这个质疑有道理,所以我采取的做法是:先给出一版默认权重模板,然后组织安全运营团队、红队和运维一起评审,把存在争议的边逐条过一遍。如果能拿到过去真实攻击事件或演练记录,就用历史数据反推校准,那是最好的校正方式。

经验表明,权重在一定范围内波动时,关键路径的排序是比较稳定的,真正敏感的是边的缺失而不是权重的小幅变化。所以与其反复争论某条边权重是3还是4,不如把精力放在确认边是否存在、证据是否可靠上。

5.3 图的大小失控:可视化与子图聚合

网络规模稍大,攻击图就会膨胀到几百甚至上千个节点,直接在图上做分析会非常混乱。我的处理方式是分层:第一层看安全域之间的宏观视图,把每个区域聚合成一个超级节点,先看清区与区之间的路径;第二层再展开某个关键区域的内部视图,看具体的主机和边。前者用于向管理层汇报,后者用于技术团队落地整改。

可视化工具方面,Neo4j适合存图数据并做交互查询,Gephi适合画布局图,但最终给决策层的报告,只需要保留关键路径和关键节点,千万不要把整张庞然大图直接贴进PPT。

5.4 误把“可能性”当“必然性”:图和渗透测试的分工

图论分析描述的是可能性空间——如果边所代表的漏洞和信任关系都成立,攻击者可以走这条路,但并不意味着它一定会走这条路。蓝队如果把这个结果直接当成“已确认风险”去推动整改,容易过度紧张;红队如果把它当成“必然有漏洞”去写报告,也可能翻车。

正确的用法,是把图论分析当作瞄准镜和过滤器:图缩小测试范围、指出高概率路径和高杠杆节点,实测验证真实可利用性,再用验证结果反过来修正图模型。两者配合,输出才经得起推敲。我在项目里明确要求,图论报告里每一处结论都必须标注“理论路径”还是“已验证路径”。

5.5 动态攻击面:定期重建图的价值

网络环境是动态的:新系统上线、防火墙策略调整、账号权限变更、漏洞利用工具更新,任何一个变化都可能让旧图失效。所以攻击图不能是一次性项目,而应该成为一种常态化机制。

我的建议是:以月或季度为周期重建一次攻击图,或在每次较大规模变更后触发重建。有条件的团队可以把它做成自动化流水线,扫描任务完成后自动更新图数据,再自动触发关键路径计算。坚持做半年以上,你会看到攻击面的变化趋势,这种趋势对安全规划的价值,远超过某一时刻的快照。

如果让我给刚接触这套方法的团队一个建议,我不会让他们一开始就追求完美数据源和全自动化,而是先圈定一个小范围,手工把图跑通。我第一次实践时也吃过数据不足、权重不准的亏,但当攻击图第一次展示在评审会上的时候,决策层的注意力就不再是“这个漏洞该不该修”,而是变成了“为什么所有路线都要经过这个跳板机、我们能不能让路径断在这里”。这个视角转变,就是图论方法最值钱的地方。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询