A rate rule restricts the flow of site traffic with the intention of:
Requests that exceed the rate limit may be dropped, redirected to another URL, or sent a custom response. The type of enforcement action that will take place is determined by the Security Application Manager configuration that leverages it.
A rate rule restricts the rate of traffic that may be directed to one or more web sites. HTTP/HTTPS requests that exceed a rate rule will not be honored.
Key information:
A rate rule may be applied to all requests, unique clients, or unique user agentsRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link)..
A Security Application Manager configuration determines the set of requests to which this rate rule will be applied. Use condition groups to define one or more additional prerequisites (e.g., URL or user agent) that a request must meet before it will count towards the rate limit.
If one or more condition group(s) have been defined, then the request must also satisfy all of the conditions defined within at least one condition group.
A rate rule is enforced by each edge server according to the approximate number of requests that it receives over the specified time interval (e.g., 1 second, 10 seconds, or 1 minute).
Requests from a single client may be load balanced to different edge servers based on the requested URL.
WAF does not perform further evaluation of a request once enforcement is triggered.
We recommend that you limit your use of the Alert Only enforcement to the shortest amount of time necessary to validate changes to your configuration.
This scenario assumes that a different edge server is handling each unique request URL. However, a single edge server could potentially handle multiple unique request URLs that are eligible for rate rules. In which case, the rate limit would be applied to the aggregate traffic for that content.
Requests will be rate limited according to this configuration:
Type |
Setting | Value |
---|---|---|
Security Application Manager |
Hostname |
Default configuration (Match all hostnames.) |
Security Application Manager |
URL path(s) |
Default configuration (Match all URL paths.) |
Rate Rule |
Apply rate limit to |
Any request This type of source applies a rate limit to all requests without taking into account the client that submitted each request. |
Rate Rule |
Rate limit |
300 requests per minute |
In the above scenario, the CDN received 1200 requests per minute for the following three files:
The CDN handled the above requests in the following manner:
It honored the following 800 requests:
More Information
A rate limit of 300 requests per minute is being enforced on a per edge server basis. Since a different edge server handled each unique URL, the maximum number of requests that could have been honored for each of these assets is 300. Only 200 requests were honored for Logo.png, since it was only requested 200 times within that minute.
Our CDN service applied a predefined rate limiting action (e.g., URL redirection) to the following 400 requests:
This scenario assumes that a different edge server is handling each unique request URL. However, a single edge server could potentially handle multiple unique request URLs that are eligible for rate rules. In which case, the rate limit would be applied to the aggregate traffic for that content.
Requests will be rate limited according to this configuration:
Type |
Setting | Value |
---|---|---|
Security Application Manager |
Hostname |
Default configuration (Match all hostnames.) |
Security Application Manager |
URL path(s) |
Default configuration (Match all URL paths.) |
Rate Rule |
Apply rate limit to |
IP address This type of source applies a rate limit to all requests from unique IP addresses. |
Rate Rule |
Rate limit |
50 requests per minute |
The following diagram illustrates how this rate rule controls the total number of requests that may flow through our network.
In this scenario, only a single client (i.e., laptop) exceeded the rate limit. Specifically, our CDN service enforced rate limiting for that client's requests for Index.html and Styles.css. Our CDN service honored all other requests, since they do not exceed the defined rate limit (i.e., 50 requests per minute).
Aggregate traffic is not taken into account when rate limiting unique clients. For example, this rate rule would not be enforced on 2,000 clients if they only issued 5 requests per minute. Although aggregate traffic exceeded the rate rule, no single client exceeded 50 requests per minute.
This scenario assumes that a single edge server is handling all of these requests.
A Security Application Manager configuration may contain multiple rate rules that define a custom rate limit for different types of requests. These rate rules are processed in the order in which they are listed. Once a rule is satisfied, it will be applied to the request and no additional rules will be processed.
It is recommended to order rate rules according to how they identify requests. Stricter rules that identify requests using multiple conditions should be placed closer to the top of the list, while catch-all rules should be placed closer to the bottom. This ensures that your rate limits are applied to requests as intended.
In this scenario, your Security Application Manager configuration determines that the following rate rules will be applied to all requests:
# | Configuration |
---|---|
1 |
Rate Rule Apply rate limit to: IP address Rate limit: 200 requests per minute
Conditions: Host = cdn.example.com & Request URL path = /sales/index.htm View Details
Condition #1:
Condition #2:
Security Application Manager Action type: Redirect (HTTP 302) |
2 |
Rate Rule Apply rate limit to: IP address Rate limit: 200 requests per minute
Condition: Host = cdn.example.com View Details
Security Application Manager Action type: Drop request |
3 |
Rate Rule Apply rate limit to: Any request Rate limit: 500 requests per minute Condition: None Security Application Manager Action type: Redirect (HTTP 302) |
This sample scenario examines how the following requests will be affected by rate rules.
Although the majority of the following requests satisfy multiple rules, only the first rule that a request violates will be applied to it.
Request | Rule |
Description |
---|---|---|
Client: 100.10.20.33 Request rate: 350 per minute Request URL: http://cdn.example.com/sales/index.htm
|
1 |
Action: Approximately 200 requests will be honored, while approximately 150 requests will be redirected. Why? All of these requests satisfy the first rule. As a result, the subsequent rules (i.e., second and third rules) are skipped. |
Client: 101.10.20.44 Request rate: 300 per minute Request URL: http://cdn.example.com/marketing/index.htm
|
2 |
Action: Approximately 200 requests will be honored, while approximately 100 requests will be dropped. Why? These requests do not meet the conditions defined for the first rule. However, they do satisfy the second rule. As a result, the subsequent rule (i.e., third rule) is skipped. |
Client: 102.10.20.55 Request rate: 250 per minute Request URL: http://cdn.example.com/sales/index.htm
|
1 |
Action: Approximately 200 requests will be honored, while approximately 50 requests will be redirected. Why? All of these requests satisfy the first rule. As a result, the subsequent rules (i.e., second and third rules) are skipped. |
Client: 102.10.20.55 Request rate: 450 per minute Request URL: http://cdn2.example.com/sales/index.htm
|
3 |
Action: All 450 requests will be honored. Why? These requests do not meet the conditions defined for the first or second rule. However, the third rule is applicable, since it is a catch-all rule that applies to all requests. Although the total number of requests from all clients exceeds 500 requests per minute, only the 450 requests submitted by this client are eligible for rate limiting by the third rule. Therefore, the rate limit defined in the third rule is not being exceeded. Notice that a different rate rule is applied to these requests, even though they originate from the same client (i.e., 102.10.20.55). |
Setting up a rate rule involves determining how requests are grouped and a rate limit. You may also specify additional criteria to identify the set of requests to which this rate rule will be applied.
Category | Description |
---|---|
Apply a rate limit:
|
|
Define a maximum request rate before a predefined action is triggered. |
|
A request counts towards a rate limit when it satisfies all of the following criteria:
|
|
Action |
A Security Application Manager configuration determines the type of action that will be applied to requests that exceed the above rate limit. |
Rate limiting may be applied across all requests or to each unique client. Define this behavior from within the Apply rate limit to option. The available modes are described below.
Mode | Description |
---|---|
Any request |
Indicates that all requests will count towards the rate limit. Once the specified rate limit is exceeded, it will be enforced without taking into consideration which client submitted the request. This mode is not recommended when there are malicious clients that are spoofing legitimate traffic. This type of configuration may potentially lead to a situation where spoofed traffic is honored while legitimate traffic is rate limited. |
IP address |
Indicates that the requests from each unique client, as determined by its IP address, will be tracked. The specified rate limit will only be enforced on the clients that exceed it. |
IP address and user agent |
Indicates that the requests from each unique client, as determined by each unique combination of IP address and user agentRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link). (e.g., web browser), will be tracked. The specified rate limit will only be enforced on the clients that exceed it. All requests from a specific IP address that contain a blank or missing User-Agent header will be treated as a single client. |
The maximum rate at which requests will be honored before a predefined action is applied to it is known as the rate limit. A rate limit defines the number of requests over a given time period (e.g., 5 seconds, 10 seconds, or 1 minute). Define the desired rate limit via the Rate limit option.
Key information:
The source that will be rate limited should be taken into account when defining a rate limit.
A rate limit that applies across all requests should be significantly larger than a rate limit that applies to unique clients.
The specified rate limit is enforced on each edge server based on the number of requests that it receives.
Typically, a single edge server will handle all requests directed to a POP for a specific URL.
If the volume of requests to the above edge server exceeds capacity, then requests will be load balanced to an additional edge server.
Example
All requests within the Los Angeles area for the following image will be handled by a single edge server in a Los Angeles POP:
If rate limiting is being applied to unique clients, then it is important to note that requests from a single client may be load balanced to different edge servers based on the requested URL.
Example
A request for a web page may result in 50 subsequent requests for its supporting files (e.g., CSS, JS, and images). Although a single client is requesting all 50 of these assets, these requests may be load balanced across anywhere from 1 to 50 different edge servers in a single POP.
A condition group defines one or more prerequisites that must be met before a request will count towards the rate limit.
A request will only count towards the rate limit when it satisfies the host and URL path match conditions defined within a Security Application Manager configuration. Additionally, if one or more condition group(s) have been defined, then the request must also satisfy all of the conditions defined within at least one condition group.
The types of prerequisites that may be defined are described below.
Type | Description |
---|---|
A request will count towards the rate limit when the filename of the requested content contains a file extension that matches a value defined in the Value(s) option. Syntax: .FileExtension
Example: .htm
|
|
A request will count towards the rate limit when its IP address matches a value defined in the Value(s) option. Make sure to use standard IPv4 and CIDR notation. Specify a subnet by appending a slash (/) and the desired bit-length of the prefix (e.g., 11.22.33.0/22). |
|
A request will count towards the rate limit when the value corresponding to the specified request header is an exact case-sensitive match for the one defined in the Value(s) option. This condition supports the following request headers:
HostA request will count towards the rate limit when its Host header matches the specified hostname or IP address. Syntax:
Key information:
User-AgentA request will count towards the rate limit when its User-Agent header matches the specified user agent. The request's user agent must be an exact match to the specified value. User agent strings typically vary by type and version. Specify a blank value to match with requests that have a blank or missing User-Agent header. RefererA request will count towards the rate limit when its Referer header matches the specified referrer. The request's referrer must be an exact match to the specified value. |
|
A request will count towards the rate limit when the request's HTTP method matches a value defined in the Value(s) option. Valid values are: GET | POST | PUT | HEAD | DELETE | OPTIONS
|
|
A request will count towards the rate limit when its request URL contains a relative path that matches a value defined in the Value(s) option. For the purposes of this option, specify a URL path pattern that starts directly after the hostname. Do not include a protocol or a hostname. This type of match condition requires a Host condition within the same condition group. Syntax: /path/asset
Example: /marketing/brochures/widget.htm
A partial match does not count towards the rate limit. For example, given the above sample configuration, the following request would not count towards the rate limit: http://cdn.example.com/marketing/brochures/widget.html. |
Key information:
A request will count towards the rate limit when it satisfies both of the following conditions:
Each condition must contain a value through which requests will be identified.
Ensure that your rate limiting configuration complies the following limits:
Type | Limit |
---|---|
Condition groups per rate rule |
5 |
Conditions per condition group |
5 |
IP Address: 200 All Other Conditions: 100 |
You may define multiple rate rules within a Security Application Manager configuration. This type of setup provides greater control when determining how requests will be rate limited.
Common use cases for multiple rules:
The order in which rules are listed is critical, since it determines which rule will be applied to a request.
It is recommended to order rules according to how they identify requests. Stricter rules that identify requests using multiple conditions should be placed closer to the top of the list, while catch-all rules should be placed closer to the bottom. This ensures that rules are applied to requests as intended.
Key information:
Only the first rate rule that a request satisfies will be applied to it.
Once a request satisfies a rate rule, all subsequent rate rules will be skipped.
You may create, modify, and delete rate rules.
Key information:
Apply a rate rule to production traffic by adding it to a Security Application Manager configuration and then determining how it will be enforced. Multiple Security Application Manager configurations may use the same rate rule. Leverage this capability to tailor security screening by application or traffic profile.
Before adding a rate rule to a Security Application Manager configuration, verify that the Security Application Manager configuration's hostname and URL path conditions do not conflict with your rate rule's conditions.
To create a rate rule
Navigate to the Rate Rules page.
Optional. Create a condition group to identify the types of requests that qualify for rate limiting.
In the Match by option, select the method by which requests will be identified.
If you set this option to Request header, then you should also select the desired request header from the Request header name option.
Skip this step if you are matching by IP address. Otherwise, in the Match type option, determine whether the Value(s) option will contain one or more exact value(s) or a regular expression.
Perform either of the following steps:
Multiple Exact Match: In the Value(s) option, type the value that must be satisfied before a request will count towards the rate rule. Repeat this step as needed. Place each desired value on a separate line.
Use the Case sensitive option to determine whether a case-sensitive comparison will be performed.
Choose whether this condition will be satisfied when a request matches or does not match a value defined in the Value(s) option.
Optional. Add another condition to the current condition group by clicking + New condition and then repeating steps iv - vii.
If a condition group has been defined, then a request must satisfy all of the conditions within at least one condition group in order to be eligible for rate limiting.
Optional. Create another condition group by following steps i - viii.
Multiple condition groups provide the means for identifying different types of requests for the purpose of rate limiting.
To modify a rate rule
Navigate to the Rate Rules page.
To delete a rate rule
You cannot delete a rate rule that is associated with a Security Application Manager configuration. Please either modify the Security Application Manager configuration to point to a different rate rule or delete that Security Application Manager configuration.
Navigate to the Rate Rules page.
Edgecast CDN