Which NVT is causing Vmware ESXi to lock Login

Hello,

i have the problem that some kind of NVT runs default username/password combinations against our ESXi Servers https login page (i think so, ssh is disabled).
This would be OK but after several failed trys the ESX Server locks the login for all users, which is the reason i want to disable this NVT.

i already run some tests where i disabled the whole “Default Accounts” “VMware” and “Brute force attacks” NVT family. but the issue still occurs. can someone point me to the NVT which causes this behaviour ?

we are using this docker repo:
https://hub.docker.com/r/mikesplain/openvas/

Thanks in advance.

Hi,

you can set the log_whole_attack setting in your openvassd.conf (location depends on your installation) to yes to get a logging of each launched VT and its launch time into your openvassd.messages (GVM-9) or openvassd.log (GVM-10+) (location for both depends on your installation as well).

For a description of this setting see man openvassd or:

https://github.com/greenbone/openvas-scanner/blob/openvas-scanner-5.1/doc/openvassd.8.in#L78-L79

1 Like

Hi,
I have the problem also to find the NVT that causes this lock out. Did you find a solution at that time?

Try to remove
Mark host as dead if going offline (failed ICMP ping) during scan - Phase 5 and
Mark host as dead if going offline (failed ICMP ping) during scan - Phase 6

2 Likes

Hi,

Could you maybe elaborate where to remove this config?
The only thing related to this setting I can find is inside the “Global variable settings” OID 1.3.6.1.4.1.25623.1.0.12288 in the scan configuration. And there I can just set it to “no” and “yes” which neither of these prevent the log-in attempts from happening on the ESXi side.
I’ve already disabled the whole “Brute force attacks” and “Default Accounts” families, as well as ticked “yes” on the “Disable brute force checks” and “Disable default account checks” in the “Options for Brute Force NVTs” Settings (OID: 1.3.6.1.4.1.25623.1.0.103697), but none of these options prevent the login and thus the account lockout from happening on the ESXi side.

You need to modify it in the scan configuration.
Clone existing Standard scan profile and in Service detection category you need to un-check those 2 tests

1 Like

Thanks, it worked without problem. No failed log-ins are registered on the ESXi server anymore.

Unchecked and every time I run the scan, the root accounts get locked :frowning:

Interesting… making those changes doesn’t change the outcome for me.

What kind of scan configuration profile are you using ?

A modified full and fast.

Sample attached. scanconfig.xml (355.3 KB)Processing: scanconfig.xml…

Just to have it mentioned:

I would suggest to solve this by configuring the ESXi host in a way that it doesn’t lock out accounts in general but do the locking based on e.g. the IP of an attacker (if that’s possible) or whitelist the scanner IP address in some way.

The rationale behind this suggestion is simple, everything what is triggered during a scan with GVM can be triggered by an attacker as well. In this case an attacker could permanently lock out the “root” account (or also others) making it impossible for an administrator to login into the ESXi host.

In addition if you’re “weakening” the scan config to not do default account checks (which is done according to a previous posting) you might missing important / high severe vulnerabilities if this scan config is also used against other Non-ESXi hosts.

4 Likes