漏洞扫描原理

漏洞扫描干的漏洞事，说白了就一句话：拿着已知的扫描“问题清单”，挨个去问目标系统“你有没有这个毛病”。原理它不创造新知识，漏洞不搞什么零日漏洞挖掘，扫描核心能力全在“比对”二字上。原理你装个Nessus扫内网，漏洞它不会突然告诉你某个服务存在一个从未被公开的扫描栈溢出——那是渗透测试和逆向工程干的活。扫描器的原理本事，是漏洞把它库里存的那几万条漏洞特征，一条条往目标上套。扫描

那它怎么“问”？原理最直接的方式是看版本号。比如你跑了个Apache 2.4.49，漏洞扫描器一抓banner，扫描发现版本落在CVE-2021-41773影响范围内，原理立刻标红。这招快，但容易被骗——管理员改个配置文件里的版本字符串，扫描器就瞎了。所以靠谱的扫描器不会只信banner，它还会发特定请求去“试探”。针对那个Apache路径穿越漏洞，扫描器会构造一个/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd的请求，看服务器返不返回root那一行。返回了，实锤；返回403或者404，那可能打了补丁，也可能路径不对，得再换几个payload试试。

这种“发请求看响应”的模式，决定了扫描器本质上是个自动化渗透测试的简化版。它不追求深度利用，只追求“能证明漏洞存在”的最小证据。比如SQL注入，扫描器不会真去拖库，它发个'看报不报错，或者发个AND 1=1和AND 1=2对比页面差异。差异出现了，它就认为有注入点。至于这个注入点能不能union select，能不能读文件，那是下一步的事。很多扫描器报告里写“可能存在SQL注入”，就是因为证据不够硬——页面差异也可能来自缓存或者WAF的随机拦截。

插件机制是扫描器的骨架。每个漏洞对应一个插件脚本，Nessus叫NASL，OpenVAS叫VT。脚本里写清楚了：发什么包，匹配什么正则，超时多少，依赖哪个端口开放。扫描时，引擎先做端口发现和 service 识别，然后根据识别结果调度对应插件。比如发现80端口跑的是IIS 6.0，那就把IIS相关的几十个插件全拉出来跑一遍。这种设计让扫描器扩展性极强，但副作用是——插件质量参差不齐。有些插件写得糙，发个请求没收到预期响应就报“无法确定”，有些则过于激进，把正常业务逻辑误判成漏洞。我见过一个扫描器把某个API的JSONP回调参数当成XSS，其实人家做了严格的白名单校验。

误报和漏报是扫描器的两个死穴。误报好理解，就是“狼来了”。漏报更隐蔽——扫描器没报，不代表没问题。比如逻辑漏洞，越权访问、支付篡改，这些没有固定payload特征，扫描器基本抓瞎。还有需要多步交互才能触发的漏洞，比如先登录再上传再访问特定URL，扫描器很难自动完成整个链条。所以真实的安全评估里，扫描器只是第一步，它产出的报告得靠人去看、去验证、去补充。

扫描器自己也可能成为攻击面。有些扫描器会发大量畸形包，把目标服务打挂；有些会触发WAF封禁IP；还有些老版本扫描器自身存在漏洞，比如Nessus曾经有个插件能导致远程代码执行。所以生产环境扫之前，最好先拿测试环境跑一遍，调低并发，避开业务高峰。我习惯把扫描器的超时设短一点，遇到卡住的请求直接跳过，别让一个不响应的端口拖垮整个扫描任务。

说到底，漏洞扫描是个“已知对抗已知”的游戏。它高效、可重复、能覆盖大量资产，但它看不见未知的、逻辑的、需要人类直觉才能发现的问题。把它当体检报告里的血常规——能筛出不少毛病，但真正确诊还得靠医生。