Volumetric cyberattacks (i.e., attacks relying on an abnormal volume of traffic) are common today. They can occur in a wide variety of forms.
When security professionals evaluate web security solutions, they tend to focus primarily on defending against DDoS. (This is understandable, since DDoS is the most common form of attack on the web today.)
However, the other forms of volumetric attack can be just as dangerous, and it’s important to avoid neglecting them. There are many threat vectors that use high volumes of incoming traffic, but at amounts significantly below DDoS levels. To defend against them, a different form of protection is essential: rate limiting.
We recently published a comparison of the DDoS protection services offered by the top-tier cloud service providers (AWS, Azure, and GCP). In this article, we’ll do the same for their rate limiting capabilities. After some background information, we’ll discuss:
- An overview of the rate-limiting features available from each CSP (cloud service provider).
- Step-by-step walkthroughs showing how to configure them for each service (which helps to illustrate their capabilities)
- The strengths and weaknesses of each CSP’s offering
- The important deficiencies shared by all three CSPs, and how to avoid them.
What Is Rate Limiting?
As we discussed in-depth in “Rate Limiting: A Vital Part of Modern Web Security,” rate limiting is the identification of hostile traffic sources by examining the rates at which they are attempting to access resources.
To enforce rate limits, a web security solution must monitor the frequency and timing of incoming requests from each traffic source. When a given requestor exceeds a specified rate limit, it is blocked from further access for a specified length of time.
The Necessity of Robust Rate Limiting
Effective rate limiting can block many attacks that otherwise are difficult to detect. For example, a hacker could wage an ATO (account takeover) attack by submitting different combinations of usernames and passwords into a login form. On an individual basis, each request appears to be legitimate; the attack is only recognizable when all the requests are considered together, and the anomalously high rate of (failed) login attempts from a single traffic source is seen.
Therefore, rate limiting is an essential component of any security solution that offers ATO prevention. It is also vital for preventing scraping and data theft, inventory hoarding, fuzzing, and many other forms of brute-force attacks against web applications. And since there is a rising frequency of these attacks against services and microservices too, it’s equally important to include rate-limiting as part of your API security measures.
All three of the major CSPs include some rate-limiting capabilities, so that their customers can protect their cloud workloads. Currently, none of the CSPs include dedicated rate-limiting services; rather, users can add rate limits to security policies configured in other tools.
Let’s briefly discuss the capabilities of each CSP. To illustrate them better, we’ll include a walkthrough of rate-limiting setup on each platform.
Amazon Web Services (AWS)
AWS offers a wide range of security-related services. One of the most important is AWS WAF: a web application firewall that processes requests sent to AWS resources.
Resources can be protected by creating web Access Control List (ACL) rules to specify rate limiting conditions for the incoming requests.
Enabling Rate Limits Using AWS WAF
On the AWS console, search for “WAF”, and then select “Create web ACL”:
Fill in the name, and select the resource type to which you want to attach the created web ACL; above, we selected “Regional resources”.
Now, click on “Next”, then “Add rules” → “Add my own rules and rule groups”:
Fill in the rule name, and switch the type to “Rate-based-rule”.
Add the rate limit for the rule, e.g., a maximum of 1,000 requests allowed per 5 minutes for each unique client source IP address:
You can specify the maximum number of allowed requests originating from a single IP address (client) within a five-minute period; the client will be automatically blocked when the limit is exceeded.
AWS Rate Limiting Summary
- IP-based and location-based access controls for rate-limiting rules
- Easy to set up
- Does not support hybrid and multi-cloud deployments.
- Time duration of rate limiting is not configurable (only a five-minute period).
- Does not support banning sources of malicious traffic. Once attackers reduce their requests to below the defined rate limit, they can access the protected resources again.
- Attackers can avoid rate limiting completely by rotating IP addresses.
Microsoft Azure offers a wide range of services for building internet-facing applications, along with some security tools to protect them. For example, Azure Front Door is Microsoft’s CDN that delivers applications and content across the globe. You can attach a web application firewall (WAF) rate limit rule to protect your Front Door profile apps, letting you limit the number of client requests from a particular IP address within a specified period of time.
Enabling Rate Limits Using Azure WAF
We previously published a general guide showing how to deploy and use Azure WAF. Here’s how to create a WAF policy with a custom rate limit rule by using the portal for Azure Front Door via the Azure portal.
First, create a WAF policy for your desired rate limit requirements on the Azure portal; select “Create a resource”, type WAF in the search box, and then select “Web Application Firewall (WAF)”, followed by “Create” to open the following:
Next, choose the policy name and what the policy is being created for. Then, select the “Custom rules” tab, and click on the “Add custom rule” button:
Change the rule type to rate limit, and select the rule priority order by adding numbers where rules with lower values (high priority) are evaluated before rules with higher values (low priority).
You can choose a rate limit duration of between 1 minute and 5 minutes. Usually, the IP address is used to match unique app clients, but you can also opt for the client’s geolocation to do this.
Next, select the action to be taken (i.e., allow, deny, redirect, or log traffic) when the rate limit rule is reached for a certain client, and then click on “Add”:
Now, go back and click the “Review + create”, followed by “Create”:
Open the created WAF policy, then select the Associations section and attach the front host to be protected with the rate limit rule:
Azure Rate Limiting Summary
- Easy to set up using WAF custom rule policies
- Can be used with Azure Front Door and Application Gateway
- Limited to use with Azure services only
- Less visibility of performance overhead
- Only supports two rate limit durations (1 minute and 5 minutes)
- Limited options for responding to violations of the rule
- Attackers can avoid rate limiting by rotating IP addresses and/or geolocation.
Google Cloud Platform (GCP)
Enabling Rate Limits Using Google Cloud Armor
We previously published a general guide showing how to setup and use Google Cloud Armor. Here’s an example of adding a rate limit policy. (For more information on the available options, see the rate limiting section of the Cloud Armor docs.)
In the Google Cloud Console, go to the Network Security page.
Click on “Start Cloud Shell” under “Setup and Requirements”, and create a security policy via gcloud-cli by typing:
gcloud compute security-policies create rate-limit-demo \ --description "policy for rate-limiting"
Then, add a rate-limiting rule:
gcloud beta compute security-policies rules create 100 \ --security-policy=rate-limit-demo \ --expression="true" \ --action=rate-based-ban \ --rate-limit-threshold-count=100 \ --rate-limit-threshold-interval-sec=240 \ --ban-duration-sec=100 \ --conform-action=allow \ --exceed-action=deny-404 \ --enforce-on-key=IP
In the Console, navigate back -> Network Security -> Cloud Armor.
Click on the created “rate-limit-demo” policy and attach it to the desired Google cloud service such as Google Kubernetes Engine (GKE) Ingress.
Google Cloud Rate Limiting Summary
- IP-based and location-based access controls for rate-limiting rules
- Integrates very easily with HTTP(s) load balancers
- Support for hybrid and multi-cloud deployments
- No UI for setup
- Configuration can be difficult, and requires a custom rules language
- Higher pricing
- Header- and cookie-based requestor tracking options are more powerful than the tracking offered by AWS and Azure, but they do not work in all architectures.
Deficiencies of All Three Cloud Providers’ Rate Limiting
Although all three of the top-tier CSPs offer some rate limiting features, they still fall short of the capabilities that are often needed in a production environment.
Here are some of them:
- Limited choice of time periods
- Difficulty in configuring different rate limit policies for different domains/sites/paths/etc.
- Inability to whitelist requests with certain characteristics
- Limited choice of actions to take when a limit is violated (e.g., there’s no way to flag requests in dashboards/logs while still allowing them, or to issue a bot challenge to the requestor to verify that it’s human, or to redirect requests, or to ban the requestor from further access attempts, etc.)
- Inability to constrain attackers that rotate IPs, geolocation, etc.
- Inability to construct complex rate limit rules, based on combinations of headers, cookies, arguments, and requestor attributes.
As a result of all this, the top-tier CSPs do not offer rate limiting features that can support a robust security posture. In today’s threat environment, organizations need something more.
Reblaze Offers Full-Featured Rate Limiting (and much more)
Reblaze is an industry leader in rate limiting. The features described above, and many more besides these, are all part of the Reblaze WAAP (Web Application and API Protection) platform.
Reblaze is a comprehensive, all-in-one web security solution. Along with advanced rate limiting, Reblaze also includes a next-gen WAF, multi-layer DDoS protection, bot management, API security, and much more.
For more information about Reblaze, or to schedule a demo, you can contact us here.