Prevent brute force attacks
A brute force attack is a common method used to gain unauthorized access to accounts by systematically guessing username and password combinations until the correct one is found. However, brute force attacks can have goals beyond just gaining access. In Active Directory, password policies often include locking out accounts after a set number of failed sign-in attempts, which can turn these attacks into tools of disruption.
In this tutorial, you will learn how to configure brute force protection for Adaxes web interface. It is especially important to configure it if your web interface is accessible from the Internet.
-
Open Adaxes web interface configurator.
How
-
On the computer where web interface configurator is installed, open Windows Start menu.
-
Click Adaxes Web Interface Configurator.
The permissions to configure the web interface are delegated via security roles. By default, only service administrators have the appropriate rights. To enable other users to configure the web interface, grant them the corresponding permissions.
Grant permissions
-
In Adaxes administration console, right-click your Adaxes service, point to New and click Security Role.
-
Enter a name for the new security role and click Next.
-
On the Permissions step, click the down arrow embedded into the Add button and click Configure Web Interface.
-
Click Next and follow the steps in the wizard.
-
-
In the top left corner, select the web interface you want to customize.
By default, all web interfaces use the sign in settings of the Common sign in page. Select Common sign in unless you want a particular web interface to have different sign in settings.
-
In the left navigation menu, click Sign in.
-
Scroll down to the Brute force protection section and configure the settings within.
-
Enable friendly captcha
Every sign-in attempt will require solving a friendly captcha.
Friendly captcha is based on proof of work and does not require user input. Instead, the user's device is served a cryptographic puzzle in the background. The puzzle requires spending computational resources for every sign-in attempt and makes brute force attacks unfeasible.
-
Delay responses after
The web interface will progressively delay its responses to users that repeatedly fail to sign in within a short time period.
-
Ask a security question after
The web interface will ask users a question after a certain number of failed sign-in attempts. Further attempts to sign in without correctly answering the question will be rejected.
The question will be identical for every user, but the answer can be either static or dynamic:
-
Static answer – will be identical for everyone. Use a certain word or phrase known only to your users. For example, the street name where your company headquarters are located.
-
Dynamic answers – will be different depending on who is signing in. You need to use value references to make answers dynamic. For example, if you specify %department%, users will need to enter their department name exactly as it is defined in their account properties.
More examples {id=more_valref_examples}
- %adm-ManagerFullName% – users will need to enter the full name of their manager.
- %extensionAttribute1% – users will need to specify the text stored in the Extension attribute 1 property of their account.
- %employeeID%%telephoneNumber,6% – users will need to provide their employee ID and the first 6 digits of their telephone number.
If you use a value reference as the answer and the corresponding property of the user account is empty, no answer will be accepted as correct.
-
-
Hide error details and remaining attempts on sign-in failure
By default, the web interface shows a reason why a sign-in attempt failed and the number of sign-in attempts left according to the password policy applied to the user. When this option is enabled, the web interface will instead show a generic error message.
-
-
Save the changes.
Tracking
Every failed attempt to sign in to the web interface is tracked by Adaxes. If the number of failed sign-in attempts exceeds a certain threshold within a short period of time, Adaxes adds a progressive delay each time a user tries to sign in to make persistent brute force attacks less efficient.
The tracking mechanism triggers when there are many continuous sign-in attempts with the same
- username, or
- password, or
- IP address.
How do I know the IP addresses from where suspicious activity originated? {idtrack_ip}
As soon as the threshold is reached, a warning containing the IP addresses of the hosts where the most of the suspicious activity originated is logged in the Adaxes event log. Warning sample:
Too many failed login attempts to web interface SelfService.
To protect you from a possible brute force attack,
all subsequent login attempts will be processed with a delay.
The most of failed login attempts originated from the following IPs:
fe80::1dbd:465e:5fe6:3ea4%5
106.22.56.42
2001::db8::a0b::12f0::2255
...
For information on how to access the log, see View service event log.