上周三凌晨两点，服务运维群里弹出一条告警：一台对外提供API服务的器漏生产服务器CPU飙到98%，持续了将近二十分钟。洞整值班同事一开始以为是改情告流量突增，查了监控才发现请求量平稳，况报真正的服务问题是某个Java进程在疯狂创建线程。天亮之后我们介入排查，器漏确认是洞整Log4j2的JNDI注入漏洞被扫描器触发了——虽然没造成数据泄露，但这台机器已经被人摸到了门口。改情告

这不是况报我们第一次遇到漏洞应急。过去半年，服务安全团队陆续提交了四十多个待修复项，器漏涉及中间件、洞整操作系统、改情告第三方组件。况报有些是陈年老账，比如一台2019年上线的CentOS 7服务器还在跑OpenSSH 7.4，CVE-2018-15473早就公开了，但一直没人动它。原因也简单：业务方怕重启影响可用性，运维怕变更引入新问题，安全怕催得太紧被投诉。三方拉扯的结果就是漏洞列表越拉越长，直到这次Log4j2把所有人都炸醒了。

整改从第二天上午正式开始。我们做的第一件事不是直接打补丁，而是把所有受影响资产拉了一张清单。这里有个细节值得说：资产管理系统里登记的服务器数量和实际扫描出来的差了十七台。那十七台是测试环境遗留的机器，早就没人认领，但网络策略没回收，一直挂着公网IP。换句话说，我们连自己有多少台机器在暴露面里都搞不清楚，谈何修复。当天下午先把这十七台机器全部断网隔离，然后逐台确认归属。

补丁策略分了三档。第一档是Log4j2这种直接可利用的远程执行漏洞，要求48小时内全部升级到2.17.1版本，业务方没有讨价还价的余地。第二档是中危漏洞，比如OpenSSH和Nginx的若干问题，给两周窗口期，但必须提交修复计划。第三档是低危或者利用条件苛刻的，排入季度例行维护。这个分档不是拍脑袋定的，参考了CVSS评分、资产暴露程度和实际业务影响。比如那台跑OpenSSH 7.4的机器，虽然漏洞年龄大，但只在内网开放，优先级就往后放了。

执行过程中最麻烦的不是技术操作，是协调。有一台核心数据库服务器，补丁需要重启，业务方死活不同意，说月底有促销活动，停一分钟损失几十万。安全团队坚持要修，两边僵住了。最后折中方案是在负载均衡层加了一条临时规则，把针对该漏洞的攻击特征全部拦截，等促销结束再重启。这个方案不完美，但比什么都不做强。类似的情况还有好几起，每个都需要单独谈。

到上周五，第一档漏洞全部清零。第二档完成了大约七成，剩下的排期在下个月。那十七台“幽灵服务器”里有五台确认可以下线，已经走了报废流程，另外十二台重新纳入了监控。Log4j2那台被攻击的机器后来做了溯源，攻击者只留下了扫描记录，没有成功执行命令，算是运气好。

整件事给我的感受是，漏洞整改从来不是单纯的技术问题。资产不清、责任不明、变更流程僵化，任何一个环节卡住，补丁就打不上。这次能推下去，很大程度上是因为Log4j2的动静太大，业务方不敢说不修。但靠漏洞自己“闹出动静”来推动整改，成本太高了。下次可能就没这么幸运。