How do I handle a host or service crashing when scanning?

Document created by kb-author-1 Employee on May 19, 2010Last modified by eschamp on Jul 15, 2010
Version 7Show Document
  • View in full screen mode


During the mapping or scanning process, the host being scanned seems to have crashed. How should I handle this?


QualysGuard scans should never have a detrimental effect on your network and we take this issue very seriously. We are eager to work with you and any third party vendor to quickly isolate and resolve these problems for you.

Please open a case with Qualys Technical Support, if you haven't already done so, and follow the guidelines below. To open a ticket we recommend doing so within the QualysGuard user interface. Navigate to Help > Contact Support. This will create a case with all of your pertinent subscription information.

Since we do not have access to your network or your QualysGuard subscription we will need you gather as much information about the affected host and scan.

- Description of the symptoms

- Steps to reproduce the issue

- When did the issue first appear?

- Is it reproducible?

- A copy of the scan results from the scan that caused the issue

- Detailed information  about each affected machine, including

     * OS version and patch level

     * IP address

     * its primary function

     * its place on the network (behind firewall, in DMZ, behind load balancer...)

- Detailed information about the affected service, including

     * software name

     * exact version and build or patch level

     * port # the affected service is running on (static or dynamic port?)

-  Packet capture of traffic from/to the affected service/port of its normal/typical communication

     - On Windows, run the free  tcpview.exe - - and  save the output

     - On Linux, run netstat -anp and save the output

     - On other Unix derivatives, the precise syntax for netstat may differ, although netstat -na appears to work at  least on BSD flavors and AIX. If 

       unsure, consult the "netstat" manpage.

- Any additional information you may find important or useful such as  screenshots, log files, etc.

The more information, the quicker we will be able to analyze the cause for the issue and help resolve it.

Once we receive this information, we will escalate this as a top priority to our development team for investigation.

Our goal is to identify the root cause of the problem and either correct it if it is something that we are doing incorrectly, or work with the vendor of the affected product if it looks like it needs to be addressed from their end. To that end, we would also recommend that you to log a case parallel to this with the relevant vendor.

Most problems we experience of this nature are due to insufficient input parameter parsing in the application. QualysGuard will usually try a best effort guess based on the port for any encountered service, for example testing the existence of an HTTP enabled service on port 80 by issuing a GET Request. If the result of this request is negative, we will then attempt to gauge the nature of the service by issuing standard requests for well known services, for example an SNMP community request to determine if the service is SNMP.

A given service should usually respond with an error or a "request denied" status and not proceed to parse the request if it is unknown. This often indicates susceptibility to a denial of service attack, because a would-be attacker would be able to cause the service to misbehave by entering nonsensical data.

In the meantime so that you are still able to use QualysGuard to further ensure the security of your network, you can add the affected IP(s) and/or Service(s) to the "Blocked Resources" section on the Advanced tab of the scan option profile.

If you have any questions, please do not hesitate to email or call our Technical Support Team.

Qualys Support KnowledgeBase

ID: 0001.001.613.000