A few days ago I downloaded the virtual CGE 6.0.2. I have successfully performed a scan on an internal /24 subnet and the feed status is current.
Now I am trying to scan a public subnet for a different Company site, but I cannot get the scan to continue on these IPs, which do not respond to “pings”. I found someone else posting this same issue, but I do not understand the justification posted in that thread for it being closed without answer, so I ask in a new thread with more details.
My target is setup as:
Hosts: publicIP1,publicIP2
Port List: All TCP and Nmap 5.51 top 1000 UDP
Alive Test: Consider Alive
My scan to this target is setup as:
Scanner: OpenVAS Default
Scan Config: Full and fast
When watching on my firewall for traffic at the OpenVAS scanner site, I only see the OpenVAS VM trying to ping the target IPs and nothing else. And then the scan stops.
However, when I create a special rule on the destination side to permit ping from the public IP address the scan comes from, then the scan does proceed and I’m seeing the many, many ports all being scanned.
Am I missing a step to permit the scan to proceed even if the destination hosts will not respond to a ping? I thought it was the “Consider Alive” setting on the target, but perhaps I have missed something?
Also GOS 6.0.2 seems to erroneous require some ping response even if “consider alive” is selected. We are currently working on it. Check future release notes for possible fixes.
Workaround for the target’s “Consider Alive” setting being ignored:
Change the setting of VT “Ping Host” (OID 1.3.6.1.4.1.25623.1.0.100315, family “Port Scanners”) in your scanconfig to:
“Mark unrechable Hosts as dead (not scanning)” = “no”
Use with care, as this will initiate a scan of any given target, regardless of its response. This can cause very long scan duration without yielding sensible results.
That is true, but as I wrote, the scan does work fine if I update the remote firewall to permit ICMP echo on the target side. Thus it’s not an issue with the NGFW on the scanning side
Of course I appreciate your point. Indeed, due to the extra processing the NGFW performs for some protocols, such as TCP/5060 for SIP, the firewall on the scanning end actually did ACK the SYN to the scanner on some ports in spite of the target not ACK’ing the SYN. Hence a port open false positive on the scan by no fault of OpenVAS.
So yes, not an optimal scanning situation. Of course I could update the NGFW on the scanning side to exempt the scanner IP address from deep inspection, but for now it’s more a POC/demonstration point, so just keeping it simple for now.
Hi Tino! Thank you very much for confirmation there is an issue with the “consider alive” feature on this GOS version. No code is bugfree. In the scope of things, that’s a fairly minor issue in our situation. Working around it by permitting ICMP echo for the scanning IP is hardly the end of the world
Thanks! I didn’t notice yet if there is “vi” or some other editor in the VM shell, but instead I cloned the scan config I wanted to use in the WebUI and edited this property and then updated the scan task to use this new scan config. That is a nicer work-around then permitting ICMP echo on the destination firewall for the scanning IP.
And understood it would create very long scan times when hitting a range of IPs that are truly dead. This is for targeted scans to IPs known to be alive but do block “pings”.
