简介一份面向网络安全专业学生的实验报告以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, encodingutf-8, errorsignore).read() # 提取所有的 Nessus 插件 ID plugin_ids re.findall(rNessus 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 检测到 VNCRFB 003.0035800/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/IPWindows 命令需管理员权限 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, encodingutf-8, errorsignore).read() medium len(re.findall(rMedium Severity, text)) high len(re.findall(rHigh Severity, text)) critical len(re.findall(rCritical 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 年就走通了“扫描 - 分析 - 加固 - 复扫”这条完整链路你现在照着复现一遍省掉的是自己摸索安装、配策略和读报告的时间。希望帮到你。本文还有配套的精品资源点击获取