Tagging
Last updated
Was this helpful?
Last updated
Was this helpful?
Link11 WAAP 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:
are generated automatically by L11WAAP.
Some system tags are always attached to the request. Other tags will vary, depending on the policies and security rulesets that were applied, or the disposition of the request.
Admins can define additional for specific circumstances.
During processing, tags can be used to make decisions about how the request is handled. For example, an 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 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.
As mentioned above, there are two types of tags:
System tags are created automatically by L11WAAP.
User tags are defined by admins.
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:
Every request receives certain tags, including all and several tags according to its source (the IP address, geolocation, etc.).
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
As L11WAAP processes a request, it will attach system tags to reflect what happened to the request during processing.
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.
sent-to-origin L11WAAP passed the request and sent it to the customer origin
upstream-status:xxx The response status code from the customer origin, if any
(Note: below, xxxis a placeholder for the name of the entity that was used.)
aclname:xxx
securitypolicy-entry:xxx
securitypolicy:xxx
contentfilterid:xxx
contentfiltername:xxx
cf-rule-id:xxx
cf-rule-category:xxx
cf-rule-subcategory:xxx
cf-rule-risk:xxx
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)
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.
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:
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.
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).
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, L11WAAP provides the Tag Finder feature.
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:
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.
One of the earliest stages of the is the Initialization stage. Here, L11WAAP attaches a variety of tags to the request, based on its characteristics.
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 that it matched.
System tags that can potentially be attached are shown at the appropriate places in the UI (generally, in the for a security ruleset or setting).
bot or human (bot is assigned to all requests unless the traffic source passes a , in which case its requests receive human)
User tags are defined and configured by admins, typically in a Tags field in a ruleset .
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 , 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 to be exempted from content filtering.
