Master and slave architecture

GVM versions

gsa: 9.0.1
gvm: 9.0.1
openvas-scanner: 7.0.1
gvm-libs: 11.0.1

Environment

Operating system: Debian Buster
Kernel: Linux 4.19.0-8-amd64

Hey :slight_smile:

I’m trying to implement a master and slave architecture with GVM 11. I firstly installed every components on two different virtual machine and each of them can perform basic scans. I then tried to create a GMP scanner which is configured with my slave’s ip address, credential and cacert.pem. After that, I tried to verify my GMP scanner, I have an error which tells me " database must be initialized from scanner" on Master side.
This is a sample of my Master configuration and error message:


I read few topics about this issue and it figure out that scanner doesn’t know which socket to use (I think) but I don’t know which scanner to mention.
Moreover, I find strange that GMP uses port 22 because on every topics I read it uses port 9391, I don’t know if it changes something.

Does someone has already had this issue?

Thanks!

We recommend to use file-sockets and not TCP connections with Certificates. To interconnect this sockets you need external tools, like SSH to build a master-slave setup. This is handheld by GOS and not GVM.

Thanks for your response.

I don’t really understand, is there a way to setup Master and Slave architecture with GVM 11? :confused:

Please note that the Master-Slave Setup changed completely with GVM 11, you need to use OSPD, all information (Source code) is available at:

At the moment there is not more detail information available. But you need to use OSP and not GVM any longer.

Hi Lukas,

Can you elaborate why file sockets would be preferable over network socket ? Since ospd natively support TCP connections.

From my experience, where I have both running; they equally share bugs & stability issues. I have witnessed no differences between the two methods.

Thanks

Hi Galen,

Yes, that is possible, although badly documented and prone to many issues. I have setup an infrastructure of one master and several slaves, all using GSE. It somehow works, assuming you follow the following conditions:

  1. You have a very stable network. Gvmd <-> OSPd connection are not resilient at all, and if for some reason the connection is lost, gvmd won’t resume it properly. It may even crash gvmd in some cicumstances.
  2. You must stick to small targets (I would say /22 maximum). Having larger targets may works, but may equally fails having scans stucked at various percentages forever.
  3. Tracing problems is very difficult, as even in debug mode, logs produced are not very useful and are using different hard coded timezones which makes debugging very difficult. Equally, SID are not shared between master & slave. (Master use one SID to identify a scan task, the slave use a different one for the same task)
  4. There is no real task synchronization between the master and slave. (Eg, a task stopped on the slave side may still be seen as running on the master; or the other way). This can happen randomely, for no particular reasons. (Although generally it happens on large or complex tasks)

I have created bugs requests for this weeks ago, but nobody has been assigned to them yet.

So to conclude I would say master / slave architecture with GSE somehow works, but you must be prepared to spent a lot of time on it, in particular to stop & restart tasks, restart scanners, etc… I wouldn’t consider this stable at all, although again it somehow works.

If you’re still interesting to have a master / slave setup, drop a reply and I’ll explain you how.

Regards,

1 Like

Hi tatooin,

Thank you very much for your answer.
I’m still interested to have a master / slave setup. Can you please tell me more about that ? :slight_smile:

Thanks in advance

Okay, so here you go. Note that I suppose in this guide you’ve setup your postgresql database properly. This is well documented in the gvmd README file.

Please also note that gvmd is only necessary on the master side. You don’t have to run it on the slave side.

First you need to tweak some sysctl configs:

sysctl -w net.core.somaxconn=1024
sysctl -w vm.overcommit_memory=1
echo “net.core.somaxconn=1024” >> /etc/sysctl.conf
echo “vm.overcommit_memory=1” >> /etc/sysctl.conf

Disable THP:

cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Disable Transparent Huge Pages (THP)

[Service]
Type=simple
ExecStart=/bin/sh -c “echo ‘never’ > /sys/kernel/mm/transparent_hugepage/enabled && echo ‘never’ > /sys/kernel/mm/transparent_hugepage/defrag”

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload ;
systemctl start disable-thp ;
systemctl enable disable-thp ;\

Then you need to make sure you have EXACTLY the same version installed on both master and slave. Take the latest stable release branch via git:

git clone -b gvm-libs-11.0 https://github.com/greenbone/gvm-libs.git
git clone -b gvmd-9.0 https://github.com/greenbone/gvmd.git
git clone https://github.com/greenbone/openvas-smb.git
git clone -b openvas-7.0 https://github.com/greenbone/openvas.git
git clone -b ospd-2.0 https://github.com/greenbone/ospd.git
git clone -b ospd-openvas-1.0 https://github.com/greenbone/ospd-openvas.git
git clone -b gsa-9.0 https://github.com/greenbone/gsa.git

Build & install everything under /opt/gvm under the user gvm on both Master & Slave; then on both systems:

Setup GVM Certificates installation. Attention; you need to setup the certificates hostnames properly otherwise slave authentication may fails.

export GVM_CERTIFICATE_LIFETIME=3600
export GVM_CERTIFICATE_HOSTNAME=yourfqdn.name

Then run gvm-manage-certs -a

Again, do this on both system.

Now you need to setup ospd & openvas configuration files:

Create /opt/gvm/etc/openvas/ospd.conf

[OSPD - openvas]
kb_location = /var/run/redis/redis.sock

Create /opt/gvm/etc/openvas/openvas.conf

db_address = /var/run/redis/redis.sock

Open your redis.conf file and make sure the following parameters are present:

unixsocket /var/run/redis/redis.sock
unixsocketperm 775
databases 65535

Make sure the following are commented out:

#save 900 1
#save 300 10
#save 60 10000

Now restart redis and check it’s listening on /var/run/redis/redis.sock, with the rights permissions.

Fix openvas permissions so it can runs probes needing root privileges:

sudo groupadd pcap
sudo usermod -a -G pcap gvm
sudo chgrp pcap /usr/sbin/tcpdump
sudo chmod 750 /usr/sbin/tcpdump
sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/wmic
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/winexe
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/openvas-nasl
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/openvas-nasl-lint
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/sbin/openvas
sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/ospd-scanner/bin/ospd-openvas

At this point you should be able to start gvmd and setup the scanner on the master. So thie following section only apply to the master.

Start gvmd from a terminal:

/opt/gvm/sbin/gvmd --osp-vt-update=/opt/gvm/var/run/ospd.sock --inheritor=admin -f

Using -f flag with help you debug everything is correct. You can remove that flag afterward. Gvmd will complain it is not initialized, which is normal. Read on.

Download feed updates:

greenbone-scapdata-sync
greenbone-certdata-sync
greenbone-nvt-sync

Start ospd-openvas wrapper:

/opt/gvm/bin/ospd-scanner/bin/python3.6 /opt/gvm/bin/ospd-scanner/bin/ospd-openvas --pid-file /opt/gvm/var/run/ospd-openvas.pid --unix-socket=/opt/gvm/var/run/ospd.sock --log-file /opt/gvm/var/log/gvm/ospd-scanner.log --log-level DEBUG --lock-file-dir /opt/gvm/var/run/ --config /opt/gvm/etc/openvas/ospd.conf -f

Again, -f flag will make sure you get all logs in ther terminal and will help debugging. Remove it once it’s working as expected. Leave it sometime to populate the redis database and load all feeds.

Create your local admin user:

gvmd --create-user=admin --password=your_pass --role=“Super Admin”

Once ospd-openvas has finished loading, check your gvmd terminal to see if it has connected succesfully to ospd.sock and is populating the database correctly. At this point, the database should be initialized properly by gvmd.

Now you can create the local scanner on the master side:

gvmd --create-scanner=“Master OPENVAS Scanner” --scanner-type=“OpenVas” --scanner-host=/opt/gvm/var/run/ospd.sock

Check with gvmd --verify-scanner =your_scanner_UUID that it’s working fine.

At this point, you should have a local GSE up & running. You can run scans via gsad, but using your local scanner.

Now, on the slave side, you can setup your slave scanner:

Download feed updates:

greenbone-scapdata-sync
greenbone-certdata-sync
greenbone-nvt-sync

/opt/gvm/bin/ospd-scanner/bin/python3.6 /opt/gvm/bin/ospd-scanner/bin/ospd-openvas --pid-file /opt/gvm/var/run/ospd-openvas-slave.pid -p 9390 -b 0.0.0.0 -k /opt/gvm/var/lib/gvm/private/CA/serverkey.pem -c /opt/gvm/var/lib/gvm/CA/servercert.pem --ca-file /opt/gvm/var/lib/gvm/CA/cacert.pem --log-level DEBUG --lock-file-dir /opt/gvm/var/run/ -l /opt/gvm/var/log/gvm/ospd-openvas-slave.log -f

Wait for it to populate redis db and finish loading nvt. It may take some time. Make sure the slave finishes loading properly.

Now copy the following slave client certificates to the master which will be used for the authentication. Copy them to gvm directory on the master side.

/opt/gvm/var/lib/gvm/CA/cacert.pem
/opt/gvm/var/lib/gvm/private/CA/clientkey.pem
/opt/gvm/var/lib/gvm/CA/clientcert.pem

Now, get back to the master and setup the slave scanner:

gvmd --create-scanner=mySlaveScanner --scanner-type=OpenVas --scanner-port=9390 --scanner-host=your_slave_ip --scanner-ca-pub=/opt/gvm/cacert.pem --scanner-key-priv=/opt/gvm/clientkey.pem --scanner-key-pub=/opt/gvm/clientcert.pem

Make sure you choose the certificates you’ve just copied from the slave, as they will be used to authenticate gvmd against the scanner.

Now again, check your scanner with gvmd --verify-scanner, and if you did everything correctly you should have the following result: OpenVAS 7.0.1.

and a working slave scanner :slight_smile:

1 Like

TLS is always subjected to the pain of certificate management, PKI, expiration, insecure ciphers, hashes and protocols (TLS 1.0, TLS1.1…) , etc … with sockets you outsource this complexity to a unix file permission :wink:

Thank you very much for your answer.

However, I’m facing an issue. I saw in different topics that it comes from certificate configuration. I think my misconfiguration comes from this command :
EXPORT_GVM_HOSTNAME=yourfqdn.name
This is what I did during my configuration:


Do you see something wrong?

Thanks in advance :slight_smile:

Yes, you are using server certificates on the client (gvmd), and client certificates on the server ! (ospd.openvas)

You must do the other way around. Client certs on gvmd; server certs on ospd.openvas.

I also tried this way but I keep having an issue with SSL.

This is what I did:

I don’t see what’s going wrong :confused:

This is my error if it can help:

Don’t pay attention to my Master’s IP address, it changes from 192.16.1.44 to 192.168.1.43

Hi Galen,

I actually can reproduce your issue. For some reason, it seems using client certificates on the client, and server certificates on the server (as it’s suppose to be !) doesn’t work and generate this SSL error.

I’m actually discussing this issue on github: https://github.com/greenbone/ospd-openvas/issues/259

As a workaround; use the client certificates on BOTH master and slave. Incredible but true !

It’s what I did (by mistake !) and it works…

Thanks so much for your help :smiley:

Effectively, I don’t have ssl handshake issue anymore but I have an other issue according to ssl:

The only difference with your setup is the python version. I’m using 3.7 instead of 3.6 in your environment. Do you think that this can be the problem or do you have already had this issue? :slight_smile:

It may be linked to newer SSL librairies. There is a patch for this problem on github: https://github.com/greenbone/gvmd/pull/1139

Thank you for your advice.

Therefore I installed the new version of gvmd. I generated certificates and key with gvm-manage-cert on both side. I tried to use client cert on master and server cert on slave, I haven’t ssl handshake error anymore but I keep having this issue:

I don’t already found how to solve this.
If you have any advice, I’m more than interested

------- EDIT:

This issue is due to python3.7, using pythn3.6 works as expected! Thanks so much for your time :slight_smile:

Good to know you’ve solved it. Thanks for raising the issue with python3.7