漏洞扫描设备功能

去年秋天，漏洞我帮一家做跨境电商的扫描设备朋友看他们刚买的漏洞扫描设备。设备上架三天，漏洞扫出两千多个“高危漏洞”，扫描设备运维团队差点集体加班到天亮。漏洞结果一条条核对下来，扫描设备真正能被利用的漏洞不到三十个。剩下的扫描设备全是误报——扫描器把某个老版本jQuery的版本号当成了远程代码执行入口。这事让我意识到，漏洞漏洞扫描设备的扫描设备核心矛盾从来不是“能不能扫”，而是漏洞“扫得准不准”。

市面上的扫描设备漏洞扫描器大致分两类。一类是漏洞网络层扫描，像Nessus、扫描设备OpenVAS这种，漏洞靠发数据包探测端口、服务、协议版本，再跟CVE库比对。另一类是Web应用扫描，比如Acunetix、AppScan，专门爬网站链接、填表单、测注入。这两类设备的工作原理完全不同，但用户经常混着用。我见过有人拿Nessus去扫一个纯前端渲染的SPA应用，结果自然惨不忍睹——扫描器连路由都爬不到，报了一堆“未发现漏洞”，实际是根本没扫到点子上。

扫描准不准，关键看三个东西：指纹库的更新频率、POC（概念验证代码）的质量、以及误报抑制逻辑。指纹库决定了设备能不能认出目标跑的是Tomcat 9.0.45还是WebLogic 12.2.1.4。认错了版本，后面全白搭。POC质量则决定它能不能真的验证漏洞存在。很多廉价设备用的是“版本比对”法——只要版本号落在受影响区间就报警。这招快，但误报率高得离谱。真正靠谱的设备会发一个无害的探测请求，看目标返回的特征字符串，甚至尝试执行一个只打印特定标记的payload。误报抑制更考验厂商功力。我测试过某国产设备，它对每个漏洞都给了置信度评分，低于60%的自动折叠，运维人员只看剩下的。这个设计很实用。

性能参数里最容易被忽略的是并发扫描能力和对扫描目标的压力控制。有些设备为了追求“扫得快”，默认线程数开到500，结果把客户的测试环境直接扫挂。我见过一台设备把某政府网站的负载均衡器打出了503，后来被要求写事故报告。好的扫描器应该允许你设置每秒请求数上限、排除脆弱路径、甚至指定扫描时间窗口。这些细节比“支持五万条漏洞库”这种宣传语重要得多。

部署方式也得看场景。旁路镜像适合被动发现资产，但扫不了漏洞。代理模式能扫内网，但需要每台机器装agent，运维成本高。主流做法还是扫描器直接接入网络，配好路由和凭据。凭据这块是个坑——很多设备号称支持SSH、SMB、数据库凭据登录后做深度扫描，实际配置起来繁琐得要命。Windows域环境里，你得开WMI、配DCOM权限、关防火墙对特定IP的限制。我见过一个团队花了三天才让扫描器成功登录一台Server 2012，最后发现是组策略里某个旧设置挡住了。

报告功能是另一个分水岭。差劲的报告就是漏洞列表加CVSS评分，看得人头皮发麻。好的报告会按业务系统分组、标注资产重要性、给出修复优先级和具体操作步骤。比如“Apache Log4j2 JNDI注入”这个漏洞，报告应该直接告诉你：升级到2.17.1，或者设置log4j2.formatMsgNoLookups=true，再或者移除JndiLookup类。而不是只丢一个CVE编号让你自己查。

价格从几千到几十万都有。开源方案像OpenVAS免费，但规则库更新慢、误报多、界面反人类。商业设备贵在服务——及时的中文漏洞通告、定制POC、现场支持。我个人的判断是：小团队用开源加人工验证就够了，中大型企业还是得买商业设备，但一定要先做POC测试，拿自己真实的业务系统扫一遍，看误报率和漏报率再决定。

最后说个观察：漏洞扫描设备永远追不上漏洞产生的速度。它是个辅助工具，不是安全保险。真正管用的还是人——知道哪些资产重要、哪些漏洞能实际利用、修复窗口有多长。设备只是帮你把清单列出来，判断和决策还得自己做。