网络安全事件漏洞应急预案

凌晨三点，网络运维老张被手机报警炸醒。安全监控大屏上，事件一台边缘节点的漏洞CPU飙到100%，日志里滚出一串从没见过的应急预案反序列化请求。他干了十五年运维，网络头一回见攻击载荷里夹着公司内网才用的安全API密钥。这不是事件演习，是漏洞有人已经踩进后院了。

漏洞应急，应急预案最怕的网络不是漏洞本身，是安全“不知道谁在打、打到哪了、事件下一个目标是漏洞谁”。很多团队一上来就急着打补丁，应急预案结果补丁还没推完，攻击者已经横向跳到数据库。我的经验是：先断血，再止血，最后缝针。断血就是隔离——把受影响主机从核心网络里摘出去，哪怕业务暂时挂掉。去年一家电商被Log4j2打穿，他们第一时间做的不是修，而是把整个支付网关的出口流量切到蜜罐，攻击者后续的扫描全打在假服务上，真数据一点没丢。

应急流程得写成人话，别搞成ISO文档。我见过一份预案，光“事件分级”就列了四页表格，真出事时没人翻。有用的预案就三块：谁打电话、谁拔网线、谁对外说话。具体点——值班手机响三声必须接，接完直接拉一个语音会议，安全、运维、业务三方进来。安全的人负责看流量和样本，运维的人负责快照和隔离，业务的人负责决定哪些接口可以临时下线。别让一个人既查日志又做决策，脑子会炸。

漏洞验证这块，别迷信扫描器。扫描器报“可能存在”和“已利用”是两码事。我习惯直接抓攻击者的请求包，在测试环境重放。能弹shell的，优先级拉满；只是报错回显的，排后面。有一次某OA系统报了个SSRF，扫描器标高危，实际重放发现只能读本地文件，且目录权限卡死。我们压到第二天修，先处理另一个能直接写webshell的。判断标准就一条：攻击者能不能从外部直接拿到服务器权限。

补丁管理有个坑：别一次全推。先拿一台非核心业务机试，跑二十四小时看有没有业务异常。去年某银行推Struts2补丁，测试环境没问题，生产一推，老交易系统直接白屏——因为补丁改了序列化行为。后来他们改成灰度，每次只推百分之五的节点，出问题立刻回滚。回滚脚本得提前写好，别等出事再现编。

沟通这事最容易被忽略。攻击者可能已经在数据里埋了后门，你这边还在群里发“已修复”。对外口径要统一，别让客服瞎猜。我参与过一次勒索软件事件，公关部提前准备了三句话：系统维护、数据未丢失、恢复时间待定。结果攻击者自己发了勒索信，公关那三句话反而成了笑话。后来学乖了——先内部对齐事实，再决定说什么。没查清楚之前，对外只说“正在排查”。

最后说个反直觉的：应急预案里必须写“什么时候放弃”。如果攻击者已经拿到域控，且你确认没有备份能恢复，那就别硬扛。拔电源、保现场、找执法。硬扛只会让攻击者删更多数据。我见过一个团队死磕了三天，最后发现备份也被加密了，白白错过报警时间。

漏洞应急不是比谁修得快，是比谁少犯错。少犯错的办法就一个：平时拿真实攻击样本做演练，别用扫描器报告糊弄自己。演练时把监控关掉，看值班的人多久能发现。超过十分钟，预案就得改。