So on the weekend I had only 1 host with this QID , now come Monday on the new scan criteria, I have 36. Has anyone else seen this? My sysadmins look at this and say, there is nothing to go on, how am I supposed to fix this?
Any ideas?
So on the weekend I had only 1 host with this QID , now come Monday on the new scan criteria, I have 36. Has anyone else seen this? My sysadmins look at this and say, there is nothing to go on, how am I supposed to fix this?
Any ideas?
The ‘Exhaustive Web Testing Skipped' or "Server Stopped Responding" vulnerability on your Scan Results means that we were not able to complete the PCI Scan since the service stopped responding during our scan. Per the PCI Council, we must complete the scan in order to issue a passing status.
There are 2 main causes for the scan not completing:
It is first recommended that you try scanning the server using the low bandwidth options in your QualysGuard Account. If the scan is still unable to complete, there most likely is some type of networking device or host based software that has DOS Protection that is acting against our scan. The PCI Council has stated that these types of devices should be set to monitor and log, but not act against the ASV’s PCI Scan. Once you identify the device you can white list the Qualys SOC IP Addresses as listed below.
Qualys Secure Operations Center (SOC)
64.39.96.0/20 (64.39.96.1-64.39.111.254)
62.210.136.128/25 (62.210.136.129-62.210.136.254)
167.216.252.0/26 (167.216.252.1-167.216.252.62)
Additional Notes:
-An additional option provided by the PCI Council in these situations is to scan from a different network location, inside your network, which can help to limit the scope of scanning. In this case you could launch a 2nd scan from a QualysGuard Internal Scanner Appliance, which could eliminate other devices in-between the scan, such as your perimeter firewalls or IPS/IDS, that could be the source of the interference. If this scan completes successfully and finds no vulnerabilities, then Qualys Support can leverage these results to accept the previous ‘stopped responding’ vulnerabilities as a PCI False Positive.
Same issue here. Nearly every target of our customers is affected by this issue. Definitely no IDS/IPS or bandwidth issue. The problem exists since Friday, after the rollout of new QG release...
As of September 13th we have deployed a fix for this issue. If you experienced this problem we recommend rescanning using the lowest scan settings for bandwidth if you are using QualysGuard PCI or if you are on QualysGuard setting your option profile scan performance to custom 1 total process, 1 HTTP process, Packet Delay to long. Note: this will increase scanning time, please use only in cases where the Low setting still fails.
Thread was edited by: Robert Dell'Immagine to remove an auto-reply message that wasn't caught by the auto-reply filter.
Engineering is looking at this right now to see if there is any issue with this detection since the PCI changes recently.
Sumedh
We have identify a potential issue with scans run with a certian bandwidth level and are actively working to fix this soon.
Sumedh
Is there any conclusion on this? My PCI scanning is due and this is not going away. I tried the above methods (low bandwidth scan, IDS/IPS exceptions) and nothing seems to work.
I am getting this same issue with one or clients. We tried low bandwidth settings and then tried to run the scans,...didn't work and further tried whitelisting scanner IPs on ASM module as it was blocking our scans....still getting "Web Server Stoppred Responding" I know using scanner appliance works however that is not feasible at this moment, since I am just running PCI scans.
Please suggest how this issue can be resolved?
Thanks,
Srinivas
This QID is typically caused by a couple things:
1. Anemic devices (e.g., slow web-servers, network devices, etc). The fix is generally to lower bandwidth settings as you had described.
2. Active blocking (e.g., bandwidth throttling, IPS, etc). The fix here usually involves white-listing, but figuring out *where* to white-list can be a challenge.
My suggestion would be to review the network topology from the appliance to the target. If possible, move the appliance to the same subnet as the target -- eliminating as much of the network as possible -- in order to help localize the problem. Additionally, you may consider doing packet captures, which might allow you to see if a device with IPS functionality is -- for example -- sending RSTs on behalf of the target.
If we use internal scanner and run the scan on public facing IPs. Will it replicate same scanning as we do externally. I am guessing number of vulnerabilities found would differ in each instance.
1. I scan A host externally and receive "web server stopped responding"
2. I again scan A host but this time using internal scanner and scan comes back clean. Can we consider this issue as false positive.
Thanks,
Srinivas
Hi Srinivas,
Re: replicating external testing:
- Generally speaking, internal tests tend to be more accurate, as we have additional visisibility into the target.
Re: false positive:
- The fact that you can scan from the inside suggests that some external device is throttling the scan traffic (e.g., firewall or load-balancer), purposefully or not. It's not likely a false-positive.
Thanks,
:Chris
Thanks Chris,
Is there any manual way of detecting this issue? I know we can do packet capture and see if there any IPS functionality in place or not.
I tried changing performance settings in express portal and re-ran the scans, but got same results.
Thank you,
Srinivas
Hi Srinivas,
To both a QualysGuard scan as well as manually testing, the network is somewhat abstracted. All we can see is that we send in a number of packets, and at some point, stop seeing the expected responses.
In order to troubleshoot, it generally takes a little bit of work: Logging into the intervening devices...checking logs...moving the appliance around to take specific devices out of the equasion, etc.
Hope this helps,
:Chris
I'm not sure what has changed but we have seen a major increase in these "webserver stopped responding" vulnerabilities in the last month or so. I have considered that this could be a network issue on our side but I'm thinking not now because we have 15 scanners deployed in completely different environments and they are all seeing an increase in this particular vulnerability. I hope somebody can take a second look at this. I'm looking at a recent report showing 1000 instances of this vulnerability against some VoIP phones. This a new phenomena - haven't seen this in the past and I'm tempted to write the whole thing off as a giant false positive. I am able to pull these same phones up in a browser and refresh repeatedly w/o issues. This vulnerability has climbed it's way into our top 15 list and I know for a fact that this can't be the case. If our environment was that fragile, we would be in big trouble.
Thanks for reporting this Heller, could you contact Qualys Tech Support so we may fully investigate? You can email us at support@qualys.com
I'm in the process of running some reports right now to support this.
I'll send to support.
Thank you.
Very much appreciated!
That does not fix the issue since the scanner is using only the ip address and the target only responds to a specifically formatted URL, ie, absolute url. Any incorrect input is rejected and the site deliberately stops responding to the incorrectly formatted url. Example: scan-1.2.3.4, output is 'webserver stops responding', but when inputting '1.2.3.4/directory/specificdirectory', the site responds. Since the scanner cannot accept any url as input, this is an ongoing issue.
As of September 13th we have deployed a fix for this issue. If you experienced this problem we recommend rescanning using the lowest scan settings for bandwidth if you are using QualysGuard PCI or if you are on QualysGuard setting your option profile scan performance to custom 1 total process, 1 HTTP process, Packet Delay to long. Note: this will increase scanning time, please use only in cases where the Low setting still fails.
Thread was edited by: Robert Dell'Immagine to remove an auto-reply message that wasn't caught by the auto-reply filter.