meaning they aren’t as likely to cause problems with the target systems. This does
mean that some checks won’t get run, and they may be the checks that test the very
vulnerabilities you are most concerned with. After all, if just probing for a vulnerabil‐
ity can cause problems on the remote system, that’s something the company you are
working with should be aware of.
Figure 4-10. Scanner preferences
Vulnerability scanners don’t necessarily exploit vulnerabilities. However, just poking
at software to evaluate its reaction can be enough to cause application crashes. In the
case of the operating system, as with network stack problems, you may be talking
about crashing the operating system and
causing a denial of service, even if that’s not
what you were looking to do. This is an area where you need to make sure you are
clear up front with the people you are doing the testing for. If they are expecting clean
testing, and you are working in cooperation with them, you need to be clear that
sometimes, even if you aren’t going for outages, outages will happen.
Safe Checks is a
setting to be careful of, and you should be very aware of what you are doing when
you turn it off. Safe Checks disables tests that may have the potential to cause damage
to the remote service, potentially disabling it, for instance.
Although you can also
adjust additional settings, after you have set your scan config‐
uration and your targets, you are ready to go. Before you get started here, you may
want to consider setting some schedules. This can be helpful if you want to be work‐
ing with a company and doing the testing off-hours. If you are doing security testing
or a penetration test, you likely want to monitor the scan. However,
if this is a routine
Remote Vulnerabilities | 133
scan, you may want to set it to run overnight so as not to affect day-to-day operations
of the business. While you may not be impacting running services or systems, you
will be generating network traffic and using up resources on systems. This will have
some impact if you were to do it while the business were operational.
Let’s assume, though, that you have your configurations in place. You just want to get
a scan started with everything you have configured. From here, you need to go to the
Scans menu and select Tasks. Then click the New Task icon.
This brings up another
dialog box, which you can see in
Figure 4-11
. In this dialog box, you give the task a
name (not shown in screenshot), which then shows the additional options, and then
you can select your targets and your scan config.
You can also select a schedule, if you
created one.
Figure 4-11. Creating a new scan
On our simple installation, we will have the choice of a single scanner to use. That’s
the scanner on our Kali system. In a more complex setup, you may have multiple
scanners to select from and manage all from a single interface. You will also be able to
select the network interface you want to run the scan on.
While this will commonly
be handled by the routing tables on your system, you can indicate a specific source
interface. This may be useful if you want all of your traffic to source from one IP
address range, while you are managing from another interface.
Finally, you have the choice of storing reports within the OpenVAS server. You can
indicate how many you want to store so you can compare one scan result to another
to demonstrate progress.
Ultimately, the goal of all of your testing, including vulnera‐
