梦双月如果你这几年一直在做网络安全相关的工作，应该能明显感受到一种节奏：每年到了固定的时间段，整个行业就像突然被按下了加速键，群里到处是“被打了”“钓鱼中招了”“IP被封疯了”的实时播报。这个节点就是HVV，圈内通常直接叫它“护网”或者“攻防演练”。很多人第一次接触这个概念时一脸懵，只看到身边同事如临大敌，却搞不清它到底在演什么、攻击方会怎么打、防守方到底该防什么、一旦出事又该怎么处置。这篇文章不聊虚的，就沿着HVV是什么、攻防演练怎么组织、安全防护体系怎么搭、事件处置怎么做这条线，把整套流程完整拆开讲透。
这篇内容适合三类人：一是马上要参加防守方，负责安全设备运营或者应急响应的人，看完能快速建立全局观，知道先从哪里下手；二是刚入行、对HVV只闻其名不闻其详的安全新人，这篇文章可以作为一张入门地图；三是不打算参加HVV，但想把手头安全工作体系化的同行，攻防演练里的很多思路，直接平移到日常防护中同样成立。
1. 先把HVV的底牌翻清楚：它到底在打什么
1.1 HVV本质上是一次“不打招呼”的实战对抗
HVV的全称是护网行动，本质是由监管层面牵头组织的大型实战化攻防演练。跟常规渗透测试最大的区别在于，它不是在授权环境里按部就班地测，而是攻击方带着目标清单，在规定时间段内对真实业务系统发起不打招呼的攻击。防守方只知道自己被划进了演练范围，但不知道攻击队什么时候进场、从哪个入口进场、用什么手法进场，所有应对都必须按照真实网络攻击来处理。
这种模式带来的压力是实实在在的。平时渗透测试漏洞修补是一套节奏，HVV期间完全不是一回事：攻击队有明确的目标分值和攻击周期，每拿到一台服务器、每导出一份业务数据、每控制一台办公终端都有对应产出。防守方一旦被突破关键系统并在裁判那里留下记录，不仅当次演练成绩难看，后续面临的整改压力也会很大。所以很多安全团队在HVV前几个月就开始红温，把压箱底的设备和规则全部翻出来检查。
从周期节奏上看，HVV通常持续一到两周甚至更久，分不同行业、不同级别滚动开展。对抗强度高的方向，攻击队可以说是全天候盯着的，凌晨两三点依然是高危时段。防守方必须保证7乘24小时有人在岗、告警有人处理、封堵有预案，这对团队人员和流程机制的要求都不低。
1.2 参演角色与对抗形态：红队、蓝队、紫队各站各的位
一场HVV里最核心的角色是攻击方和防守方，圈内习惯叫红队和蓝队，此外还有负责评判和协调的紫队或裁判组。把这些角色的任务和考核点提前搞清楚，你才知道自己那摊活儿到底要干到什么程度。
| 角色 | 主要任务 | 核心考核维度 |
|---|---|---|
| 红队（攻击方） | 对目标系统执行渗透测试，包括信息收集、漏洞利用、钓鱼攻击、权限维持、横向移动直至拿下目标业务或数据 | 有效突破数量、目标分值、攻击成功率 |
| 蓝队（防守方） | 负责监测告警、分析研判、封堵溯源、应急响应，防止红队突破核心系统 | 发现率、阻断率、响应时效、溯源反制成果 |
| 紫队/裁判组 | 负责制定规则、评分、判定是否突破成功，同时协调演习进程 | 规则公平性与过程可审计性 |
红队打的是“点”，目标是拿分；蓝队守的是“面”，目标是让红队拿不到分，并且在红队出手时能抓到证据、完成溯源。两者之间的对抗更像是猫鼠游戏，但红队的进攻手段远比日常“跑扫描器”复杂得多，下一节就先把红队的攻击路径完整拆一遍——不知道攻击者怎么打，防守永远只能是盲人摸象。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 红队视角的攻击路线：从外围扫描到权限失控
2.1 攻击起点永远是“踩点找面”，不是直接掏工具打
很多刚接触攻防演练的人有个错觉，觉得红队就是拿着扫描器一顿扫，扫到漏洞直接打进去。实际上的攻击流程要讲究得多。红队进场的第一件事是摸清目标暴露在互联网上的攻击面，包括但不限于域名、IP段、开放端口、Web服务指纹、中间件版本、办公终端入口、常用业务系统，甚至包括员工在公开渠道泄露的账号信息和代码仓库里的敏感配置。
这一步对应的就是你日常说的资产测绘。红队会借助各类测绘平台和扫描工具，把目标企业的互联网暴露资产梳理成一张结构化的表，然后按照重要程度和利用难度排序，选择最容易打出效果的入口。比如某个边缘业务系统使用了老旧的Web框架，或者某个管理后台直接暴露在公网且存在弱口令，这些在红队眼里都是送分题。
所以在防守视角下，暴露面收敛永远排在所有工作之前。你连自己有多少系统挂在公网上都说不清楚，后面安全产品堆得再高、规则写得再多也是白搭。同一个IP段里如果存在无人认领的“影子系统”，红队花半天时间就能把它变成跳板，你要花几周才能反应过来业务已失守。
2.2 红队最常撬的“门”：弱口令、钓鱼、应用漏洞一个都不少
进入实战阶段后，红队打进去的路径集中在几类：弱口令爆破、钓鱼攻击、应用层漏洞利用、第三方设备或内网应用漏洞。可以这么说，红队投在钓鱼和口令爆破上的精力，往往比直接挖0day要多得多，因为这两件事成本低、命中率高。比如针对远程办公系统的账号爆破，针对运维后台的弱口令尝试，一旦成功就相当于拿到了一把开门钥匙。
钓鱼攻击在HVV期间也是重灾区。红队会精心构造钓鱼邮件，把木马程序伪装成简历、报销单、会议邀请、升级补丁，甚至直接压缩包绕过网关检测。如果员工没有足够的安全意识，双击后门之后，红队就获得了内网终端的初始权限。这之后再配合系统提权和横向渗透工具，攻击者就能逐步深入到核心业务服务器。
应用层漏洞利用方面，重点依然是文件上传、SQL注入、未授权访问、反序列化这类传统但对业务系统杀伤力极大的问题。很多企业以为上了WAF就万事大吉，但WAF配置不当、规则不全、存在绕过路径的情况非常普遍。红队对WAF的绕过手法甚至已经模块化，常规产品能力根本挡不住。
2.3 攻破一台机器不是终点，横移和内网渗透才是重头戏
红队拿到第一台机器的权限，只代表攻击进入下半场。接下来他们会迅速做权限提升、抓取系统内的凭据和哈希，然后通过内网扫描寻找更多机器，一步一步向核心区和数据区推进。这个过程叫横向移动，也是蓝队防守压力最大的阶段。因为攻击流量已经混入内网正常流量中，特征不明显，非常考验流量监测和主机agent的检测能力。
为了不掉线，红队还会做权限维持。Web服务器上可能被上传webshell，中间件里可能被注入内存马，主机上可能被写入计划任务、注册表自启动项、免杀的持久化后门。有些攻击队甚至会利用合法工具做“白加黑”，让防守方的封禁措施无从下手。
当你发现一台机器失守时，红队很可能已经在里面待了几个小时，甚至已经控制了几台关键服务器。这就是为什么事件处置要求“发现即响应、响应即溯源”，时间拖得越长，影响面就越大。接下来就从蓝队视角看，防守体系到底该怎么搭。
3. 蓝队防守不是堆设备：先盘资产，再谈监测
3.1 第一步永远是清理家底：资产、账号、暴露面
防守方最容易犯的错误是一上来就折腾安全设备，把WAF规则调了半天，但连资产清单都不完整。评估一家企业的防守水平，我最先看的就是资产清单和对应的责任人表。没有资产清单，就没有办法准确评估风险等级；没有责任人，告警出来了都不知道该找谁确认业务影响。
资产梳理至少包含三类：网络资产（域名、IP、端口、协议）、应用资产（Web系统、业务后台、API接口）、人员权限资产（系统账号、远程接入账号、高权限账号）。攻防演练开始前，最好把每一台互联网暴露设备、每一个公网应用都过一遍，确认是否仍然在运行、是否存在弱口令、访问控制策略是否有效。尤其是那些开发测试环境、演示环境、已经停用的老系统，是真正的重灾区，红队最喜欢打这种“被遗忘的边界”。
账号权限层面也要做收敛：高权限账号是否存在多人共用、离职人员账号是否还在活跃、运维账号是否开启了双因子认证。HVV期间可以临时执行更严格的策略，比如对敏感系统的登录增加二次验证、对内部高危操作执行审批流程。对于Web应用，特别要检查认证与会话管理机制，严格设置Cookie的HttpOnly、Secure、SameSite属性，防止攻击者通过XSS窃取会话后直接接管管理员账号。
3.2 第二步把监测网络铺开：流量、主机、日志一个不能少
资产梳理完之后，安全监测才谈得上落地。实战中一个比较实用的监测架构是分层部署：边界出口网络流量由流量检测设备负责，业务服务器和办公终端部署主机型EDR，Web系统前置WAF，再把这几个维度的告警统一接入安全管理平台进行关联分析。
很多团队把设备买回来接上线就以为完事了，真实问题往往出在日志上。比如攻击者已经在Web服务器上留下webshell，但访问日志没有记录POST请求体，导致无法还原攻击路径；又比如核心数据库从未开启审计日志，攻击者拖库之后你连他执行过哪些语句都不知道。所以在HVV前，必须检查关键设备的日志策略是否完整、日志留存周期是否覆盖整个演练期间，至少保证流量日志和登录日志能追溯，不要等应急的时候才发现日志是空的。
告警规则也不建议一上来就全量打开，海量低质量告警会把团队淹没，真正的高危攻击反而被漏过去。正确的做法是梳理出高危事件清单，按优先级设置监测规则，比如异常登录、WebShell上传成功、内网扫描行为、敏感文件读取、C2外联等，确保每一条告警都有明确的人去跟进处理。热点方向可以借鉴：Cookie安全与Web权限控制是攻防双方都盯着的焦点，凡是涉及登录态校验的接口都要重点录日志，关键会话变化甚至要比对到具体账号和来源IP。
3.3 第三步用欺骗防御主动制造“陷阱”，反打红队一手
防守不能永远被动等告警。一场成功的HVV防守，往往有蜜罐体系的参与。蜜罐的作用不是直接拦截攻击，而是让攻击者误入陷阱，暴露其攻击工具和手法，同时也为溯源采集样本。比如在办公网里部署模拟的运维后台、数据库跳转节点，一旦有非正常的访问流量被导流到蜜罐，就可以确认内网已经有人进来了。
蜜标的思路也值得实践：在系统里放置一些包含特定格式账号密码的诱饵文件，攻击者横向移动时大概率会去尝试这些口令，一旦命中立马触发高优先级告警。这种主动猎杀机制能把防守视角从“等告警”转变为“找异常”，特别适合HVV这种高强度对抗阶段。
当然，蜜罐本身也会暴露，不能被当成万能解药。它更多是监测体系之外的补充项，重点价值在取证和溯源，不在直接阻断。真正常规防线还是那套“收敛暴露面、补强认证、全量日志、快速响应”的硬功夫。
4. 告警拉起后的应急响应：一次事件处置的完整闭环
4.1 确认、定级、分工：事件处置头15分钟别乱
无论防守体系铺得多完善，HVV期间总会有告警进来。真正拉开团队差距的，是告警出现之后头15分钟到半小时的处置节奏。缺少流程的团队会陷入一片混乱：有人去查日志、有人去翻设备、有人去打业务部门电话，最后连决策人都没定。正常流程应该是一条清晰的流水线。
第一步是确认告警真实性，判断是误报还是真实攻击。这一步最常用的手段是直接查看原始日志和请求包，结合威胁情报源确认攻击来源IP是否存在恶意标记。第二步是评估影响面，快速判断这个问题只涉及单台主机、某个业务模块，还是已经扩散到内网其他区域。第三步是明确角色分工，应急负责人在哪、技术人员在哪、业务联系人是谁，必须在演练前就确定下来，不能出事后再现找人。
可以提前把告警分级做成一张表，贴在SOC大屏旁边，遇到告警直接对照定级，大家对需要多快的响应节奏心里有数。
| 告警等级 | 典型场景 | 响应要求 |
|---|---|---|
| 紧急 | 确认攻击者已进入核心系统、发现内存马或后门 | 10分钟内处置，立即隔离受影响主机 |
| 高 | 发现可疑WebShell上传、账号异常登录 | 30分钟内完成阻断和取证 |
| 中 | 批量扫描、弱口令爆破尝试 | 2小时内处理，加强监测 |
| 低 | 单个IP触发规则、疑似误报 | 当日确认并关闭 |
4.2 应急响应五步法：切断、取证、清除、恢复、溯源
把定级和分工理清之后，事件处置动作基本可以概括为五个步骤，这也是我在一线处理安全事件时一直在用的框架。
第一是切断，也叫隔离。确认失守主机后要立刻操作，优先断开网络连接或者通过防火墙封禁源IP，防止攻击者继续横向移动。注意隔离动作要快但也要留有余地，不要立刻重装系统，否则后边取证就没办法做了。第二是取证，这一步特别关键。要把内存中残留的进程信息、网络连接、账号会话、Web日志、样本文件全部保留下来，至少做一份完整的快照和日志导出，确保攻击路径可以被还原。
第三是清除，也就是删掉已发现的WebShell、恶意计划任务、异常注册表项、免杀后门文件。清除时要排查全面，不能只删一个入口文件就完事，攻击者往往会准备多个备用通道。第四是恢复，确认系统干净后，针对漏洞和弱口令完成修复，再重新接入业务，同时加强该系统的监测强度。第五是溯源，把所有证据串成一条完整的攻击链：来源IP、攻击手法、时间线、影响范围，最后输出报告。对手为什么进得来、我们有哪些环节没拦住、下一步要补什么，都要在报告里写明白。
4.3 实战回放：一次WebShell事件从发现到收尾
为了让这套流程更直观，我放一个实际处置过的WebShell事件的缩略版过程。某个HVV期间的下午，WAF突然告警，一条外网IP对某台业务服务器的POST请求命中“可疑上传”规则。应急人员第一时间打开访问日志，发现这一条POST请求后紧接着出现了执行命令动静，初步判定为真实的文件上传攻击。
随后团队把源IP加入封禁黑名单，同时通过EDR平台对该服务器做进程排查，在Web目录下发现一个带图片马头部的JSP文件，确认是WebShell。服务器随即被隔离，技术人员导出了最近六小时的Web访问日志、EDR操作日志、进程快照。通过日志比对，确认攻击者只上传了WebShell，没有进一步提权和横向动作，影响范围被控制在单台服务器。
接下来就是清除文件、修补对应上传接口的校验逻辑、升级WAF规则，之后对全网服务器做了排查，确认没有其他同类样本后重新恢复了业务。最后输出事件报告，说明攻击者利用的是一个老系统的文件上传缺陷，该缺陷的修复补丁其实一个月前就发布了，但因为系统归属模糊，迟迟没有落实。整场处置用了大约两个小时，问题不算难，但暴露出的资产管理漏洞比漏洞本身更值得警惕。
5. HVV之外的日常功课：把演练逼出来的能力沉淀下去
5.1 演练之后最该补的不是设备，是流程和习惯
每次HVV结束，很多团队都会松一口气，然后迅速回到原来的节奏里。但说实话，每年演练暴露出的高频问题几乎都是那几类：资产管理混乱、日志不完整、弱口令痼疾、补丁更新滞后、内部人员安全意识薄弱。这些问题不是演练期间临时生成的，而是日常工作欠下的债。
如果赛后只写一份报告交差了事，明年大概率还会在同样的地方栽跟头。更实际的做法是从问题清单里挑出三项影响最大的，列入整改计划：比如把暴露在公网的无人认领系统全部下线；把关键系统的远程访问全部改成强认证加固；补全核心业务的日志采集，确保至少能够回溯一个月内的攻击痕迹。整改完成后，最好再做一次小规模的复测验证，确认修复措施真的生效了。
5.2 把攻防演练变成常态化机制，而不是一年一次的突击战
把视角拉远一点，HVV真正有价值的地方在于，它把安全团队从被动修修补补的状态硬生生逼成了一支能打仗的队伍。如果能把这种状态延续到日常工作中，比演练拿多少分都重要。我个人比较推荐的做法是，每隔一个季度就组织一次小范围的红蓝对抗，不用搞成大规模的HVV，就找两三个人扮演攻击方，对核心业务做一轮有重点的测试，检验当前的安全防护水平。常态化对抗能暴露出很多设备配置上的问题，也能让应急处置的流程保持熟练度，不至于每次都是临阵磨枪。
日常运营里还建议坚持几个习惯：每周核对一次资产变更记录，确认没有新增的未知系统；定期审查账号权限，清理长期未使用的比测账号和高权限账号；对Web应用重点检查会话管理、Cookie安全属性、后台权限控制逻辑，这些都是红队最常利用的薄弱环节。像comfy+ui这类通过Web化部署的内部工具系统，也要纳入权限管理，不能因为是办公辅助工具就跳过认证和访问控制。安全没有一劳永逸，只能在一次次对抗中不断修正。
最后再分享一点个人体会。干了这些年安全，参与过不少攻防演练，我最深的感受是：真正决定防守水平的往往不是买了多贵的安全产品，而是团队对自身资产的了解程度、对告警的响应速度、以及问题出现之后敢不敢直面而不是掩盖。HVV不过是一面镜子，把平时忽视的问题照得清清楚楚。如果你今年还没开始准备，不用焦虑，从资产清单开始，其他的都可以按优先级一步步来。