Overview
As part of the WAF rules editor, users are able to create custom rules revolving around tags to help further filter incoming traffic. A tag contains information about an end-user and is attached to their request. Tag rules are just one component of StackPath's robust rule engine. There are two types of tag rules that users can create: tag based rules and tag generating rules.
Basic tag based rules are created using pre-defined sets of tags provided by StackPath. Tag generating rules allow you to create your own custom tags according to the conditions you define to be applied to incoming requests. These custom tags are called user defined tags, and can be used to customize your tag based rules by allowing you to create even more complex rule sets.
Tag Based Rules
By defining specific if/then statements in the portal, users are able to block and allow certain requests to protect their site. StackPath offers a pre-defined set of tags that are available to you, which you can then use to create basic tag based rules.
In the example below, we set up a tag based rule that will block traffic if the tag associated with the request contains Hosting Services. The reason why we want to block traffic coming from hosting services, is because these IPs are more likely to belong to automated users rather than human users.
WAF Requests
It is recommended that you review the details of your WAF Requests prior to creating these tag based rules, as these details contain the tags associated with end-users. You can use this information to help you determine which tags in the list to use in your rules to filter traffic. For a list of these pre-defined tags and their descriptions, please refer to our guide here.
Tag Generating Rules
In addition to the availability of pre-defined tags, the WAF also provides you with the ability to create rules that will generate custom tags of your choice based on the conditions you define. We call these custom tags, user defined tags. Once a user defined tag is created, it's then added to the list of pre-defined tags, making it available for you to use in a tag based rule.
In our next example, let's say we are running an online shop that requires users to be logged-in before checking out for verification purposes. We will create a rule to generate a custom tag named validuser if the header named set-cookie contains a cookie named mycookie, which indicates that the user is logged-in.
Using User Defined Tags
In our example above, validuser is our new user defined tag that's now available for us to use in a tag based rule. With that said, in the example below, we are going to be allowing all requests that contain the user defined tag validuser, as we know these users are verified because they are logged-in. This will ensure that our logged-in users do not encounter any unwanted WAF blocks.
Please note that user defined tag rules run before other rules that use our pre-defined sets of tags.
Reserved Tags (Magic Tags)
Reserved tags, or magic tags, are pre-defined tags that trigger specific actions. Unlike user defined tags, reserved tags are not completely customizable, however, they do play a key role in tag generating rules.
Below are some use cases and examples of reserved tags along with their descriptions.
Use Cases
Pre-condition
Using Reserved tags, you'll only need to create a single WAF rule that can be used later on in other rules used to tackle same use case.
For example, you have a set of WAF rules that deal with orders originating from certain countries.
With tag generating rules, you only need to tag the use case with something like ‘Order from high-risk countries', and then look for this tag in every rule within your rule set.
If you need to add or remove a country from one of your rules, all you need to do is go to the main rule that created the tag and update it, which in turn updates all other sets of rules using this tag simultaneously.
Testing a rule condition
If you perform traffic analysis and want to track certain cases without taking any action on them, then tagging specific types of requests will enable you to do so without intervening with the natural flow of your WAF policies and custom rules. You will be able to click on the requests and see if they hold the tag you’ve created.
This is true also for optimizing an existing rule. If you created a rule and are noticing false positives, then marking a tag with a designated future rule will enable you to specify if your future rule does a better job of defining the conditions to trigger it.
'Logged in' and 'Registered' Users
You can tag requests that are coming from a Logged in or a Registered user. Set this up using a secure condition (e.g. IP=1.2.3.4), or use a signal from the server response to mark this tag.
For example, you can create a rule that looks for a set-cookie header with a cookie that designates logged in users, or you can inject a special header for logged in users, where the WAF can look for this info with a rule formed on the response phase and tag the request.
The WAF Rules engine will see this tag and add it to the user session for you to use on other requests from the same session, as well as take that into account when it will process the risks from this client.
Monitor
When you will tag a request with the Monitor tag, you will be able to see these requests within the requests graph.
This was usually done using the Monitor action. However, with the Monitor action, if conditions are met, the rest of the rules engine will take this as the action of the request and other rules and actions will not be processed, which may not be your original intention.
The Monitor Reserved tag will replace the Monitor action, as tag generating rules don’t inhibit other rules and do not interfere with other actions.
Ignore Automation
This functionality will notify the WAF of legit automation behavior and exclude them from our anti-automations policies. This means you can still benefit from the protection of unknown automation while still allowing legit known automations to create traffic without being interrupted by the WAF.
Login Pages
This tag will notify the WAF if certain endpoints are used as login pages. This functionality will help identify certain attacks, such as brute force attacks.
‘Malicious Activity’ and ‘Legitimate Activity’
Using thresholds configured by Support, the WAF will recognize and tag requests as being either malicious or legitimate.
For example, the WAF can be configured to identify malicious/legitimate actors based on the thresholds of declined/successful orders that need to be exceeded.
If the threshold for declined orders is set to three, and the threshold for successful orders is set to two, then a client would be considered a legitimate actor if it made two successful orders after being wrong twice.
Denial of Inventory Detection
This mitigation method aims to detect hoarder bots using endpoints such as add to cart and checkout, cookies and more. The WAF will calculate the number of items held in each clients' cart, and using thresholds configured by Support, tag each one that did not check out as hoarderbot if the threshold is exceeded.
Please reach out to Support to inquire about Malicious Activity, Legitimate Activity and/or Denial of Inventory Detection tags, as these require additional configuration.