Firewall Event Filtering (Event Excluding)

By using event filtering rules, you can stop agents from reporting certain classes of App Firewall events to the tCell service. Essentially, this is a form of allowlisting, where you indicate that certain types of events represent normal acceptable behavior in your web application.

Specifically, the tCell service will not automatically categorize clients as suspicious for the filtered events, and you will not see these events in the tCell console.

Adding filtering rules from the Events viewer

We recommend building exclusion rules starting from interactive workflow looking at the events that have been reported. From the Events -> App Firewall Monitoring page, you can create a rule from the list of events grouped By Route , By Path, or By Parameter. Whenever you are in one of these tabs of the events table, there will be a blue plus icon in the left-hand column, which you can use to create a filtering rule.

By beginning the rule creation process this way, the route, path, or parameter will automatically be populated in the rule creation form.

Adding filtering rules directly in the policy editor

You can also create, edit, review, or delete filtering rules in the Policies editing pages by nagivating on the left-side list to Policies. In this page, select App Firewall and scroll to the bottom of the Monitor tab.

Note: If your tCell app was created before 2018, you may still have an older ui presentation for an older set of features, and may need to approve a policy change before filtering rules are available.

Existing rules will be listed here, and you can create a new rule from scratch by clicking the + Add link.

Filtering rule elements

Description: a description field to record helpful information about the intent of the rule.

Enabled: if off, a rule will have no effect, but is still recorded in the service.

Selecting criteria: Rules can have four optional types of selectors on what types of events to filter.

• The access point identified by path or route.
• The client by IP address.
• The specific sensor or sensor type.
• A fieldname, field type, or both.

All of these act to narrow the scope of a filtering rule. None are required. For example, a rule with none of these selected, would apply to all App Firewall events, effectively disabling all App Firewall events.

For all below items such as routes, ip addresses, fields, multiple entries are combined together with a logical OR. In other words, a rule with multiple routes or multiple ip addresses listed will match events that match any of those routes, or any of those IP addresses.

Path or Route

Paths selectors can identify a choice of method, path, or both.

A Path selector can match all methods or one specific method (GET, POST, etc). If you need to match two or more specific methods, you can create multiple Path entries for each specific method.

For the path component, an exact full path can be used, or the start of a path, by using a trailing asterisk.

For example /login would only match urls where this was the entire path section such as http://site:port/login?query. It would not match a url such as http://site:port/login/access since the path portion /login/access is not an exact match.
By comparison /static* would match all path urls that begin with /static including /static/images/34234.jpg.

Routes can be selected from a list of identified routes.

IP Address(es)

Any specific IP address can be entered here. For IPv6 addresses, be sure the represent them the same way they appear in the event viewer.

Sensors

Some sensor types are simply added to the list, with no additional choices, like Unusual Response Size. Others permit optional selection of the specific sensor within a category, such as SQL injection.

The App Exceptions category applies to both SQL exceptions and CSRF errors.

Fields

Fields only exist for some sensor types. For example, Unusual Response Size has no associated field.

When using at least one type of sensor that does not relate to fields, no fields can be added to the rule. If you wish to apply your rule to specific fields in one sensor and all cases for another sensor, you will need multiple rules.

A field type can be chosen, in which case only fields of that type will be matched, or no type can be chosen in which case all fields of a particular name will be matched. If, for example, you wish to match AccessToken as either a query parameter or a body/POST parameter, but not as a cookie or header, you will need two entries in the Fields selection, for the two field types.

As a special note, the detection for parameters in form-encoded post parameters as well as json body parameters is expressed the same way.