修不了就是高危修不了。别指望有什么银弹。漏洞

去年冬天，修复我接手了一个烂摊子。不办某企业的高危对外网关跑着一个老掉牙的Struts2，版本号我都不好意思说。漏洞CVE-2017-5638，修复远程命令执行，不办CVSS评分10.0。高危扫描器每天报警，漏洞安全部门每天发邮件，修复运维每天重启服务。不办我问为什么不升级，高危对方说：这套系统是漏洞2009年上线的，源码丢了，修复原厂早没了，现在跑在一个没人敢动的Windows Server 2003虚拟机上。升级？等于把整栋楼拆了重盖。

这不是段子。这是很多一线安全工程师的日常。

高危漏洞修复不了，核心原因就那么几个。业务不能停，系统太老，依赖太深，或者——更常见的——根本没人知道这个系统是谁写的、怎么跑起来的。我见过一个财务系统，跑在CentOS 5上，内核版本2.6.18，OpenSSL还是0.9.8。心脏出血漏洞爆出来的时候，全公司都在换证书，就它不能动。为什么？因为给它签证书的那台CA服务器也跑在同一个虚拟化集群里，动一个，全挂。

那怎么办？等死？也不是。

第一件事，别想着彻底修。修不了就是修不了。你要做的是把风险压到可接受的范围内。具体怎么做，看情况。

如果漏洞在边界上，比如一个对外暴露的Web服务，最直接的办法是加一层。WAF、反向代理、API网关，什么都行。把攻击面收窄。Struts2那个例子，最后我们在前面挂了一个Nginx，把Content-Type里带OGNL表达式的请求全拦了。误杀肯定有，但比被拖库强。运维一开始不乐意，说影响业务。我说那你选，是每天被扫描器追着跑，还是偶尔误拦几个请求。他选了后者。

如果漏洞在内网，那就更麻烦。内网不是信任区。零信任喊了这么多年，真正落地的没几个。我的做法是：先做资产测绘。你不知道自己有什么，就谈不上保护。用Nmap、Masscan，把整个网段扫一遍。别怕动静大，扫自己家不犯法。扫完你会发现，至少30%的资产不在CMDB里。这些就是定时炸弹。

找到之后，分类。能打的补丁打上，不能打的隔离。VLAN划分、ACL、防火墙策略，把高危资产圈起来。别让一个点被突破，整个内网沦陷。我见过一个医院，HIS系统跑在XP上，补丁打不了。他们怎么做的？把HIS单独划了一个物理网络，跟办公网完全隔离，U盘管控，端口封死。五年了，没出过事。笨办法，但管用。

还有一种情况：漏洞在底层库或者框架里，比如Log4j。这个更恶心。你应用本身没问题，但依赖的某个jar包有问题。升级jar包可能引发兼容性问题，不升级就是等死。Log4j2那个漏洞爆出来的时候，我们连夜排查了三百多个应用。最后发现有一个核心交易系统用的是Log4j 1.x，本来不在影响范围内。但它的某个第三方支付SDK里，打包了一个Log4j 2.14。你根本不知道。

这种怎么办？要么找SDK厂商要新版本，要么自己反编译改。后者风险极高，但有时候是唯一的路。我们最后是找了个开源替代，把支付SDK整个换掉了。花了三周，测试了两周。期间那个漏洞就挂着，靠WAF规则硬扛。

说点实在的。高危漏洞修不了，不是技术问题，是管理问题。你得让业务方知道风险，让老板知道代价。别自己扛。写风险接受单，让业务负责人签字。这不是甩锅，这是流程。安全不是一个人能搞定的事。

最后，别信什么“一键修复”。那都是卖产品的。真实世界里，修复一个高危漏洞，往往意味着改代码、换组件、调架构、停机窗口、业务妥协。能修就修，修不了就控。控不住就转。转不了就认。认了之后，至少把监控做好。真被打了，你得知道是谁、从哪、什么时候。

漏洞永远修不完。但你可以让自己不那么好打。