No response from localhost:9392

lcn · September 8, 2024, 5:25pm

Hi!

My QEMU guest is Debian Forky and host is Debian Bookworm.
I installed package gvm in QEMU guest.
Below is what I did in QEMU guest.
What have I missed?

wget http://localhost:9392 prints:

--2024-09-09 00:14:09--  http://localhost:9392/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:9392... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:9392... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2024-09-09 00:14:10--  (try: 2)  http://localhost:9392/
Connecting to localhost (localhost)|127.0.0.1|:9392... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

gvm-check-setup prints below.

gvm-check-setup 23.11.0
  Test completeness and readiness of GVM-23.11.0
Step 1: Checking OpenVAS (Scanner)... 
        OK: OpenVAS Scanner is present in version 23.8.5.
        OK: Notus Scanner is present in version 22.6.4.
        OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.
Checking permissions of /var/lib/openvas/gnupg/*
        OK: _gvm owns all files in /var/lib/openvas/gnupg
        OK: redis-server is present.
        OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock
        OK: the mqtt_server_uri is defined in /etc/openvas/openvas.conf
        OK: _gvm owns all files in /var/lib/openvas/plugins
        OK: NVT collection in /var/lib/openvas/plugins contains 92080 NVTs.
        OK: The notus directory /var/lib/notus/products contains 467 NVTs.
Checking that the obsolete redis database has been removed
        OK: No old Redis DB
        OK: ospd-openvas service is active.
        OK: ospd-OpenVAS is present in version 22.7.1.
Step 2: Checking GVMD Manager ... 
        OK: GVM Manager (gvmd) is present in version 23.8.1.
Step 3: Checking Certificates ... 
        OK: GVM client certificate is valid and present as /var/lib/gvm/CA/clientcert.pem.
        OK: Your GVM certificate infrastructure passed validation.
Step 4: Checking data ... 
        OK: SCAP data found in /var/lib/gvm/scap-data.
        OK: CERT data found in /var/lib/gvm/cert-data.
Step 5: Checking Postgresql DB and user ... 
        OK: Postgresql version and default port are OK.
 gvmd      | _gvm     | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           | 
16440|pg-gvm|10|2200|f|22.6||
        OK: At least one user exists.
Step 6: Checking Greenbone Security Assistant (GSA) ... 
        OK: Greenbone Security Assistant is present in version 22.11.0~git.
Step 7: Checking if GVM services are up and running ... 
        OK: gvmd service is active.
        OK: gsad service is active.
Step 8: Checking few other requirements...
        OK: nmap is present.
        OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
        OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
        OK: xsltproc found.
        WARNING: Your password policy is empty.
        SUGGEST: Edit the /etc/gvm/pwpolicy.conf file to set a password policy.
Step 9: Checking greenbone-security-assistant...
        WARNING: the package greenbone-security-assistant is not installed
        FIX: install the package greenbone-security-assistant (available in non-free)

It seems like your GVM-23.11.0 installation is OK.

Package greenbone-security-assistant is replaced by gsad and /etc/systemd/system/greenbone-security-assistant.service is a symbolic link to /usr/lib/systemd/system/gsad.service.

/var/log/gvm/gsad.log:

gsad main:MESSAGE:2024-09-08 16h08.12 utc:679: Starting GSAD version 22.11.0~git

lcn · September 10, 2024, 4:48am

I am having this same problem with Ubuntu 24.04.1 which also runs as a QEMU guest on top of the same Debian Bookworm host.

lcn · September 10, 2024, 7:22am

I edited /etc/apt/sources.list to append non-free, and then installed packages greenbone-security-assistant and nodejs. The former package filled several files under /usr/share/gvm/gsad/web/.

Then I changed all level in /etc/gvm/gsad_log.conf to 128 and then issued command systemctl restart gsad.

File /var/log/gvm/gsad.log now reports the following line in addition to Starting GSAD version 22.11.0~git.

gsad main:  DEBUG:2024-09-10 06h52.54 utc:1942: GSAD started successfully and is listening on port 9392.

gsad doesn’t log anything about why it doesn’t respond any content to wget http://127.0.0.1:9392.

This issue occurs to both Debian and Ubuntu.

Lukas · September 10, 2024, 12:34pm

Hi,

Are you trying to connect to localhost within the VM or from outside ? It seems you try to connect from the host and that is of course not working to a loopback of a guest
You need to bind that to a networking interface within your virtual network setup.

lcn · September 10, 2024, 4:32pm

I actually tried both - issuing the command wget from within the guest and from host, and got the same aforementioned messages.

Firstly, I launch the guest with this command:

qemu-system-x86_64 -m 5G,maxmem=5G -drive format=qcow2,file=forky.qcow2 -accel kvm -netdev user,id=net0,hostfwd=tcp::8022-:22,hostfwd=tcp::8080-:9392 -device virtio-net-pci,netdev=net0

With the guest started in this way, I succeeded in signing in to guest from host with this command ssh user@127.0.0.1 -p 8022.

But the command wget http://127.0.0.1:8080 running from host gets the same messages as the command wget http://127.0.0.1:9392 running from within guest (VM) does.

Lukas · September 11, 2024, 2:07pm

Did you checked the binding with “ss” on the guest.
You can´t access loopback via VM Networking from the host, you need to bind that to a VM Interface within the guest …

lcn · September 12, 2024, 10:56am

I have no clue about the “ss binding”.

Not only wget in host receives no responses, but the wget http://127.0.0.1:9392 command I type in QEMU guest, in which gsad also runs, connects but receives no content from local gsad.

I resort to this approach in QEMU guest (Ubuntu server edition) and have succeeded in bringing up gvm to run flawlessly in QEMU guest.

My browser in QEMU host can now fully access gsad running in QEMU guest.

Close this case.

cfi · September 12, 2024, 12:21pm

Note that the used 3rdparty packages / integration might have enabled SSL/TLS (https) by default but you have only us plaintext (http) wget and curl calls. In such cases it seems to be expected (had shortly verified this on an own installation) that no responses are given by the gsad daemon.

lcn · September 14, 2024, 12:25pm

If I understand gsad correctly, it uses libmicrohttpd and runs independently as a standalone HTTP server, and it solely decides whether HTTPS/HTTP will be supported or not.

None of the following sets of parameters fixes the no-response problem.

gsad --foreground --listen=0.0.0.0 --port=9392 --no-redirect

gsad --foreground --listen=0.0.0.0 --port=9392 --http-only --no-redirect

gsad --foreground --listen=0.0.0.0 --port=9392 -k /etc/ssl/private/ssl-cert-snakeoil.key -c /etc/ssl/certs/ssl-cert-snakeoil.pem --no-redirect