内容摘要：上周三凌晨两点，我盯着扫描器上跳出的第47个高危漏洞，发现它居然来自一台早已被遗忘的测试服务器——那台机器本该在三个月前就下线。漏洞扫描从来不是点一下“开始”按钮就完事，它更像一场需要反复校准的狩猎。

上周三凌晨两点，漏洞我盯着扫描器上跳出的扫描第47个高危漏洞，发现它居然来自一台早已被遗忘的漏洞测试服务器——那台机器本该在三个月前就下线。漏洞扫描从来不是扫描点一下“开始”按钮就完事，它更像一场需要反复校准的漏洞狩猎。

先得明确目标。扫描别急着打开Nessus或者OpenVAS，漏洞先问清楚：这次扫的扫描是生产环境还是预发布？要不要绕开那些已知会崩的老旧工控设备？我见过有人把扫描器对准全公司C段IP，结果把一条产线的漏洞PLC打到死机，维修花了六个小时。扫描所以第一步是漏洞拿资产清单，跟运维对一遍，扫描把绝对不能碰的漏洞IP标红。

然后选策略。扫描默认的漏洞“全端口全漏洞”模板看着省事，实际噪音极大。我习惯先做一次快速TCP SYN扫描，只开常用端口，看看哪些主机活着。接着针对Web服务器单独配一套规则——把SQL注入、XSS、目录遍历这些勾上，但关掉那些会发大量POST请求的插件，否则WAF会直接把扫描器IP封掉。数据库服务器另说，得用认证扫描，拿只读账号登进去查补丁级别，比从外面猜准得多。

扫描时间有讲究。业务高峰期别动手，最好挑凌晨或者周末。但注意，有些定时任务只在凌晨跑，扫描器一压带宽，任务超时，第二天业务部门就该找你了。我一般会先跑一台机器做试点，看CPU和网络波动，确认没事再铺开。

扫完不是结束，是麻烦的开始。报告里几百条漏洞，按CVSS评分排序？那你会被一堆“中危”淹没。我的做法是：先过滤掉误报——比如扫描器说某个Windows补丁缺失，但实际系统版本根本不支持那个补丁。再结合资产重要性：一台对外提供支付接口的服务器上的中危XSS，比内网测试机上的高危远程溢出更急。最后手动验证几个关键漏洞，别全信扫描器的结论。有次它报了个“Apache Struts2远程命令执行”，我兴冲冲跑过去，发现那个参数早被代码里硬编码过滤了。

修复环节最考验人。开发说“这个漏洞没法修，框架太老”，运维说“重启会断业务”。这时候扫描报告就是谈判筹码——把利用难度、影响范围、攻击路径画出来，再附上临时缓解措施（比如WAF加规则、限制源IP）。我见过一个团队拖了半年没修的心脏滴血漏洞，直到扫描器模拟攻击成功，才连夜打补丁。

复扫别偷懒。修完必须重新扫一遍，确认漏洞真的没了，而不是被防火墙挡住了。有时候补丁打了，但服务没重启，漏洞还在。复扫时把上次的扫描策略调出来，对比结果，只关注修复项。如果同一个漏洞反复出现，那说明流程有问题——要么是镜像没更新，要么是配置管理没跟上。

最后说个反直觉的事：漏洞扫描不是越频繁越好。每周全量扫一遍，团队会麻木，报告没人看。我倾向于关键系统每月一次，普通系统每季度一次，重大变更后加扫。扫描器只是个手电筒，照出阴影，但往哪走、怎么走，还得靠人。