2023年5月，网络某省级政务平台的系统一个文件上传接口被攻破。攻击者没用什么高深手段，漏洞略只是应对策利用了一个未过滤的路径穿越漏洞，就拿到了服务器权限。网络事后复盘，系统这个漏洞在两年前的漏洞略代码审计报告里就被标注过，但优先级被排到了“低”。应对策

这种事我见过太多次。网络漏洞本身不致命，系统致命的漏洞略是应对节奏乱了。

先止血，应对策再查病因

发现漏洞后的网络第一个小时，别急着写报告、系统拉会议。漏洞略先确认三件事：影响范围有多大、攻击者是否还在活跃、有没有现成的临时缓解措施。比如那个政务平台，如果运维团队第一时间把上传目录设为不可执行，攻击者就算传了webshell也跑不起来。这比事后追责有用得多。

我见过一个团队，漏洞爆出来之后花了三天写了一份八十页的根因分析PPT，期间服务器一直裸奔。这不是严谨，是拎不清。

补丁不是万能药

很多团队的应对策略就一个字：打补丁。但现实是，老旧系统打不了补丁，业务系统不敢随便重启，补丁本身还可能引入新问题。某银行的核心交易系统跑在AIX上，数据库版本停更五年了，厂商早就不提供安全补丁。他们的做法是在前面加了一层RASP（运行时应用自我保护），把危险函数调用直接拦掉。性能损耗3%，但比换系统便宜太多。

补丁要打，但不能只靠补丁。网络层ACL、WAF规则、主机层HIDS、应用层RASP，能上的手段叠上去。纵深防御这词听着老套，但真出事的时候，多一层就多一条命。

日志比直觉可靠

漏洞被利用之后，最怕的是什么？是不知道攻击者干了什么。很多团队查入侵就靠last和history，这跟闭着眼睛找东西差不多。全流量留存成本高，但至少要把关键服务器的进程创建、网络连接、文件变更这三类日志集中收集起来。某电商公司被挖矿，安全团队从进程日志里发现了一个异常的curl下载行为，顺着时间线追到了入口点——一个三天前就被修复但没重启服务的Struts2漏洞。没有日志，这个追溯根本做不了。

人的惯性才是最大的漏洞

技术手段再全，也架不住运维人员图省事。我见过一个案例：安全团队发了紧急通知要求所有服务器禁用某个危险端口，结果一台测试机没关，被当成跳板打进了内网。问就是“测试机不重要”。攻击者最喜欢的就是这种“不重要”的机器。

应对策略里必须有一条：变更之后要有验证。别发个邮件就当事情做完了。自动化扫描脚本跑一遍，确认端口真的关了、补丁真的生效了。这比开十次安全会议都管用。

别指望一次搞定

漏洞应对是个循环。发现、缓解、修复、验证、复盘，然后等下一个漏洞。没有一劳永逸的方案。某互联网公司的安全负责人跟我说过一句话：“我们不是要建一堵墙，而是要养一群随时能补墙的人。”这话我记到现在。

策略写在纸上是死的，执行的人得是活的。工具买回来要调，流程定下来要练，人员配到位要训。不然真出事的时候，你手里那堆安全设备跟砖头没区别。