2

I'm currently scanning a network using OpenVAS / Greenbone Security Assistant installed on Kali Linux.

During the scan, multiple targets have crashed. This is obviously something I want to investigate. As I'm running the "Full and fast" scan profile, 65238 NVTs are being run against each host. Unfortunately, OpenVAS does not (and probably cannot) realize, if a target has crashed.

  1. How can I find out, or at least narrow down, which NVT caused the crash? Are there options other than binary search?
  2. Does OpenVAS run the NVTs in consecutive order or is the order randomized?
  3. OpenVAS does not seem to log, which NVT was run at which time, so I cannot correlate the time (which would only give me a rough time-window, anyways). Can I activate this somehow?
cfischer
  • 302
  • 1
  • 9
Niklas
  • 73
  • 7

1 Answers1

2
  1. Can / will be answered with 3. together below.
  2. To the best of my knowledge it is a mixture of both. The internal scheduler of OpenVAS is scheduling and launching VTs based on a dependency chain (e.g. VT y.nasl depends on VT x.nasl) so the VT get consecutively launched depending on this dependency chain. But then again the order depends on at which time the previous dependency got scheduled an launched. In turn this means the order on subsequent scans might be a different one because a specific dependency had a different run time (e.g. slower responding target caused a longer run time of the dependency or any other in the chain, newly added VTs in the dependency chain, ...) causing a different running order then in the previous scan.
  3. OpenVAS is capable of logging each scheduled and launched VT in it's logfile (openvas.log, should be at /var/log/gvm/openvas.log on Kali). You can enable this logging by setting log_whole_attack = yes in your openvas.conf (Location can bee seen with openvas -s | grep config_file). If the file doesn't exist you can create it manually and add just that string to it. Note that the extended logging might fill up your disc space so only enable the logging during your debugging work and disable it afterwards.
cfischer
  • 302
  • 1
  • 9