修复漏洞工具

去年十月，修复我蹲在客户机房的漏洞地板上，盯着一台跑了六年的工具老服务器。风扇嗡嗡响，修复屏幕上一行红字报错，漏洞系统日志里躺着一条三年前就存在的工具漏洞——CVE编号我至今记得，因为那天我翻了整整两小时补丁记录。修复运维主管站在旁边说，漏洞这机器从上线就没打过补丁，工具厂商早停止支持了。修复我当时想，漏洞要是工具有一把趁手的工具，哪至于这么狼狈。修复

修复漏洞这件事，漏洞很多人以为就是工具点一下“扫描”再点一下“修复”。真干过的人知道，中间隔着一条河。扫描工具告诉你哪里有洞，可它不告诉你补丁会不会把业务搞崩。上个月我帮一家小公司处理Struts2的远程执行漏洞，官方补丁打上去，他们自研的登录模块直接白屏。开发早离职了，源码都找不全。最后只能在前端加WAF规则挡着，治标不治本。工具给出的“修复”按钮，有时候按下去就是另一场事故。

我常用的组合是Nessus做资产发现和初步扫描，OpenVAS做交叉验证，真正动手修复靠Ansible写playbook批量推。但这里面有个坑：扫描器报的漏洞等级和实际风险经常对不上。CVSS评分9.8的洞，如果那台机器在内网深处、没有任何外部路由可达，优先级可能还不如一个评分5.3但直接暴露在公网的弱口令。工具不会替你判断这个，得自己画网络拓扑图，标出攻击路径，再决定先修哪个。

补丁管理是另一摊烂账。Windows Server 2008停更之后，微软不再发安全更新，可客户还在跑SQL Server 2008。怎么办？要么花钱买ESU扩展支持，要么把服务迁移到新系统，要么用0patch这类第三方微补丁工具顶着。0patch的原理是在内存里打热补丁，不碰硬盘文件，重启就失效，得重新注入。我试过在测试环境跑，确实能拦住某些提权攻击，但内存占用涨了15%，老机器本来内存就吃紧。这种取舍，工具说明书不会写。

开源工具里，我比较信任Trivy和Grype，扫容器镜像漏洞快且准。但有个细节：它们比对的是镜像层里的软件包版本，如果Dockerfile里用了apt-get upgrade但没固定版本号，下次构建出来的镜像漏洞列表可能完全不同。我见过一个团队用latest标签构建，周一扫出来12个高危，周三变成7个，周五又冒出来15个。他们以为是工具抽风，其实是基础镜像在变。修复漏洞的前提是环境可控，否则工具只是在追一个移动靶。

说回机房那台老服务器。最后我没打补丁，因为厂商的补丁包依赖新版本glibc，升级glibc等于重装系统。我写了个iptables规则，把那个漏洞对应的端口从外网访问列表里删掉，又在应用层加了一段输入过滤代码。漏洞还在，但攻击面缩小到可接受范围。客户问我这算修复吗，我说算缓解，不算修复。工具能帮你发现和定位，但“修”这个动作，永远需要人来判断边界在哪里。

现在每次打开扫描报告，我先看的是“误报”和“不可修复”两栏。真正能一键修掉的漏洞不到三成，剩下的要么等厂商更新，要么自己写缓解措施，要么接受风险签字画押。工具越用越觉得，它像一把螺丝刀，能拧紧松动的螺丝，但拧多紧、要不要换螺丝、会不会滑丝，全看拿工具的人。那天离开机房时，运维主管说下次买新服务器一定记得打补丁。我说你先把资产清单理清楚，不然新机器上线三个月，照样会变成另一台漏洞博物馆。