1. 为什么我坚持把 Nessus 放在虚拟机里跑
虚拟机里装 Nessus,这个组合看上去像是"多此一举"——直接装在物理机上不也一样能用吗?我最初也是这么想的,直到有一次在一台自用笔记本上跑完整网段扫描,插件库把系统盘吃掉十几 G,扫描进程把内存吃到接近满载,同时那台机器上还开着几个正在调试的服务,结果整个环境卡到没法用。从那次之后,我的规矩就定下来了:Nessus 这类主动扫描器,一律进虚拟机。
Nessus 是 Tenable 出品的漏洞扫描器,干的是"主动探测"这件事——往目标端口发探测包、用几万条插件规则去匹配服务指纹、在本地维护一个体积不小的插件与结果数据库。这些行为叠加在一起,就决定了它不适合和你的日常生产力环境共用一套系统。放在虚拟机里,它就可以是一台"专门的扫描机":配置可以给得抠一点,磁盘可以随它写,扫完不满意直接回滚快照,一点都不心疼。
1.1 扫描器天生带着"脏活"属性
这里说的"脏",不是说工具本身有问题,而是它的工作方式决定的。一次典型的非凭据扫描,Nessus 会对目标做端口发现、服务识别、协议握手、漏洞特征匹配,中间会产生大量半开连接和异常报文。在企业网络里,这种行为会被 IDS/IPS 记录、被终端防护拦截,甚至被业务方当成攻击投诉——这是很正常的现象。
所以环境隔离的价值就出来了。虚拟机是一层物理隔离,扫描流量从虚拟网卡出去,出问题影响的是这台虚拟机的网络状态,而不是你宿主机上正在用的浏览器、IDE、数据库客户端。更重要的是,扫描器经常需要接触一些你不希望留在本机的数据:目标资产清单、扫描结果里的主机名与路径、可能包含敏感信息的响应片段。把这些东西关在一个可以整体删除的虚拟磁盘里,比事后手工清理干净得多。
1.2 快照是这套方案里最值钱的东西
我给虚拟机装完系统、装好 Nessus、插件更新到最新之后,做的第一件事永远是打一个干净快照,命名成类似"base-nessus-ready"这种一看就懂的名字。
这个快照的价值在几个具体场景里体现得特别明显:
- 插件库升级到某个版本后行为异常,或者误删了配置目录,回滚快照比重新装一遍省一个小时;
- 做实验性质的扫描策略,需要反复调整参数又不想污染正式配置,快照就是低成本沙盒;
- 授权到期、需要重新初始化向导时,从干净状态重来比在已有环境里修修补补更省心。
需要注意的是,快照不是备份。虚拟机快照保留的是磁盘状态,如果你的虚拟机磁盘文件本身损坏,快照也救不回来。我一般的做法是:干净的基线状态用快照锁住,同时把 Nessus 的授权文件和重要的扫描结果定期导出到宿主机,两条腿走路。
1.3 虚拟机配置怎么给才不憋屈
网上很多教程让你给 2 核 2G,这个配置能开机、能进 Web 控制台,但一旦开始插件编译或全端口扫描,会慢到让你怀疑人生。按我的实测经验,可以这样分配:
| 资源项 | 最低可用 | 日常舒适 | 说明 |
|---|---|---|---|
| CPU | 2 核 | 4 核 | 插件编译和多目标并发扫描吃 CPU |
| 内存 | 4 GB | 8 GB | 低于 4 GB 时扫描大网段容易触发 OOM |
| 系统盘 | 40 GB | 80 GB | 插件库本体加数据库会持续增长 |
| 网络 | 桥接或仅主机 | 桥接 | 取决于你要扫哪一段网络 |
| 快照空间 | 预留 20 GB | 预留 40 GB | 快照不是零成本的 |
如果你用的是笔记本做宿主机,还需要注意一件事:虚拟机开着扫描跑的时候,宿主机风扇会明显起飞。这不是虚拟机的问题,是扫描本身在压榨 CPU。要长时间跑扫描,尽量找个散热过得去的机器,别在开会前五分钟开扫。
2. 底座要先打好:虚拟机网络模式与系统选型
装 Nessus 之前,虚拟机本身有三件事必须想清楚:网络模式选哪种、装哪个系统、装机之后要做哪些收尾配置。这三件事如果一开始搞错,后面会出现"能装不能扫""扫不到目标""宿主机打不开控制台"这类让人抓狂的问题,而且排查起来非常费时间。
2.1 网络模式选错,扫描结果全废
虚拟机网络模式直接决定扫描流量从哪张网卡出去、能看见哪些目标,这是最容易被忽略却最关键的一步。
- 桥接模式:虚拟机和宿主机同级,获取同一网段的 IP,扫内网其他机器最自然。缺点是把这台扫描机直接暴露在网络里,企业环境里可能触发安全策略告警。
- NAT 模式:虚拟机通过宿主机做地址转换出去,能上网、能更新插件,但从宿主机外部无法直接访问虚拟机的 Web 控制台,需要在虚拟机软件里配置端口转发。
- 仅主机模式:虚拟机和宿主机组成一个封闭小网络,适合纯隔离实验。它上不了外网,插件更新只能走离线包。
我的建议是:要扫真实内网就用桥接,纯做实验就用仅主机加宿主机端口转发。NAT 模式最不推荐用于扫描,因为它会改写源地址,很多基于源 IP 做访问控制的目标系统会直接把你当异常流量处理。
顺带提一个高频问题:虚拟机装好之后发现"网络适配器 vmnet1 有感叹号",或者宿主机根本连不上虚拟机的服务。这种情况大多数不是系统问题,而是虚拟网络编辑器里的虚拟网卡配置被改乱了。进虚拟网络编辑器,把虚拟网卡恢复默认设置,然后重启一下虚拟网络服务,通常就能解决。
2.2 系统选型:为什么我更倾向最小化安装的 Linux
Nessus 支持 Windows 和主流 Linux 发行版,两边都能跑通,但我日常用的是 Linux,理由很务实:
第一,Linux 的资源占用低。同样给 4 GB 内存,Linux 下 Nessus 能拿到的可用内存明显更多,扫描并发能力也更好。第二,命令行操作更顺手,看日志、改配置、跑离线更新都是几行命令的事,不用来回点图形界面。第三,出问题的时候,日志位置固定、格式清晰,排查路径短。
具体发行版上,Debian/Ubuntu 系列和 RHEL/CentOS 系列都是官网直接提供安装包的,选你熟悉的那个就行。我一般用 Ubuntu Server 的最小化安装,装完只有基础系统,没有桌面环境、没有多余服务,攻击面小、快照体积也小。
如果你确实需要在 Windows 上装,也不是不行。Windows 版走标准的安装向导,装完服务会自动注册,Web 控制台同样是 8834 端口。只是要注意 Windows 下磁盘占用增长会更快一些,而且系统本身的内存开销会挤压 Nessus 的可用资源,所以给 Windows 虚拟机的内存建议再往上加一档。
2.3 装机后必做的三件收尾事
系统装完别急着装 Nessus,先把这三件事做掉,能省掉后面一大堆莫名其妙的报错。
第一件,时间同步。虚拟机的时钟在长时间挂起后容易漂移,而 Nessus 的插件更新、证书校验、扫描时间戳都依赖系统时间。时间不准的时候,你可能看到"证书无效""更新时间异常"这类报警。装个时间同步服务,开机自动对齐就行。
第二件,磁盘和分区规划。如果装系统时用的是默认分区,根分区可能只给了二十来 G,插件库更新几轮就满了。我习惯在装系统时手工分区,给/opt单独留一块空间,因为 Nessus 默认就装在/opt/nessus,数据也跟着长在这里,单独分区方便后续扩容和监控。
第三件,本地防护策略的取舍。虚拟机自带的防火墙如果拦了 8834 端口,你在宿主机上就打不开控制台。要么提前放行 8834,要么在确认这台机器只在实验网段使用的前提下,暂时把本地防火墙关掉。这里要强调一句:只在隔离的实验环境里做这个取舍,真实内网里的机器不要随手关防火墙。
3. Nessus 安装:从安装包到 Web 控制台的完整链路
到这一步,虚拟机已经是一台干净、联网正常、时间准确的 Linux 机器了。接下来是安装本体。整个过程其实不复杂,但每一步都有几个容易忽略的细节,我按实际操作顺序拆开讲。
3.1 安装包怎么拿、怎么确认没拿错
Nessus 的安装包只从官方渠道获取,这是原则问题。原因很直接:扫描器本身就在做安全相关的操作,你从第三方站点下载的包,谁也不知道里面被塞了什么。官方下载页面会根据你的系统给出对应的包格式,Debian/Ubuntu 是.deb,RHEL/CentOS 是.rpm,文件名的版本号部分要留意,不同版本在配置文件和命令行参数上是有差异的。
拿到包之后,我习惯先看一眼文件大小和校验信息,确认下载过程没出岔子。用sha256sum算一下摘要,和官方页面公布的对照,几秒钟的事,但能排除掉因为网络中断导致的半个包。这种"半个包"最坑人,安装时可能不报错,运行起来才出各种诡异问题。
3.2 安装命令与目录结构
Debian/Ubuntu 系列上,进到包所在目录执行安装:
sudo dpkg -i Nessus-<版本号>-ubuntu<发行版代号>_amd64.debRHEL/CentOS 系列上:
sudo rpm -ivh Nessus-<版本号>-el<版本号>.x86_64.rpm如果dpkg提示依赖缺失,先跑一次sudo apt --fix-broken install把依赖补齐再重装。
装完之后,你会得到一个结构相当清晰的目录树,理解它比死记命令有用得多:
| 路径 | 作用 |
|---|---|
/opt/nessus/sbin | 命令行工具目录,nessuscli、nessusd都在这里 |
/opt/nessus/etc/nessus | 配置文件,包括服务端配置和授权文件 |
/opt/nessus/var/nessus | 数据目录,插件库、结果库、日志都在这里 |
/opt/nessus/var/nessus/logs | 日志目录,排查问题的第一现场 |
/opt/nessus/lib | 依赖库与插件运行环境 |
记住nessuscli这个工具,后面更新插件、重置密码、生成离线激活请求码,全靠它。
3.3 服务启动与控制台首次访问
启动服务:
sudo systemctl start nessusd sudo systemctl enable nessusd第二条命令是设置开机自启,建议加上,省得每次重启虚拟机都要手动拉一次服务。
服务起来之后,Nessus 会监听 8834 端口。这时候从宿主机浏览器访问https://<虚拟机IP>:8834就能看到初始化界面。这里有几个高频坑点:
- 必须用 https,直接输 http 是打不开的,浏览器会提示"连接被拒绝",很多人卡在这一步以为是服务没起来;
- 自签名证书警告,浏览器会拦一下,选择继续访问即可;
- 连接超时,八成是防火墙或网络模式的问题,按前面讲的方法逐一确认。
如果宿主机怎么都访问不到,而虚拟机内部curl -k https://127.0.0.1:8834又能通,那问题一定在网络上,不要在 Nessus 身上找原因。按"虚拟机网络模式 → 虚拟网卡状态 → 虚拟机防火墙 → 宿主机防火墙"这个顺序往下排查,基本两三轮就能定位。
3.4 初始化向导与授权方式的选择
首次访问会进入初始化向导:设置管理员账号密码、选择授权类型、等待插件下载编译。这里重点说授权。
Nessus 有面向个人学习和非商业场景的免费授权,覆盖的资产数量有限(通常是十几个 IP),对个人做实验、学习、验证扫描流程完全够用。获取方式是到官方注册账号、申请一个激活码,然后在向导里填入。不要去网上找所谓的共享激活码,这类来源不明的码要么已经被几个人同时占用导致你频繁掉线,要么本身就是无效的,浪费的时间远比自己申请一个多。
如果你的实验环境完全不能联网,Nessus 支持离线激活流程:用nessuscli生成一个挑战码,拿着挑战码去官方页面换取授权文件,再把文件放回虚拟机导入。离线插件包更新也是同样的思路——在能联网的机器上下载插件包,拷进虚拟机,用命令行导入。
初始化过程中,插件下载和编译会花掉不少时间,视机器性能和网络情况从十几分钟到半小时不等。这期间界面会停在"正在更新插件"之类的提示上,鼠标点不动是正常的,不要反复刷新或者重启服务,那会把已经下载的一部分内容作废重来。
4. 插件更新这件事:慢、卡、失败都发生在哪
对 Nessus 来说,插件库就是它的全部知识。没有插件,它只会做最基础的端口识别;插件老旧,它会漏报大量新披露的问题。所以插件更新是日常维护里最频繁也最容易出岔子的环节,值得单独拎出来说。
4.1 首次启动为什么能卡到让人以为死机
首次启动的插件初始化,本质上是把几万个插件脚本从压缩包里解出来,做语法校验、依赖检查、然后写进本地数据库。这个过程是纯 CPU 和磁盘 IO 密集型,对虚拟机的资源配置非常敏感。
我给的经验值是:2 核 4 GB 的虚拟机跑首次初始化,可能要 30 分钟以上;4 核 8 GB 大约 15 分钟;如果磁盘是机械盘,时间还要再翻。这个阶段你能做什么?看日志。日志文件在/opt/nessus/var/nessus/logs/nessusd.messages,用tail -f跟着看,如果日志里在持续输出内容,说明它在干活,只是慢;如果连续几分钟一行不动,那才需要怀疑卡住了。
一个实用的小技巧:初始化期间不要同时跑其他吃资源的任务,尤其是别在这个虚拟机上开图形界面。把资源集中给 Nessus,能明显缩短等待时间。
4.2 在线更新和离线包更新该怎么选
在线更新最简单,Web 控制台里点一下更新,或者命令行执行:
sudo /opt/nessus/sbin/nessuscli update --all它的前提是虚拟机能稳定访问外部更新服务器。如果你的网络环境不稳定或者有出口限制,在线更新很容易中断,而中断后的插件库可能处于半新半旧的状态,这种情况比不更新还麻烦。
离线更新的做法是:在能联网的机器上从官方下载完整的插件包(通常是个几十到上百兆的压缩包),拷进虚拟机,然后执行:
sudo /opt/nessus/sbin/nessuscli update /path/to/all-2.0.tar.gz离线更新的好处是过程可控、可重复,适合网络受限或者需要统一管理多台扫描器的场景。我自己的习惯是:正式环境用离线包,实验环境用在线更新。前者求稳,后者求方便。
4.3 更新失败时的排查顺序
插件更新出错的报错信息往往很模糊,只说"更新失败"。我一般按这个链路往下排查:
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 卡在下载阶段不动 | 出口网络不通或被限速 | 换离线包方式,或检查网络策略 |
| 提示磁盘空间不足 | /opt分区写满 | 清理旧日志、扩容磁盘 |
| 更新到一半报校验失败 | 下载包不完整 | 重新下载完整包,校验摘要 |
| 更新后服务起不来 | 插件库与版本不匹配 | 回滚快照,用匹配的插件包重装 |
| 更新成功但扫描结果异常 | 插件版本与策略不匹配 | 检查策略里引用的插件族设置 |
特别提醒一点:插件更新之前打快照。插件库回滚不像改个配置文件那么简单,没有快照的话,一旦更新搞坏了,你只能清理掉数据目录重新初始化,等于前面所有配置全丢。
5. 跑通第一次扫描:策略、目标与结果解读
Nessus 装好、插件更新完之后,很多人会直接点"新建扫描"、随便填个 IP、选默认模板就开跑。能跑出结果,但结果往往是几百条中低危告警堆在一起,看不出重点在哪。第一次扫描真正该花心思的是三件事:选对模板、配对目标、想清楚凭据要不要给。
5.1 模板不是越多越好,先搞懂它们的分工
Nessus 内置的扫描模板按用途分几大类,新手最容易乱选。实际常用的就这几个:
- 基础网络扫描(Basic Network Scan):通用型,适合第一次摸清一台或一段目标上的服务与已知问题,也是最常用的默认选择;
- 主机发现(Host Discovery):只做存活探测,速度快,适合先确认网段里有哪些机器在线,再决定扫哪些;
- 高级扫描(Advanced Scan):所有参数都开放,适合有明确目标、需要精细控制插件族和性能参数的场景;
- Web 应用测试类:针对 Web 服务做更细的检查,需要你明确知道目标跑的是什么类型的应用。
我的建议是从主机发现开始,先摸清存活主机,再对关键目标用基础网络扫描做一轮,最后才对少数重点系统上高级扫描。一上来就对整个网段跑高级扫描,结果是又慢又吵,收益还低。
还有一个性能参数值得留意:并发主机数和每主机并发检查数。这两个值调大能加速扫描,但对目标系统的压力也会同比上升,在真实生产环境里是很不礼貌的行为。稳妥的做法是从默认值开始,观察目标负载后再小幅上调。
5.2 目标怎么填、凭据要不要给
目标位置支持单个 IP、IP 段、主机名、甚至从文件导入。填 IP 段的时候注意 CIDR 写法,写错了会扫出大量无关主机。我习惯把目标清单单独维护成一个文本文件,每次扫描从文件导入,这样资产范围清晰、可追溯。
凭据配置是新手最容易忽略、但对结果质量影响最大的一项。不给凭据的扫描叫"非凭据扫描",只能从外部看服务版本和响应特征,能看到的问题有限;给了凭据(SSH、SMB、数据库账号等),Nessus 可以登录进去做本地检查,比如看补丁级别、看配置文件、看已安装软件版本,能发现的问题多出一个量级。
不过给凭据这件事要慎重。用哪种账号、给多大权限、这台扫描机的凭据怎么保管,都需要提前和资产负责人确认。我的做法是:专门建一个只读的扫描账号,只授予检查所需的最小权限,绝不复用管理员账号。
5.3 扫描跑起来之后盯哪几个指标
扫描一旦启动,控制台上能看到进度、剩余时间、已发现问题数量这些信息。我实际会关注三类信号:
第一是扫描速度,如果长时间停在很低的百分比,可能是目标响应慢或者某类检查卡住了。第二是告警数量增长速度,如果短时间内爆出大量同类告警,通常是某个服务版本整体过旧,属于系统性问题的信号。第三是扫描机自身的资源占用,如果内存和 CPU 接近上限,扫描结果的可信度是要打折扣的,因为超时导致的误判会增加。
还有一点容易被忽略:扫描时长。同一个目标,不同时段扫出来的结果可能不同,因为有些服务在业务高峰期会限制连接。我一般把耗时较长的大范围扫描安排在业务低峰期,结果会更干净。
5.4 报告出来后先看什么
扫描完拿到报告,看到几百条结果直接懵掉是很正常的。我的阅读顺序是这样的:
先看高危和严重级别,这部分数量通常不多,但每一条都值得认真读。Nessus 会给每条问题附上描述、检测原理、修复建议和外部参考链接,判断是不是误报的关键在于看它的检测依据和你对这台机器的实际了解是否吻合。
再看中危里的"配置类"问题,比如弱加密套件、允许的认证方式过宽、服务 banner 暴露版本信息。这类问题单独看不致命,但组合起来经常是完整攻击链的入口。
最后批量处理低危和信息类。这部分数量最大,但价值在于建立资产画像——你能从里面看出这台机器上跑着什么服务、开放了什么端口、装了哪些组件,这些信息对后续做资产梳理很有用。
导出报告时,.nessus格式是 Nessus 自己的 XML 结构,适合后续再导入分析;CSV 适合丢进表格里做统计和筛选;PDF 适合给不做技术的人看,但排版在结果量大时会比较难看。我一般同时导出.nessus和 CSV 两份,前者留档,后者干活。
6. 用了小半年之后,我总结出的几个实操心得
前面讲的是流程,这里讲一些流程之外的东西,都是踩过坑之后才明白的。
6.1 关于"扫自己家的机器"这件事的边界
扫描器的能力是中性的,用在哪、怎么用,才是关键。我一直给自己定两条规矩:一是只扫自己有明确授权的资产,包括自己搭的实验环境、公司明确指派给我的测试范围;二是扫描前通知相关方,尤其是可能触发告警的业务系统。
原因很实际:主动扫描的流量特征和探测行为在很多防护体系里会被判定为可疑,你不打招呼就扫,轻则被拦截、重则被当成攻击事件上报,后续解释成本远高于提前说一句。真做过这件事的人都知道,最麻烦的从来不是技术问题,是沟通问题。
6.2 虚拟机长期运行的维护动作
虚拟机不是装完就不管了。我的日常维护清单大概是这几项:
- 定期检查
/opt分区使用率,插件库和结果库都会持续增长,别等到写满才发现; - 定期清理旧的扫描结果,只保留需要留档的部分,历史结果占的空间比你想的多;
- 保留一到两个干净快照,但不要把快照一直挂着不带清理,快照链太长会影响虚拟机整体性能;
- 授权到期前提前处理,别等到扫描跑到一半提示授权失效。
还有个小细节:如果你把虚拟机长期挂起而不是关机,重新恢复后先确认一下系统时间和服务状态,挂起过的机器这两项最容易出问题。
6.3 结果只是起点,修复闭环才是目的
扫描报告出了几百条问题,如果只是导出 PDF 归档,那这次扫描的价值基本等于零。真正有用的做法是给问题分派负责人、定修复期限、修完再验证一轮。
验证的方法很简单:针对已修复的条目,用同一个策略对同一目标再扫一次,对比两次结果的差异。Nessus 支持对扫描结果做比较,能直接看出哪些问题消失了、哪些还在、有没有新引入的问题。这个对比视图比翻两份独立报告高效得多。
我的做法是在虚拟机里保留一份"基线扫描结果",作为后续所有对比的参照。每季度扫一次,对比基线,就能比较清楚地看到整个环境的安全状况是变好还是变差。这比单次扫描报告里那堆数字有意义得多。
最后再说一个我个人比较看重的习惯:每次扫描完,把策略、目标范围、扫描时间、结果摘要记在一个简单的文本笔记里。Nessus 自己会记录扫描历史,但不会记录"当时为什么这么扫"。过几个月回头看,这份笔记比任何报告都更能帮你还原当时的判断依据。