Link11 WAAP
v2.12
v2.12
  • Link11 WAAP v2.12 Portal
  • Introduction
  • Getting Started
  • Setup Checklists
  • Marketplace onboarding
  • Console UI Walkthrough
    • Traffic
      • Traffic Concepts
      • Dashboard
      • View Log
    • Security
      • Security Section Concepts
      • Static Rules
      • Dynamic Rules
      • Quarantined
      • Profiles
        • Profile Concepts
        • Profiles
        • ACL Policies
        • WAF/IPS Policies
        • Custom Signature
      • Args Analysis
    • Settings
      • Web Proxy
        • General Settings
        • Application Profiles
        • Security Profiles
      • SSL Management
      • DNS
      • Planet Overview
      • Account
  • Using the product
    • Best Practices
      • Saving and Publishing Your Changes
      • Enabling Passive Challenges
      • Using the Reblaze Query Box
      • Understanding and Diagnosing Traffic Issues
    • How Do I...
      • Ban, Unban, and Whitelist Traffic Sources
      • Bypass Rate Limits for Loadtesting
      • Control Caching Behavior
      • Filter by Content
      • Quickly Block an Attacker
      • Secure Traffic from a Third-Party Page
      • Set Rate Limits
      • Set up SIEM/SOC integration
      • Video Tutorials
        • DNS Training
        • SSL Training
    • API
      • Reblaze REST API
      • Mobile SDK
  • Reference Information
    • Access log-structure
    • Acronyms
    • Deployment Terminology
    • Hostile Bot Detection / RCSI
      • Environmental detection and browser verification
      • Client authentication
      • Biometric behavioral verification
    • HTTP Response Codes
    • Pattern Matching Syntax
    • Signatures
    • TTL Expression Syntax
  • Support
Powered by GitBook
On this page
  • The Challenge Process
  • How Requests Are Reflected in Reblaze's Statistics
  • Counting Bots
  • Relationships of Traffic Metrics
  • Hits = Passed + Blocked + Challenges
  • Hits = Humans + Bots
  • Active Challenges versus Passive Challenges

Was this helpful?

Export as PDF
  1. Console UI Walkthrough
  2. Traffic

Traffic Concepts

How Reblaze reports on the requests it receives

PreviousTrafficNextDashboard

Last updated 4 years ago

Was this helpful?

The Reblaze and provide intuitive yet very powerful ways of viewing your traffic.

Within those sections, your traffic data is reported in terms of several statistics:

Statistic

Comment

Hits

Total incoming requests

Humans

Requests originating from humans.

Bots

Requests originating from traffic sources not (yet) verified to be human. Most of the requestors will be bots, but some will not be. More on this below.

Passed

Requests accepted by Reblaze and passed upstream to the origin (i.e., the web server, API endpoint, etc.).

Blocks

Requests deemed to be hostile, and blocked.

Challenges

The Dashboard provides a variety of ways to view your traffic. Most of them do not include all of the above metrics in the same view (as in the first screenshot below), but some do (as in the second screenshot below).

The discussion below is for sites and web applications.

The Challenge Process

Most of the Reblaze interface focuses on configuration for:

  • The detection and mitigation of hostile requests.

  • The detection and mitigation of hostile behavior of requestors.

The challenge process is different. It is built into Reblaze, and provides a third approach to security. It mitigates threats based on the requestor's identity and environment.

When Reblaze receives the first request from a previously unknown traffic source (below described as the "user"), this is the typical process that is followed.

  1. If the challenge is not passed, the request is suspected to be a bot, and another challenge is issued. This process continues until a challenge is passed, or a threshold is reached (e.g., via a Dynamic Rule) to ban the requestor.

  2. If the challenge is passed, the browser's session is authenticated, and the browser receives cookies from Reblaze.

  3. The browser then automatically resubmits the original request, but this time, the cookies are included. The user is granted access to the requested URL, resources, etc.

  4. Subsequent requests will also include the cookies, and thus, they are not challenged.

This process happens quickly (in a few milliseconds), and is invisible to the user.

As noted above, this is the "typical" process that occurs in normal use. There are a variety of situations in which it might not be followed. For example, sometimes Reblaze is configured to whitelist certain IP addresses, and not to challenge them.

The discussion below will be based on the typical process described above.

How Requests Are Reflected in Reblaze's Statistics

The process described above will result in the following statistics being incremented.

For each challenge that was not passed:

  • Hits

  • Challenge

  • Bots

If the challenge was passed:

  • Hits

  • Challenge

  • Bots (see explanation below)

  • Hits (incremented a second time for the post-challenge resubmission of the request)

  • Passed

  • Humans

Counting Bots

Within Reblaze, a request that does not have authenticating cookies is counted as a bot.

As a result, the Bot count can sometimes be incremented even when the visitors are humans. Examples:

  • When a human user visits a Reblaze-protected site for the first time, the first request does not yet have the authenticating cookies.

  • Static files (images, etc.) are often exempted from challenges for performance reasons. Direct requests for those URLs from a new visitor will not have cookies.

  • Sometimes, trusted IPs are whitelisted and exempted from challenges. They never receive authenticating cookies.

Therefore, although most of the Bot count represents non-human requests to your web application, the Bot metric is not an exact count of this.

Relationships of Traffic Metrics

When working with Reblaze's traffic statistics, the following relationships can be helpful.

Hits = Passed + Blocked + Challenges

Hits = Humans + Bots

Active Challenges versus Passive Challenges

The process described on this page is the active challenge process. Out of the box, this is the challenge process that Reblaze uses.

We recommend that whenever possible, customers also enable passive challenges.

  • In some situations, active challenges can interfere with certain metrics such as those provided by Google Analytics. (The initial referrer information is lost.) If this is a problem, active challenges can be disabled. In this situation, passive challenges can provide effective bot protection instead.

  • When caching is being done by a CDN, active challenges will not occur for pages being served from the cache. Passive challenges are necessary for Reblaze to perform bot detection in this situation.

If possible, we recommend that customers use both active and passive challenges.

Requests that were challenged. The is an important part of Reblaze's traffic processing, as seen below.

Reblaze processes "web" requests (http/s traffic for a web site or application) differently than API requests from a mobile/native application. Mobile applications have different methods of client authentication, as discussed here: .

Reblaze challenges the user's browsing environment. Reblaze uses a variety of proprietary, multi-faceted techniques to verify that this requestor is a human using a browser, instead of a bot using a headless browser or emulator. (For more detailed information, see .)

Passive challenges still include, while adding three additional benefits:

They enable : a much more powerful means of identifying automated traffic, and an important part of Reblaze's behavioral analysis.

To learn more about passive challenges, go here:

Mobile SDK
Environmental detection and browser verification
Environmental detection and browser verification
biometric behavioral verification
Enabling passive challenges.
challenge process
Dashboard
View Log
This graph shows Hits, Challenges, and Blocked
The Top Sessions view shows all the metrics