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.

Tip

If you only want to create Access control lists (ACL), check our Allowed IPs and Blocked IPs 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
JS Challenge	Displays a JavaScript 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.

Tip

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.