Revealing the composition and details of your traffic
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.
In the screenshots below, IP addresses are censored for privacy reasons.
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, click here.
The Query box allows you to filter and display specific requests and their details. To show the results graphically instead, you can copy the filter string and paste it into the Query box on the Dashboard.
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.
Export to CSV creates a text-based spreadsheet file.
The Help button opens a display with a quick-reference guide to Query box operator syntax.
The Clear button removes your current Query box entries.
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.
Challenge: Brown text on a yellow 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:
Green: Passed request
Red: Blocked request
Yellow: Explanatory
Blue: Informational
HTTP Request Method (GET / POST / PUT...)
HTTP Version
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.
Resource that was requested (JPG / PNG / HTML / JS, etc.)
Origin Country and Country Initials
Block reason: The reason, if any, that the request was denied. Standard reasons are listed in the Reblaze WAF Signatures list, while others are constructed dynamically (e.g., from a rate limit). A hyphen ("-", as in the example above) means that the request was not denied.
IP Classification: Whether the requestor is using an IP from a cloud provider, VPN, TOR, etc. In the example above, the requestor is using a cloud provider. Note that this does not indicate that the request was blocked for this reason. If the current Profile had included an ACL to block cloud users, then the Block reason would say "acl:cloud", and then this "Cloud" notification would appear after it for the IP Classification.
Origin IP address (censored in the example above)
Autonomous System Number (organization/ISP/etc.)
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 Reblaze Signature reference ID.
How to search for one IP (censored in the screenshot below), only showing requests with a GET method during a specific time frame.
Using this regex syntax:
status:[4]\d\d
Provides all status codes for 4xx.
How to display all requests from a certain country, for "EXE" files, which produced error code 403.
A full explanation of filter syntax, a listing of operators, and tips for quickly building queries is found here: Using the Reblaze Query Box.
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.
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.
Viewing current and historical traffic data
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.
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: Mobile SDK.
The discussion below is for sites and web applications.
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.
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 Environmental detection and browser verification.)
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.
If the challenge is passed, the browser's session is authenticated, and the browser receives cookies from Reblaze.
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.
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.
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
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.
When working with Reblaze's traffic statistics, the following relationships can be helpful.
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.
Passive challenges still include Environmental detection and browser verification, while adding three additional benefits:
They enable biometric behavioral verification: 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.
If possible, we recommend that customers use both active and passive challenges.
To learn more about passive challenges, go here: Enabling passive challenges.
An overview of traffic activity
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:
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, go here.
Queries run in the Dashboard will display the results graphically. To see the results as a full list of the requests and their details, you can copy the filter string and paste it into the Query box in the View Log.
Enables the user to select a pre-defined time frame, or a custom time period. See the video below:
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.
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
5xx - Server Error
For a detailed list of response codes, go here.
As in the Passed vs. Blocked display, the data is shown in different colors.
The number of network requests during a certain period of time.
The downstream bandwidth limitation per response. Left-axis units are "k" for kilobytes, and "M" for megabytes.
This displays the time (in milliseconds) consumed by Reblaze's processing.
You can zoom in upon the various graphs, in order to examine a smaller window of time. The video below demonstrates this process.
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.
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:
Shows your traffic sorted by country. Each country's flag is shown by its name.
On the screenshots below, IP addresses are censored for privacy reasons.
Shows traffic data according to IP address. The ASN (autonomous system number) for each IP is also shown.
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.
Shows the URLs in your site(s) that were accessed the most frequently.
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, explained here.
Shows the referers that were extracted from the request headers.
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.)
Shows all the user agents that initiated requests for the application(s).
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.
Shows a list of all applications, with the corresponding latency for each.
Name
Description
Hits
Total amount of requests
Passed
Requests that reached the upstream server
Blocked
Requests that were blocked by one of Reblaze’s correlation engines.
Humans
Requests that passed Reblaze's human vs. bot challenge process.
Bots
Requests with originators that were not (yet) verified as humans. For a full explanation, see Counting Bots.
Challenges
Requests that were served with bot detection challenges.
Latency
How much time it takes for a packet of data to get from one designated point to another. Displayed in milliseconds.
Dn
Amount of traffic in MB that originated from the upstream server towards the clients.
Up
Amount of traffic in MB that originated from the client towards the upstream server.
Name
Description
Cloud
Cloud Providers (GCP, AWS, etc.)
Anon
Anonymous Proxy Browsers
Blockage
Blockage rate
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
Requests that were challenged. The challenge process is an important part of Reblaze's traffic processing, as seen below.
