简介：这份《大型红蓝攻防实战系列全景图》PPT面向网络安全从业者、红蓝对抗演练人员及企业安全建设决策者，系统梳理了红蓝攻防全景推演的攻击面识别、边界突破、横向渗透、攻陷强控等阶段，并围绕基础、强化、协同三层保护机制展开。内容涵盖数字化资产关联、风险情报、安全能力三大基础库，以及日常管理运营、一体化对抗蓝方、战略决策协同指挥等平台方案，结合金融、能源、政务等落地案例，帮助读者理解综合防御体系搭建思路。资源为单个pptx文件，压缩包约19.47MB，以图文架构图形式呈现，便于快速浏览与内部培训引用。目前已有1515人学习，适合需要体系化掌握红蓝对抗框架、对标行业实践的安全人员参考。

1. 红蓝攻防全景图到底画什么：从一份 PPTX 说清演练的全局视角

很多人第一次拿到「大型红蓝攻防实战系列全景图.pptx」这类文件，第一反应是把它当成一份汇报材料，翻两页就丢进硬盘吃灰。但真正带过演练的人知道，这张全景图的价值不在好看，而在于它把一场持续数周、涉及几十号人的对抗，压缩成一张能对齐认知的作战地图。红蓝攻防实战的核心矛盾是：攻击方（红队）要找一条能打穿的路，防守方（蓝队）要在自己都说不清资产的情况下守住每一条路。全景图解决的正是这个信息不对称——它把资产、攻击面、检测点、响应流程画在同一张图上，让红蓝双方对「战场长什么样」达成一致。这篇笔记不聊虚的，就按这张图的结构，把大型红蓝攻防从组织、技术到落地一步步拆开，适合刚接手演练统筹的安全工程师、想搭自己靶场的团队，以及需要向管理层讲清楚投入产出的人。

2. 全景图的四层结构：资产、攻击面、检测、响应怎么落到一张图

一张能用的全景图不是美术作品，它必须能回答四个问题：我有什么、敌人从哪来、我怎么发现、发现之后怎么办。这四层对应图上的四个横向泳道，纵向则按攻击链阶段（侦察、初始访问、横向移动、影响）切分。下面逐层说清楚每层该画什么、数据从哪来。

2.1 资产层：把 CMDB、扫描器和人工盘点对齐

资产层是全景图的地基，也是最容易翻车的地方。很多团队的 CMDB 和真实网络里跑的东西对不上，扫描器扫出来的和业务报上来的差一大截。我的做法是以扫描结果为主、CMDB 为辅、人工确认兜底，三者取并集再标差异。

具体操作上，先用一条命令把存活资产拉出来，再和 CMDB 做比对：

# 用 nmap 做一次快速存活与端口探测，输出成可解析格式 nmap -sS -Pn -p 1-65535 --open -oX scan_result.xml 10.0.0.0/16 # 把 XML 转成 CSV，方便和 CMDB 做 diff python3 -c " import xml.etree.ElementTree as ET import csv tree = ET.parse('scan_result.xml') rows = [] for host in tree.iter('host'): addr = host.find('address').get('addr') for port in host.iter('port'): rows.append([addr, port.get('portid'), port.find('state').get('state')]) with open('assets.csv','w',newline='') as f: csv.writer(f).writerows(rows) "

这段脚本的逻辑很直接：nmap 负责发现，Python 负责把 XML 拍平成表格。参数上-sS是半开扫描，速度快但需要 root；-Pn跳过主机存活探测，防止内网设备不回 ping 被漏掉；--open只保留开放端口，减少噪音。扫完之后拿assets.csv和 CMDB 导出表做一次 join，对不上的就是你要重点确认的「影子资产」。这一步不做，后面所有检测和响应都是空中楼阁。

2.2 攻击面层：从外网入口到内网横向的路径标注

资产清楚了，接下来要标出敌人可能走的每一条路。攻击面层不是简单列 IP，而是画路径：外网 Web 入口 → 应用漏洞 → 提权 → 内网横向 → 核心数据。每条路径上标注历史漏洞、弱口令、暴露面。

我一般会维护一张攻击面清单表，字段包括：入口类型、资产、已知风险、利用难度、影响范围。比如：

这张表的价值在于，红队看了知道从哪打，蓝队看了知道重点防哪。注意「利用难度」和「影响范围」要分开评，难度低影响小的可以先放，难度中影响大的必须优先处置。

2.3 检测层：把日志源映射到攻击链阶段

检测层是全景图里最技术的一层，它要回答「每个攻击阶段我靠什么发现」。常见做法是把日志源按 ATT&CK 阶段排布：侦察阶段靠流量和 DNS 日志，初始访问靠 WAF 和 EDR，横向移动靠内网流量和主机登录日志，影响阶段靠数据防泄漏和备份系统。

这里有个血泪经验：日志源不是越多越好，而是要覆盖关键阶段。我见过团队买了十几个安全设备，结果横向移动阶段只有一条 Windows 登录日志，红队在内网跑了一周都没人发现。所以画检测层时，先列攻击阶段，再往每个阶段填日志源，填不上的就是盲区，盲区就是你要补的检测能力。

2.4 响应层：从告警到处置的闭环流程

响应层画的是流程，不是技术。它要明确：谁看告警、多久响应、什么级别升级、处置动作有哪些。全景图上通常用泳道图标出「检测 → 研判 → 遏制 → 清除 → 恢复」五个环节，每个环节标责任人和时限。

我一般会定几条硬规则：高危告警 5 分钟内必须有人认领，30 分钟内出研判结论，确认失陷后 1 小时内完成隔离。这些数字不是拍脑袋，是根据过往演练的平均响应时间倒推的。响应层画不清楚，前面三层做得再好，真出事也是一锅粥。

3. 用开源工具搭一套可复现的红蓝对抗靶场

全景图画完，下一步是验证它。最靠谱的验证方式不是纸上推演，而是搭一套靶场真打一遍。这一章讲怎么用开源工具在本地复现一个缩小版的红蓝对抗环境，成本低、可重复、能暴露全景图里的盲区。

3.1 靶场拓扑与工具选型

靶场不需要大，但结构要全。我常用的最小拓扑是：一台外网 Web 靶机（含已知漏洞）、一台跳板机、一台内网域控、一台员工终端、一台日志服务器。工具选型上，红队用 Metasploit + Cobalt Strike 的替代品（如 Sliver），蓝队用 Suricata + Wazuh + ELK。

选这些工具的理由：Sliver 开源、支持多种 C2 协议、适合练手；Suricata 做流量检测、规则生态成熟；Wazuh 做主机 HIDS、和 ELK 集成顺滑。整套跑起来对硬件要求不高，一台 16G 内存的机器用 Docker 就能撑住。

3.2 用 Docker Compose 拉起靶场环境

下面这份 compose 文件是我常用的骨架，去掉了具体漏洞镜像，你可以按需替换：

version: '3.8' services: web-target: image: vulnerables/web-dvwa ports: - "8080:80" networks: - dmz jumpbox: image: ubuntu:20.04 command: sleep infinity networks: - dmz - internal dc: image: dperson/samba environment: - USER=admin;admin networks: - internal elk: image: sebp/elk ports: - "5601:5601" networks: - internal networks: dmz: internal:

这份配置的逻辑是：dmz网络模拟外网可达区，internal模拟内网。Web 靶机只挂在 dmz，跳板机同时挂两个网络，模拟被打穿后的横向通道。参数上注意sebp/elk镜像比较吃内存，建议给 Docker 至少 8G。启动后访问localhost:5601进 Kibana，把 Suricata 和 Wazuh 的日志接进来，检测层就活了。

3.3 红队视角：从外网打点到内网横向的最小路径

靶场起来后，红队要做的第一件事是确认攻击路径。以 DVWA 为例，常见路径是：发现 8080 端口 → 弱口令登录 → 命令执行 getshell → 从跳板机扫内网 → 找域控。

# 从跳板机扫内网存活 nmap -sn 172.20.0.0/24 # 对发现的域控做端口探测 nmap -sV -p 445,139,389 172.20.0.10 # 用 impacket 做一次简单的 SMB 登录测试 python3 -m impacket.smbclient admin:admin@172.20.0.10

这几条命令的目的是验证「外网打穿后能不能进内网」。-sn只做 ping 扫描，快速摸清内网有多少活物；-sV做版本探测，判断域控开了哪些服务；impacket 那条是测试弱口令能不能直接登。如果这条路径走通了，说明全景图上的攻击面标注是准的；如果走不通，要么是网络隔离没画对，要么是检测层漏了。

3.4 蓝队视角：把 Suricata 和 Wazuh 告警接进全景图

蓝队的任务是在红队每一步动作上验证检测能力。Suricata 负责流量侧，Wazuh 负责主机侧。配置 Suricata 时，重点开这几条规则：扫描检测、SMB 异常、DNS 隧道。

# suricata.yaml 关键片段 vars: address-groups: HOME_NET: "[172.20.0.0/24]" EXTERNAL_NET: "!$HOME_NET" outputs: - eve-log: enabled: yes filetype: regular filename: eve.json types: - alert - flow

HOME_NET一定要设成你的内网段，否则规则匹配会乱。eve.json是给 ELK 消费的，格式选 JSON 方便解析。Wazuh 那边重点配文件完整性监控和登录失败告警，把告警级别调到 7 以上，避免噪音淹没真实事件。接完之后，让红队再打一遍，看蓝队能不能在 5 分钟内发现——发现不了，就回去补全景图的检测层。

4. 大型演练里最容易翻车的五个坑

靶场跑通不代表实战能打。大型红蓝攻防涉及人多、系统杂、时间紧，下面这五个坑是我踩过或者见别人踩过的，每条按现象、原因、解决写清楚。

4.1 资产清单和实际不符，红队一打一个准

现象：演练开始第一天，红队就从某个「不在清单上」的测试系统打进来了。原因：CMDB 更新滞后，测试环境没纳入管理，扫描器也没覆盖。解决：演练前两周做一次全量扫描，和 CMDB 强制对齐，差异项必须人工确认；测试环境要么下线，要么纳入监控。

4.2 告警太多没人看，真实攻击被淹没

现象：蓝队一天收几万条告警，真正的高危事件被埋在噪音里，等发现时红队已经拿到域控。原因：检测规则没调优，阈值太低，重复告警没去重。解决：演练前做一轮告警收敛，把已知误报加白，同类告警做聚合；定一条硬规则——高危告警必须 5 分钟内有人认领，认领不了就升级。

4.3 响应流程卡在审批，隔离动作慢半拍

现象：确认某台机器失陷，但隔离需要走变更审批，等了两个小时才动手，红队早跑了。原因：演练前没预授权紧急处置流程。解决：提前和运维、业务方约定，演练期间高危隔离可以先斩后奏，事后补单；把这条写进响应层，让所有人知道。

4.4 红蓝双方信息不同步，重复劳动

现象：红队打穿了一个点，蓝队还在另一个方向查日志，两边都不知道对方在干嘛。原因：没有统一的作战室和共享看板。解决：全景图本身就是共享看板，演练期间实时更新攻击路径和检测状态；每天早晚各一次同步会，红蓝各说三分钟。

4.5 演练结束不复盘，下次还踩同样的坑

现象：演练打完，报告一交，没人跟进整改，第二年同样的漏洞还在。原因：复盘流于形式，整改没责任人没时限。解决：复盘会必须产出整改清单，每条有责任人、有 deadline、有验证方式；把整改项回填到全景图，下次演练前先看上一轮的坑填了没。

5. 把全景图变成可执行的检测规则与验证清单

全景图画得再好，不落到检测规则上就是一张废纸。这一章讲怎么把图上的每个检测点翻译成可执行的规则，以及怎么验证规则真的有效。

5.1 从攻击链阶段反推检测规则

以「横向移动」阶段为例，全景图上标了「内网 SMB 异常」这个检测点。翻译成 Suricata 规则就是：

# 检测内网 SMB 扫描行为 alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"Possible SMB scan"; flow:to_server; flags:S; threshold:type both, track by_src, count 20, seconds 10; sid:1000001; rev:1;)

这条规则的逻辑是：10 秒内同一源 IP 发起超过 20 次 SMB 连接，就告警。threshold是关键参数，调太低误报多，调太高漏报。我一般先用 20/10 跑一周，看告警量再微调。每条规则都要对应全景图上的一个检测点，规则 ID 和检测点编号关联，方便追溯。

5.2 用原子测试验证每条规则是否真的会响

规则写完不代表会响。我习惯用 Atomic Red Team 做验证，它把 ATT&CK 技术拆成一个个可执行的小测试。比如验证 SMB 扫描规则，就跑对应的原子测试：

# 安装 atomic-red-team git clone https://github.com/redcanaryco/atomic-red-team.git cd atomic-red-team # 跑一个 SMB 发现测试 python3 atomic-operator/atomic_operator.py -t T1046 -a

跑完看 Suricata 有没有出告警。没出，要么规则写错了，要么日志没接对。这一步不能省，我见过太多团队规则写了一大堆，真打起来一条都不响。

5.3 全景图迭代：每次演练后更新哪几个字段

全景图不是一次画完就完事。每次演练后，至少更新这几个字段：资产层加新发现的影子资产，攻击面层更新已修复和新增的风险，检测层标注哪些规则响了哪些没响，响应层记录实际响应时间。我一般会在图上用不同颜色标状态：绿色已验证、黄色待验证、红色盲区。下次演练前先看红色区域，那就是重点补的地方。

5.4 一个具体技巧：用时间线对齐红蓝双方动作

最后分享一个我常用的技巧：演练结束后，把红队攻击日志和蓝队告警日志按时间轴对齐，画一张时间线图。这张图能直观看出「红队动作 → 蓝队发现」的延迟。延迟超过 30 分钟的，就是检测或响应流程有问题。我一般会把这张时间线附在全景图后面，作为下一轮改进的依据。这个习惯坚持了几年，每次演练的发现时间都在缩短，从最初的平均两小时压到现在的十几分钟。希望帮到你。

本文还有配套的精品资源，点击获取