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.
Then you are lost Try to calculate 50,000*65535 TCP Ports = 3276750000 connection Just for a ALL TCP portscan Not one single NVT executed as well. I would advice to divide such a big network into many sensors and a mix of physical and virtual appliances. To scan and process such a big network you need at least one GSM 6500 as hardware accelerated scanner Good luck setting this up.
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.
@Lukas, thank you a lot for all these explanations.
This is one of the threads I learned the most about the differences between Community and Enterprise Editions (apart from the feeds), and the corresponding limitations and challenges and thus reasons for certain choices.
It’s very clear and completely logical.
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 ?
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
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 openvassd as 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. openvas-scanner/INSTALL.md at v6.0.1 · greenbone/openvas-scanner · GitHub
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)