Tag Rules
Overview
Early in the traffic evaluation process (immediately after evaluation of Quarantines and Dynamic Rules), Reblaze can assign one or more Tags to an incoming request. Subsequently, the Tags can be used to make decisions about how the request is processed. After processing, a request's Tags remain associated with it, and they are available for display in the View Log.
This page allows you to administer Tag Rules, which are combinations of Tags and the criteria for assigning them to requests.
Each Tag Rule consists of:
Match conditions: A description of possible characteristics that a request can match (e.g., a list of IP addresses that it might originate from).
One or more Tags to assign when a match occurs.
An Active toggle to enable the Rule.
An Action to take immediately when a match occurs. Other Actions might be taken later as well; more on this below.
For each request, Reblaze will evaluate all active Tag Rules. A single request will receive Tags from all Rules which match it.
Two Types of Tag Rules
Tag Rules can be either Reblaze-managed or self-managed.
Reblaze-managed Rules are maintained by Reblaze. Most of these are based upon online data feeds (e.g., Spamhaus DROP lists), and are updated frequently and automatically. The match conditions for these rules are not editable in the interface, although the remaining parameters (Active, Tags, Action, etc.) still are.
Self-managed Rules are created and managed by admins. These Rules are fully editable within the interface.
Administration
The main window (shown above) lists all current Tag Rules.
To edit an existing Rule, select the Edit icon at the end of its entry in the list. To delete a Rule, select the Edit icon, and then within the window that appears, select the Trash icon.
To add a new Rule, select the + button in the main window, or edit an existing one and choose the Duplicate button at the top right.
The discussion below will focus on self-managed Rules. For Reblaze-managed Rules, the parameters that are editable will work the same as discussed below.
Editing a Tag Rule
General Parameters
Name. A description that will be displayed within the Reblaze interface.
Active. By default, this Rule will be evaluated for all incoming requests. To prevent this, unselect the checkbox.
Tags. One or more Tags (separated by spaces) that will be assigned to all requests that fulfill the match conditions. Example:
internal team-devopsNotes: An optional field for including information about this Tag Rule.
Action Parameter
The choices for this parameter are described in Action Response.
The Action that is selected here will be applied globally to all requests that match the Match Conditions.
To apply an Action to only some of the matching requests instead:
Choose the Tag Only Action and an appropriate Tag
Create an ACL Policy for that Tag
Assign the ACL Policy to a Security Profile
Assign the Security Profile to the relevant section(s) within application(s) in the Web Proxy page.
Match Conditions
Match conditions consist of two parts:
A list of one or more criteria to match.
If the criteria are organized into multiple sections, the Entries Relation specifies the logical condition to apply (either OR or AND) among the sections.
Match Criteria for a Rule based on an external data feed
Some Tag Rules are based on external data feeds. (Many of the Reblaze-managed Tag Rules fall into this category.)
Enter the URL of the data feed into the Source field, then select the update now button that appears. Reblaze will then populate the criteria list automatically.
As an example, to create a list based on the Spamhaus ASN DROP list, you would enter https://www.spamhaus.org/drop/asndrop.txt, and then select the "update now" button.
(Note that this example is for illustration only. An out-of-the-box deployment should contain the ASN DROP list already as a Reblaze-managed list.)
A self-managed Tag Rule based on an external data feed should be refreshed frequently, to re-query the data source. This can be done by opening the Rule for editing, then selecting the update now button next to the Source field. For convenience, you can also do this directly from the list of Rules in the main window; in the entry for the self-managed Rule, an Update now button will appear before the Edit icon.
If the criteria are organized into multiple sections--which is unlikely for a feed-based Tag Rule, but not impossible--also choose the appropriate value for Entries Relation, as discussed below.
Match Criteria for a Rule based on custom criteria
Many Tag Rules will be based on specific criteria for a use case--criteria that are not found in an external feed.
To add match criteria, select the Create new section button. (If this button is not available, verify that the Source field is set to self-managed.)
A new section of criteria will be available, and the following dialog will appear.
For most of the criteria categories, the dialog will appear as it is above. Multiple entries can be made at once, with each entry on a separate line. Each line contains the value, plus a pound sign (#) followed by an annotation (a label for display within the Reblaze interface). Example:
For some categories, one entry can be made at a time, with each entry requiring multiple fields. Annotations are not preceded by a pound sign.
Match criteria are case-sensitive. The exception is Header keys, where match criteria are case-insensitive.
Here are some sample entries for the various categories. Notice that the logical operators are available.
Once created, these entries cannot be edited. If one needs to be modified, remove it and re-create it.
Multiple sections and the Entries Relation parameter
The first criterion added to a Tag Rule will be in one section. If additional criteria are added, they are all evaluated with an OR. (For a request x and list of criteria a, b, c , the evaluation will be (x==a) OR (x==b) OR (x==c) ).
You can add additional sections by selecting the Create new section button. Each section will similarly use OR internally.
However, when there is more than one section, an additional evaluation must occur among the results of the individual sections. The Entries Relation selector specifies the logical operation used here.
Example: there are two sections. The first section has criteria a, b, c and the second has i, j, k . The Entries Relation is set to AND. For a request x, the evaluation will be ((x==a) OR (x==b) OR (x==c)) AND ((x==i) OR (x==j) OR (x==k)).
