Clarifications regarding NVT cache and update

Archive Greenbone Community Edition
1

Hi,
I have some questions (more like clarifications) regarding the functioning of GVM11 NVT’s management. I am trying to grasp how gvm is working behind the scenes.

  1. Running greenbone-nvt-sync synchronizes NVT’s local postgresql db.

  2. Using openvas -u loads the plugins (which includes NVT’s) into Redis.
    This is not necessary should I run a scanner using ospd-openvas as it will do the update automatically each time a new feed is detected (I understand this new feed as being the comparison to the manager’s postgresql).

  3. We can start a manager by specifying --osp-vt-update=<scanner-socket> (Unix socket for OSP NVT update) so that when there is a new feed, the manager will send the new NVT’s (from postgres) into the scanner’s Redis. So if I want a new scanner they need to share the same socket or it won’t get updated?

  4. Every couple of seconds or so the manager spawns two processes:

gvm       11327  0.0  2.1 209216 98932 pts/3    S+   05:25   0:00 gvmd: Reloading NVTs
gvm       11330  0.0  2.2 209216 101944 pts/3   S+   05:25   0:00 gvmd: OSP: Updating NVT cache

I understand the manager is using osp through openvas-ospd and updating NVT cache on the scanner. How does this cache relate to Redis?
Also, what is the point on doing it with such high frequency, even on standby (i.e no scans running)?

  1. This is a bit unrelated but whenever postgres fails and comes back up gvmd displays the following logs:
md manage:WARNING:2019-11-26 15h14.38 utc:72795: sql_exec_internal: PQexec failed:  (7)
md manage:WARNING:2019-11-26 15h14.38 utc:72795: sql_exec_internal: SQL: BEGIN;
md manage:WARNING:2019-11-26 15h14.38 utc:72795: sqlv: sql_exec_internal failed
md manage:WARNING:2019-11-26 15h14.38 utc:72795: manage_schedule: manage_update_nvti_cache error (Perhaps the db went down?)

These logs are repeated indefinitely every 10s despite postgres being back up and GVM being able to perform scans, get reports etc. It appears to be happening with sqlite https://github.com/greenbone/gvmd/issues/347 on previous versions. Sounds like something is not being closed. I’ll take a further look this weekend but any hints are welcome.

Thank you for your attention.

1 Like
2

Hi @drm,

The NVT’s update is performed in the opposite direction. When greenbone-nvt-feed is run, you get the new feed and ospd-scanner stores it in Redis automatically (or you can do it manually running openvas -u). Then, gvmd asks ospd-scanner for the feed version (once each 10 seconds). In case there is a new feed, gvmd will get the new/modified NVT’s.

Regarding the point 5., unfortunately I don’t have the answer for that.

2 Likes
4

Thank you for the response!
So greenbone-nvt-sync downloads/syncs and stores in Redis while openvas -u by itself only loads existing plugins to Redis. I guess the manager asks ospd-scanner with 10s frequency because it needs the updated feed with some “novelty” for the interface.

5

Hi @jjnicola

I just finished installing openvas/gvm 11 with some help from the excellent work of falkowich at Install Greenbone Vulnerability Manager 11 on Ubuntu 19.04 from source... Part 1 · sadsloth.net

When working within gsad, all NVT data is in place and all scans are working perfectly.

However, under GSA menu “Administration” > “Feed Status”, only the SCAP and CERT feed versions are visible, the NVT feed version is nowhere to be seen. Just the same, the NVT feed is up to date on the system as can be seen with “$ greenbone-nvt-sync --feedversion”.

Is this normal in GSA 9.0?

$ gvmd --version
Greenbone Vulnerability Manager 9.0.1~git-8973c49d-gvmd-9.0
GIT revision 8973c49d-gvmd-9.0
Manager DB revision 221

$ gsad --version
Greenbone Security Assistant 9.0.0~git-ff857b53a-gsa-9.0

$ ospd-openvas --version
OSP Server for openvas: 1.0.0
OSP: 1.2
OSPd: 2.0.0

$ openvas --version
OpenVAS 7.0.0
gvm-libs 11.0.1

6

What happens in case the scanner is run remotely, so not available via file socket. We could imagine a situation, although probably not frequent, where the scanner is not running on the server hosting gvmd and gsad. I have looked into gvmd but I could not find out any option like --osp-vt-update which could be used with a network socket.

7

Have you solved this challange? I’m facing the same, running ospd-openvas remotely but no NVT’s in his inventory.

8

I don’t think it’s possible with current version.My understanding is that you need to setup feeds updates with a socket ospd-openvas on the system where gsad/gvmd run AND on the slave, you need to setup feeds updates too, but you don’t need to have gvmd run there. Only ospd-openvas + greenbone feeds updates scripts.

It’s what I’m doing at the moment and it works. The burden being you need to managed updates on all nodes separately, knowing that when a slave is updated, you won’t be able to start scan from the manager; which will set the scan task as “Done” because it doesn’t know a feed update is under way on the slave node.

From my perspective, it would makes more sense to have feeds updates managed centrally. This would avoid the risk of inconsistencies between scanners, and would reduce the load on feeds.greenbone.net because you would only need to download the feeds on one central node.

9

Hm, thanks for the insight. Then it currently makes no sense to switch to OSP. With GPM you can attach a remote GVM and distribute tasks to it. The remote GVM contacts the local ospd-openvas thru socket so you have NVT’s.