简介这是一份聚焦Nessus漏洞扫描工具的网络安全实验报告适合网络安全初学者、高校学生及运维人员用于理解漏洞扫描与插件扫描原理并学习如何针对扫描工具进行防范。全文按实验目的、要求、内容、分析组织既介绍了Nessus服务器端、插件库和客户端的安装与配置也展示了局域网主机扫描与本机扫描的完整过程。报告对IP段219.219.68.110-120内8台主机的扫描结果进行了对比解释了UDP传输不可靠与中等风险之间的关联本机扫描部分则详细列出开放端口、VNC与NetBIOS服务识别、风险因素及过滤流量、停用服务等加固建议。资源包共1个PDF文件大小约1.11MB内容完整、目录清晰可直接作为实验报告写作或复习备考的参考模板。该报告已有424人学习下载具有较好的参考价值。1. 网络安全实验报告里为什么拿 Nessus 当主力扫描工具写网络安全实验报告最绕不开的一步就是漏洞发现。而 Nessus 扫描工具基本是这类实验里出场频率最高的那个。它能在一次扫描里把主机的开放端口、服务版本、已知 CVE、弱配置一并拉出来最后生成一份带风险等级和修复建议的报告直接能贴进实验文档。对还没入门的学生或者刚转岗的工程师来说它的价值不是“扫得多深”而是“扫完能看懂、能交代”。这篇笔记就从一份实验报告的完整产物出发把 Nessus 从部署、配置、执行到结果解读的整条链路拆开讲让你照着做就能跑通并且知道每一步为什么要这么做。2. 实验环境的 Nessus 部署安装、激活与三个必调参数2.1 实验场景选型Nessus 和常见漏洞扫描工具差在哪做实验之前先要回答一个问题为什么选 Nessus而不是用 OpenVAS、Nikto、masscan 这些工具凑一套组合拳。常见做法是OpenVAS 免费且开源适合想折腾底层机制的爱好者但它的问题在于部署重、依赖复杂插件库更新慢结果里噪声大Nikto 只面向 Web 服务扫不出主机层面的端口和系统漏洞masscan 只管端口发现根本不给你漏洞结论。Nessus 在这个对比里的定位是“开箱即用的综合评估工具”它对实验报告最友好的地方在于结果结构化——每个漏洞都带有 CVE 编号、CVSS 分数、插件家族、风险等级、修复建议这些字段在写实验报告时可以直接引用不需要你再拿多个工具的结果做二次汇总。Nessus 分为 Essentials、Professional 等版本实验场景用 Essentials 免费版就够。免费版限制扫描的 IP 数量一般是 16 个做内网靶机实验完全够用。激活方式需要一个邮箱接收激活码下载安装包后填码解锁插件库。要注意的是插件库更新依赖网络条件插件包体积不小第一次更新可能很慢后面我会专门讲这个坑。2.2 安装与激活的完整步骤从下载到 Web 界面Nessus 的安装包在官网按操作系统区分实验场景最常见的是装在 Linux 虚拟机里比如 Kali 或 Ubuntu Server。以 Ubuntu 为例拿到.deb安装包后执行安装装完会注册一个系统服务叫nessusd。安装完成后先确认服务状态再打开浏览器访问 Web 界面。sudo dpkg -i Nessus-xxx-ubuntu.deb # 安装 Nessus 服务 sudo systemctl start nessusd # 启动 Nessus 服务 sudo systemctl status nessusd # 查看服务运行状态active 才算正常服务启动后在浏览器访问https://localhost:8834。第一次打开会提示证书不受信任这是因为 Nessus 用的是自签名证书选择“继续访问”即可。首次进入 Web 界面会引导你填激活码并创建管理员账号。激活码填入后页面会进入插件初始化阶段正常情况下会显示插件下载和编译的进度条。这段流程里有几个参数值得留意。端口 8834 是 Nessus Web 服务的默认监听端口如果实验环境里 8834 被其他进程占用安装后服务可能起不来用sudo netstat -tlnp | grep 8834查一下即可确认。另外自签名证书在部分较新的浏览器里可能被拦截得更严格遇到打不开页面的情况换 Firefox 或者用--ignore-certificate-errors参数临时绕过不要纠结证书警告本身。2.3 部署阶段会碰到的三个参数监听地址、端口与插件更新策略部署阶段有三个参数建议在实验报告里写一笔因为很多翻车现场都出在这三个地方。一是服务监听地址。默认情况下 Nessus 只监听本机的 8834 端口也就是只有你自己能访问。如果实验环境是 Kali 虚拟机而你想从宿主机浏览器访问 Nessus需要把监听地址改成0.0.0.0或者宿主机可达的网卡地址。改法是编辑 Nessus 的配置文件位置一般在/opt/nessus/etc/nessus/nessusd.conf找到listen_address这一行修改改完重启服务。二是扫描并发参数。Web 界面里虽然有大把按钮但真正决定扫描速度和负载的是配置里的max_threads和每主机并发数。这个在后面的扫描策略一节详细展开部署阶段你要知道的只是默认并发参数偏保守扫一个小靶场没问题但如果你觉得扫描慢不是网卡了是并发没调。三是插件更新策略。Nessus 每次启动扫描时会先检查插件库是否有更新。免费版的插件更新频率有平台限制不必刻意去追最新版本实验报告里只要记录“扫描前插件库更新到某日”即可。但要注意插件更新的耗时和你所在网络环境强相关几十 MB 到几百 MB 的插件包如果网络不稳定会反复失败这会直接导致扫描按钮灰着点不了也是后文避坑章节的第一条。提示部署阶段不用追求所有参数最优先让服务能跑起来、Web 界面能打开再逐项调参数。很多人在安装环节花大量时间调网络参数实际上插件更新和扫描并发才是后面真正会卡住你的点。3. 配置一次可复用的实验扫描模板、目标网段与扫描策略参数3.1 扫描模板怎么选Basic Network Scan 与 Advanced Scan 的边界Nessus 新建 Scan 的时候会给你一排模板最常见的两个是Basic Network Scan和Advanced Scan。实验报告里如果是做常规主机漏洞评估用 Basic Network Scan 就够Advanced Scan 多出来的能力体现在能自定义端口范围、Web 扫描开关、暴力破解强度等选项适合你知道自己在做什么、想控制扫描行为细节的场景。对新手来说别一上来就选 Advanced默认配置下它会启用更多探测方式扫描时间拉长结果里也多出一堆和实验内容无关的噪声。Basic Network Scan 的本质是全端口发现 服务识别 漏洞匹配它对内网主机做一次覆盖式的 TCP 连接扫描识别开放端口上跑的服务然后用插件库里的签名去匹配已知漏洞。实验报告里的目标通常是靶机镜像这类镜像里的漏洞大多是比较老、特征明显的 CVEBasic Network Scan 完全能覆盖。如果你在写报告的时候发现目标漏洞没扫出来先别怀疑模板不够强先看是不是目标机防火墙挡了探测包。3.2 目标填法与排除项CIDR、IP 列表和本地排除配置新建扫描时有一个必填项是 Targets这里的填法直接影响扫描效率和结果质量。Nessus 支持三种常见写法单个 IP、CIDR 网段、用逗号分隔的 IP 列表。实验场景里如果你的靶场是隔离的内网环境直接填整个网段比如192.168.1.0/24最省事但如果你只是想测两台指定的虚拟机填192.168.1.10,192.168.1.20更精准扫描时间会短得多。填目标的同时务必顺手配置排除项。Nessus 的 Exclusions 字段在目标填写的下方它接受和目标一样的格式。排除项里至少要把这几类地址加进去你自己机器的 IP、实验网段里的网关、以及 DHCP 分配的地址池。如果不加排除Nessus 会把网关设备也扫一遍结果里出现一堆打印机、路由器管理界面的中低危漏洞对你的实验结论没有任何帮助只会让报告显得冗长。# Targets 示例实验环境内网目标 192.168.1.10,192.168.1.20 # Exclusions 示例排除网关和自己 192.168.1.1,192.168.1.100这段配置的要点是Nessus 扫描的边界边界之外的内容都写进 Exclusions。实际操作里很多人图省事把整个 C 段填进 Targets结果把本机流量网关、虚拟机的虚拟网卡地址全扫了一遍报告里多出来几十条“SSH Weak Algorithm”之类的中危项这在实验报告里反而显得不够专业。3.3 实验场景下值得改的五个性能参数如果你用的是 Advanced Scan 或 Basic Network Scan 里的自定义配置下面这几个参数是实验中最值得调的它们出问题时的表现各不相同但都有一个共同特征默认值太保守导致扫描时间被无故拉长。第一个是端口扫描范围。默认是全端口 1-65535内网靶机建议改成1-10000或者按实验涉及的端口来填比如一个 Web 靶机实验可以只扫80,443,8080,3306,22这几个常用端口扫描时间能压缩到原来的十分之一。第二个是每主机并发连接数。这个参数决定同一时间对目标建立多少个 TCP 连接Nessus 默认值偏低调高到 5-10 能让扫描快不少但别超过这个范围否则目标机器可能因为连接数过多直接断连结果出现大量“host unreachable”的误报。第三个是扫描强度也就是 scan intensity 相关的选项有些版本里叫依赖范围。默认的强度是“正常”对实验环境来说可以保持默认。如果调成“激进”会启用更多的服务指纹探测好处是识别更准坏处是更容易触发目标 IDS 的告警实验环境里反而干扰判断。第四个是 Web 扫描开关。Basic Network Scan 会附带一部分 HTTP 层的测试项如果目标没有 Web 服务这部分纯属浪费时间可以在高级配置里把 Web 相关的扫描项关掉或者直接选 Port Scan 系统漏洞测试的组合。第五个是 SSH 登录凭据。如果你有靶机的 SSH 账号密码可以填在 Credentials 标签页里Nessus 会登录主机做本地检查查出来的漏洞比远程探测细致得多比如补丁缺失、本地配置错误。实验报告里如果做的是系统加固实验这一项是拿高分的关键。提示性能参数调整的第一原则是“先小后大”。先扫单个 IP看耗时和结果数是否合理再扫整个网段。直接拿一个大网段去试参数出了问题排查起来非常累这也是我反复踩过坑之后养成的习惯。4. 扫描结果怎么看风险分级、误报验证与实验报告导出4.1 先看风险分布再看单条漏洞CVSS 评分体系怎么用扫描完成后Nessus 的结果页会先给你一个风险分布图用 Critical、High、Medium、Low 四种颜色统计漏洞条数。这是实验报告的第一张截图建议直接采信它但别急着往下写。你要能解释这个分布是怎么来的——每一类风险都对应一个 CVSS 评分区间Nessus 用的是 CVSS v3 的标准Critical 对应 9.0-10.0High 是 7.0-8.9Medium 是 4.0-6.9Low 是 0.1-3.9没有评分信息的漏洞会单独归到 Info 级别不算风险。打开单条漏洞详情你会看到这些字段插件名称通常就是漏洞名称、CVE 编号、CVSS 分数、风险等级、描述、解决方案、还有 Nessus 插件本身的家族和 ID。写实验报告时不要只贴一个漏洞列表自己挑两三条典型的漏洞把描述和解决方案翻译成自己的话说清楚这个漏洞“为什么存在、能造成什么影响、怎么修复”。这份解读比罗列全部结果更有说服力也是实验报告里最容易拉开差距的地方。4.2 验证一条结果而不是照抄报告Nessus 的结果是“自动评估”的产物它不等于事实。实验报告里最怕出现的情况是Nessus 报了一个 High 漏洞你直接截图上交但实际这个漏洞根本不存在或者不存在于你能访问的范围内。这类误报在扫描结果里并不少见尤其是当目标设备对探测包有特殊响应时。拿我印象最深的一次实验说Nessus 报目标主机的 3306 端口开放了 MySQL并且匹配出一条“MySQL 存在弱口令”的漏洞。但实际我用手工连接验证时目标端口确实是开的响应内容却是一段自定义的 banner根本不是 MySQL 协议。这种情况常见于靶场里故意部署的蜜罐或者一个完全无关的服务占用了这个端口Nessus 探测到端口开放就按服务指纹匹配了漏洞库。所以一条合格的实验报告起码要有一次验证动作。对于端口类结论用nc或nmap做一次连接验证对于 Web 类漏洞用浏览器或curl手动访问一次页面看响应是否符合预期对于凭据类漏洞尝试用报告里给出的默认口令实际登录一次。实践下来你会发现很大比例的“漏洞”其实是服务探测的误报而验证之后剩下的那部分才是实验结论里真正值得写的核心发现。4.3 导出实验报告选对模板避免交作业翻车Nessus 的结果页右上角有导出功能支持导出 HTML、PDF、CSV、NESSUS 格式。实验报告里最常用的是 PDF 和 CSV。PDF 适合直接作为附录CSV 适合二次整理数据。导出时会让你选报告模板常见的有 Executive Summary执行摘要和 Full Report完整报告。如果是交课程作业或实验报告建议选 Full Report里面会包含每个主机的漏洞明细、解决方案信息完整Executive Summary 只有汇总数据适合给管理层看不适合做学习用途的资料。导出 PDF 时最容易翻车的是排版问题尤其是中文环境的实验报告PDF 里可能出现乱码或者表格错位。这个坑的具体表现和解决方式放在下一章的避坑部分详细说这里先给你一个操作习惯导出之前先把结果按“风险等级”排序然后勾选你要展示的漏洞条目而不是全量导出。全量导出的 PDF 通常很长而且夹杂大量 Info 级别的低价值信息反而淹没了实验的核心结论。5. Nessus 实验中最常见的五个坑现象、原因与解决5.1 插件一直卡在初始化扫描按钮灰着点不了现象刚装好 Nessus激活码也填了Web 界面里却一直显示 “Plugin compilation in progress” 或者插件的初始化进度条卡住不动新建扫描的按钮点不了。原因插件编译过程依赖下载插件包这一步的时间和网络稳定性直接相关插进下载中断、服务重启、磁盘空间不足都可能导致初始化挂起。多数情况下是插件包没下载完整服务卡在等待状态。解决先看磁盘空间df -h确认/opt/nessus所在分区有足够剩余空间至少 3-5GB。然后重启 nessusd 服务sudo systemctl restart nessusd如果配置没问题重启后初始化会从头继续。如果反复卡在同一个进度手动删掉插件缓存目录里残留的临时文件再重启路径一般是/opt/nessus/var/nessus/plugin_feed_cache。实验环境里最多的场景是网络不稳定导致插件反复下载失败这种情况只能耐心等或者换一个网络更稳定的时段再激活。5.2 扫描目标扫不完时间长得像页面卡死现象一个只有两三台主机的实验网段扫描跑了一个多小时还没完进度条一直在 5% 左右浮动页面也没有报错。原因默认的扫描配置是全端口 中等级别的探测强度加上目标主机如果是 Windows 虚拟机防火墙可能对无效端口的探测包返回超时Nessus 只能等超时等待时间被拉得很长。真正把时间拖慢的往往不是目标数量而是大量没有响应的端口占满了并发槽。解决按第 3 章的办法缩端口范围、提高每主机并发数、排除不相关的目标。如果实验只需要验证某个特定漏洞更快的做法是新建一个只扫描单一端口段的策略把扫描模板改成Host Discovery先确认主机存活再用精简端口策略做漏洞匹配。扫之前先在 Targets 里填一个 IP 试跑估算单机的扫描时长再乘上目标总数心里有数就不会误以为卡死了。5.3 明明有漏洞扫不出来结果为空现象用工具验证目标主机确实存在某个漏洞比如一个弱口令的 Web 登录页但 Nessus 扫描结果里干干净净一条高危都没有。原因这类“扫不出来”的漏报大半是服务指纹识别失败导致的。Nessus 不是魔法它必须先确定端口上是某个具体服务才能匹配对应漏洞插件。如果目标服务返回的 banner 被修改过或者服务运行在非标准端口Nessus 的识别逻辑就会失配进而跳过整个插件家族。另一种常见原因在 Credentials 没填——很多高质量漏洞条目需要登录目标系统做本地检查远程探测只能看到表面。解决先确认服务指纹是否被正确识别在扫描结果的 Host 详情里看开放端口对应的服务名称如果显示的是unknown或者错误的名字问题就出在识别环节。解决思路是给 Nessus 提供更多信息要么手动指定端口对应的服务类型Advanced Scan 里有端口与服务映射的配置要么填上目标的登录凭据开启认证扫描没有登录凭据时至少在报告里注明“本次扫描为未认证扫描结果仅反映远程可见的攻击面”这不是遮丑反而是实验方法上的严谨表述。5.4 报告导出 PDF 排版乱、中文乱码现象扫描结果页里看得很正常一导成 PDF中文变成方块表格线错位漏洞描述的排版乱到没法看。原因Nessus 报告生成的 PDF 依赖服务端预置的字体库对中文的支持并不可靠或者说服务端缺少 CJK 字体的映射导致 PDF 里字体回退成了默认拉丁字体。另一个情况下自定义报告模板里拖了太多列PDF 布局引擎算不过来也会错位。解决最直接的绕过方案是导 HTML 格式Nessus 导出的 HTML 在浏览器里打开再“打印为 PDF”这一步由浏览器完成字体渲染中文乱码问题基本消失。另一个方案是直接导 CSV用数据处理工具生成自己的报告附页排版完全可控。实验报告场景下我常用的是 HTML 浏览器打印 PDF 的组合既能保留 Nessus 的完整排版又不会乱码。5.5 同一目标不同时间扫结果差异很大现象上一次扫描目标主机报了 5 个高危这次扫变成了 8 个甚至上次数的高危这次没报。原因插件库更新是最直接的影响因素。两个时间点之间Nessus 插件库新增了检测规则或者修正了误报逻辑导致同一条结果被加入或移除。另一个因素是目标主机自身状态变了比如服务重启、补丁更新、端口开放策略变化。解决实验报告里要写明扫描时间和插件库版本这一步很多人会忽略。做法是在报告的工具环境描述里加一行记录“Nessus 插件库更新至某一日期”以及“扫描执行时间”。如果要做前后对比不要跨插件更新周期尽量在同一天内完成基线和复查两次扫描。提示以上五个坑是实验场景里最高频的问题前三个影响你能不能拿到结果后两个影响结果能不能写进报告。我自己的习惯是第一次扫一个小目标试全流程然后再扩大范围这能省下后面一大半排查时间。6. 给实验报告加分用 nessuscli 做命令行扫描与定时复查6.1 用 nessuscli 跑一次最小命令行扫描Web 界面能完成大部分实验任务但 Nessus 在底层还提供了一套命令行的管理工具nessuscli用它可以脱离 Web 界面直接发起扫描、查看策略、管理插件。实验报告里写上一笔命令行操作能明显体现出你对工具的理解不止停留在点按钮的层面。# 查看当前 Nessus 服务的状态实例确认服务正常 sudo nessuscli info # 列出已存在的扫描策略获取 policy id sudo nessuscli policy ls # 用指定策略扫描目标主机 sudo nessuscli scan --policy Basic Network Scan --target 192.168.1.10这三条命令的用途分别是确认服务可用、确认策略存在、执行扫描。nessuscli info会输出版本号和插件库更新时间这条信息正好可以写进实验报告的工具环境说明里。nessuscli policy ls里显示的 policy 名称要和扫描模板里保存的策略名一致如果保存的是自定义策略就用自定义的名字替换上面的字符串。nessuscli scan发起的扫描在后台运行不会阻塞终端观察结果仍然要到 Web 界面的 Scan History 里查看。命令行方式的实际价值在于可脚本化。如果你要扫描多台机器可以把命令写进一个循环脚本跑完自动收集结果这对做批量实验的环境很实用。但要注意一点命令行发起的扫描使用的是“策略”而不是“模板”所以在这之前你得先在 Web 界面里把想要的配置存成一个 Policy命令行只是引用了那个配置并不是说命令行有一套独立的参数体系。6.2 把扫描策略固化成模板顺便做个定时复查做实验最怕每次扫描都重新点一遍配置所以一个必要的习惯是当你调出一组满意的扫描参数后立刻在 Web 界面的 Policy 里新建一个模板给它一个明确的名字比如lab-basic-scan-tcp10000然后保存。这样后续再做同类型实验只需要选这个模板改一下目标网段其他参数全部继承不会出现两次扫描配置不一致的问题。更进一步如果你熟悉系统定时任务可以用 cron 配合 nessuscli 做定时复查。比如你想观察一台靶机在加固前后几天的漏洞变化可以每天凌晨跑一次扫描用同样的策略和同样的目标这样得到的对比数据在实验报告里非常直观。# 每天凌晨 2 点对实验靶机做一次定时扫描日志输出到文件 0 2 * * * nessuscli scan --policy lab-basic-scan-tcp10000 --target 192.168.1.10 /var/log/lab_nessus_daily.log定时复查的做法有几个前置条件目标机器要常开、扫描策略要保持不变、日志目录要提前建好并且 Nessus 服务有权限写入。如果条件都满足这套机制能让你在一周后拿到一组干净的“漏洞变化时间线”这比单次扫描结果图更有说服力也会让实验报告的结论部分扎实很多。回到开头的问题上Nessus 作为实验工具它的上限不在于工具本身的插件多少而在于你有没有把它当成一个需要“校核”的测量仪器。我做了这么多次扫描实验之后最大的教训就是不要直接信任任何一次扫描结果先看配置再选模板最后手工验证几个关键漏洞然后才敢写结论。这条流程你如果能完整跑一遍无论是写实验报告还是将来做真正的渗透评估项目都不会因为工具层面的事翻车。希望帮到你。本文还有配套的精品资源点击获取