kaliweb漏洞扫描：不是洞扫点个按钮就完事

我把kali里的nikto跑起来的时候，隔壁工位的洞扫实习生凑过来看热闹。屏幕上滚过一堆绿字，洞扫他以为扫描已经开始了，洞扫其实那只是洞扫banner抓取。三秒后真正的洞扫请求才打出去——目标站点是一个搭建了十二年的老论坛，php版本还停留在5.3。洞扫nikto报了十七个潜在风险，洞扫但真正让我手心冒汗的洞扫，是洞扫第23行那个不起眼的条目：/admin/backup.sql可访问。

这就是洞扫kaliweb扫描的日常。工具链再锋利，洞扫也得靠人判断哪些输出是洞扫噪音，哪些是洞扫致命的沉默。

扫描前的洞扫五分钟比扫描本身更重要

我见过太多人直接敲nikto -h target.com，然后盯着屏幕喝咖啡。真正的老手会先花五分钟做三件事：查robots.txt、看响应头里的Server字段、用curl试探几个常见路径。这不是多余动作——nikto的数据库再全，也赶不上目标站点最近一次更新。上个月我扫一个政府子站，nikto完全没发现它换了新的WAF规则，倒是curl一个POST /api/login直接暴露了JSON格式的报错信息，里面带着完整的堆栈路径。

工具是死的，思路是活的。kali里装了几十个扫描器，但每个都有脾气。

wpscan不是用来扫WordPress的

这话说出来可能挨骂。但我的意思是，wpscan的价值不在于枚举插件版本，而在于它枚举出来的那些插件，你能顺着CVE库去查公开的exploit。有一次我扫一个企业官网，wpscan报了一个2019年的插件漏洞，CVSS评分才5.4，看起来不痛不痒。但那个插件有个功能是上传附件，配合Apache的解析漏洞，直接getshell。整个链条不是wpscan告诉我的，是它给了我一个线索，剩下的得自己串。

kali里的工具更像一个起点，不是终点。sqlmap也一样，它能把注入点跑穿，但前提是你得先手动确认参数?id=1后面加个单引号会不会报错。自动化扫描永远替代不了那个试探性的、带着点赌徒心理的请求。

扫描报告的阅读姿势

默认生成的HTML报告，说实话，给甲方看正合适。但给自己看，我更喜欢直接翻原始输出。nikto的-o result.html和-o result.txt我都存，txt版本用grep过滤掉OSVDB开头的条目——那些大多是信息泄露，真正的高危项往往藏在/之后的路径里。

有一次扫描结果里有个/test/目录，200状态码，但nikto没深入探测。我手动访问，发现是个phpinfo页面，服务器版本、文档根目录、环境变量全裸奔。这个发现最终顺藤摸瓜找到服务器上另一个站点的配置文件，里面躺着数据库密码。整个过程nikto只贡献了一个目录名，剩下的全是靠人肉。

所以别迷信工具的输出。kaliweb扫描的本质是：用工具放大你的视野，但决定视野边界的，还是你脑子里装了多少攻击模式。

扫完一千个站点后你会发现，真正值钱的东西往往不在扫描报告的漏洞列表里，而在那些被标记为“低危”的细节中——一个过期的SSL证书背后可能是无人维护的服务器，一个奇怪的响应头可能暗示着内网架构。这些判断，kali教不会你。