Avoiding implications of scans - best practice?

Hey everyone :slight_smile:

When performing network scans, how do you cope with systems of the network going down and being unable to respond?

There is a lot of implications that we face in client networks - some of which have already been pointed out here - but usually our clients are getting locked out from ESXi, vSphere and similar tools due to account lockout. Commonly smaller network devices and servers such as IP phones, are probably simply overloaded by the scanners’ task and refuse to respond/are only available again after a restart.

We want to make the security scans as convenient as possible for administrators of client networks, so we are looking for ways to reduce negative implications of security scans.

Do you have any experience you can share how to avoid running into account lockouts, downtimes, unresponsiveness etc?
We are experimenting with using 4 NVTs per host and 1-3 hosts at most.
Also we are splitting the networks into smaller segments and distribute evenly over a set time frame.

I hope to get some insight here!

As this question is not directly related to a specific NASL script (or its results) which the Vulnerability Tests category is about and more about scanning strategies i have moved it into the Security Processes category (About the Security Processes category) which seems to better fit.

2 Likes

Devices are not only closing logins down due to the sheer amount of tests (as you rightfully suggested) , but sometimes also because they very specifically don’t like the brute force login tests for common user/password combinations.
You can switch them off by cloning your scan config.
Then open the preferences of the VT “Options for Brute Force NVTs” (OID: 1.3.6.1.4.1.25623.1.0.103697) of the clone via:
Edit Scan-Config > Family=Settings - Edit Scan Config Family > Name=Options for Brute Force NVTs - Select and Edit NVT Details

Here you can change the preference so that no brute force checks made by any vt in this config.

Please be aware, that no security risks by commonly used username / Password combinations will be found anymore.

2 Likes