Link11 WAAP
v5
v5
  • Link11 WAAP Documentation
  • Release Notes
  • Known Issues
  • User Guide
    • Introduction to Link11 WAAP
  • How Link11 WAAP Works
    • Traffic Filtering Process
    • Traffic Reporting and Analytics
    • Policy Mapping and Traffic Routing
    • Tagging
    • UI Overview and Common Elements
  • Console UI Walkthrough
    • Analytics
      • Dashboard
      • Events Log
    • Security
      • Global Filters
      • Flow Control Policies
      • Security Policies
      • Rate Limit Rules
      • ACL Profiles
      • Actions
      • Dynamic Rules
      • Quarantined
      • Content Filter
        • Content Filter Profiles
        • Content Filter Rules
    • Sites
      • Server Groups
      • Proxy Templates
      • Mobile Application Groups
      • Backend Services
      • Edge Functions
      • DNS Records
      • SSL
        • Load Balancers
        • Certificates
    • System
      • Interactive Challenge
      • SSO Configuration
      • Purge CDN Cache
      • Users Management
      • Security Alerts
      • Log Exporters
      • Version Control
      • System DB
      • Publish Changes
    • Account
  • Using the product
    • Best Practices
      • Saving and Publishing Your Changes
      • Enabling Passive Challenges
      • Understanding and Diagnosing Traffic Issues
    • How Do I...
      • Authenticate mobile app users
      • Ban, unban, and allowlist traffic sources
      • Bypass Link11 WAAP for loadtesting or other purposes
      • Configure a new path/section of a site
      • Control caching behavior
      • Enable GraphQL traffic
      • Enable mTLS (mutual TLS)
      • Protect sensitive information in logs and analytics
      • Quickly block an attacker
      • Redirect or block HTTP traffic
      • Run custom code
      • Set rate limits and exemptions
      • Stream event data to a SIEM solution or other destination
    • The Link11 WAAP API
      • Overview
      • Internal data structures
      • Using Swagger UI
      • Using curl
  • Reference Information
    • Acronyms
    • API
      • API access to traffic data
      • Types of namespaces
      • Namespace reference
        • ACL Profiles
        • Actions
        • Backend Services
        • Certificates
        • Configs
        • Content Filter Profiles
        • Content Filter Rules
        • Data queries
        • Dynamic Rules
        • Edge Functions
        • Flow Control Policies
        • Global Filters
        • Load Balancers
        • Log Exporters
        • Mobile Application Groups
        • Planets
        • Proxy Templates
        • Rate Limit Rules
        • Security Alerts
        • Security Policies
        • Server Groups
        • Tags
        • Tools
        • Users
    • Hostile Bot Detection / LWCSI
      • Environmental detection and browser verification
      • Client authentication
      • Biometric behavioral verification
    • HTTP Response Codes
    • Log Exporter Output
    • Pattern Matching Syntax
    • Query Filter Syntax and Best Practices
  • Support
Powered by GitBook
On this page
  • Overview
  • Tag categories
  • System tags
  • Attached during initialization
  • Attached during processing
  • User tags
  • Administration
  • Adding user tags
  • Removing user tags
  • Displaying tag usage
  • Tag Finder

Was this helpful?

Export as PDF
  1. How Link11 WAAP Works

Tagging

PreviousPolicy Mapping and Traffic RoutingNextUI Overview and Common Elements

Last updated 20 days ago

Was this helpful?

Overview

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.

When using tags to make decisions during the , only tags that were generated before the relevant step are available. For example, sent-to-origin and upstream-status:xxx are only available for use in , because they are not attached until after L11WAAP has passed the request to the customer origin.

Tag categories

As mentioned above, there are two types of tags:

  • System tags are created automatically by L11WAAP.

  • 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

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

Attached during processing

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.

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.

Examples:

Generic

  • 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

Security rulesets

(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

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)

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-policy

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

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.

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, L11WAAP 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.

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.

traffic filtering process
Security Policy
bot challenge
Global Filters
ACL Profile
ACL Profile
Rate Limit Rule
traffic filtering process
System tags
user tags
Editor page
Editor page
The dropdown list is for administering user tags, described further below.
Dynamic Rules