漏洞扫描总结报告

上周三凌晨两点，漏洞我盯着扫描器输出的扫描那份报告，整整37页，总结高危漏洞占了四页半。报告最扎眼的漏洞是那台对外提供API服务的服务器——OpenSSH 7.4，CVE-2018-15473，扫描用户名枚举。总结这个漏洞2018年就公开了，报告六年过去，漏洞它还稳稳当当地跑在生产环境里。扫描我顺手查了下资产台账，总结这台机器上次做系统更新是报告2021年9月。运维说“业务不敢动”，漏洞安全说“早就提过工单”，扫描两边就这么耗着，总结直到扫描器把证据甩在所有人脸上。

漏洞扫描这件事，很多人把它当成走流程。装个Nessus或者OpenVAS，配好IP段，点开始，等报告，导出PDF，发邮件。一套动作行云流水，然后呢？然后就没有然后了。报告进了共享盘，工单挂在系统里，风险该在还在。我见过最离谱的案例是一家金融公司，扫描报告里连续六个月出现同一个Redis未授权访问漏洞，每次都是“已确认，排期修复”，排了半年没动。直到有天半夜被人写了挖矿脚本，CPU跑满才有人翻出那份报告说“原来早就扫出来了”。

扫描器不是万能钥匙。它擅长发现已知的、有签名的、配置层面的问题。比如缺失的补丁、弱口令、开放的危险端口、SSL证书过期。但它看不见业务逻辑漏洞——你自己写的那个转账接口，参数没做校验，扫描器根本不知道这回事。它也测不出权限绕过，因为那需要理解会话和角色。更别提那些需要多步交互才能触发的漏洞。所以我一直觉得，扫描报告只能覆盖你攻击面的百分之三四十，剩下的得靠人工渗透、代码审计、威胁建模去补。

说回那份37页的报告。我做了三件事。第一，把高危漏洞按资产重要性和利用难度重新排序。对外服务、能直接拿shell的、不需要认证的，排最前面。内网测试机上的本地提权漏洞，往后放。第二，给每个高危漏洞找了对应的利用工具或者POC，附在工单里。运维不修，很多时候不是不想修，是不知道这东西真能被利用。你把metasploit的模块名字写上去，他态度会变。第三，拉了个群，把业务负责人、运维、安全都拽进来，每天同步修复进度。别发邮件，邮件会被淹没。群消息至少能看见。

修复过程也不是一帆风顺。有个Tomcat的漏洞需要升级JDK，但业务代码依赖旧版本的一个内部API，升上去直接编译不过。怎么办？上WAF加虚拟补丁，先挡着，同时排期改代码。扫描器下次再扫，这个漏洞还会报，但你知道它已经被临时控制了，在报告里标注“已缓解”就行。安全不是追求零漏洞，那不现实。安全是管理风险，把高危的、能被利用的先干掉，剩下的排好优先级慢慢来。

最后说个细节。扫描器配置里有个选项叫“安全扫描”和“ aggressive scan”，很多人图快选后者。结果扫的时候把测试环境搞挂了，因为某些老旧的Windows服务经不起那么多并发连接。扫描本身也是一种攻击，你得控制节奏。生产环境最好在业务低峰期扫，并且提前通知相关方。别问我是怎么知道这一点的。

那份报告最后修了三个星期。高危漏洞从四页半降到半页，剩下的都是需要架构调整才能解决的，列入了季度计划。扫描器又跑了一次，报告页数没变，但内容干净多了。你看，工具还是那个工具，关键看人怎么用。