漏洞扫描修复工具

去年冬天，漏洞一个朋友的扫描公司被勒索病毒锁了全部服务器。事后复盘，修复攻击入口是工具一个三年前就公布过补丁的Apache Struts漏洞。他们的漏洞运维团队不是没装漏洞扫描工具，而是扫描装了之后没人看报告。这事让我意识到，修复漏洞扫描修复这件事，工具工具只占三成，漏洞剩下七成全在流程和人的扫描执行上。

扫描器到底在扫什么

很多人以为漏洞扫描就是修复拿个工具跑一遍，出一份报告。工具实际上扫描器的漏洞核心工作分两步：指纹识别和漏洞匹配。指纹识别阶段，扫描扫描器会去探测目标服务的修复banner、HTTP响应头、TCP/IP协议栈特征，判断你跑的是Nginx还是IIS、版本号是多少。漏洞匹配阶段，它拿这些指纹去跟漏洞库比对——比如检测到OpenSSH 7.4，就标记CVE-2018-15473（用户名枚举漏洞）。

问题在于，指纹识别会出错。我见过扫描器把一个改过banner的Nginx识别成Apache，然后报了一堆根本不存在的漏洞。也见过它把CDN回源IP当成真实服务器扫，结果整份报告全是误报。所以拿到扫描结果的第一件事不是急着修，是先验证。

误报比漏报更让人头疼

漏报当然危险，但误报会直接摧毁团队对工具的信任。一个中型企业内网扫下来，几千条漏洞警告，按严重程度排完前两百条，逐条验证发现六成是误报。运维人员花了两天时间做无效劳动，第三次之后他们就不再看报告了。

降低误报有几个实操手段：关闭基于版本的粗粒度检测，改用POC验证模式；对已知的误报规则做白名单；扫描前先确认资产清单，别把蜜罐和测试环境扫进去。Nessus和OpenVAS都支持插件级别的开关，别偷懒用默认策略。

修复的优先级怎么定

CVSS评分高不代表一定要先修。一个内网才能访问的Redis未授权访问，和一个公网直接可达的Log4j RCE，后者哪怕CVSS分数低一点也该先处理。我的判断顺序是：公网暴露面 > 内网横向可达 > 本地提权。再叠加一个维度——利用难度。已经有公开EXP的漏洞，优先级直接拉满。

还有一类漏洞容易被忽略：配置类问题。比如TLS 1.0没关、HTTP方法没限制、目录列表没禁用。扫描器会报，但很多人觉得“不算漏洞”就跳过了。实际上攻击者拿这些做信息收集，比直接打漏洞还高效。

修复之后要做什么

修完不是结束。得重新扫一遍确认修复生效，有时候补丁打了但服务没重启，漏洞还在。更关键的是把这次修复记录到资产管理系统里——哪个资产、什么漏洞、什么时候修的、谁修的。下次扫描再报同一条，直接标记为已修复待验证，省掉重复劳动。

我自己的习惯是每次修复完做一次diff对比，把修复前后的扫描结果导出来，用脚本比一下：哪些漏洞消失了，哪些还在，有没有新出现的。这个动作花不了十分钟，但能抓住很多“以为修好了其实没修”的情况。

工具选型上，商业的用Nessus或Qualys，开源的用OpenVAS加Nuclei做补充。Nuclei的模板社区更新快，新漏洞出来当天就有POC，适合做应急扫描。但别指望一个工具解决所有问题，漏扫、基线核查、渗透测试是三件不同的事。

说到底，漏洞扫描修复是个持续运转的循环：扫描、验证、定级、修复、复扫。工具负责发现，人负责判断和推动。流程断在哪一环，整个循环就白转了。