Content Filter Rules
Signatures of threats and other potential issues
Last updated
Was this helpful?
Signatures of threats and other potential issues
Last updated
Was this helpful?
A traditional WAF evaluates incoming requests according to a list of threat signatures, and flags the request if any matches are found.
Within Reblaze, Content Filter Rules provide the equivalent of these signatures, although they are more powerful and flexible than those within a traditional WAF.
When a request undergoes the content filtering process, its content is compared to the Rules administered here. When a request matches a Rule, various tags will be attached to it. Later, those tags can be evaluated, and can cause actions to be taken on the request.
Content Filter Rules are defined globally within the system, and are available to all Content Filter Profiles.
The usage of Content Filter Profiles within applications and APIs is explained here.
The main page lists all current Content Filter Rules.
The administration (addition/deletion/editing/versioning) of Rules follows the conventions described here.
Out of the box, Reblaze includes a wide variety of well-tested Content Filter Rules. Usually, there will be no need to edit their Match criteria (which can be quite complicated). Before deleting or editing a default Rule, admins should consider the implications of doing so.
If edits are made, and later it becomes desirable to restore an edited Rule to its original form, an admin can revert it using the Versioning capabilities at the bottom of the page.
Alternately, the original request can be duplicated to preserve it, and marked with an appropriate tag (e.g., inactive) which could then be added to the appropriate Ignore lists.
For most of the included Rules, their categories and subcategories should make their functions clear. If you have any questions about the purpose of a specific Rule, feel free to contact Support.
A Content Filter Rule consists of the following:
The signature for this Rule. Usually, this represents the characteristics that makes a request hostile. (Match)
Organizational parameters for the Rule (Category, Subcategory, Risk level)
Tags to apply to requests that match this Rule
Log message for requests that match this Rule (this field is not currently used, but will be in a pending release)
General parameters for administration (Name, Description)
A name for this Rule, to be used within the Reblaze interface. A system tag (shown below the Tags field) will include it as well.
For the default Rules included with Reblaze, the Names are numeric identifiers. (A production deployment will include a large number of Rules; therefore, they are usually organized/administered by their categories and subcategories.)
Information about this Rule, for use within the interface.
A general category for this Rule. It will be the basis for a system tag.
A subcategory for this Rule, within the general Category. It will be the basis for a system tag.
A number ranging from 1 (lowest threat) to 5 (highest threat). It will be the basis for a system tag.
A list of one or more tags, separated by spaces. Whenever this Content Filter Rule's Match condition matches a request, these tags will be attached.
In addition to these admin-defined tags, the system also shows some system tags that will be attached as well.
The tags are the basis for the decisions made when the applicable Content Filter Profile is evaluated for a request. They will also appear in the traffic logs.
(This field is not currently used, but will be in a pending release.) A message that will appear in the traffic logs when a request matches the Match condition.
The criteria against which incoming requests will be compared. For Content Filter rules only, regexps are of the hyperscan flavor (syntax).
