漏洞扫描系统不能扫描

凌晨两点，漏洞运维老周盯着屏幕上那个转了三小时的扫描扫描圆圈，骂了一句脏话。系统漏洞扫描系统又卡死了——不是漏洞网络慢，不是扫描扫描目标主机拒绝响应，是系统系统自己把自己锁死了。这已经是漏洞本周第三次。

他点开日志，扫描扫描发现扫描进程在枚举端口时撞上了自己生成的系统临时文件。系统在扫描过程中不断往内存里写中间结果，漏洞写到某个阈值后，扫描扫描垃圾回收机制开始和扫描线程抢CPU。系统两个进程互相等，漏洞死锁了。扫描扫描讽刺的系统是，这套系统昨天刚升级了“智能调度模块”，号称能自动分配资源。

这种故障不是个例。我见过太多企业花几十万买的扫描器，最后沦为合规检查时的摆设。最离谱的一次，某银行的安全团队告诉我，他们的扫描系统只能扫内网IP段，因为外网扫描功能需要额外购买license，而采购流程走了八个月还没批下来。系统本身没问题，是制度把它废了。

还有更隐蔽的坑。扫描系统依赖的漏洞库如果更新不及时，扫出来的结果比过期报纸还没用。有个客户曾自豪地展示他们的扫描报告——全是绿色通过。我随手查了下CVE-2023-1234，这个漏洞他们系统里根本没收录。不是扫描器坏了，是喂给它的“食谱”已经馊了。

但最让人抓狂的，是那些“能扫却扫不动”的场景。某次渗透测试，目标是个老旧的工业控制系统。扫描系统一开全端口探测，直接触发对方工控协议的异常保护机制，把整个生产线搞停机了。甲方老板脸都绿了。后来我们改用人工手法，只针对特定端口做轻量级探测，才拿到结果。你看，有时候“不能扫描”反而是种保护——系统太莽撞，目标太脆弱。

回到老周的问题。他后来发现，那个死锁的根源是系统配置里“最大并发连接数”设成了0。默认值，没人改过。0意味着无限，无限就意味着资源耗尽。这就像把汽车油门踩到底却忘了挂挡——引擎轰鸣，车轮不动。

我见过太多这样的案例了。扫描系统不能扫描，从来不是单一技术故障，而是一连串决策失误的最终呈现。可能是配置模板抄错了，可能是权限分配太死板，可能是漏洞库更新流程卡在某个审批人手里，也可能是系统压根没适配真实网络环境。技术文档里把这类问题叫“扫描器失效”，但我更愿意叫它“组织性便秘”——该通的地方堵了，该排的地方憋着。

老周最后怎么解决的？他没升级硬件，也没换软件。他只是把那个“0”改成了“200”，然后重启了服务。三分钟后，扫描进度条开始动了。他盯着屏幕，忽然笑了——原来系统一直没坏，只是没人告诉它该跑多快。

漏洞扫描系统不能扫描，多数时候不是它不想干，是周围的环境让它没法干。你给它配个会思考的运维，比给它装十层AI滤镜都管用。