简介攻防演习防守技术方案PPT系统梳理了HW护网行动中防守方所需的核心知识与落地路径面向政企单位安全运维、应急响应及参与红蓝对抗的防守人员帮助其理解演习规则、攻击战术与体系化防御建设。压缩包共1个文件PPTX格式约20.15MB内容结构完整涵盖攻防演习概念、演变过程、攻击手段、防守方认知、安全防御体系化转变等主题并延伸出五点演变、四点成绩、九个关键举措及案例介绍。方案结合HW2016—HW2020实战数据展示演习从实验阶段到推广阶段、参演单位由2家扩展至148家、攻击队突破100支的演变同时逐类解析物理设备攻击、大型内网跨区域攻击、集权类设备攻击、供应链攻击、邮箱攻击、免杀加密隧道、钓鱼水坑、周边WIFI以及安全产品与IOT设备漏洞利用等攻击手法并给出安全加固、SOC、流量威胁检测、威胁情报、主机威胁检测、蜜罐等主流防护措施防守评分也从终端失陷、边界失陷、目标系统失陷等扣分项转向发现攻击、消除威胁、追踪溯源等得分项。这些内容无论用于备赛护网、组织内部攻防演练还是完善重保期间的安全保障策略都具有直接参考价值。目前已有1502人学习下载。1. 攻防演习防守技术方案一份PPT凭什么决定演习成败攻防演习防守技术方案听起来像是一份用来汇报的PPT但实际上它决定的是演习期间整个防守团队的作战方式。演习开始后所有流量告警、应急封禁、攻击路径研判、上报节奏都围绕这份方案展开。见过太多团队方案做了上百页资产台账、拓扑图、组织架构写得满满当当结果演习第一天就被攻击队通过一个没登记的云上实例打了进来。问题不在演习本身而在方案只写了“有什么”没写清楚“出事怎么办”。这份方案真正该解决的是三件事第一攻击队可能走哪几条路径进来第二每条路径上谁在看、谁在拦、谁在报第三发现到处置之间每一步多久必须完成。适合谁读正准备参加攻防演习的安全工程师、蓝队队长、运维和平台负责人以及要把防守工作落到人和工具上的团队负责人。想看懂一份防守方案的价值先得知道它是一张作战地图而不是一份资产说明。2. 从高危端口到内网横移防守方案的攻击路径拆法2.1 站在攻击队视角重画网络拓扑防守方案最常见的翻车点是网络拓扑图画成了机房接线图。交换机、防火墙、服务器之间连线画得清清楚楚但攻击队根本不看这些。攻击队眼里的网络拓扑只有三种节点打得进去的、打不进去的、打进去以后能摸到核心数据的。画拓扑的时候要按这个逻辑来。常见做法是先拉一遍全量资产清单然后把资产分成三组入口面、内网面、目标面。入口面包括Web站点、API网关、邮件系统、堡垒机这类能被互联网访问的系统内网面包括办公网、生产网、测试网里的主机和业务系统目标面是核心数据库、备份系统、运维审计平台这类攻击队最想拿的东西。分组之后重新画一张图不画设备连线只画可达关系哪些入口能到达哪些内网网段哪些内网主机能访问目标面。这张图才是防守方案的底图。我一般会要求团队在方案里把每一组资产标上“暴露范围”和“影响范围”。暴露范围指这个系统面向谁开放影响范围指它一旦被攻破能碰到的其他系统。很多团队只登记了IP和端口没登记这两项结果攻击队拿下一台测试机后沿着信任关系直接迁回了生产网方案里完全没有这条路径。2.2 攻击路径拆解入口、横移、目标的三段论把攻击过程拆成三段来看防守方案才写得清楚。第一段是入口突破攻击队在这个阶段做的事情包括Web漏洞利用、弱口令猜解、钓鱼邮件、供应链接口打点、历史漏洞复现。第二段是内网横移拿到第一台主机后开始扫描网段、抓取口令、复用密码、利用内网漏洞跳转。第三段是目标获取横移到核心数据区拷数据或破坏业务。每一段对应的检测手段和阻断手段完全不同。入口阶段主要靠边界防护设备和访问日志横移阶段主要靠主机侧行为监测和东西向流量分析目标阶段靠数据访问审计和数据库防火墙。很多防守方案只写了入口防护边界WAF和IPS配置写得详细但内网横移的章节几乎空白。攻击队只需要突破一次剩下的时间都在内网里慢慢挪。横向监测缺失等于把后面两段战场直接让了出去。表攻击路径与防守控制点对照攻击阶段典型手法优先检测点阻断动作责任角色入口突破Web漏洞、弱口令、钓鱼WAF告警、登录日志、邮件网关封禁来源IP、下线漏洞端口边界运维组内网横移口令复用、漏洞利用、扫描探测内网扫描告警、异常连接、账号行为隔离主机、重置口令、收紧ACL主机安全组目标获取数据外传、数据库导出、备份拷贝数据访问量异常、大流量外发阻断外联、暂停备份任务数据安全组2.3 把路径写成防守控制点一个表格模板路径拆完以后下一步是把每一条路径翻译成防守控制点。控制点不是监控项而是一个完整的小闭环能看到什么、能拦什么、由谁负责、多久响应。方案里每个控制点至少要回答四个问题观测源是什么告警规则是哪条封禁或隔离动作在哪台设备上做执行人是谁。缺任何一个这个控制点在实战里就是摆设。我习惯让团队用一张表管理全部控制点。这张表直接放进防守方案PPT里演习期间每天对照更新。表格模板防守控制点登记表编号攻击阶段路径描述观测源检测规则阻断方式执行人响应时限P-001入口突破互联网访问Web管理后台WAF日志后台路径高频访问封禁来源IP 24小时张工10分钟P-002内网横移敏感端口全网扫描主机安全Agent同IP扫描超过50个主机隔离源主机李工15分钟P-003目标获取数据库批量导出数据库审计单会话导出行数超阈值断开会话并冻结账号王工5分钟这个表格看起来简单实际填起来最花时间。每个控制点都要先验证观测源是否覆盖比如要检测数据库导出异常前提是数据库审计日志确实接收到了所有数据库实例的流量。方案里写十个控制点不如现场验证过五个。写完表格以后逐条模拟一次把攻击命令真的跑一遍看告警能不能出现。这一步做完方案才算从文档变成了作战工具。3. 把防守方案落成任务清单监测、阻断、上报的衔接点3.1 防守任务清单的五个维度一份能执行的防守方案最终必须落到任务清单上。常见做法是把防守工作拆成五个维度监测、研判、阻断、上报、恢复。每个维度都要写清楚由谁做、用什么工具、多长时间完成。五个维度缺了任何一个方案就会出现断层。监测负责发现异常研判负责判断是不是真攻击阻断负责把攻击掐断上报负责让指挥组知道发生了什么恢复负责把业务和服务拉回正常状态。很多方案只写了前三个上报和恢复完全没提。结果攻击发生后一线人员花了一个小时确认处理结果指挥组还在等消息业务那边因为封禁误伤急着找人恢复。这五个维度应当按时间顺序串成一条流水线前一个环节的产出正好是后一个环节的输入。3.2 监测层落地日志源、告警聚合、研判闭环监测层是整个防守方案的感知基础。监测不是把告警收得越多越好而是把该看的流量和日志都看进来。演习前必须做一次日志源核对确认几类关键日志没有缺口边界流量日志、WAF日志、主机登录日志、数据库访问日志、DNS解析日志、邮件网关日志。每一类日志对应攻击链上的一到两个环节缺一类攻击队就可能从那个方向偷偷溜进来。日志源核对完以后还要解决告警聚合的问题。演习期间最怕的不是没告警而是一条攻击命令触发十几种设备同时告警。常见做法是把告警按源IP、目标IP、攻击特征三个维度归并把同一事件的告警收成一条工单再进入研判流程。研判闭环要写成“三人一组”一人看告警、一人查上下文、一人出结论。手里只有一条孤立的告警很难定性查一下同类日志里有没有其他异常行为远比自己盯着一个IP猜来得可靠。监测层落地时我一般会把日志检索命令备好以安全分析平台的检索为例查单个来源IP所有行为可以这样写sourcetypefirewall src_ip10.20.30.40 sourcetypehost_login src_ip10.20.30.40 actionfailed sourcetypedns_query client_ip10.20.30.40第一条看该IP触发的防火墙记录第二条看登录失败情况第三条看解析请求是否指向可疑域名。三条结果放在一起基本能拼出攻击队的行为轨迹。注意这里要确认检索字段名跟自家日志平台一致不同平台字段叫法差别很大直接把别人的检索语句拿过来用常常查不到数据。3.3 阻断层落地封禁、下线、降权要写到人阻断动作写进方案时不能只写“对攻击IP进行封禁”。封禁涉及谁来执行、在哪台设备执行、封禁多久、封禁后谁来验证、误伤业务怎么办。五件事缺一件演习现场就会乱。常见做法是按动作类型建立标准操作卡每种动作用一小段话描述操作步骤和确认方式。封禁IP的操作卡要写清楚登录防火墙或云安全组的方法、封禁命令示例、验证封禁生效的方法和解除条件。隔离主机的操作卡要写清楚通过管理平台下发隔离指令的路径、确认主机已断网的方式、恢复上线的审批流程。重置账号口令的卡要写清账号范围、重置后如何通知业务方、是否需要暂停业务。降权账号的卡要写明临时降权与回滚的权限归属。这些操作卡是防守方案里最容易被跳过的内容恰恰又是实战中最救命的部分。演习开始以后现场人员没有时间翻操作手册能让他们停下脚步的只有标准操作卡上的那几行字。方案里多花两页写操作卡比多写十页安全理念有用得多。3.4 上报与指挥协同信息同步的节奏和模板上报机制写得好不好直接决定防守方是主动还是被动。常见做法是分三级事件上报一般事件、重大事件、紧急事件。一般事件指单个IP扫描、单次登录失败一线人员处置后记录即可重大事件指疑似漏洞利用成功10分钟内上报指挥组紧急事件指已确认主机失陷或数据外传5分钟内电话上报并启动应急预案。上报模板要固定下来方便现场快速填写。模板内容包含时间、事件类型、影响范围、是否失陷确认、已执行的处置动作、当前状态。建议直接把模板做成表格放进方案附件演习期间第一时间复制填写。指挥组每天还要有一个固定时间统一同步各小组战果比如每天14点和20点召开十分钟短会只报新增事件、未闭环事件和需要跨组协调的问题不汇报过程细节。信息同步的节奏定了指挥才不会乱。4. 防守技术方案里的硬参数阈值、频控和研判时限怎么定4.1 流量侧的关键阈值参数防守方案里最容易被拍脑袋定下来的就是各种阈值。阈值设得高攻击队在里面横着走都触发不了告警阈值设得低告警风暴直接把人淹没。流量侧有几个关键参数需要在演习前用两周左右的基线数据校准。连接建立速率是第一个要校准的参数。正常业务高峰时单台服务器每秒钟新建连接数是多少演习期间如果超过均值的三倍一般需要告警。这个三倍不是拍出来的是通过分析历史峰值和业务促销场景后取的一个安全余量。单源IP触发IDS告警的次数也要设频控同一个源IP十分钟内触发超过五次相同规则自动升级为严重告警否则按普通事件处理。表流量侧关键参数建议值参数建议初始值校准依据调整方向单台服务器连接建立速率历史均值的三倍业务高峰期流量误报多就上调漏报多就下调单源IP触发同类告警频控10分钟内5次扫描行为与正常业务比例扫描多就收紧到3次异常外联流量大小单会话超过200MB正常业务外传基线按业务类型分端口单独设这里要说一个关键思路阈值永远是一个区间不是一个死数字。演习第二天发现某个业务系统正常同步数据就会触发大流量告警那就需要按业务特征单独加白名单而不是把全局阈值调高。全局阈值一旦调高攻击队的大量异常行为也会跟着漏过去。4.2 主机侧和内存马的检测参数主机侧参数比流量侧更细也更依赖终端安全产品的具体实现。内存马是近几年攻防演习里最让防守方头疼的技术隐蔽性高传统文件查杀经常看不到。对付内存马的方案里一般要配几个参数内存马扫描频率、进程行为告警阈值、文件变更监控范围。内存马扫描频率建议在演习期间调整为每十五分钟一次平时一天一次就够了。进程行为方面重点看两个特征Java进程启动非标准子进程、进程外连异常端口。一旦命中这类行为直接升级为严重告警。文件变更监控要覆盖Web目录、临时目录和系统启动目录变更事件超过三个文件同时发生时默认按可疑事件处理。主机侧的登录失败锁定策略也要提前定好。常见做法是同一账号五分钟内失败五次就锁定十五分钟。这个参数既要防止攻击队暴力破解又要防止误伤正常运维人员。账户锁定后需要明确解锁流程否则攻击队故意触发锁定机制会把运维人员自己锁在外面制造混乱。4.3 研判时限与响应SLA必须写进方案的约定研判时限是防守方案里最接近管理契约的内容。它规定了从告警产生到确定是不是攻击中间最多能花多少时间。很多方案只写了告警规则和阻断方式没写时限结果演习现场一个告警在群里转了三圈没人接。没有时限的流程执行起来就是空转。建议按三个等级设定SLA高优告警5分钟内完成首次研判并给出结论中优告警15分钟低优告警30分钟。首次研判可以只定性为“疑似攻击”“确认攻击”“误报”三种状态之一详细的攻击目的分析可以后续补。阻断动作的SLA从研判确认开始计算高危攻击5分钟内执行封禁或隔离中危15分钟。这个时间表要写进防守方案的控制点表格里并在演习前演练一次。SLA还必须包含解除条件。封禁攻击IP后如果确认业务误伤谁有权解除、解除前要不要审批方案里要有明确约定。没有解除条件的封禁是危险的动作演习还没结束业务先被自己的防守方案打断了。把解除条件提前写清楚相当于给每个阻断动作留了后悔药。5. 防守技术方案避坑五个让防守行动变表演的常见翻车点5.1 翻车点一资产清单漏了云上临时实例现象演习期间告警平台突然跳出一台完全没登记过的主机攻击队已经从这台机器上开始内网扫描了。原因资产盘点只翻了台账和申请记录没对照云平台控制台实际列表核对。现在很多业务团队喜欢临时开一台云服务器测试用完不销毁台账上永远没有它。解决演习前一周做一次全网资产实测用扫描工具对出口IP段全量探测再跟管理平台里的资产清单逐条核对发现不一致的资产当场确认用途。防守方案里要写一条规则演习期间任何人不得私自开通新的云主机确需开通必须向指挥组报备并纳入监控范围。5.2 翻车点二告警风暴压垮研判现象演习第二天早上告警平台推送了一万两千条消息研判组三个人从早忙到晚真正有用的攻击情报全被淹没了。原因阈值全部按厂商默认配置设置的内网一台主机被攻击队用来扫了一遍网段触发了上千条相同告警每条都单独推送。解决演习前必须完成告警降噪和归并。把相同源IP、相同目标网段、相同攻击特征的告警合并成一条事件同时对已知的内网扫描行为建立基线正常范围内的扫描降级处理。告警平台要建立“事件”和“原始日志”两个层级研判人员只盯事件层原始日志留待需要深挖时再查。5.3 翻车点三攻击队从第三方接口打进来防守方看不见现象攻击队没有直接打防守方任何系统而是通过合作单位的一个接口拿下了权限再顺着接口业务流进到了内网。原因防守方案里把监测范围限定在了自己管理的IP段和设备上没覆盖跨机构之间的链路。解决演习前梳理所有与第三方系统的接口明确接口的数据流向和访问权限。第三方接口链路必须纳入边界监测范围至少保证接口入口和出口两侧的流量都能被记录。同时要和第三方约定应急联系人演习期间一旦发现异常接口流量能第一时间联动处置。这条往往是最容易被忽略、代价又最高的路径。5.4 翻车点四应急预案只写了封禁没写验证和解除条件现象一线人员封禁了一个来源IP过了一个小时业务方开始投诉访问异常。查下来发现被封的IP段里包含办公网出口的地址攻击队用了同段的其他IP访问业务防守方的封禁恰好把正常用户也拦在门外。原因写预案时只考虑了“封住攻击”没考虑“封禁后的验证”和“误伤的解除路径”。解决每个阻断动作后面补两步封禁后的5分钟内验证攻击源是否确实无法访问目标同时检查该IP段是否包含正常业务流量确认无业务影响。解除条件明确写成三行该IP连续30分钟无攻击行为、业务方确认受影响、指挥组同意。三条全部满足才能解封。5.5 翻车点五复盘只对时间线不对根因现象演习结束后的复盘报告写了二十页全是时间线9点01分收到告警9点10分上报指挥组9点35分完成封禁。但被攻击的Web系统为什么存在未修复漏洞没人回答。原因复盘变成了“流程走查会”大家只关心谁慢了谁快了没人关心技术层面的根因。解决复盘必须强制带上根因分析环节。每个溯源出来的漏洞都要回答三个问题这个漏洞为什么存在为什么没有被发现下次怎么做才能不让它再出现。写根因时用连续追问的方式比如“Web后台为什么暴露在互联网上”追问到“端口映射申请时没有安全审核环节”问题才算真正找到。6. 演习结束后才有价值复盘模板与三个验证技巧演习结束不等于防守工作结束。真正让防守方案有价值的动作是在复盘阶段把演习中发生的事件重新拉一遍验证每个处置动作是否真的有效。我现在的复盘习惯是固定用一张模板按“时间、事件、发现时间、研判结论时间、处置完成时间、根因、验证结果”七个字段记录每一条线索。不需要写长篇分析但每个字段都不能空。验证结果这一栏写的是封禁之后攻击源是否还能访问目标漏洞修复后是否还能复现这个字段只填“已验证”或“未验证”不允许填“待跟进”。表攻防演习防守复盘模板时间事件发现时间研判完成处置完成根因验证结果第2天 09:01后台路径高频访问09:0109:0709:12后台未做访问控制已验证复盘阶段我常用三个验证技巧。第一个技巧是攻击路径复现挑选演习期间被攻击队实际利用过的路径在隔离环境重新演示一次完整攻击过程看当前的封禁策略和监测规则能不能拦住。第二次可能仍然拦不住但这时候发现漏洞总比下次演习再被打穿要好。第二个技巧是日志完整性自检随机挑演习中某台主机的某个时间段对比各平台日志条数是否一致防止出现日志侧漏了关键线路的情况。第三个技巧是基线对比把演习期间调整过的阈值和默认值放在一起对比确认哪些改动应该保留、哪些应该回滚。这类工作看起来不显眼但它是防守能力从一次演习积累到下一次演习的路径。以前我参加一次演习处置完告警就收工了结果下一次同样的问题换一个入口又出现一次。后来把验证环节补上每次至少复测一遍已确认的攻击路径团队对“封禁到底有没有生效”这件事有了确定答案不再是凭感觉说话。防守方案的价值从来不在PPT本身而在方案里的每个动作能不能经得起下一次攻击的检验。希望帮到你。本文还有配套的精品资源点击获取