Global Filters

Assigning tags and (potentially) executing an Action

Overview

This page allows you to administer Global Filters. These are applied to each request early in the traffic filtering process.

A Global Filter has two purposes:

  • It 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 traffic analytics.

  • It also contains an Action, which can be executed when the Filter's conditions are met.

For each request, Link11 WAAP will evaluate all active Global Filters. The request will receive tags from all Filters which match it.

After all Filters have been evaluated, L11WAAP will execute the highest-priority Action found in those Filters which matched the request.

Two types of Global Filters

There are two types of Global Filters:

  • System-managed, which are maintained by Link11.

  • Admin-managed, which are maintained by customer admins.

They vary in their visibility, alterability, and sources for Rule lists (i.e., the criteria for determining if a Filter should be applied to the request being analyzed).

System-managed Global Filters

These are provided and maintained by Link11. Most use external datafeeds as the sources of their Rule lists.

Datafeed-based Filters are updated regularly by Link11. Admins can also trigger an immediate refresh by selecting the Update now button on the Editor page.

Most system-managed Filters are visible to admins in the interface, with the ability to edit some of their parameters.

Depending on traffic conditions, some additional Filters might exist that are not visible to admins. Each active Dynamic Rule creates an internal Global Filter to enforce its restrictions. These are managed automatically by the system, and are mentioned here purely for informational purposes.

Changing system-managed Global Filters might result in unexpected behavior. For example, the Let's Encrypt Requests Global Filter is necessary for customers who want to use Let's Encrypt to generate or renew their own SSL certificates.

Admin-managed Global Filters

These are created and managed by admins. They are fully editable within the interface.

Typically, admins will manually create and manage their Rule lists, although these Filters can also be based on external data sources.

Administration

The administration of Global Filters follows the List/Editor UI conventions described here.

The main List page (shown above) lists all current Global Filters. The Editor page (discussed below) enables administration of individual entries.

Components

Each Global Filter consists of:

  • Tag(s) to assign to requests that match the Rule list.

  • Rule list: The possible characteristics that a request could match (e.g., a list of IP addresses that it might originate from).

  • An Action that, if a match occurs, will be executed after all active Global Filters have been evaluated, unless a higher-priority Action overrides it.

  • General parameters for administrative purposes.

Each of these is described in depth below.

Individual Parameters

The discussion below will focus on admin-managed Filters. For system-managed Filters, the parameters that are editable will work the same as discussed below.

A Global Filter, opened in its Editor

General parameters

  • Name. A description that will be displayed within the L11WAAP interface.

  • Active. By default, this Global Filter will be evaluated for all incoming requests. To deactivate it, unselect this toggle.

  • Description: Information about this Filter, for use within the interface.

  • Source: For datafeed-based Global Filters, this contains the URL of the source. Otherwise, this field should be set to self-managed.

Tags

This field contains one or more user tags (separated by spaces) that will be assigned to all requests that fulfill the Rule list. Example: internal team-devops

Action

The choices for this parameter are administered in the Actions page.

The Action that is selected here will be applied globally to all requests that match the Rule list.

If a request triggers an Action, the Action is performed after all Global Filters have been evaluated and all applicable tags have been attached to the request.

Rule list

The Rule list is generated in different ways, depending on the source of the data.

Datafeed-based Global Filters

Many Global Filters obtain their Rules from an external source, specified by the URL in the Source field. Some are maintained by Link11; others can be created and maintained by admins.

  • System-managed Global Filters based on datafeeds are maintained automatically. Their underlying data sources are refreshed every 24 hours, and the Global Filters are updated automatically.

  • Admin-managed Global Filters based on datafeeds are initially created by entering the URL of the source file into the Source field, then selecting the Update now button that appears. L11WAAP will then populate the Rule list automatically. To refresh the Rule List, simply select the Update now button again.

"Self-managed" Global Filters

Many Global Filters will be based on criteria that are not found in an external feed. In this situation, the Source field will say self-managed.

Typically, most admin-managed Filters will have this setting, with their Rule lists being created and maintained manually (described below). It is also possible for a system-managed Filter to have this Source setting.

To avoid confusion, note that "self-managed" does not mean "managed by admins instead of the system". Rather, it means "using Rules defined directly by specific criteria instead of being pulled from a datafeed".

Manually creating a Rule list

When a new Global Filter is created, its Rule list will be empty, as shown above.

A Rule list contains one or more Sections. Each Section contains one or more Entries, where each Entry defines a match condition for evaluating requests. Sections can also contain one or more nested Sections.

When a Section contains multiple items (whether Entries or other Sections), its Section Relation button defines the logical condition (either AND or OR) to apply among those items.

Example: A Rule list contains two sections, with the overall Section Relation set to AND. The first section has criteria a, b, c and the second has i, j, k . Within each section, the Section Relation is set to OR. Thus, 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)).

Defining a Section

To create a new Section, select the + New Section button. (If this button is not available, verify that the Source field is set to self-managed.)

Defining an entry

To create an Entry within a Section, select the + New Entry button. The following dialog will appear:

For some 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 optional individual annotation (a label for display within the L11WAAP interface). If individual annotations are not provided, then L11WAAP will assign the content of the Annotation field to each entry. Example:

For other categories, one entry can be made at a time. Annotations are defined in the Annotation field, and are not preceded by a pound sign.

Most Rule criteria are case sensitive. The exception is Header, where the criteria are not case sensitive.

Category and Match

The Match parameter will vary, depending on the chosen Category.

Category
Match
Comments

Argument

Name: exact match, case sensitive. Value: regex

ASN

Exact match for ASN number

Authority

Regex

Combination of the domain and (optional) port

Cookie

Name: exact match, case sensitive. Value: regex

Country

Exact match

Header

Name: exact match, case insensitive. Value: regex

IP Address

Exact match for IP, CIDR

Method

Regex

Organization

Regex

Example: the Organization for ASN AS15169 is Google LLC.

Path

Regex

Path Matching Name

Exact match

Query

Regex

Region

Regex

Security Policy Name

Exact match

Subregion

Regex

Tag

Exact match

URI

Regex

Path + query

Currently, there is not a category for a request's protocol. However, you can still create a protocol-based Global Filter by specifying an appropriate Tag, for example protocol:http or protocol:https. This is useful when blocking or redirecting unencrypted HTTP traffic (how to do this).

Examples

Here are some sample entries for the various categories. (Note that when the Rule list is displayed like this, for criteria that consist of Name and Value fields, the system displays a colon between them. This colon is not included when entering the criteria.)

Editing the Rules list

A Rule list for admin-managed Global Filters can be edited. Hover the cursor over the Entry that you wish to edit, and an "edit" button (a pencil icon) will appear. Select this button, and the Entry can be edited. After editing is complete, select the "confirm" button (a checkmark), then save the changes, and publish them.

Last updated

Was this helpful?