2. Nessus架构与核心组件

理解Nessus的架构，关键不是记住六个组件的名字，而是看清它们之间的数据流向与控制关系：谁发起任务、谁决定扫什么、谁真正发包、谁保存证据、谁把结果变成可读的报告。Nessus采用典型的“控制面与数据面分离”设计——用户界面和API属于控制面，负责下发指令与读取结果；扫描引擎与插件库属于数据面，负责实际探测；策略模板是控制面与数据面之间的“翻译层”，把人的意图转成引擎可执行的参数；结果数据库则是贯穿全程的持久化中枢。

六个组件的职责边界

扫描引擎（Scanner）是执行主体。它接收一个已实例化的策略，按插件清单逐项发起网络探测，处理超时、重试与并发，并把原始响应交给插件做判定。Nessus支持本地引擎与远程Scanner（Nessus Manager场景下可挂多个Scanner），引擎本身不存储长期结果，只负责“跑”和“回传”。

插件库（Plugin Feed）是知识底座。每个插件是一个NASL脚本，包含元数据（Plugin ID、家族、严重级别、CVE/CNVD引用）和检测逻辑。插件库通过Feed更新，更新后引擎才能识别新漏洞。插件不是“全量执行”，而是由策略筛选出子集——这正是策略模板存在的意义。

策略模板（Policy Template）是意图的载体。它定义扫描范围（端口、协议）、插件家族开关、凭据（用于本地检查）、性能参数（并发主机数、超时）以及高级选项（如是否启用安全模式）。模板可复用、可继承，是团队标准化扫描的抓手。

结果数据库保存扫描历史、主机资产、漏洞实例、插件输出与审计日志。它使“同一主机两次扫描的差异对比”成为可能，也是合规报告与趋势分析的数据源。

用户界面与API是交互入口。Web UI面向人工操作，REST API面向自动化集成（如CI/CD流水线、SOAR平台）。两者最终都调用同一套后端服务，因此API能完成UI能做的绝大多数事情。

协同工作机制：一次扫描的完整链路

下面这张图展示了从“创建任务”到“结果可查”的组件协作关系。注意箭头方向：控制指令自上而下，结果数据自下而上，插件库与策略模板在中间完成“意图到执行”的转换。

图中有一条容易被忽略的虚线：结果数据库并不是终点，它同时被API和UI回读。这意味着自动化流水线可以在扫描完成后直接拉取JSON格式的漏洞列表，而不需要人工导出。这也是Nessus能被集成进DevSecOps的关键。

策略模板如何影响扫描行为

策略模板不是“随便选一个就行”的配置。它直接决定引擎执行哪些插件、以什么强度执行。举一个教学示例：假设要对一台内网Linux服务器做基线核查，策略中启用“Unix Compliance”家族并配置SSH凭据，引擎就会先通过SSH登录，再执行本地检查插件；如果不配凭据，同一批插件只能做远程版本推断，结果会从“确认缺失补丁”降级为“疑似版本过低”。

性能参数同样关键。默认并发主机数在大型网段中可能导致引擎过载或目标设备响应超时。一个合理的示例配置是：max_hosts=30、max_checks=5、network_timeout=10秒。这些值不是固定答案，而是需要根据网络质量和目标承受能力调整的起点。

API协同的典型用法

API的价值在于把“扫描”变成可编排的步骤。一个常见的自动化链路是：CI流水线构建镜像后，调用API创建扫描任务 → 轮询任务状态 → 扫描完成后拉取结果 → 若存在高危漏洞则阻断发布。这里的关键接口包括/scans（创建）、/scans/{id}/status（状态）、/scans/{id}（结果）。API与UI共享同一套策略和插件库，因此不会出现“UI能扫、API扫不了”的情况。

组件之间的依赖关系与排障视角

当扫描结果异常时，可以按组件链路逐段排查：如果任务创建失败，问题通常在API/UI或调度服务；如果任务一直排队，检查Scanner是否在线；如果扫描完成但结果为空，检查策略是否误关了插件家族；如果结果缺少本地检查项，检查凭据是否有效；如果历史结果查不到，检查结果数据库的保留策略与磁盘空间。这种“按组件定位”的思路，比盲目重扫更高效。