Nessus漏洞扫描速度快不快？影响扫描效率的因素

最近大家都在聊Nessus这东西，我最近也在折腾这个漏洞扫描工具，跑了几次下来，发现这玩意儿的速度真不是盖的，有时候扫描个大网段，比我预期的要快不少。不过也有时候感觉它慢得像老牛拉破车，同一个范围，上次三小时搞定，这回能磨磨蹭蹭跑一天。

我这个人做事比较轴，遇到这种性能起伏大的情况，总得琢磨琢磨是咋回事，不能稀里糊涂地用。我就把这些跑下来的记录翻出来，仔细对比了一下，发现影响Nessus扫描速度的因素，还真不少，不是光看网速那么简单。

初次尝试，摸清家底

我一开始就是随便找了个中等规模的公司内网环境，大概几百台设备，操作系统五花八门，有Windows、Linux，还有点物联网设备。我用的就是默认配置，选了个最全的扫描策略，然后就启动了。第一次跑下来，用了差不多六个小时，跑完之后我一看报告，发现很多设备压根就没啥高危漏洞，但是扫描时间还是那么长。

我当时就觉得，这默认配置是不是太保守了？啥都扫一遍，肯定慢。于是我开始调整我的策略。

调整扫描策略，速度立竿见影

我发现，Nessus最花时间的地方，在于它要对每一个端口、每一个服务进行深度检查。尤其是一些默认不开放的端口，它都要去试探一下，浪费时间不说，有时候还容易被防火墙或者入侵检测系统（IDS）给拦下来。

我做了两件事：

• 端口扫描策略：我把默认的扫描所有端口，改成了只扫前1000个最常见的端口。这个改动一出，扫描时间直接腰斩了一半。我算了算，那些不常用的端口，就算有漏洞，发现的概率也不高，为了速度，这点牺牲可以接受。
• 插件选择：有些插件是针对特定应用的版本检查，比如某个老旧的FTP服务漏洞，我确定内网里没有，就直接把对应的插件组禁用了。少了成百上千的插件去跑，效率自然就上去了。

目标主机的响应能力是关键

后来我把扫描范围缩小，只扫我们测试部门的几台服务器，结果发现，同样的配置，扫这几台服务器比扫整个部门要快得多。这就让我意识到，目标主机本身的性能和配置，对扫描速度影响太大了。

我记录了两组数据对比：

• 老旧主机：有几台是好多年前买的服务器，CPU老是跑到80%以上，内存也吃紧。扫这些机器的时候，Nessus的进度条经常卡住不动，我去看那台服务器的资源占用，发现它被扫描请求打懵了，响应非常慢。
• 新服务器：我们新上了一批虚拟化主机，资源很充裕，扫起来几乎是瞬时的反馈。Nessus发送请求，机器马上回应，扫描器等的时间短，自然就快。

所以说，如果目标主机处理能力差，扫描器就得在那里干等着，这时间消耗的，比它自己跑检查还多。

网络环境与扫描器的限制

我还得考虑网络带宽和扫描器本身的性能。我试过把Nessus装在虚拟机里跑，也试过直接装在物理机上跑。装在物理机上，资源分配更直接，跑起来明显比虚拟机稳定，尤其是在高并发扫描的时候，虚拟机的IO争抢很明显。

网络延迟和丢包率也是隐形杀手。有一次我远程跑扫描，连接网络不太稳定，进度条爬得慢不说，还报错了好几次，不得不重新跑。对比之下，在我办公室局域网内直接跑，基本很少出岔子。

Nessus想跑快，得是策略精简、目标健壮、网络稳定三者结合。默认配置只是个起点，要想用得顺手、效率高，还得根据实际环境去调教它。