Custom rules
Using custom rules is a great way to ensure a thorough assessment and filtering of web requests. You can control access to specific URLs, limit access to your application, allow or block countries or organizations, and adjust WAAP behavior to a variety of use cases.
If you only want to create Access control lists (ACL), check our Allow and block IP addresses guide.
You can create the following types of custom rules:
WAAP rules consist of two key elements: rule type that defines the conditions for matching a rule and an action that will be enforced when the rule is triggered.
Rate limit rules allow you to set the limit for the number of requests allowed within a particular time range.
Tag rules contain tags, which are added to existing rules and function as identifiers for monitoring and analytics purposes. You can also create custom rules based on tags.
Actions in custom rules
Rule actions are triggered based on the conditions you specify. If you create multiple rules with the same conditions, then only the action with the highest priority level will take place.
For example, you’ve created a rule that allows all requests from 1.1.1.1 to access your application, and then you added another rule to present a captcha response page to 1.1.1.1. In this situation, only the Allow action will be triggered because it has a higher priority level than the CAPTCHA action.
The following table features all rule actions along with their priority levels.
| Action | Description | Priority level |
|---|---|---|
| Allow | Allows specified traffic to view the application's content and exclude the user from any security checks. | Second |
| Block | Blocks specified traffic from accessing the application's content. | Third |
| Captcha | Displays a CAPTCHA challenge before the user can view the application's content. | Fourth |
| Browser validation | Displays a Browser validation challenge before the user can view the application's content. | Fifth |
| Tag | Tags a request with the custom user-defined tag you specify. This action type doesn’t send any challenge to the user and only adds information to a request. All tag action rules run first before any other action type. They don’t stop the rule engine even after the condition has been met and the tag has been applied. Thus, the user-defined tags that are generated in this run can be used in the "user-defined tag" condition of the same run (during the same request processing). |
N/A Tags work in parallel—if a request is blocked, it can still be tagged. |
The Tag action doesn’t challenge requests. Thus, it has no assigned priority level.
Rule conditions
When creating a rule, it’s important to choose a proper type of condition that defines when the rule will be triggered. The following table features the available custom rule conditions.
| Condition type | Description |
|---|---|
| IP | Challenge requests based on a specified IP address. You can also enter multiple IP addresses, separated with commas. You cannot enter a subnet. |
| IP range | Challenge requests based on a specified IP address range. For example, if you enter 8.8.8.8 and 10.10.10.10, then every address higher than 8.8.8.8 and every address lower than 10.10.10.10 will trigger the rule. |
| URL | Challenge requests based on a specified URL. The expression may start with a slash (/) to represent the path following the hostname in the URL. You can create the rule to trigger for: An exact match, such as "/index.html". In this case, you must start with a slash (/)A partial match, such as "index". In this case, any request that contains an "index", such as /index.html, /index.htm, /index.php, will activate the rule.
|
| User agent | Challenge requests based on a specified user agent. You can create the rule to trigger for: An exact match that will include a specific user agent. For example, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko). Chrome/44.0.2403.157 Safari/537.36. A partial match that will include a more general user agent type, such as AppleWebKit. In this case, any user agent with AppleWebKit will trigger the rule. |
| Header | Challenge requests based on a specified header. |
| Header exists | Challenge requests depending on whether a specific header NAME is present in the request. For example, if a request doesn't include the User-Agent header name, then such request should be blocked or challenged. |
| HTTP method | Challenge requests based on a specified HTTP method, such as GET, POST, and others. |
| File extension | Challenge requests based on a specified file type, such as pdf, jpeg, jfif, and exe. |
| Content type | Challenge requests based on a specified content type, such as application/pdf. |
| Country | Challenge requests based on the country associated with the requesting IP address. This challenge is based on public IP address databases. |
| Organization | Challenge requests based on the organization associated with the requesting IP address. This challenge is based on a public database that contains known ranges relating to organizations. |
| Owner types | Challenge requests based on the category associated with a related IP range. For example, an IP range can be categorized as Commercial, CDN, or related to Hosting services. |
| Session request count | Challenge requests based on the number of requests made within a session (per session ID). |
| Tag | Sanction requests based on specific pre-defined tags provided by Gcore. View the full list of tags, their API slugs, and their descriptions in our dedicated guide. |
| User-defined tag | Sanction requests based on custom-generated tags named "user-defined tags". You can create these tags in the Customer Portal or via API. For more details, check out the Tag generating rules. |
Was this article helpful?