Try many times to identify the username using sign-up/forgotten password.
Try many times to login using a list of known usernames and either potential passwords or every possible password combination.
Each website cookie has a unique identifier that if guessed would provide them the same access as the username and password.
Account locking can be considered an alternative in some cases to rate limiting, but it has the disadvantage of disabling accounts from working, which could of been the aim of the cyber attack.
An example could be a website that allows people to post comments. A cyber attacker could then post millions of comments to disrupt other users using the site or overload the server and cause an outage.
There may be a page on a website that places significant load on the server, by loading this page many times it could overload the server and cause an outage.
Potential methods for extracting data may require loading a page many times.
Once you have decided to implement rate limiting the question is how and where. Considering the different types of Cyber Attacks that rate limiting impacts, it seems obvious that you would apply rate limiting in most situation for most connections including Active Directory Logins, Websites, Emails, etc.
Let us focus on rate limiting of a website, and drill down in a little more detail.
Although applying rate limiting to an entire website might be a quick fix, it may not take into account the different rates for different pages. As an example applying a general 100 loads a minute per person may work for most pages but it is not restrictive enough for a login page where you may want it limited to 10 login attempts per person an hour.
Code specific rate limiting applied to specific pages e.g. Login, Password Reset, ..
Easy to setup and manage as simple rules go into the NGINX server, and complex rules are handled in code.
Provides two layers of rate limiting defence so any bypass of HTTP Reverse Proxy will still be rate limited.
Allows rate limiting in code so for sensitive pages rate limiting occurs within the code and stops the code from executing further.
Provides ability to log rate limiting events at appropriate level to identify for manual review or automatically provide further restrictions.
This may be important for detecting certain types of data breach attacks.
Performance impact was less than 1% in our testing setup.
So go forth and rate limit your resources.
If you need help securing or rate limiting your Server, Website, Email or Active Directory get in contact with us.