Rate Limiting on VergeCloud

Introduction

Rate limiting is a mechanism to manage the flow of incoming traffic to a network. VergeCloud’s Rate Limiting feature enables users to control the number of requests a user can make per specified time period (e.g., per minute, hour, or day). If the request threshold is exceeded, the user's access can be temporarily restricted, enhancing security and optimizing traffic flow. Common uses of rate limiting include:

• Improving traffic flow management.
• Enhancing security by preventing attacks like DDoS, Brute Force, and other malicious application-layer attacks.

Glossary

• Rate Limiting: A technique to control the number of requests a user can make within a certain time frame.
• Path: The specific URL or endpoint to which the rate limit applies.
• Glob Pattern: A syntax for defining path patterns, often used in URL configurations to specify paths broadly.
• DDoS Challenge: A validation step used to block bots and malicious actors from overwhelming a network with requests.

Real Usage Scenarios

Rate limiting is widely used to secure websites and APIs. For instance, an online service might apply rate limits to prevent excessive login attempts, thus protecting against brute force attacks. Additionally, public-facing APIs can apply limits to prevent users from overwhelming the system with too many requests, ensuring fair usage and stability.

VergeCloud Rate Limit Settings

With VergeCloud's Rate Limiting feature, users can set restrictions on the number of requests from individual IPs to specific routes or to the entire domain over various time periods (seconds, hours, days). Unique policies can be defined for different routes, allowing tailored access control across site resources.

How to Add/Edit Rate Limit Settings in VergeCloud

To set up a new rate limit rule, navigate to the VergeCloud dashboard under the CDN section. In the Rate Limits tab, click on Add Rule. Here, you can configure the following fields:

Rate Limit Parameters

• Limitation Path: Define the URL path where the rate limit applies. Use a Glob pattern format.
• Number of Requests: Set the maximum number of requests allowed from a single IP within the specified time frame.
• Time Frame: Define the duration (in seconds, minutes, hours, or days) over which requests will be counted.
• Allowed Methods: Specify HTTP methods (e.g., GET, POST) exempt from rate limiting.
• Unrestricted IPs: List IPs exempt from the restriction.

Once all fields are filled in, click Save to apply the rule.

Note: Fields such as Description are optional.

Choosing VergeCloud Rate Limit Module Behavior

In the Rate Limit module, users can choose how VergeCloud should respond if the request rate for a particular path exceeds the defined limit. Options include blocking further requests or initiating a DDoS challenge. When selecting the DDoS challenge, you can customize the challenge level and its duration.

Testing and Validation

To validate your rate limit configuration:

• Use the curl command to simulate requests and check response codes. Requests exceeding the set limit should return a 429 Too Many Requests error.
• Use dig to inspect DNS configurations if your rate limits include DNS-dependent features.
• Verify by visiting the path in a browser. If the limit is exceeded, you should encounter either a block or a DDoS challenge prompt, depending on the chosen behavior.

Example Scenario: Limiting Access to a Path with 20 Requests Per Day

Assume you have a contact form at www.example.com/api/contact/form. To prevent DDoS or Brute Force attacks, you can limit access to this endpoint to 20 requests per day. If this threshold is exceeded, the IP will be blocked for 24 hours. This restriction can be applied through the VergeCloud dashboard or API, excluding the GET method and source IP 1.2.3.4.

Prioritizing Rate Limit Rules

VergeCloud evaluates rate limit rules based on priority, starting with the highest priority rule (priority 1). Once a request matches a rule, lower priority rules are ignored for that request. By adjusting priorities, you can apply more lenient or stringent policies to different routes.

Example: To secure the following paths with different priorities:

Set the first path with higher priority to ensure specific protection for login attempts, while general traffic to example.com/api/** remains more accessible.