Content Filter Profiles
Filtering requests based on their content
Last updated
Was this helpful?
Filtering requests based on their content
Last updated
Was this helpful?
Content Filtering is the final stage of traffic processing. This fulfills the role of a traditional WAF, which is to examine the content of a request for specific signatures and take specific actions when matches are found.
When a request is received, the system checks its destination URL, and uses the Profile that best matches it.
Out of the box, the system includes a default Content Filter Profile. It can be edited, but it cannot be deleted. It is used for all URLs where no other Profile has been assigned.
The main page lists all current Content Filter Profiles.
Content filtering is a multi-step process:
Data Masking: sensitive data in the request is masked, so that it does not appear in traffic logs.
Content Type Checking: if one or more Restrict content type settings are enabled, they are enforced.
Allowlisting: if the request has one or more specified tags in the Ignore list, it is exempted from further processing.
Tag Evaluation: the request's tags are evaluated for reporting and/or action purposes.
Each step is described in more detail below. For context, here is a graphic showing the controls/sections within the UI that are used in each step:
And here is a flowchart of the process described below, with captions along the top representing the relevant steps:
If the Ignore Body setting is not enabled, and one or more Restrict content type settings are enabled, the request is evaluated against them. If the request cannot be parsed according to one of the specified types, the Action will be executed.
The Parameter Properties list allows the following to be defined:
The parameters, if any, whose values should be masked.
The parameters, if any, whose values should be restricted to regex definitions.
The parameters, if any, which should be exempted from evaluation against specific Content Filter Rules.
For each parameter, the processing occurs in the order described below, until one of the following happens:
the parameter is exempted from further inspection
the Action is triggered (which also terminates the processing of the request)
the parameter completes its processing
At that point, the next parameter is processed, until none remain.
Parameter processing in detail
The relevant Max Count limit is checked (excluding decoded content). If it is active and the parameter exceeds the limit, the Action is triggered.
The relevant Max Length limit is checked (excluding decoded content). If it is active and the parameter exceeds the limit, the Action is triggered.
If the Ignore Alphanumeric input option is enabled, and all the parameter's content is alphanumeric, this parameter is exempted from further inspection.
If one or more entries have a definition for Parameter that matches the parameter's name, the entry that most closely matches it is selected. If an entry was selected, and the parameter's value does not match the entry's Matching Value, and the entry's Restrict? option is enabled, the Action is triggered.
If the parameter matched an entry (in both Parameter and Matching Value), and any of the Rule's tags are listed in the entry's Ignore Content Filter Tags, this Rule is skipped and its tag(s) are not attached.
Otherwise, the Rule's Match string is compared to the parameter's value. If a match is found, the Rule's tags are attached to the request.
This parameter has now completed its processing, and the next parameter in the request is selected.
All the request's tags, including the list of new tags accumulated in the previous step from Content Filter Rule evaluation, are now compared to the Report and Active tag lists.
During this process, a request's tags are divided into two categories:
Specific tags produced by individual rules (and designated with the Rule name: cf-rule-id-XXX)
General tags (cf-all and all other tags that are not specific)
Specific tags are processed first. This allows admins to set up general configurations for threat categories, while still being able to make exceptions for how specific Content Filter Rules are handled.
The request's list of tags are processed as follows:
All specific tags are compared to the Report list. For each tag that is found there, the relevant Content Filter Rule name will be added to the Events Log's Monitor reason field for the request.
All general tags are compared to the Report list. For each tag that is found there, the relevant Content Filter Rule name will be added to the Events Log's Monitor reason field for the request.
If any of the specific tags are found in the Active list, the Action is executed, and processing ceases.
If any of the general tags are found in the Active list, the Action is executed, and processing ceases.
An entry in Ignore always "wins". It is dangerous to put anything other than specific tags into it.
Content Filter Profiles can be used as part of a positive security model (where by default, all requests are rejected, except for those identified as being legitimate).
This can be done by ensuring that each parameter (header, argument, or cookie) that could appear within a request is listed in the Parameter Properties list, with an appropriate Matching Value, and with the Restrict? option enabled.
As described above, during processing, each parameter in the incoming request will be evaluated according to the applicable Matching Value.
If it matches, this parameter will pass the test.
If it does not match, the Restrict? setting will cause the Action to be executed.
A Content Filter Profile consists of the following:
Settings for parsing the request (Restrict content type, Decoding, Ignore Alphanumeric Input, Ignore Body)
Settings for processing the request (Action, Tags)
Content filtering parameters (the bottom section of the UI, referred to below as the Parameter Properties section)
Masking parameters for concealing sensitive information in logs and analytics (Masking seed, and Mask? setting for individual parameters)
General administration parameters (Name, Description)
In this context, "global" means "applying to the entire request."
Information about this Profile, for use within the interface.
An admin-defined string for salting the hash when masking private data. See discussion of the Mask? field, below.
A list of one or more tags, separated by spaces. Whenever this Content Filter Profile is applied to a request, these tags will appear in the traffic logs.
When this is selected, this Content Filter Profile will not inspect requests that only contain alphanumeric characters. This reduces computational overhead by not evaluating alphanumeric requests. (Hostile requests such as SQLi, XSS, etc., will contain some non-alphanumeric characters.)
When this is selected, this Content Filter Profile will not inspect the body of the request.
If Ignore Body is not selected, and one or more Content Types are checked, L11WAAP will expect the request to conform to one of them. If the body cannot be parsed according to one of the specified types, the Action will be executed. If no Types are checked, no restrictions are enforced.
Which decoding standard(s) should be used.
This section defines what happens to a request, depending on its tags.
If a potential tag is not included in the Active or Report lists, it is effectively in Ignore mode. That tag cannot result in the request being blocked, regardless of the severity of the threat signature (i.e., the Content Filter Rule) that produced the tag.
Along with ensuring that all potential tags are properly configured, it is also recommended that each Content Filter Rule has an appropriate Risk Level defined, and that each Content Filter Profile has the highest risk-level tags (e.g., cf-rule-risk:5, cf-rule-id:libinjection-sqli, andcf-rule-id:libinjection-xss) included in the Active mode. This ensures that the highest-risk requests will still be blocked.
This is the bottom section of the interface. It defines how L11WAAP processes individual parameters within a request.
The maximum allowable length of the value for this parameter type (header, cookie, or arg).
When enabled, Max length is enforced.
The maximum allowable number of this parameter type (headers, cookies, or args).
When enabled, Max count is enforced.
The parameter whose value will be compared to the Matching Value. This can be provided as a specific Name (e.g., sessionid), or as a Regex to match multiple parameters (e.g., user_.+). Note that a Name will be marked with ABC, while a Regex will be marked with <>.
A regex pattern. If a parameter's value matches it, the Ignore Content Filter Tags become relevant. If it does not match, the Restrict? option becomes relevant.
If a parameter does not match the Matching Value, and Restrict? is selected, then the Action is executed.
Some requests might contain private data which should not be saved to a traffic log. Parameters which match the Matching Value and for which Mask? is set will be masked / hashed when they are written to the logs, salted with the Matching Seed from the global settings.
A parameter whose value matches its Matching Value, or which does not match but Restrict? is not enabled, will be evaluated against the Content Filter Rules. For each Rule that it matches, that Rule's tags will be attached. Sometimes it is desirable to exempt a parameter from the effects of certain Rules. For example, some Rules filter out special characters; if a parameter can legitimately contain these characters, it would make sense to exempt that parameter from those specific filters. To do this, add the tags from those Rules to this list. These tags will then be ignored for this parameter.
A Content Filter Profile associates signatures () with specific actions, and includes some other parameters as well.
It triggered a Skip action in a , or Bypass in the
Its destination URL matches a which does not have an active Content Filter Profile assigned to it.
A Content Filter Profile is assigned to paths/URLs within applications and APIs via .
The administration (addition/deletion/editing/versioning) of Profiles follows the conventions described .
Content Filtering: several forms of content limits are checked. The request's parameters (headers, cookies, and arguments) are then examined. Tags are added to the request based on .
For parameters listed in the list with the Mask? option enabled, their values are replaced by hashes of these values with the Masking seed.
Before content filtering is performed, the tags that are already attached to the request are evaluated. (These tags could be the result of , , or .)
If any tag is found in the Ignore list, the request is not subjected to content filtering (i.e., and below do not occur). This allows certain requests to be allowlisted (for example, if they are from a trusted source), avoiding the overhead of unnecessary processing.
Starting with the headers, each parameter (each header, cookie, and arg) of the request is processed. Each parameter and its value are compared to the entries in the list: the entries in its All section and also the relevant parameter-type section (either Headers, Cookies, or Arguments).
The parameter is evaluated against the . Link11 WAAP iterates through the Rules, and for each one:
Parameters for (the Ignore list) and (Active and Report lists)
A name for this Profile, to be used within the interface. A (shown below the Tags field) will include it as well.
The action that can be executed under the various circumstances described above in .
In addition to these admin-defined tags, the system also shows some that will be attached as well.
This list is evaluated before content filtering occurs, as described above in .
These lists are evaluated after content filtering rules have been evaluated. See the description above of .
