网络攻防应急预案

```html

凌晨三点，网络监控大屏上突然跳出一片红色告警——某台核心业务服务器的攻防出站流量在十秒内飙到 1.2 Gbps。值班的应急预案同事后来说，他当时第一反应是网络“这破监控是不是又抽风了”。但抓包一看，攻防全是应急预案加密的 DNS 查询，目标地址指向一个从没见过的网络域名。这不是攻防演练，是应急预案真实的 DNS 隧道攻击，数据正在被往外抽。网络

网络攻防这件事，攻防预案如果只停留在纸面上，应急预案真出事的网络时候连第一分钟都扛不过去。我见过太多团队把“应急预案”写成了八股文，攻防什么“立即上报”“组织分析”“启动响应”，应急预案全是正确的废话。真正管用的预案，得从“谁第一个看到告警”开始写起。

谁在值夜班，比什么流程都重要

很多公司把安全监控外包给 NOC，但 NOC 的兄弟们只认“服务器宕机”“端口不通”这类硬故障。流量异常？他们可能觉得是业务高峰。一个真实的教训：某电商大促前夜，攻击者用慢速 HTTP 攻击打瘫了推荐服务，NOC 看到 CPU 高但没报警，因为阈值设了 95%，而攻击者故意压在 92% 跑。等业务方发现推荐结果全空的时候，已经过去四十分钟。

所以预案的第一页不该是流程图，而是一个具体的人名和手机号——谁在凌晨三点能拍板决定“拔网线”。这个人不需要懂技术细节，但他得知道：什么情况下可以牺牲可用性换安全。没有这个授权，一线工程师不敢动手，只能眼睁睁看着数据流走。

隔离不是拔电源，是精确断腕

去年帮一家制造业客户做复盘，他们被勒索软件加密了财务系统。值班工程师的反应是“赶紧把服务器网线拔了”。结果呢？财务系统是双机热备，拔了一台，另一台还在被加密；更糟的是，拔网线导致数据库事务日志损坏，恢复时多花了两天。

正确的隔离动作应该是：先看交换机端口，用 ACL 封掉受感染网段到核心交换的流量，而不是物理断网。如果交换机不支持动态 ACL，那就关端口——但得提前把端口和业务映射表打印出来贴在墙上。别笑，真出事的时候，没人有空去查 CMDB。

日志不是用来“留存六个月”的

合规要求日志存半年，但攻防对抗里，你只有前十五分钟能抓到攻击者的指纹。我习惯在每台关键服务器上跑一个轻量级脚本，一旦发现异常外连，立刻把那个进程的内存 dump 出来，同时抓 60 秒的完整包。这些东西不存六个月，存 24 小时就够——但必须是自动触发的，等人登录上去敲命令，黄花菜都凉了。

有个细节：很多预案写“保留证据”，但没写“保留什么”。内存里的加密密钥、C2 域名的 DNS 缓存、进程的父进程链——这些比硬盘镜像值钱多了。硬盘可以慢慢镜像，内存断电就没了。

恢复不是“重启试试”

最怕听到的一句话是“先重启服务看看”。如果是 WebShell 植入，重启后攻击者换个马甲又回来了。恢复阶段必须做两件事：第一，从已知干净的备份恢复，但备份本身要验证——我见过备份里藏着三年前的挖矿木马；第二，恢复后挂上蜜罐，观察有没有二次连接。攻击者发现目标复活，通常会回来看看，这时候就能顺藤摸瓜。

预案里应该写清楚：恢复后的第一个小时，谁盯着流量，看什么特征。比如 DNS 查询里有没有那个该死的隧道域名，或者某个不存在的用户账号有没有登录尝试。

演练别搞成演戏

红蓝对抗演练，蓝队如果提前知道攻击时间，那叫考试不叫演练。我推崇“盲测”：找一个周五下午，让外部团队随机挑一个非核心但真实的系统打。蓝队只有值班表上的那个人知道“可能有事”，其他人正常干活。这样测出来的响应时间才是真的。

最后说个反直觉的观察：预案越厚，执行越差。一页 A4 纸，写清楚“谁、在什么条件下、做什么动作、做完通知谁”，比五十页的 PDF 管用。攻防对抗拼的是肌肉记忆，不是阅读理解。