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
  • Circumstances where content filtering will not occur
  • Usage within applications and APIs
  • Administration
  • The Content Filtering process
  • Step 1: Data Masking
  • Step 2: Content Type Checking
  • Step 3: Allowlisting
  • Step 4: Content Filtering
  • Step 5: Tag Evaluation
  • Configuring a Positive Security model
  • Components
  • Parameters
  • Global Parameters
  • Tag Processing Settings
  • Parameter Properties

Was this helpful?

Export as PDF
  1. Console UI Walkthrough
  2. Security
  3. Content Filter

Content Filter Profiles

Filtering requests based on their content

PreviousContent FilterNextContent Filter Rules

Last updated 1 month ago

Was this helpful?

Overview

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.

Circumstances where content filtering will not occur

A request will not be subjected to content filtering if any of these are true:

  • It was blocked during a previous stage of processing.

As discussed below, there are also several stages within the content filtering process where some or all of a request might be exempted from completing the process.

Usage within applications and APIs

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.

Administration

The main page lists all current Content Filter Profiles.

The Content Filtering process

Content filtering is a multi-step process:

  1. Data Masking: sensitive data in the request is masked, so that it does not appear in traffic logs.

  2. Content Type Checking: if one or more Restrict content type settings are enabled, they are enforced.

  3. Allowlisting: if the request has one or more specified tags in the Ignore list, it is exempted from further processing.

  4. 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:

Step 1: Data Masking

Step 2: Content Type Checking

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.

Step 3: Allowlisting

Step 4: Content Filtering

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.

A parameter can be exempted from all Content Filtering Rules by including cf-all in its Ignore Content Filter Tags.

When the Action is triggered, it is executed immediately, and no further content filtering occurs for that request. Therefore, if a request contains more than one type of attack, one will appear in the logs while the remainder will not.

Step 5: Tag Evaluation

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:

  1. 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.

  2. 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.

  3. If any of the specific tags are found in the Active list, the Action is executed, and processing ceases.

  4. If any of the general tags are found in the Active list, the Action is executed, and processing ceases.

Note that in the UI, the Ignore list appears next to the Active and Report lists. However, the Ignore list is processed earlier in the content filtering process (see Step 3: Allowlisting, above). If any of a request's tags match one in the Ignore list, that request is exempted from content filtering.

An entry in Ignore always "wins". It is dangerous to put anything other than specific tags into it.

Configuring a Positive Security model

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.

If a positive security model is correctly implemented, with all possible parameters appropriately defined in the list of Parameter Properties, then Step 5: Tag Evaluation would seem to be irrelevant. Invalid requests will trigger the Action before the Active and Report lists are evaluated, and only valid ones would remain when these lists are evaluated; thus, in theory, these lists could be left empty. However, to compensate for potential errors or omissions, it is still wise to include general high-risk tags (such as the cf-rule-risk:5) anyway.

Components

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)

Parameters

Global Parameters

In this context, "global" means "applying to the entire request."

Name

Description

Information about this Profile, for use within the interface.

Masking seed

An admin-defined string for salting the hash when masking private data. See discussion of the Mask? field, below.

Action

Tags

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.

Ignore Alphanumeric Input

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.)

Ignore Body

When this is selected, this Content Filter Profile will not inspect the body of the request.

Restrict content type

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.

This setting can be a useful way to easily block a variety of attacks. For example, when "Multipart Form" is not selected, a user cannot upload any files, thus preventing malware uploads.

Decoding

Which decoding standard(s) should be used.

When one or more decoding standards are not applicable, they should be unselected here. This will reduce processing time and overhead.

Tag Processing Settings

This section defines what happens to a request, depending on its tags.

The Ignore list

The interface has two separate places where a tag can be configured to be ignored: here in this section's Ignore column, and also in the Parameter Properties (discussed below). The setting here is global, and will apply to all tags attached to the request. The settings in the Parameter Properties list apply only to the evaluation of specific parameters.

The Active and Report lists

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.

Parameter Properties

This is the bottom section of the interface. It defines how L11WAAP processes individual parameters within a request.

Max length

The maximum allowable length of the value for this parameter type (header, cookie, or arg).

Max length limit active mode

When enabled, Max length is enforced.

Max count

The maximum allowable number of this parameter type (headers, cookies, or args).

Max count limit active mode

When enabled, Max count is enforced.

Parameter

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

Matching Value

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.

Restrict?

If a parameter does not match the Matching Value, and Restrict? is selected, then the Action is executed.

Mask?

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.

Ignore Content Filter Tags

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.

Properties are defined in the same way for Headers, Cookies, and Arguments within their respective tabs.

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 .

Content Filter Rules
Global Filter
ACL Profile.
Security Policy
Security Policies
Content Filter Rules
Global Filters
Rate Limit Rules
Flow Control Policies
Content Filter Rules
Parameter Properties
Step 4
Step 5
Parameter Properties
Step 3: Allowlisting
Step 5: Tag Evaluation
The Content Filtering Process
Step 3
Step 5
here
system tag
system tags
Click to expand this image.