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.

Welcome!

Reblaze Technologies offers an all-in-one web security platform. It includes a next-gen Web Application Firewall (WAF), full-scope 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.

Reblaze is fully integrated with the top-tier public cloud providers (AWS, Azure, and GCP), and runs on the customer’s clouds of choice. The platform protects web applications, services and microservices, and API endpoints.

The platform is designed around a no-compromise approach to web security. All customers enjoy comprehensive protection, without having to purchase premium tiers or subscribe to additional services. Each customer receives a dedicated Virtual Private Cloud (VPC), eliminating multi-tenancy vulnerabilities. For maximum privacy, all traffic data is processed exclusively inside the customers’ clouds. Fine-grained ACLs enable precise traffic regulation. An intuitive web-based management console provides real-time traffic control. Multivariate threat detection, behavioral analysis, and machine learning ensure accurate, adaptive protection.

Product overview

Reblaze deploys as a reverse proxy, geolocated immediately in front of the protected network for minimal latency. As incoming traffic passes through Reblaze, attack traffic is blocked and denied access. The platform's overall architecture is as follows:

Cloud-based web security

• Reblaze deploys a dedicated VPC for each customer: an entire full-stack environment for each protected web platform, deployed immediately and automatically, and running across one or more cloud vendors (usually AWS, GCP and Microsoft Azure, although private clouds are supported as well).

• All incoming traffic is routed through the VPC 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.

• Attackers cannot reach, or even find, the targeted web platform.

• Bandwidth, compute, and other resources scale automatically as needed, limited only by the capacity of the global cloud.

• Remote management ensures minimal obligations (of time or expertise) from onsite staff.

Architecture

Authentication

Reblaze supports various methods of authentication such as Basic, Digest, and Kerberos. (Note that NTLM cannot work with reverse proxies, and thus Reblaze does not support NTLM sites/applications.)

Processing Within Your Perimeter

With Reblaze, you can process and scrub your traffic exclusively within your clouds—the clouds you already trust for your other business processes.

Top-tier Cloud Platforms

Reblaze is integrated with, and runs natively on, multiple cloud platforms, including the top-tiers (AWS, GCP, and Azure). It can run on any combination of clouds, on your choice of accounts (Reblaze’s, yours, or a combination of the two), and it deploys in minutes.

Reblaze deploys slightly differently on each platform, to take full advantage of its inherent capabilities.

GCP

Here is an example deployment of Reblaze on Google Cloud Platform.

Static content is served by the CDN. Incoming dynamic requests are directed through Cloud Load Balancing (capable of handling millions of requests per second) to ensure that the request processing time is minimal and availability will be fully utilized.

Requests are routed through the Auto Scaled instance group of "Reblazers" (security logic units) that will inspect the traffic, and according to their security policies, will bypass, deny, or allow the requests. Rule updates are sent to Cloud Armor, which blocks hostile traffic at the edges.

All incoming requests and their disposition are displayed in the console admin, and also streamed into Cloud Security Command Center (not shown above for lack of space).

All events and requests are recorded in BigQuery, accessible to users at all times via full historical logs. Cloud Machine Learning is used to analyze the data. Reblaze identifies new traffic and behavioral patterns (both legitimate and hostile), and updates all deployments appropriately. Thus, even as new web threats arise, Reblaze hardens itself against them.

All Security policies are stored in secure Cloud Storage and constantly synchronized.

AWS

Here is an example deployment on AWS. The overall traffic flow and processing is similar to that described above for GCP, although it leverages AWS's native capabilities.

Microsoft Azure

Here is an example deployment on Azure.

Welcome to Reblaze!

In this section you'll find a quick setup guide to get your planet (i.e., your entire Reblaze deployment, containing all its domains and web applications) up and running. After completing this section, it's advised to read through the rest of this Manual in order to understand the full capabilities of Reblaze.

The flowchart below describes the process we are about to begin:

Login

The initial login process is as follows:

1. Go to the link provided by Reblaze.

   https://example-console.reblaze.com/

2. Enter the initial login credentials (in lowercase), which are: Username = email

3. Password: Click on "Reset password" in order to set one.

4. A link will be sent to the provided email address. Click on that link, and on the page that follows, choose and enter a password for your user account.

5. You will be redirected to your console’s Login page. Please enter the email address specified above, and the password you just created. Then, next to the field which says “Multi-factor Authentication PIN,” select "Text me my code". During your initial setup request, you had provided a mobile phone number; that number will now receive an SMS message with an OTP (One Time Password), which you will enter here.

6. Click on the Login button.

After you login into the system, the first screen you will see is the Dashboard. This is the main screen for the Reblaze UI; once traffic statistics are available, they will be displayed here. (The Dashboard screen is described in-depth here.)

Before the Dashboard can show anything, your Reblaze planet must be set up. This is done in the Settings -> Planet Overview section.

Planet Overview

To add a new web application to Reblaze, you will duplicate the pre-defined default application.

Once you choose the right domain for your new application, you should be redirected automatically to the Settings -> Web Proxy page. If not, go there directly.

On the Web Proxy Page

If your new application is not already selected for editing, select it now.

In the Frontend section:

• Define the Domain Names (the aliases) for your application.

• Add the Trusted source IPs.

For many or all of the remaining fields on this page, the default values might be acceptable. You should take a few minutes to go through them to verify this.

When you are finished, save your changes. Then go to the Settings -> Backend Services page.

On the Backend Services Page

In the Host field, enter the IP address of the backend server(s).

Then verify that the default values on the rest of the page are acceptable.

When you are finished, save your changes. Then return to the Settings -> Planet Overview page, and publish your changes.

Note: the deployment will not occur until you click "Publish Changes." In general, whenever you work within the Reblaze interface, saving and publishing is always necessary. More information is here: Saving and Publishing Changes.

Now it's time to set up your SSL Certificates.

Setting up SSL Certificates

All connections between your server and clients must be encrypted. This requires an SSL Certificate to be installed on the web server. Once a certificate is installed, client browsers can connect via HTTPS instead of HTTP.

With Reblaze, you can either upload an existing certificate into Reblaze, or you can generate a new one for free through the Let's Encrypt service.

If you have an existing SSL Certificate

1. Add your certificate to Reblaze, as explained under SSL Management.

2. Copy the relevant details from the DNS section, and redirect your traffic through Reblaze. (DNS setup varies widely depending on your current configuration, and this Manual cannot discuss every permutation. Contact support if you need assistance with this.)

3. Go back to "Planet Overview" and publish your changes as explained previously.

4. Your initial configuration is complete. Welcome to Reblaze!

Generating a new SSL Certificate

1. Copy the relevant details from the DNS section, and redirect your traffic through Reblaze. (DNS setup varies widely depending on your current configuration, and this Manual cannot discuss every permutation. Contact support if you need assistance with this.)

2. Return to the Planet Overview page. Create a certificate using the "Generate Certificate" button in your application's listing there.

3. Publish your changes as explained previously.

4. Your initial configuration is complete. Welcome to Reblaze!

This is a description of some general UI components used throughout the system.

Common grid-based administration

Pages such as Tag Rules, Rate Limiting, Cloud Functions, and Backend Services are based on a common grid component that displays all the entries of the specified type in the system. For example, here is the grid in use on the Cloud Functions page.

The grid provides several administrative actions.

Add entry

To add an entry, select the "+" button at the top of the display.

Edit entry

To edit an entry, select the pencil button at the right side of the corresponding grid row.

Find entries

Above the grid, an input control accepts regular expressions for finding matching entries in the grid.

Sort entries

By default, all the grid columns are sortable. Just select the corresponding column header (the cursor view changes to a pointer when hovering).

Grid details page

This component appears after selecting a pencil button within the grid component. It consists of different fields depending on the displayed data type (cloud function, tag rule, etc.), but the common element is a fixed header. Consider the example of a tag rule details page.

The component header includes the following 3 blocks:

1. The entry's main info (on the left: the entry's name and id)

2. Entry selector (the dropdown on the right)

3. Actions block (a set of buttons on the right)

Main info

Each entry has a user-defined name, and an auto-generated id for internal use.

Entry selection

The entry selector dropdown allows you to change the entry currently being displayed and go directly to another without going back to the grid page. Also, since this selector is based on the autocomplete dropdown component (see below), it's possible to fast-search for a desired entry in the dropdown list using regular expressions.

Actions block

The actions block usually consists of at least 3 buttons:

1. Close the details page and go back to the grid page

2. Delete the entry usually after confirming the deletion via a modal confirmation window. Sometimes this button is unavailable, depending on the specific entry type.

3. Save the entry, which means it's possible to change the entry details and save those changes. Sometimes this button is unavailable due to validation issues, depending on the specific entry type.

As shown on fig. 2 above, the actions block may include additional buttons depending on the entry type.

Autocomplete dropdowns

Some pages (such as Web Proxy and individual grid details pages) as well as some general UI components are using an autocomplete dropdown component. It's a dropdown list with a capability of quickly searching for a desired entry using regular expressions. Consider the example of a tag rules details page:

Initially the component looks like an ordinary dropdown, but after it is selected, it splits into 2 parts: a text input and, below it, an entries list. By typing in the text input, it's possible to filter the entries list, leaving only those entries which names contain the typed letters; regular-expressions notation also works here.

When there are a large number of entries, the dropdown list becomes scrollable. If the selected entry is hidden at the bottom of the list, it automatically scrolls down to make this entry visible when the list is opened. When an entry in the list is selected, it gets highlighted in blue and the parent component catches this change; in the example move, the details page will change to display the selected entry.

Action Response

This component is used on the Rate Limiting and Tag Rules details pages. Initially, it's an ordinary dropdown labeled as "Action" with several options available:

1. 503 Service Unavailable

2. Challenge

3. Tag Only

4. Redirect

5. Request Header

6. Response

7. Ban (not available in Tag Rules)

503 Service Unavailable

The request will be blocked with a 503 error. This is the default action for Rate Limits, and is also available for Tag Rules.

Challenge

For a browser-based web application, a bot challenge will be issued to verify that the requestor is a human using a browser, and not a bot using a headless browser or emulator. If the challenge is failed, the request is blocked.

Tag Only

One or more tags are attached to the request, and processing continues (i.e., it is not blocked).

• For a Tag Rule, the tags are those specified in the Tag Rule.

• For a Rate Limit, the tag is the name of the Rate Limit.

This is the default action for Tag Rules.

Redirect

This action blocks the request with the specified error code, and redirects the requestor to a specified URL. For example, the URL might be a page that says, "Your activity appears suspicious, and your access has been restricted. Contact support if you think this decision was made in error."

When this action is selected, the component changes as follows:

The component now has a Redirect Status dropdown, with five options for error codes: 301, 302, 303, 307, and 308.

The focus is automatically placed on the Location input, which is a mandatory entry with a regular expression format ^https?://.+$. Until this contains a valid entry, the Save entry button at the top of the page will be disabled, and the control will be highlighted in red.

Request Header

This action does not block the request; it merely adds a header to it for receipt and evaluation by the customer's backend.

When this action is selected, the component changes as follows:

Both input controls use regular expressions (^[0-9a-zA-Z-_]+$), and are mandatory. Until they contain valid entries, the Save entry button at the top of the page will be disabled, and the invalid control(s) will be highlighted in red.

Response

This action blocks the request, and responds with a custom error code (0-999) and response.

When this action is selected, the component changes as follows:

The Status field (which should be a regular expression ^[1-5][0-9][0-9]$) and both Header fields (as regular expressions ^[0-9a-zA-Z-_]+$) are mandatory. Until they contain valid entries, the Save entry button at the top of the page will be disabled, and the invalid control(s) will be highlighted in red.

Ban

This action is only available for Rate Limits. When selected, the component changes as follows:

The Time Frame field is mandatory. Until it contains a valid value (an integer less than 86,400), the Save entry button at the top of the page will be disabled, and the control will be highlighted in red.

The Ban action dropdown is an instance of the Ban Action component, except that it does not contain a "Ban" option.

Common uses for Ban are described in the documentation for the Rate Limiting page.

Links to URLs

This component is used on Rate Limiting, Cloud Functions, and Backend Services details pages. It consists of 2 sections: Add New Link and a list of linked sites. (In Backend Services, Add New Link is unavailable.)

Overview

Please go through these checklists, and verify that their actions have been completed, both before and after your traffic is routed through Reblaze.

There are three checklists below: two for setup, and one for testing.

Prerequisite

Before going through the checklists below, you should already have performed the actions listed in Getting Started.

Configuring your environment

Setting up Reblaze

Testing your setup

When the following checklist has been completed, you'll be ready to go.

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:

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.

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.

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

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

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

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.

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

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:

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

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

• 5xx - Server Error

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

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 section defines the parameters with which Reblaze scrubs traffic.

The user interface is divided into these sections:

1. Dynamic Rules: Thresholds for banning sources of hostile traffic.

2. Quarantined: The "warehouse" of traffic sources that are currently banned. This contains blacklists and whitelists, allowing you to manually control quarantines when necessary.

3. Profiles: Creation of security rule sets for assignment to specific resources, locations, and applications.

4. Args Analysis: Settings for allowing requests based on their arguments, in a procedure that occurs before normal WAF inspection and filtering.

5. Session Profiling: Settings for assigning tags to incoming requests.

6. Rate Limiting: Settings for rate limits and the actions that will be performed when a rate limit is violated.

7. Cloud Functions: Custom code that can be executed at specified times during traffic processing.

The Security section is where you define the "under the hood" settings for Reblaze. When defining or editing the information in this section, careful consideration is necessary.

Before investigating each section of the interface, it's recommended to read the "Security Concepts" discussion on the next page of this Manual.

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, click here.

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

• 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

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.

4. Resource that was requested (JPG / PNG / HTML / JS, etc.)

5. Origin Country and Country Initials

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

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

8. Origin IP address (censored in the example above)

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

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.

Reblaze evaluates incoming traffic in a multi-stage filtering process. An HTTP/S request which passes all security tests will be forwarded to the backend.

This decision-making is done in several stages.

Overview

The quarantined section will show requestors that have been banned for violation of the Dynamic Rules and Rate Limiting rules, requestors that have been blacklisted, and requestors that have been whitelisted. You can add and remove requestors, and transfer them among the various lists.

Main Display

There are four lists of requestors in this section:

1. Banlist

2. Simulation Banlist

3. Blacklist

4. Whitelist

Each is described in more detail below.

For each entry, it's possible to see the following: IP address, origin country, AS number, the violation that was triggered, "CNT/Limit" (the number of violations compared to the allowable limit), when the ban began, and when the ban will expire.

Banlist

All requests from these requestors are currently being rejected. These requestors violated a rule that was set to “Ban” mode.

Simulation Banlist

These requestors are NOT having all their requests rejected. These requestors violated a rule that was set to “Simulated Ban” mode. Simulated Bans are used mainly for testing new rules and seeing how they function, before converting those rules to Ban mode.

Blacklist

All requests from these requestors are currently being rejected. These requestors were placed here by a Reblaze admin.

Whitelist

These requestors are exempted from the Dynamic Rules and Rate Limiting Rules. For example, even if they violate a rate limit, they will not be banned.

Managing Requestors on the Lists

Adding an Entry

Banlist and Simulation Banlist

Requestors are added to the Banlist and Simulation Banlist automatically when they violate a Dynamic Rule or Rate Limiting Rule.

Blacklist and Whitelist

You can add a requestor manually to the Whitelist or Blacklist using the "Add New Entry" option in the section menu. This is demonstrated in the following video:

The fields are:

Transferring an Entry

Requestors can be transferred among the various lists with this procedure:

1. Select the requestor(s) by checking the box at the left of each entry.

2. Open the section menu.

3. Choose the desired "Move to" command (e.g., "Move to Whitelist").

Removing an Entry

Automatic Removal

Requestors on the Banlist, Simulation Banlist, or Blacklist will be automatically removed when their expiration time is reached. (The Whitelist has no expiration time.)

Manual Removal

Requestors can be manually removed from the list they are currently on:

1. Select the requestor(s) by checking the box at the left of each entry.

3. Choose "Delete".

Overview

The Dynamic Rules section defines security rulesets that evaluate various criteria over time. When requestors commit activities that exceed defined thresholds, they can be banned, or merely reported on within the interface.

Note that Dynamic Rules do not block requests; they ban the sources of requests. Individual incoming requests are blocked for reasons defined elsewhere, e.g., in ACL Policies.

When requests are blocked, or display other hostile characteristics, Dynamic Rules are used to monitor their sources. If the sources continue their hostile activities, they can be banned. A ban means that all subsequent requests from that source will be blocked for a configured length of time.

The interface displays the Dynamic Rules that are currently defined. At the top are the default rules supplied by Reblaze, marked with the Reblaze icon.

Dynamic Rules Administration

To edit a rule, click on its name, and its parameters will appear below.

Dynamic Rules section menu

It provides these abilities:

The interface also provides a search box, which can be used to find a rule according to a string within its name.

Creating Dynamic Rules

To create a Dynamic Rule, click on "Add new rule" in the Dynamic Rules section menu and provide the Rule Name.

Dynamic Rule settings

Each Dynamic Rule contains the following parameters:

Matching Conditions for Dynamic Rules

The monitor list includes many useful arguments for identifying relevant traffic.

The video below sums it all up:

Defining Block Reasons

The Block Reason field allows you to construct a Dynamic Rule that will be triggered when requests are blocked for specific reasons. When this is included in a Rule, Reblaze will compare its value to the reasons that a request was blocked.

The comparison is based on a "contains" substring search, and is case-insensitive. Therefore, when a request is blocked for Over-capacity, Block Reason values of capacity, over-capacity, and Over-capacity will all match.

There can be multiple Block Reasons OR'd together, e.g.: autoban|over-capacity.

There are several ways to obtain values for constructing Block Reasons. The first is the list of standard Reblaze WAF signatures (example: Autoban/etc.). Other possible values are custom, created dynamically by Reblaze as the result of user configuration. Example: Rate limit 2/1s .

In both cases, recent values can be obtained from individual events in the View Log, or from the Signatures tab on the Dashboard page.

How to Test Dynamic Rules

After creating or modifying Dynamic Rules, it is recommended that you test them to ensure that they are behaving as expected.

You can safely test Dynamic Rules against actual traffic data, without actually banning any traffic sources. This is done by running the rules in Simulated Ban mode.

There are two ways to do this: testing all rules globally (most useful when setting up a new planet), or testing individual rules (useful in daily operation).

Testing all rules globally

Select Activate global simulation mode from the section menu, which will change all Dynamic Rules that were set to Ban to Simulated Ban.

This means that requestors who violate Dynamic Rules will not be banned; instead, they will appear within the Simulation Ban List in the Quarantined section. You can observe the requestors who appear there, and evaluate if the Dynamic Rules are identifying the requestors you expected.

Testing individual rules

To test individual rules, set each one to Simulated Ban mode. Save and Publish your changes. Then from the section menu, choose Test All Rules.

This will evaluate the current set of Dynamic Rules against the most recent traffic data. Example: a rule with a Period of five minutes will be evaluated against the requests that were received in the last five minutes.

You can compare each rule's performance with what you expected. Once you are satisfied with a rule's performance, you can make it active by changing its mode to Ban.

Note that you can accomplish a similar result by observing the Simulated Ban list in the Quarantined section. However, testing is faster using Test All Rules: you get the results immediately, instead of having to wait for a full Period to see how a Rule performed.

Examples of Dynamic Rules

Rate-limiting access to a specific URL

In the example below, this Dynamic Rule limits the number of requests that are sent to /login from a specific IP.

Limiting could also be done globally for all IPs by changing the Target to "Planet."

Using cookies to ban an attacker who is switching IPs

By using a cookie threshold, it is possible to eliminate Denial Of Service attacks originating from the same session, even if the attacker is changing IP addresses. In the screenshot below, requests are counted toward the threshold if they have the same value for the "rbzid" cookie. Requests are not counted toward the threshold if they were Bypassed by an ACL, or if the requestor has already been banned.

Rate-limiting specific HTTP requests

This rule blocks HTTP GET requests from a specific IP for 10 hours, under these conditions:

• The IP has submitted more than 3600 GET requests in the previous three minutes.

• The requests were not for a static file (.png , .jpg, .ico, .gif).

• The requests were not already blocked

• The requests were not from IP 1.2.3.4.

Within the Security section, this tab provides an interface for administering Profiles.

Existing Profiles are shown on the left.

To create a profile, click the Create New button toward the top of the screen, and then choose Profile. Or select an existing one and choose Duplicate, then edit the newly-created copy.

To edit a profile, select it from the list on the left. Its contents will appear in the middle part of the screen.

To add a new Policy, select the desired Policy from the Link More Policies list on the right, and click the Add button. To remove an existing Policy from the Profile, click on the X to the right of its name.

Most Profile administration will not be possible until the appropriate Policies have been created. Similarly, complete Policy administration will not be possible until there are Rules to add to them.

This section allows you to administer WAF/IPS Policies, which define the sets of defined behaviors for the WAF. The Policies are assigned to paths/URLs in the .

Existing WAF/IPS Policies are listed on the left side; selecting one will display its contents on the right for editing. A default Policy must always exist. Additional Policies for specific situations can be defined if needed.

When viewing or editing a WAF/IPS Policy, the Active Modules section allows you to enable/disable some of the modules. The four on the left are always active and cannot be turned off. (However, an ACL Policy that resolves to an action of Bypass will exempt a requestor from them.) These four modules are:

The next three modules are optional, but are recommended in most situations:

As mentioned earlier in , Reblaze's decision-making can vary depending on the context. In a typical Reblaze deployment, much of the traffic evaluation is done using Profiles. When Reblaze receives a request for web resources, it first determines the Profile that is in effect for the resource that was requested.

Reblaze's Profiles are hierarchical structures, so that you can set up your security framework in a modular fashion. Rules and collections of rules can be set up once, and re-used throughout your planet as needed.

The hierarchy has several levels:

• Profile

• Policy

• Rule

• Condition and Operation

A Profile contains one or more Policies. A Policy contains one or more Rules. A Rule is a combination of a condition and an operation. Let's illustrate these with examples, from the bottom of the hierarchy upward.

Example conditions:

• Is the request coming from a specific country? Or ASN?

• Is the request coming from a specific IP address?

• Is the request coming from a proxy? Or a VPN? Or a Tor network?

• Is the request for a specific URI?

• Is the request originating from an allowed (or a disallowed) HTTP referer?

• Does the request contain (or not contain) specific arguments?

• Is the request using (or not using) a specific method or protocol?

• Does the request contain (or not contain) a query string in a specific format?

• Does the requesting client have (or not have) specific cookies, or a specific cookie structure?

Possible operations:

• Deny

• Allow

• Bypass (similar to "Allow", but the request will not be subject to further evaluation or filtering by other rules)

Example Rules:

1. If the requestor IP is within 131.253.24.0/22 [a known range of Bing crawlers], Allow.

2. If the requestor IP is within 157.55.39.0/24 [a known range of Bing crawlers], Allow.

3. If the requestor IP is within 1.10.16.0/20 [a range within the Spamhaus DROP list], Deny.

4. If the requestor IP is within 1.32.128.0/18 [a range within the Spamhaus DROP list], Deny.

5. If the requestor is a bot, Deny.

6. If the requestor is using a proxy anonymizer, Deny.

7. If the requestor's Company is [our company], Bypass.

8. If the requestor submitted an HTTP/S request, Deny.

Example Policies:

• Allow Bing Crawlers [contains example Rules 1-2 above]

• Deny requestors on Spamhaus DROP list [contains example Rules 3-4]

• Deny bots [contains example Rule 5]

• Deny proxy users [contains example Rule 6]

• Allow users from our company [contains example rule 7]

• Deny all requests [contains example rule 8]

Example Profiles:

• Default:

  • Allow Bing Crawlers

  • Deny requestors on Spamhaus DROP list

  • Deny bots

  • Deny proxy users

• Private area of our website, for internal use only:

  • Allow users from our company

  • Deny all requests**

** "Allow" Policies are evaluated before "Deny" Policies. When a match is found, no further evaluation is performed. In this example, company users will be Allowed, which exempts them from the Policy which Denies all requests.

Custom signatures are custom matching conditions that you can use in Rules and Policies to evaluate client requests.

These allow the administrator to "catch" traffic based on any parameter in the request or the response. They can be used in a number of situations. Some examples:

1. "Virtual patching": Identifying an incoming exploit attempt for a newly-discovered vulnerability in the upstream network.

2. Identifying logged-in admin users, so that their requests can be Bypassed.

3. Identifying specific patterns of traffic that are suspected to be malicious, so they can be blocked.

4. Identifying specific types of requests (e.g., XMLHttpRequest), so they can be blocked from specific sections of a website.

Custom Signatures give you tremendous power and flexibility for evaluating your traffic. They are composed of one or more matching conditions, which can be combined using Boolean AND/OR operators.

Each matching condition combines the entries in Either one of the following fields and Is matching with.

Possible entries for Either one of the following fields:

Entries in Is matching with

This text box accepts strings or PCRE (Perl Compatible Regular Expressions).

Creating custom signatures

When you first create a Signature, one condition appears for editing. If you wish to create more than one, click on the Append Condition button at the bottom. This will add another condition for editing.

You can continue for as many conditions as you want. The conditions will be evaluated according to the Boolean operator specified by the Condition Type selector.

The ACL Policies section allows you to define Policies and Rules by which Reblaze will scrub your incoming traffic. Once the Policies have been defined, they are assigned to specific resources (e.g., a section of your website) in the Web Proxy section.

In the discussion below, "ACL" and "ACL Policy" refer to the same thing: the Policies that can be administered in this section.

Existing ACLs are listed on the left. Selecting one will display it in the middle of the screen for editing.

To create a new ACL, click the "Create New" button toward the top of the screen, then "ACL Policy." Or, duplicate an existing ACL and then edit the newly-created copy.

Each ACL contains one or more Rules. These are listed in the middle of the screen. To create a new Rule and add it to the current ACL, use the settings on the right part of the screen. (See below for more on this.) When you are finished with the Rule setup, click on the Add button. The Rule will be added to the Policy that you are currently defining or editing.

To remove a Rule from a Policy, click on the "X" to the right of its name.

Creating a New Rule

Each of these fields is explained further below.

Operation

The Operation field has three possible values:

• Bypass: the requestor will be granted access to the requested resource, without further evaluation or filtering of the request. However, although a Bypassed request will not be subject to further filtering, it will still show up in the logs (as “reason:bypassed”).

• Allow: the requestor will not be presented with a challenge, but will still be evaluated by the WAF.

• Deny: the requestor will not be allowed to access to the requested resource

When constructing an ACL Policy from multiple Rules, the Rules are arranged in the hierarchy shown above (Bypass, then Allow, then Deny). Rules are evaluated in order from top to bottom. When a Rule resolves to an action, that action is implemented, and further evaluation ceases.

Match

There are five available options for Match:

• Tag

• Company

• Country

• IP Address

• Custom Signature

The first four of these are common matching conditions that are always available. The fifth choice allows you to select custom matching conditions that you constructed by using the Custom Signature feature (however, note that Custom Signatures have been deprecated. Session Profiling should be used instead).

Match Argument

This is the third, unlabeled field in the New Rule dialog. The correct entry will depend on the option that was selected for Match.

Tag

If you selected Tag, enter one or more tags as the Match Argument.

Company or Country

If you selected either of these, enter the first few characters of the company name or country, and then choose the full name from the list that appears. (If the text box does not populate itself appropriately as you type the first few characters, check your spelling.)

IP Address

Enter the specific IP or range of IPs (e.g., 178.184.0.0/16).

Custom Signature

Enter the first few characters of a Signature that you created previously in the Custom Signature tab, and then choose the one you want from the list that appears. (If the text box does not populate itself with matching Signatures, check your spelling.)

Special ACLs

By adding the following characters as a suffix to the ACL's name, the ACL will behave as follows:

For an example of using the OC suffix, see Bypassing Rate Limits for Loadtesting.

For an example of using XDeny, see Quickly Blocking an Attacker.

In a typical deployment, Reblaze performs much of its traffic evaluation according to security Profiles. There are four tabs within the interface:

1. Profiles

2. ACL Policies

3. WAF/IPS Policies

4. Custom Signature

Before discussing each tab, it will be useful to discuss Profile Concepts.

A Cloud Function (CF) allow you to extend Reblaze's tools and functionality. Each CF consists of Lua code that can be run at different points in Reblaze's traffic processing.

Cloud Functions are defined here. They are assigned to URLs within the web application in the Security Profiles section of the Web Proxy page.

The top right of the screen provides a pulldown for selecting a CF for editing, an Add button to create a new CF, and a Save button for saving edits that were made on the currently-displayed CF.

The CF itself consists of a name (for display within the Reblaze interface), an automatically-generated ID, the Code itself, and a specified Phase. The Phases pulldown allows you to specify when the CF will execute:

• Request Pre Reblaze: Execute immediately when Reblaze receives an incoming request, before any other processing occurs.

• Request Post Reblaze: Execute after Reblaze has finished processing the request, and before it accesses the backend server.

• Response Pre Reblaze: Execute when Reblaze receives the response from the backend.

• Response Post Reblaze: Execute as the last action before Reblaze sends the response to the client.

Cloud Functions are a very powerful tool. If you need assistance with this feature, please feel free to contact support.

Overview

Early in the traffic evaluation process (immediately after evaluation of Quarantines and Dynamic Rules), Reblaze can assign one or more Tags to an incoming request. Subsequently, the Tags can be used to make decisions about how the request is processed. After processing, a request's Tags remain associated with it, and they are available for display in the View Log.

This page allows you to administer Tag Rules, which are combinations of Tags and the criteria for assigning them to requests.

Each Tag Rule consists of:

• Match conditions: A list of possible characteristics that a request can match (e.g., a list of IP addresses that it might originate from), plus the logical operator to use when evaluating the match.

• One or more Tags to assign when a match occurs.

For each request, Reblaze will evaluate all active Profiles. A single request will receive Tags from all Profiles which match it.

Two Types of Tag Rules

Tag Rules can be either Internet-sourced or self-managed.

• Internet-sourced Rules are based upon online lists (e.g., Spamhaus DROP lists). These lists are not editable within the interface, because they are obtained automatically; Reblaze updates them every 24 hours. You can also trigger an immediate update via the "update now" button.

• Self-managed Rules are created manually. These lists are fully editable within the interface.

Administration

At the top of the page, the pulldown list specifies the Rule currently being displayed for editing. Next to it are four buttons: Fork (to create a copy of the profile being displayed), Download, Add, and Save.

Adding a Tag Rule

To add a Tag Rule, either:

The new Rule will be displayed for editing:

Enter values into the following fields:

• Name. A description that will be displayed within the Reblaze interface.

• Tags. One or more Tags (separated by spaces) that will be assigned to requests if the match conditions are fulfilled. Example: internal team-devops

• Active. By default, this Profile will be applied to incoming requests. To prevent this, unselect the checkbox.

• Notes: An optional field for including information about this Profile.

Next, specify the match conditions, as discussed below.

Specifying Match Conditions

Match conditions consist of two parts:

• A list of one or more criteria to match. The list will be entered differently for the two types of Tag Rules.

• The logical condition to apply (either OR or AND), specified in the Entries Relation pulldown

Match Criteria for an Internet-sourced Profile

For a Profile based on an online source, simply enter its URL into the Source field. For example, to create a list based on the Spamhaus ASN DROP list, you would enter https://www.spamhaus.org/drop/asndrop.txt, and then select the "update now" button. Reblaze will then populate the list automatically.

If the list contains more than category--which is unlikely for an Internet-sourced Profile, but not impossible--also choose the appropriate value for Entries Relation, as discussed below.

At this point, the new Profile should be complete. Before exiting the page, be sure to save your work.

Match Criteria for a Self-Managed Profile

To add a match criterion, select the "+" button at the top of the criteria list. The following dialog will appear.

For most of the categories, the dialog will appear as it is above. Multiple entries can be made at once, with each entry on a separate line. Each line contains the value, plus a pound sign (#) followed by an annotation (a label for display within the Reblaze interface). Example:

For some categories, one entry can be made at a time, with each entry requiring multiple lines. Annotations are not preceded by a pound sign.

Here are some sample entries for the various categories. Notice that the logical operators are available.

Once created, these entries cannot be edited. If one needs to be modified, remove it and re-create it.

The Entries Relation Field

This specifies the logical operation used when evaluating a request against the match criteria.

When all the match criteria are in the same category, the operation is OR. For a request x and list of criteria a, b, c , then the evaluation will be (x==a) OR (x==b) OR (x==c) For example, if the match criteria are all IP addresses, then a match will occur if the request matches any of the IPs in the list.

When there are two or more categories, the default operation is still OR (in which case, a match will occur if the request matches any of the criteria in the list). However, when there are multiple categories, you can select AND instead. In this case, OR will still apply within each category, while AND will apply between the categories. Thus, for one list a, b, c and a second list i, j, k , the evaluation will be ((x==a) OR (x==b) OR (x==c)) AND ((x==i) OR (x==j) OR (x==k)). For example, if the match criteria are IP addresses and headers, then a match will occur if the request matches any of the IPs and any of the headers, but it will not occur if it matches an IP but none of the headers.

The Arguments Analysis feature has two primary functions:

1. Examining incoming requests for specific whitelisted characters in specific arguments (i.e., parameters in the URL query string or within the request body). Alphanumeric characters are allowed by default; all others must be allowed via a whitelist. When all characters in all arguments are found in the respective whitelists, the request is allowed, and no further inspection or filtering by the WAF is performed. If one or more characters are encountered that are not whitelisted, the request is either forwarded to the WAF for further inspection (when Inspect Unknown mode is enabled), or the request is denied (when Strict Whitelist mode is enabled).

2. Automatically updating the whitelists: As non-whitelisted characters are encountered, they can be added to the argument whitelists, depending on the Adaptive Mode selected.

The first function is often used in complicated sites; it offers a positive-security approach for analyzing traffic. Arg Analysis makes it easy to whitelist values that should be allowed in various request parameters. Another possible use is to bypass specific parameters that are too long for the WAF to efficiently process, or where WAF inspection is not relevant.

The second function (i.e., automatically updating whitelists) is less applicable for most deployments, and in most situations, is not encouraged. If Args Analysis is used incorrectly, large whitelists can be inadvertently built that will match most or all incoming requests. Thus, most or all incoming requests will bypass the WAF's traffic inspection and be sent directly upstream. In effect, this will disable Reblaze's traffic scrubbing. Therefore, we discourage the use of this function unless you are sure you need it, and you fully understand how it works.

For both functions, an argument list must be built.

Building an Argument List

Initially, this section will look like this:

Note the pulldown list on the right, which specifies the domain that you are currently administering.

Automatic Argument Learning

Each time the system performs an analysis, arguments that were not previously known will be learned and added to the argument list, automatically (even in Supervised mode). The new character whitelists will consist of those characters that were encountered with each argument.

Manual Argument Addition

Upload arguments file: The system allows you to upload a HAR file (that can be recorded using the browser’s dev tool). From the HAR file, the system will learn all the arguments and their values.

Creating an argument manually: You can also create individual arguments by selecting "New Argument," after which this dialog will appear:

When an argument is encountered in a query string or request body, its Argument Name is sought within the Args list for the relevant domain. If not found, it is added to the list, as noted previously.

If found, its value is analyzed. If each character within it is found in its corresponding Argument Characters, then this argument is passed.

If every argument in a query string or request body is passed, then the entire request is passed. It is sent to the origin (the upstream server), without being subjected to further inspection or filtering by Reblaze.

if the request is not passed, further processing occurs. See Handling Requests with Unmatched Characters, below.

Argument List Administration

In addition to the "New Argument" and "Upload Arguments File" options, the pulldown menu also offers additional capabilities.

Download as JSON - When this option is selected, the system will start a browser download of a JSON file that contains all the arguments and their values.

Delete App Args - Removes all the arguments in the current domain.

Analyze Now - Manually triggers the analysis process (described below), starting from the previous day.

Learning Resources - Displays the list of all ACL Policies defined in your planet, except for the default ones supplied by Reblaze. Example:

By default, Args Analysis learns from every request. The Learning Resources feature allows you to filter this, so that it only learns from specific requests.

When you select an ACL Policy from this list, Args Analysis will be limited to the requests which match that Policy. (If the ACL Policy happens to be empty, then the most recent 100,000 requests will be analyzed, or the most recent 24 hours' worth of data, whichever limit is reached first.)

If the selected ACL Policy has an Operation of Allow, then Args Analysis will analyze all the requests that were not blocked by the WAF or other ACL Policies. If the Policy is instead set to Bypass, then Args Analysis will also learn from blocked requests. (This can be useful when in Report-Only mode).

Show Regex/Characters - Toggle the display of all values on this page in regex, and then back into characters. Note when showing regex, alphanumeric characters are also explicitly included in the whitelist. In character mode, the Reblaze interface does not display these; the user should understand that all alphanumerics are whitelisted by default.

Refresh and Discard Changes - This allows you to discard all the changes you made to the arguments table.

Save Changes - When making any changes to the arguments table, you must save them afterward. This includes any modified or accepted conflicts in the system (more on these below).

Once Argument Lists Are Built

In daily operation, Reblaze analyzes arguments in incoming requests. When they match the character whitelists, the requests are allowed, as described above.

Additionally, Reblaze goes through the traffic logs, analyzing and mapping all arguments received since the last analysis. This occurs every night around 3am UTC.

The system creates a list of argument characters that were encountered in requests, but were not in the whitelists.

Then in this Args Analysis section of the interface, Reblaze displays the current whitelists as follows:

• Unchanged Arguments: This is at the bottom of the screen. It shows all the arguments for which Reblaze did not encounter any new (i.e., non-whitelisted) characters.

• Conflicted Arguments: This shows the results of the most recent analysis: all the arguments for which Reblaze encountered characters that were not in the whitelists.

Here you have the opportunity to update the whitelists, accepting some or all of the proposed updates listed in the Conflicted Arguments section.

The manner in which these updates are accepted or rejected will depend on the New Args Adaptive Mode.

New Args Adaptive Mode

There are four possible modes: Automatic, Supervised, Locked, and Preview.

Automatic

The system will discover and deploy new args without any human intervention. Everything occurs automatically.

Supervised

The system will discover new args, but it will not deploy them. Instead, it will present them as Conflicted Arguments, and await approval or rejection by a human admin.

Locked

The system will not discover any new args. All configuration changes must be done manually.

Preview

The system will discover new args, but this is for informative purposes only. Traffic processing is not affected.

Handling Requests with Unmatched Characters

For each of the first 3 operation modes (Automatic, Supervised, and Locked), another setting is available:

This defines Reblaze's behavior when non-whitelisted characters are encountered for known args.

Inspect Unknown

A request that contains an argument that contains one or more non-whitelisted characters will be forwarded to the WAF for inspection and potential filtering.

Strict Whitelist

A request that contains an argument that contains one or more non-whitelisted characters will be blocked.

After the request is processed, this argument is added to the list of Conflicted Arguments.

Conflicted Arguments

When new (non-whitelisted) characters are encountered, the arguments in which they were found are listed in the interface as Conflicted Arguments. Reblaze suggests updates (the New Values) for each argument's whitelist, and awaits the user's decisions.

Every time an analysis is performed, the previous list of Conflicted Arguments is discarded, and a new one generated. Thus, the interface displays only the Conflicted Arguments that were found in the most recent analysis.

Each Conflicted Argument contains a set of New Values. These are updates that Reblaze is proposing to make. There are three available actions:

• Deleting

• Modifying

• Accepting

Deleting - selecting the Trash icon will remove the Conflicted Argument from the list. This can produce unintended consequences: see warning below.

Modifying - You can edit the New Values. For the character field, only valid regex will be accepted.

Accepting - Clicking on the green Accept Conflicts button will accept all the Conflicted Arguments, updating the args list to the New Values.

Unchanged Arguments

At the bottom of the screen is a list of Unchanged Arguments.

This shows the arguments for which Reblaze has not encountered any non-whitelisted characters.

You can edit these arguments if desired, or even delete them (by clicking on the trash icon to the right—but see the warning above about the potential consequences of deleting arguments).

Rate limiting defines the actions that will occur in response to events in the incoming traffic. This page is used to define Rate Limit Rules.

Rate Limit Rule Administration

Existing rules are listed on this page. To add a new rule, select the "New Rule" button on the upper right of the window. To edit or delete a rule, select the "edit" button at the end of its listing. The following window will appear.

Defining a Rate Limit Rule

Each Rate Limit Rule consists of the following types of parameters:

Each is discussed further below.

Meta Parameters

Rate Limit

Event Criteria

Event criteria have two components:

• Key(s). These define the events that are being counted. See "Composing Keys," below.

• Include/exclude filters constrain the requests whose Keys are being counted. In other words, they define the segment of the incoming traffic stream that is being evaluated for possible events. See "Including/Excluding Requests," below.

Composing Keys

A Key consists of a field and a value. Within a Rate Limit Rule, they play a role like this:

"More than <LIMIT> requests with the same <KEY-VALUE> <KEY-FIELD> sent to <ASSIGNED-LOCATION> within <TIME-PERIOD> will cause <ACTION>."

Key Fields

A Key can be built upon any one of these four fields:

Multiple Keys

Multiple Keys can be defined within the same Rule. To create a new Key and open it for editing, select the "+" button next to the Key label.

If multiple Keys are defined, they are evaluated by combining them together with a logical AND. In other words, the cumulative count toward the Limit will be incremented whenever a request is seen that matches all of the Keys simultaneously. Different combinations of Keys will have separate Limit counts maintained for them.

The "Pair with" option: Changing the meaning of the Rate Limit

Below the list of Key(s), there is a checkbox labeled "Pair with." If this is checked, then a different type of Key can be added below it.

Adding a Paired Key changes the evaluation process. A Paired Key is not logically combined with the preceding Key; it is always evaluated separately.

Also, adding a Paired Key changes the meaning of the Rate Limit.

• If a Paired Key is not defined, an internal counter is maintained for each Key value, and incremented each time that value is encountered in a request.

• If a Paired Key is defined, an internal counter is maintained for each Key Value, and incremented each time a new, previously unobserved Paired Key value is encountered in a request.

Therefore, if a Paired Key is defined, the Rate Limit constrains the number of allowable Paired Key values for any given Key value.

So, the evaluation becomes something like this:

"More than <LIMIT> <PAIRED-KEY-VALUE> <PAIRED-KEY-FIELD>s per any one <KEY-VALUE><KEY-FIELD> sent to <ASSIGNED-LOCATION> within <TIME-PERIOD> will cause <ACTION>."

Note that the number of Key values is not being limited here. The limit is on the number of Paired Key values that each Key value is allowed.

Including/Excluding Requests

The Include and Exclude filters allow you to constrain the requests against which this Rate Limit Rule will be evaluated.

By default, an active Rate Limit Rule will be enforced upon all incoming requests. Specifying an Include and/or an Exclude filter will set limits to this enforcement.

The Include filter will limit enforcement to requests matching its parameters. All other requests in the traffic stream will not have this Rate Limit Rule enforced upon them.

The Exclude filter will exempt requests from enforcement that otherwise would have been evaluated. These requests, which otherwise match the Include filter's parameters, will not have the Rate Limit Rule applied to them.

Action

When a Rate Limit is triggered, the specified Action will occur.

There are various Actions available for selection here: 503 Service Unavailable, Challenge, Tag Only, and more. They are described in the documentation for the Action Response dropdown.

The Ban action is a unique option for Rate Limiting, and is described in detail below.

The Ban action

Most of the available Actions will not fully exclude an attacker that continues pressing the attack.

The Ban action can be used to block (or take some other Action in response to) a Rate Limit violator for an extended period of time.

Note that when setting up a Ban, the most common choices for its Action are to deny the violator's requests (via 503 Service Unavailable, Response, or Redirect). However, you can also choose Tag Only (to observe the violator's actions during the ban period), Challenge (to verify that the violating activity is not being done by bots), or Request Header (to mark the requests for further scrutiny by the backend).

Assigning Rate Limit Rules to URLs

In the main window, each Rule listing has a number for Linked URLs.

The number represents the number of URLs to which this Rule is currently assigned. To assign a Rule to a URL, click on this number. The following window will appear.

On the left, a summary of this Rule is shown.

On the right, clicking on Add New Link will show a list of web applications that are currently defined in the Planet Overview.

After selecting a web application, a pulldown list will appear. It will contain the locations defined for this web application within the Security Profiles section of the Web Proxy page. To assign the current Rule to this location:

• Select a location from the pulldown

• Select the "+" button to add it to the list of assignments.

• Select the Save button at the upper right of the window.

More than one assignment can be performed at once. After adding the first assignment to the list, simply add additional ones as needed. When the list is complete, select the Save button.

This section allows you to customize the error messages that are displayed to users. There are separate tabs for the most common types of errors, with the HTTP status code for each one. The defaults can be used, or you can customize the content and/or contact details as needed.

A straightforward use of this feature is to enter text into the fields. More advanced usage (for example, iframes) is also possible.

Select the web application to edit by using the pulldown on the upper right. When you have completed your edits, select the Save Changes button on the upper right, and then .

The Settings section has an extensive number of configuration values for Reblaze. These tend to be parameters that once set up, usually will not change during your use of Reblaze.

There are five sections in this part of the interface.

contains parameters for the overall architecture of Reblaze and its interaction with the downstream clients and the upstream network. It includes settings for proxy behavior, load balancing, failover, and more. It is also where you assign Security Profiles to specific areas of your website.

is where SSL Certificates are uploaded and managed.

is where DNS records are configured.

shows you information relevant to your entire planet: the active domains and applications, what notifications are issued in response to events, and the ability to Publish changes that were made elsewhere in the interface.

is where your user account settings are managed.

DNS Management is an optional capability. Your DNS management does not need to be done within Reblaze, but it can be.

Reblaze provide a full DNS service, based on. Reblaze also supports DNS on other cloud platforms, but they are not yet supported natively within the Reblaze interface. If you need this capability within your deployment, .

Motivation

Many site administrators use their domain registrars as their DNS providers, but this is often a poor choice. In general, domain registrars do not place a high priority on DNS security (since DNS management is not a primary part of their business model), and attackers frequently target their DNS servers. A successful DNS poisoning attack can result in your site getting hijacked.

Managing your DNS through a secure platform like Reblaze is a better choice. This ensures your full stack is protected—even the DNS layer.

A full explanation of DNS setup is beyond the scope of this Manual. The discussion below is an overview of Reblaze's capabilities and interface. Please if you need assistance for your particular situation.

Scope

You can manage millions of DNS zones and records using the Reblaze interface.

The DNS Management feature of Reblaze is for both external and internal DNS administration. Internally, Reblaze maintains a special name for every planet (planetname.d1.rbzdns.com), and every domain protected by Reblaze is mapped to an entry in this domain. This system can also be used for domains accessible externally.

Administration

To display existing records, a "search" feature is provided at the upper left.

This will control the DNS entries being displayed, by filtering them according to the search value and selected record type.

To add a new DNS entry, click on the "New" button. The following dialog is displayed:

Once a record has been created, it can be deleted (via the trash icon shown to the right of its entry in the list) or edited (via the blue edit icon shown to the right of its entry in the list).

Supported Record Types

Reblaze supports the following types of DNS records:

Expected formats for the respective values are given below.

A Record Type

The value for an A record is an IPv4 address in dotted decimal notation.

Example:

example: 192.150.2.1

AAAA Record Type

The value represents an IPv6 (128bit) address in a colon separated notation.

Example:

20541:0da8:85a3:0:0:8a2e:0370:7334

CNAME Record Type

A CNAME value is a domain name.

Example:

www.sample.com

MX Record Type

Each record includes a priority (integer) and an email server domain name. It is possible to add multiple records.

Example:

10 mail1.sample.com

20 mail2.sample.com

NS Record Type

Delegates a DNS zone to use the given authoritative name servers. (It is possible to include multiple name servers.)

Example:

ns1.amazon.com

ns2.amazon.org

ns3.amazon.net

ns4.amazon.co.uk

TXT Record

Includes a text record. (Enclose the text in quotation marks. Multiple entries are allowed.)

Example:

"test1"

"test2"

SPF Record

SPF records were formerly used to verify the identity of the sender of email messages. It's now deprecated, and a TXT record should be used instead.

Example:

"v=spf1 ip4:192.168.0.1/16-all"

SRV Record

A generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX.

The syntax is based on the following: [Priority][Weight][Port][Domain Name]

Example:

2 12 5050 sip-server.example.com

3 15 5060 network.example.com

PTR Record

Pointer to a canonical name. Unlike a CNAME, DNS processing stops and the name is returned.

Example:

www.example.com

Overview

This section defines the Services that Reblaze will protect. In other words, these are the destinations to which Reblaze will send the (legitimate) traffic it receives.

Each Service can receive traffic for multiple web applications, and for multiple resources/locations within each web application. These assignments are made on the page.

Service Administration

At the top of the window, the title on the left displays the Service currently being displayed for editing. The pulldown on the right allows the selection of a different Service.

Adding a Service

To add a Service, click on the "Add" button (the plus sign).

Saving and Publishing Edits

Deleting a Service

Endpoint Definitions

For a single Service, you can define multiple endpoints. Within them you can:

• Enable and configure load balancing, weighting and distributing traffic across your primary endpoints.

• Define backups hosts, to which Reblaze will failover your traffic when your primary hosts aren’t available.

• Take hosts offline for maintenance by ticking a single box in the interface.

Adding and deleting endpoints from this list is straightforward. To add an endpoint, click on the Add button (the plus sign) and fill out the new entry. To delete an existing entry, click on the delete link next to that entry.

The settings for each endpoint in the list are as follows.

General Settings

The Name field defines the description for this Service within Reblaze.

Use HTTP/1.1: selecting this can speed up communication, via the use of connection pooling.

Transport Protocol: this configures the communication between Reblaze and the backend.

Load Balancing

Sometimes an application requires a user to be connected to the same Reblaze instance and backend endpoint throughout the session. Reblaze can ensure that this occurs, and can do so using a variety of methods.

Introduction

This section allows you to manage your SSL Certificates. You can create, edit, attach, and remove certificates. The certificates themselves can be uploaded and stored into Reblaze's cloud, or a cloud load balancer.

A note on certificates and sites

If you are reading this Manual as part of an initial evaluation of Reblaze, and if you have large numbers of certificates to manage, you should know that Reblaze treats certificates differently than most other security solutions.

It's not unusual for some companies (especially SaaS platforms) to have dozens or even hundreds of certificates to manage. Unfortunately, most security solutions treat each SSL Certificate as a separate "site," and they charge their customers on a per-site basis. Thus, these solutions can be extremely expensive.

Contrary to this, Reblaze does not treat certificates as sites. A certificate is merely a certificate. For customers with tens or hundreds of certificates to manage, Reblaze's monthly pricing can be one or two orders of magnitude less than its competitors'.

Section Overview

The SSL Management interface is split into 2 tabs: Load balancers and Certificate store.

The Load balancers list shows the load balancers for the current site, and the certificates that are attached to them. Certificate store is where certificates are managed.

Load Balancers

Entry parameters

For each load balancer shown in the list, the displayed parameters are:

Table 1: Max number of certificates depending on the load balancer type

Table 2: Cloud vendor regions

Administration

The Filter by name input control at the top accepts regular expressions, and quickly filters the list to show matching entries.

Selecting an entry in the list expands it to show that load balancer's details: a default certificate, and a list of any additional attached certificates.

The expanded list provides several buttons to perform administrative actions.dnnd

• To change the default certificate for the load balancer, select the Set default button next to the name of the desired certificate.

• To remove a certificate from the list, select the Detach button next to its name.

• To attach a certificate from the certificate store, select Attach certificate. See discussion below.

Attaching a certificate

Additional certificates can be attached to a load balancer until it reaches its full capacity, i.e. the maximum number of certificates shown in Table 1. (Full capacity is indicated when the "# Of Certs" column contains two similar numbers, e.g., "15 / 15". Also, the Attach certificate button will change to the message "You have reached the max certificates quota for the load balancer.")

To attach a certificate, select the Attach certificate button. This will open a modal window with a list of unattached certificates from the certificate store:

The Filter by name input control at the top accepts regular expressions, and quickly filters the list to show matching entries.

To attach a certificate, press the Attach button next to its name. The certificate will disappear from this list ail appear in the list of the certificates attached to the load balancer (see Figure 2).

Certificate store

This tab displays certificates according to the site to which they are attached.

The Filter by name input control at the top accepts regular expressions, and quickly filters the list to show matching entries.

For each entry, the displayed parameters are:

Certificates are loaded console. After that they can be loaded to a cloud provider. The AWS/GCP columns indicate which provider has the certificate. It can be none, one, or both.

Generating a new certificate

Adding an existing certificate to Reblaze

SSL certificates can be added to Reblaze in two ways:

• Uploading a PFX file.

• Manually entering the certificate information.

In both cases, begin by clicking the "+" button. This dialog will appear:

To upload a PFX file, select "Extract pfx file." Otherwise, enter the Private Key, Certificate body and Intermediate chain values into their respective text boxes.

Editing and managing existing certificates

To remove an existing certificate, click on its trash icon to the right of its entry in the list. You can delete a certificate if it's not linked to a site. However, you cannot remove the last certificate on a load balancer.

To edit a certificate, click on its edit icon to the right of its entry in the list. This dialog will appear:

The following options are offered:

• Attach to application - Select an application/site and attach it to this certificate.

• Replace existing certificates - When this is chosen, a "Select Certificate" dropdown list will appear. 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.

• Auto Replacement by Let's Encrypt: See discussion below.

• Download PFX: Download the certificate information as a file in PFX format.

When managing certificates through one of these options (except for "Download PFX"), you must click the Save button to preserve your changes.

Automated replacement using Let's Encrypt

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

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

As described in Traffic Concepts, out of the box Reblaze 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 Reblaze 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 Reblaze to use Biometric Bot Detection—an advanced and sophisticated means of distinguishing humans from automated traffic sources.

Biometric Bot Detection

With Biometric Bot Detection, Reblaze 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 uses Machine Learning to construct and maintain behavioral profiles of legitimate human visitors. Reblaze 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. More information about this.

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>

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

• 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 Mobile SDK, 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.

• For specific URLs/locations: remove the default "Deny Bot" ACL Policy from all Profiles that are assigned to those locations.

• For an entire site/application: remove the "Deny Bot" ACL Policy from all Profiles within the site.

• For specific traffic sources: Add an ACL Policy that will 'Allow' those specific requestors. The requestors should be defined as narrowly as possible.

If you merely remove the Deny Bot ACL Policy from the relevant Profiles, then bots will still be excluded by the other active ACL Policies, Dynamic Rules, content filtering, and so on. If instead you added an "Allow" ACL Policy to specific requestors, then other ACL Policies will not block those requestors; they will be exempted from ACL Policy filtering.

The Planet Overview page enables the following actions:

1. Add and manage a site/application.

2. Generate an SSL certificate for a site/application using the Let's Encrypt service.

3. Publishing configuration changes.

4. Configuring Notifications and Alerts.

Note that in the discussion below, "site" and "web application" are synonymous.

This section allows you to add and modify web applications. It does not provide the ability to delete them.

Adding a Web Application

Creating a new web application is done by duplicating an existing one, and then editing the one that is created.

• Select an existing site that is the most similar to the one you want to add.

• Select its "Duplicate Application" button.

• This will clone the site and create a new one with identical settings, which you can then edit.

Editing a Web Application

Clicking on a site name will open it in the Web Proxy page, where it can be edited.

Generating a New SSL Certificate

Reblaze integrates with Let's Encrypt to provide free SSL Certificates.

By clicking on the "Generate Certificate" button at the end of an entry in the site list, you can:

• Generate a new certificate without attaching it to a site

• Generate a new certificate and immediately attach it to a site. If the site has an existing certificate, it will be replaced by the new one.

In either case, this is the dialog you will see:

Just choose the button for the activity you want.

Notification and Alert Settings

At the bottom of the Planet Overview are the Notification Settings.

When a Dynamic Rule is violated, Reblaze can send immediate alerts to a list of one or more email addresses, SMS numbers, and hooks (e.g., Slack).

In addition, a cumulative report of the previous week's violations can be sent to one or more email addresses.

This section defines one or more Notification Groups for these notifications. Clicking on the "+" button on the right will display this dialog:

The settings for a Notification Group are as follows.

An existing Notification Group can be edited by clicking on its listing, or deleted by clicking on the trash button at the right end of its listing.

When you deploy Reblaze to protect your web assets, it acts as a proxy; it receives requests from clients (web visitors, mobile/native app users, etc.), blocks hostile traffic, and passes legitimate requests to your servers.

The Web Proxy page defines how Reblaze behaves in this role. It contains these sections, from top to bottom:

1. Web Application Selection

2. Security Profiles

3. Frontend

4. Backend

5. Mobile SDK Settings

6. Advanced Frontend Settings

7. Further Advanced Settings

8. Site Deletion

After making edits to this section, Save Changes and Publish them to the cloud.

Web Application Selection

At the top of the page, the title shows the web application currently being displayed below for editing.

The pulldown on the right selects the web applications to edit. The save button on the far right saves the edits that have been made to the current application.

Security Profiles

This section shows a list of URLs/resources within the application, and defines Reblaze's behavior for them.

Every incoming HTTP/S request targets a specific URL. Reblaze finds the best match for that resource in this list, and applies the security configuration defined for it.

An HTTP/S request which passes all security tests will be forwarded to the Backend Service defined for the requested resource.

Adding a Resource Definition

Editing a Resource Definition

To edit a definition, click on the "expand" button at the end of its listing. The following window will appear.

The entries in this window correspond directly to the various fields discussed earlier in the definition listing.

Deleting a Resource Definition

Frontend

This section configures Reblaze's behavior as the frontend for traffic.

Backend

This section (shown above in the previous screenshot) configures Reblaze's communication with the backend.

Mobile SDK Settings

This section lists the signatures of recognized applications and available remote profiles.

App Signatures lists 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 extract 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 here.

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

Any number of signatures may be 'Active' at given time. While debugging the app on emulator, it will present a special signature "abadbabe": make sure it is not activated on production.

Profiles lists the remote profiles that can override the parameters of the SDK on all mobile clients. The Default profile is always empty, and when it is active, the SDK parameters are fully determined by the app local configuration. Only one remote profile may be active at given time.

Grace period defines the allowable time between the timestamp of a request and the time that Reblaze receives the request from the application. Requests with a longer delay will be rejected.

UID Header Name determines the name of the header that contains the user authentication token. With the new versions of Mobile SDK, it can be empty.

Support for old versions of Mobile SDK is disabled by default, but if your app has not fully migrated to Mobile SDK v2.0, you can enable backwards compatibility:

Documentation for the old versions of Mobile SDK is available here. Note that the Grace Period field is read-only; it only reflects the global setting above.

Advanced Frontend Settings

This section defines several types of limits: Timeouts, Size Limits, and Request Rate Limits.

Timeouts

The Timeout settings allow the system to monitor the time required to serve resources to each client. Any connection that exceeds the specific limits will be dropped.

The Timeout settings allow Reblaze to block unresponsive requestors, whether their unresponsiveness is malicious or not. For most Reblaze deployments, the default timeout settings work very well. They are sufficient to filter out hostile traffic, while still accommodating even those users with low bandwidth.

All times are specified in seconds.

Size Limits

You can place limits on the amount of data that users can upload to the system. The defaults usually work well; however, if your application accepts user-generated content or other large files, then changes to these settings might be necessary.