Configuring gvmd for external access (tls)

Building from Source and Advanced Topics
1

I’ve installed OpenVAS 22.4 (from source, following the official page) on an Ubuntu 22.04 VM running on a cloud provider. I’ve also added self signed ssl certs and can access the web UI via https, trigger scans etc and all is working.

I’m having a bit of trouble triggering a scan remotely from gvm-cli and would very much appreciate any advice that anyone might have that I can do to make it work. I have provided detailed info about my config and can provide more if needed.

gvm-cli
I want to connect to my OpenVAS VM using the gvm-cli via TLS and my gvm-tools.conf file on the client running gvm-cli contains the following:

[main]
timeout=60
tls_path=/gvm/tls

[gmp]
username=myUsername
password=myPassword

[tls]
certfile=%(tls_path)s/cert.pem
keyfile=%(tls_path)s/cert-key.pem
cafile=%(tls_path)s/ca.pem
port=9390

The command that I’m trying to execute is:

gvm-cli -c /gvm/gvm-tools.conf tls --hostname <REMOTE_OPENVAS_HOST_IP> --xml <get_version/>)

When I execute the above command I get the following error:

gvmtools.cli:[Errno 111] Connection refused

I’ve been reading through this forum and have change the settings in my gsad.service and gvmd.service files as follows:

gsad.service

[Unit]
Description=Greenbone Security Assistant daemon (gsad)
Documentation=man:gsad(8) https://www.greenbone.net
After=network.target gvmd.service
Wants=gvmd.service

[Service]
Type=exec
RuntimeDirectory=gsad
RuntimeDirectoryMode=2775
PIDFile=/run/gsad/gsad.pid
Restart=always
TimeoutStopSec=10
ExecStart=/usr/local/sbin/gsad --foreground --listen=0.0.0.0 --drop-privileges=gvm --port=443 --mlisten=0.0.0.0 --mport=9390 --rport=80 -k /etc/gvm/cert-key.pem -c /etc/gvm/cert.pem

[Install]
WantedBy=multi-user.target
Alias=greenbone-security-assistant.service

gvmd.service

[Unit]
Description=Greenbone Vulnerability Manager daemon (gvmd)
After=network.target networking.service postgresql.service ospd-openvas.service
Wants=postgresql.service ospd-openvas.service
Documentation=man:gvmd(8)
ConditionKernelCommandLine=!recovery

[Service]
Type=exec
User=gvm
Group=gvm
PIDFile=/run/gvmd/gvmd.pid
RuntimeDirectory=gvmd
RuntimeDirectoryMode=2775
ExecStart=/usr/local/sbin/gvmd --foreground --osp-vt-update=/run/ospd/ospd-openvas.sock --listen-group=gvm
Restart=always
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

When I run ss -utlpn I can see that gvmd is not running on port 9390

image
image1823×242 155 KB

I’ve read through this forum and try various configs in my gvmd.service file, but I haven’t been able to get it working so far.

I would appreciate any comments/advice if anyone knows what might be reason (based on the info) that my gvmd is not running on port 9390?

2

Hi,

you need to adjust the ExecStart= line of the gvmd.service file and add gvmd arguments for listening on a TCP port (should be -a and -p arguments).

2 Likes
3

Hi @bricks,

I tried changing the ExecStart= line in my gvmd.service file to the following:

ExecStart=/usr/local/sbin/gvmd --foreground --osp-vt-update=/run/ospd/ospd-openvas.sock -a 0.0.0.0 -p 9390

I then restarted and ran systemctl status gvmd.service for the status of gvmd, but the sevice then fails to start:

gvmd.service - Greenbone Vulnerability Manager daemon (gvmd)
     Loaded: loaded (/etc/systemd/system/gvmd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2023-01-26 16:27:09 UTC; 4min 11s ago
       Docs: man:gvmd(8)
    Process: 1138 ExecStart=/usr/local/sbin/gvmd --foreground --osp-vt-update=/run/ospd/ospd-openvas.sock --listen-group=gvm -a 0.0.0.0 -p 9390 (code=exited, status=1/FAILURE)
   Main PID: 1138 (code=exited, status=1/FAILURE)
        CPU: 562ms

Jan 26 16:27:09 openvas-dev systemd[1]: gvmd.service: Failed with result 'exit-code'.
Jan 26 16:27:09 openvas-dev systemd[1]: gvmd.service: Scheduled restart job, restart counter is at 5.
Jan 26 16:27:09 openvas-dev systemd[1]: Stopped Greenbone Vulnerability Manager daemon (gvmd).
Jan 26 16:27:09 openvas-dev systemd[1]: gvmd.service: Start request repeated too quickly.
Jan 26 16:27:09 openvas-dev systemd[1]: gvmd.service: Failed with result 'exit-code'.
Jan 26 16:27:09 openvas-dev systemd[1]: Failed to start Greenbone Vulnerability Manager daemon (gvmd).

I’ve also tried running -a 0.0.0.0 --port=9390 instead of -a 0.0.0.0 -p 9390 as detailed in another topic, but gvmd then also fails to start. I then also tried removing the line --drop-privileges=gvm from ExecStart in my gsad.service file, but that also didn’t work.

If I change my gvmd.service back to the way it was then gvmd is running correctly on the host, but then also not exposing a TCP port as before.

I’ve also tried adding --listen=0.0.0.0 --port=9390 to my ExecStart= line in my gvmd.service.

I noticed that my gvmd.service file contains --listen-group=gvm, which I haven’t seen in other posts so far (here/elsewhere online). I tried removing it and only have the -a & -p flags but that also resulted in gvmd not starting.

Is there maybe a particular order in which the arguments in the ExecStart= line in gvmd.service should be added?

4

Did you take a look at the log file to evaluate why gvmd didn’t start?

1 Like
5

I added -a 0.0.0.0 -p 9390 to my gvmd.service again and this time checked the log and I get the following output:

md   main:MESSAGE:2023-01-27 11h46.17 utc:1056:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
libgvm util:WARNING:2023-01-27 11h46.18 utc:1056: server_new_internal: failed to set credentials key file: Error while reading file.
libgvm util:WARNING:2023-01-27 11h46.18 utc:1056: server_new_internal:   cert file: /var/lib/gvm/CA/servercert.pem
libgvm util:WARNING:2023-01-27 11h46.18 utc:1056: server_new_internal:   key file : /var/lib/gvm/private/CA/serverkey.pem
md   main:CRITICAL:2023-01-27 11h46.18 utc:1056: gvmd: client server initialisation failed

When I run gvm-manage-certs -V I get:

OK: Directory for keys (/var/lib/gvm/private/CA) exists.
OK: Directory for certificates (/var/lib/gvm/CA) exists.
OK: CA key found in /var/lib/gvm/private/CA/cakey.pem
OK: CA certificate found in /var/lib/gvm/CA/cacert.pem
ERROR: CA certificate failed verification, see /tmp/tmp.yQRidCEy4y/gvm-manage-certs.log for details. Aborting.

ERROR: Your GVM certificate infrastructure did NOT pass validation.
       See messages above for details.

And the gvm-manage-certs.log file:

Note that no verification profile was selected. In the future the medium profile will be enabled by default.
Use --verify-profile low to apply the default verification of NORMAL priority string.
|<1>| There was a non-CA certificate in the trusted list: CN=****
Loaded CAs (1 available)
	Subject: CN=****
	Issuer: O=****
	Signature algorithm: RSA-SHA256
	Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. 

	Subject: CN=****
	Issuer: O=****
	Signature algorithm: RSA-SHA256
	Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. 

Chain verification output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown.

**** = Redacted info

Looks like there is something wrong with my SSL setup. When I setup my SSL I used OpenSSL to create a self signed cert, but I only did that because I was not yet aware of the gvm-manage-certs tool that GVM already has when I created my ssl cert.

If I remove the my existing SSL key & cert files, setup the appropriate env variables (as explained in gvm-manage-certs -h) and then run gvm-manage-certs -a, do I have to run any other gvm-manage-certs command or will that set up my SSL completely (apart from me having to update the key & cert paths/filenames in my gsad.service file)?

6

I managed to resolve my issue by creating a fresh gvm install, running gvm-manage-certs -a and then modifying my gvmd.service file with the -a and -p arguments as was recommended here.

I also removed the cert & key paths (-c & -k) from ExecStart in my gsad.service file.

I’m now able to interact with GVM remotely using the gvm-cli

3 Likes