Why the scan becomes slower when its progress reaches to 99%?

hi all,

I have been using openvas-scanner with v21.4.4 for one year.

But every time the scan progress reaches to 99 percent, the scan will become much slower,especially if task has large number of hosts.

Would you kindly help explain what happened or give me some suggestions for optimization.

Thanks for your time in this great project.

Hello and welcome to this community forum.

I’m usually seeing such (assumed to be) “stuck” scans at 99% progress at the end of the scan because there are still long running VTs like e.g. SSH login brute force or HTTP ones running which might take a good amount of time to finish.

Background: AFAICT the progress bar / percent is based on the still to be scheduled / launched VTs because the software stack / component responsible for this calculation has no prior knowledge how much time a VT would take to finish (some might be finished in one second while special ones like the SSH login brute force one is allowed to run for 15 Minutes).

3 Likes

I really appreciate your assistance!

1 Like

I’m still thinking that there is a real error in the scanner. Some of the tasks that used to take 2 hours to complete are now taking more than 6 hours, and they won’t stop.

I had the same problem as you. During last 1% progress, besides running some long time VTs, maybe there are still some other process, I think.

As a reference, what the scanner is currently / actually doing can be checked on the scanner host with something like e.g.:

ps auxwww | grep "[o]penvas: testing"

I hope this report will help.
I have noticed this behavior happens when openvas tries to scan a smartTV with LGwebOSTV and it comes to be shut off during the scan. I’m not sure if the same thing happens even while a full scan is run against a different device and it comes to be “off” while the scan task runs.
When is “off”, the smartTV is still connected to the network (so it goes in a “suspend” state, and this is when I noticed this behavior)

These are the running processes that hang up:

root      617897  0.2  0.1 238944 27048 ?        SN   nov18   2:56 openvas: openvas: testing 192.168.0.11
root     1188155  0.0  0.1 238944 23576 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (rbs.nasl)
root     1188156  0.0  0.1 238944 23576 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (eyeos_command_execution.nasl)
root     1188158  0.0  0.1 238944 23576 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (secpod_eyeos_php_files_info_disc_vuln.nasl)
root     1188160  0.0  0.1 238944 23576 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (gb_ezblog_sql_injection.nasl)
root     1188161  0.0  0.1 238944 23252 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (rbs.nasl)
root     1188162  0.0  0.1 238944 23252 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (eyeos_command_execution.nasl)
root     1188163  0.0  0.1 238944 23252 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (secpod_eyeos_php_files_info_disc_vuln.nasl)
root     1188164  0.0  0.1 238944 23396 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (rbs.nasl)
root     1188165  0.0  0.1 238944 23252 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (gb_ezblog_sql_injection.nasl)
root     1188166  0.0  0.1 238944 23376 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (eyeos_command_execution.nasl)
root     1188167  0.0  0.1 238944 23376 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (secpod_eyeos_php_files_info_disc_vuln.nasl)
root     1188168  0.0  0.1 238944 23376 ?        SN   09:01   0:00 openvas: openvas: testing 192.168.0.11 (gb_ezblog_sql_injection.nasl)

If I turn on the smart TV the scan task goes on.

Openvas is openvas-scanner-22.7.6 built from sources on gentoo.

Scan configs and many of the NVTs have configuration settings that can be adjusted. Timeout and connection attempt thresholds in particular may alleviate the symptoms of your problem. If the scanner is going through a long list of say, credentials to test, and the device is not responding, it may take a long time for the timeout to be reached each time the test runs. I guess that timeout settings are fairly liberal by default to allow for poor network conditions.

Perhaps try:

AFAICT this is the expected default behavior of the scanner for this case and might be indeed also a reason why such supposedly “stuck” scans are seen (which are actually just slow due to the previous mentioned timeouts which needs to hit first). But in this case the scan could stay on an arbitrary percentage / progress and not only at 99%.

When using Boreas and version 22.04+ of the scanner the following:

max_vts_timeouts

During a scan it might happen that a host unexpectedly shuts down, a firewall blocks the traffic, a network device issue break the connection, etc. This leads to many VT timeouts and long scan durations. This option checks the alive status of the host again after the provided amount of max VT timeouts are reached. If the host is considered dead the scan will be stopped for this host. Otherwise the scan will continue. This option requires Boreas alive test to be enabled. Default: option not set, disabled.

seems to be available since:

as a scanner preference which can be configured as desired (in e.g. the openvas.conf).

On a related note:

has also extended some reporting recently which makes the state of a scan more clear in the GUI.

1 Like

Does the ‘max_vts_timeouts’ function work when the Boreas alive test option is enabled?
Could you please provide instructions on how to enable the Boreas alive test option?

Unfortunately i don’t have specific insights in the use of Boreas and this max_vts_timeouts, how it is/can be used or configured so i’m not able to give additional guidelines outside what have been provided previously.