攻防演习防守技术方案:从资产梳理到应急响应的实战指南

发布时间:2026/9/24 21:33:00
攻防演习防守技术方案:从资产梳理到应急响应的实战指南 简介攻防演习防守技术方案PPT围绕实战攻防演习中的防守视角展开面向HW/护网、红蓝对抗及重保期间的安全管理人员、蓝队工程师旨在帮助建立从攻击识别到体系化防御的完整认知。压缩包共1个文件为PPTX演示文稿大小约20.15MB内容组织清晰便于直接用于内部培训与防守预案修订。已有1502人学习下载。方案梳理了攻防演习从实验阶段到系统化、常态化的发展脉络归纳了物理设备攻击、供应链攻击、0day1day、钓鱼水坑等典型攻击手段并结合防守方脆弱性提出安全防御体系化转变思路。内容还涵盖演习评分规则从终端失陷、边界突破到追踪溯源的演进以及九个关键举措与案例介绍可帮助安全人员快速掌握备战HW与重保的防守技术要点提前部署监测、应急响应和溯源能力。1. 攻防演习防守技术方案防守方在红蓝对抗里到底守什么一场攻防演习防守方收到通知后往往第一反应是“赶紧打补丁、加WAF规则”真打起来才发现最难的不是某个漏洞而是整套防守动作没有串联。攻防演习防守技术方案说白了就是把资产、监控、研判、处置、溯源这几件事提前串成一条流水线让每个岗位在高压下按流程走而不是临场拍脑袋。红队的攻击路径再绕最终逃不开侦察、建点、横向、留后门这几步防守方案的作用就是在这几步上卡住它。这篇笔记写给防守队负责人和安全工程师后面每一章都可以当作演习前的自检清单——该收的资产、该接的日志、该定的角色、该跑的流程一项一项对着做。2. 演习前的防守准备资产台账、攻击面收敛与加固基线2.1 资产摸底先给攻击面画一张准确的地图防守最怕的是“不知道自己在守什么”。很多单位CMDB里的资产列表长期没人更新新上线的测试系统、临时开的映射端口、运维私自装的主机都是红队最喜欢抓的破绽。演习前第一件事就是把资产台账重新核一遍。常见做法是以CMDB导出的列表为基础再用网络扫描做交叉验证。扫描要分段做别一口气扫全内网既容易把网络设备扫出问题也会产生海量告警干扰后续研判。我在演习前一般会做两次扫描一次是存活探测一次是服务识别。# 第一遍分段探测存活主机避免大范围高并发打满网络设备 nmap -sS -sn -T4 -iL segment_list.txt -oG alive.gnmap grep Up alive.gnmap | awk {print $2} alive_hosts.txt # 第二遍对存活主机做全端口服务识别重点盯高位端口 nmap -sS -sV -Pn -p 1-65535 --open -iL alive_hosts.txt -oX services.xml第一条命令里的-sn是只做主机发现不发探测包-T4调高扫描并发segment_list.txt里按网段分行写。第二条的-sV是服务版本识别-p 1-65535扫全端口这一步不是强迫症而是要把改到高位端口的管理后台、数据库、调试接口全部暴露出来。-Pn跳过Ping探测防止部分主机禁Ping被漏掉。扫描结果不能直接当台账用得补上“负责人”和“业务重要性”两列。没有负责人的资产演习期间出了问题没人接比没有资产更麻烦。我一般会让各业务线在扫描结果上认领认领不上的先标记为“待确认”演习前再给两天宽限之后还没有主的系统直接做成隔离候选。边界上还要做一次映射核对。防火墙里的NAT策略、端口映射配置往往比内网资产更危险。把配置导出来按目标端口排序# 从防火墙导出配置后过滤静态映射条目按目的端口排序看看暴露面 cat fw_nat.conf | grep -E nat server|static | awk {print $NF} | sort不同厂商配置格式有差异但思路一致找到“从外网能访问到什么”这个答案。重点看RDP、Oracle/MySQL、Redis、Elasticsearch这类端口这些是高危映射。演习期间不能下线的至少要在防火墙上加源IP限制。2.2 攻击面收敛把暴露入口收窄到最小资产摸清后的第二步是收敛。收敛不是把所有服务都关掉而是把“演习期间不该暴露的”收掉。红队第一波侦察基本靠端口扫描和目录爆破暴露面越窄红队拿到有效情报的时间就越长。优先处理这几类一是有管理后台但无访问控制的外网系统二是默认口令、弱口令还没改完的设备三是测试/预发布环境挂在生产域名下的站点。对于管理后台最直接的手段是限制来源IP只允许办公网出口或堡垒机访问。对于测试站点演习期间要么下线要么加HTTP Basic Auth并限制来源别怕麻烦。内网主机上的弱口令整治同样不能省。很多防守方只盯边界演习开始后却发现自己内网一台Windows测试机用的是admin/admin123被红队打下来当跳板。演习前用脚本批量自查一遍本机账号# 在重点Windows主机上检查本地管理员组成员和启用账号 net localgroup administrators wmic useraccount where disabledfalse get name,sidnet localgroup administrators能快速看出管理员组里有没有不该存在的账号wmic那行列出所有启用的本地账号SID可以用来区分本地账号和域账号。红队拿到权限后常做的就是往管理员组塞账号演习前先把这些洞堵上。自查脚本执行完把结果汇总到一个文件里逐台确认。还有一类经常被忽略的是网络设备。交换机、防火墙的管理口如果暴露在业务网里且口令用的是默认或弱口令那基本等于给红队开了一扇侧门。演习前把网络设备口令全部轮换一遍并把管理地址收敛到管理网段这是性价比最高的收敛动作。2.3 加固基线把该管的、该记的、该关的都定下来收敛是“收门”加固是“砌墙”。攻防演习加固不用追求全套CIS基线把跟攻击路径直接相关的几条做扎实更重要。第一条是日志审计策略。很多Windows服务器默认不记录进程创建和详细登录信息真出事的时候只能看到结果没有过程。演习前要把关键审计子类打开# 启用登录/注销和进程创建审计成功失败都记录 auditpol /set /subcategory:Logon/Logoff /success:enable /failure:enable auditpol /set /subcategory:Process Creation /success:enable /failure:enable注意不同语言版本的系统里子类别名称不同可以先执行auditpol /list /subcategory:*查看本机实际名称。打开之后会产生额外日志量建议在重点服务器和所有面向用户的入口主机上开启一般办公终端可以先不开。第二条是关闭不再使用但有历史问题的协议和服务。SMBv1这类协议在不少老业务里还开着红队横向移动时最喜欢拿它做文章。如果业务确认不再依赖直接通过PowerShell关掉# 关闭SMBv1协议需要管理员权限并重启生效 Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force这类加固动作一定要先跟业务确认不能自己闷头关。演习期间业务中断比丢分更麻烦搞不好责任还会落到防守方头上。第三条是账号权限收缩。域管理员账号必须做分离使用平时办公不能拿高权限账号登录本地管理员口令如果所有机器都是同一个演习开始前要改成随机独立口令。用组策略推送密码重置比较现实逐台手动改时间上来不及。2.4 演习前的监控预演先让传感器“睁眼”监控配置最怕的是“以为接了日志实际没接上”。我见过太多这样的情况SIEM平台界面很漂亮但某个核心网段的流量镜像早就断了日志根本没进来。所以演习前一到两周必须做一次日志连通性验证。做法很简单模拟一个无害的攻击动作然后去日志平台里查能不能收到。比如在测试机上执行一条外部域名解析和HTTP请求再到SIEM里查这条记录# 在测试终端执行模拟外联动作域名用内部专用的检测域名 curl -m 5 http://inspection.example.local/ping nslookup inspection.example.local执行完之后到日志平台查这个域名是否产生记录。如果查不到说明流量链路有断点趁演习前赶紧修。-m 5是让curl最多等5秒避免域名不存在时长时间挂起。这个模拟动作要提前通知监控组别让值班同事误以为是真攻击。监控预演这一步做得好能避免演习期间至少一半的抓瞎。传感器都没睁眼后面再好的研判流程都是空转。3. 防守指挥与监控检测从告警到研判的可落地链路3.1 蓝队角色怎么搭五个组千万别散防守方案里最常见的问题不是缺技术而是缺组织。演习一开始告警一多所有人都在群里喊没人决策没人汇总最后变成“谁声大听谁的”。一套标准的防守组织至少要有五个角色角色职责关键动作指挥组总体决策、对外汇报、资源调度拍板处置级别联系业务方监控组值班盯告警做第一层过滤把可疑告警分诊到研判组研判组确认告警是否真实攻击还原攻击链路定级上报处置组执行阻断、隔离、加固按预置动作包操作溯源组日志取证、攻击链分析输出溯源报告供复盘用在小型团队里监控和研判可以合并但研判和处置必须分给不同的人。原因很简单执行处置的人如果同时负责判断“是不是攻击”很容易因为疲劳或压力把误判掩盖过去出了事没人兜底。这个设计是用翻车换来的经验。五组之间要有明确的交接格式。监控组转给研判组时至少要带“时间、源IP、目标IP、事件类型、原始告警链接”这五个字段缺一不可。否则研判组接到的就是一个“有告警但不知道怎么回事”的黑匣子。3.2 监控规则怎么写先把告警收口再谈精准监控规则不是越灵敏越好。默认规则全开的结果就是告警洪水第一天就能把研判组淹没。我的建议是分级建设基础规则保覆盖重点规则保精度。终端侧优先保留Sysmon的关键事件ID比如进程创建Event ID 1、网络连接Event ID 3、文件创建Event ID 11。Sysmon默认会记录很多正常行为需要做排除配置!-- Sysmon配置示例排除正常系统进程保留进程创建和网络连接告警 -- Sysmon schemaversion4.90 EventFiltering ProcessCreate onmatchexclude Image conditionisC:\Windows\explorer.exe/Image /ProcessCreate NetworkConnect onmatchexclude Image conditionends with\svchost.exe/Image /NetworkConnect /EventFiltering /Sysmononmatchexclude表示排除满足条件的进程conditionis是完全匹配conditionends with是后缀匹配。排除项越少越安全宁可多留几条告警也不要漏掉关键行为。部署前先在一台终端上试跑24小时看看日志量能否接受。网络侧的监控重点不是“所有流量”而是“可疑的目的地址非标准端口”。很多SIEM平台支持直接查询日志索引以Elasticsearch为例查“进程在临时目录里运行”这一类高可疑行为{ query: { bool: { filter: [ { term: { winlog.event_id: 1 } }, { terms: { process.executable.keyword: [ C:\\Windows\\Temp\\*.exe, C:\\Users\\Public\\*.exe, C:\\ProgramData\\*.exe, C:\\Users\\*\\AppData\\Local\\Temp\\*.exe ]}} ] } } }这段查询里的wildcard用terms配合通配符匹配能覆盖红队在Windows临时目录释放恶意程序的高频动作。process.executable.keyword是字段名不同索引映射可能不一样需要根据实际数据调整。运行之后会产生少量误报比如运维脚本在Temp目录下解压工具所以建议配合白名单机制。监控规则重点覆盖五类场景扫描探测、暴力破解、横向移动、Web攻击、命令执行。每一类都要有清晰的证据来源否则告警打出来也不知道看什么。3.3 研判流程一个告警怎么决定升不升级监控组把告警推到研判组之后不能每个人都上去查一遍。要有明确的研判关卡第一关看白名单第二关看上下文第三关看时间线三个关过了才能定级。告警级别典型特征响应时限低单一端口扫描、密码尝试低于阈值4小时合并处理中同一来源多次爆破、单个异常登录成功30分钟内复核高已确认Webshell上传、C2外联、横向会话异常10分钟内启动处置低危告警合并处理很重要。演习期间红队必然会有扫描行为如果每次扫描都触发响应处置组会被拖死。把同一源IP在一段时间内的扫描归并成一条“扫描事件”记录起止时间和目标范围即可。中危告警要人工复核重点是确认“这个登录行为是否来自合法运维”。高危告警一旦确认直接拉指挥组跳过常规流程。研判结论一定要留痕。每一条告警关闭时强制填写“放行、误报、确认攻击”三选一并附一句理由。这个习惯到复盘时价值极大没有结论记录的告警等于没看。3.4 威胁狩猎不等告警自己捞一遍攻防演习里防守方最大的错觉是“告警没响就安全”。红队真正高明的动作很多都不会触发告警比如利用合法账号登录、在内网批量读取共享文件。所以防守方必须在演习中段主动做威胁狩猎。狩猎不需要追求全内网覆盖挑重点就够了。一是在业务高峰期过后查所有服务器上最近新建的计划任务和启动项二是导出重点主机的远程登录会话看有没有不在预期内的来源IP。# 在重点主机上查找非Microsoft路径的计划任务 Get-ScheduledTask | Where-Object { $_.State -ne Disabled -and $_.TaskPath -notlike \Microsoft\* } | Select-Object TaskName, TaskPath, State # 查看启动项里最近新增的条目 Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Run, HKCU:\Software\Microsoft\Windows\CurrentVersion\Run -ErrorAction SilentlyContinue这两条命令只适合在重点服务器上跑比如域控、备份服务器、运维跳板机。-ErrorAction SilentlyContinue是为了避免无权限访问的注册表项刷屏。狩猎本身就是个技能活儿没有捷径多查几轮就能认得哪些是正常运维动作哪些是红队的痕迹。4. 应急处置与追踪溯源告警确认后的黄金45分钟4.1 处置动作包先阻断后取证边处置边留痕告警确认的瞬间处置组面临的最大诱惑是“赶紧把网线拔了”。这个动作从防守得分角度看可能是对的但从溯源角度看是灾难——内存里的证据、活跃连接、确认木马进程拔网线之后就全没了。我的处置顺序是固定的先阻断C2通信再冻结目标账号然后快速抓取主机现场证据最后才考虑隔离主机。阻断C2通信在防火墙上做目的IP封锁即可不要把整个网络断掉# 防火墙ACL示例只封攻击者C2服务器IP不影响其他业务访问 ip access-list extended block-c2 deny ip any host 203.0.113.55 permit ip any any interface GigabitEthernet0/0 ip access-group block-c2 in203.0.113.55是示例地址实际替换为确认的C2 IP。ACL配置完成后要立即验证业务端口是否受影响特别是有多个应用共用同一出口的场景。只封目的IP、不封整个网段这是避免误伤的关键原则。做主机现场取证时至少要在关闭进程前抓下这些内容当前网络连接、进程列表、登录会话、异常监听端口。用命令直接导出到文件# 取证快照先留网络连接和进程列表再考虑隔离 netstat -ano snapshot_netstat.txt tasklist /v /fo csv snapshot_tasklist.csv query session snapshot_sessions.txtnetstat -ano里的-o会显示每个连接对应的进程PID这个信息对后续定位木马进程至关重要。query session用于查看当前登录会话能发现攻击者是否还保持着一个远程登录。快照文件要立刻复制到安全存储里并记录抓取时间别留在被控主机上否则就是白抓。在拿到快照之后由指挥组决定是否隔离主机。隔离手段优先交换机端口ACL而不是远程关机。断网隔离一定让业务方背签避免被反咬一口。4.2 溯源分析把攻击路径按时间线拉出来溯源不是演习结束后才做的事而是处置过程中同步进行的。处置开始后的第一个小时溯源组就要回答三个问题攻击者从哪里进来的、现在到过哪些机器、有没有留下新的入口。日志是溯源唯一的依据但日志对不齐时间就是废纸。演习开始前第一件事就是把全网的NTP时间校准。很多单位服务器时间差着几分钟平时看不出来一溯源全乱套。校准完再检查核心设备的时间同步状态。溯源实战中最常看的是Windows安全日志里的4624登录事件。通过聚合登录类型、源IP和账号能快速定位异常横向登录# 提取最近50000条4624登录事件按源IP和账号聚合找出高频来源 Get-WinEvent -FilterHashtable {LogNameSecurity; Id4624} -MaxEvents 50000 | ForEach-Object { $ip $_.Properties[18].Value $user $_.Properties[5].Value [PSCustomObject]{IP$ip; User$user; Time$_.TimeCreated} } | Group-Object IP, User | Sort-Object Count -Descending | Select-Object -First 20这里Properties[18]是源IPProperties[5]是登录账号不同Windows版本偶有偏移如果取到空值可以改用XML解析。这个聚合结果并不能直接认定攻击但能快速发现在短时间内从多个IP登录同一个账号的异常模式。网络侧日志同样重要。在防火墙上查目标主机过去几天的所有访问日志看是否有可疑的境外IP或非业务端口的外联。把网络侧和主机侧时间线对齐就能画出一条攻击路径。这个对齐过程比较枯燥但通常能拼出红队的完整动作序列。4.3 上报与跨组同步让决策发生在正确的位置处置过程中最忌讳的是“各干各的最后汇总”。监控组发现情况、研判组定了级、处置组在执行指挥组必须同步知道进展否则一个关键决策延迟几分钟可能就错过最佳阻断时机。我比较推荐结构化上报每次通报固定四要素时间、事件、影响范围、需要什么决策。例子如下表时间事件类型影响范围已采取措施需求决策14:32确认C2外联办公网3台Windows终端已封锁C2 IP已抓取快照待隔离是否通知业务下线系统上报到指挥组的信息不要带“可能、大概”这种词。研判到什么程度就说“已证实、待证实”让指挥组基于事实做决策而不是陪着你猜。每一条上报记录都要留档复盘时就是对得上的证据链。5. 防守方的五个高频翻车现场与排查思路5.1 现象演习第一天告警平台就刷屏研判组根本看不完原因演习前没有做告警基线和白名单处理。外网扫描、内网正常运维动作、补丁分发行为全被当成攻击触发告警平台默认规则全开告警量远远超出人工处理上限。解决演习前至少提前48小时用“准演习流量”跑一遍监控规则把同一来源的扫描告警改成一个归并事件把补丁分发、配置变更、备份任务等周期性运维行为加入白名单白名单要留有证据。如果第一天已经刷屏先停掉低级别扫描告警只保留登录、命令执行、Webshell这个级别的行为。5.2 现象核心服务器被拿下日志系统里找不到对应时段的记录原因网络流量镜像存在断点核心交换机的镜像端口没有覆盖或者服务器时间偏差太大日志到了SIEM里却归到了错误的时段。解决演习前必须做日志连通性测试在一台测试机上模拟外联动作后去日志平台查记录。开始前全网校准NTP时间这一步不能省。如果日志确实丢了只能用网络设备日志和DNS解析记录拼时间线难度大很多所以把功夫花在前面。5.3 现象封了攻击者IP红队依然在内网活跃原因封IP只封了当前看到的那个入口红队往往通过跳板云主机发起攻击甚至已经在内网其他机器上植入后门。单点阻断无法阻止已经完成的横向渗透。解决处置动作必须组合执行封当前攻击IP、禁用被利用的账号、断开目标主机的网络会话、同步查杀文件哈希。封完IP之后继续观察是否有新的外联记录如果有就说明还有未发现的失陷主机要立即扩大排查范围。5.4 现象处置组担心木马运行直接把被控服务器关机溯源时内存证据全没了原因传统故障处理习惯是“先停机再排查”没把取证优先写进处置流程。内存中的数据断电即失连着的会话、解密后的进程信息全部丢失。解决在应急处置流程里明确规定关机前必须完成“抓连接、抓进程、抓登录会话”三个动作条件允许时再做内存转储。这个流程要让处置组每个人都背下来不能靠临场发挥。内存转储工具可以在演习前先装在运维工具包里省得事到临头找不到。5.5 现象复盘时争论“当时那个告警算不算攻击”没有任何结论原因研判过程中没有记录结论告警只是被关掉了没留下“为什么关掉”的依据。复盘时靠记忆还原当时的判断谁也说服不了谁。解决告警平台里把“关闭原因”设为必填字段三选一放行、误报、确认攻击再加一句话理由。这个字段必须在关闭动作之前填写否则无法提交。有了这个记录复盘就变成了翻记录而不是翻账本。6. 演习复盘与防守效能评估一次复盘顶三次演习演习结束后的复盘不能只是把红队攻击报告念一遍然后大伙儿各说各话。我更推荐先做“时间对齐”把红队每个关键攻击动作的时间点跟防守方日志里的检测时间点排到同一张时间线上然后逐段看防守方在哪一步看见了、在哪一步没看见、在哪一步看见了但没反应。这个过程通常比看任何报告都更能暴露问题。防守效能的量化重点看三个指标一是攻击行为的检出覆盖率二是从发现告警到完成阻断的平均时长三是横向移动被切断的段数。处置时长可以直接用演习期间的工单数据算# 统计处置工单的平均耗时CSV列工单号,开始时间,结束时间,状态 awk -F, NR1 $4success { split($2,a, ); split($3,b, ); t1mktime(a[1] a[2] a[3] a[4] a[5] a[6]); t2mktime(b[1] b[2] b[3] b[4] b[5] b[6]); sumt2-t1; n } END { if(n0) printf 平均处置时长: %.0f秒\n, sum/n } response_tickets.csv这个统计依赖gawk的mktimeLinux下一般自带macOS需要换成gawk。时间格式要跟命令行里拆分的顺序保持一致。算完之后你会发现平均处置时长是个特别刺激人的数字那些超过阈值的高耗时工单就是下次演习最该补的短板。复盘输出不要写成几十页的分析报告最终落到一张整改清单就够了。每个问题只保留四列问题描述、根因、整改动作、负责人。整改顺序按攻击路径从入口到核心先补能挡住下次同路径攻击的再优化监控和流程。我带队做第一次复盘时写了整整六页纸真正能落地执行的只有三行后来改成时间对齐加整改清单每次都能在演习结束一周内把整改任务下发完。从那以后我养成了习惯演习期间每天花十分钟记录“当天最大的一个决策失误”只记一条不带评论就是怕到复盘时忘掉。这个习惯保持到现在也算是一颗后悔药希望帮到你。本文还有配套的精品资源点击获取