从零编写Nessus自定义扫描策略：插件集配置与性能调优实战

1. 为什么默认策略总是“差点意思”

先聊个日常。干安全评估这几年，Nessus基本是随身工具了。但说实话，大部分人的用法就是装完开默认策略直接扫，出个报告就算交差。这个流程应付常规巡检没问题，真到实战项目里就捉襟见肘了。

举几个例子：默认策略全端口扫描跑一个C段可能要好几个小时，紧急漏洞排查时根本等不起；内网资产里有ESXi、网络打印机、数据库中间件，默认策略的探测方式和插件选择不见得匹配，容易漏报；合规基线检查需要按特定标准核查配置项，默认模板里根本没这功能。这些场景下，自定义扫描策略模板就成了绕不开的选项。

我在实际项目里吃了不少亏之后，才正儿八经把Nessus的策略模板体系摸清楚。这篇文章就把我从零编写自定义策略的完整路径、参数配置逻辑、插件筛选思路和排坑经验都整理出来。内容主要基于Nessus 10.x版本，界面和功能在10.9.4上验证过，老版本可能菜单名略有差异，但核心逻辑完全通用。

适合人群：刚接触Nessus但发现默认策略不够用的人、需要做内网深度评估的安全工程师、运维团队想建立可复用扫描模板的。这篇文章不是教你怎么点按钮出报告，而是讲清楚每个配置项背后的逻辑，让你能独立设计出贴合自身环境的策略模板。

2. 策略模板设计前的核心思路

2.1 先搞清楚策略、模板、插件集三者的关系

Nessus里有个容易混淆的概念：Policy、Template和Plugin Set。Policy是整套扫描配置的集合，包含目标范围、端口扫描方式、插件启用状态、性能参数等；Template是Policy的载体，Nessus启动扫描时选择一个模板，其实就是在加载一套Policy配置；Plugin Set则是插件知识库里的一个子集，你选了哪些插件族、哪些具体插件，决定了扫描器实际执行哪些检测。

关系可以这样理解：模板是外壳，策略是内核，插件集是内核里真正干活的组件。你在新建策略时做的所有设置，最终都围绕这三层展开。

设计策略前先回答几个问题：这次扫描的目标是主机漏洞还是Web应用？重点在基线合规还是入侵痕迹排查？目标环境是隔离网段还是核心业务区？允许的扫描时长和带宽消耗上限是多少？这些问题直接决定后续所有配置方向。

还有一点值得注意：策略模板不是写得越多越好。我见过有人建了二三十套策略，结果团队成员根本搞不清哪套该用哪套，最后全部退回默认模板。我的习惯是建四到五套核心策略，覆盖常见的应急扫描、Web评估、合规基线、全量深度和快速探测，每个策略的差异点写清楚用途，这样团队协作时才能达成一致。

2.2 策略配置的三大板块逻辑

打开Nessus的Policy配置界面，你会发现配置项分了好几块。核心三大板块分别是：发现配置（Discovery）、评估配置（Assessment）、报告配置（Report）。

Discovery板块管的是“怎么找到目标、识别目标是什么”，包括主机发现方式、端口探测策略、服务识别深度。这里的配置直接决定扫描的“广度”和“速度”。Assessment板块管的是“找到目标后做什么检测”，包括启用的插件族、凭据扫描设置、Web爬虫策略、合规基线选择。这里的配置决定检测的“深度”。Report板块管的是“结果怎么呈现”，包括报告语言、漏洞分级标准、输出格式细节。

还有底部的Performance和Advanced选项，属于“扫描行为控制”，管理并发数、超时时间、重试次数、丢包容忍度等。很多新手只看前三大板块，性能参数完全不动，导致高并发下扫描器自身被拖垮，或者目标主机网络被扫崩。这块后面实操部分会详细拆解。

3. 从零创建自定义策略的完整流程

3.1 新建策略模板的正确入口

Nessus 10.x的Web界面里，进入Policies页面，点击New Policy按钮，会弹出模板选择框。这里列了很多预设模板：Basic Network Scan、Advanced Scan、Web Application Tests、Credentialed Patch Audit、Host Discovery等等。

需要注意：直接选Basic Network Scan之类的基础模板，你虽然能改一些配置，但很多高级选项被限制了。要完全自定义，应该选Advanced Scan作为起点。我在项目里基本都这么做，因为Advanced Scan开放了全部配置维度，其他模板都是它的子集变体，从Advanced Scan改写效率最高。

选定Advanced Scan后进入策略编辑页，左侧是配置分组，右侧是具体参数。整个编辑流程可以按发现配置、评估配置、性能参数、报告输出四条线推进。

3.2 发现阶段配置的关键参数

发现阶段在漏洞检测之前。这里常见误解是“端口扫得越全越好”，实际上端口扫描方式的选择对结果影响极大。

Nessus支持多种端口扫描方式：TCP SYN、TCP Connect、TCP FIN、UDP、ACK等。默认的SYN扫描速度远快于Connect扫描，但对于部分老旧的网络设备或者防火墙策略严格的服务器，SYN包会被直接丢弃，反而Connect扫描更可靠。我在扫描混合内网时，端口探测常用“SYN + 部分UDP TOP50”的组合：TCP用SYN快速摸清开放端口，UDP只扫常见服务端口，比如DNS的53、SNMP的161、NTP的123，这样效率高又不会太慢。

端口范围配置也很有学问。全端口（1-65535）扫描慢且容易触发目标防护系统报警，应急场景完全不适合。常规巡检我用默认列表（常用端口约1000多个），重点目标或合规项目才开全端口。在自定义策略模板里，端口范围应该做成可变参数，扫描前根据目标重要性和时间窗口临时调整，而不是死写固定值。

服务识别（Service Detection）建议开启。Nessus识别出具体服务版本后，才能精准匹配各版本对应的漏洞插件。如果关闭服务识别，很多检测逻辑只能靠猜，误报率会明显上升。代价是扫描时间增加，但收益远超成本。

3.3 主机存活探测的取舍

主机发现方式中，Nessus提供ARP、ICMP Ping、TCP Ping、UDP Ping等多种组合方式。跨网段扫描时ARP不好使，ICMP被禁的环境中TCP Ping就派上用场。

我常用的组合是：ARP + ICMP + TCP 80/443/22等常见端口。这个组合对绝大多数内网环境都有效，如果目标网络禁ping且封禁了常见端口，说明极其注重隐蔽性，这种网络环境通常也不会让你随便扫。根据我的经验，主机发现策略不用贪多求全，把常见的三到四种方式搭配好足够应对，开太多反而增加扫描时长，对结果没实质帮助。

还有个细节：主机发现和端口扫描的节奏可以分开控制。第一轮先快速定位存活主机，第二轮只对存活主机做全量检测。这个“分阶段扫描”思路在大型内网中能大幅减少无效流量和扫描时间。

3.4 插件集配置是策略的灵魂

设置完发现方式，接下来就是评估配置，这部分的核心是插件集。

Nessus插件按家族（Family）分类，包括CentOS Local Security Checks、Windows、Databases、DNS、Firewalls、Web Servers、Misc等几十个大类。策略模板里你可以按需启用或禁用整个家族，也可以精确到单个插件级别。

在建自定义策略时，我的思路不是“全选然后等结果”，而是“按场景裁剪插件集”。做Web应用评估时，Web Servers、Web Application Tests这些家族必须开，但网络设备专属插件可以关掉。做数据库基线核查时，Databases家族和相关插件全部开启，桌面软件类插件直接排除。这样既加快扫描速度，也减少无关插件引发的噪声。

判断哪些插件该启用，还有一个更精细的维度——按照CVE时间线。Nessus插件库每天都会更新，新漏洞CVE对应的插件会逐步加入。你在做应急排查时，可以只启用最近30天新增的插件，快速定位新曝出的高危项。具体做法是在插件搜索框里用“plugin_modification_date >= 某个日期”的条件过滤，然后保存为一个自定义插件组，下次直接用。

3.5 进阶配置：凭据扫描与合规基线

默认的远程扫描是从外部视角探测漏洞，很多安全问题只有拿到系统权限后做本地核查才能发现。Nessus支持凭据扫描（Credential Scan），给你提供SSH账号、Windows远程账号、数据库账号后，扫描器登录系统内部执行本地检查项。

这个能力极大提升检测深度，尤其对补丁缺失、配置弱点这类问题，比纯黑盒扫描准确几个量级。凭据信息在策略模板里可以预先配置好，也可以留在扫描时输入。我的建议是模板里留占位变量，实际扫描时输入具体凭据，避免模板文件泄露账号信息。

合规审计（Compliance）部分是另一个重头。Nessus内置了多种合规基准，包括CIS Benchmark、等保基础要求、行业合规配置项等。自定义策略中可以挂载这些审计文件，扫描结束后直接输出“合规判定”结果，对于做等级保护、CIS基线核查的项目特别好用。

需要注意：合规审计扫描依赖凭据采集系统配置项。在策略模板中同时启用Credential Scan和Compliance Check，两者配合才能输出有效的合规结果。只开合规检查不给凭据，结果基本是空的。

4. 三种典型场景的策略模板解剖

4.1 应急排查场景模板

应急场景的核心需求是“快”：快速定位存活主机、快速判断是否存在指定漏洞、避免过度扫描导致目标机压力过大。

我的应急模板参数：主机发现开启ARP、ICMP、TCP 80/443/3389/22组合探测；端口范围暂时设为常用高危端口列表（涵盖Web服务、远程管理、数据库默认端口等约300个）；插件集只启用最近15天新增且Critical级别以上插件，同时手动加入当前已被公开利用的CVE对应插件。

性能参数上，最大并行主机数调到中低档，相当于每台目标只分配较少的并发扫描线程。目标机器如果是生产业务服务器，过高的并发容易触发OS层面的资源竞争，极端情况下会把服务扫挂。

这模板的核心逻辑是基于“时间窗口”筛选插件，而不是全量检测。我已在多个真实应急事件中验证过，整段C段从开始扫描到产出结果能控制在十分钟内，而默认策略同等条件下至少要四十分钟以上。

4.2 Web应用安全评估模板

Web场景要单独走一套逻辑。Nessus的Web应用检测能力虽然不如专业DAST工具，但做常规Web安全巡检足够用。

Web评估模板要重点关注评估设置里的Web Crawling配置。爬虫深度设置影响可被检测的URL数量，深度太高会爬出大量动态URL导致扫描时间失控，太低会漏掉深层页面。我通常设置爬虫深度为3到5层，同时启用“跟随动态URL中的链接”选项，但要限制外部域名的请求数量，避免扫描器被带偏去请求外部站点。

另外必须在插件集里启用“Web Application Tests”全家族，同时开启“Generic SQL Injection”和“XSS”两个专项检测插件组。Nessus的Web漏洞检测插件有不少是基于行为探测的，关闭专项插件组后检测效果会大幅缩水。

还有一个容易被忽略的点：Web扫描时必须开启“模拟浏览器用户代理”选项。很多WAF和登录页面会通过User-Agent识别爬虫，直接拒绝非浏览器UA的请求。Nessus提供“浏览器UA”预设选项，开启后检测结果接近真实攻击者视角。

Web模板我是作为专项检测工具使用的，不会拿它代替完整的渗透测试流程，但在安全开发上线测试和第三方系统巡检场景中，它可以提供一个稳定可复用的自动化评估基线。

4.3 合规基线核查模板

合规场景的重点在于“标准化输出”，即每次扫描结果都能按同样的标尺对照基线要求逐项判定。

策略配置上：开启Credential Scan（提供系统凭据），在合规设置中挂载对应的CIS Benchmark或其他合规审计文件，并将输出格式设置为带“Compliance Summary”的报告模板。插件集方面启用Local Security Checks族（这是本地核查的核心插件族），同时保留少量远程漏洞检测插件作为环境信息补充。

合规基线要明确基线版本。CIS Benchmark有不同系统版本和不同的基线版本号，同样一台Windows Server 2016，挂载的基准版本不同，判定结果可能有明显差异。我会在策略模板名称上直接标注基线版本，比如“Windows_CIS_v2.0.0_template”，避免用错版本导致后期结果争议。

这种模板适合构建团队内部的统一检测标准。我搭建这套机制后，新加入的安全人员只需按模板执行，得到的报告字段和格式保持一致，统计纵向趋势也方便很多。

5. 插件ID、插件组与自定义过滤规则

5.1 插件ID到底怎么用

Nessus每个检测项都对应一个唯一插件ID。掌握插件ID的查阅方法，等于拿到了策略灵活定制的钥匙。

查询插件有两种方式：插件搜索框输入ID精确查找；也可以用规则表达式过滤。比如要筛选所有Apache相关插件，输入“Apache”即可联查。如果我看中某个插件但在策略编辑界面不知道它在哪个插件族，直接在搜索框搜ID，选中后Nessus自动帮你定位到对应的族。

自定义插件组功能在建策略时很重要。你可以把多个插件ID组合成一个组，比如“等保三级关键项插件组”，把等级保护涉及的核心核查插件放在一个组里，策略模板只引用这个组而不是逐个开关。后续要调整检测范围，只需要维护插件组，模板保持不动。

5.2 过滤规则的正确打开方式

除了按ID，Nessus还支持用CVSS分数、插件类型、漏洞类型（远程/本地）、发现时间等维度做过滤。推荐优先熟悉“按CVSS过滤”的场景：全量扫描只保留CVSS 7.0以上的高危插件，输出报告噪声大幅减少。

过滤规则的边界也值得注意。有些漏洞很少单独触发高严重级别，但组合起来就是真实风险。所以纯按CVSS过滤可能错过低危漏洞的组合攻击链。我的折中方案是：日常巡检按CVSS 7.0以上过滤；月度深度扫描则禁用过滤条件做全量核查，靠报告模块的筛选能力做二次分析。

5.3 插件依赖问题

自定义插件集时还有一个隐藏问题：插件依赖。某些漏洞检测插件依赖前置检查项的结果，比如操作系统类型识别、端口服务确认、补丁包枚举结果等。你手动禁用了“Misc”或“Service Detection”相关插件，表面上看只是少了一些探测项，实际会导致大量依赖它的检测插件“有依赖未满足”而被跳过。

Nessus中可以通过查看插件的依赖链来确认。插件信息界面会显示Dependencies字段，列出所有依赖插件ID。建议不要随意禁用Service Detection、OS Identification这类的公共前置插件，它们是很多检测逻辑的地基。

我在一次内网扫描中就踩过类似的坑：为了压缩时间把“Misc”插件族整个关了，结果大量Web安全检测插件没执行，报告看起来“干净”得反常。当时排查原因花了整整半天。后来养成了习惯，插件选择是精心挑选结果，不是不要哪些全删掉。

6. 性能调优与参数计算

6.1 并行度参数计算逻辑

Nessus性能参数中有Max Simultaneous Hosts（最大并发主机数）、Max Checks Per Host（每主机最大并发插件数）、Max Simultaneous TCP Sessions（最大TCP会话数）三个关键值。三者之间不是独立项，而是乘积关系。

算一笔账：并发主机数设为20，每主机并发插件数设为5，TCP会话数上限设为50。那么满负载时扫描器同时发起的TCP连接数约等于20乘以5，等于100个潜在连接，而会话数上限50意味着实际最多只有50个TCP会话同时进行。这里的瓶颈是TCP会话数。所以在调整参数时不要只调某一项，要看三者共同作用下的实际瓶颈。

我的经验值：内网千兆带宽条件下，Max Simultaneous Hosts设为30，Max Checks Per Host设为4到6，Max Simultaneous TCP Sessions设为100到150，整体扫描效率和稳定性比较平衡。这套参数在C段规模（约250个存活主机）的全量检测中能在两小时内完成主要检测，峰值流量也不会把交换机端口打满。

6.2 扫描速度与准确度的平衡

扫描速度变快通常意味着发包频率更高，目标应用压力更大。压测实验来看，同样的内网网段，高并发参数的完成时间比低并发参数快三倍多，但如果目标包含老旧的Windows Server 2003、打印机等低配置设备，高并发模式会导致这些设备响应超时甚至宕机。

稳妥做法是分设备类型跑策略。服务器区用高并发模板，办公区和IoT设备区用低并发模板，并适当调大超时时间。低并发参数配置可以参考：最大并发主机数10，每主机并发插件数3，TCP会话数上限60。对大量老旧设备来说，这套参数能从瓶颈流量和超时重试两个维度降低风险。

6.3 超时与重试设置

Nessus支持设置连接超时、读超时、重试次数。默认超时值兼容性好，但在网络质量差的环境里重试次数不够会导致大量“端口状态未知、检测跳过”的结果。

跨网段远距离扫描时，我习惯把Connect Timeout从默认的5秒上调到10秒，Read Timeout保持默认，重试次数设为2次。网络丢包率超过5%的链路，这个调整能显著减少误报“不可达”。内网正常环境就不用动默认值，盲目调大超时只会拖慢整体进度。

重试次数也不是越多越好，一次扫描里同一个端口反复尝试三次以上，基本说明该端口实际不可用或防火墙拦截了探测，继续重试只是浪费时间。

7. 常见问题与排查技巧实录

7.1 为什么扫描结果大量“服务信息缺失”

一次用自定义策略扫描后，发现报告里主机虽然有开放端口，但“服务指纹”字段大面积空白，连带漏洞检测结果也很少。

排查过程发现：策略里端口扫描选了TCP FIN方式。这种扫描方式能判断端口开放状态，但不建立完整TCP握手，抓不到服务Banner信息。服务识别阶段的插件需要Banner数据来匹配指纹，自然大面积失效。

正确做法是服务识别依赖的端口扫描方式应选择SYN或Connect，而不是FIN。或者单独增加一轮服务识别扫描，专门抓Banner。

7.2 插件开太多把扫描拖到“天荒地老”

有次全量扫描开了所有插件族，结果跑了两天半还没完。问题在于没有理解插件规模和扫描时间的线性关系。Nessus全插件库在两万个检测项以上，全部启用后目标每开一个端口，扫描器就要逐个跑完对应检测项，耗时自然爆炸。

压缩方案是启用Top 20关键插件族（覆盖系统漏洞、Web漏洞、弱口令等主力检测项），关闭冗余的外围类族（如桌面软件、娱乐设备类），总检测项压缩到六七千，扫描时间降到原来的五分之一，关键漏洞检出量基本不受影响。

所以自定义策略一定要根据业务类型裁剪插件集。全插件扫描不是默认选项，而是有特定目的才会启用的深度模式。

7.3 凭据扫描一直提示认证失败

SSH凭据设置正确，但Nessus持续报“Authentication failure”。常见原因有三个：一是Nessus扫描器到目标主机的SSH端口被防火墙限制；二是目标系统SSH配置禁用了密码认证，只允许密钥登录；三是账号有跳转目录限制或Shell是nologin类型，导致SSH会话无法正常运行命令。

逐一排查时，先确认扫描器到目标22端口连通性，再检查目标系统sshd_config的PasswordAuthentication配置，如果确实是密钥认证环境，就需要给Nessus配置私钥文件路径。这个坑在加固过的Linux服务器上遇到不少次，多数情况不是账号密码错，而是远程登录策略本身拒绝了密码认证。

7.4 扫描器自身崩溃或无响应

Nessus服务运行时若遭遇并发过高，Web界面会出现长时间转圈、扫描任务无响应。生产环境的扫描器建议单独部署一台独立的虚拟机或者低配服务器，分配至少4核8GB内存，磁盘预留200GB以上给插件库和扫描结果缓存。不要把Nessus装在正在运行的业务服务器上，插件库的持续更新和扫描任务的临时文件都会干扰业务运行。

7.5 策略模板无法保存或报错

自定义策略保存时偶尔提示“Policy validation failed”。大多是指定端口范围格式不正确，或者端口和服务识别参数之间出现冲突。我习惯在修改策略后立即保存并做一次小范围试扫（一两台主机），确认没有报错后再用于正式范围。这个习惯帮我避免过几次在大型扫描前才发现模板问题的情况。

8. 小技巧：用变量模板团队复用策略

最后分享一个实际带团队时验证过的小技巧：在自定义策略里善用Targets和Credential变量。把目标IP段在扫描任务创建时动态输入，不在模板里写死，这样同一套策略可以反复用于不同项目。凭据变量同理，模板里不保存明文账号，每次扫描前输入或者调用本地的凭据库。

团队内部还可以建立策略模板的命名规范，比如格式统一为“使用场景_基线版本_创建日期”，配上简短说明写清适用范围。这样成员之间查看模板列表时很快能理解差异，不用一个个打开看配置才知道哪套是哪套。策略多了之后这个习惯的省事效果很明显，我建了十几套模板后靠命名规范也能快速定位目标模板。

折腾Nessus自定义策略这些年，我最大的感受是：工具本身的能力只占一半，另一半在操作者对自己环境和目标的判断。策略模板不是越复杂越好，配置项也不一定都要动，贴合场景、输出有效结果才是核心价值。写出来的模板建议结合自身项目持续复盘和迭代，每个季度花点时间重新审视当前的模板是否够用，随着资产变化和检测需求演进，模板肯定也需要调整。

希望这篇文章能帮你在自定义策略这条路上少走点弯路。如果你在实际配置中遇到了本文没覆盖的奇怪问题，欢迎在评论区留言，我看到了会尽量回复。