上周帮朋友看一台内网服务器，漏扫他用Nessus扫出来一个“Apache Tomcat AJP协议文件包含漏洞”，验证风险标着高危，漏扫问我是验证不是真的能打。我看了眼版本号，漏扫Tomcat 9.0.31，验证AJP端口8009确实开着。漏扫但Nessus只给了个插件ID和一句模糊描述，验证连PoC都没附。漏扫这种时候就得靠Kali里的验证工具去手动验证一遍，不然拿着扫描报告去跟运维扯皮，漏扫人家一句“误报”就能把你顶回来。验证

Kali里验证漏扫结果，漏扫我习惯先上searchsploit。验证命令行敲下去，漏扫searchsploit tomcat ajp，返回三条记录。其中一条是CVE-2020-1938的Python利用脚本，路径在/usr/share/exploitdb/exploits/multiple/remote/48143.py。直接cp到临时目录，python3 48143.py -u http://target:8080——注意这里得填HTTP端口，脚本内部会去连8009。跑完输出一串文件列表，WEB-INF/web.xml赫然在列。这就坐实了漏洞存在，不是扫描器瞎报。

但光验证存在还不够。实际渗透里，你得拿到能读的文件内容才算数。那个脚本默认读web.xml，我改成读/etc/passwd，重新跑一遍，终端里直接回显了root用户那行。这时候才能跟运维说：不是危言耸听，攻击者能直接读你系统文件。有意思的是，Nessus扫的时候没提文件读取范围，只说了“可能泄露敏感信息”。这种模糊表述在漏扫报告里太常见了，验证的价值就是把“可能”变成“确认”。

另一个坑是误报。上个月扫一台JBoss，Nessus报了个反序列化漏洞，CVSS 9.8。我兴冲冲用ysoserial生成payload去打，结果服务器返回500错误。换metasploit的jboss_vulnscan模块再扫，提示“Target is not vulnerable”。回头翻Nessus插件详情，发现它只检测了HttpInvoker路径是否存在，压根没验证反序列化点是否可用。这种基于特征匹配的扫描，在复杂中间件环境里误报率不低。Kali工具的好处是能让你亲手构造请求，看服务端真实反应。

验证过程中还有个细节：时间窗口。有次扫一个WebLogic，Nessus报T3协议反序列化。我白天用weblogicScanner打，没反应。晚上十一点再试，成功了。后来发现是白天有WAF在拦T3流量，晚上运维关了WAF做备份。扫描器可不管这些，它只记录“目标可达时”的结果。所以验证漏扫得考虑业务时段、防护策略这些变量，不能只看工具输出。

工具选择上，Kali自带的nmap脚本也常用来做辅助验证。比如扫到ms17-010漏洞，Nessus说存在，你可以nmap -p445 --script smb-vuln-ms17-010 192.168.1.100跑一遍。脚本会返回“VULNERABLE”或者“NOT VULNERABLE”，比Nessus的插件结果更直接。但注意，nmap脚本也有版本依赖，太老的Kali镜像里脚本可能没更新，遇到Windows Server 2019会漏判。我一般两个工具交叉跑，结果一致才下结论。

说到底，漏扫报告就是个线索清单，不是判决书。Kali里的验证工具让你从“扫描器说有问题”走到“我确认有问题，并且知道怎么利用”。这中间的距离，就是安全工程师和脚本小子的区别。朋友那台Tomcat最后打了补丁，AJP端口也关了。他问我怎么跟领导汇报，我说你就写：经手动验证，CVE-2020-1938可读取服务器任意文件，风险等级维持高危。别加“可能”“疑似”这种词，验证过了就是实锤。