漏洞封堵

凌晨三点，漏洞封堵值班室的漏洞封堵电话响了。运维说某台服务器CPU飙到100%，漏洞封堵持续了二十分钟。漏洞封堵我爬起来打开电脑，漏洞封堵SSH连上去，漏洞封堵top命令一敲——有个进程在疯狂fork。漏洞封堵不用细看，漏洞封堵大概率是漏洞封堵上周那个没打完补丁的服务被人扫到了。

这事其实挺典型的漏洞封堵。那个服务用的漏洞封堵是老版本框架，官方三个月前就发了安全公告，漏洞封堵修了一个反序列化漏洞。漏洞封堵当时我在群里转过链接，漏洞封堵@了相关负责人。漏洞封堵对方回了个“收到”，然后就没有然后了。不是他懒，是那几天正好赶上大版本上线，所有人都在救火，补丁这事就被压在了待办列表的最底下。

漏洞这东西，你不管它，它不会自己消失。攻击者也不挑食，扫描器全网跑一遍，谁没穿衣服一目了然。

补丁打了就完事了？

真不是。我见过太多团队把“封堵”等同于“打补丁”，结果补丁打完了，问题还在。

去年有个案例印象很深。某电商平台修了一个SQL注入，代码层面确实加了参数化查询，测试环境也验过了。上线之后安稳了两个月，然后被人拖了库。复盘的时候才发现，修的那个接口只是主站用的，还有一个内部老系统调用同一个数据库，走的是另一条链路，那条链路上的拼接查询压根没人动。补丁打了一个口子，旁边还开着三扇窗。

这就是漏洞封堵里最容易被忽略的事：你得先搞清楚攻击面到底有多大。一个漏洞从被发现到被利用，中间的时间窗口越来越短。以前可能几周，现在自动化工具一跑，几个小时就能找到入口。你修的速度如果赶不上别人扫的速度，那补丁就只是心理安慰。

封堵的颗粒度

我自己的习惯是，处理一个漏洞至少问三个问题：

• 这个漏洞影响的组件，在系统里被哪些模块引用了？
• 有没有间接依赖？比如A服务调B服务，B服务用的库有漏洞，A算不算暴露面？
• 修完之后，有没有办法验证攻击路径确实断了？

第三个问题最要命。很多人修完就完了，不做验证。我一般会写一个最小的PoC，自己打自己一次。打不通，才算封住。打得通，说明修错了地方或者修得不彻底。

还有一点，封堵不是一锤子买卖。你今天封了一个反序列化，明天可能又冒出一个SSRF。漏洞的生命周期跟业务代码一样长，只要系统还在跑，就永远有新的口子。所以与其追求“一次性修完”，不如建立一个能快速响应的机制——知道谁在维护什么组件，知道出事了找谁，知道怎么在最短时间内把口子堵上。

说回凌晨那件事。我最后定位到的是一个被遗忘的测试接口，没有鉴权，直接暴露在公网。攻击者用它做跳板，在服务器上跑挖矿脚本。封堵方案很简单：下线接口，清理进程，加一条防火墙规则。前后不到四十分钟。

但真正让我在意的是，那个接口为什么会在那里。没人记得它是什么时候上线的，也没人知道它归谁管。它就像一个没人认领的后门，安安静静地开着，直到有人走进来。

漏洞封堵，堵的不只是代码里的那个洞。