Kali Linux 2024.4 上部署 GVM (OpenVAS) 完整指南与避坑实践
1. 项目概述
最近在给团队搭建一个内网安全评估环境,手头正好有一台刚装好的Kali Linux 2024.4。作为渗透测试和漏洞管理的标配,GVM(Greenbone Vulnerability Management,也就是大家更熟悉的OpenVAS)自然是绕不开的核心工具。但说实话,每次在新系统上部署GVM,都像是一次“开盲盒”——官方源、依赖冲突、数据库版本、初始化失败,各种坑层出不穷。网上的教程要么是几年前的旧版本,要么步骤跳跃太大,对新手极不友好。这次我决定把从零开始,在Kali 2024最新版上完整安装、配置GVM,并成功启动扫描的整个过程,连同踩过的每一个坑和对应的填坑方法,都详细记录下来。这份指南的目标很明确:让你能跟着步骤一步步走,避开所有常见的陷阱,最终得到一个稳定、可用的GVM环境,无论是用于学习、演练还是内部安全评估,都能直接上手。
2. 核心需求与方案选型解析
2.1 为什么在Kali 2024上安装GVM依然是个“技术活”?
你可能觉得,Kali作为安全领域的“瑞士军刀”,预装了海量工具,装个GVM还不是apt install一句话的事?现实恰恰相反。Kali的滚动更新机制和追求“最新”的特性,与GVM这套相对庞大、依赖复杂的系统之间,存在着微妙的版本博弈。GVM的核心组件,如gvmd(管理器)、gvmd(扫描器)和openvas-scanner,对PostgreSQL数据库、Redis以及特定的库文件版本有严格的要求。而Kali的默认源可能提供的是较新的、但未经GVM充分测试的依赖版本,这就导致了安装后无法启动、服务崩溃、数据库连接失败等一系列问题。因此,我们的核心需求不仅仅是“安装”,而是“安装并成功配置一个能稳定运行的GVM服务”。
2.2 方案对比:一键脚本 vs 手动编译 vs 官方源安装
面对GVM的安装,通常有三种主流思路,各有优劣:
使用社区一键安装脚本:网上能找到一些
gvm-install.sh之类的脚本。优点是省心,理论上一条命令搞定。缺点也明显:脚本可能过时,无法适配Kali 2024的最新库;脚本执行过程不透明,一旦出错,排查难度极大;脚本通常会修改系统全局配置,可能带来潜在冲突。对于追求可控性和学习目的来说,不推荐。从源码手动编译安装:这是最灵活、最能适配特定系统环境的方法,可以精确控制每个组件的版本。但过程极其繁琐,需要手动解决数十个依赖,编译耗时漫长(动辄数小时),且极易在编译过程中因依赖问题失败。除非有极特殊的定制化需求,否则在Kali上不推荐。
通过Kali官方/Greenbone社区源安装:这是本文推荐的方法。Kali官方仓库和Greenbone社区都维护了针对Debian/Kali的预编译包。通过配置正确的软件源,我们可以用
apt命令来安装,兼顾了便捷性和稳定性。我们的核心策略就是:优先使用Kali官方整合的gvm元包,当遇到版本冲突时,则引入Greenbone社区源来获取更匹配的组件版本。这个方案既能利用包管理器的依赖解决能力,又通过源控制规避了版本陷阱。
2.3 环境准备与关键决策点
在开始之前,有几个关键决策点需要明确,这直接决定了后续步骤的走向:
- 全新系统还是已有环境?本文假设在一个新安装的Kali Linux 2024.4虚拟机上操作。如果你的系统已经安装过旧版GVM或进行过复杂配置,强烈建议先备份重要数据,然后考虑使用快照恢复或全新安装,避免残留配置导致问题。
- 资源分配:GVM运行起来比较吃资源。建议虚拟机至少分配4核CPU、8GB内存、80GB磁盘空间。初始化漏洞数据(NVTs)需要大量磁盘IO和网络下载,空间不足是导致失败的常见原因。
- 网络环境:整个安装过程需要从外网下载数百MB甚至上GB的数据(系统更新、软件包、NVTs)。务必保证网络通畅,且能访问
http.kali.org、packages.greenbone.net等源地址。如果身处特殊网络环境,可能需要配置HTTP/HTTPS代理。
3. 系统准备与依赖环境搭建
3.1 初始系统更新与清理
第一步不是直接安装GVM,而是确保你的Kali系统是最新且干净的。打开终端,依次执行以下命令:
sudo apt update sudo apt full-upgrade -y sudo apt autoremove -y sudo apt autoclean这里解释一下为什么用full-upgrade而不仅仅是upgrade:full-upgrade会处理因新版本依赖关系而需要安装或移除的包,更适合跨版本的系统升级,能更彻底地更新所有组件。autoremove和autoclean则清理无用的依赖包和旧的软件包缓存,释放磁盘空间。
注意:
full-upgrade可能会重启某些系统服务,最好在操作前保存好所有工作。整个更新过程取决于网速,可能需要十几分钟到半小时。
3.2 解决潜在的PostgreSQL版本冲突
这是GVM安装中最经典的“坑”。GVM从某个版本开始,强制要求PostgreSQL的版本至少为13。而Kali 2024.4默认安装的PostgreSQL版本可能是15或16。虽然版本更高,但GVM的某些脚本或配置可能仍固执地寻找版本13的套接字或数据目录,导致服务启动失败。
我们的策略不是降级PostgreSQL,而是确保GVM组件能与现有高版本PostgreSQL兼容。首先,检查当前PostgreSQL状态和版本:
sudo systemctl status postgresql psql --version如果PostgreSQL服务是active (running),并且版本高于13,那么通常可以继续。但为了保险起见,我们需要安装GVM所需的PostgreSQL开发库,并明确告诉系统我们使用现有的PostgreSQL服务:
sudo apt install -y postgresql postgresql-contrib postgresql-server-dev-all3.3 安装核心依赖与工具
GVM的运行需要一系列支撑服务和支持库。一次性安装它们:
sudo apt install -y curl wget gnupg net-tools rsync bison libpcap-dev libgpgme-dev libssh-gcrypt-dev libhiredis-dev libxml2-dev libpopt-dev libunistring-dev gnutls-bin cmake pkg-config libglib2.0-dev libical-dev perl-base heimdal-dev libperl-dev libpq-dev xsltproc libksba-dev libsnmp-dev python3-polib python3-paramiko python3-lxml python3-defusedxml python3-pip redis-server这个命令安装了编译工具、网络工具、数据库客户端以及Python3的相关库。其中redis-server是GVM用于任务队列和缓存的关键服务,务必确保它被正确安装并启动。
4. GVM核心组件安装与配置
4.1 添加Greenbone社区软件源(关键步骤)
如前所述,为了获得兼容性更好的GVM组件包,我们需要添加Greenbone官方维护的社区源。这里我们使用Greenbone社区为Debian/Kali准备的稳定版仓库。
导入Greenbone的GPG密钥,用于验证软件包签名:
sudo wget -O /usr/share/keyrings/greenbone-archive-keyring.gpg https://packages.greenbone.net/archive/keyring.gpg添加社区源到APT源列表。这里注意,我们要添加的是针对
bookworm(Debian 12)的源,因为Kali 2024基于此。创建文件/etc/apt/sources.list.d/greenbone-community-stable.list:echo "deb [signed-by=/usr/share/keyrings/greenbone-archive-keyring.gpg arch=amd64] https://packages.greenbone.net/community/debian/bookworm main" | sudo tee /etc/apt/sources.list.d/greenbone-community-stable.list更新软件包列表,使新添加的源生效:
sudo apt update执行后,你应该能在更新过程中看到来自
packages.greenbone.net的索引信息。
4.2 安装GVM完整套件
现在,我们可以安装GVM的完整元包了。这个包会拉取管理器、扫描器、前端(GSAD)等所有必要组件。
sudo apt install -y gvm安装过程会提示你配置postgresql和redis-server,通常选择默认选项即可。安装程序会自动创建_gvm系统用户和用户组,并设置必要的目录权限。
实操心得:安装过程中,如果出现类似“无法定位软件包 gvm”的错误,说明上一步添加的Greenbone源没有生效,或者你的系统代号与
bookworm不匹配。可以检查/etc/os-release文件确认系统版本,并核对源地址是否正确。
4.3 初始化GVM系统(最耗时步骤)
安装完软件包,GVM还只是一个空壳,核心的漏洞测试规则(NVTs)、扫描配置(SCAP/CERT数据)等都需要下载和初始化。这是整个流程中最耗时的一步,可能持续30分钟到2小时,完全取决于你的网络速度和磁盘IO性能。
使用gvm-setup脚本进行初始化:
sudo gvm-setup这个脚本会自动执行以下操作:
- 检查并配置PostgreSQL数据库,创建
gvmd数据库和用户。 - 下载最新的网络漏洞测试(NVT)数据包,这是漏洞扫描的核心规则库。
- 下载SCAP(安全内容自动化协议)和CERT(计算机应急响应小组)数据,用于合规性检查和已知漏洞匹配。
- 设置
gsad(Greenbone安全助手守护进程,即Web界面)的初始配置。 - 生成默认的SSL证书用于Web界面加密通信。
在这个过程中,请保持耐心,并确保:
- 网络稳定:如果中途断网,初始化会失败,可能需要清理后重来。
- 磁盘空间充足:检查磁盘空间(
df -h),确保/var目录下有至少20GB的剩余空间。 - 不要中断进程:在控制台会看到大量日志输出,这是正常的,除非出现明确的错误信息并停止,否则不要用
Ctrl+C中断。
4.4 启动GVM所有服务
初始化成功后,使用gvm-start命令一键启动所有相关服务:
sudo gvm-start这个命令会按顺序启动redis-server、postgresql、gvmd(管理器)、gsad(Web服务)和openvas-scanner(扫描器)。你可以用以下命令检查各个服务的状态:
sudo systemctl status gvmd gsad openvas-scanner如果看到active (running)的状态,恭喜你,核心服务已经跑起来了。
4.5 修改管理员密码并首次登录
默认情况下,gvm-setup会创建一个用户名为admin,密码也为admin的超级管理员账户。出于安全考虑,首次登录后必须立即修改密码。
修改
admin用户密码(这里将新密码改为YourStrongPassword123!,请务必替换):sudo runuser -u _gvm -- gvmd --user=admin --new-password=YourStrongPassword123!打开浏览器,访问GVM的Web界面。地址是
https://127.0.0.1:9392。注意是HTTPS协议。浏览器可能会提示SSL证书不安全(因为使用的是自签名证书),这是正常的,点击“高级”或“继续前往”即可。
使用用户名
admin和你刚设置的新密码登录。
5. 深度配置与优化调优
5.1 配置数据库同步与数据更新
GVM的强大在于其庞大的、持续更新的漏洞数据库。安装完成只是开始,必须配置自动更新,才能保证扫描的有效性。Greenbone提供了greenbone-feed-sync工具来同步各类数据。
首次手动同步:在终端执行以下命令,下载所有数据。这又是一次漫长的下载过程。
sudo greenbone-feed-sync --type all这个过程会同步NVTs、SCAP、CERT、GVMD数据(报告格式、端口列表等)和SCAP数据。
配置定时自动更新:为了免去手动更新的麻烦,我们可以设置一个系统定时任务(cron job)。编辑root用户的crontab:
sudo crontab -e在文件末尾添加以下行,表示每天凌晨3点自动同步所有数据:
0 3 * * * /usr/bin/greenbone-feed-sync --type all --compression-level=9--compression-level=9表示使用最高压缩比,可以节省一些带宽。
5.2 调整扫描器性能参数
默认配置下的openvas-scanner可能不适合你的硬件环境。调整其配置可以优化扫描速度和稳定性。配置文件位于/etc/openvas/openvas.conf或/etc/gvm/openvas-scanner.conf(取决于版本)。
需要关注的关键参数(在配置文件中找到并修改):
max_hosts: 同时扫描的最大主机数。默认值(通常为30)对于性能较弱的机器可能过高,可降低到10-15。max_checks: 同时进行的最大漏洞检查数。默认值(通常为10)也可以根据CPU核心数调整。建议设置为CPU逻辑核心数的1.5到2倍。plugins_timeout: 单个插件执行的超时时间(秒)。对于响应慢的网络或主机,可以适当增加(如从5增加到10)。
修改后需要重启扫描器服务:
sudo systemctl restart openvas-scanner5.3 配置Web界面(GSAD)访问
默认情况下,GSAD只监听本地回环地址(127.0.0.1)。如果你想从其他机器访问Web界面,需要修改其绑定地址。
编辑GSAD的配置文件,通常位于/etc/gvm/gsad.conf或/etc/default/gsad。找到GSA_ADDRESS或LISTEN_ADDRESS选项,将其值从127.0.0.1改为0.0.0.0(监听所有网络接口)或者你的服务器具体IP地址。
安全警告:将服务暴露在非本地网络会带来安全风险。务必确保:
- 防火墙已正确配置,只允许可信IP访问9392端口。
- 管理员密码足够强壮。
- 考虑结合反向代理(如Nginx)并配置HTTPS证书,以增强安全性。
修改后重启GSAD服务:
sudo systemctl restart gsad6. 实战:创建并执行你的第一次漏洞扫描
6.1 通过Web界面创建扫描目标与任务
登录Web界面后,我们进行第一次实战扫描。
创建扫描目标(Target):
- 点击左侧菜单栏的Configuration -> Targets。
- 点击左上角的蓝色“魔法棒”图标(创建新目标)。
- 在“Name”字段输入一个易于识别的名字,例如
Internal_Web_Server。 - 在“Hosts”字段输入要扫描的IP地址或范围,例如
192.168.1.100(单台)或192.168.1.1-254(一个网段)。切记,只扫描你有权测试的设备! - 端口列表(Port List)通常选择默认的
All IANA assigned TCP and UDP即可,它包含了常见的端口。 - 其他选项保持默认,点击“Save”保存。
创建扫描任务(Task):
- 点击左侧菜单栏的Scan -> Tasks。
- 点击左上角的蓝色“魔法棒”图标(创建新任务)。
- “Name”字段输入任务名,如
First_Scan_on_Web_Server。 - “Scan Targets”下拉菜单,选择你刚刚创建的目标
Internal_Web_Server。 - “Scan Config”是扫描策略的核心。对于第一次全面扫描,建议选择
Full and fast。这是一个平衡了覆盖面和速度的配置。Full and very deep更彻底但耗时极长;Discovery只进行主机发现和端口扫描。 - 其他选项如计划时间(Schedule)、报告格式(Report Format)可以先保持默认。
- 点击“Save”保存任务。
6.2 启动扫描与监控进度
在“Tasks”列表中找到你刚创建的任务,点击最右边的“播放”按钮(Start)来启动扫描。
扫描启动后,任务状态会变为“Requested”,然后很快变为“Running”。你可以点击任务名称进入详情页,查看实时进度,包括已完成的测试数量(NVTs)、当前正在检查的插件等。
注意事项:扫描时间取决于目标主机的数量、开放端口的数量以及选择的扫描配置。对一个简单的Web服务器进行
Full and fast扫描,可能需要15分钟到1小时。扫描期间,GVM会与目标主机产生大量网络交互,请确保不会对生产网络造成影响。
6.3 解析扫描报告
扫描完成后,状态会变为“Done”。此时,你可以查看报告。
- 在“Tasks”列表,该任务的最右侧,点击“报告”图标(一个文档形状的按钮)。
- 系统会列出该任务生成的所有报告(每次扫描都会生成一份)。点击最新的报告进入。
- 报告页面会以汇总形式展示扫描结果,包括:
- 严重性分布:用饼图展示“高危”、“中危”、“低危”、“日志”等级别的漏洞数量。
- 漏洞列表:详细列出每一个发现的漏洞,包括漏洞名称(NVT名称)、严重等级(CVSS分数)、受影响的主机/端口、漏洞描述以及解决方案建议。
- 主机摘要:按主机统计漏洞情况。
- 你可以将报告导出为PDF、HTML、XML等多种格式,方便存档或提交。
7. 安装与配置过程中的常见问题与解决方案
即使按照指南操作,你也可能会遇到一些问题。下面是我在多次部署中总结的“坑位”地图和填坑方法。
7.1 服务启动失败类问题
问题1:执行sudo gvm-start后,gvmd或openvas-scanner服务启动失败(状态为failed)。
- 排查思路:首先查看具体服务的日志,这是最直接的错误信息来源。
sudo journalctl -u gvmd -xe --no-pager | tail -50 sudo journalctl -u openvas-scanner -xe --no-pager | tail -50 - 常见原因及解决:
- 数据库连接失败:日志中可能出现“Failed to connect to PostgreSQL”或“password authentication failed”。这通常是PostgreSQL的
pg_hba.conf文件配置问题。检查/etc/postgresql/*/main/pg_hba.conf,确保有一行允许_gvm用户本地连接:
修改后需要重启PostgreSQL:local gvmd _gvm md5sudo systemctl restart postgresql,然后再启动GVM服务。 - 端口冲突:
gsad默认使用9392端口,gvmd使用9390端口。确保这些端口没有被其他程序占用:sudo netstat -tlnp | grep -E ‘:9390|:9392’。 - Redis服务未运行:
gvmd依赖Redis。确保redis-server服务是运行状态:sudo systemctl enable --now redis-server。
- 数据库连接失败:日志中可能出现“Failed to connect to PostgreSQL”或“password authentication failed”。这通常是PostgreSQL的
问题2:sudo gvm-setup在下载NVTs时卡住或报错。
- 排查思路:网络问题是主因。
gvm-setup脚本会从feed.openvas.org等地址下载数据。 - 解决方案:
- 手动下载:可以尝试从Greenbone的GitHub Release页面手动下载NVT数据包,但过程复杂。
- 使用代理:如果网络环境特殊,可以为
wget或curl配置代理。但gvm-setup脚本内部调用可能不遵循系统代理。一个更彻底的方法是在运行gvm-setup前,设置环境变量:export http_proxy=http://your-proxy-ip:port export https_proxy=http://your-proxy-ip:port sudo -E gvm-setup # -E 参数保留当前环境变量 - 重试与清理:有时只是临时网络波动。可以尝试清理后重来(谨慎操作,这会删除已下载数据):
sudo gvm-stop sudo rm -rf /var/lib/openvas/plugins/* sudo gvm-setup
7.2 Web界面访问类问题
问题:浏览器访问https://127.0.0.1:9392无法连接。
- 检查服务状态:首先确认
gsad服务是否在运行:sudo systemctl status gsad。 - 检查监听地址:确认
gsad是否监听在127.0.0.1:9392:sudo netstat -tlnp | grep gsad。 - 防火墙问题:如果是从其他主机访问,确保Kali本地的防火墙(如
ufw)放行了9392端口:sudo ufw allow 9392/tcp。 - 证书问题:如果页面显示证书错误,这是正常的,因为使用的是自签名证书。在浏览器中添加例外即可。
7.3 扫描执行类问题
问题:创建扫描任务后,一直停留在“Requested”状态,不开始“Running”。
- 原因:这通常是因为扫描器
openvas-scanner没有成功连接到管理器gvmd,或者任务队列(Redis)有问题。 - 解决步骤:
- 重启整个GVM套件:
sudo gvm-stop && sudo gvm-start。 - 检查
openvas-scanner的日志,看是否有连接管理器失败的记录。 - 在Web界面,进入Administration -> Feed Status,查看各个数据源(NVT, SCAP, CERT)的状态是否为“Current”。如果显示“Not current”或更新时间很久远,需要手动或等待定时任务同步数据。没有最新的NVT数据,扫描器可能无法启动扫描。
- 重启整个GVM套件:
问题:扫描速度异常缓慢。
- 优化扫描配置:如前所述,调整
/etc/gvm/openvas-scanner.conf中的max_hosts和max_checks参数。 - 检查目标主机响应:使用
ping或nmap检查目标主机的网络连通性和响应速度。如果目标主机本身响应慢,扫描速度自然快不起来。 - 资源瓶颈:使用
htop或top命令监控系统资源(CPU、内存、IO)。如果磁盘IO等待(wa)很高,可能是硬盘性能不足,考虑使用SSD。
7.4 数据更新类问题
问题:sudo greenbone-feed-sync执行失败,报错“Permission denied”或“Sync failed”。
- 权限问题:确保以root权限运行。数据需要写入
/var/lib/openvas/等目录,这些目录属于_gvm用户和组。greenbone-feed-sync脚本内部会处理权限,但必须以sudo执行。 - 磁盘空间不足:再次检查磁盘空间,同步过程需要临时空间。
- 网络问题:同
gvm-setup的解决方案,检查网络或配置代理。
经过以上步骤的安装、配置、优化和问题排查,你应该已经拥有了一个功能完整、运行稳定的GVM漏洞扫描平台。这套系统将成为你进行内部网络安全检查、学习漏洞评估流程的得力工具。记住,能力越大,责任越大,务必在合法授权的范围内使用它进行安全测试。
