Introduction:
Web applications are often exposed to various types of attacks, such as denial-of-service (DoS), brute force, or credential stuffing. These attacks can overwhelm your application with a large number of requests, affecting its performance and availability. To prevent these attacks, you need a way to detect and block abnormal traffic patterns and limit the rate of requests to your application.
In this blog post, we will introduce a new feature - Rate limiting for Azure Web Application Firewall on Application Gateway that is currently in Public Preview. This feature allows you to define custom rules to limit the number of requests from different sources, such as IP addresses, geographies, or user sessions. By using rate limiting on Application Gateway WAF_v2, you can mitigate many types of attacks, protect against misconfigured clients, or control traffic rates from specific regions.
What is rate limiting for Application Gateway WAF?
Rate limiting for Web Application Firewall (WAF) on Application Gateway allows you to define custom rules to limit the number of requests that match certain conditions within a specified time period. For example, you can limit the number of requests per minute from a single IP address, or the number of requests per hour from a certain country. By doing so, you can prevent your application from being overwhelmed by excessive or malicious traffic.
This feature uses a sliding window algorithm to determine when traffic has exceeded the threshold and needs to be dropped. During the first window where the threshold for the rule is breached, any more traffic matching the rate limit rule is dropped. From the second window onwards, traffic up to the threshold within the window configured is allowed, producing a throttling effect.
How to configure rate limiting policies?
Rate limiting is configured using custom WAF rules in a policy. You can create multiple rate limit rules that match different variables and paths within your policy. Each rule has a threshold, a match condition, and a group by variable.
The threshold is the number of requests allowed within the specified time period. For example, you can set a threshold of 100 requests per minute or 1000 requests per hour.
The match condition is the criteria that determines when to activate the rate limit. You can match various variables, such as request method, header, query string, body, cookie, or path. For example, you can match requests with a specific user agent or cookie value.
The group by variable is the variable that defines how requests are grouped and counted for a matching rate limit rule. You can choose one of the following three options:
- ClientAddr: This is the default option, and it means that each rate limit threshold and mitigation applies independently to every unique source IP address.
- GeoLocation: This option groups traffic by their geography based on a geo-match on the client IP address. So, for a rate limit rule, traffic from the same geography is grouped together.
- None: This option groups all traffic together and counts it against the threshold of the rate limit rule. When the threshold is breached, the action triggers against all traffic matching the rule and doesn’t maintain independent counters for each client IP address or geography. This option is recommended for specific match conditions, such as a sign-in page or a list of suspicious user agents.
Use cases for Rate limiting:
Rate limiting can be used for various scenarios, such as:
- Mitigating DoS attacks: You can protect your application from being flooded by malicious requests that aim to exhaust your resources or disrupt your service. For example, you can limit the number of requests per second from an IP address that is sending too many requests or has been flagged as malicious.
- Protecting against misconfigured clients: You can prevent your application from being affected by clients that have accidentally been configured to send large volumes of requests in a short time period. For example, you can limit the number of requests per minute from an IP address that is sending repeated requests with the same parameters or headers.
- Controlling traffic rates from specific regions: You can manage the traffic distribution to your application from different geographies based on your business needs or preferences. For example, you can limit the number of requests per hour from a country that is not your target market or has low conversion rates.
Best practices for Rate limiting Feature on Application Gateway WAF:
Here are some of the best practices that you should be aware of while configuring this feature.
- The configured rate limit thresholds are counted and tracked independently for each endpoint the WAF policy is attached to. For example, if you have a single WAF policy attached to five different listeners, each listener will have its own counters and threshold enforcement.
- The rate limit thresholds are not always enforced exactly as defined, so you should not use it for fine-grain control of application traffic. Instead, you should use it for mitigating anomalous rates of traffic and for maintaining application availability.
- The sliding window algorithm blocks all matching traffic for the first window in which the threshold is exceeded, and then throttles traffic in future windows. You should use caution when defining thresholds for wide-matching rules with either GeoLocation or None as the group by variables. Incorrectly configured thresholds could lead to frequent short outages for matching traffic.
Configuring rate limiting on Application Gateway WAF:
If you want to try out rate limiting on Application Gateway WAF_v2 (preview), you can follow these steps:
- Create an Application Gateway with WAF_v2 SKU and enable the latest WAF engine by selecting CRS 3.2 for the default rule set.
- Create a Web Application Firewall policy and attach it to your Application Gateway.
- Create one or more custom rules with rate limit action and configure the threshold, match condition, and group by variable as per your requirements.
- Test your application and monitor the and logs.
Example Scenario:
Here we have setup an Application Gateway WAF policy for a sample webpage with host IP: 20.160.216.25. As we can see in the below image, a rate limit rule has been configured to deny traffic from a specific IP, if the number of requests exceed 100 with in a duration of 1 minute.
To verify the functionality of this setup, you have two options: either manually reload the page http://20.160.216.25 more than 100 times (or any limit specified on the rule) in less than a minute or use a traffic generator tool such as Microsoft Client to Server Traffic Tool or any simple script to send multiple requests to the destination IP address. After performing either of these actions, you will observe that this attempt will be blocked by the Application Gateway WAF due to the configured rate limit rule for the specified source IP address.
To analyze the traffic patterns for your web application in a given period of time, you can utilize the metrics that are available for your Application Gateway WAF as displayed in the below image.
Conclusion:
In this way, Rate limiting feature on Application Gateway WAF can be used to manage and enhance your application’s traffic quality. It allows you to avoid undesirable or harmful requests, safeguard your resources and service, and adjust your traffic distribution according to your business objectives. Rate limiting can be implemented in various situations, such as mitigating DoS attacks, protecting against misconfigured clients, and controlling traffic rates from specific regions.
Additional Resources:
Microsoft
