I have installed Greenbone/OpenVAS from Debian repository and running version 7.0.3. I have two NICs and both of those are having access to different networks, and also both of them are having access to Internet, one quite direct route and another via multiple hops and devices in-between.
Let’s say that my eth0 NIC is having IP 192.168.0.20 (internal network) and eth1 having IP 10.0.0.10 (direct route to Internet).
By default without specifying “Network Source Interface” at web portal scan tasks the system uses eth0 and scans for the internal network work just fine. But if I would like to use eth1 NIC to scan some subnet through more direct Internet connection the task just finishes in about a minute without producing any results. I think OpenVAS tries to use 192.168.0.20 as source IP when communicating from eth1 and that is the reason why it will not work.
I know that routing from eth1 works, since for example I’m able to fetch files with wget through it when specifying bind IP that matches to eth1. The issue is that I do have two default gateways with the server and I should be somehow able to tell to OpenVAS what source IP to use, since just specifying the interface is not solving the issue.
I have been reading the man page:
And I have specified -S attribute so that the scanner daemon knows both of the IP addresses I have, but I don’t know how to request the scanner service to use the other IP. I cannot find a setting for this from the web portal, nor my Googling efforts how to do something for it at the command line.
One possibility perhaps would be having only one default route with the server, but I really would like the default route to point to the internal network instead of the Internet, since managing the Internal IP address ranges would be painful with a large environment. Much better would be to specify for some scans to use the direct Internet connection NIC.
You have to use different namespaces and advanced routing. This is complete agnostic to the OpenVAS-Scanner.
So I’ll take this then being more like a feature request for OpenVAS… Since like I said, for example wget works perfectly well like:
wget --bind-address=10.0.0.10 http://file
If I just could specify the source IP address for a scan task, it would work just nicely. Specifying just NIC is quite useless, at least for my setup.
This would for example enable me to scan our DMZ IP range internally by default settings and when adding bind IP to the scan task I could use the same OpenVAS scanner to scan it externally from eth1. With just routing rules the traffic will always go either internal or external interface.
Also referring to the MAN page, I wonder why it is even possible to specify multiple IP addresses for the scanner daemon if those cannot be somehow used:
-S <ip[,ip2,…]> , --src-ip= <ip[,ip2,…]>
Force the source IP of the connections established by OpenVAS to checks need to fully establish a connection to the remote host. This option is only useful if you have a multi-homed machine with multiple public IP addresses that you would like to use instead of the default one. Example : openvassd -S 192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4 will make openvassd establish connections with a source IP of one among those listed above. For this setup to work, the host running openvassd should have multiple NICs with these IP addresses set.
That is NOT supported, this scenario takes a lot of OS Tailoring, we do this with GOS on our Physical Midrange and higher Appliances, but you need to reinvent it on your uncoordinated installation. The simple solution would be, use a master-sensor setup for this or buy an Greenbone Appliance.
Hi, I realise this is kind of old, but I have come across a similar thing; two interfaces, wanting to scan through the one that is not on the default GW - do I understand correctly that this has to be configured outside of GVM at the OS level? Thank you
EDIT: Based on what does Greenbone Vulnerability Manager decide through which NIC the scan will go?
That needs to be handled by the OS. Greenbone OS does support this from mid range physical appliance on.
Hi Lukas, thank you for the answer. Does GVM decide on the source interface based on the default gateway? It certainly seems to be the case.
EDIT: yeah, the above is the case.
Just as a friendly reminder this is not the job of GVM your OS is doing it. GVM writes raw socket packets and then your OS needs to deal with the packets.