Content Filter Profiles

The input controls at the top of this page are described here: Policies & Rules Entry Administration. Specific editing of a Content Filter Profile is described below.

Introduction

A Content Filter Profile is a set of security policies that are used by Curiefense. Every deployment includes a default Profile, and additional Profiles can be created.

Every URL that Curiefense protects has a Profile assigned to it in Security Policies. (If none is assigned explicitly, the default is used.)

Each incoming request is evaluated according to the Profile assigned to the target URL. Some of the Profile's settings (e.g., Decoding and Restrict Content Type) are global: they apply to all parameters within the request. Others (the Parameter Content Constraints at the bottom of the page) are applied to individual parameters within the request.

In certain situations, a Content Filter Profile will not be used to evaluate a request:

• When the request was already blocked before content filtering would have occurred. (Before the Content Filter Profile is evaluated, several other stages of filtering occur first.)

• When the applicable ACL Profile resulted in an Action of Bypass, which exempts the request from content filtering.

• When the Security Policy has assigned the Profile to the target URL, but the Profile is not in Active Mode.

The Content Filtering Process

An overview of the process is as follows:

• Incoming requests are compared to injection signatures and Content Filter Rules. Each injection signature and Rule that the request matches will result in Tags being attached to the request.

• After the request has been processed, its collection of Tags is evaluated. The Tags can result in the request being blocked, passed, or passed with log entries.

• During this process, there are several ways to exempt a request, or certain parameters within it, from this filtering. There are also several reasons why a request could be blocked.

The details of this process will now be discussed.

Step 1: Request Whitelisting

Before Content Filtering is performed, the Tags that are already attached to the request are evaluated. (These Tags could be the result of Global Filters, Rate Limits, or Flow Control Policies.)

If any Tag is found in the Ignore column of the Tag Processing settings, the request is not subjected to Content Filtering. This allows certain requests to be whitelisted (for example, if they are from a trusted source), avoiding the overhead of unnecessary processing.

Step 2: Section Processing

Each section (path, headers, cookies, args) of the request is processed as follows:

• The Max Count limit is checked (including decoded content). If the request exceeds the limit, it is blocked.

• Step 2a is performed for each parameter within the current section.

• The next section is then selected for processing, until all have been completed.

Step 2a: Parameter Processing

Each parameter within the current section is processed as follows.

• The Max Length limit is checked (excluding decoded content). If the parameter exceeds the limit, the request is blocked.

• If the global Ignore Alphanumeric input option is enabled, and the parameter's value is alphanumeric, this parameter is exempted from further inspection.

• The Parameter Content Constraints list is then evaluated.

  • If there is an entry with a Parameter value that exactly matches the parameter's name, the following parameter evaluation occurs, in this order:

    • If the entry's Matching Value matches the parameter's value, this parameter is exempted from further inspection.

    • If the Restricted? option is enabled, the request is blocked.

    • If any of the request's current Tags are found in the Ignore Content Filter Tags list, this request is exempted from further inspection. (Note that the field name is confusing; this list can include all types of Tags, not merely those generated by content filtering).

    • The parameter is checked for injection attempts.

      • If the Ignore Content Filter Tags does not contain any of the libinjection sqli Tags, the parameter is checked for sqli injection characteristics. If these are detected, appropriate Tags are added.

      • If the Ignore Content Filter Tags does not contain any of the libinjection xss Tags, the parameter is checked for xss characteristics. If these are detected, appropriate Tags are added.

    • The parameter is evaluated against the Content Filter Rules. Curiefense iterates through the list of Rules, and for each one:

      • If any of the Rule's Tags are listed in the parameter's Ignore Content Filter Tags, this Rule is not evaluated.

      • If none of the Rule's Tags are listed in the Content Filter Profile's Active or Report list, this Rule is not evaluated.

      • Otherwise, the Rule's Match value 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 for processing.

  • If there is not an entry with a Parameter value that exactly matches the parameter's name, then the Parameter Content Constraints list is then checked for entries with Parameter values that match the parameter's name, but not exactly. For each entry that is found, the same parameter evaluation is performed as described above for "exact" matches.

Step 3: Tag Processing

The list of Tags accumulated by the request during Step 2a are now compared to the Active and Report tag lists for this Content Filter Profile.

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 (all 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. If any of the specific Tags are found in the Active list, the request is blocked.

2. If any of the specific Tags are found in the Report list, the request is passed. However, the Log Message(s) associated with the Tag(s) will be added to the traffic log.

3. If any of the general Tags are found in the Active list, the request is blocked.

4. If any of the general Tags are found in the Report list, the request is passed. However, the Log Message(s) associated with the Tag(s) will be added to the traffic log.

Resolving Conflicts

When a single Rule matched the request and produced Tags that were configured across more than one column in the Tag Processing section, this is what happens.

In Ignore	In Active	In Report	Result
no match	no match	no match	pass
specific	anything	anything	pass
general	anything	anything	pass
no match	specific	anything	block
no match	general	specific	report
no match	general	no match	block

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

When multiple Rules matched the request, this is what happens:

• If there is a specific entry in Ignore, the request is passed.

• Otherwise, if there is a specific entry in Active, the request is blocked.

• Otherwise, if there is a specific entry in Report , the request is passed with log entries.

• Otherwise, if there is a general entry in Active, the request is blocked.

• Otherwise, if there is a general entry in Report , the request is passed with log entries.

• Otherwise, the request is passed.

Two Security Models

A Content Filtering Profile can be configured in two ways:

• Positive security: reject all requests except for those identified as being legitimate.

• Negative security: allow all requests except for those identified as being hostile.

Configuring a Positive Security model

1. First, define the Global Filtering Settings as narrowly as possible.

2. Then, for each parameter (header, argument, or cookie) that could appear within a request:

• Add the parameter to the list of Parameter Content Constraints

• Enter its Matching Value (an expression that defines the characteristics of a valid parameter)

• Ensure the Restrict? checkbox is checked.

As described above, during processing, each parameter in the incoming request will be evaluated according to the applicable Matching Value.

• If it matches, then this parameter passes the test, and the next parameter will be evaluated.

• If it does not match, the Restrict? setting will cause the request will be blocked.

If a positive security model is correctly implemented, with all possible parameters appropriately defined in the list of Parameter Content Constraints, then Tag Processing will never occur. In theory, the Tag Processing section of the interface could be left empty. However, to compensate for potential errors or omissions, it can still be wise to include general high-risk Tags (such as the cf-rule-risk:5) anyway.

Configuring a Negative Security model

1. First, define the Global Filtering Settings as narrowly as possible.

2. Select the request parameters (headers, arguments, and cookies), if any, that you wish to exempt from content filtering. For each one:

• Add the parameter to the list of Parameter Content Constraints

• Define its Matching Value. A parameter that matches this value will be exempted from further evaluation.

• Leave the Restrict? checkbox unchecked

• In Ignore Content Filter Tags, enter the Tags for each type of content filtering from which you wish to exempt this parameter.

3. Complete the Tag Processing section.

Global Filtering Settings

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

Parameter	Description
Name	A name for this Profile, for use within the Curiefense interface.
Masking Seed	A user-defined string for salting the hash when masking private data. See the Mask? setting, discussed below.
Ignore Alphanumeric input	When this is selected, this Content Filter will not inspect requests that only contain alphanumeric characters. This reduces computational overhead by not evaluating benign requests. (Hostile requests such as SQLi, XSS, etc., will contain some non-alphanumeric characters.)
Decoding	Which decoding standard(s) should be used.
Restrict Content Type	If one or more Content Types are checked, Curiefense will expect the request to conform to one of them. If the request cannot be parsed according to one of the specified types, it will be rejected. If no Types are checked, no restrictions are enforced.
Max Length	The maximum allowable length of any header/cookie/argument within the request.
Max Count	The maximum allowable number of headers/ cookies/arguments within the request.

Tag Processing Settings

This section defines what happens to a request, depending on the Tags attached to it during the Content Filtering process. See Step 3: Tag Processing, above.

If a potential Tag is not configured in any of the three modes, it is effectively in Ignore mode. That Tag cannot result in the request being blocked, regardless of the severity of the injection signature or 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 page of the interface has two separate places where a Tag can be configured to be ignored: here in this section, and also in the Parameter Content Constraints (discussed below). The setting here is global, and will apply to all Tags attached to the request. The setting in the Parameter Content Constraints applies only to the Tags produced by the evaluation of a specific parameter.

Parameter Content Constraints

The bottom part of the interface defines how Curiefense processes individual parameters within a request.

Field	Value
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 a capital "A", while a Regex will be marked with "</>".
Matching Value	A regex pattern. If a parameter's value matches it, the parameter will be exempted from evaluation against the Content Filter Rules (and thus, no Content Tags could be assigned). 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 request is blocked. If Restrict? is not selected, then the Ignore Content Filter Tags field becomes relevant.
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 which fails its Matching Value comparison, and for which Restrict? is not selected, 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.

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