网络攻击应急预案方案

凌晨三点，网络运维老张被手机告警炸醒。攻击核心业务数据库的应急预案CPU飙到900%，日志里全是网络陌生IP的批量查询请求。等他手忙脚乱登上堡垒机，攻击客户信息表已经被拖走了三成。应急预案事后复盘，网络最要命的攻击不是漏洞本身，而是应急预案从发现到切断攻击链路，中间整整耗了47分钟——没人知道第一步该干什么。网络

这就是攻击没有应急预案的代价。攻击者不会等你准备好再来。应急预案

先搞清楚：谁在打你，网络打到什么程度

别一上来就拔网线。攻击先花30秒做判断：是应急预案DDoS流量洪水，还是Web漏洞被利用，还是内部人员泄露凭证？这三种攻击的处置路径完全不同。DDoS你拔网线等于自杀，业务直接全断；Web入侵你得先保留现场再隔离；内部泄露你封IP没用，得先冻结账号。

我见过最离谱的一次，某电商被撞库，安全团队直接封了整个C段IP，结果把自家CDN节点也封了，全国用户访问全挂。判断攻击类型比急着动手重要得多。

切断链路，但别把证据也切了

确认攻击方向后，第一动作是隔离，不是删除。把受影响服务器从负载均衡摘掉，但别关机——内存里的进程、网络连接、临时文件都是证据。用iptables封攻击源IP，别用防火墙全局黑名单，容易误伤。

有个细节很多人忽略：先改密码，再断连接。攻击者如果已经拿到凭证，你断了他还能重连。顺序反了等于白干。

保留现场，同时恢复业务

这两件事不矛盾。用快照恢复业务，用原始磁盘做取证。云环境下直接对受影响实例打快照，然后从快照克隆一台新机器改配置上线。原始那台关机断网，留着给取证用。

数据库被拖库的情况，恢复业务前先确认攻击者有没有留后门。检查计划任务、启动项、SSH密钥、数据库存储过程。我见过一个案例，运维恢复了业务但没清后门，三天后攻击者又进来了，这次把备份也删了。

通知谁，什么时候通知

别等查清楚了再上报。确认攻击事实后，30分钟内必须同步给业务负责人和法务。涉及用户数据泄露的，法务需要评估是否触发监管上报义务。很多国家有72小时上报窗口，超时罚款比损失本身还高。

对外口径要统一。技术团队别自己在社交媒体上发分析文章，攻击者也在看。你暴露的处置细节，就是他们下一步的绕过思路。

事后：改什么，怎么改

攻击复盘别开成批斗会。重点看三个时间：攻击者从入口到得手用了多久，我们从发现到切断用了多久，业务从中断到恢复用了多久。第一个时间反映防御纵深，第二个反映检测响应能力，第三个反映备份恢复能力。

每次攻击都是一次免费的压力测试。把攻击者的路径画出来，对照自己的安全架构，缺什么补什么。WAF规则、EDR策略、网络分段、权限最小化——这些不是买来就完事，得根据真实攻击数据持续调。

最后说句实在的：应急预案不是文档，是肌肉记忆。每季度拉一次实战演练，不通知时间、不预设剧本。练到运维半夜被叫醒，第一反应是打开预案而不是打开搜索引擎，这事才算成了。