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
  • Biometric Bot Detection
  • Implementation
  • Testing
  • Disabling Active Challenges (Optional)

Was this helpful?

Export as PDF
  1. Using the product
  2. Best Practices

Enabling Passive Challenges

PreviousSaving and Publishing Your ChangesNextUnderstanding and Diagnosing Traffic Issues

Last updated 1 month ago

Was this helpful?

As described , 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.

We recommend that all customers enable Passive Challenges if it is possible to do so. Biometric Bot Detection provides much more robust detection of automated traffic than is possible without it.

Implementation

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

<script src="/c3650cdf-216a-4ba2-80b0-9d6c540b105e58d2670b-ea0f-484e-b88c-0e2c1499ec9bd71e4b42-8570-44e3-89b6-845326fa43b6" type="text/javascript"></script>

The code snippet can go into the header or at the end of the page. The best practice is to place it within the header. This ensures that subsequent calls contain authenticating cookies.

(This matters for the first page served to a visitor. Subsequent pages will already have the authenticating cookies to include with their requests.)

Most customers set up the code snippet as a tag within their tag manager. This makes it simple to install it instantly across their entire site/application.

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

<script async src="/c3650cdf-216a-4ba2-80b0-9d6c540b105e58d2670b-ea0f-484e-b88c-0e2c1499ec9bd71e4b42-8570-44e3-89b6-845326fa43b6" type="text/javascript"></script>
<script defer src="/c3650cdf-216a-4ba2-80b0-9d6c540b105e58d2670b-ea0f-484e-b88c-0e2c1499ec9bd71e4b42-8570-44e3-89b6-845326fa43b6" type="text/javascript"></script>

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

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

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

We recommend that you keep Active Challenges enabled if possible. They automatically eliminate almost all DDoS traffic, scanning tools, and other hostile bot traffic.

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

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

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

  • For each Security Policy in the list:

    • To partially disable Active Challenges, ensure that its ACL Profile has the proper combination of tags in the Bot Challenge / Skip and Bot Challenge / Apply columns.

Note that the acl-deny-bot ACL Profile includes the all tag in its Bot Challenge / Apply column. As described above, for all Security Policies that use this Profile, you could exempt some traffic sources from Active Challenges by adding tags to the Bot Challenge / Skip column, or all traffic sources by removing the all tag.

However, if this were done, then this Profile would not behave in the way that its name implies. This can cause confusion later: not only during administration, but also when viewing events in the Dashboard and Events Log. To avoid this situation, we recommend that this default Profile should not be edited. Instead, admins should create a separate one for use in the relevant Security Policies.

Turning off Active Challenges will disable the direct blocking of bots (where a requestor is blocked merely for being identified as a bot). However, automated traffic will still be excluded via all other relevant means.

If you have not enabled Passive Challenges (and successfully tested them), disabling Active Challenges is not recommended.

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

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

To completely disable Active Challenges, ensure that its does not include any tags in the Bot Challenge / Apply column.

Mobile SDK
Security Policies
ACL Profile
More information about this.
here