Configuring Brute Force Protection

In a brute force attack, an attacker attempts to guess a password by trying to authenticate with many different passwords. You can configure an event broker to temporarily lock out local accounts after a number of failed authentication attempts as a mitigation measure.

The account types covered by this feature are:

  • local Linux accounts (appliance)

  • local CLI accounts (appliance, container image)

Accounts from integrations (LDAP, RADIUS, OAuth, etc.) are not a part of this feature, although LDAP and RADIUS accounts are affected by the lockout when using SSH.

To enable brute force protection, enter the following command:

solace(configure/authentication)# brute-force-protection no shutdown

When brute force protection is enabled:

  • 10 consecutive failed authentication attempts in 15 minutes for a management account will cause that specific management account to be locked out for 15 minutes.

  • A successful login will reset the count.

  • For an appliance, this does not apply to the serial console.

  • For SSH, this applies to local, LDAP, and RADIUS accounts.

  • For SEMP, this applies only to local accounts (not LDAP, RADIUS, or OAuth accounts).

To disable brute force protection, enter the following command:

solace(configure/authentication)# brute-force-protection shutdown

When brute force protection is disabled, the event broker does no password guessing mitigation.

There is a risk of denial of service when you enable brute force protection.

To mitigate this risk, you should add additional non-default admin management users. You can also add LDAP management users to mitigate this issue for SEMP access.

If an admin account is locked out, there are various things you can do to workaround the issue:

  • Use a different management user that isn't locked out.

  • Log in using the appliance or host console.

  • If you are using a container image, connect via solacectl cli, docker/podman/kubectl exec, etc.

  • Connect via SEMP with an LDAP, RADIUS, or OAuth management user.

  • Use SSH if SEMP is locked out and SEMP if SSH is locked out (SSH and SEMP track the lockout separately).

  • Use network level access control to prevent the attack, such as blocking the attacking IP address at the switch. This is the standard way to block most denial of service attacks.