Scans, Preflight checks, and Network errors

A preflight check runs at the beginning of every scan to determine whether the target within the scan scope is responsive. Depending on the result of the preflight check, Acunetix will either abort or continue with the scan; one such check is simply an attempt to connect to the Target's web server. If any of the critical initial checks do not pass, the scan fails immediately.

How preflight check works

In the first stage of the preflight check, the Acunetix scan engine tries to connect to the primary target with the defined agent (managed by Invicti in cloud, or internally hosted agent). If the primary target is not responsive, the scan will abort, resulting in a 'Could not connect' message in the Scan detail. If the primary target is responsive, the preflight check continues by trying to connect to the other targets (Allowed hosts) within the scan scope. If any additional target is not responsive, that target is removed from the scan scope, and the scan will continue with a warning message added to the scan logs.

Once the Acunetix scan engine has successfully connected to the target, it assesses the response from the target to determine how the scan will proceed. Three main response status codes influence this: 2XX, 3XX, and 4XX or 5XX. It is important to understand what each of these means and their impact on the scan results. The next section of this document explains more about these response status codes.

The preflight check also tests whether the SCA server is reachable. If Acunetix Online Services is enabled in your Acunetix On-Premises instance, then a health check to https://sca.acunetix.com/api/v2/healthcheck is made, and a warning message is raised if the check fails.

You can find more detailed information about Scan statuses and the various information, warnings, and error messages here.

How are Network Errors Counted?

If a running scan encounters 25 consecutive network errors, the scan is aborted. The network errors need to be consecutive, meaning that if the Acunetix scanner encounters 21 consecutive errors, and the 22nd request is successful, then the network error counter is reset to zero and the counting starts again. Below we discuss some of the finer points of what is counted as a Network Error, and what is NOT counted as a Network Error.

Not Counted: HTTP Error Response Codes

In particular, HTTP Error response codes received from a Target are NOT considered to be Network Errors. Any 4xx and 5xx error responses will simply be processed according to the scanner's rules and the scan will proceed as normal. You should keep in mind that the scanner makes a number of requests to the target using awkwardly built requests (payloads) to make sure the web application is able to process such malformed requests correctly and it is commonplace for a web application to respond with a 4xx or 5xx message to badly-formed requests.

Not Counted: AcuMonitor Missed Responses

Some vulnerability checks require out-of-band communication with the AcuMonitor service. Network errors resulting from requests to the AcuMonitor service during the scan are NOT counted and will not cause the scan to be aborted.

Not Counted: Special Checks where Failure is the Expected Result

Some vulnerability checks will, by design, not successfully connect (or will not receive a response) if the vulnerability is not present. Therefore, such connection failures or missed responses are also NOT considered Network Errors.

Counted: Critical Network Errors

Some types of Network Error are considered critical for the scan, and therefore such errors are counted.

The most common types of such Network Errors are Connection Resets, and Socket or SSL Errors.

Counted: Connection Timeouts

Another critical error scenario is a Connection timeout. If the scanner's network layer sends a request to a Target and a response is not received within 30 seconds, then the network request "times out" and such an event is counted.