Tagging

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. Some are generated automatically by Reblaze, while admins can define additional tags for specific circumstances.

• Some tags are generated when analyzing the request. Metatags (described below) are always assigned. Other tags will vary, depending on the policies and security rulesets that were applied to the request

• 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.

Sometimes, admins will wish to see a list of all security entities that can potentially attach a specific tag, or that might use it in other ways. For this purpose, Reblaze provides a Tag Finder capability, discussed below.

Three Types of Tags

Tags can be categorized according to when they are assigned, and whether they are configured by admins or are built into Reblaze. The categories are:

• Metatags

• Automatic tags

• Admin-defined tags

Metatags

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:

• all

• geo-country:france

• geo-city:paris

• geo-region:idf

• geo-subregion:75

• geo-continent-code:eu

• geo-asn:12322

• geo-continent-name:europe

• ip:82-64-131-193

Automatic Tags

As Reblaze processes a request, it will attach automatic tags to reflect what happened to the request during processing.

Some types of automatic tags will always be attached. For example, every request receives tags that reflect the Security Policy that it matched.

Other automatic 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 automatic tags with descriptive names.

Some automatic 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.

Automatic 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).

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 Monitor - global filter - [name of the Global Filter] - [the type of Rule that matched]. Strictly speaking, these are not tags, since they cannot be used in ACL Policies and so on.

Automatic tag examples

Generic

• bot or human (bot is assigned to all requests unless the traffic source passes a bot challenge, in which case its requests receive human)

Security policy selection

• aclid:--default--

• aclname:default-acl

• securitypolicy-entry:default

• securitypolicy:default-entry

• contentfilterid:--default--

• contentfiltername:default-contentfilter

Triggered by mechanisms, e.g. Content Filters

• cf-rule-id:xxx

• cf-rule-category:xxx

• cf-rule-subcategory:xxx

• cf-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-sqli or -xss (per case)

• cf-rule-risk:libinjection

• cf-rule-category:libinjection

• cf-rule-subcategory:libinjection-sqli or -xss (per case)

Sometimes a request will get two separate tags that seem to be redundant. For example:

• securitypolicy-entry:default

• securitypolicy:default-entry

When a Security Policy is matched with a request, a tag is generated for the Policy itself, and for the 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.

Admin-defined tags

Some security settings include a "Tag" field where admins can specify tags.

Admin-defined Tags are created and selected via the Tag selector control, described here.

Note that these admin-defined tags do not replace the automatic tags. Rather, when a request triggers a ruleset, all of the specified tags (both automatic and admin-defined) are attached to it.

Unlike automatic 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 too that when admin-defined tags are configurable, the "Tag" field will generally accept more than one tag (separated by spaces). This provides even more flexibility, such as the ability to create a hierarchy of tag categories.

Tag Finder

Sometimes, admins will wish to see a list of all entities that can attach a specific tag. For example, when examining a request in the Events Log, an admin might want to verify the source of a particular tag. Or, when editing a security configuration, it can be useful to see which other configurations generate or rely on a particular tag.

For this purpose, Reblaze provides a Tag Finder feature.

Opening the Tag Finder

In the UI, simply click the tag, and a panel will appear with a list of all the entities that use or can generate that tag. This can be done from the Events Log, and also when editing individual security entities.

Here is an example from the Security Policy editor:

When this Security Policy is applied to a request, the all tag will be attached.

Clicking the tag will display the Tag Finder, showing that this tag is also used in two ACL Policies and a Flow Control Policy.

• Hovering the cursor over an entry will display a button, allowing the admin to 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.

Inspecting tags in security entities

When editing a security entity, hovering the cursor over a tag will show an x for removing that tag. To open the Tag Finder instead, the part of the tag to the left of the x must be clicked.

As shown below, when the tag has a short name, the available area is small, and some precision might be required.