Brute-force prevention on specific URLs

Hi, DOS protection is based on Transactions Per Second (TPS) so it does not need a specific URL as it can be any URL under attack. For example - if the number of requests of any URL increases by 500% or reaches 1000 TPS - start mitigating.

Do not confuse this with 'Heavy URL' which is a URL requiring a significant resource consumption on the server - a search URL is a good example of a 'Heavy URL'. Heavy URL protection is based not on TPS but on Latency. Because of this ASM needs to know the specific URL to monitor the response time, e.g. if responses on /search.php heavy URL start exceeding 1000 ms per response - apply mitigation.

You are confusing DoS and Brute Force detection. Brute Force attack detection happens if the number of FAILED LOGINS exceeds a threshold (e.g. someone is trying to hack in/find working set of credentials using trial and error - they are attacking specifically the Login pages).

DoS attacks have nothing to do with "hacking"/attempting to log in, but with attempts to overwhelm the server with requests so it stops responding - compare that with Brute Force which is NOT about overwhelming the server, but about finding a working combination of username/password.

To detect a Brute Force attack ASM will count the number of FAILED LOGINS either from within the same session (same session cookie) or same client IP address. So "Session Awareness" is NOT the count of new HTTP sessions but the count of FAILED LOGINS within the same session. Showing a CAPTCHA in session-awareness is not of much use as we don't care if the attacker is a human or a bot - we just block their session. If it is a human - he or she can close the browser and start a new session. If it is a bot - it will be blocked for a duration of time specified in 'Re-enable login after' so the service is protected. If you have a bot which is trying 1 million login/password combinations and we stop it for 10 minutes after each 5 failed login attempts that bot will be there for a long time trying to hack in...

when mitigating DoS attacks you don't care about logins and sessions - you only care about the huge volume of requests coming from bots. Having a CAPTCHA here makes sense as it will allow ASM to identify requests from humans (and that is any requests from humans, not just login requests as in Brute Force).

Re: your question of username/password parameters in Login URLs being wildcard - this is not documented anywhere so I suggest that you experiment yourself to see if you can verify this (or raise a support case with F5 and ask them if that's quicker for you).

Hope this helps,

Sam

A request For Enhancement was raised to allow matching on wildcard User name or password parameters and this is currently being tracked as ID436044.

Thanks for raising an RFE - I never understood why F5 never made username/password parameters on the Login Page an existing parameters from the policy which would have allowed you to define wildcards.

Re: DOS protection for specific URL - you can always create a SEPARATE ASM policy with just DOS profile which triggers on specific URLs only and assign it to virtual server separately - it makes it easier to manage.

That would be an overkill in managing 2 different policies.

What about iRule, would it be possible with ASM iRule?

Yes, you can do anything with iRules :)

If you want a ready-made iRule then I think the request throttling iRule will do it for you, there are variations of it on CodeShare, for example this one:

https://devcentral.f5.com/codeshare?sid=564

Alternatively a custom iRule will need t be developed to watch out for POST requests to your login page and to monitor with the response is a success or fail and then raise a custom ASM vioation if the number of login failures exceed some threshold