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
  • Introduction
  • Overview
  • Stages/components of traffic filtering
  • "Request" Edge Functions
  • Initialization
  • Global Filters
  • Flow Control
  • Global Rate Limits
  • Rate Limits
  • ACL Profiles
  • Content Filtering
  • "Response" Edge Functions
  • Customer Backend
  • Actions
  • Logging
  • Analytics and Dashboards
  • Dynamic Rules and Quarantines

Was this helpful?

Export as PDF
  1. How Link11 WAAP Works

Traffic Filtering Process

PreviousIntroduction to Link11 WAAPNextTraffic Reporting and Analytics

Last updated 1 month ago

Was this helpful?

Introduction

Link11 WAAP subjects incoming requests to a multi-stage filtering process.

Below is a high-level description of the overall process. For a more in-depth review of the various stages and how to configure them, see their detailed discussion in the Console UI Walkthrough section of this manual, as linked to below in each description.

Overview

The diagram above shows the progression of incoming requests through this process, shown from left to right. When a request successfully passes a stage, it proceeds to the next stage, as designated by a green arrow. When it does not, it follows the red arrow instead. Black arrows show activities that occur independent of a request's evaluation.

Stages/components of traffic filtering

"Request" Edge Functions

Initialization

Subsequently, the attached tags can be the basis for decisions about the disposition of the request.

Global Filters

  • Attaching tags when the request matches specified criteria.

Flow Control

Example: a web application has a login page. A legitimate user will submit a GET request to access the page, followed by a POST request with login credentials. Conversely, a threat actor waging a brute-force attack might conserve resources by submitting a series of POSTS, without any GETs. A Flow Control Policy can allow the legitimate user to access the page, while excluding the threat actor.

Global Rate Limits

Rate limiting restricts the rate at which the system will accept requests from traffic sources. When a limit is exceeded, an action can be taken.

Rate Limits

In this stage, path-specific rate limiting is enforced. Admins can define different parameters for the limits, depending on the request's destination URL.

Path-specific rate limiting can be configured in two places within the system:

ACL Profiles

As shown in the diagram above, three outcomes are possible:

  • The request is passed, and then subjected to content filtering.

  • The request is passed, but is exempted from content filtering.

Content Filtering

This stage fulfills the traditional role of a WAF, which is to examine the content of a request for threat signatures and take action when a match is found.

However, Content Filtering within L11WAAP is much more powerful than this. Admins can configure Content Filter Profiles to allow or block requests if they do have specific characteristics, or if they don't.

"Response" Edge Functions

Customer Backend

Actions

Logging

Analytics and Dashboards

Dynamic Rules and Quarantines

Dynamic Rules are not meant to pass or block specific requests. Instead, they are used to analyze the overall behavior of traffic sources, as shown in the requests they have recently submitted.

When a traffic source violates a Dynamic Rule, the traffic source is quarantined. Until the quarantine expires, two things occur:

  • The traffic source can also be banned, which means that future requests will be blocked. (As shown in the diagram above, this is done by adding the traffic source to an internal system-maintained Global Filter, automatically.)

When processing an incoming request, L11WAAP enforces the applicable security rulesets. As shown above, some types of rulesets are applicable to all requests, while others will vary depending on each request's destination URL and/or the tags attached to the request. To see how L11WAAP decides which rulesets are applicable to a request, see the page.

Link11 WAAP acts as a proxy for the backend that it protects. It receives incoming requests, and examines them for potential threats. Requests that pass inspection are passed through to the backend. Those that do not pass inspection trigger an , which often is either a blocking action or a . Along the way, L11WAAP logs the request and the actions that occur, which are available to admins via analytics and dashboards.

Before any other processing occurs, L11WAAP can execute one or more . An Edge Function consists of custom Lua code; it allows admins to extend the system's capabilities as desired.

Each Edge Function contains a parameter. When this is set to Request, the Function is executed immediately when processing of the request begins.

L11WAAP uses a when processing and evaluating requests. At various points during processing, tags are attached to a request based on its source, content, and other characteristics.

In this stage of processing, each request receives a . For example, every request will be tagged with all, along with tags for the geolocation of the traffic source.

This stage is also when L11WAAP performs : determining which security rulesets should be enforced upon the request.

The stage has two primary purposes:

Executing an depending on the tags that were attached. In some situations, admins will decide to stop ths system's processing at the Global Filter stage. For example, an admin can decide that if the traffic source is found on a hostile IP list, there is no point in analyzing it further; it should just be blocked.

In this stage, are evaluated. Flow Control allows admins to define and enforce sequences (flows) of requests submitted by traffic sources.

In this stage, rate limiting is enforced upon incoming requests, regardless of their destination URLs. The limits are defined in with enabled.

that do not have enabled.

, which allow for IP-based rate limiting to be defined for all applications based upon them.

An defines what will happen to a request, based on the tags that it contains. Admins can assign a variety of available actions that will be performed.

The request triggers an .

In this stage, the applicable is used to evaluate the request. Each Profile defines the applicability of various .

When have a setting of Response, L11WAAP will execute them as the final step in its filtering.

When a request has passed all of the system's traffic filtering, it is forwarded to the backend. The backend's response is then obtained, and returned to the client. L11WAAP's interaction with the backend is configured in and .

Various stages of processing can result in an being executed. Often, this is a blocking action, but as well, including the acceptance of the request and bypassing the remainder of the filtering process.

L11WAAP stores all requests and their details, and makes them accessible in the .

The and provide customizable displays of traffic and events.

L11WAAP periodically reviews the most recent tranche of incoming requests and evaluates them using . Unlike the other stages of analysis described above, this is done after the requests have been processed, and the resulting responses have been returned to the user.

The traffic source is added to the list, where admins can monitor it.

Policy Mapping
Action
bot challenge
Edge Functions
tag-based system
policy mapping
Global Filters
Action
Flow Control Policies
Proxy Templates
ACL Profile
Action
Content Filter Profile
Content Filter Rules
Proxy Templates
Backend Services
Events Log
Dashboard
Events Log
Dynamic Rules
Quarantine
Rate Limit Rules
Rate Limit Rules
Edge Functions
Action
specific set of system tags
other actions are possible
Phase
Phase
Global mode
Global mode