Global Filters
Assigning tags and (potentially) executing an Action
Last updated
Assigning tags and (potentially) executing an Action
Last updated
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, Reblaze will evaluate all active Global Filters. The request will receive tags from all Filters which match it.
After all Filters have been evaluated, Reblaze will execute the highest-priority Action found in those Filters which matched the request.
There are three types of Global Filters:
Datafeed-based
Self-managed
Dynamic
Each has a different source for its Rule list (i.e., its criteria for determining if a Filter should be applied to the request being analyzed).
These use an external URL as a data source. Many of these Filters are provided by Reblaze and included out of the box, based upon online data feeds (e.g., Spamhaus DROP lists). Admins can also add new Filters of this type. For Datafeed-based Filters, the Rule list is pulled from the data source, and it is not editable in the interface.
These are created and managed by admins. These are fully editable within the interface.
Self-managed Global Filters are not maintained by Reblaze. They must be kept up-to-date by admins.
Self-managed Filters that are based on an external data source are updated by selecting the "update now" button on the Editor page.
Each active Dynamic Rule creates a Global Filter. These are managed automatically by the system, and are not visible to, or editable by, admins.
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.
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.
The discussion below will focus on self-managed Filters. For Reblaze-managed Filters, the parameters that are editable will work the same as discussed below.
Name. A description that will be displayed within the Reblaze 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 data feed. For self-managed Global Filters, this field should be set to self-managed.
This field contains one or more tags (separated by spaces) that will be assigned to all requests that fulfill the Rule list. Example: internal team-devops
In addition to these admin-defined tags, the system will also create and attach Automatic Tags when a Global Filter matches an incoming request. These can be seen in the Events Log. Here's an example:
In this example, two Filters matched the request: the first named API Discovery, the second named Add branch tag. The first Filter matched due to the request's URI, while the second matched due to its IP address. Both Filters had their Action set to monitor (tag only).
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.
The list of Rules can be defined in different ways, depending on the type of Global Filter.
Dynamic Global Filters are created and maintained automatically by Reblaze, based on the Dynamic Rules. They are not visible or editable in the UI.
To create the Rule list, enter the URL of the data feed into the Source field, then select the update now button that appears. Reblaze will then populate the Rule list automatically.
As an example, to create a list based on the Spamhaus ASN DROP list, you would enter https://www.spamhaus.org/drop/asndrop.txt, and then select the "update now" button.
(Note that this example is for illustration only. An out-of-the-box deployment should contain the ASN DROP list already as a Reblaze-provided list.)
These Global Filters are kept up-to-date differently, depending on their source.
Datafeed-based Global Filters managed by Reblaze are maintained automatically. Their underlying data sources are refreshed every 24 hours, and the Global Filters are updated automatically.
Datafeed-based Global Filters created by admins are maintained by admins. They should be refreshed frequently, to re-query the data source. This can be done by opening the Global Filter for editing, then selecting the "update now" button next to the Source field.
Many Global Filters will be based on specific criteria for a use case, i.e. criteria that are not found in an external feed. Admins can create these manually, as described below.
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)).
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.)
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 Reblaze interface). If individual annotations are not provided, then Reblaze 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.
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 |
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).
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.)
A Rule list for Self-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.
ecurs
