简介：《E002-渗透测试常用工具-使用Nessus扫描操作系统漏洞》是一份面向网络安全初学者与渗透测试入门者的实操型PDF教程。内容围绕Kali Linux环境下Nessus的安装、注册、用户创建、服务启动与Web登录展开，并以Windows XP靶机为例说明漏洞扫描配置，涉及网络连通性验证、扫描目标设定和结果解读等环节，适合用于课程实验、靶场练习与漏洞管理基础训练。资源包内仅含1个PDF文件，大小约13.34MB，版式适合按实验流程阅读与对照操作。目前已有927人学习或下载，说明其在渗透测试工具入门场景中具有一定参考价值。教程把实验环境说明、关键命令、注册与激活流程、离线插件导入及常见激活失败情形的处理思路串联起来，读者可据此搭建一套可复现的Nessus扫描环境，并理解从资产发现到漏洞报告的基本路径。
1. 从一台没打补丁的 XP 靶机说起：Nessus 在漏洞扫描里到底站哪一班岗
一台没打补丁的 Windows XP 摆在网段里，用 Nessus 扫一遍，十来分钟后你拿到的是一张按严重程度排好序的漏洞清单，而不是靠猜。这套实验干的就是这件事：Kali 当渗透机，XP 当靶机，从装包、激活、导插件，到建策略、跑任务、读报告，走完一条完整的漏洞扫描链路。适合两类人：刚接触渗透测试、想把扫描器从「一路点下一步」变成「知道每个参数在干嘛」的新手；以及手上有一堆内网资产、需要定期出漏洞台账的运维。它不负责利用，只负责把「哪台机器、哪个端口、哪个服务、对应哪条公告」摆清楚——这份清单的质量，完全取决于你策略配得细不细。
2. 装之前先把架构和版本对齐：i386 包、依赖与首次启动
装 Nessus 翻车最多的环节不是激活，是包下错了。实验讲义里那台 Kali 是 32 位的，uname -a显示 i686，很多人一看「i686」就去下 64 位包，或者反过来，看到x86_64却拿了 i386 的 deb，dpkg直接甩一句架构不匹配就退出。这一章把从确认架构到服务起来的整条路径拆开，每一步都能对着敲。
2.1 先确认系统架构，再决定下哪个包
uname -a的输出里，机器硬件名那一栏会写i686、i386、x86_64或aarch64。i686 是 i386 指令集的超集，对 deb 包来说它仍然属于 32 位体系，所以你要找的是文件名里带i386的那个包，而不是被 i686 这几个字符带偏。更直接的判断方式是问 dpkg 自己认什么架构，以及内核是多少位。
# 看内核与硬件架构，重点关注最后一段的 i686 / x86_64 / aarch64 uname -a # 问包管理器：本机 dpkg 认可的架构是什么，输出 i386 或 amd64 dpkg --print-architecture # 看内核位数，32 或 64 getconf LONG_BIT # 如果手上已经有 deb 包，直接读包元数据里的 Architecture 字段 dpkg-deb -I Nessus-7.2.0-debian6_i386.deb | grep Architecture第一条命令是给你自己看的，后三条是给系统看的。dpkg --print-architecture输出i386就只认 32 位包；getconf LONG_BIT返回 32 说明用户态是 32 位。第四条最有价值——包下载完先dpkg-deb -I读一眼，比装完了报错再回头找原因省事得多。安装包命名一般是Nessus-<版本>-<发行版标识>_<架构>.deb的结构，发行版标识那段对应的是 debian 系，Kali 属于这一支，所以 debian6 之后的包都能装。
提示：虚拟机快照是很便宜的后悔药。装包之前打一个快照，后面激活失败、插件编译崩了，回滚比查日志快。
2.2 dpkg 安装与目录结构：/opt/nessus 下都有什么
包确认无误就装。Nessus 不改动系统自带的库，全部文件落在/opt/nessus下，这一点对实验环境很友好——想彻底卸载，停服务、删目录、清掉 init 脚本就干净了。
# 安装，-i 表示 install；包不在当前目录就写全路径 sudo dpkg -i /usr/local/nessus/Nessus-7.2.0-debian6_i386.deb # 装完先确认目录结构，别急着启动 ls -l /opt/nessus/ ls -l /opt/nessus/sbin/ # 看服务脚本是否就位 ls -l /etc/init.d/nessusddpkg -i之后如果输出里出现dependency problems，说明缺依赖，用sudo apt-get -f install补齐再重来一次。装完的目录里，/opt/nessus/sbin/下有两个关键程序：nessusd是扫描服务本体，nessuscli是命令行管理工具，后面创建用户、注册激活码、导插件全靠它。/opt/nessus/var/nessus/是数据目录，许可证、用户库、日志都在这儿；/opt/nessus/lib/nessus/plugins/是插件落地的地方，.nasl脚本解压后堆在这里。记住这两个路径，出问题时第一个要看的就是它们。
安装完成后服务默认不会自己起来，也不会监听端口。这一步容易让人误判成「装失败了」，实际上只是没启动。
2.3 首次启动前的两件事：adduser 与 8834 端口
第一次用 Nessus 的人常犯的错是先启动服务、再打开浏览器，然后在登录页卡住——因为还没有任何用户。正确的顺序是先建用户，再起服务，最后访问。创建用户的命令是交互式的，会连着问你五件事。
# 创建 Nessus 登录用户，全程交互 sudo /opt/nessus/sbin/nessuscli adduser交互流程依次是：输入登录名；输入密码并确认；询问该用户是否为系统管理员（选是，否则后面没法上传插件、改全局设置）；询问是否给这个用户设置主机规则（直接回车表示不限制，实验环境没必要设）；最后确认是否授予系统管理员权限。规则那一项值得多说一句：它是一段 Nessus 自己的规则语法，可以限定这个账号只能扫某几个网段，生产环境里给外包人员开临时账号时会用到，实验里留空就行。
用户建好，启动服务并确认监听状态。
# 启动扫描服务 sudo /etc/init.d/nessusd start # 确认 8834 端口在监听；没有 ss 命令就用 netstat -lntp ss -lntp | grep 8834 # 看服务状态和最近日志，启动失败时第一现场在这里 sudo /etc/init.d/nessusd status sudo tail -n 50 /opt/nessus/var/nessus/logs/nessusd.messages8834是 Web 控制台的默认端口，走 HTTPS，证书是安装时自签的，浏览器第一次访问必然弹警告。实验讲义里那段「高级 → 我了解风险 → 确认例外」就是处理这个自签证书，不是配置错误，别在这上面浪费时间排查。如果ss看不到 8834，先看日志最后几十行，常见原因是端口被占、插件目录权限不对，或者上一次进程没退干净。
3. 激活与插件：离线环境下的注册码和插件包
Nessus 的激活分两层，很多人把它当成一件事，结果卡在半路：第一层是注册码校验，决定你的授权等级和可扫描 IP 数量；第二层是插件集，决定你手上到底有多少条检测规则。两层都过了，扫描才有意义。实验环境通常没有外网，所以第二层必须靠离线包补，这也是最容易出问题的地方。
3.1 fetch --register 到底做了什么
注册码从官方站点申请，家庭版有可扫描 IP 数量的上限，实验里扫一台靶机绰绰有余。拿到码之后用nessuscli fetch --register提交。
# 提交注册码，命令会尝试联网校验并拉取插件 sudo /opt/nessus/sbin/nessuscli fetch --register xxxx-xxxx-xxxx-xxxx-xxxx # 校验当前授权状态，能看到授权类型和到期时间 sudo /opt/nessus/sbin/nessuscli fetch --check这条命令做两件事：把注册码提交上去换取插件订阅资格，以及在本地写入许可证信息。联网正常时它会顺带把插件拉下来并开始编译；没有外网时，命令会在联网阶段报错退出，但注册码本身已经成功写进本地许可证库了。这一点特别关键——很多人看到报错就以为激活失败，反复执行 register，把码反复提交，反而可能触发限制。判断标准不是命令有没有报错，而是fetch --check能不能读出有效的授权信息。只要能读出来，接下来走离线插件包这条路就行。
注意：
fetch --register报网络错误不等于激活失败。先用--check确认授权落盘，再决定要不要重试。
3.2 离线插件包的导入路径与校验
离线插件包是一个几十到上百 MB 的压缩包，里面是按家族组织的.nasl检测脚本。导入有两条路：Web 界面里走设置里的手动更新，上传压缩包；或者命令行直接喂给nessuscli update。实验讲义走的是界面那条，因为它对新手更直观，页面上有进度条。
界面路径是登录后进设置页，找到软件更新那一块，右上角切到手动更新模式，选择上传自己的插件归档，选中文件，等它解压编译。命令行等价操作如下：
# 先确认包完整：比对文件大小，压缩包损坏会在解压阶段才报错 ls -lh /usr/local/nessus/all-2.0.tar.gz # 命令行导入插件包，路径写绝对路径 sudo /opt/nessus/sbin/nessuscli update /usr/local/nessus/all-2.0.tar.gz # 导入并编译期间盯着日志，编译失败的原因都在这 sudo tail -f /opt/nessus/var/nessus/logs/nessusd.messagesnessuscli update的参数就是插件包路径，没有别的开关。执行后它会先解压，再逐条编译.nasl脚本，这个过程吃 CPU 也吃内存，老机器上跑十几分钟很正常。日志里会滚动输出编译进度，看到大批done之类的字样基本就是成了；如果中途出现大量失败条目，八成是包不完整或者磁盘空间不够。
插件编译完成后需要重启服务才会全部生效，重启前顺手确认一下插件目录里的文件数量。
# 统计插件目录下的 nasl 脚本数量，量级不对说明没解压全 ls /opt/nessus/lib/nessus/plugins/*.nasl | wc -l # 重启服务让新插件生效 sudo /etc/init.d/nessusd restart3.3 插件状态的确认与版本对齐
插件装完不等于能用，还要确认它被服务识别了。最直观的位置是 Web 界面的关于页面，那里会显示插件集版本号和插件总数；命令行侧可以看插件目录的文件时间戳，刚导入的那批文件修改时间应该都是当下。
这里有个隐性的坑：注册码对应的插件订阅是有时间范围的。如果你手上的注册码是很久以前申请的，而离线包是新的，两者可能对不上，表现为插件能编译但部分条目在扫描时不触发。判断办法是对比关于页面显示的插件集版本和离线包的文件名/日期，差距太大就换一个匹配的包。实验讲义里给的注册码和插件包是配套的，照抄流程不会遇到这个问题，但换成自己的码时要注意。
另一个常被忽略的点是磁盘空间。插件解压加编译的中间产物会占掉不少空间，/opt单独分区的机器上尤其容易撞墙。装之前df -h /opt看一眼，留出至少一倍插件包大小的余量比较稳。
4. 策略怎么建：从 Advanced Scan 到只开 MS10-054 的插件集
Nessus 的扫描逻辑是「策略 + 任务」两层：策略定义怎么扫、扫什么，任务定义扫谁、什么时候扫。同一个策略可以挂到多个任务上，所以策略配得细，后面复用起来才省事。这一章按讲义里的顺序走一遍，但每个参数都说明白为什么这么设——照着点是一回事，知道点了什么才有复现价值。
4.1 模板选型：Advanced Scan 和几个常见模板的差别
新建策略时会先让你选模板，选错模板后面很多参数根本找不到入口。几个常用模板的差异如下：
| 模板 | 适合场景 | 关键限制 |
|---|---|---|
| Basic Network Scan | 快速摸一遍资产，出个大概 | 端口范围和插件集基本固定，改不动 |
| Advanced Scan | 需要精细控制端口、插件、报告 | 参数多，配置成本高 |
| Credentialed Patch Audit | 有管理员凭据，专门查补丁缺失 | 强依赖凭据质量，无凭据时结果很差 |
| Web Application Tests | 扫 Web 应用层漏洞 | 面向 HTTP 服务，不适合系统层 |
实验里要做的是「只开某一批插件、端口全扫、报告尽量详细」，这三件事在 Basic 模板里都做不到，所以选 Advanced Scan。这不是因为它「高级」，而是因为它把端口范围、插件开关、报告详细度这几个开关都暴露出来了。选模板这个动作本质上是选一组默认参数，选完还能改，但默认值决定了你少改多少项。
策略建好后记得看一眼权限设置。默认是只有创建者能用，如果实验环境是多个人共用一个 Nessus，把它改成允许其他用户使用，否则别人登录进来在任务里选不到这个策略，会以为是 bug。
4.2 Port Scanning 与 Report 的参数取舍
端口扫描这一项，实验要求把范围设成 1-65535。全端口扫描的代价是时间长，一台机器可能多花十几分钟，收益是不会漏掉高位端口上的服务。内网小规模资产做基线核查时，我一般会全扫；如果是几十上百台的大网段，会先按常见端口快速摸一轮，再对重点机器补全端口。
DISCOVERY → Port Scanning → Port range: 1-65535 DISCOVERY → Port Scanning → Scan type: 按需选择，默认的 SYN 扫描够用 REPORT → Report Verbosity: Detailed（讲义要求尽量详细） ADVANCED → Performance → Max checks per host: 老靶机调低，避免打挂报告详细度这一项，Normal 只给结论，Detailed 会带上插件输出的原始信息和请求响应片段，排查误报时后者几乎是必需的。但详细度上去了，报告体积也跟着涨，扫大网段时下载报告会很慢，按需选。
性能那几项容易被忽略。Max checks per host控制对单台主机并发发起的检测数量，默认值对 Windows XP 这种老系统偏激进，并发一高，目标机的 SMB 服务可能直接无响应，扫描结果里就会出现一堆超时，看起来像「目标不可达」，实际是被自己打挂了。实验环境里把它调低到个位数更稳。
4.3 Credentials：带凭证扫描和纯远程扫描的差别
不带凭据的扫描是黑盒，只能从服务指纹、版本号、响应特征去推断漏洞；带上凭据就变成灰盒，可以直接读注册表、查补丁列表、比对文件版本，准确率差一个量级。实验里要求加 Windows 凭据，就是这个原因。
配置位置在策略的凭据分类下，选 Windows 类型，填用户名和密码。这里有两个前提：目标机必须开着 SMB 相关端口，账号必须有本地管理员权限。普通用户权限能查到的信息会少很多，补丁缺失这类结论基本出不来。
注意：凭据在 Nessus 里是加密存储的，但别拿域管理员账号做实验。给扫描器单独开一个专用账号，权限够用就行，这是行业里的常规做法。
凭据配错的表现很典型：扫描能跑完，结果里也有端口和服务信息，但一条补丁类漏洞都没有。这时候先别怀疑插件，去结果的认证信息里看登录是否成功——多数情况是账号密码错了、账号被锁定策略拦了，或者目标机禁用了相关的共享访问。
4.4 Plugins 过滤器：按 CVE 和公告编号定位插件
这是整个策略配置里最需要动手的一步。默认情况下策略会启用几千个插件，全开跑一遍时间长、噪音大。实验的做法是先全部禁用，再按公告编号把相关插件捞出来单独启用。
操作顺序是：进插件页签，点全部禁用，然后在过滤器里把匹配方式设为任意匹配，输入 CVE 编号或公告编号。MS10-054 这类公告通常对应多条 CVE，比如 SMB 服务里的几个池溢出问题，所以用公告号搜可能命中一组插件，用 CVE 搜更精准。筛选完点应用，列表会只剩下命中的条目。
此时这些插件的状态仍然是被禁用的，需要按插件家族批量打开：左侧选家族，右侧把命中的插件逐条点亮，或者整个家族全开。这一步在界面上比较费手，插件多的时候建议先按家族归类再操作，比一条条点快得多。全部打开后保存策略。
筛选逻辑里有几个细节值得记一下：过滤器同时支持按插件名、CVE、BID、公告编号匹配，混用的时候注意匹配模式是「任意」还是「全部」；改完筛选条件一定要点应用，不然列表不会刷新，很多人以为自己筛出来了，实际还是全量列表；保存前再扫一眼已启用插件的数量，个位数到几十条是合理范围，几千条说明禁用没生效。
策略存好之后，主界面上可以对它做导出和删除。导出功能在换机器复现时很好用——把策略导成文件，拿到另一台 Nessus 上导入，参数一个不差，比重配一遍靠谱。
新建任务时在用户自定义策略里选刚建好的那个，填目标 IP，启动。任务跑完再看结果，这才是完整闭环。
5. 避坑与排查：六个真实翻车的现场
前面的步骤按顺序走一般不会出问题，真正耗时间的是各种「看着像成功其实没成」的状态。下面这几条是这套实验里出现频率最高的，每条都按现象、原因、解决三步写，对着排查能省不少时间。
5.1 六条高频故障的现象、原因与解决
现象一：装完包，浏览器访问 8834 打不开，提示无法连接。原因是服务没启动，或者只监听了本地回环。nessusd安装后不会自动运行，必须先adduser再start。解决：ss -lntp | grep 8834确认监听，没有就启服务；如果监听在 127.0.0.1 而你从另一台机器访问，需要在配置里放开监听地址，或者直接在本机浏览器访问。
现象二：激活时报网络错误，以为注册码废了，反复重试。原因是没有外网，fetch --register在联网校验阶段失败，但注册码已经写入本地。解决：用fetch --check确认授权状态，能读出授权就走离线插件包，不要重复提交注册码。
现象三：插件包上传后进度条卡住，或者编译到一半报错。原因通常是磁盘空间不足、内存不够，或者包本身下载不完整。解决：先df -h /opt看余量，再比对包大小；空间够就换命令行方式重新导入，日志里能看到具体是哪一步失败。老虚拟机上把内存调大一点，编译会顺畅很多。
现象四：扫描跑完，结果里全是信息级条目，一条高危都没有。原因有三个常见方向：插件根本没启用（禁用后忘了打开）、凭据认证失败导致补丁类检测全部跳过、端口范围没覆盖到目标服务。解决：回策略里确认已启用插件数量，去结果页看认证状态，再核对端口范围。三者按顺序查，基本能定位。
现象五：带凭据扫描仍然提示无法认证。原因是账号权限不足、目标机禁用了相关共享、或者密码策略要求首次登录改密码。解决：用同一个账号在目标机上手动验证能否访问管理共享，确认账号是本地管理员且密码没有过期标记。实验里的靶机账号是预先配好的，换环境时这一步最容易出问题。
现象六：扫描过程中靶机卡死或服务无响应。原因是并发检测数太高，老系统扛不住，SMB 服务被打到无响应。解决：把单主机并发检测数调低，把扫描类型换成更温和的方式，必要时对目标机做限速。这不是扫描器的 bug，是压力参数和目标承载能力不匹配。
5.2 一套从下往上的排查顺序
出问题时最忌讳东一榔头西一棒子。我习惯按网络、端口、服务、凭据、插件、策略这个顺序自下往上查，每一层确认通过再往上走，能避免在错误的层面上浪费时间。
# 第一层：网络可达 ping -c 4 172.16.1.103 # 第二层：关键端口是否开放 nc -zv 172.16.1.103 445 # 第三层：本机服务状态与日志 sudo /etc/init.d/nessusd status sudo tail -n 30 /opt/nessus/var/nessus/logs/nessusd.messages # 第四层：授权与插件是否就位 sudo /opt/nessus/sbin/nessuscli fetch --check ls /opt/nessus/lib/nessus/plugins/*.nasl | wc -lping通不代表端口通，nc -zv这一条经常能直接指出问题：SMB 端口不通，后面凭据配得再对也没用。服务状态和日志解决本机侧的问题，授权和插件数量解决「扫了但没结果」的问题。按这个顺序走一遍，多数故障在第二层或第三层就露头了，不用一路查到策略配置。
6. 结果怎么读：从红色条目到一张能派活的修复单
扫描结束后界面上会出来一堆彩色条目，颜色对应严重级别，红色是最高的那一档。点开红色条目，里面会写清楚受影响的主机、端口、服务、对应的公告编号，以及一段描述和解决方案。实验里命中的是 SMB 服务上的远程代码执行问题，描述大意是该主机的 SMB 服务存在多个缺陷，攻击者可以发送特制请求执行任意代码或造成拒绝服务，解决方案那一栏写的是厂商已发布补丁。
读报告的关键不是看颜色，而是把颜色翻译成动作。我一般按这张表过一遍：
| 级别 | 含义 | 处置动作 |
|---|---|---|
| Critical | 可直接远程利用，影响面大 | 当天确认，优先打补丁或封端口 |
| High | 利用条件稍多但风险仍高 | 本周内排期修复 |
| Medium | 需要特定条件才能触发 | 纳入常规补丁周期 |
| Low / Info | 信息泄露或配置建议 | 记录，随版本迭代处理 |
信息级条目别直接划过去。它们往往写着开放的端口、运行的服务版本、操作系统的推断结果，这些是下一轮排查的入口。实验里蓝色条目就属于这一类，点开会给出 IP、系统类型、扫描起止时间，用来核对资产台账很合适。
真正让人头疼的不是漏报，是误报。带凭据扫描能显著压低误报率，因为补丁是否真的缺失可以直接读出来，而不是从版本号猜。所以看到高危条目，先确认这次扫描是不是带了有效凭据——没带凭据的高危，先按「疑似」处理，人工复核之后再派活。
修复动作要和业务方对齐。封端口是最快的，但可能影响正常业务；打补丁最彻底，但需要窗口期。我的习惯是给每条高危都写清楚三件事：影响的主机和端口、可利用性和前置条件、两个可选方案及其代价。扫描器只负责出清单，把它变成能派下去的工单，是人的活。
从那以后我每次跑完扫描，都会先抽三条高危手工复核一遍再发报告——扫描器的结论是线索，不是判决书。希望帮到你。
本文还有配套的精品资源，点击获取
