WebInspect Connectivity issue, Reason ServerConsecutive - scan 'pauses'
I'm scanning an environment just now, where I am repeatedly hitting connectivity issues, that cause the scan to pause.
The error message is:
Connectivity issue, Reason: ServerConsecutive, Server:<ip address>:80, Error:(100) Unable to parse WebServer response: Unable to read data from the transport connection: A conection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I've looked at the traffic log, and I can see large numbers of 'POST' messages, but I cannot see responses in the traffic monitor, so I assume after a specified number of 'no responses' the scan will halt.
I tried modifying some settings, to perhaps even get the scan to pause more quickly in this scenario (although this could be detrimental in that I may have made it more prone to stopping now, as less responses are needed to trigger this action). I modified:
Consecutive 'single host' retry failures to stop scan from 50 to 10
Consecutive 'any host' retry failures to stop scan from 150 to 15
Is there anything I can do to prevent the scan 'pausing', as obviously I want to complete the scan as quickly as possible?
Is there anything I can do to prevent the error in the first instance? Is this a software issue?
I've attached a depersonalized sample 'POST' message that got no response.
Your thoughts to change the Consecutive Timeout Counts is correct, but does not address the underlying issue. If you simply turned off that auto-Pause feature, then WebInspect would just send all its probes regardless of any response, assume there were no vulns found, and "complete" the scan. The true issue is that you are not getting HTTP REsponses, which is what the auto-Pause has brought to your attention. There may be several reasons for this, but they are network related.
- The target server is getting over-loaded. Perhaps it cannot handle the Request load it is receiving, or its memory is filling while holding the request states. Check the Requestors scan settings panel. By default, WebInspect 10.50 runs with 5 threads of Crawl and 10 of Audit. This is akin to one user logging in from 15 browsers at once, making new Requests as fast as the server sends back Responses. You might find that lowering these threads to something like 2 and 6 or 1 and 5 helps this situation.
- Some other network lag may be a factor, especially if the target is not in the local LAN or country. Check the Requestors scan settings panel. You might find it beneficial to increase the Request Timeout.
- The traffic is being hampered by a network proxy. By default WebInspect assumes it will use whatever proxy has been configured in MSIE in order to reach the scan target. Check the Proxy scan settings panel. You might be able to set WebInspect to "Direct Connection", by-passing any middleman.
- Perimeter or network defenses may be interfering. IDS or WAF frequently view WebInspect traffic as malicious and drop the offending Requests, sometimes without any proper FIN back to the WebInspect machine. check with your network admins to see if this might be the case. While you have their ear, see if there might be a HIPS on your WebInspect machine that could be too restrictive, and see if they can edit its configuration to permit the WebInspect programs fully.
-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify
Another suggestion is to enable Traffic Monitor in your scan settings. In real time, or after the fact you can then see what happened to each of the requests that were sent out as part of the scan. You may see that some requests did receive a response and the response may give you some cluse as to what the issue might be - for example a throttling proxy could be limiting the amount of traffic it is allowing through from your system.