Log Exporters

Link11 offers a network security software suite, including robust WAAP (Web Application and API Protection). This is the documentation for the Link11 WAAP ("L11WAAP") SaaS system.

Release Notes

• November 24, 2025

Known Issues

• Available .

User Guide

The manual is organized into the following sections, accessible through the sidebar table of contents:

• Introduction to Link11 WAAP: general information about the system and its capabilities

• How It Works: an overview of how L11WAAP filters traffic

• Console UI Walkthrough: a detailed explanation of the user interface

• Using the Product: some tips and best practices

Welcome!

Link11 offers an all-in-one WAAP platform. It includes a next-gen Web Application Firewall (WAF), autoscaling Denial of Service (DoS)/Distributed Denial of Service (DDoS) protection, advanced bot management, real-time traffic monitoring & control, full historical logs & analytics, and more.

Link11 WAAP runs on the customer’s clouds of choice, whether the Link11 Network and Web Security solution, or any of the top-tier public cloud providers (AWS, Azure, and GCP). It protects web applications, services and microservices, and API endpoints.

Platform overview

L11WAAP deploys as a reverse proxy, continually analyzing incoming traffic. Benign traffic is passed through to the customer's origin, while hostile traffic is blocked and denied access.

The platform's overall architecture is as follows:

Cloud-based web security

• L11WAAP deploys and runs in the customer's choice of clouds, whether private (Link11) or public (AWS, GCP, or Azure).

• All incoming traffic is routed through L11WAAP and scrubbed as it passes through. Latency is negligible (generally 1.5 milliseconds or less).

• Hostile traffic is blocked before it reaches the protected network. Legitimate traffic has normal access to the requested resources.

Full integration

L11WAAP is integrated with, and runs natively on, multiple cloud platforms. It leverages the advantages of each. Examples:

• When L11WAAP runs on Link11, customers can use Secure CDN, Link11 load balancing, Infrastructure DDoS for offloading Layer 3 protection, and more.

• On GCP, L11WAAP can act as the 'threat detection engine' for Cloud Armor, automating and extending its capabilities, and blocking attacks at the edges.

• On Azure, L11WAAP integrates with Azure Security Center to fit smoothly into existing customer workflows.

• On AWS, L11WAAP integrates with AWS WAF and Shield, adding granularity, control, and many other additional capabilities to AWS's native security features.

This section provides settings for content filtering:

DNS Management is an optional capability. Your DNS records do not need to be maintained within Link11, but they can be.

The user interface displays the records that are currently defined within Link11 WAAP. These records are not editable within the UI; they are configured outside of the UI, and are displayed here for informational purposes only.

For assistance in changing or configuring DNS records, within L11WAAP, .

This section describes best practices for some common tasks.

This section answers questions that often arise about using Link11 WAAP.

Sometimes it is desirable to add custom annotations to events in the traffic logs: perhaps for monitoring, visibility, or other purposes.

This can be done with .

Link11 WAAP includes a Mobile SDK for authenticating mobile application clients. For more information, see .

Sometimes end-to-end encryption is necessary, and client traffic must be kept encrypted until it reaches the backend server.

For this purpose, Link11 supports TCP passthrough. When this is configured, neither the Link11 load balancer nor L11WAAP will terminate or decrypt the TCP connection. The specified traffic will be passed through to the backend as-is.

Web clients can cache resources from a server. Afterwards, a client can access its local cache, which reduces the number of requests sent to the server.

Servers can instruct clients to implement caching in certain ways. Servers can also set separate caching policies for any intermediary proxies in-between the server and the client.

Link11 WAAP is a proxy between the clients and the backend. When the backend responds to clients, the outgoing responses pass through L11WAAP. You can instruct the system to preserve or alter the caching instructions in those responses.

This can be done through . Out of the box, L11WAAP includes several cache policy Edge Functions for this purpose. If you need additional assistance in customizing L11WAAP's caching behavior, .

When a web application or API frequently receives incoming requests with excessively large arguments, or a large number of arguments, this can adversely impact the performance of the Events Log.

To address this, Link11 WAAP can defer the retrieval of arguments until an admin specifically requests it. More info on this feature is .

Link11 WAAP provides inherent capabilities for load-balancing across origin/backend servers.

This is configured in .

To run custom Lua code before or after Link11 WAAP processes a request, use an .

To define code for customizing nginx's behavior or parameters, use .

Link11 WAAP integrates with a wide range of SIEM [Security Information and Events Management] solutions. Most of our enterprise clients stream L11WAAP events to ArcSight, RSA, IBM, Splunk, and other solutions.

To stream traffic event data to one or more of these destinations, create one or more .

The lengths of Log Exporter data values can be controlled using the .

This section is for SSL settings.

Blocked requests can receive customized response headers, status codes, and content, by configuring the appropriate Actions.

Admins can also run custom Lua code via Edge Functions. Edge Functions with a phase of Response Pre Processing or Response Post Processing will be run after the backend has responded to the request, but before the response is sent to the client.

Sometimes, incoming requests contain sensitive or Personally Identifiable Information that should not be included in logs and other forms of analytics.

Link11 WAAP provides the ability to mask specific types of information. This is configured using the Masking Seed and Mask? fields within Content Filter Profiles.

Note that you should ensure that the relevant requests are always subjected to the Content Filtering process.

The Analytics section contains the UI for viewing traffic.

If you have not used Link11 WAAP before, read this first: Traffic Reporting and Analytics.

Otherwise, the Analytics UI is documented here:

• Dashboard

• Events Log

The Security section of the UI provides configuration options for basic security rulesets and policies. The pages in this section document the configuration for these security settings.

If you are not yet familiar with how Link11 WAAP filters traffic, and how the various settings below fit into this process, it is recommended that you read this overview first: The traffic filtering process.

• Global Filters

• Flow Control Policies

• Content Filter:

Overview

The Quarantined List page shows a list of traffic sources that have triggered one or more Dynamic Rules. While a traffic source is on this list, Link11 WAAP responds to all of its requests automatically with the Dynamic Rule's Action.

This is often used to ban a persistent violator of other security rulesets, but it can also be used merely to monitor a traffic source for a period of time. An explanation of the quarantining process is here.

Administration and Use

Viewing quarantines

Each quarantined traffic source will have an entry in the list. Long lists will be broken up across multiple pages, which can be navigated using the controls at the bottom of the page.

The overall list can be sorted according to the values in each column by using the Filter control at the top.

Cancelling quarantines and preventing False Positives

Traffic sources will be automatically removed from the Quarantine list when their quarantines have expired.

They can also be manually deleted. In the UI, this is done by selecting the trash icon at the end of an entry in the Quarantined List.

When a traffic source is manually deleted from the list, L11WAAP understands this to mean that the quarantine was a False Positive.

Therefore, when the next cycle of Dynamic Rule evaluation occurs, the Rule's corresponding Global Filter will be updated by removing the traffic source from its Rule list. Subsequent requests from that traffic source will not automatically receive the Rule's Tags and Action., unless/until that traffic source violates the Dynamic Rule again.

To exempt the traffic source from further Dynamic Rule enforcement, an admin should add appropriate tag(s) to the Dynamic Rule's Exclude list.

• Server Groups: properties of server(s) for sites(s).

• Backend Services: the services that L11WAAP is protecting.

• Edge Functions: for running custom Lua code.

• : information about DNS configuration.

• : managing SSL associated with load balancers.

• : for managing SSL certificates.

Overview

Security Alerts allow admins to configure email alerts to be sent when Dynamic Rules are triggered.

Usage within applications and APIs

Security Alerts operate at the system level. They can be defined for individual , or for multiple Server Groups simultaneously. When any of the specified Dynamic Rules is triggered for any of the specified Server Groups, an email alert will be sent to the designated recipient(s).

Each email alert includes:

• The Dynamic Rule that was triggered: its name, description, "Limit" (a combination of the Rule's Number of events and Time frame), and "Type" (which corresponds to the Rule's setting)

• A list of the violators of that Rule

Administration

The main window (shown above) lists all currently defined Security Alerts.

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

Parameters

Name

The name of this Security Alert, for use within the interface.

Server Groups

The Server Group(s) for which this Security Alert will be active.

Alert recipients

One or more recipients (specified as email addresses, separated by commas) to receive alerts when any of the listed Dynamic Rules are triggered.

Dynamic Rules

One or more Dynamic Rules which will, when violated, trigger the sending of email alerts to the specified recipients.

Whenever you change the configuration of the Link11 WAAP platform within the UI, you must save your changes, and you must publish them to the cloud as well.

Saving Changes

The various Editor pages within the UI have "Save" buttons in the top row of controls. Select this button to save whatever changes have been ma.de

Note that the "Save" button only saves your changes within your local session. To push them to your planet in the cloud, you must publish the changes as well.

Publishing Your Changes

Follow the process described here: .

Sometimes an admin needs to bypass the WAAP's traffic filtering, for example when "attacking" an application or server as part of a loadtest. Under normal circumstances, L11WAAP would prevent this, because it would enforce rate limits and block the excessive requests from reaching the backend.

Specific requests can be exempted from L11WAAP's traffic filtering (including rate limiting) by:

• Creating a Global Filter with narrowly-defined Rules (which will only match those specific requests, and no others)

• Selecting the Global Filter's Action to be one of type Skip

• And ideally, defining a unique to assign to those requests, so they will be identifiable in the traffic logs.

Incoming requests that meet the criteria for the Global Filter will not subjected to filtering. They will be passed directly through to the backend.

Scenario: An admin has recently created a new section within an existing domain. (In this context, "section" means a path, or set of paths, that can be described in a single regex.) For example, perhaps a new API version is being exposed at /apiv3, which is a URL that did not previously exist.

How can the admin configure Link11 WAAP's security settings for the new path(s)?

As shown in the diagram below, the association between security settings and paths is done within a Security Policy.

Specifically, each Security Policy contains a Path Map: a list of paths, and the security settings assigned to each.

Thus, the process for configuring new paths within L11WAAP is as follows:

1. Determine the Security Policy currently in place for the domain

2. Within that Security Policy, clone an existing Path Map

3. Configure the new Path Map as appropriate, to contain the new settings.

These steps are described below.

Determining the Security Policy

1. Navigate to Sites -> Server Groups.

2. In the list that appears, select the for the domain in question.

3. On the Server Group Editor page, note the current selection in the Security Policy pulldown list.

Cloning an existing Path Map

1. Navigate to Security -> Security Policies

2. Select the Security Policy that is (as noted above) currently assigned to the domain's Server Group.

3. At the bottom of the Security Policies Editor page is the Path Mapping section. Expand one of the entries in this list.

4. Within the expanded display of the Path Map, at the bottom right, select the Fork Path Mapping

Configuring the new Path Map

Ensure that the new Path Map is displayed for editing, and then:

1. Edit its Name to something appropriate

2. Define the Match path with an expression that will match all the new path(s) being configured

3. Verify that the other security settings in this Path Map are appropriate. If not, existing security rulesets (such as Rate Limit Rules, Content Filter Profiles, etc.) are available for selection. If it is necessary to create one or more new rulesets, you will need to leave this page (be sure to select Save first!), create the new settings, and return here to select them.

Motivation

By default, Link11 WAAP will block GraphQL traffic, for two reasons:

1. The size of the argument

2. number 600110, which contains this Match string: ([$@{}()\[\]].*){8,})

Enabling GraphQL traffic

To allow GraphQL traffic, create a with:

1. An Argument Max Length that will accommodate the maximum size of the queries

2. This tag in the Ignore Content Filter Tags list: cf-rule-name:600110

Then assign this Content Filter Profile to the location (i.e., the site or path) of the GraphQL queries via an appropriate .

Overview

As part of its security suite, Link11 includes robust bot management, including tracking of individual types of bots. There is some additional granularity for managing AI crawlers.

Overview

This page lists the load balancers currently set up within Link11 WAAP.

Load balancers are added and managed outside of the UI; for assistance in changing or configuring load balancers, .

Load balancer administration involves two primary activities:

• : one of Link11 WAAP's mechanisms for human verification.

• : for managing Single Sign-On for L11WAAP

• : for clearing the cache(s) of Content Delivery Network nodes

Link11 WAAP maintains Git versions of data and configurations.

This page displays previous versions of configurations, and allows admins to:

• Download a version by using the "Download" button at the top

• Revert/restore the system to any saved configuration.

To revert/restore, hover the cursor over the desired configuration. The "Restore"

This page pushes a selected system configuration to the proxy, and makes it active. This is necessary when:

• Edits were recently made to the current configuration

• Changing to a different system configuration on the page: either reverting to a previous version, or rolling forward to one that's different than the currently active one.

Overview

If the user is logged into the planet directly (i.e., without using SSO), then selecting the user icon () at the top right of the UI will display a menu, including an option for opening the Account Details page.

This page displays the account details of the current user, allows configuration of MFA (multi-factor authentication), and provides keys for using the API. Its sections are described below.

The section shows a list of traffic sources (i.e., sources of incoming requests) that are currently banned, blocklisted, and allowlisted.

How to ban a requestor

A traffic source is banned automatically when it violates a .

You cannot manually move a traffic source into quarantine. Instead, you can create a Dynamic Rule to do it for you. The Dynamic Rule's parameters should be as follows:

By default, Link11 supports communication between customer backends and .

When a backend system requests a new or renewed certificate from LE, Let's Encrypt responds initially with a challenge. Because Link11 WAAP is a proxy for the backend, this challenge will be sent to L11WAAP.

Under normal circumstances, L11WAAP will forward this to the customer system. If this is not occurring, something in L11WAAP's default configuration might have been changed.

To correct this, perform the following two-step process.

Step 1: Verify the necessary Global Filter

• Redirecting them to HTTPS

• Or simply blocking them.

Admins must also choose whether to refuse HTTP traffic:

• Globally, throughout the entire planet, or

The Link11 WAAP API is available in . This tool provides design documentation, and can also be used to submit API calls directly to your planet.

Location

By default, the API is available in Swagger UI at:

{your planet name}/api/v4.0/openapi.

Overview

Link11 WAAP maintains most of its security parameters as Entries, which are contained in Documents, which are contained in Configurations.

A Configuration is a complete definition of L11WAAP's behavior for a specific environment. An organization can maintain multiple Configurations (e.g., development, staging, and production).

Each Configuration contains multiple Documents of various types (Global Filters, ACL Profiles, etc.) Each Document contains at least one Entry, i.e., an individual security rule or definition.

A Configuration also includes data blobs, which currently are used to store the geolocation database. This is where L11WAAP obtains its geolocation data and ASN for each request it processes.

Different types of rate limits are defined in different parts of the Link11 WAAP interface.

Static rate limits for entire sites/applications: A static rate limiting capability is available via the within . This is simple, IP-based rate limiting that applies globally to every site/application based upon that Proxy Template.

Granular rate limiting: More powerful capabilities are available through , including variable scope, multiple criteria for tracking requestors, actions, and more. These Rules are then associated with specific locations/URLs through .

Global enforcement by traffic source: Requestors who submit excessive requests across the planet can be banned for configured lengths of time. This can be done via .

Link11 WAAP includes an API that provides full coverage of the system's capabilities.

Using the API will require familiarity with the following:

• L11WAAP's

• The API's namespaces and endpoints, which are documented in two locations:

  • In the reference section of this manual

Overview

Link11 WAAP includes a Mobile SDK: a unique client certification mechanism for iOS and Android apps. Customers can publish their applications with the SDK embedded.

In use, the SDK signs the application, authenticates the device, and verifies user identity, adding a cryptographic HMAC signature to each request. The SDK provides a reliable and secure mechanism to confirm that the traffic is originating from a legitimate app user and not a bot or emulator.

Acquiring the SDK

The latest version of the Mobile SDK, including instructions and code samples, is available here:

Below, we discuss the parameters to configure within L11WAAP for receiving requests from mobile applications.

Usage

A Mobile Application Group configures Mobile SDK parameters for a specific (which usually represents a domain).

Administration

The main window (shown above) lists all currently defined Mobile Application Groups.

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

Components

Name

The name of this Mobile Application Group, for use within the interface.

Description

A description of this Mobile Application Group, for use within the interface.

Token header name (optional)

The name of the header that contains the user authentication token. This can be left blank.

Grace period

The allowable time between the timestamp of a request and the time that L11WAAP receives the request from the application. Requests with a longer delay will be rejected.

App signatures

This list contains the SHA-256 digests of recognized certificates.

To find the signature for an iOS app, you can open the Apple Development Certificate in the Keychain app, and copy the SHA-256 fingerprint. Alternatively, you can this fingerprint from the ipa bundle.

For Android app, you can get the SHA-256 fingerprint from the keystore or extract it from a signed APK with the apksigner tool (part of the Android SDK). See detailed instructions .

When uploading the fingerprint to the L11WAAP Console, make sure that it contains hexadecimal characters only, in lowercase, without spaces.

Active mode

Any number of signatures may be 'Active' at given time.

Profiles

This lists the remote profiles that can override the parameters of the SDK on all mobile clients.

The Default profile is always empty. When it is active, the SDK parameters are fully determined by the app's local configuration. Only one remote profile may be active at a given time.

Overview

Link11 WAAP contains several mechanisms for detecting bots within web traffic, including Active Challenges and Passive Challenges.

This page allows admins to configure the third mechanism: the L11WAAP Interactive Challenge, which is a form of CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart").

The Interactive Challenge is more stringent than the other mechanisms. Therefore, when an Interactive Challenge is triggered, the user must pass it before being allowed to continue, even if the user had previously passed an Active Challenge or Passive Challenge.

Usage within applications

The Interactive Challenge defined on this page can be used at various places within a web application. Create one or more with the Type parameter set to Interactive Challenge, and then use the Action(s) within the appropriate security rulesets (within , , , and ).

Parameters

The parameters described below will determine how the Interactive Challenge page is displayed to the user.

Direction

The direction of the text displayed to the user. For example, English should be set to Left to right, while for Hebrew, this should be set to Right to left.

Style

This specifies how to display the image configured in the Image/IMG settings within the Languages section. When set to Logo, the image will be shown on the page once. When set to Wallpaper, the image will be tiled to fill the page.

Palette

The colors used in the challenge.

Languages

Admins can configure Interactive Challenges in different languages. A default L11WAAP deployment will contain English; to add additional languages for configuration, select New language. (This appears below the Languages section; you can collapse the section to make it more accessible.)

Each configured language will include the options below.

Title

The title that will be shown on the page.

Buttons text

During the Interactive Challenge, two buttons are shown to the user. The top field specifies the text for the first button that appears, and the bottom field specifies the text for the second button.

Image Element Source

This is the source for the image that will be shown on the Interactive Challenge page. It will be shown according to the Style setting.

IMG Element Preview

This displays a preview of the image specified in the Image Element Source.

Testing an Interactive Challenge

To see how an interactive challenge will appear to a user, you can select it as the Action for a dedicated : one with a Rule list that will only match a test request (e.g., a specific IP that you will use to test the challange).

This feature allows admins to purge CDN caches at various scopes:

• The entire planet

• Specific domain(s) within the planet

• Specific paths within domain(s)

A history of current and past activity is provided.

Prerequisites

This feature is available when at least one CDN has been set up in the system. (To do this, contact customer support.) If no CDN is currently configured, an error message will be shown.

Three-Step Purging Process

Purging requires these steps:

1. Select the cache(s)

2. Initiate the purge

3. (Optional) monitor the results

Step 1: Select the cache(s) to purge

Cache selection varies, depending on the CDN being used.

To purge caches for an entire planet

For non-AWS CDNs, at the top left of the page, ensure that All domains in the planet is selected, then skip the remainder of Step 1, and continue to Step 2 below.

To purge one or more domains within the planet

AWS Cloudfront users will see the controls described below. For non-AWS CDNs, at the top left of the page, ensure that Specific domains is selected to display them.

• Select CDN: If there are multiple AWS load balancers, this control will appear. Select the AWS CDN provider for each domain/path where the cache has to be purged. In other situations (e.g., the planet uses the Google Cloud or Link11 CDN, or has only one AWS load balancer) this control is unnecessary and will not appear.

• Alternative domain names: For non-AWS CDNs, specify a domain configured within the planet. AWS Cloudfront does not support individual purges, so Cloudfront users will see a non-editable list (for informational purposes only) of all the domains for which caches will be purged.

• Add a specific path:

Adding more domains/paths Multiple domains and/or paths can be specified for a purge.

After appropriate values have been entered into the controls described above, if another domain or path purge needs to be defined, select the New Host button and populate the new entry in the purge list. Repeat this process until all desired purges have been specified.

Step 2: Initiate the purge

Select the Purge CDN cache button. The specified purge(s) will appear in the Results list at the bottom of the page.

Step 3: (Optional) monitor the results

The Results list shows a history of purge commands submitted during the previous week. The list shows the date and time when each was submitted.

Within the list, the Status field shows the result of each purge during the most recent status update. Updates occur when the page is loaded or reloaded, and also each time the Refresh Status button is selected.

The possible statuses are:

• In progress: as of the most recent status update, the purge was still being processed. (Note that depending on how recently the list was updated, the actual current status might be different.)

• Done. The purge completed successfully.

• Failed. The purge was attempted but was not successful. To try again, a new purge command must be submitted.

• Not available. The purge was unsuccessful because the CDN was unavailable. To try again, a new purge command must be submitted.

Overview

This page allows admins to manage users of the Link11 WAAP system.

Administration

User administration follows the List/Editor UI conventions described .

Add a new user

Select the + New button, and the New User dialog will appear:

Note that once a user is created, the email and organization values cannot be edited later. To change these, the user should be deleted and

User Parameters

Overview

Log Exporters allow admins to stream event data to an outside destination, e.g. a SIEM solution. Every few seconds, Link11 WAAP bundles and exports the most recent traffic events from its internal logs.

If desired, data values can be truncated according to settings in the System DB.

Below is a discussion of the console interface for configuring Log Exporters.

Usage within applications and APIs

Log Exporters operate at the system level. Admins can configure them for specific , or for the entire planet.

Administration

The main Log Exporter window lists all currently defined Log Exporters.

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

Parameters

Name

A unique name for use within L11WAAP.

Status

Whether or not this Log Exporter is currently active.

Destination IP

The destination IP to which event data will be sent.

Port

The port to which event data will be sent.

Server Groups

The specific server groups for which event data will be sent.

Include encoded request data

When this is enabled, exported data will include a Base64-encoded representation of the HTTP request: its headers, cookies, and query arguments. This enables customer admins to extract and inspect the auth token and other metadata required for customer identification and security analysis.

Request data will be truncated (if necessary) to the , then encoded for export.

Transport protocol

The protocol to use while streaming the event data.

• TCP: Event data will be streamed over TCP.

• TCP + TLS (Trusted): Event data will be streamed over HTTPS. When this is selected, an additional control will appear for uploading a PEM file containing the TLS certificate for the data's destination. The system will validate the certificate upon upload.

• TCP + TLS (Untrusted): Event data will be streamed over HTTPS, but the system will not use a certificate.

Requests to export

• Blocked: Export only the requests blocked by L11WAAP.

• All: Export all the requests blocked or passed by L11WAAP.

Troubleshooting

If a Log Exporter has been configured but is not streaming data:

1. Verify that it is in .

2. If its is TCP + TLS (Trusted), verify that the certificate is valid and has not expired.

If a Log Exporter is streaming truncated data, verify the data-length limits set in the .

Sometimes situations will arise where an attacker needs to be blocked temporarily, while the security posture is being reconfigured. Since the hostile traffic is not being filtered, admins recognize that their security posture needs to be strengthened, but they need some time to analyze the situation. Meanwhile, the attacker should be blocked.

It might seem that admins should merely add the system tag for the attacker's IP (e.g., ip:82-64-131-193) to the Enforce Deny column in the applicable ACL Profile. This can work (as long as the attacker is consistently using the same IP), but it's not necessarily the best approach.

Using a Global Filter

The better approach is usually to create a , based upon criteria that will match the attacker (but will not match any other traffic source), with an to block the matching requests.

Here's why this is usually the optimal choice:

• While both approaches can be done when the attacker is using a single IP (or a set of IPs), the second one also supports situations where the attacker is rotating IPs, and therefore needs to be identified with a combination of characteristics.

• The ACL Profile will limit the blocking to specific paths/URLs (those defined in the associated with it, and used within one or more ). The Global Filter will block the attacker's activity globally, which is usually more desirable.

• The Global Filter is more efficient during processing, because the hostile requests are blocked earlier in the .

Consider a dedicated Global Filter for long-term management

Instead of creating and discarding one-off Global Filters, it's often better to maintain a dedicated Global Filter for manually blocking attackers. As traffic sources need to be blocked (or unblocked), admins can just add (or remove) matching criteria.

This creates a single location for administering these special cases. Admins can easily monitor the current list of manual interventions, and purge them as they become obsolete.

Prerequisites

The {config} API parameter is discussed here.

Load balancer administration is discussed here. The discussion below assumes familiarity with it.

Special considerations when using the API

Multi-regional configuration

As explained , when a Link11 load balancer supports a multi-regional planet, admins can (if desired) configure traffic routing.

The API provides additional granularity beyond the configuration available in the web console:

• In the UI, the load balancer is treated as a single instance. However, this "one" load balancer is conceptual: it represents multiple physical instances, running simultaneously in different cities. The API provides the ability to configure each city separately, if desired.

• In the UI, the Preferred datacenter control displays a list of datacenters where Link11 WAAP has been deployed. In the API, this list is provided in the upstream_regions parameter, which is returned when calling GET /api/v4.3/conf/{config}/load-balancers/regions.

• In the UI, one Preferred datacenter can be selected, which will be applied to all cities. In the API, different datacenters can be specified for different cities, by calling POST /api/v4.3/conf/{config}/load-balancers/regions.

API overview

To retrieve information about all load balancers:

GET /api/v4.3/conf/{config}/load-balancers

To add a certificate:

PUT /api/v4.3/conf/{config}/load-balancers/{entry_name}/certificates/{certificate_id}

To remove a certificate:

DELETE /api/v4.3/conf/{config}/load-balancers/{entry_name}/certificates

To get the list of Link11 WAAP datacenters, and each city's current preference:

GET /api/v4.3/conf/{config}/load-balancers/regions

To set preferred datacenters for each city:

POST /api/v4.3/conf/{config}/load-balancers/regions

Operations

Overview

When L11WAAP processes incoming requests (as described in the discussion of the ), the system must perform:

• Policy mapping: deciding which security rulesets are applicable to the request.

This page within the L11WAAP console displays the current System Database. The parameters contained here are used throughout the system.

Most of these settings are displayed for informational purposes only. In some cases, they can reflect features of the system not currently in use.

The following features are available for configuration by customer admins:

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.

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 Policy Mapping page.

Overview

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.

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 Pre-Processing" Edge Functions

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 Pre Processing, the Function is executed immediately, before other processing occurs.

Initialization

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.

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

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.

Global Filters

The stage has two primary purposes:

• Attaching tags when the request matches specified criteria.

• 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.

Flow Control

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

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.

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

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:

• that do not have enabled.

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

ACL Profiles

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.

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

• The request triggers an .

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

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

Content Filtering

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

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.

"Request Post-Processing" Edge Functions

When an has a setting of Request Post Processing, L11WAAP will execute it as the final step in its processing, before sending the request to the backend.

Customer Backend

When a request has passed all of the system's processing, 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 .

Actions

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.

Logging

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

Analytics and Dashboards

The and provide customizable displays of traffic and events.

Dynamic Rules and Quarantines

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.

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 is added to the list, where admins can monitor it.

• 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.)

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

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.

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.

Administration

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

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

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.

Each of these is described in depth below.

Individual parameters

Name

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

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

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

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.

Overview

A traditional WAF evaluates incoming requests according to a list of threat signatures, and flags the request if any matches are found.

Within Link11 WAAP, Content Filter Rules provide the equivalent of these signatures, although they are more powerful and flexible than those within a traditional WAF.

When a request undergoes the content filtering process, its content is compared to the Rules administered here. When a request matches a Rule, various tags will be attached to it. Those tags can be evaluated, and can cause actions to be taken on the request.

Usage within applications and APIs

Content Filter Rules are defined globally within the system, and are available to all Content Filter Profiles.

The usage of Content Filter Profiles within applications and APIs is explained .

Administration

The main page lists all current Content Filter Rules.

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

Components

A Content Filter Rule consists of the following:

• The signature for this Rule. Usually, this represents the characteristics that makes a request hostile. (Match)

• Organizational parameters for the Rule (Category, Subcategory, Risk level)

• Tags to apply to requests that match this Rule

Parameters

Name

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

For the default Rules included with L11WAAP, the Names are numeric identifiers. (A production deployment will include a large number of Rules; therefore, they are usually organized/administered by their categories and subcategories.)

Description

Information about this Rule, for use within the interface.

Category

A general category for this Rule. It will be the basis for a system tag.

Subcategory

A subcategory for this Rule, within the general Category. It will be the basis for a system tag.

Risk level

A number ranging from 1 (lowest threat) to 5 (highest threat). It will be the basis for a system tag.

Tags

A list of one or more tags, separated by spaces. Whenever this Content Filter Rule's Match condition matches a request, these tags will be attached.

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

The tags are the basis for the decisions made when the applicable is evaluated for a request. They will also appear in the traffic logs.

Log Message

(This field is not currently used, but will be in a pending release.) A message that will appear in the traffic logs when a request matches the Match condition.

Match

The criteria against which incoming requests will be compared. For Content Filter rules only, regexps are of the hyperscan flavor ().

As described here, out of the box Link11 WAAP includes an Active Challenge process. This is very useful in distinguishing humans from bots.

Active Challenges work well, but an even better option is Passive Challenges.

• Active Challenges temporarily redirect the user's browser. This can affect site metrics gathered by products such as Google Analytics. (Specifically, the initial referrer information is lost.) Passive Challenges are simple pieces of Javascript. They do not redirect the user's browser; they merely ask it to solve a challenge, and then insert the L11WAAP cookies.

• Active Challenges will not occur when site content is served from a CDN. Passive Challenges can still detect bots in this situation.

Most importantly, Passive Challenges allow L11WAAP to use Biometric Bot Detection—an advanced and sophisticated means of distinguishing humans from automated traffic sources.

Biometric Bot Detection

With Biometric Bot Detection, L11WAAP continually gathers and analyzes stats such as client-side I/O events, triggered by the user’s keyboard, mouse, scroll, touch, zoom, device orientation, movements, and more. Based on these metrics, the platform constructs and maintains behavioral profiles of legitimate human visitors. L11WAAP learns and understands how actual humans interact with the web apps it is protecting. Continuous multivariate analysis verifies that each user is indeed conforming to expected behavioral patterns, and is thus a human user with legitimate intentions.

Implementation

Implementing Passive Challenges is simple. Place this Javascript code within the pages of your web applications:

If desired, the script code can include async and/or defer attributes:

These usually are not necessary, and their effect will depend on the placement of the script within the page. Their use is left to your discretion.

Testing

To test the implementation, use a browser to visit a page containing the Javascript snippet. Once it runs, the browser should have a cookie named waap_id.

Disabling Active Challenges (Optional)

There are two primary situations where customers sometimes want to disable Active Challenges:

• When a customer needs site analytics to correctly reflect all referrers. (Active Challenges can interfere with this.)

• For API endpoints. Active Challenges are designed to verify the client's browser environment; for most API calls, there is no browser environment to verify. (For users of our , this is not a problem. They can still use active challenges for these endpoints.)

Other than those situations, Active Challenges can be very beneficial.

If you wish to turn off Active Challenges, do the following.

• Decide which paths/URLs should have Active Challenges disabled.

• Make a list of the that are enforced upon those paths/URLs.

• Ensure that this combined list of Security Policies does not apply to any paths/URLs where you wish to keep Active Challenges enabled. If there are some undesired paths/URLs included, split them off into separate Security Policies that are not part of the list. When you are done, the list of Policies should include all desired paths/URLs, and only those paths/URLs.

Overview

Link11 WAAP supports mTLS encryption. This is optional, and can be enabled separately for:

• Communication between Link11 WAAP and customer backends, for one or both ends of the pipeline.

• Communication between clients (end users) and L11WAAP.

To enable mTLS for an end of a pipeline, the appropriate certificate must be supplied. Their names within the system are as follows:

How it works

L11WAAP-to-customer-backend mTLS

Configuring mTLS to the customer backend is straightforward. After enabling this feature (as described below), admins add certificate(s) and assign them to . Once configured, L11WAAP will use mTLS when communicating with customer origins.

Client-to-L11WAAP mTLS

Configuring mTLS to clients also requires feature enablement. Then, admins add CA Certificates and assign them to .

Once client-to-L11WAAP mTLS is configured, end users will be required to present a client certificate at the beginning of each session during the TLS handshake. L11WAAP will validate the certificate, including the date, issuer, and verification against the . If validation fails, the user will receive an error, and will not be permitted to connect to the protected system.

Two additional notes about this type of mTLS:

• In the user interface, mTLS is only available when using an AWS (Network Load Balancer). To enable mTLS when using a Link11 load balancer, contact support.

• mTLS verification does not exempt a client from other types of traffic filtering. Even if a client successfully establishes an mTLS connection with L11WAAP, its requests will still be blocked if they originate from a banned source, or exceed rate limits, or match a content filtering signature, etc.

How to configure mTLS for communication with the backend(s)

Follow this process:

• .

• Upload the certificate(s) in the Server-to-Backend mTLS Certificates tab and/or Server-to-Backend CA Certificates tab(s) of the page.

• your changes.

• Assign the appropriate certificate(s) to each Backend Service:

How to configure mTLS for communication with clients

Follow this process:

• .

• Upload the CA Certificate(s) in the CA Certificates tab of the page.

• your changes.

• Assign the appropriate certificate to each Server Group:

While Swagger UI provides a visual interface into the API, it is often desirable to send API calls via the command line. For this, curl can be used.

Required information

To send a curl request to the API, two things are required:

• An API key

• The curl command string

Obtaining an API key

If an API key is not already available from previous API usage, the following steps should be followed.

1. Log into the planet console using a Link11 WAAP account (i.e., without using SSO). The account must have an of Editor or higher.

2. Navigate to by selecting the user icon on the top right of the page

3. Navigate to Account Details -> API Keys. (If Account Details is not displayed in the Account menu, verify that the login was done directly into the planet using an L11WAAP account. If SSO is used, Account Details will not be available in the interface.)

Using Swagger UI to construct the curl command string

Sending an API request via Swagger UI will also construct and display its curl command string:

1. Navigate to .

2. Expand the desired namespace, and then the desired route within the namespace.

3. Select the "Try it Now" button

4. Edit the input fields (if any), providing all required inputs

To send this request using curl, edit the command string to include an additional header (Authorization:Basic) for the API key obtained earlier.

Example

When Swagger UI is used to get a list of configurations via GET /api/v4/conf/configs, it will also display this curl command:

To submit this command directly via curl, the following header must be added:

...without the <>, and where api-key-obtained-earlier is the string obtained .

Manually constructing the curl command string

API calls using curl are constructed according to these requirements:

• The API key is included, as explained above

• Input parameters defined as query are encoded into the URL

• Input parameters defined as header are included as headers

• Input parameters defined as Request body are included via curl's -d

Example: query and header parameters

A route to retrieve traffic data has this definition:

Note that limit, offset, filters, and debug are marked as query parameters, and therefore, will be encoded into the URL. However, syntax and provider are marked as header parameters.

The resulting curl command will look like this:

Example: request body

The POST /api/v4.0/data/timeline/parse call includes this input:

Let's say that an admin wants to submit the string timestamp between 2024-06-06 09:31:00 and 2024-06-06 09:36:00, status=301. The curl command would look like this:

Overview

This section allows admins to manage SSL Certificates. There are four kinds of certificates, each with its own tab:

• Server Certificates, so that clients (end users) can communicate with Link11 WAAP using HTTPS.

• CA Certificates, so that Link11 WAAP can validate clients for mTLS communication.

• Server-to-Backend mTLS Certificates, so that customer origins can validate Link11 WAAP for mTLS communication.

• Server-to-Backend CA Certificates, so that Link11 WAAP can validate customer origins for mTLS communication.

Server Certificates are necessary for end users to communicate securely with Link11 WAAP. The other types of certificates are optional, and are only necessary for using mTLS (mutual TLS).

Here is a diagram of the different types of certificates:

Out of the box, Link11 offers management of Server Certificates.

To enable management of the other types of certificates so that their tabs appear in the interface, follow the instructions here: .

Usage within applications and APIs

Server Certificates can be attached to , or to domains via .

Similarly, CA Certificates are also used in Server Groups. However, they are only available in the interface when using AWS NLB (Network Load Balancing). When using a Link11 load balancer, please contact support.

Server-to-Backend mTLS/CA Certificates are used in .

Administration

The list of currently defined Certificates is displayed in each tab. From here, new certificates can be generated, or existing ones can be edited.

All four types of certificates are administered using the same procedures, described below.

Securing private keys

By default, Link11 WAAP offers admins the ability to auto-replace certificates using Let's Encrypt, and to download certificates in PFX format. To remove these features from the web console and API, .

Generating a Certificate

Selecting the + New button displays the Upload Certificate dialog:

Certificates can be added manually, or L11WAAP can parse a PFX file.

Editing/Configuring a Certificate

When an existing Certificate is edited, the Edit Certificate dialog appears:

Editable parameters and controls

Auto Replacement by Let's Encrypt

Let's Encrypt is a free certificate authority service. L11WAAP integrates with it, and offers this service by default.

Once a day, L11WAAP will check each application it protects. If that application's certificate is going to expire in the coming week, and its Auto Replacement by Let's Encrypt option for that certificate is enabled, L11WAAP will generate a new certificate using Let's Encrypt, and will attach all of its sites to the new certificate.

Attach To Application

This tab includes a list of Server Groups. Selecting one will connect this Certificate to it.

Replace Existing Certificate

This tab includes a list of Certificates defined within the system. Selecting one and then clicking Save will result in all sites/applications being transferred from the selected Certificate over to the Certificate you're currently editing.

Download PFX

This will download the certificate information as a file in PFX format.

November 24, 2025

What's New

Overview

An Edge Function (EF) allow you to extend Link11 WAAP's tools and functionality. An EF consists of Lua code that can be run at different points in L11WAAP's traffic processing.

An EF can be configured to execute before any other processing occurs. Therefore, it can override or preempt other configured settings within L11WAAP.

Or, it can be run after traffic filtering has been completed. An example use case is .

This section explains the usage of L11WAAP's API.

Metrics

The Link11 WAAP and provide intuitive yet powerful ways of viewing your traffic.

Data is reported in terms of several statistics:

Overview

This page provides the ability to review and analyze the most recent traffic, up to and including real time. It is a powerful tool for traffic control; if a security event occurs, this page will allow you to quickly find its root cause.

Running a query will display a list of requests matching the specified criteria. Each request can be expanded to display additional details.

Overview

When a request is processed by Link11 WAAP, a number of are assigned to it during the early stages of the .

As one of the final stages of processing, the relevant ACL (Access Control List) Profile for this request is evaluated.

The ACL Profile 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.

Overview

At various stages in the traffic filtering process, Link11 WAAP can execute an action according to the characteristics of the request. These actions are defined within Actions.

Out of the box, L11WAAP includes several default Actions for admins to select. Additional ones can also be defined.

Introduction

Many security solutions provide information only about the traffic that they block. Contrary to this, Link11 WAAP shows all of the traffic that it receives.

This provides you with a powerful ability to dig into your traffic data and gain deep understanding about the nature and disposition of incoming requests.

Metrics about blocked requests are useful, but their usefulness is multiplied when you can compare them to passed requests. By showing all requests, L11WAAP allows you to understand what "normal" requests look like. This gives you more insights into abnormal traffic.

The Link11 WAAP API includes over a dozen namespaces, each containing a number of routes.

Each namespace has its own page in the documentation, listing all its routes, their parameters, and so on. These pages can be accessed in the left sidebar, in the .

Below is a general guide to the namespaces, showing the type of functionality each one provides. The namespaces can be organized into three broad categories: