Unfortunately the appliance model is not an option in my case, due to the internal constraints imposed by my company in our datacenters. So I’m a bit stuck because I can’t go for the commercial model. Regarding the issues I’ll be facing if I don’t setup a specific kernel, is this documented somewhere ? If I don’t have the choice, then at least understanding the consequences may help me taking a final call.
Thanks for your help.
As well there are virtual appliances available as well that run on many Hypervisors as well without a Firewall. If you set it up on your own, you just need to understand how TCP works. What connection tracking is, and how a firewall limit your scan capabilities with internal states, tables and counters. As well different Kernel Security might break your access to PCAP like shown above.
You make it on your own or you buy it That´s simple. We are happy to help …
I understand virtual appliances is an option for small / medium installations. In my case, it’s a very large installation with targets of up to 50,000 IPs. So I fear the virtual appliance model won’t fit.
Well, the scanner is not scanning 65535 ports of 50,000 machines simultaneously. In general the setup is more to scan 20 hosts simultaneouslly with 4 NVTs per host. This makes a total of 80 NVTs run simultaneously, which is perfectly doable. And with gvm-9, this setup is working fine enough. A target of 50,000 IPs takes between 1 to 2 weeks to perform completely depending on the number of hosts alive. Perhaps we are missing some probes due to the fact the kernel is a default one, but nothing which would ruin the objective of those campaigns.
I have difficulties to understand though what are the main diffs from gvm-9 to gvm-11 from that perspective. What worked with gvm-9 somehow would definitely not work with gvm-11 due to that limitation ? Or would it be more or less the same ?
First the session table does have a timeout around 1-4h, forget GVM-9 it´s end of life and no longer supported.
GVM-11 will do. And this limitation is valid for any scanner or high load application. You simply can´t run such a big installation without exactly tuning your system to your needs.
I am aware of performant scan setups with multiple Class-A networks but this needs to be highly tuned.
NAT and session tracking needs to identify for a period of time the state of every connection, and this will not work in your scenario.
Well, I guess the only way to know for sure is to experiment…I’m moving out of gvm-9, of course. So I’ll try in my lab with both default kernel and home made kernel and see if the results are significantly different. Thanks for the explainations.
So I have recompiled an home made kernel with everything related to netfilter / apparmor / SELinux fully disabled (there was no reference to GRSecurity), rebooted with my new kernel. But sadly I have exactly the same error message in the logs:
lib misc:MESSAGE:2020-02-14 09h46.57 utc:26714: enp0s3: You don’t have permission to capture on that device (socket: Operation not permitted)
I’ll try to launch the scanner with root permissions, see if that makes any difference. Appart from that is there anything else I could try ?
Have you checked the obvious ?
First check with TCPDUMP, and then give permissions …
- groupadd pcap
- usermod -a -G pcap nonrootuser
- chgrp pcap /usr/sbin/tcpdump
- chmod 750 /usr/sbin/tcpdump
Yes, I’ve checked the obvious and I’m still getting that error.
Yes, tcpdump works as my gvmd user. I can capture traffic without issue. However gvmd is still complaining about this error.
Note; the following command was also necessary for tcpdump to work:
> sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
Did you set this to all binaries needed by the Scanner and the OSPd ?
A strace -f -e file might help.
I’ve just added the setcap to the following files:
7 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/ospd-scanner/bin/ospd-openvas
8 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/wmic
9 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/bin/winexe
10 sudo setcap cap_net_raw,cap_net_admin=eip /opt/gvm/sbin/openvas
And so far I can’t see the error anymore (scan is still under way, but normally this error pop up quite frequently)
No I need to test it again with a normal kernel, see if that make any difference.
By the way, this is all GRSecurity So it was not disabled
Okay, thanks for the lesson. I thought it was something added to the kernel, like SELinux
Just finished my tests; I confirm the default kernel is perfectly fine. There is no need to remove netfilter / SELinux / etc… from the kernel. Disabling it is enough. That’s good news because it means there is no need to recompile our kernels to have gvm working on linux
Back to the initial message:
In GVM < 11 it was required to run the
openvassd daemon as root so that it is capable to do package forgery:
Please note that although you can start
openvassd as a user without elevated privileges, it is recommended that you start
root since a number of Network Vulnerability Tests (NVTs) require root privileges to perform certain operations like packet forgery. If you run
openvassd as a user without permission to perform these operations, your scan results are likely to be incomplete.
IIUC since GVM-11
openvassd is just
openvas which is called by
ospd-openvas (See Goodbye OTP, OpenVAS = Open Vulnerability Assessment Scanner) and to my understanding (which seems to be confirmed by the MR below) you can either run ospd-openvas as root (discouraged) or setup sudo by following the description in the MR (seem this hasn’t made it into the documentation).
I confirm; ospd-openvas needs to run as a regular user, while openvas binary needs to run with root privileges. For reference, the following needs to be done for openvas:
Edit sudoers file with visudo as root and add the following:
Allow the user running ospd-openvas, to launch openvas with root permissions
gvm ALL = NOPASSWD: /opt/gvm/sbin/openvas
Enable packet capture capability for GVM regular user: (where gvm is the user running GVM)
usermod -a -G pcap gvm
chgrp pcap /usr/sbin/tcpdump
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/bin/ospd-scanner/bin/ospd-openvas
Not sure it’s necessary to do this for all binaries though, but at least this setup works.