Scanning web sites and web-based applications for vulnerabilities can take a long time time to complete. The following may affect the scan time:
- Web server performance and response time
- Size of web site
- Back-end database speed
- Number of simultaneous connections by the scanner
- Number of vulnerability checks
- Acunetix server performance
Slow scans can get in the way of reports being delivered on time, preventing developers from moving onto other projects. There are several steps that can be taken to limit the time a scan takes, and in general to save time while using Acunetix Web Vulnerability Scanner (WVS).
1. Break the scans down into a smaller more manageable size
When going through the New Scan Wizard in the advanced section there is the option “After crawling let me choose the files to scan”. When this option is selected, after the crawl is completed, it is possible to select what is or is not scanned.
Read more information specific to Template based sites.
2. Save the crawler data and re-use it
Crawling a large web-based application can in itself take a lot of time, before even getting to the scan. The structure of most large applications doesn’t change often so there is no need to crawl a site every time a scan is performed. That being said, once the initial crawl is completed, select “Web Scanner” from the left hand column and right click on “Site Structure” and save the .cwl file for future use.
The next time the site is scanned using the Scan Wizard, the crawler file can be imported, eliminating the time it usually takes to perform a crawl.
3. Select specific scan profiles
When scanning there isn’t always the need to run a full “Default” scan on an application. Acunetix Web Vulnerability Scanner allows you to choose a profile in order to focus on a specific type of vulnerability, if there is something specific that needs to be tested. This is convenient when a development team is verifying they have fixed a particular type of vulnerability such as Cross Site Scripting or SQL injection throughout the application.
4. Don’t rescan the entire application, retest specific vulnerabilities that have been fixed
When confirming a particular vulnerability has been fixed, there is no need to run a full scan. That individual alert can be retested by right clicking on it and choosing “Retest alert(s)”
5. Monitor the average response time
A common reason for slow scans is the average time it takes for a server to respond to a request made by Acunetix. A good average response time is roughly 200 milliseconds. The response time can be determined by clicking on ‘Scan Thread 1’ at the very top of the scan results and then opening the ‘Statistics’ tab on the right hand side pane.
There can be a number of reasons for a high average response time, including:
- Network connection or infrastructure issues between the Acunetix Web Vulnerability scanner and the web application
- Application server overload
- Low server specifications, RAM, slow hard drives, network card issues, etc.
- Shared hosting environments are generally slower than dedicated servers
Find out more detailed information on how response time effects a scan
6. Monitor the number of parallel connections
It would seem as though the more parallel connections you have connecting to the application the faster the scan would run, though this is not always the case.
By default Acunetix WVS scans web applications using 10 parallel connections. This can be modified based on the load that can be put on the web application. If the server itself can handle a larger number of requests, then this number can be increased incrementally producing faster scan times. If the server is finding it difficult to handle 10 connections and the applications performance is decreasing, then parallel connections should be lowered to take some load off the server. This should result in a faster scan time.
The number of parallel connections can be configured in Configuration → Scan Settings → HTTP Options
!! Important note !! This should only be increased if the application server can handle the high number of requests generated by Acunetix. If it can’t, this could potentially significantly slow down a scan or the application performance itself or possibly cause a DoS.
7. Use the scheduler to scan during off peak hours
It is not ideal to scan a site when it is being used by users. The scan might affect the users’ experiences, and the scans will take longer. In order to avoid this, you can schedule the scans to run automatically during off-peak hours using the built-in scheduler.
First configure the excluded hours by going to Configuration → Application Settings → Scheduler. Scroll down to the Excluded Hours Templates, and verify that you can use one of the default Excluded Hours Templates. You can also create a new template if needed.
Next proceed to the Acunetix Scheduler from Tools (menu) → Scheduler which opens the Scheduler’s web interface in a browser. Proceed to creating a new schedule (or select an existing one), and from the “Advanced options”, select the Excluded Hours.
The scheduled scan will be automatically paused during the excluded hours, and will automatically resume once the period covered by the excluded hours has elapsed.
A scan might take some time to complete depending on a number of factors, as seen above. With these suggestions being put into place, scanning performance will improve.