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
  • Administration
  • Components
  • Individual parameters
  • Name
  • Description
  • Tags
  • Main Session ID & Other Session IDs
  • Path Mapping

Was this helpful?

Export as PDF
  1. Console UI Walkthrough
  2. Security

Security Policies

Applying security rules to paths and resources

PreviousFlow Control PoliciesNextRate Limit Rules

Last updated 1 month ago

Was this helpful?

Overview

Security Policies assign security rulesets to specific paths within applications and APIs. When a request is received, Link11 WAAP finds the Security Policy assigned to its destination Server Group (i.e., the destination site). That Policy then specifies the security rules to enforce upon the request, according to its destination URL.

Each Security Policy also includes a definition of the Session ID to use within its scope. This is an important setting, as discussed below.

Usage within applications and APIs

Every L11WAAP deployment contains a default Security Policy. This default Policy cannot be deleted. Admins can define additional Policies as well.

Administration

The main page (shown at the top of the page) lists all current Security Policies.

Components

Each Security Policy contains the following:

  • A list of paths or scopes within which this Policy will be applied.

  • Optional Edge Functions(s) to run when requests are sent to the specified paths.

  • One or more Tags that will be attached to requests sent to the specified paths.

  • General parameters for administration.

Individual parameters

Name

Description

Information about this Policy, for use within the interface.

Tags

A list of one or more tags, separated by spaces. Whenever this Security Policy is applied to a request, these tags will appear in the Events Log.

Main Session ID & Other Session IDs

However, the definition of a Session ID can vary. The optimal combination of request parameters can differ, depending on the circumstances.

The Main Session ID and Other Session IDs define the request parameters that should be combined and used as the Session ID within the scope of this Security Policy.

Main Session ID: This is the header, cookie, argument, or attribute that will be the Session ID by default.

Other Session IDs: This is a list of additional headers, cookies, arguments, and/or attributes that might, or might not, be available, depending on the situation. When they are available, they are combined with the Main Session ID to form the Session ID used by L11WAAP.

Example: the Main Session ID is set to Header / user_id, and Other Session IDs contains one entry for an authentication token (Header / auth_token). Initially, the Session ID will consist of the user_id alone. Once the user is authenticated and the requests begin to include auth_token too, the Session ID will then be a combination of those two values.

Another example: the Main Session ID is set to Header / user_id. In Other Session IDs, there is one definition (Header / device_id) for a field that is sent by a mobile application.

  • If the user is using the mobile application, then device_id will be included in the incoming requests, and the Session ID will be a combination of user_id and device_id.

  • If the user is using a browser instead, then device_id will not be defined, and the Session ID will consist solely of user_id.

The choice of parameters for the Session ID should be carefully considered, because it can affect the performance of various security settings and rules. Sometimes, a narrowly-defined Session ID is better, while in other situations, a broader definition should be used.

  • If the applicable Security Policy has a Session ID based on the session tokens, then the Rate Limit Rule will detect and block the attack.

  • If however the Session ID also includes the IP address, then a Rate Limiting Rule would maintain separate counts for each of the various IPs that are used, and the Rule would not perform as the admin had intended.

Path Mapping

This is a list of paths, and the security settings (Content Filter Profiles, ACL Profiles, Backend Service, Rate Limit Rules, and Edge Functions) assigned to each one.

Every incoming request targets a specific URL. L11WAAP finds the best match for that URL in the Path Mapping list, and applies the security settings defined for it, along with whatever settings are contained in the special Site Level path definition (see below).

The "best match" is determined by regex evaluation. The order in which the paths are listed in the interface does not matter. If multiple admin-defined Path Maps could match a request's destination, the longest matching regex will determine which Path Map gets selected. If no regex matches, then the Default Path Map will be selected.

Out of the box, Security Policies can contain three special path definitions:

  • Root: Will be selected for requests sent to the root level of the site.

  • Site Level: Will be selected for all requests sent to the site (see note below).

  • Default: Will be selected for requests that do not match any other specific path definitions.

The Site Level definition behaves differently than other path definitions; it is always selected and added to the best-matching path definition for the request (including the Default definition). Thus, if Site Level contains any settings, they are used in addition to the settings contained in the best-matching definition.

Managing the Path Maps

A new Security Policy will include several Path Maps. Clicking on a listing will expand it for editing.

Creating Path Maps

To add a new Path Map, select an existing one, expand it, and select "Fork Path Mapping" at the bottom. The existing one will be cloned, and the new one will be displayed for editing.

Note that the controls at the top of the window are for administering Security Policies, which generally correspond to domains. Administering Path Maps (for paths and URLs within the specified domain) is done in the Path Mapping list.

Path Map Fields

Field

Value

Name

A descriptive label for use within the interface.

Path or Expression

An expression for the path, expressed as PCRE (Perl Compatible Regular Expressions).

Content Filter Profile

ACL Profile

Backend service

Rate Limit Rules

Edge functions

In addition to editing the fields discussed above, the expanded Path Mapping dialog also provides the ability to:

  • Activate or deactivate the Content Filter Profile (by changing its active mode toggle).

  • Activate or deactivate the ACL Profile (by changing its active mode toggle).

  • Add an existing Rate Limit Rule to this Path Map, via the + New button. (The + New button will only be shown if there are Rate Limit Rules available.) An existing Rate Limit Rule can be removed by selecting the trash icon at the end of its entry.

  • Add an existing Edge Function to this Path Map, via the + New button. (The + New button will only be shown if there are Edge Functions available.) An existing Edge Function can be removed by selecting the trash icon at the end of its entry.

  • Create a copy of this Path Map, and open it for editing, via the "Fork Path Mapping" button.

Security Policies are used within . Every Server Group includes a Security Policy.

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

The , , and (optional) that will be enforced on requests sent to the specified paths.

What to use as a Session ID for requests sent to the specified paths. This is used elsewhere by the system; for example, .

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

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

Some types of settings within L11WAAP allow admins to track user activity and enforce security rules based on the user's Session ID. (Examples of this include and .)

For example, an admin has defined a based on Session ID. A threat actor then begins a session in a web browser, copies its session tokens, and tries to use them in a brute force attack across different IPs and distributed networks in the cloud.

The applied to this path. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.

The applied to this path. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.

The associated with this path. Requests that pass through L11WAAP without being blocked will be forwarded here.

The ) assigned to this path.

The assigned to this path.

Server Groups
Content Filter Profile
ACL Profile
Rate Limit Rule(s)
Flow Control Policies
Rate Limit Rules
Rate Limit Rule
Content Filter Profile
ACL Profile
Backend Service
Rate Limit Rule(s
Edge Function(s)
system tag
system tags
here
Rate Limit Rules can be enforced on a per-session basis