漏洞扫描资产脆弱性检查方案

上周某金融客户的漏洞核心业务系统被攻破，溯源发现是扫描三个月前就公开的Apache Log4j2漏洞，而他们的资产扫描报告里压根没出现这个资产。这不是脆弱查方个例——大多数企业的漏洞管理，败在“资产清单不准”而不是性检“扫描器不够强”。

脆弱性检查的漏洞第一步不是扫漏洞，而是扫描盘资产。你连自己有多少台服务器、资产跑什么服务、脆弱查方开放哪些端口都不清楚，性检扫描器扫到的漏洞只是冰山一角。我见过一家零售企业，扫描IT部门报上来的资产服务器是87台，结果用网络探测工具一跑，脆弱查方实际在线132台——那45台“黑户”里，性检有一台居然连着生产数据库的备份链路。资产梳理得像查户口：IP、MAC、操作系统版本、中间件类型、数据库实例、开放端口、归属人，一个都不能少。动态资产用CMDB管，但CMDB的更新往往滞后，所以还得靠主动探测兜底，每周跑一次全网段指纹识别。

资产清楚了，才轮到扫描策略。别一上来就全量漏洞库狂扫，那会吵得业务部门摔电话。按风险等级分梯队：第一梯队是核心交易系统，用非侵入式扫描，避开业务高峰，凌晨两点到六点窗口期跑；第二梯队是办公网和开发测试环境，可以放开手脚用综合扫描，包括弱口令检测、Web漏洞爬虫；第三梯队是那些边缘系统，比如打印机、摄像头、老旧Windows Server 2003，这些往往是跳板，但优先级低，每月扫一次就够。扫描器配置要贴实际——默认配置经常把SNMP公共字符串当漏洞报，却对真正的Redis未授权访问视而不见，你得根据自家技术栈调插件。

扫描结果出来，才是真正的重头戏：漏洞验证。扫描器报的“高危”里，至少三成是误报或无效风险。比如它报某台Linux服务器存在Sudo提权漏洞，但实际系统已经打了补丁，只是补丁版本号识别错误。又比如报MySQL弱口令，一验证发现是扫描器自己连错了实例端口。人工验证的活儿不能省，用安全工具复现攻击路径，或者直接看配置文件、跑一下exp的检测版，把真漏洞和噪音分开。这一步做扎实了，后续的修复才有的放矢。

修复环节，别指望IT部门一夜之间全补上。漏洞有生命周期，得按业务影响和可利用性排序。我曾经处理过一个案例：扫描发现OA系统存在文件上传漏洞，CVSS评分9.8，但该系统仅内网访问且无敏感数据，反而是另一台暴露在公网的测试服务器存在低危的信息泄露，被攻击者利用作为跳板。优先修公网可触达的、能直接getshell的、涉及核心数据的；那些内网深处的低危问题，可以排进月度维护窗口。修复动作要明确：是打补丁、改配置、加防火墙规则，还是直接下线系统？每一条都得落实到人，给deadline。补丁打不上的，用虚拟补丁或WAF规则临时缓解，但必须登记在案，跟踪到最终解决。

最后留个心法：漏洞扫描不是季度运动，而是持续循环。资产在变，漏洞库在更新，业务在扩展，今天扫干净了，明天新上线的容器可能又带进来一堆问题。我建议把整个流程固化到安全运营平台里，资产变化自动触发扫描，扫描结果自动关联工单，修复完成自动复测。别信“扫完就安全”的鬼话，脆弱性管理是和时间的赛跑——你跑得比攻击者快，系统就安全；慢一步，上周那个金融客户的剧本就会重演。