简介：一份面向网络安全专业学生的实验报告，以Nessus扫描工具的使用为核心。内容围绕工具安装配置、插件库部署与客户端管理展开，在局域网指定IP段扫描和本机扫描两种场景下，完整记录了扫描配置过程与结果输出，包括对离线主机的成因分析，以及对扫描结果中中等风险问题的复盘判断。报告对VNC远程显示端口、NetBIOS信息收集、操作系统识别、开放端口服务等关键漏洞逐项分析，比较了不同主机扫描结果的差异，由此阐述插件扫描原理、结果研判方法与针对扫描工具的具体防范措施。资源为1个PDF文件，包体大小1.11MB，结构包含实验目的、要求、内容、分析与总结，适合用于撰写实验报告、课程设计或复习漏洞扫描技术要点。该资料在CSDN已有424人学习下载，具备较好的学习参考价值。
1. 从一次实验报告看 Nessus 扫描工具：它到底在帮你暴露什么
你手上这份《网络安全实验报告-Nessus扫描工具的使用》，不是一份普通的课堂作业抄本。它记录的是一次完整的漏洞扫描实操：在一段 C 类地址上扫主机、对单台本机做端口与服务指纹识别、从 VNC 到 NetBIOS 再到 SMB 空会话逐条分析，最后还要针对扫描结果做加固并复扫对比。搁在今天看，Nessus 已经迭代到 10.x，插件库和 Web 界面都换了几轮，但这份报告里沉淀的流程、分析思路和踩坑记录依然不过时——这也正是它值得下载复现、值得拉出来逐段拆解的原因。适合谁？网络安全方向的学生、刚入行做基线检查的运维，以及想弄明白“扫描器到底是怎么把一台机器的信息扒出来的”的从业者。它能解决的问题很具体：装好 Nessus、配好用户、选对策略、看懂报告里的 Medium/Critical 到底意味着什么、最后照着结果做一轮加固。
2. 安装部署：服务器端、插件库、客户端的三角关系
2.1 为什么 Nessus 要拆成“服务端 + 插件库 + 客户端”三段
Nessus 从早期版本开始就不是一个单文件工具。它的架构逻辑很清楚：服务端（nessusd）负责承载扫描引擎和管理配置，插件库负责提供检测脚本，客户端负责发起扫描请求和呈现结果。拆开的好处在于，你可以把扫描引擎部署在机房的一台 Linux 机器上，自己坐在办公位用 Windows 客户端连过去，扫描任务在服务器端跑，结果再拉回本地看。实验环境里用的是 Nessus 3.2.1.1，那是 2005 年前后的插件版本，放在今天看确实老，但安装路径和配置思路是一脉相承的。
安装顺序有讲究。我一般会先在服务器端装好 nessusd，再装插件库，然后才是客户端。不是插件库必须先装，而是插件库的更新过程很耗时，让它先跑起来能省出大量等待时间。如果先装客户端再去配服务端，客户端会因为连不上 nessusd 而报一堆连接错误，容易让新手误判成安装失败。
# 以 RPM 包安装 Nessus 服务端为例 rpm -ivh Nessus-3.2.1.1-es5.x86_64.rpm # 启动服务并注册插件库 service nessusd start /opt/nessus/sbin/nessus-fetch --register <your-registration-code> /opt/nessus/sbin/nessus-update-plugins这段命令里，第一行是装核心引擎，第二行启动服务，第三行用注册码激活插件下载权限，第四行拉取插件库。注意nessus-fetch --register这一步决定了你能不能拿到完整插件，不注册就只能用极少数的内置检测项，扫描结果基本没有参考价值。插件更新因为体积大，经常要等很久，耐心一点，别中途掐断。
2.2 服务端配置与用户分配的细节
Nessus 启动后，默认监听在 8834 端口（老版本是 1241 或 8834，要看具体版本）。服务端装完不等于能用，还要在服务端上创建用户，这个用户才是你后续用客户端登录扫描的凭证。我在做实验时踩过一个坑：直接拿系统 root 去登录 Nessus，结果是连不上的。Nessus 有自己的用户体系，必须用nessus-adduser单独建。
/opt/nessus/sbin/nessus-adduser # 按提示输入用户名，例如 labuser # 输入两次密码 # 选择用户权限，一般实验用 Administrator 或 Standard用户权限这块，实验环境选 Standard 就够用了，能执行扫描、看结果。Administrator 额外有管理插件策略和用户的权利，单机复现实验不需要开那么高。分配完用户后，用客户端连接时填的是服务端 IP 加上这个新建的用户，而不是系统的登录账号。这一点不搞清楚，后面一整天都在报“authentication failed”。
2.3 客户端与服务端版本不一致的活教训
版本匹配是另一个反复出现的翻车点。Nessus 客户端版本如果和服务端差太多，连接时会出现 TLS 握手失败或者协议版本不兼容的提示。这份实验报告里的版本号是 3.2.1.1，客户端必须也跟着用同代的 3.x，不能拿现在 10.x 的新版客户端去连。常见做法是直接在服务端机器的浏览器里访问管理界面，老版本还能用独立的 GTK 客户端。
我这边的习惯是：装好后先用nessusd -D跑一次前台模式看日志，确认没有报错再注册插件。日志里如果出现ERROR: could not open这类路径问题，多半是权限或安装目录被改动过，重新装一遍比排错更快。
3. 扫描策略配置：插件组、端口范围与目标选择的取舍
3.1 策略的四个关键参数
Nessus 的扫描能力完全依赖策略（Policy）配置。新建策略时要定四件事：哪些插件组启用、扫描哪些端口、用什么端口扫描方式、扫描强度怎么控制。默认策略会启用全部插件，但全部启用意味着扫描时间成倍增加，而且很多插件会互相干扰。比如同时启用 DoS 检测插件和 SMB 枚举插件，某些老旧 Windows 主机会直接蓝屏或者断网，这在生产环境是事故。
# 命令行创建策略的方式（老版本支持的配置入口） # 实际更多是在 GUI 的 Policies 页面里操作 # 这里用命令行演示关键参数的含义 /opt/nessus/bin/nessus -q -x -T html \ -P "Safe Checks" \ -p 1-10000 \ -t 219.219.68.106 \ -u labuser -p password \ -c /opt/nessus/etc/nessus/nessus-files/scan.nessus-P "Safe Checks"表示开启安全检测模式，插件不会尝试破坏性攻击，实验环境强烈建议开；-p 1-10000是端口范围，实验报告里扫出来的端口集中在 135、139、443、5400、5800 这些，1-10000 已经覆盖了主要服务；-t是目标 IP；最后的scan.nessus是策略文件。实际上我用 GUI 更多，但理解命令行映射能帮助你搞清楚界面里每个输入框到底对应什么。
端口范围这个参数最值得讲。报告里本机扫描开放了 10 个端口，最低 21，中危 2 个，高危 0 个。如果只扫默认的常用端口，VNC 的 5400 和 5800 很容易漏掉——因为 5400 不是常见端口，不在默认列表里。所以做内网资产梳理时，我一般会把端口范围拉到 1-65535，或者至少 1-10000，否则结论会失真。
3.2 插件组：不是全开就好
报告里最典型的插件是服务检测类：22964 是 VNC 检测，10758 是 VNC HTTP 检测，10150 是 NetBIOS 信息检索。这些插件的原理是向目标端口发送特征请求，根据响应报文判断服务类型。比如 22964 会向 5400 端口发 RFB 协议握手包，收到RFB 003.003就确认是 VNC。理解这点对分析报告很有用：Nessus 报“VNC 服务器运行在这个端口”，不只是说端口开着，而是它通过协议指纹确认了上层服务。
插件组的开启策略，我的经验是分两轮：第一轮只开“服务发现 + 端口扫描”，快速搞清楚目标暴露面；第二轮再开“Windows 枚举 + SMB + 特定服务检测”，针对第一轮发现的端口做深挖。不要一上来就全开，否则你会拿到几百条信息、但不知道哪些才是真问题。
3.3 目标选择的三种写法
实验报告里选了219.219.68.110-219.219.68.120共 11 台主机，最后扫出来 8 台。Nessus 的目标输入支持单 IP、IP 段、CIDR 三种写法，实验里用的连字符格式等同于 IP 段。
219.219.68.110-219.219.68.120 # 区间写法，精确控制范围 219.219.68.0/24 # CIDR 写法，适合整段资产盘点 219.219.68.106 # 单机写法，适合排除干扰后的定点扫描有一个细节容易踩坑：实验报告里专门排除了本机219.219.68.106。为什么排除？因为 Nessus 扫描本机会把自身也纳入结果，而本机往往开着扫描器相关端口，结果会产生干扰。实际做扫描时，我习惯先把目标网段里所有 IP 探活一遍（用ping -c 1批量探一遍），再把不通的 IP 从目标里剔除。报告里 11 台只扫出 8 台，原因可能是另外三台没接入网络或 IP 被改过，这个分析放在今天依然成立。
4. 报告分析实战：从端口列表到漏洞研判的完整读法
4.1 网段扫描结果的颜色逻辑
扫描 8 台主机里有 5 台显示黄色标记“Medium Severity problem(s) found”，3 台是黑色无标记。Nessus 的结果列表里，黑色代表“没有检出中危以上问题”，黄色代表有 Medium，橙色是 High，红色是 Critical。只看颜色只能判断个大概，真正有用的是对比分析。报告里发现.113比.112多了一项general/udp检测项，因此判断问题出在 UDP 服务上。
UDP 这里值得展开说。TCP 扫描是三次握手完成状态判断，可靠性高；UDP 扫描只能靠 ICMP Port Unreachable 来判断端口是否关闭，如果目标主机不回包，Nessus 就会把端口标记为open|filtered，然后继续对其发送 UDP payload 来探测服务。这种探测方式误报率天然高。.113多出的general/udp意味着它在某个 UDP 端口上有响应或者有过滤行为，Nessus 无法完全确认端口状态，于是给了个 Medium。这不是说那台机器一定有漏洞，而是说它存在“不可确认的攻击面”——这种结论在写报告的时候要表达准确，不能直接说“有漏洞”。
4.2 本机扫描的核心端口解读
本机扫描结果是整份报告里信息密度最高的部分，操作系统识别为 Windows XP，置信水平 99，方法 MSRPC。这句话翻译一下：Nessus 通过向 135 端口发 MSRPC 请求，从响应中提取到 Windows 版本特征，然后和特征库比对得出结果。不是猜的，是有协议级依据的。
# 解析 Nessus HTML 报告的关键字段示例（简化版） # 实际报告是 HTML/XML 结构，这里演示提取端口与风险等级 import re report_text = open("scan_result.html", encoding="utf-8", errors="ignore").read() # 提取所有的 Nessus 插件 ID plugin_ids = re.findall(r"Nessus ID[：:]\s*(\d+)", report_text) print("插件ID列表:", plugin_ids) # 提取端口与协议组合 port_info = re.findall(r"端口[：:]?\s*([\w\-.]+)\s*\((\d+)/(tcp|udp)\)", report_text) for name, port, proto in port_info: print(f"端口 {port}/{proto} 服务识别: {name}")这段代码可以帮你把 HTML 格式的扫描报告里端口、协议、插件 ID 批量抽出来，做成一个可检索的清单。正则可能要根据报告格式微调，但思路是通用的——拿到报告先结构化，再逐条看。从报告看，5400/tcp 检测到 VNC（RFB 003.003），5800/tcp 有 VNC HTTP 服务，SSDP 1900 也有探测，137/udp 有 NetBIOS 名称信息泄露，139/tcp 上发现了 NULL 会话可登录和 SMB NativeLanMan 信息泄露。这几个条目串起来说明这台上网机器有几件事：开了远程桌面类服务且未限制来源、NetBIOS 信息可达、SMB 空会话能枚举信息。
4.3 风险因素“无”的准确含义
报告里很多条目的风险因素是“无”，包括 VNC 协议版本识别、NetBIOS 名称获取、HTTP 头信息探测。新手容易理解成“没问题”，实际意思是“这个信息泄露本身没有直接评分，但它是攻击链的起点”。比如 NetBIOS 名称 + MAC 地址暴露，配合 SMB 空会话，攻击者就能进一步枚举用户名、共享目录、补丁级别，然后针对性利用。Nessus 的评分机制是单条目的，它不会把多个低危信息串成一条高危链条，这需要分析者自己串联。写分析报告时，把这种组合拳逻辑写清楚，比罗列几十条 Medium 更有说服力。
5. 避坑与常见问题排查：安装、扫描、结果三个阶段的典型翻车记录
5.1 插件更新卡住不动
现象：nessus-update-plugins执行后长时间停在下载阶段，网络连接看着还在，但进度条几乎不动。原因：插件库文件体积大，且服务端默认从国外源拉取，实验室网络环境下延迟和丢包都很明显。解决：优先检查/opt/nessus/var/nessus/下是否有临时下载文件，有的话删除重试；设置 HTTP 代理后用all_proxy环境变量指向本地代理下载；实在不行就手动下载插件包再本地导入，nessus-update-plugins --tar-file指定离线包路径。
5.2 客户端登录一直提示认证失败
现象：用户名密码确认无误，但客户端连接服务端时报authentication failed。原因：八成是用系统账号登录了，Nessus 要求的是专用扫描账号；另外也可能是客户端和服务端版本跨代。解决：重新执行nessus-adduser创建一个新用户，用新账号登录；如果还不行，检查服务端日志/opt/nessus/var/nessus/nessusd.messages看是否有 TLS 版本不兼容记录。
5.3 网段内主机扫描数量少于预期
现象：目标段写了 11 台，只扫出来 8 台。原因：目标主机未接入网络、IP 地址被 DHCP 改变，或者主机开了防火墙策略丢弃了 Nessus 探测包。解决：先做一轮ping探活确认哪些 IP 在线；在线但扫不到的主机检查防火墙入站规则，Windows 机器重点看“文件和打印机共享”是否启用以及 ICMP 是否被拦。如果目标装了个人防火墙且默认丢弃所有入站，Nessus 的 TCP SYN 扫描拿不到任何响应，自然会跳过。
5.4 本机和目标主机互相扫描产生污染数据
现象：扫描结果里突然多出一堆来源不明的服务，端口列表和实际不符。原因：扫描器所在机器如果同时被其他扫描任务覆盖，或者本机开放了 Nessus 相关服务端口，会被误判为目标服务。解决：扫描目标列表里显式排除扫描器自身 IP；有条件的话把扫描器放到独立网段，和扫描目标做物理隔离。
5.5 UDP 检测结果大量 Medium 无从下手
现象：一整批主机都标记为 Medium，点开全是general/udp相关条目。原因：UDP 扫描可靠性本来就低，防火墙丢包、无响应都会导致 Nessus 标记为open|filtered，从而触发中等风险判定。解决：核对具体 UDP 端口号，对关键端口另做一次手动探测（比如用nc -u -z -v验证）；如果确认服务不存在，在报告里标注“探测受限导致的误报”，不要直接写进漏洞清单。
6. 扫描后的加固验证：用“收敛 + 复扫”检验你的整改有没有落地
先明确一点，加固不是把漏洞报告里的条目一条条打勾，而是要理解每个问题对应的攻击路径，然后切断路径。从这份报告的扫描结果来看，优先级最高的是 SMB NULL 会话和 NetBIOS 信息暴露。Windows XP 上默认开启的 NetBIOS over TCP/IP 会让 137/139 端口对外响应名称请求，SMB 空会话则允许匿名用户连接。这两条连在一起，攻击者能拿到主机名、MAC、域名、操作系统版本，等于给后续攻击画了张地图。针对这种实验室环境，最优解是直接禁用 NetBIOS over TCP/IP 和空会话访问。
# 关闭 NetBIOS over TCP/IP（Windows 命令，需管理员权限） netsh interface ip set netbios disable # 通过注册表禁止 SMB 空会话枚举（对应报告中的 CVE-2002-1117） reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RestrictAnonymous /t REG_DWORD /d 2 /f # 停止并禁用 Remote Registry 服务，避免注册表远程访问探测 sc stop RemoteRegistry sc config RemoteRegistry start= disabled这三条是实验室场景最直接的收敛手段。第一条禁掉 NetBIOS，第二条把匿名枚举限制拉到最高，第三条关掉远程注册表服务。执行完之后，VNC 那两条怎么处理？VNC 本身不是漏洞，风险在于暴露在公网且未限制来源。如果实验场景允许，直接把 5400 和 5800 端口加入防火墙黑名单，或者用 ACL 限定只允许管理网段访问。下图是常见的验证方式：做完加固后，用相同的策略和目标再跑一次扫描，对比两次结果。
# 对比两次扫描结果的风险等级计数（示例脚本） import re from collections import Counter def count_severity(file_path): text = open(file_path, encoding="utf-8", errors="ignore").read() medium = len(re.findall(r"Medium Severity", text)) high = len(re.findall(r"High Severity", text)) critical = len(re.findall(r"Critical Severity", text)) return {"medium": medium, "high": high, "critical": critical} before = count_severity("scan_before.html") after = count_severity("scan_after.html") print("加固前:", before) print("加固后:", after)这个对比脚本的意义不只是看数字降没降，而是验证整改动作是否生效。比如 RestrictAnonymous 设置为 2 之后，SMB 空会话相关的 Nessus ID 10394 和 26920 条目应该消失，137/udp 的 NetBIOS 条目也会因为服务被禁用而不再响应。如果复扫后这些条目还在，说明配置没有真正生效，或者目标机器需要重启。用同样的策略复扫最大的价值在于：控制变量。策略变了，结果差异就说不清是加固带来的还是扫描噪声造成的。我自从做过一次“加固后换了个策略去扫，结果漏洞数反而变多”的尴尬事之后，每次复扫都强制要求自己和前一次用完全相同的策略文件，只在目标 IP 上做最小改动，然后逐条对比插件 ID 级别的变化，而不是只看中高危总数。这份实验报告最值得下载的地方，正是它在 2013 年就走通了“扫描 - 分析 - 加固 - 复扫”这条完整链路，你现在照着复现一遍，省掉的是自己摸索安装、配策略和读报告的时间。希望帮到你。
本文还有配套的精品资源，点击获取
