When we run our initial scan at Full and Fast, it triggers multiple root lockouts due to repeated failed attempts
We manage quite a few network devices, so this creates a real problem when we do require root access again.
I’ve spent significant time trying to find where to fine tune the scan, but I essentially need to ask the scanner to “try root twice and then move on.” Once it ticks over the third time, we encounter the lockouts
Can someone kindly point me to where I might reign in the number of attempts per credential?
Does this question betray a fundamental misunderstanding of what the vulnerability scan is all about? I see several views and still no responses so maybe this isn’t a feature of the product?
Seems you might check your lockout strategy first. Seems to be quite easy to perform a DoS attack on your root users which an attacker might do first…
That said, you might exclude the “Default accounts” family and set the preferences in the NVT “Options for Brute Force NVTs” (OID: 1.3.6.1.4.1.25623.1.0.103697") like “Disable brute force checks” and “Disable default account checks” to “yes” to disable such account checks.
However, as I said, I strongly suggest to revise the lockout settings on your devices first…
There is no such configuration to limit the amount of password tries for each account. The simple rationale is:
If you’re limiting the amount of login tries for each account to e.g. “3” and there are devices (maybe not even known to you / the scanning operator) in the environment which have a default password for such an account down in the list you would completely miss this vulnerability.
Instead of limiting the scope of vulnerability tests / checks the scanner is doing it is strongly advised to revise your lockout strategy as pointed out above.
A common recommendation is to not do lockouts of an account globally but rate-limit or even block the login tries based on the Source-IP of the remote device and add the scanning machine to the white list to not getting blocked.
Really great responses from you both - they are greatly appreciated and I will take these recommendations back to my team who are far more knowledgeable than I am. Hopefully, we can use this insight to improve our policies, as you’re suggesting
Alright - after gaining some understanding from my team, your points are well made and without doubt, we need to examine our lockout policies and make some better decisions on that, and that is the long term goal.
In the intermediate, it seems the aim would be to try and modify certain vulnerability scans to exclude SOME targets (the lot where we are having the lockout issues)
Is there any easy way to exclude SOME of our targets from SOME of the scans?