I’m having a hard time in preventing my scanner from following and scanning other, but connected, hostnames.
For example, let’s say I want to execute a scan of target “mydomain”, which is an alias of “maindomain”, which is on IP 1.2.3.4. The webserver will serve a certificate from it’s IP address with secondary domain names “customer1”, “customer2”.
As it is, the openvas scanner attacks ALL these domains, and not just the single one I want, which is “mydomain”. This behaviour results in my audits scanning too much, taking too long, attacking other customer’s web sites, and the reports/results can be huge.
I have been experimenting with the server config (openvassd.conf) and scan config nvt settings to try to find a way to disable this behaviour, but to no avail!
Am I missing out on something obvious here? Is there a single setting in the config file to disable this, or a single nvt?
Please note that you shouldn’t use such pre / development releases in production, especially not when doing audit scanning against live targets as such releases might be not feature complete or even contains bugs/issues causing a lower coverage of your scans or other unwanted side effects.
Related to your initial question there is currently no such configuration to directly control this new behavior. It might be introduced in the final release of GVM-10, i will keep this topic updated on this matter.
To answer your issue report on https://github.com/greenbone/openvas-scanner/issues/177 and to expand on Christian’s answer, with current master / upcoming GVM-10, we are replacing manual/limited handling of vhosts through old vhosts_ip/vhosts preferences with automatic detection and addition of vhosts values through different means (reverse-lookups, matching names and ip’s in target lists to avoid duplication of scans, handling of multi-name resolutions etc,.) this part resulted in scanning of domx.net for you.
Plugins now can inject new vhost values to the scanner. This part resulted in scanning of cust1/2.com
Current Master branch is work-in-progress, obviously. We’re thinking about adding a new preference to limit/disable the automatic expansion of vhosts values.
“exclude_hosts” preference should also probably support excluding vhost values too, but it is only working for hosts/IPs as of now, so it wouldn’t solve your issue, as all domains point to the same IP.
I strongly support what you propose. Having a preference (in openvassd.conf or in target settings) like “scan_vhosts=yes/no”, “follow_vhosts=yes/no” or similar, is a must have to control this behaviour.
The current behaviour places openvas scans out of control for the auditor, and there is no way to tell exactly what will be scanned. I have seen hosting providers operating up to 100 sites on a single IP, with dozens of domain names on a single certificate (to safe money). Besides, DNS reverse records can be multiple, outdated and can point to domains completely outside of the scope of the audit.
I did some scans with different combinations of “Reverse Lookup Only” and “Reverse Lookup Unify” in target settings, but that has no effect on this behaviour, i.e. multiple domains on same IP and/or certificate.
Come to think of it, this feature you are describing - automatic detection and addition of vhosts values through different means, reverse-lookups etc. - is down right dangerous and should not be implemented at all!
He who is performing the scan should order the scan based on a known list of domains/hostnames/IPs. And, IF he orders a scan based on reverse lookups or certificate additional names, he must know the risks associated. This feature can easily wreck havoc in an environment of sensitive equipment!
as previously outlined this functionality is far from being feature complete (thus it only “lives” in the master/development branch) and there are various considerations to allow to control this behavior.
Just to clarify, at least from the VT side which is collecting additional hostname from the certificate:
There is no expansion of the target scope done to systems found outside of the target scope. If an additional hostname was gathered from such a certificate it will be verified against the IP of the actual target and no expansion is done if it doesn’t match to that target.
Just the same, defining the “scope” as being “everything on this IP address” is not safe. A single IP may host a multitude of systems completely out of scope with eachother.
A feature like this should ONLY be activated by the user on a per target level. And even then, it still is down right dangerous for reasons I have outlined above.
If the auditor does not know exactly what will be scanned, this feature is a “Russian Rulette”, both for the systems involved and his own credibility
A feature like this belongs to the discovery phase of a pen test/audit, where the auditors runs tools and methods to find out all systems associated with a target network, before doing actual vulnerability scans.
as outlined previously there is no fixed decision made on this. It is currently implemented in an early development state with still a lot room for improvements until the final release shipped within a stable release. And there might be various configuration possibilities as outlined previously as well.
You also need to consider that the most common use case for OpenVAS/GVM is to scan whole subnets where the scanning operator (in your case called “Auditor”) don’t know what is running within it.
While you might think that the functionality doesn’t match your use case it might be highly desired by others.
Btw. completely forgot to mention: Thanks for raising your (absolutely valid) concerns and for participating in this discussion. This helps to understand the various use cases of the end user and to make such a functionality working as expected.
Update on this issue, since my last reply, we have added to the current development branch:
expand_vhosts preference, when set to ‘yes’, scanner collects new vhosts values for the target IP from different sources such as reverse-lookups, NVTs (eg. fetching hostnames that match the IP from SSL certs etc,.) . Setting it to ‘no’ disables this behavior.
You can now exclude scanning of specific hostnames/vhosts by adding them to the “exclude_hosts” preference.
Will this be a per-target-preference, e.g. to be set within the <create_target> command of omp/gmp?
exclude_hosts is not relevant in this respect as the user then needs to know which hostnames to exclude. My concern is with hostnames connected to the IP in question, that the user does not know about beforehand and does not want to scan.
exclude_hosts is not relevant in this respect as the user then needs to know which hostnames to exclude.
While it doesn’t match the case you described above (as you didn’t know in advance,) it is still a valid use case. Note that when you don’t have full information about your environment (but still want to use these features), you can always start with a conservative empty/discovery scan before attempting a full scan.
Will this be a per-target-preference, e.g. to be set within the <create_target> command of omp/gmp?
This is still undecided to be honest. I personally think that clattering Targets with further per-target preferences is not a good idea, but others may have a different opinion. A config preference as currently implemented, seems more appropriate to me.
I would say a “per-target setting” or per “scan-policy setting” should be the prefered choice for this feature.
A “per server setting” should be out of the question, as it is easier for the user to enable/disable this feature in his scans while configuring the target and/or choosing a scan config to use, as opposed to reconfiguring the server and restarting.
Scanner preferences (which you set in the .conf file) are overriden by values from scan configs’ “Scanner Preferences”. No need to reconfigure/restart, just change the value in the scan config.
