简介这份《大型红蓝攻防实战系列全景图》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 入口 → 应用漏洞 → 提权 → 内网横向 → 核心数据。每条路径上标注历史漏洞、弱口令、暴露面。我一般会维护一张攻击面清单表字段包括入口类型、资产、已知风险、利用难度、影响范围。比如入口类型资产已知风险利用难度影响范围外网 Web门户站点历史 Struts2 漏洞中可 getshellVPN 入口远程接入网关弱口令未打补丁低内网可达邮件系统Exchange已知 RCE中域内信息泄露办公网员工终端钓鱼成功率低横向跳板这张表的价值在于红队看了知道从哪打蓝队看了知道重点防哪。注意「利用难度」和「影响范围」要分开评难度低影响小的可以先放难度中影响大的必须优先处置。2.3 检测层把日志源映射到攻击链阶段检测层是全景图里最技术的一层它要回答「每个攻击阶段我靠什么发现」。常见做法是把日志源按 ATTCK 阶段排布侦察阶段靠流量和 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: - USERadmin;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:admin172.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 - flowHOME_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 做验证它把 ATTCK 技术拆成一个个可执行的小测试。比如验证 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 分钟的就是检测或响应流程有问题。我一般会把这张时间线附在全景图后面作为下一轮改进的依据。这个习惯坚持了几年每次演练的发现时间都在缩短从最初的平均两小时压到现在的十几分钟。希望帮到你。本文还有配套的精品资源点击获取
