Rate Limit
Rate limiting is a way to control incoming traffic to a network. For example, by using Rate Limit, it can be specified that the user is only allowed to send a certain number of requests per minute, and if the number of requests exceeds this amount, an error will be given and access will be banned. The purpose of implementing rate limiting is:
- Better traffic flow management
- Increasing security by preventing attacks such as DDoS, Brute Force, or any other type of malicious attacks in the application layer
Arvancloud Rate Limit Settings
Using Arvancloud's Rate Limiting feature, you can limit the number of requests per IP in seconds, hours, or days to a path or your entire domain.
Due to the fact that Arvancloud's Rate Limiting feature has provided the possibility of different rules in different routes, you can have a different policy and limit for each route.
Rate Limit Settings in User Panel
To apply a new rule, in the Arvancloud user panel, in the CDN section, and in the "Rate Limits" section, click on the Add Rule option.
In this section, you can set the following parameters to apply restrictions:
Limitation Path
Description
Number of Requests
Time Frame
Allowed Methods
Unrestricted IPs
Note that the way to enter the path must be in the form of Glob pattern.
In the Limit section, there are two fields "Number of Requests" and "Time Period". The number entered in the first field shows the maximum number of requests sent from an IP in the time period you specify. If the number of IP requests sent in that time period exceeds this amount, it will encounter a limit and receive a 429 error. On the other hand, the "Time Frame" field specifies the time period for which the specified "number of requests" can be sent from an IP. If more requests are sent from the same IP during in this period, the user will be faced with a limitation and error 429.
After specifying these two values, you can determine that if you made more requests from an IP than allowed, for a certain period of time, requests from this IP will be blocked with a status code of 429.
In the following, there is a list of allowed methods and IPs, which the defined limit in this law will not include the methods and IPs entered in it. In these two sections, you can specify which HTTP methods and IPs this restriction should not be applied to.
This field and the description field are not mandatory.
Finally, after submitting the desired information and selecting the save option, the restriction will be applied.
Choose Rate Limit Module Behavior
In the Rate Limit module, you can choose if the request rate for a certain path exceeds the defined limit, how Arvancloud should behave in response to requests. In this case, subsequent requests can be blocked or faced with a DDoS challenge. By choosing the DDoS challenge, you can determine the level of protection and also the validity period of the challenge.
Create a rule with the challenge operator using the API:
curl --location --request POST 'https://napi.arvancloud.ir/cdn/4.0/domains/example.com/rate-limit/rules' \
--header 'authority: napi.arvancloud.ir' \
--header 'accept: application/json, text/plain, */*' \
--header 'authorization: API KEY 1 2 3 4' \
--header 'cache-control: no-cache' \
--header 'content-type: application/json' \
--header 'origin: https://panel.arvancloud.ir' \
--header 'pragma: no-cache' \
--data-raw '{"is_enabled":true,"url_pattern":"example.com/**","description":"","exclude_sources":[],"rate":1,"burst":4000000,"block_duration":0,"time_duration":10,"allowed_methods":[],"action":"challenge","action_details":{"mode":1,"ttl":120,"https_only":false}}'
- In creating a rule with the challenge operator through the API, the mode parameter can be equal to three values: 1 for cookie challenge, 2 for JS challenge, and and 3 for captcha challenge.
- The TTL parameter indicates the time period for which the DDoS challenge is valid and the user will not be authenticated again until it expires.
Rate Limiting Settings via API
All Rate Limit settings that can be defined in the Arvancloud panel are available to you through the API according to the following table:
Example: Limiting Access to One Path per 20 Requests In a Day
Let's say you have a contact form on your website. To prevent DDoS or Brute Force attacks, you can define a limit corresponding to the number of requests received on the POST API of this form. For example, limit access to www.example.com/api/contact/form to 20 requests per day and block it for 24 hours if you receive more requests from an IP. Also, this restriction should not be applied to the GET method and from the source IP 1.2.3.4. You can apply this rule as follows through the panel and API.
curl --location --request POST 'https://napi.arvancloud.ir/cdn/4.0/domains/example.com/rate-limit/rules' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <Bearer Token>' \
--data-raw '{
"url_pattern": "example.com/api/contact/form",
"rate": 20,
"time_duration": 86400,
"is_enabled": true,
"description": "test",
"exclude_sources": [
"1.2.3.4/32"
],
"burst": 4000000,
"block_duration": 86400,
"allowed_methods": [
"GET"
]
}'
Prioritizing Constraints
When calculating the number of requests of a user and matching it with existing rules, priorities are calculated in order, starting with priority 1. That is, if a user encounters the restriction of rule 1, other rules with a lower restriction about this user will not be checked. With the help of prioritization for different routes, different policies can be determined for the site. For example, put routes with lower sensitivity at the beginning of the list and routes with higher sensitivity at the end of the rule list. Let's say you want to restrict users to access the following two paths:
| Path | Request Count | Time Frame |
|---|---|---|
| example.com/api/login/** | 5 | 60 s |
| example.com/api/** | 10 | 60 s |
In this case, it is better to set the first path with a rule with a higher priority (priority number 1) and the second path with a lower priority (priority number 2).