Is ASM right for a very slow "Brute Force"

IPI could help in this case. Another option could be to use the APM in front of your server and using captcha.

you could try to increase the Measurement Period from the Dynamic Brute Force Protection, but the max value is 60 seconds. Not very long. Maybe an irule counting the false logins, if countable

Hi,

Using ASM, you can leverage IP Intelligence, Brute Force protection or the DoS profile (really cool in v12.1.0)

Alternatively, I can suggest you using an irule to protect against brute force like this one (need to change peaces of code to fit the authentication method used by the backend) : DoS and NTLM Brute force protection for HTTP(s) flow

Or you can also write an irule to grap credentials and play them seemlessly against APM to create an APM session or deny access : ACCESS::policy evaluate -sid -profile [ +]

You can see an example here : ACCESS::policy

Hi Russel,

I've writen in the past a traditional prä-auth / reverse proxy iRule, which included:

• Normalization of username strings (e.g. removing CaSe, different representation of a single username, etc.).

• [table] based serialization of parallel login request for a single username spanning multiple TCP connections (to avoid race conditions, while waiting for AAA decissions)

• [table] based backlogging of parallel login request with identical credential sets.

• [table] based tracking the number of wrong login attemps per user-account, with the added ability to rember and supress attemps using already proven as wrong credentials (e.g. to avoid accidential lockouts caused by the user themself entering old passwords or just using a wrong keyboard layout)

• [table] based tracking the number of wrong login attemps per IP address, with some added logic so that a single IP address needs to bruteforce multiple useraccounts before getting locked.

• The repository access was implemented using [SIDEBAND] HTTP request directly to the published webservers (e.g. via BASIC or Forms auth) and included a [table] driven SSO mechanism to SSO to multiple websites (also including Cross-Domain-SSO).

If the lockout counter for a specific username has been reached a given limit, further authentication attemps from the same user would be supressed/denied for a given timeframe.

If the lockout counter for a specific IP adresss has been reached a given value, further authentication from the same user would be supressed/denied for a given timeframe.

Hope this helps to get some ideas, what could be done without Catcha, APM or IPI but instead using plain iRules.

Cheers, Kai

Thanks again to all the guys that gave answers, will feedback once we come to a decision and let you know how it turned out.