2026 Greenbone 漏洞扫描平台服务器租用合规部署避雷手册

2026 Greenbone 漏洞扫描平台服务器租用合规部署避雷手册

企业安全部门采购服务器，最常见的算账方式是「装什么软件 → 软件要几核几 G」。这套算法放在 Web 服务上勉强够用，放在漏洞扫描平台上会直接翻车。原因是两类负载的形状不一样：Web 服务的请求全天均匀到来，资源水位可以从 QPS 反推；漏洞扫描平台的负载是一阵一阵的——任务不跑时机器几乎闲着，任务一启动，成百上千条探测连接在几分钟内同时打出去，连接跟踪表、临时端口、磁盘写入会一起冲到峰值。按「平均负载」配机器，机器会在任务启动后的第三分钟卡死，而且卡死的方式很隐蔽：不是 CPU 打满，是连接建不起来，扫描结果里出现大片「主机不可达」，最后交出一份充满假阴性（漏报）的报告。

Greenbone Vulnerability Management（GVM，社区里常按旧称叫 OpenVAS）是一套多进程协作的套件：管理守护进程 gvmd 负责任务调度、目标与凭据管理、报告生成；扫描器 openvas-scanner 及其 OSP 封装 ospd-openvas 负责实际探测；GSA/gsad 提供 Web 操作界面；PostgreSQL 存放结果库；Redis 承担任务队列、扫描过程知识库（KB）与缓存。组件名与拆分方式随版本演进，部署前请以当前版本的官方文档为准。这些组件挤在同一台物理机上时对资源的争抢方式，和「一个 Web 服务加一个数据库」完全不是一回事。

本文只谈防守侧：企业或机构对自己已授权的资产做合规漏洞排查时，承载这套扫描平台的服务器该怎么规划资源、怎么定流程，才能让任务跑得完、结果可信、报告留得住。全文不涉及任何攻击方法、利用步骤、绕过手段、未授权扫描与口令猜解流程。

扫描平台的负载画像：并发目标数才是第一参数

给扫描平台配机器，第一个要定的数字不是 CPU 核数，是并发目标数——一次任务里同时被探测的主机（或主机上的端口组）数量。理由是一条简单的乘法：一次任务在峰值时刻打开的 socket 数 ≈ 并发目标数 × 单目标并发探测数。假设一次扫 200 个目标、单目标并发探测数设为 10，峰值就是约 2000 条并发连接状态；把并发目标数提到 1000，峰值连接状态接近一万条。这个数字直接决定了内核连接跟踪表要开多大、临时端口够不够用、扫描进程的文件描述符上限设多少。CPU 在这条链路上排在很后面。

第二个要定的数字是单次扫描时长，它由「脚本条目数 × 目标数 ÷ 并发度」决定，而不是由 CPU 主频决定。Greenbone 的 NVT（Network Vulnerability Test，漏洞测试脚本）库是一个持续增长的集合，条目数量在十万量级（以实际同步后的统计为准）。一次「全量脚本 + 全端口」的任务，对单个目标要跑的探测次数非常可观；目标数一涨，任务时长就线性涨。工程上常见的做法是把任务拆成两类：日常跑「快速模板」（只跑高风险脚本、常用端口），季度或月度跑一次「全量模板」，两类任务的资源峰值差好几倍，机器要按全量那一次来配，按日常那一次来用。

CPU 什么时候才成为瓶颈？主要在三处：一是脚本执行本身（部分检测包含大量字符串处理与协议解析）；二是 TLS 握手密集的目标（握手是计算活）；三是报告生成阶段（尤其是导出大体量报表时的排序与渲染）。这三处的共同特征是「短时尖峰」，不是持续占用。所以扫描机的 CPU 选型思路和 Web 服务器相反：宁可核心数适中、单核性能不弱，也不要堆一堆低频核心然后指望并发。更实际的做法是先把内存和内核参数配够，跑一轮全量任务，看 CPU 到底吃不吃满，再决定要不要加核。

内存的主要去处有三个：Redis 常驻占用、每个扫描进程的运行时数据、PostgreSQL 的共享缓冲与工作内存。其中 Redis 是固定开销，扫描进程的占用随并发目标数线性增长，PostgreSQL 则会尽可能吃掉你给它的内存。这三者在任务峰值时会同时向上顶，所以扫描机的内存配置不能按「Web 服务经验值」给，要给到峰值时仍有余量。具体档位见文末表格，但那只是起步参考值，最终以压测为准。

磁盘的压力分两种形态，要分开看：feed 同步是突发的大批量小文件下载与解压，考验的是随机写与元数据性能；结果入库是持续的小块随机写，考验的是数据库所在卷的 IOPS。把这两件事放在同一块机械盘上，同步期间正在跑的任务会被拖慢，任务写入又会拖慢同步。SSD 在这台机器上不是「提升体验」，是「让任务能在窗口内跑完」的必要条件。容量规划另说，见下文结果库一节。

连接跟踪表与临时端口：扫描机最容易被忽略的两个内核瓶颈

扫描机出问题时，最先响警报的地方往往不是监控面板，而是内核日志。nf_conntrack 表被打满时，dmesg 里会出现「nf_conntrack: table full, dropping packet」一类的记录（不同内核版本措辞略有差异）。这个错误的危害不在于丢几个包，而在于它会伪装成业务事实：被丢包的探测没有回包，扫描器判定「主机不在线」或「端口无响应」，于是这些主机上的真实漏洞一个都没扫出来。一份看起来很干净、实际漏掉一整段网段的报告，比一份扫出两百个问题的报告危险得多。

所以要按并发目标数把这两个参数先算出来：net.netfilter.nf_conntrack_max 决定能跟踪多少条连接，net.netfilter.nf_conntrack_buckets 决定哈希桶数量（桶太少会让查找变慢，通常按 max 的四分之一左右配置，具体以内核版本与实测为准）。给出一个工程经验起算口径：把峰值并发连接数乘以 2 到 3 作为 conntrack_max，因为一次扫描任务里除了探测连接，还有 DNS 查询、feed 同步、数据库连接等旁路流量。这个倍数不是实测数据，是留余量的经验做法，需要在你的环境里用 conntrack -C 或读取 /proc/sys/net/netfilter/nf_conntrack_count 观察峰值后校正。

临时端口是第二个瓶颈。net.ipv4.ip_local_port_range 决定了本机发起连接时可复用的端口范围，默认区间大致是两万多个端口（具体以发行版默认值为准）。扫描任务产生大量短生命周期连接，这些连接关闭后进入 TIME_WAIT，端口在一段时间内不可复用。当扫描并发度很高时，端口耗尽会表现为连接建立失败——症状和上面 conntrack 满几乎一样，都表现为「目标无响应」，很容易误判。调整端口范围是常规操作，但更有效的做法是控制并发目标数：把并发度从 500 降到 250，任务时长翻倍，但成功率从七成提到接近满格，多数合规扫描场景里后者更划算，因为窗口是夜间八小时，时间并不紧张。

还有两个配套项别漏：文件描述符上限（ulimit -n 与 systemd 服务的 LimitNOFILE），扫描进程开的 socket 都算文件描述符，系统默认的 1024 会在几十个并发目标时就撞墙；以及 TIME_WAIT 相关的回收参数，这类参数在新内核上的行为与老资料里的描述有出入，不要照抄多年前的博客，改之前先在测试机上验证，改之后观察一轮完整任务。

需要提醒的是，这些调优只适用于扫描机。把同一套内核参数推给生产 Web 服务器或数据库服务器，可能带来完全不同的后果。扫描机的定位是单一用途，参数可以往「短时间内大量连接」这个方向倾斜，这也是它应该独立部署、而不是和别的业务共用一台机器的原因之一。

NVT 脚本库同步：feed 完整性直接决定漏报率

Greenbone 的检测能力来自 feed，主要包括 NVT（漏洞测试脚本）、SCAP（安全内容与配置基准）、CERT 等几类数据（分类与命名以官方文档为准）。脚本库不是装完就完事的一次性资源，它需要持续同步——新披露的漏洞对应的检测脚本会不断加入。判断一台扫描机是否合格，与其看它的 CPU 型号，不如看它能不能稳定、完整、按时地同步 feed。同步失败的机器，扫出来的「没问题」毫无意义。

同步过程的负载特征很特殊：短时间内拉取大量小文件，接着是解压与解析，最后 gvmd 要把新脚本全量载入并重建缓存。这个过程中 CPU、磁盘随机写、内存占用会依次冲高，Redis 的占用也会因为缓存重建而上涨。工程上的处理办法很直接：同步窗口和扫描窗口必须错开。把每日同步排在凌晨，扫描任务排在凌晨之后的低峰时段，两者之间留出缓冲；如果资产分布在多个时区或分支机构，宁可把同步单独排一个时段，也不要让它和大型任务重叠。同步期间跑全量任务，常见后果是任务超时、部分目标未完成，而报告里未必会显著提示。

同步的硬前提是网络可达。扫描机需要能够访问官方 feed 源，这涉及出口策略与白名单配置。很多机构把扫描机放在内网隔离区，结果 feed 同步长期失败却没人发现——因为扫描任务照样能跑，用的只是三个月前的脚本库。所以必须建立两条机制：一是同步结果的告警，同步失败或中断要能被运维收到；二是同步后的核对，记录每次同步后的脚本条目数与最后更新时间，形成趋势。条目数突然大幅下降、或最后更新时间超过预期天数，都是要立刻排查的信号。这个核对动作建议做成定时任务，输出到内部监控，不要依赖人工登录查看。

feed 对磁盘的占用也要算进去。脚本文件本身、解压后的中间产物、以及载入 Redis 后的内存占用，三者不是同一个数量级。规划磁盘时要给 feed 目录单独留出空间，并预留增长余量——脚本库是持续增长的，按当前占用乘 1.5 到 2 倍预留是常见的工程做法（预估，以实际增长趋势为准）。另外，feed 目录所在的文件系统如果 inode 耗尽，即使空间还剩很多，同步也会失败，小文件量大的场景下要留意 inode 使用率。

还有一点容易被忽略：版本升级。GVM 套件跨版本升级时可能涉及数据库结构变更，升级本身耗时长、且升级期间服务不可用。生产环境的做法是在升级前完成一次完整备份（结果库 + 配置 + feed 缓存），并在测试环境先走一遍升级流程。不要在生产机上直接跟新版本，也不要为了省事长期不升级——不升级的代价是脚本库与平台组件版本不匹配，检测能力打折。

结果库增长曲线与保留策略的磁盘规划

结果库的增长速度通常超出首次部署时的预估。每次全量扫描都会生成一批新的结果记录，这些记录不会因为「下一次扫描有同样结果」而被自动去重——它们是一条条独立的报告数据。所以磁盘消耗大致遵循「单次报告体量 × 扫描频次 × 保留月数」的乘法关系，而单次报告体量又与资产数、开放端口数、命中脚本数正相关。资产在增加、脚本库在增加，这个乘积是超线性增长的。

举例说明估算方法（以下为工程推算示例，非实测数据）：假设 500 个资产、每周一次快速扫描、每月一次全量扫描，单次快速扫描生成的报告体量按资产数与命中条目粗略估计，先跑满四周，用 du 或数据库表大小查询拿到实际增量，再乘以保留周数外推。这个「先测一周再外推」的办法比任何事前公式都准，因为在你的资产特征下，报告条目数可能与别的企业差出一个量级——一台开了几千个端口的中间件服务器，产生的条目数可能抵得上五十台普通办公终端。

磁盘规划上有几条硬经验。第一，PostgreSQL 数据目录要单独分区或单独卷，不要和 feed 目录、系统盘、日志混在一起；混在一起的后果是任何一个目录写满，整个平台都会异常。第二，任何分区都不要用到 90% 以上再扩容，数据库在接近满盘时的行为很难预测，而且扩容窗口往往要停服务。第三，保留策略要在部署前就定死并配成自动任务，靠人记得清理是不可靠的。

保留策略怎么定？一个实用口径是「滚动保留 + 节点留存」：滚动保留最近 N 次扫描结果（N 按合规要求与磁盘容量共同决定），同时对关键节点做永久留存——比如整改前基线扫描、整改后复扫、季度合规扫描、重大版本上线前后的扫描。这些节点报告是证明整改闭环的核心材料，删了就没法回溯。滚动保留之外的历史数据，可以导出为报告文件后从库中清理，导出的文件放到归档存储，成本比放在数据库里低得多。

数据库维护是配套动作。PostgreSQL 在高写入场景下需要定期的清理与索引维护，否则表膨胀会让查询越来越慢、磁盘占用只增不减。GVM 官方提供了数据库优化与清理相关的命令（具体命令名与参数以当前版本文档为准），建议配成周期性任务放在低峰执行，并保留执行日志。此外，结果库的备份要纳入整体备份体系：合规扫描的历史记录属于重要数据，备份周期与保留周期按机构的合规要求执行，备份介质与存放位置要满足保密要求——扫描结果本身就是一份资产弱点清单。

Redis 常驻内存与任务队列的可用性边界

GVM 的现代版本引入 Redis 后，很多运维仍按「缓存」的老印象对待它，这是部署事故的高发点。在这套架构里，Redis 不只缓存热点数据，它还承载扫描过程中的 KB（知识库）暂存、任务队列与中间结果。换句话说，Redis 里放着正在跑的任务的半成品数据。如果 Redis 内存不足触发淘汰、或者实例重启导致数据丢失，直接后果是正在执行的任务失败或结果不完整，而不是「下次重新拉一遍缓存」这么轻。

内存配额要提前划走，而不是让 Redis 和系统其他部分去抢。一个工程起算口径（预估，需按实际压测校正）：把 Redis 的 maxmemory 按「并发目标数 × 单目标结果条目平均占用 × 安全系数」估算，安全系数取 1.5 到 2，覆盖多个任务叠加执行的情况。更简单的验证办法是跑一轮最重的任务，观察 Redis 的内存峰值，然后在这个峰值上再加 50% 余量。观察指标要落到监控里，包括已用内存、key 总数、命中率与淘汰计数。

淘汰策略的选择有明确取舍。设为 noeviction 而又不给足内存，会在写入时直接报错，任务中断；设为 allkeys-lru 之类无条件淘汰的策略，则可能把正在使用的 KB 数据淘汰掉，同样导致任务异常。合理的做法是：先给足内存，让日常运行根本不触发淘汰；再配合一个有据可依的策略，并把「淘汰计数大于零」当作告警信号——正常运行状态下，这个计数应该长期保持为零。

持久化也要开。Redis 默认配置侧重性能，重启后数据全丢；对扫描平台来说，一次计划外的重启丢掉所有在途任务，意味着整个扫描窗口白费。开启 RDB 或 AOF（具体选择以数据量与恢复要求权衡，参考 Redis 官方文档）可以在重启后恢复状态。同时要盯一个现象：任务结束后 Redis 内存应明显回落。如果任务跑完内存不降、key 数持续累积，说明有数据未被正常清理，长期运行会把内存吃满，这种泄漏型问题要在试点阶段就发现，而不是等到生产环境三个月后半夜宕机。

安全配置上，Redis 实例不应监听公网地址，应当绑定内网地址并配置访问口令，与数据库、管理界面放在同一个受控网络区域。扫描平台本身是高权限系统，Redis 又是其中数据最集中的一环，暴露出去的风险等级与把整个平台的控制权限暴露出去是同一量级。

扫描窗口约定与扫描机落位：扫得准和不影响生产怎么取舍

扫描流量的形态和正常业务流量差异明显：短时间内发起大量连接、包含大量非常规请求与不完整报文、对同一目标的请求密度远超人类访问。这类流量经过 WAF、IPS、IDS 时，几乎必然被判定为异常并触发告警、限流甚至封禁。所以扫描前有三件事必须做完并且留痕：一是目标资产的书面授权；二是提前通知业务方与安全运营团队，让对方知道告警来源；三是在目标侧与中间安全设备上配置白名单，避免扫描机 IP 被自动封禁导致扫描中断。跳过第三步的后果是扫描跑到一半被封，后面的目标全部漏扫，而报告上未必看得出来。

扫描窗口的选择要同时满足两个条件：业务低峰、且不与其它重负载作业重叠。避开大促、月末结算、备份窗口、系统变更窗口。窗口长度要按「全量任务时长 × 1.5」来定，留出重跑一次的余地——任务失败需要重跑是常态，窗口卡得刚好等于必然超窗。跨时区的多分支机构环境，可以按区域拆分任务与窗口，让每个区域的扫描都落在该区域的低峰，而不是统一在总部时间执行。

带宽占用需要估算。一个粗略的口径（预估）：观测一次典型任务在扫描期间的出口流量曲线，取峰值带宽，再判断这条链路在那个时段还剩多少余量。扫描机的网卡与上游链路带宽通常不是瓶颈，真正的约束是共享这条链路的生产业务能否承受。如果扫描流量确实会影响生产，优先做法是限制并发目标数与每目标发包速率（平台提供相应的任务参数，以版本文档为准），用更长的任务时长换更小的瞬时冲击，而不是硬挤带宽。

落位问题是扫描机规划里最需要权衡的一环。放在靠近目标的网段，探测流量不经过额外的 NAT、ACL 与云安全组，扫描结果最贴近资产真实状态，漏报与误报都少；代价是扫描流量直接进入生产网络，冲击更直接，且扫描机本身的暴露面变大。放在远端跨公网扫描，流量隔离得好，但中间设备会过滤掉一部分探测，结果失真——尤其是被云安全组、边界 ACL 拦掉的端口，扫描器会判定为关闭，而你并不知道它是被拦还是真的没开。用一个比喻说清楚：跨公网扫描的结论只能用来做「外部可见性检查」，不能用来做「资产全量排查」。

折中方案是分布式架构：管理端集中部署在一处，负责任务调度、结果汇总与报告；从属扫描器（sensor）部署在各个目标网段就近扫描，只负责发探测流量并回传结果。这样既拿到了就近扫描的准确性，又把扫描流量限制在各自的网段内部，不会跨骨干网冲击。具体的实现方式（OSP 或 GMP 方式的从属扫描器）与版本支持情况，以官方文档为准。另外，扫描机自身要配置出口限制：只允许访问授权范围内的网段与 feed 同步源，其它出站流量默认拒绝。这既是控制误扫风险，也是防止扫描机被挪作它用。

报告留存、权限分离与操作审计的三条硬约束

等保测评、行业检查与企业内控，都会要求留存历史扫描报告与对应的整改记录。留存周期与留存内容按适用的合规要求确定，本文不给出具体级别结论，也不承诺任何测评结果。能确定的是留存材料的构成：原始扫描报告 + 整改记录 + 复扫验证报告，三者形成闭环。只有原始报告没有整改记录，检查时会被视为未闭环；只有整改记录没有复扫报告，无法证明问题真的修掉了。这三类材料要按「时间 + 资产范围」组织归档目录，保证事后能按任意一次检查要求快速调出。

导出格式与归档方式上，平台通常支持 PDF、CSV、XML 等若干导出格式（以当前版本支持的为准）。建议的归档口径是：对外提交与长期留存用 PDF（人可读、不易篡改），对内分析与自动化处理用结构化格式（便于统计趋势与比对两次扫描的差异）。归档存储与数据库不同，它要求的是低成本与长期可读性——报告文件不大，但数量多、保留周期长，用对象存储或归档存储比放在数据库卷上划算。归档目录同样要做备份，并限制访问权限。

权限分离是第二条硬约束。至少要把三类角色分开：扫描账号（平台用来登录目标主机做凭据检查的账号，权限应最小化，只给检测所需的只读或必要权限，不给管理员权限）、任务执行人（有权限创建任务、设定目标与窗口，但不应看到全部历史报告）、报告查看者（有权限查看报告用于整改，但不能改任务配置、不能导出全量结果）。三类角色混在一个账号下的隐患很直接：任何一次账号泄露，等于同时拿到了扫描凭据、目标清单和全部历史弱点数据。

扫描凭据的管理要单独拿出来说。凭据是这套系统里价值最高的数据——它是一把能登录大量主机的钥匙。凭据应当集中保管、加密存储、定期轮换，不要在任务配置里明文留下，也不要在截图、工单、聊天记录里出现。登录目标主机做检查的账号要可追溯到人，离职或转岗时同步回收。平台自身的账号体系也要清理：长期不用的任务、失效的目标清单、离职人员的账号，都要有定期核查机制。

操作审计是第三条。谁在什么时间创建了任务、修改了目标范围、导出了报告、删除了历史记录，这些动作都要有日志，且日志本身要防篡改并独立留存。审计日志与扫描报告是两类不同用途的数据：前者用来追责，后者用来整改，不要混在一个存储里一并清理。审计日志的保留周期通常要求不短于报告保留周期，具体按合规要求执行。

最后是暴露面控制。GSA 管理界面不应直接暴露在公网，应限制来源 IP、强制 HTTPS、管理员账号启用双因素认证。这套平台掌握着全网资产的弱点清单，一旦被非授权访问，危害等级高于一般的业务系统。把它当作核心资产来管，而不是当作「内部工具」随手放在某个子域名上。

授权边界与法律合规：仅对已授权资产开展扫描

这一节的内容必须写在部署方案的第一页，而不是附录里：仅对已授权资产开展扫描，严格遵守《网络安全法》《数据安全法》《个人信息保护法》等相关法律法规，以及行业主管部门的监管要求。任何超出授权范围的探测，无论出发点是自查还是排查，都不属于合规的资产排查行为。本文讨论的所有资源配置与流程设计，都建立在这个前提之上。

授权要落到书面。一份可用的授权文件至少包含：资产清单（IP 段、域名、主机名的明确列举，而不是模糊的「公司所有资产」）、扫描范围与扫描类型、允许的时间窗口、扫描机出口 IP、双方负责人与联系方式、有效期。扫描范围变化时——新增网段、新增域名、新增分支机构——要走变更流程重新授权，不能沿用旧文件。资产清单里混入了供应商托管、第三方运营或客户提供的系统时，要先确认授权链条是否覆盖，覆盖不到就先划出扫描范围。

云上资产要额外确认。在国内主流云厂商以及中国香港、中国澳门、中国台湾地区的服务商处租用的资源，扫描前需确认服务商对安全测试的授权要求与报备流程，部分平台要求提前提交测试申请。这不是形式主义：云平台的边界防护会把扫描流量判定为异常，未经报备的扫描可能导致服务受限，也会让扫描结果失真。

扫描结果的保密等级要等同于资产弱点清单。报告里包含未修复的漏洞、开放端口、版本信息与可登录凭据的线索，一旦外泄，等同于给了一份攻击路线图。因此报告的查看、导出、外发都要有审批与记录；对外提交给监管或第三方机构时，按需裁剪，只提供必要范围。

还有一种情况容易被忽略：扫描机自身也在资产清单里。它是一台高权限主机，存着凭据与弱点数据，理应被纳入自身的扫描与加固范围，且优先级要靠前。给别的系统扫漏洞的机器自己常年不打补丁，是很常见的疏漏。

哪些场景不该自建 Greenbone 扫描平台

自建的前提是有足够资产规模与持续的运维投入。以下几种情况，建议直接选择托管扫描服务或云厂商提供的漏洞扫描能力，把机器和 feed 维护的成本转嫁出去。

第一种是资产规模很小。只扫几十个 IP、几台服务器的场景，自建的投入产出比很差——feed 同步、版本升级、结果库维护、报告归档这些固定工作量不会因为你资产少而减少。一台扫描机的年度成本加上人力投入，通常高于同规模的托管服务费用（公开渠道差异较大，以实时报价为准；托管服务同样需询价）。这类场景更适合按次或按年购买托管扫描，把精力放在整改上。

第二种是没有专职安全运维。Greenbone 不是装上就能自动出结论的系统。feed 要盯同步、任务要定窗口、结果要做误报研判、报告要跟进整改，这些环节缺一个，平台就退化成「定期生成一堆没人看的 PDF」。如果团队里没有能长期负责这些事的人，自建的结果通常是三个月后没人登录。先解决人的问题，再解决机器的问题。

第三种是只需要周期性合规报告。如果目标就是在检查时提交一份扫描报告与整改记录，托管服务的报告模板与合规性往往更贴合要求，且不用维护平台。自建的优势在于资产规模大、扫描频次高、需要定制化检测与内部系统集成，没有这些需求时优势发挥不出来。

第四种是扫描频次要求极高且范围极大。每日多次全量扫描、覆盖上万资产，自建的资源成本会快速上升，且单次任务的资源峰值难以压平。这种规模下更合理的路径是先做小范围试点，把单次扫描的实际资源消耗测准，再逐步扩容或改为分布式从属扫描器架构。上来就按最大规模采购机器，是这类项目最常见的浪费。

还有一个判断口径值得写在前面：如果一个组织的主要矛盾是「扫出来的问题没人修」，那么买再大的机器也没用。这种情况下优先要解决的是整改流程与责任归属，扫描平台的规模可以往后放。反过来说，如果整改流程已经跑顺、资产在持续增加、需要把扫描结果接入内部的资产与工单系统，自建的收益才会真正体现。

Greenbone 扫描并发与结果库增长的容量口径

把全文的容量口径收敛成四个可直接拿去算的数字。第一个是并发目标数，它是所有资源参数的源头：峰值并发连接 ≈ 并发目标数 × 单目标并发探测数，由此推出 conntrack_max、临时端口需求与文件描述符上限。第二个是单次全量扫描时长，它决定扫描窗口的长度，估算口径是「脚本条目数 × 目标数 ÷ 并发度」，用一轮试点任务的实际耗时反推系数。第三个是结果库增量，按「单次报告体量 × 扫描频次 × 保留期数」外推，前提是先用一周实测拿到单次增量，不要事前拍脑袋。第四个是Redis 常驻内存峰值，在最重的任务上实测，再加 50% 余量作为 maxmemory。

这四个数字的共同点是：它们都不能靠事前公式精确算出，必须靠一轮真实任务来标定。所以合理的部署节奏是试点先行——先用一台中等配置的机器，跑三轮覆盖不同资产类型的任务（办公终端、中间件服务器、网络设备各一轮），把四个数字测出来，再扩容或调整。直接按最大值采购，要么浪费，要么在错误的方向上加资源。

下面这张表给出起步档位的工程参考值，用于做预算与方案初稿。表中数字为工程经验值，非实测数据，部署后必须用自己的任务压测验证并校正。

表格之外的几项资源也要一并进方案。磁盘类型必须是 SSD，feed 同步的小文件随机写与结果入库的持续随机写，机械盘扛不住；feed 目录与数据库目录分卷；Redis 持久化要开；管理界面与 Redis、数据库放在受控内网区域，不暴露公网。价格方面，不同机房与配置档位的差异较大，服务器租用与裸金属的具体费用需询价，公开渠道差异较大，以实时报价为准，本文不给出具体金额。

一万网络深耕 19 年（成立于 2007 年），提供服务器租用、裸金属、云主机与 GPU 定制等基础设施服务。扫描平台这类负载形态特殊的业务，建议先按上表档位做一轮试点压测，把四个数字测准后再定最终配置，具体报价与配置方案可到官网 https://www.idc10000.net/ 咨询，以签约时最新报价与合同为准。

数据来源与核对方式：Greenbone 漏洞扫描平台配置口径

组件与架构口径：GVM 的组件构成（gvmd 管理守护进程、openvas-scanner 与 ospd-openvas 扫描器、GSA/gsad Web 界面、PostgreSQL 结果库、Redis 队列与缓存）、feed 数据分类（NVT、SCAP、CERT）均来自 Greenbone 官方文档与社区文档。文中出现的命令名、配置项与支持的从属扫描器接入方式，均以当前部署版本的官方文档为准，跨版本可能存在差异，部署前请核对版本说明。

内核参数口径：net.netfilter.nf_conntrack_max、net.netfilter.nf_conntrack_buckets、net.ipv4.ip_local_port_range、ulimit -n / systemd LimitNOFILE 等参数的作用与取值来自 Linux 内核与发行版文档。文中给出的倍数关系（conntrack_max 按峰值并发连接的 2–3 倍预留、哈希桶按 max 的四分之一配置）为工程经验值，非实测数据，需结合内核版本与实际任务验证。TIME_WAIT 相关参数在不同内核版本上行为存在差异，不建议直接沿用历史资料中的配置。

容量估算口径（文中均标注「预估」）：并发连接数换算、单次扫描时长估算、结果库增量外推、Redis 内存峰值与安全系数、feed 目录按 1.5–2 倍预留、扫描窗口按 1.5 倍时长留余量，以及文末表格中四个档位的内存、conntrack、结果库年增长数值，均为基于行业通行工程经验的推算，不是任何特定环境的实测结果。这些数据只用于方案初稿与预算参考，实际配置必须以部署后一轮完整任务的实测数据校正，校正命令包括但不限于 conntrack -C、/proc/sys/net/netfilter/nf_conntrack_count、du、数据库表大小查询、Redis 内存与 key 数监控。

合规口径：文中关于授权范围、书面授权文件要素、凭据管理、权限分离、操作审计、报告留存的表述，为通用的安全工程管理实践。留存周期、留存内容、测评要求等具体条款，须以适用的法律法规与行业监管要求为准，本文不承诺任何等保级别或测评结论。所有扫描行为仅针对已授权资产开展，遵守《网络安全法》《数据安全法》《个人信息保护法》等相关法律法规。

价格口径：本文不给出任何具体金额。服务器租用、裸金属、云主机、GPU 定制的具体配置与报价，不同渠道差异较大，需询价，以实时报价为准；最终以一万网络官网 https://www.idc10000.net/ 页面信息与签约时最新报价、合同为准。品牌口径：深耕 19 年（成立于 2007 年）。地域表述：中国香港、中国澳门、中国台湾。