The Traffic section allows you to monitor your network activity on a monthly, weekly, daily, hourly, or even minute-by-minute basis. It contains two primary sections: the Dashboard and View Log.

Dashboard: Provides an overview and a breakdown of your traffic to the VPC, during specified time frames. In addition, the Dashboard also provides information about Top Activities (a sorted summary of your top events).

View Log: Provides the ability to view and query network traffic data. You can analyze and monitor traffic data in real time, or over custom time frames.

Before diving into the interface, it's helpful to first read Traffic Concepts: How Reblaze reports on the requests it receives.

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

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

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

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

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

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

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

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

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)

Counting Bots

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.

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.

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

To learn more about passive challenges, go here:

After logging into Reblaze, the Dashboard screen is the first screen you'll see. It displays all incoming traffic and what happens to it. By default, this screen shows current activity; by using the archives, you can also 'go back in time' to see previous activity.

The user interface has three main sections:

1. Filtering and Time Interval Selection

2. Traffic Graphs

Filtering and Time Interval Selection

Query Box

Allows you to easily filter the display to show exactly what you want. The structure of a filter is operator:value.

For example, to show all traffic from France that was blocked:

country:France, is:blocked

For a full explanation of Reblaze's Query box, including operators and syntax, .

Time Interval Selection

Enables the user to select a pre-defined time frame, or a custom time period. See the video below:

Traffic Graphs

Passed vs. Blocked

This section shows the traffic that was processed by Reblaze: requests which passed through to the upstream servers, and requests that were blocked. Hits are distributed by time and sorted into three different categories: Humans, Challenges, and Blocked. As you can see in the example below, the data is shown in different colors to easily distinguish among the categories.

Response Status

Counts the number of status codes in a certain time period.

HTTP Status response codes are divided into five categories:

• 1xx - Informational Response

• 2xx - Request Successful

• 3xx - Request For Redirection

• 4xx - Client Error

For a detailed list of response codes, .

As in the Passed vs. Blocked display, the data is shown in different colors.

Requests Count

The number of network requests during a certain period of time.

Bandwidth

The downstream bandwidth limitation per response. Left-axis units are "k" for kilobytes, and "M" for megabytes.

Latency

This displays the time (in milliseconds) consumed by Reblaze's processing.

Zooming in

You can zoom in upon the various graphs, in order to examine a smaller window of time. The video below demonstrates this process.

"Top" Section

This section displays traffic statistics according to a variety of "top" metrics: the Top Applications, Top Countries, Top Signatures, etc.

In many of these displays, entries contain links. Clicking on them will open the traffic log, filtered to show the item you selected. For example, in the "Top Countries" view, clicking on a country name will open the traffic log to display the most recent requests originating from that country.

Section Characteristics

Applications

Shows all protected sites for the current Reblaze deployment. Applications marked in red have a blockage rate above 30%. The blockage rate is the ratio of requests blocked by the system to the number of total network requests.

Note that in this section, "Passed" and "Latency" entries aren't shown, and "Cloud", "Anon" and "Blockage" are added. Their meanings are:

Countries

Shows your traffic sorted by country. Each country's flag is shown by its name.

Sources

Shows traffic data according to IP address. The ASN (autonomous system number) for each IP is also shown.

Sessions

Shows the nature of user sessions. Sessions that pass Reblaze's bot mitigation challenge are identified as originating from humans, and are listed here according to the user's RBZ (Reblaze) cookie ID. In the screenshot below, note that the first line shows "-" for the ID. These are sessions that did not pass the challenge.

Targets

Shows the URLs in your site(s) that were accessed the most frequently.

Signatures

Shows the reasons that traffic was blocked. Unlike other displays, this section does not include hits, passed, blocked, etc.—the counter only shows the number of blocks per signature. Here you can see which types of attacks are most common in your environment. In the example screenshot below, the first entry is "-": this shows requests that were blocked, but not by Reblaze (i.e., they were blocked "by origin"—by the upstream server).

In the example screenshot below, the third and fourth entries include a "ref" value. These are Reblaze reference IDs, .

Referers

Shows the referers that were extracted from the request headers.

Extensions

Allows you to view the various file types that are being used by the application. ("None" shows the network requests that weren't counted as file extensions.)

Browsers

Shows all the user agents that initiated requests for the application(s).

Companies

Shows all of the ASNs (Autonomous System Numbers) from which requests were sent. The ASN can identify individual entities, or larger networks: for example, a telecom provider or a cloud provider.

Latency

Shows a list of all applications, with the corresponding latency for each.

This page provides the ability to review and analyze the most recent traffic, up to and including real time. At first glance, you'll see the origin country, IP address, HTTP message type, the targeted location, time stamp, and status code.

If a security event occurs, this page will allow you to quickly find its root cause.

On the top right of the page, you can select the range of requests displayed: from the most recent 200 events up to the most recent 2500. Choose the desired range (200, 500, 1000, 1500, 2000, or 2500) and then click on the checkmark to set the display.

Analyze Traffic Log

The main tool in this section is the Query box for filtering the display; this is quite similar to the one on the Dashboard. It allows you to filter the display and see only the data you wish to analyze. For a full explanation of how to use it, .

At the top right of the screen, you can choose the application you want to analyze. The drop-down menu allows you to search for and choose your desired application.

Next to the Query box, you'll see several buttons.

• The search icon is for applying the requested filters on the log. (Or, just hit "Enter" on the keyboard after typing your query.)

• The calendar button allows you to specify a certain date or period of time.

• The Search History button displays your recent searches, so you can re-run them without having to enter them completely from scratch.

Log Structure

Log entries are color-coded depending on their type.

• Passed requests: Black text on a white background.

• Blocked by Reblaze: Red text on a red background.

• Blocked by origin (i.e., the upstream server): Red text on a white background.

Clicking on any log entry will display its details:

This will reveal:

• The URL that was requested

• The user agent

• Optional additional information (not shown in the example above), depending on the request. Example: the referrer.

• A row of colored labels:

1. HTTP Request Method (GET / POST / PUT...)

2. HTTP Version

3. HTTP Response code, and which server sent the code: either the upstream server (noted as "Origin," as in the example above), or the Reblaze proxy.

To see full log details for an entry, click on the small magnifier on the right side of the log. This will show all the headers, cookies, and session details.

The example above shows a request that was answered with a challenge. It came from a known cloud provider, by curl, to www.example.com.

The above screenshot shows a log entry for a request that was blocked. Note that the Block reason is "Generic Attack [ref 22400000]". The "ref" number is a .

Examples for Log Filters

Example 1

How to search for one IP (censored in the screenshot below), only showing requests with a GET method during a specific time frame.

Example 2

Using this regex syntax:

status:[4]\d\d

Provides all status codes for 4xx.

Example 3

How to display all requests from a certain country, for "EXE" files, which produced error code 403.

Using the Log

The View Log page has many uses, and it will allow you to learn a lot about your traffic.

This page is a powerful tool for traffic control, and is especially useful when you are first starting to use Reblaze. By revealing the composition of your traffic, it can help you decide which requests you should begin blocking.