goby漏洞扫描

Goby 的漏洞扫描速度是我用过的工具里最不讲道理的一个。第一次跑它扫一个 C 段，扫描我泡了杯茶回来，漏洞界面上已经整整齐齐列了 47 台主机，扫描端口、漏洞协议、扫描资产类型全标好了。漏洞当时我盯着屏幕愣了几秒——Nmap 还在后台吭哧吭哧跑 SYN 扫描呢。扫描

这东西本质上是漏洞个资产测绘工具，但大多数人拿它当漏洞扫描器使。扫描它的漏洞逻辑跟传统扫描器不一样。Nessus、扫描AWVS 那套是漏洞先定义漏洞库，再逐条匹配。扫描Goby 走的漏洞是另一条路：先识别资产是什么，什么版本，跑了哪些服务，然后根据这些指纹去匹配已知的漏洞 PoC。说白了，它更像一个带了 10 万+ PoC 的指纹识别引擎。

我拿它扫过一台暴露在公网的 Jenkins。Goby 识别出这是 Jenkins 2.263 版本，紧接着弹出三个漏洞提示：CVE-2021-21604、CVE-2021-21605，还有一个未授权的脚本命令行执行。点进去看详情，PoC 代码直接嵌在界面里，一键就能验证。那个未授权漏洞我手动测过，确实能执行 Groovy 脚本。整个过程从扫描到确认，不到两分钟。

不过它的误报率得单独拎出来说。有次扫内网一台老旧的 Tomcat 6，Goby 报了 CVE-2016-8735 反序列化漏洞。我兴冲冲去验证，发现目标根本没开 AJP 端口。看 PoC 逻辑才发现，它只检测了 Tomcat 版本号，没管 AJP 连接器是否启用。这种基于版本匹配的粗暴逻辑，在复杂环境里很容易翻车。所以我现在养成了习惯：Goby 报的洞，高危的必须手动复现，中低危的挑着看。

它的插件生态是个亮点。官方 PoC 更新频率很高，Log4j2 爆发那会儿，Goby 是最早一批集成检测能力的工具。社区也有人写自定义 PoC，用 Go 语言，写起来不算复杂。我照猫画虎写过一个泛微 OA 的检测脚本，大概三十行代码，编译成插件丢进目录就能用。这比 Nessus 的 NASL 脚本友好太多。

界面设计明显参考了 Burp Suite 的布局。左边资产树，中间详情面板，右边漏洞列表。操作逻辑也像——右键菜单里藏着大部分功能。但有个细节让我觉得开发者是真的干过渗透：扫描结果可以直接导出成 Excel，资产、端口、漏洞分三个 Sheet。交报告的时候省事不少。有次给客户做应急响应，凌晨三点导出报告，客户早上八点拿到手，直接标红了三个高危漏洞。

资源占用值得夸一句。我同时在虚拟机里跑 Goby 和 Nessus 扫同一个 B 段，Nessus 吃了 2.3G 内存，Goby 只占了 400 多兆。扫描 65535 个端口的速度，Goby 大概比 Nmap 的 -T4 模式快 30% 左右。当然代价是精度——它默认只扫常见端口，全端口扫描得手动调参数。

用久了会发现一个规律：Goby 适合做第一轮快速摸底。先拿它扫一遍，把资产和明显漏洞捞出来，再用 Nmap 做精细扫描，用 Burp 手动测逻辑漏洞。它替代不了专业扫描器，但作为渗透测试的起手式，效率提升是实打实的。我现在的标准流程就是 Goby 开局，Nmap 补漏，Burp 收尾。三件套下来，一个 C 段从信息收集到漏洞验证，半天能出初步报告。

最后说个槽点。它的 Mac 版偶尔会闪退，特别是扫描大网段的时候。有次扫 /16 的段，跑到 3000 多个 IP 时直接崩了，重新打开发现扫描进度没保存。Windows 版倒是稳，但界面字体渲染有点糊。开发团队在 GitHub 上回应说 macOS 的 WebView 有兼容问题，下个版本修。这个“下个版本”从去年说到现在，还没修好。