01-18-2017 02:42 AM
How do i block failed login attempts to the website via the loadblancer ?
Someone is trying random user names and passwords, they are bringing the server down
I only want to block failed login attempts not limt the number of connections as the real user does hit the server hard.
01-18-2017 04:37 AM
This is effectively an L7 DoS attack on your web site, One possible way to do protect against this is to apply a rate limit to login requests. You can either create a rate limit for ALL login requests, or you can add some extra logic to rate limit individuals.
Alternatively, you may be able to use TrafficScript to determine whether a username is valid before you attempt to submit the page to perform authentication. For example, you might be able to check with a regex to see if the username in the form meet the correct pattern Or if you know that valid users have a cookie, then you could use that to decide whether to reject a login request, without attempting to authenticate.
This feature brief gives an overview of simple TrafficScript rules:
Here are a few other articles that could help:
01-18-2017 05:05 AM - edited 01-18-2017 05:06 AM
However, this kind of "random" attack may need to be handled differently. To protect against more sophisticated attacks, you could use the Brocade vWAF (Web Application Firewall) - among other features, it includes the capability to "virtualize" a form - so that an attacker does not know which fields in your webform are the "user/password" fields.
You could do this with Brocade vTM and TrafficScript, but Brocade vWAF includes many capabilities like this, and makes it very easy to apply security policies across an entire application, not just to a single page.
With TrafficScript, you could modify the login page without changing your application logic: change the HTML on the login page to give the login/password fields different internal names. When the user hits the "submit" button on the form, then use TrafficScript to submit the user credentials with the correct field names to your application. You could also create a couple of "dummy" fields in the HTML with the original fieldname, which a attacker would assume were the actual login/password fields. You could hide these "dummy" fields in a corner of the web page, or behind a graphic, so that genuine users can't see them.
In this way, only genuine users would have filled in the field that woud be submitted to your actual website authentication process - automated attacks would fill in the wrong fields, and would be rejected without any exrta workload on your application.