How to disable administrator authentification

Hello everybody !

I’m using the Greenbone container and I’m seeking assistance in disabling the administrator check in my scans. To provide context, I’ve set up Kibana to monitor all authentication attempts on my server. Consequently, when I initiate a scan, I notice a significant number of failed authentication events on my dashboard only for user “administrator”.

Thank you in advance for your help!

Hello and welcome to the Greenbone community forum.

When you create a custom scan configuration you can enable or disable any vulnerability tests according to your needs. You could clone either the Full and Fast and remove VTs or clone Base Scan and only add the scans you want.

Start this process by going to the Configuration -> Scan Configs from the top menu bar and then clone an existing scan. Then edit it and customize the NVT selection.

Thank you for your response. Do you happen to know which specific setting I need to disable in order to turn off administrator authentication? I’ve tried numerous approaches, but none of them have proven successful. :cry:

Are you only concerned about logins for the username “administrator” or also “admin”?

Only Administrator, i search and delete every entry where i saw “administrator” but no change

[EDITED TO ADD CLARITY]

After cloning a Full and fast I suggest looking in the Network Vulnerability Test Preferences section which is below the other two sections.

Specifically, I think Brute Force security checks may disable all remote authentication attempts. I believe this turns off all default account checks. Maybe you can make a more granular approach to address only "administrator" login attempts. More specifically, the credentials file indicates the smb_default_credentials.inc file would be loaded which contains many administrator default credentials / weak passwords to try.

If that does not accomplish your goal, you may find some other options in the Network Vulnerability Test Preferences section such as:

There are other places where administrator credentials are indicated. Other .inc NASL include files that contain administrator` login attempts include:

  • plugins/xerox_printers.inc:
  • plugins/wmi_user.inc:
  • plugins/smb_default_credentials.inc:
  • plugins/sharp_printers.inc:
  • plugins/default_credentials.inc

You can look for NASL .nasl scripts that include these credential files and look for an OID to associate with an NVT so you can disable those tests in the scan config.

Hello,

and welcome to this community forums.

While it doesn’t answer the initial question it should be noted that disabling VTs just because the logging solution is not adequate configured is the worst thing what one can do from a vulnerability scanning viewpoint. Default credentials like administrator are a high severe risk once found.

Instead of disabling VTs it is strongly suggested to configure adequate filters in the logging solution (e.g. adding the scanner IP address to an allow list or similar).

@rippledj : I have already tried the first two steps but without success.
I’m going to try to see in the .inc if it corresponds to what I want to do

@cfi Thank you for the advice, but our administrator accounts have been disabled and we get an alert when someone tries to use it or activate it, I don’t think it’s mandatory to scan this account and if for some reason the openvas VM has been compromised an attacker could from this machine do a lot of damage so we do not want to put a filter for this machine. But if you have other arguments that go in your direction I am ready to listen to them, I am new to the product

At the end it is in the responsibility of the users to accept the risks originating from disabling any VT:

For example in (larger) environments and with disabled administrator accounts there is always the risk that new systems are getting added (e.g. without the administrators knowing that) which are using such credentials or there are even existing ones included in that specific environment.

IMHO and as pointed out previously a solution on the logging system where the alerts are ending up should be found instead (e.g. adequate filtering or similar depending on the solution).

2 Likes