网站漏洞扫描工具OpenVAS在运维中的定时任务

运维团队部署OpenVAS后最常踩的坑，不是安装失败，而是扫描器装完就扔在那吃灰。漏洞库不更新、扫描任务不规律、报告没人看，这三件事让一套本该发挥价值的安全系统变成了合规摆设。解决这个问题的核心手段就是定时任务，把OpenVAS的更新、扫描、报告导出全部自动化，让它在后台像巡检机器人一样规律工作。

OpenVAS的定时任务不是靠自身图形界面点点就能搞定的，Greenbone Security Assistant（GSA）网页后台虽然提供了任务调度入口，但真正稳定可靠的自动化方案必须落到命令行和系统级调度上。OpenVAS核心组件包括绿骨更新守护进程greenbone-feed-sync、扫描守护进程ospd-openvas、以及管理服务gvmd，这三者各自有独立的命令行工具，定时任务就是把这些工具按正确顺序和频率串起来。

先说清楚一个容易混淆的点：GSA里创建的“定时任务”本质上是gvmd管理的调度规则，依赖gvmd服务持续运行。如果gvmd进程挂了，这些任务就静默失败，不会有任何告警。生产环境里更稳妥的做法是绕过GSA，直接用系统crontab调用gvm-cli或ospd-openvas的API，这样即使Web前端崩了，扫描照样跑。

OpenVAS的检测能力完全取决于漏洞库的新鲜度。社区版漏洞库每天更新多次，企业版Greenbone Enterprise Feed更新频率更高。很多运维习惯把更新放在凌晨，这没问题，但要注意两个细节：第一，greenbone-feed-sync执行期间会占用大量内存和磁盘IO，如果同步过程中恰好有扫描任务在跑，两者争抢资源会导致扫描结果不完整；第二，同步完成后gvmd需要重新加载缓存，这个过程不是瞬间完成的。

推荐的更新策略是把feed同步和扫描任务错开至少一小时。比如凌晨2点执行feed同步，3点再启动扫描任务。具体crontab配置如下：

# 每天凌晨2点同步漏洞库
0 2 * * * /usr/local/bin/greenbone-feed-sync --type GVMD_DATA >> /var/log/gvm/feed-sync.log 2>&1
0 2 * * * /usr/local/bin/greenbone-feed-sync --type SCAP >> /var/log/gvm/feed-sync.log 2>&1
0 2 * * * /usr/local/bin/greenbone-feed-sync --type CERT >> /var/log/gvm/feed-sync.log 2>&1

同步完成后必须验证完整性。feed-sync命令返回码为0不代表数据完整，可能因为网络波动丢包导致部分NASL脚本损坏。建议在同步脚本后追加校验步骤，用gvmd --get-feeds命令检查各feed版本号和更新时间，与Greenbone官方发布页面做对比。如果版本号滞后超过24小时，触发告警通知运维介入。

OpenVAS扫描任务的核心调度逻辑要考虑三个维度：扫描目标分组、扫描强度分级、时间窗口规划。不要把几十个目标全部塞进一个任务，一旦某个目标无响应，整个任务会卡在主机发现阶段超时。应该按业务系统或网段把目标拆分，每个任务控制在20个IP以内。

扫描强度方面，OpenVAS默认配置模板有Discovery、Host Discovery、System Discovery、Full and fast、Full and very deep等多个级别。日常巡检用Full and fast就够了，它能覆盖大部分高危端口和常见漏洞，单台主机扫描时间通常在15到30分钟。Full and very deep会遍历所有65535个端口并对每个服务做深度指纹识别，单台主机可能跑两三个小时，只适合在变更窗口期对新上线的系统做全面体检。

用gvm-cli创建和管理定时扫描任务是目前最成熟的做法。先通过gvm-cli创建目标、任务、调度，然后把调度绑定到任务上。示例流程：

# 创建目标
gvm-cli --gmp-username admin --gmp-password your_password socket --xml "Web服务器组192.168.1.10-192.168.1.20"

# 创建任务
gvm-cli --gmp-username admin --gmp-password your_password socket --xml "每周巡检-Web服务器"

# 创建调度
gvm-cli --gmp-username admin --gmp-password your_password socket --xml "每周日凌晨3点37"

上述命令中的config id对应Full and fast配置模板，不同OpenVAS版本该ID可能不同，需要先用gvm-cli --get-configs查一下。调度创建后返回的schedule_id要绑定到任务上，这一步在GSA界面操作更方便，或者用modify_task的XML命令指定schedule_id。

扫描跑完了，报告躺在gvmd数据库里没人看，等于白扫。自动化导出报告并推送到相关责任人，才是定时任务闭环的关键一步。OpenVAS支持多种报告格式：PDF适合给管理层看，XML适合导入SIEM或自研平台做二次分析，CSV适合用Excel做漏洞跟踪表。

gvm-cli导出报告的命令行如下，可以根据任务名称和日期范围获取最新一次扫描的报告ID，然后指定格式导出：

# 获取最近一次扫描的报告ID
REPORT_ID=$(gvm-cli --gmp-username admin --gmp-password your_password socket --xml "" | xmllint --xpath 'string(//report/@id)')

# 导出PDF报告
gvm-cli --gmp-username admin --gmp-password your_password socket --xml "" > /tmp/openvas_report_$(date +%Y%m%d).pdf

导出后的文件需要自动分发。如果公司用企业微信或钉钉，可以that可以调webhook机器人接口把PDF文件发送到指定群聊；如果用邮件，可以用mailx或sendmail把报告作为附件发送。这里给一个邮件发送的脚本片段：

echo "OpenVAS每周扫描报告，扫描时间：$(date +%Y-%m-%d)" | mailx -s "漏洞扫描周报" -a /tmp/openvas_report_$(date +%Y%m%d).pdf security@example.com

更进阶的做法是把XML报告解析后提取高危漏洞列表，只把摘要推送到即时通讯群，降低信息噪音。用Python解析XML报告，筛选威胁级别大于等于7.0的漏洞，格式化后通过webhook发送，这样相关人一眼就能看到需要紧急处理的问题，而不是收到一份几十页的PDF然后搁置。

OpenVAS扫描是资源密集型操作，同时发起大量探测包会打满网络带宽，目标主机也可能因为并发连接数过高触发防护告警甚至被临时封禁。定时任务调度时必须控制并发扫描数，gvmd默认同时最多执行多少个扫描任务可以在配置文件里调整，建议不超过CPU核心数的2倍。

另一个容易被忽略的点是扫描器本机的磁盘空间。每次扫描都会在/var/lib/gvm/reports下生成报告数据，长期不清理会撑爆磁盘。定时任务里必须加一条清理策略，保留最近30天的报告，超过的自动删除。可以用find命令配合cron实现：

# 每周日清理30天前的扫描报告文件
0 4 * * 7 find /var/lib/gvm/reports -type f -mtime +30 -delete

如果扫描目标包含大量Web应用，OpenVAS的爬虫模块会抓取页面链接做注入测试，这个过程可能触发应用层的限流或WAF拦截。建议对生产环境做扫描时，把扫描速度从默认的“中等”调低到“慢速”，减少对业务的影响。这个参数在创建任务时可以指定，也可以在任务模板里预设。

定时任务配好了不代表它会一直正常运行。cron的静默失败特性让很多问题潜伏很久才被发现。必须对定时任务本身做健康监控，至少监控三个指标：feed同步是否成功、扫描任务是否按时完成、报告是否成功生成并推送。

实现方式不复杂，在每个关键脚本末尾加一个状态写入逻辑，把执行结果和时间戳写到指定文件，然后用另一套监控系统（比如Zabix、Prometheus的textfile collector或者最简单的脚本检测）读取这些状态文件。如果发现feed同步超过24小时未成功，或者最近一次扫描任务状态为失败，立即触发告警。

gvmd本身也有健康检查接口，可以通过Unix socket发送XML命令查询服务状态。把这个检查也加入定时任务，每小时执行一次，发现gvmd无响应时尝试重启服务并告警。

当资产规模超过几百台时，单台OpenVAS扫描器的吞吐量就不够用了。Greenbone支持主从架构，一个gvmd管理多个ospd-openvas扫描节点。这种架构下定时任务的设计要更复杂：主节点负责调度和汇总，从节点只负责执行扫描。

多节点环境下，定时任务要错开各从节点的扫描窗口，避免所有节点同时满载导致网络拥塞。可以在主节点用脚本轮询各从节点的负载状态，动态分配扫描任务书务。不过这已经超出基础定时任务的范畴，属于编排调度的领域了。对于大多数中小企业，单节点配合合理的定时策略完全够用。

定时任务出问题时的第一反应是看日志。OpenVAS的日志分散在多个位置：feed同步日志通常在/var/log/gvm/目录下，gvmd日志在系统日志或/var/log/gvm/gvmd.log，扫描任务日志需要通过gvm-cli查询。排查问题时按这个顺序来：先确认cron是否触发（查看/var/log/cron），再确认feed同步是否正常，然后检查gvmd服务状态，最后看具体任务的执行日志。

一个高频故障是feed同步因为网络问题中途失败，导致漏洞库不完整。如果同步脚本没有校验机制，这个状态可能持续数周。解决办法是在同步脚本里加校验和重试逻辑，同步失败时等待5分钟重试，最多重试3次，全部失败再告警。

另一个常见问题是扫描任务超时。OpenVAS默认任务超时时间是0（无限制），但实际环境中如果目标主机防火墙拦截了探测包，扫描会卡在端口扫描阶段。建议给每个任务设置合理的超时时间，比如单台主机30分钟，整个任务2小时，超时自动终止并标记为部分完成。这个参数在创建任务时通过XML标签指定。

把这些定时任务、监控告警、日志轮转、报告分发全部串起来，OpenVAS就从一台需要人工操作的扫描工具，变成了一套持续运转的漏洞发现体系。安全运维的日常不再是“记得跑一下扫描”，而是收到告警后去处理真正需要关注的高危漏洞。这套方案不依赖任何商业软件，完全基于OpenVAS社区版就能实现，成本只有投入的配置时间和一台服务器的资源。