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
  • Usage within applications and APIs
  • Implementation example
  • Administration
  • Components
  • Individual parameters
  • Name
  • Active
  • Time Frame
  • Count by
  • Tags
  • Description
  • Include and Exclude
  • Flow Control Sequence

Was this helpful?

Export as PDF
  1. Console UI Walkthrough
  2. Security

Flow Control Policies

Tagging valid or invalid session flow patterns

PreviousGlobal FiltersNextSecurity Policies

Last updated 1 month ago

Was this helpful?

Overview

Flow Control Policies allow admins to define "flow" sequences of submitted requests. As incoming traffic is received, the requests are evaluated against the active Policies. If a defined sequence is completed--in other words, if the listed requests are received in the specified order--the Policy will attach one or more tags to the final request in the sequence. The tags can subsequently trigger an action (allow, block, challenge, etc.)

Link11 WAAP includes several types of behavioral profiling and control. Flow Control Policies are one type of behavioral control that are defined by admins. They can allow, or disallow, traffic sources that display specific patterns of behavior.

Use case example: A web application has a login page. A legitimate user session will begin with a GET request, followed by a POST. However, threat actors who are waging brute-force login attacks will typically just send a series of POSTs. A Flow Control Policy can be the basis for blocking every POST request that was not preceded by a GET.

Usage within applications and APIs

Instead, each Policy has its applicable scope defined by the Active, Include, and Exclude parameters, as described below.

Implementation example

To implement the GET/POST example mentioned above, an admin would create the following configuration:

  • A Global Filter would assign a tag (e.g., method-post) to all POST requests sent to /login.

  • A Flow Control Policy would assign a tag (e.g., login-flow) to each POST that was preceded by a GET.

  • An ACL Profile would Block/Skip all requests tagged with login-flow, and Block/Apply all requests tagged with method-post.

Administration

The main page (shown above) lists all current Flow Control Policies.

Components

Each Flow Control Policy consists of:

  • A flow sequence: A list of two or requests that are expected to be received in the sequence shown, within the specified Time frame.

  • Tag(s) to assign to the final request in the defined flow sequence.

  • Include/Exclude: Tags to define the scope within which this Policy is enforced.

  • Count by parameters for identifying distinct flow sequences within incoming traffic. In other words, these settings tell the system how to separate incoming requests into distinct groups, each of which will be evaluated separately for flow sequence analysis. Usually, admins will want to enforce flow sequences on individual users (for example, according to IP address).

  • General parameters for administrative purposes.

Each of these is described in depth below.

Individual parameters

Name

Active

When this toggle is selected, the Policy will be enforced within its defined scope.

Time Frame

This defines the time available for the flow sequence to be completed. When the first request in the sequence is received, an internal timer begins. The final request must be received within the Time Frame in order for the Tags to be assigned.

Count by

At any given time, an application might receive a variety of incoming requests from different users simultaneously, each of which might be at a different stage of a flow sequence. For Flow Control Policies to work successfully, the system must be able to differentiate among all the various streams of incoming traffic, and perform stateful evaluations of each one separately.

The Count by parameter allows admins to define how this differentiation is done. For example, a common configuration is Attribute / IP Address. When the application is receiving requests from multiple IP addresses simultaneously, the requests from each IP will be considered as a separate and distinct set for Flow Control purposes. On the other hand, if it is possible that users will sometimes share IP addresses, then a better choice might be Attribute / Session ID.

Admins have a variety of configuration options for this parameter. Incoming requests can be processed according to specific headers, cookies, arguments, or attributes.

Multifactorial Count by definitions can be set up by selecting "New entry" and editing the controls that appear. When incoming requests are evaluated, the Count by definitions are combined with a logical AND.

Tags

Enter one or more unique tags, separated by spaces. When a series of incoming requests matches the flow control sequence, the tags listed here will be attached to the final request.

In addition to these admin-defined tags, the system also shows some system tags that will be attached as well.

Description

Information about this Policy, for use within the interface.

Include and Exclude

Flow Control Sequence

This is an admin-defined sequence of at least two steps.

The system maintains stateful histories of each traffic stream defined by the Count by parameter. When a series of incoming requests matches the Flow Control Sequence exactly, the final request has the defined Tags attached.

Each step in the sequence is defined by a Method, Host, and Path, along with any optional parameters added by an admin.

A new Flow Control Policy includes a two-step sequence by default. To add additional steps, select the "Add Step" button.

A Flow Control Policy's purpose is to assign its defined Tags to the last request in defined flow sequences. The Tags can then be used in or to trigger specific actions. Usually, a is involved in the process as well (see the implementation example below).

Unlike some other types of security settings, Flow Control Policies are not assigned to paths in , because a Flow Control Policy can incorporate multiple paths within an application or API.

The administration (addition/deletion/editing/versioning) of Policies follows the conventions described .

A name for this Policy, to be used within the interface. A (shown below the Tags field) will include it as well.

These are lists of tags that can limit the applicable scope for this Policy. Their use is described on the page.

Rate Limit Rules
ACL Profiles
Global Filter
Security Policies
here
UI Overview
system tag
A Flow Control Policy, opened within its Editor page