I’ve seen a number of posts with no response, so I’m adding mine here too.
Is $Subject possible? If so, is there any documentation on how to setup?
Thanks,
-Scott
Yes its possible create a remote OSP-Scanner with 22.4
Steps are the same for either a docker container or source build.’
Example assumes a source in install into /usr/local and configuration data written to /var/lib/gvm
To do this with docker use docker compose exec gvm gvmd instead of sudo
1 configure your main scanner (gvmd, ospd-openvas, gsad).
2 generate your certificates for SSH authentication for your clients.
sudo -u gvm gvm-manage-certs -a -q -f
3 copy client certificates from /var/lib/gvm/CA and /var/lib/gvm/private/CA to remote scanner platform
4. configure ospd-openvas to use the specified certificate files by changing the contents of
/etc/gvm/ospd-openvas.conf to the following:
[OSPD - openvas]
port = 9390
bind_address = 0.0.0.0
log_level = INFO
ca_file = /var/lib/gvm/CA/cacert.pem
cert_file = /var/lib/gvm/CA/clientcert.pem
key_file = /var/lib/gvm/private/CA/clientkey.pem
pid_file = /run/ospd/ospd-openvas.pid
log_file = /var/log/gvm/ospd-openvas.
5 either start your docker containers remote scanner - or do the following
start redis and mosquito services, do an initial feed sync with greenbone-feed-sync --type nvt.
start ospd-openvas
6. On the main scanning node
gvmd --verbose --create-scanner=“DEMO NAME”
–scanner-host=remote-host
–scanner-port=9390
–scanner-type=OSP-Sensor
–scanner-ca-pub=/var/lib/gvm/CA/cacert.pem
–scanner-key-pub=/var/lib/gvm/CA/clientcert.pem
–scanner-key-priv=/var/lib/gvm/private/CA/clientkey.pem
Beware gvmd does not check if connection is valid so you may with to do gvmd --verify-scanner on the UUID just defined to ensure connection configuration is valid.
To remove the remote scanner gvmd --delete-scanner is used. Beware you will corrupt your database for GSAD if you do not delete all the tasks associated with the remote scanner first (including any deleted trasks still in the trash can).
3 Likes
Hello,
Thank you for all these sweet information :)!
Would these configuration be kept in case of update/reboot of the container ?
It should if your docker compose file is correct. If the certificates used by the scanner are stored as secrets in the docker project directory they should persist.
If you run docker compose $COMPOSE_OPTIONS exec -u gvmd gvmd gvm-manage-certs -a -q -f
you need to update the clients that use them. Normally these certificates persist in the gvmd container.
Thanks for this @bwittm
gvmd --version
Greenbone Vulnerability Manager 22.9.0
When verifying my remote scanner I get this:
WARNING:2023-10-11 08h48.53 CEST:3222: Could not connect to Scanner at 10.0.0.239:9390
However, when investigating there are no packets sent from gvmd, so it’s not even trying to connect?! 
Just to be clear, I’m monitoring the traffic with tcpdump on the container greenbone-community-edition-gvmd-1 itself. And when simulating traffic with other tools I connect fine and can see the traffic. Also no other connectivity issues from this container, it’s just gvmd that is not even trying to connect to the remote scanner.
Looks like some configuration things changed though, like OSP-Sensor is not a valid scanner-type anymore. So mine is OpenVAS (type 2). Also forced to use client cert credential but all that “should” be OK I believe. And not a reason for gvmd to show this in the log without trying to connect.
Any ideas?
The OSP-Sensor type is still supported by gvmd. Support within gsa is limited.
It’s the only sensor type that supports a host and port.
on the main scanner:
docker compose exec -u gvmd gvmd gvm-manage-certs -a -q -f
create your remote sensor with the keys copied from the gvmd container.
Remember the remote scanner docker compose file is different than that of the main scanner.
the coetent of this file can be found in other posts.
As is the /etc/gvm/ospd-openvas.conf file different it should be:
ospd-openvas scanner - connected directly to gvmd
[OSPD - openvas]
port = 9390
bind_address = 0.0.0.0
log_level = INFO
ca_file = /var/lib/gvm/CA/cacert.pem
cert_file = /var/lib/gvm/CA/clientcert.pem
key_file = /var/lib/gvm/private/CA/clientkey.pem
pid_file = /run/ospd/ospd-openvas.pid
log_file = /var/log/gvm/ospd-openvas.log
docker compose exec -u gvm gvm gvmd -create-scanner=“remote sensor”
–scanner-host=172.16.0.3
–scanner-port=9390
–scanner-type=OSP-Sensor
–scanner-ca-pub=/var/lib/gvm/CA/cacert.pem
–scanner-key-pub=/var/lib/gvm/CA/clientcert.pem
–scanner-key-priv=/var/lib/gvm/private/CA/clientkey.pem
Note this above command will always succeed.
gvmd --verify-scanner is the only way to tell if its real.
Hopefully this will help with why your remote scanner is not working.
Thanks for your reply, much appreciated!
For the remote OpenVAS I’m quite sure everything is ok.
The real problem I believe resides on the main scanner. With the proviso that I might be misunderstanding, if you mean "docker compose exec -u gvm gvm gvmd -create-scanner=“remote sensor” " is referring to some other special container and not the greenbone-community-edition-gvmd-1 I’m currently struggling with.
It’s like some options has been disarmed or something.
Check this out… added exit codes to the commands.
root@755bde04bb80:/# gvmd --version && echo "exit 0" ||echo "exit 1"
Greenbone Vulnerability Manager 22.9.0
Manager DB revision 255
Copyright (C) 2009-2021 Greenbone AG
License: AGPL-3.0-or-later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
exit 0
root@755bde04bb80:/#
root@755bde04bb80:/# gvmd --verbose --create-scanner="remote_sensor" --scanner-host=172.16.0.3 --scanner-port=9390 --scanner-type=OSP-Sensor --scanner-ca-pub=/var/lib/gvm/CA/cacert.pem --scanner-key-pub=/var/lib/gvm/CA/clientcert.pem --scanner-key-priv=/var/lib/gvm/private/CA/clientkey.pem && echo "exit 0" ||echo "exit 1"
exit 1
root@755bde04bb80:/#
root@755bde04bb80:/# gvmd --get-scanners && echo "exit 0" ||echo "exit 1"
exit 1
root@755bde04bb80:/#
root@755bde04bb80:/# gvmd --foo-bar="hello" && echo "exit 0" ||echo "exit 1"
(gvmd:1302): md main-CRITICAL **: 17:25:31.684: gvmd: g_option_context_parse: Unknown option --foo-bar=hello
exit 1
root@755bde04bb80:/#
However, through the API I can manage everything, but when trying to set the scanner type to OSP-Sensor I get:
Response Error 400. Invalid value
But honestly not sure about anything atm… IP and PORT is configured, type is OpenVAS (as on the remote machine) and I do get “Could not connect to Scanner at 10.0.0.239:9390” in the logs. But no packets leaving the machine 
There is no working python-gvm API to add/delete scanners you must use gvmd directly. I know because I wrote a bug against the Gmp.delete_scanner python-gvm API for this.
Don’t try and run the gvmd commands as root. It must be run as the gvmd user. The way to do this is:
docker compose exec -u gvmd gvmd bash
This is from my deployment.
gvmd --version
Greenbone Vulnerability Manager 22.9.0
Manager DB revision 255
Copyright (C) 2009-2021 Greenbone AG
License: AGPL-3.0-or-later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
when gvmd --get-scanners is called it will without a remote scanner
UUID1 OpenVAS /run/ospd/ospd.sock 0 OpenVAS Default
UUID2 CVE 0 CVE
With a remote scanner.
UUID1 OpenVAS /run/ospd/ospd.sock 0 OpenVAS Default
UUID2 CVE 0 CVE
UUID3 OSP-Sensor hostname 9390 test-scanner
Brilliant! Now we’re on track again… thank you 
gvmd@755bde04bb80:/$ gvmd --modify-scanner="328798af-7eec-4801-96cc-b43103b2d306" --scanner-type=OSP-Sensor
Scanner modified.
Thing is I was actually running the commands with ‘su gvmd -c’ at first but didn’t get any output at all then, tried various ways of jumping to the gvmd user inside the container but failed.
Haven’t tried much yet but sure things will be easier to manage now
type=OSP-Sensor got a numeric value of 5 and I actually tested it before, scanner disappears from the scanners view, but what I didn’t notice is that it’s still selectable for scans. Is it only for me or does it disappear for anyone else when setting to OSP-Sensor?
Haven’t tried python-gvm but works fine with gvm-cli both over TLS and socket, so perhaps something isolated to the python library you ran into then. Or it’s been fixed.
So after testing all possible combinations I still can’t get gvmd to initiate a single packet to the remote scanner when doing a --verify-scanner. But the bogus log event is still there.
md manage:WARNING:2023-10-12 10h52.34 CEST:448: Could not connect to Scanner at 10.0.0.239:8888
@bwittm When time, may I ask you to confirm your gvmd container actually initiates some traffic when you verify a remote scanner? No need for a successful connect, just if a SYN is sent.
e.g. tcpdump -i br-2e36aa38e73a -n host 10.0.0.238
Otherwise I would seriously wonder if this is a bug or simply “disarmed” by design in greenbone-community-edition-gvmd-1. But hopefully just some other configuration part I’m missing somewhere.
What you see in the security assistant is mostly correct. By default, the OSP-Sensors are not displayed. To see all the configured scanners do the following:
menubar->Configuration->scanners
Now select the folder icon the screen.
This will display the details of all the scanners which will display the configured scanners.
The fact that gvmd cannot connect points a few possible issues.
- your docker compose file for the remote scanner is wrong so nothing is listening.
- The remote host OS running your ospd-openvas docker container may be blocking the connection.
What is the OS that’s running the docker containers?
If the host OS is RedHat/Fedora/CentOS or Rocky Linux firewalld is normally enabled so, check its configuration. Ubuntu also supports a software firewall (firewalld or ufw) but by default it’s not running.
To see if your remote sensor is running check:
docker ps
docker compose logs ospd-openvas
docker compose exec exec ospd-openvas /var/log/gvm/openvas.log
One odd behavior I have seen with these containers is ospd-openvas and notus-scanner sometimes do not start after reboot of the platform. If this is the case change the restart options for them from
restart: on-failure to restart: unless-stopped
Ah nice! there I can see the remote scanner, shown as “Greenbone Sensor”.
But for the connection issues, at this point it has nothing to do with the remote ospd-openvas. It’s gvmd that is not even trying to connect to it.
When/if I get this sorted, the next issue may be with the actual authentication and connection to the remote scanner. But at this point gvmd is the blocker.
So I would guess something in this order…
- a gvmd configuration issue, direct or indirect through docker.
- by design
- a bug
Hello i’m trying this setup but encounter some doubt.
For the point 4., i have 2 file named ospd-openvas.conf when i look for them for my container:
/var/lib/docker/overlay2/a268084e8fb62e3267aff5f39777eb131d41b715ad9ffd0e8bc28adf92a1a624/diff/etc/gvm/ospd-openvas.conf
/var/lib/docker/overlay2/a268084e8fb62e3267aff5f39777eb131d41b715ad9ffd0e8bc28adf92a1a624/merged/etc/gvm/ospd-openvas.conf
Also does that configuration need to be done on the main scanner, the remote one or both?
And does the port 9390 is need in UDP or TCP ?
I read some answer about remote-scanner container, is this different from the one on the website ?
Thank you for your help =D 
The containers are the same the docker compose file is different. There are fewer services when running a remote sensor. It does not use gsad, gvmd, pg-gvm, gvm-tools or the data feeds that support gvmd. The other items you will need to deal with is mounting the certificates into the ospd-openvas container, as well as, the customized ospd-openvas.conf file. Just remember to copy the certificates you generated for gvmd on the main scanner to your remote sensor(s).
Okay
Do you know where i can find the correct docker compose file for the remote scanner version ?
Hello
By any chance do you have a link to a doc/git for the official docker compose file of the remote sensor ?
I have tried to use the “normal” docker compose and not use gsad, gvmd, pg-gvm, gvm-tools but it only broke it on my side ^^’
So … How does the notus-scanner fit into this scenario? Does it need to be running in the container with ospd ? Does it need to be running in its own container? Will ospd start it if it’s available ?
Thanks,
Scott
For master/sensor scenarios, notus-scanner behaves in the same way as in common scenerio. Since it communicates with openvas and ospd via mosquitto (MQTT broker), it must be installed in the “sensor side” and has nothing to do with the master.
4 Likes