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
  • Filter structure
  • Quickly Creating a Filter
  • Example 1: Dashboard
  • Example 2: Events Log
  • Example 3: Manually Editing Filters
  • Query Operators and Examples

Was this helpful?

Export as PDF
  1. Reference Information

Query Filter Syntax and Best Practices

How to construct queries for displaying analytics data

PreviousPattern Matching SyntaxNextSupport

Last updated 1 month ago

Was this helpful?

Overview

The and pages display data based upon user queries. These queries are entered into the text box at the top of each page.

A query is essentially a filter; it instructs Link11 WAAP which data should be displayed, with all other data excluded. Admins should understand the syntax of these filters, and how to create them.

The discussion below explains:

  • How to quickly and efficiently build filters to display the desired data

  • The syntax and operators available for this process

Filter structure

Individual filters include a field name, operator, and value. Example: status=200

Multiple filters can be combined; these are delimited with a comma, and evaluated with a logical AND. Example: status>=200,status<=299

Strings are encapsulated with double quotes. Regex can be used; see the examples in the section below.

Quickly Creating a Filter

Simple filters can be entered directly into the query box. However, admins will frequently need to create complex filters, e.g. when investigating attacks or trends.

For a full discussion and examples of how to use L11WAAP's tools to investigate and explore traffic data (such as discovering anomalies, diagnosing False Positive alarms, and more), see this page: .

L11WAAP provides the ability to build and add filters to the box automatically.

In the Dashboard or Events Log, admins can right-click on analytics data and then select "Show Matching" (to add an inclusionary filter) or "Hide Matching" (to add an exclusionary filter).

Afterwards, the filter string can be manually edited if desired.

Example 1: Dashboard

In this screenshot, the Dashboard is displaying all traffic data from a specific time period. The admin wishes to display only requests that originated from China and were blocked for a specific reason.

Selecting Show Matching adds the appropriate filter to the query box:

Next, the admin goes to the Blocked & Monitored list, finds the blocking reason of interest, and right-clicks on it:

Selecting Show Matching adds another filter to the query box:

... and running the query will then display the desired results.

Example 2: Events Log

The process described above could also be run from the Events Log, with only a few minor differences:

  • Since the Events Log does not contain a Top Metrics section, filters can be added when viewing specific events, and built from the individual event parameters of interest.

  • The Show Matching and Hide Matching filters will be created from the specific parameter that was clicked on. In the example below, selecting Show Matching will create a filter to show all events with the Result of Blocked by origin.

Example 3: Manually Editing Filters

Sometimes it is necessary to manually edit filter strings after they are built.

When viewing the Events Log, sometimes it is difficult to find an event that includes the exact characteristics that are desired for the filter. In this situation, admins can build the filter from an event that is similar (thus allowing the system to construct the correct syntax and format automatically), and then edit it manually.

In other cases, the filter strings are too specific, because the admin wants something broader. This is especially true when building filters from Events Log entries, for example when selecting a Blocking Reason or MonitoringReason. In these situations, the admin can create the filter, then edit it appropriately. For example, a specific instance of XSS will produce a filter that looks like this:

reason="Block - content filter xss[lvl3] - default contentfilter - [URI argument a==<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="https://example.com/";}</script>]

This can be edited to show all requests blocked for XSS:

reason~"xss"

Query Operators and Examples

Symbol
Meaning
Data Types
Examples

=

Equals (exact and full match.)

reason=“ACL” only matches requests when reason exactly equals ACL.

String Number Boolean Date/Time

method=“GET”

reason=“ACL”

country="United States" blocked=true status=300

!=

Does not equal (doesn't match exactly).

reason!=“ACL” only matches requests when reason does not exactly equal ACL.

String Number Boolean Date/Time

status!=200 reason!=“ACL”

~

Contains (i.e., partial match).

reason~“ACL” only matches requests when reason contains ACL.

String

method~“GET” reason~“ACL”

!~

Does not contain (no partial match was found).

reason!~“ACL” only matches requests when reason does not contain ACL.

String

method!~“GET” reason!~“ACL”

~=

Regex match

Regex

method~=“^(GET|POST|METHOD)$”

!~=

No Regex match

Regex

method!~=“^(GET|POST|METHOD)$”

header[key] cookie[key] argument[key]

Header, cookie, or argument has the key with specified value.

header[~“arg1”]=“foo” only matches requests with a header key that contains arg1 and value that exactly equals foo.

String

Exact match in key: header[=“arg1”]=“foo”

Contained in key: header[~“arg1”]=“foo”

Regex in key: header[~=“arg1”]=“foo”

>

Greater than

Number

status>399

<

Less than

Number

status<400

>=

Greater than or equal to

Number

status>=300

<=

Less than or equal to

Number

status<=399

in

In: Request has a field within the specified values

Number String

status in (200,201,203)

between

Between: Request has a field with a value equal to or between the two given values

Number and number, or Date/time and Date/time

status between 200 and 299

Going to the at the bottom of the Dashboard, the admin finds the Countries list and right-clicks on China:

Dashboard
Events Log
Understanding and Diagnosing Traffic Issues
Operators
Top Metrics section