Tagging
Overview
Reblaze uses an intuitive tag-based system for evaluating and processing traffic.
As an incoming request is analyzed and processed, internal tags are generated and attached to it:
System tags are generated automatically by Reblaze, while admins can define additional user tags for specific circumstances.
Some system tags are always attached to the request. Other tags will vary, depending on the policies and security rulesets that were applied.
During processing, tags can be used to make decisions about how the request is handled. For example, an ACL Profile might block all requests that contain a specific tag.
Tags will also be attached to reflect decisions that were made. For example, a request that was blocked because it violated a Rate Limit Rule will be assigned a tag containing that Rate Limit Rule's name.
Once processing is complete, all of the request's tags are included in the traffic analytics and logs.
Tag categories
As mentioned above, there are two types of tags:
System tags are created automatically by Reblaze.
User tags are defined by admins.
System tags
System tags are attached to the request at different stages of traffic processing. In the UI, they are displayed in blue, as in this Security Policy example:
Attached during initialization
One of the earliest stages of the traffic filtering process is the Initialization stage. Here, Reblaze attaches a variety of tags to the request, based on its characteristics.
Every request receives certain tags, including all and several tags according to its source (the IP address, geolocation, etc.).
Examples
allgeo-country:francegeo-city:parisgeo-region:idfgeo-subregion:75geo-continent-code:eugeo-asn:12322geo-continent-name:europeip:82-64-131-193
Attached during processing
As Reblaze processes a request, it will attach system tags to reflect what happened to the request during processing.
Some types of system tags will always be attached (assuming that the request makes it far enough into the processing sequence). For example, every request receives tags that reflect the Security Policy that it matched.
Other system tags will depend on the disposition of the request. For example, requests which violate a security ruleset (such as a Rate Limit Rule) or fulfill a condition (such as being the last request in a Flow Control Policy sequence) will receive tags with descriptive names.
Some system tags have their names generated during processing. When tag names are generated from underlying values (IP addresses, security rule names, etc.), hyphens will replace spaces and special characters.
System tags that can potentially be attached are shown at the appropriate places in the UI (generally, in the Editor page for a security ruleset or setting).
Examples:
Generic
botorhuman(botis assigned to all requests unless the traffic source passes a bot challenge, in which case its requests receivehuman)
Security policy selection
aclid:--default--aclname:default-aclsecuritypolicy-entry:defaultsecuritypolicy:default-entrycontentfilterid:--default--contentfiltername:default-contentfilter
Triggered by mechanisms, e.g. Content Filters
cf-rule-id:xxxcf-rule-category:xxxcf-rule-subcategory:xxxcf-rule-risk:xxx
Libinjection tags
If a request matches a libinjection check during Content Filtering, the following tags will be added:
cf-rule-id:libinjection-sqlior-xss(per case)cf-rule-risk:libinjectioncf-rule-category:libinjectioncf-rule-subcategory:libinjection-sqlior-xss(per case)
While processing a request, there is other information that might get attached to a request. For example, when a Global Filter matches a request and its Action is set to "Monitor", this will be shown in the Events Log with a Monitor reason named Global filter:[name of the Global Filter]. These are not tags, since they cannot be used in ACL Policies and so on.
Sometimes a request will get two separate tags that seem to be redundant. For example:
securitypolicy:default-security-policysecuritypolicy-entry:--default--
When a Security Policy is mapped to a request, a tag is generated for the Policy itself, and for the path-map entry within that Policy that was used. If the names are similar (which is true for default values, as in the example), then the tags can appear to be redundant.
User tags
User tags are defined and configured by admins, typically in a Tags field in a ruleset Editor page.
Admin-defined tags do not replace the system tags. Rather, when a request triggers a security ruleset, all of the specified tags (system and user) are attached to it.
Administration
Admin-defined Tags are created and selected via the Tags dropdown list. Initially, it appears as in this Security Policy example:
When expanded, the Tags list looks like this:
Adding user tags
To add an existing user tag, find it in the list (or start typing its name into the Search field), and select its checkbox.
To define a new user tag, type its name into the Search field and hit Enter. The tag will be created, and will be automatically selected for use.
Unlike system tags, admin-defined tags do not need to be unique. Therefore, admins can use them to combine different categories of requests for later processing. For example, there might be several different Global Filters, each of which defines a category of requests to be allowlisted. An admin might specify the same tag (e.g., trusted) for each one, and then have that tag configured in an ACL Profile to be exempted from content filtering.
Note that the Tags field will accept more than one tag, separated by spaces. This provides even more flexibility, such as the ability to create a hierarchy of tag categories.
Removing user tags
When editing a security entity, hovering the cursor over the Tags control will display an X at the end of the control. Clicking on this will remove all tags from the entity.
As shown above, hovering over a tag will also show an x on that tag. Click on it to remove only this specific tag from the entity.
When a tag is removed from an entity, and no other entity uses this tag, it will also be removed from the list of available tags displayed within the Tags list.
If it is needed again in the future, it can be restored by defining it again as a new tag (i.e., by entering it into the Search field and selecting Enter).
Displaying tag usage
Sometimes, admins will wish to see a list of all uses of a specific tag. Examples:
When examining a request in the Events Log, an admin might want to verify the source of a particular tag.
When editing a security configuration, it can be useful to see which other configurations generate or rely on a particular tag.
An admin might also want to see all requests in the Events Log which had a specific tag attached.
For this purpose, Reblaze provides the Tag Finder feature.
Tag Finder
The Tag Finder lists all current usages of a given tag. It works for both system tags and user tags.
To open the Tag Finder in the UI, simply click the tag. Here's an example (a tag named static-content) from a Global Filter:
The Tag Finder is available when editing various types of security entities, and also from the Events Log.
When a tag is clicked, the Tag Finder panel will appear with a list of all the entities that use or can generate that tag:
In this example, along with the Global Filter that is currently being edited, the tag is also used in two Rate Limit Rules.
As shown above, hovering the cursor over an entry will display a button that will open the relevant security entity in the UI.
At the bottom, there is also a button to open the Events Log, pre-populated with a filter to display all requests that have this tag attached.
Last updated
