企业官网建设流程全解析

简介：这份面向渗透测试初学者与安全运维人员的PDF教程，聚焦Nessus在操作系统漏洞扫描中的实际应用，围绕Kali Linux实验环境展开，帮助读者理解漏洞发现、策略配置与结果研判的基本流程。资源包仅含1个PDF文件，大小约13.34MB，篇幅完整，便于离线查阅和按章节学习。教程结合Windows XP靶机场景，覆盖Nessus安装注册、用户与权限设置、插件更新、Web控制台使用及扫描任务配置等内容，并提示授权测试、定期更新漏洞库和分析修复计划等注意事项。已有927人学习，适合课程实验、入门培训或渗透测试工具选型时作参考，也可用于梳理Nessus从部署到扫描评估的知识框架。

1. 一个装着 Nessus 却扫不出东西的下午

实验室有台 Windows XP 靶机，Nessus 装好、策略建好、点了 Launch，等二十分钟，报告里只有几条蓝色 Info，最该出现的 SMB 远程代码执行一条都没有。翻回去看：插件库没导全，Disable All 之后没逐个启用，凭据扫描的账号也填错了。渗透测试里漏洞扫描翻车，十次有八次不是扫描器不行，是配置没到位。

这份资源就是一份 Nessus 从装到出报告的完整实验记录：Kali 上选版本、Home 版注册激活、离线插件导入、Advanced Scan 策略怎么调、按 CVE 编号精确定位插件、最后读报告。适合刚做漏洞扫描的安服同学、要给老系统做基线核查的运维，以及在课程实验里被 Nessus 卡住的人。

2. 装之前先确认三件事：架构、包版本与 Home 版权限

很多人拿到Nessus-7.2.0-debian6_i386.deb就直接dpkg -i，装完发现/opt/nessus/sbin是空的，或者包管理器直接报依赖缺失。问题几乎都出在同一处：包架构和系统架构对不上。这一步花两分钟确认，能省掉后面半小时排查。

2.1 i686 和 i386 的关系：先把架构对清楚

uname -a输出的机器硬件名就是你该下哪种包的第一依据。教程里写「显示为 i686 实际是 i386 的一个子集」，这句话是对的，但只说了一半。i686 是 Intel 32 位处理器的第六代指令集代号，Debian 系把 32 位 x86 架构统一叫i386，所以你看到i686就该下 32 位包；看到x86_64就必须下amd64包，这两者不通用。

# 一次性看清内核、架构、系统位数 uname -a uname -m dpkg --print-architecture getconf LONG_BIT

四行命令的输出要能对上：uname -m给的是内核视角的硬件名（i686 / x86_64），dpkg --print-architecture给的是包管理器视角的架构名（i386 / amd64），getconf LONG_BIT给 32 或 64。三个值互相印证，就不会出现「以为自己是 32 位，结果下了 32 位包装在 64 位系统上」这种低级错误。

提示：uname -m在 32 位内核跑 64 位 CPU 的机器上会返回 i686，这种老机器只能用 32 位包，不要硬装 amd64。

2.2 dpkg -i 前后各做一步，别让安装静默失败

确认好架构，就把包丢到一个固定目录再装。我习惯放在/usr/local/nessus，一是路径好记，二是后面激活码、离线插件包都能放同一处，实验环境里方便统一清理。

# 1. 建目录并把安装包挪进去 sudo mkdir -p /usr/local/nessus sudo cp Nessus-7.2.0-debian6_i386.deb /usr/local/nessus/ cd /usr/local/nessus # 2. 安装，注意看最后几行输出 sudo dpkg -i Nessus-7.2.0-debian6_i386.deb # 3. 验证安装结果：这两个目录有东西才算成功 ls -l /opt/nessus/sbin/ ls -l /opt/nessus/var/nessus/

dpkg -i执行完不会自动拉起服务，它做完的事只有三件：解包到/opt/nessus、注册/etc/init.d/nessusd、创建一个nessusd系统用户。所以装完必须去/opt/nessus/sbin/看有没有nessuscli和nessusd两个可执行文件，没有就是没装上。

如果dpkg -i报依赖未满足，先别急着乱装包：

# 让 apt 自动补齐 dpkg 记账里缺的依赖 sudo apt-get install -f

这条命令在多数情况下能解决 libc、libssl 一类的基础依赖。但要注意一个边界：Nessus 7.x 时代的 deb 包依赖libssl1.0.0，而现在主流发行版早就换成了libssl1.1甚至libssl3，包名对不上，apt-get -f也补不回来。这种时候的正确做法不是硬凑依赖，而是换成与当前系统版本匹配的安装包，或者干脆在 32 位的老镜像里做这套实验。血泪经验是：在老包上折腾依赖，花的时间足够重装一遍环境。

2.3 Home 版的边界：16 个 IP 到底怎么算

注册 Nessus Home 免费版时页面会写明最多扫描 16 个 IP。这个数字在实战里有两个容易误解的地方：一是它按「被扫描目标的独立 IP」计数，同一台机器重复扫一百次只算一个；二是它跟端口数量毫无关系，你把扫描范围开到 1-65535 也不会额外消耗配额。

对实验环境来说 Home 版完全够用。真要说限制，是它不适合拿来做大网段资产普查：一个 /24 就是 254 个地址，配额瞬间打满。我一般的做法是先用别的轻量手段把存活主机摸出来，只把真正需要出报告的那十几台塞进 Nessus。

3. 激活与插件：从 adduser 到 all-2.0.tar.gz 落地

装完只是把程序摆上去了，Nessus 真正能不能用，取决于三件事：有没有建登录账号、激活码有没有注册成功、插件库有没有导进去。这三步任意一步断了，Web 界面要么登不进去，要么登进去扫不出东西。

3.1 adduser 的五个交互项，每一项在决定什么

Nessus 的用户体系和 Linux 系统账号是两套东西，Web 界面登录用的是nessuscli adduser建出来的账号。教程里让你「用 root/toor 登录」，指的其实是建用户时把登录名填成 root、密码填成 toor，不是拿系统 root 去登。

sudo /opt/nessus/sbin/nessuscli adduser

执行后会依次问你五件事，每一项的含义和取舍如下：

1. Login：Nessus 内的登录名，和 Linux 用户名无关，实验里填 root 只是为了跟教程对齐。
2. Login password / 再输一次：这个密码就是后面 Web 登录密码，长度建议 8 位以上，太短会被拒绝。
3. 是否设为 system administrator：选 y。只有管理员才能上传插件包、改全局设置，普通用户只能跑扫描。
4. User rules：用户可扫描范围的限制规则，直接回车表示不限制。实验环境不需要设，生产环境建议按网段限定。
5. 最后确认：再问一次是否赋予管理员权限，选 y 完成。

命令执行完不会有明显的成功提示，只回到 shell。这时用同样的方式再跑一次adduser如果提示「user already exists」，说明建成功了。

3.2 fetch --register：联网和断网是两条路

拿到激活码后，用fetch --register把它写进本地配置：

# 激活码形如 xxxx-xxxx-xxxx-xxxx-xxxx，五位一组 sudo /opt/nessus/sbin/nessuscli fetch --register 1234-ABCD-5678-EFGH-9012

这一步的结果分两种，必须分清：

• 有外网：命令会顺带把插件 feed 拉下来，输出里能看到下载进度，几分钟后插件就是最新的，直接跳 3.4 启动服务。
• 无外网：命令后半段会报下载失败，但激活码本身已经写入本地。

这是整个流程里最容易被误判的地方。失败提示看着像全盘崩了，实际上激活是成功的，缺的只是插件。判断依据是下面这个文件是否存在且内容非空：

# 插件集标识文件，有这个文件说明 feed 已经落地过 ls -l /opt/nessus/var/nessus/plugin_feed_info.inc cat /opt/nessus/var/nessus/plugin_feed_info.inc

文件里会有PLUGIN_SET = "xxxxxxxx"和PLUGIN_FEED = "Regular Feed"两行。外网环境拉取成功后这里会写上新值；断网环境这个文件可能压根不存在，那就得手工导入插件包。

3.3 离线插件 all-2.0.tar.gz 的两条导入路径

插件包的导入有命令行和 Web 两条路，命令行适合批量部署，Web 适合单机操作。

命令行方式：

# 先确认服务处于停止状态，避免导入过程中被占用 /etc/init.d/nessusd stop # 导入本地插件包，路径按实际存放位置改 sudo /opt/nessus/sbin/nessuscli update --file /usr/local/nessus/all-2.0.tar.gz # 导入完成后重新看标识文件，PLUGIN_SET 应该变成新值 cat /opt/nessus/var/nessus/plugin_feed_info.inc

update --file的过程就是把 tar.gz 解压、校验、编译进插件库，包越大耗时越久，all 包通常要几分钟，中途别 Ctrl+C。

Web 方式则是在服务启动并登录之后：Settings → Software Update → 右上角 Manual Software Update → 选Upload your own plugin archive→ 选择all-2.0.tar.gz→ 等进度条走完。这条路的好处是有可视化进度，坏处是必须先能登进 Web，而登 Web 又要求服务先起来。所以我的顺序一般是：先命令行导入插件，再启动服务，最后 Web 上确认版本号。

3.4 启动服务并确认监听

# 老系统用 init 脚本，新系统用 systemctl，两条都试一下 sudo /etc/init.d/nessusd start sudo systemctl start nessusd # 看端口有没有起来，8834 是 Web 管理端口 ss -lntp | grep 8834

第一次启动会比较慢，因为 Nessus 要生成自签证书、初始化插件索引，通常要等一到两分钟。这段时间里浏览器访问https://127.0.0.1:8834会直接连接失败，属于正常现象，别当成服务没起来。真正的排障入口是日志：

# 服务端主日志，启动失败、插件编译报错都在这里 tail -n 100 /opt/nessus/var/nessus/logs/nessusd.messages

日志里如果出现Generating plugins一类字样，说明还在初始化，等着就行；出现bind: Address already in use则是端口被占，需要换端口或者杀掉占用进程。

访问时浏览器会拦自签证书，点 Advanced → I Understand the Risks → Confirm Security Exception 加例外即可。登录框里填的是 3.1 建的那个 Nessus 账号，不是 Linux 账号，这一点填错的话会一直提示认证失败。

4. 策略与扫描任务：Advanced Scan 里真正要改的那几项

Nessus 的扫描逻辑是三层结构：先有策略（Policy），策略决定扫什么、怎么扫；再有扫描任务（Scan），任务把策略和一个目标列表绑起来；最后执行任务出报告。策略没配对，任务跑得再勤也是白跑。

4.1 Discovery 里改三处，剩下的保持默认

新建策略时选 Advanced Scan，进入后左侧有一排配置页。Discovery 这一页决定 Nessus 怎么找到目标上的东西，默认值偏保守，全端口扫描必须手工放开。

端口范围填1-65535是最直接的改动。有人会担心全端口扫描太慢，实际在局域网靶机上通常也就几分钟，真正的瓶颈在老机器的响应速度，不在扫描器。如果靶机是 Windows XP 这种老系统，Performance 里的并发数不要拉满，否则容易把目标打到假死，报告里会出现一堆超时。

4.2 凭证扫描：填了账号之后差别在哪

Credentials 页是很多人跳过的地方。不填凭证，Nessus 只能从外部看端口和服务响应，判断逻辑是「这个版本号有已知漏洞」；填了凭证，它就能登录目标读注册表、读补丁列表、读已安装软件，直接判断「这个补丁到底打没打」，误报率差一个数量级。

Windows 目标的填法：

Credentials → Windows → Password Username: administrator Password: <目标机管理员密码> Domain: 留空（工作组环境）或填域名的短名

三个字段里最容易错的是 Domain。工作组环境留空即可，填了反而会走域认证流程导致失败。用户名建议用本地管理员，别用普通用户，否则读不到 HKLM 下的补丁信息。

带凭证扫描对目标有个隐含要求：SMB 服务得是通的，防火墙不能拦 445，XP 上还要确认「简单文件共享」相关的设置没有把远程管理挡掉。这些条件不满足时，Nessus 会在报告里给出凭据失败提示，而不是直接报错退出，很容易被忽略。

4.3 插件过滤：用 MS 公告号或 CVE 精确定位

实验目标是验证某一个特定漏洞，没必要跑全量插件。Plugins 页的操作顺序是固定的：

1. 点Disable All，把所有插件先关掉。
2. 在 Filter 区域选择过滤字段，Match 选Any。
3. 在值框里填漏洞标识。以 MS10-054 为例，可以填微软公告号MS10-054，也可以填对应的 CVE 编号CVE-2010-2550。
4. 点Apply等筛选结果出来。
5. 结果列表里状态为 DISABLED 的条目，逐个点成 ENABLED。
6. 点SAVE保存策略。

这里有个顺序陷阱：必须在 Disable All 之后再做过滤和启用，如果先启用再 Disable All，前面启用的会被一起清掉。另外，Filter 一次只能匹配一个字段，想同时匹配多个 CVE 就在值框后面点加号追加，不要指望一个框里用逗号分隔能生效。

保存之后回到 Policies 列表能看到策略名，此时这个策略还只是「存在」，没有跟任何目标绑定。

4.4 建任务、跑扫描、看状态

任务创建在 Scans 页：New Scan → User Defined → 选刚建好的策略 → 填目标 IP（实验里是靶机地址）→ Save → Launch。启动后任务状态会经历 Running → Completed，中途可以在任务详情里看到已完成的检查项数量。

扫描结束后报告按严重级别分色：红色 Critical、橙色 High、黄色 Medium、蓝色 Info。蓝色不代表没问题，只代表「发现了信息但不构成漏洞」，比如开放的端口、识别出的操作系统类型，这些恰恰是复现漏洞时最有用的线索。真正要盯的是红橙两色，点进去能看到插件名、端口、CVE 编号和修复建议。

5. 避坑：五条把我卡住的排查记录

5.1 扫完只有蓝色 Info，一条漏洞都没有

现象：任务显示 Completed，报告里全是 Info 级别，一个 Critical 都没有。

原因：九成是插件没启用。Disable All 之后如果只做了过滤没做启用，或者启用了但没点 SAVE，策略实际生效的插件列表是空的；剩下一种是插件库本身没导进去，plugin_feed_info.inc不存在，Nessus 只能跑最基础的探测。

解决：回到 Plugins 页看筛选结果的 ENABLED 数量，为 0 就重来一遍；再看plugin_feed_info.inc有没有内容，没有就按 3.3 重新导入all-2.0.tar.gz，导完重启服务。

5.2 浏览器打不开 8834，curl 也连不上

现象：服务命令执行了没报错，但https://127.0.0.1:8834一直转圈或拒绝连接。

原因：三种可能。一是首次启动还在生成证书和编译插件，这个阶段端口确实不监听；二是上次异常退出留下锁，进程起不来；三是 8834 被别的进程占了。

解决：先等两分钟再试；不行就tail -f看nessusd.messages，出现Address already in use就用ss -lntp | grep 8834找占用进程；再不行检查/opt/nessus/var/nessus/下有没有残留的 pid 文件，清掉后重启。

5.3 激活码明明没输错，fetch 一直报失败

现象：fetch --register返回错误，提示无法连接或激活无效。

原因：断网环境下插件下载必然失败，这属于预期行为，不是激活失败；另一种是真无效，常见于系统时间偏差太大导致证书校验不过，或者激活码已经被别的机器占用。

解决：先date看一眼时间，偏差超过几分钟就同步一下再重试；确认是断网环境的话，忽略下载失败的提示，直接走 3.3 的离线插件导入，激活状态不会因为下载失败而回滚。

5.4 带凭证扫描一直提示登录失败

现象：报告里明确写了凭据认证失败，目标系统信息一行没有。

原因：账号密码错、Domain 字段多填了、目标机 SMB 服务没开、防火墙拦了 445，四选一。XP 靶机上还多一种：Administrator 账号被改过名。

解决：先用同一组账号密码在渗透机上跑smbclient -L //<目标IP> -U administrator验证能否列举共享，能通说明网络和账号没问题，问题在 Nessus 的 Domain 或策略；不能通就先查目标机的服务状态和防火墙规则。

5.5 新系统上装老 deb 包，依赖怎么都补不齐

现象：dpkg -i报一串未满足的依赖，apt-get install -f跑完还是装不上。

原因：Nessus 7.x 的 deb 包依赖libssl1.0.0这类早已被淘汰的库名，新系统里只有libssl1.1/libssl3，包名对不上，apt 没有可补的候选。

解决：别在这条路上耗。要么换成与当前系统版本匹配的 Nessus 安装包，要么把这套实验放到 32 位的老镜像里做。强行软链库文件的方式看起来能装上，实际运行时会因为 ABI 差异在插件编译阶段崩掉，属于典型的后悔药。

6. 报告落地：从一条红色 Critical 到可交付的整改单

扫描出漏洞只是中间产物，真正要交出去的是能被人看懂、能安排修复的东西。我习惯在 Nessus 报告页把每一台目标的红橙条目逐条抄进一张整改台账，字段固定成下面这几列，谁拿到都能直接派活：

抄完之后不要直接发出去，先做一次交叉验证。Nessus 的端口识别偶尔会因为指纹匹配出错，用另一个工具对同一目标复核一遍最稳妥：

# 对 Nessus 报出的可疑端口做一次独立核验，-Pn 表示不依赖 ping 存活判断 nmap -sS -p 139,445 -Pn 172.16.1.103 # 想确认 SMB 具体版本和签名状态，可以用脚本模式 nmap -p 445 --script smb-os-discovery,smb-security-mode 172.16.1.103

第一条命令看端口开没开，和 Nessus 的结果对上就说明端口层面没误报；第二条能拿到 SMB 的系统和签名信息，正好用来印证 MS10-054 这类 SMB 漏洞的适用性。两边结论一致再往台账里写，不一致就把两个结果都留档，交给复扫时重点看。

还有一个容易被忽略的点：报告里的 Solution 段落是英文的，直接转给业务方经常没人看得懂。我的做法是在台账里加一列中文处置意见，比如「安装对应补丁包，无法安装则临时封禁 445 端口并限制内网访问范围」，这样运维拿到就知道先做什么。高危端口封禁和补丁安装两条路要同时写，因为老系统上装补丁往往要停机窗口，先封端口能立刻降风险。

从那以后我每次跑完 Nessus，都会强制走一遍「抄字段 → 独立工具复核 → 写中文处置意见」这三步，哪怕只扫出一台机器也不例外。少了这一步，报告就只是一堆截图；多这一步，它才是能推动修复的东西。希望帮到你。

本文还有配套的精品资源，点击获取