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.

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!

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.

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.

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

: 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

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

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

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

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

The discussion below is for sites and web applications.

The Challenge Process

Most of the Reblaze interface focuses on configuration for:

• The detection and mitigation of hostile requests.

• The detection and mitigation of hostile behavior of requestors.

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

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

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

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.

Passive challenges still include Environmental detection and browser verification, while adding three additional benefits:

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

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

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

To learn more about passive challenges, go here: Enabling passive challenges.

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

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

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.

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.

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 .

Configuring your environment

Setting up Reblaze

Testing your setup

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

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

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.

The ACL Policies section allows you to define 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 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

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

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

Special ACLs

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

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

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 Session Profiles, which are combinations of Tags and the criteria for assigning them to requests.

Each Session Profile 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 Profiles

Session Profiles can be either Internet-sourced or self-managed.

• Internet-sourced Profiles 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 Profiles are created manually. These lists are fully editable within the interface.

Administration

At the top of the page, the pulldown list specifies the Profile 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 Session Profile

To add a Session Profile, either:

The new Profile 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 Session Profiles.

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

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.

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.

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.

Signatures that have already been defined are listed in the left column, while you can edit and create new ones on the right. Once a Signature has been created, it will be available in the New Rule section within the ACL Policies tab.

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

An explanation and some examples are here: Pattern Matching Syntax.

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.

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 Security Profiles section of the Web Proxy page.

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:

At the bottom of the page are the Request Arguments Limitations, Whitelist Argument Names, and Whitelist Rule IDs. These allow you to permit or deny requests based on the arguments contained in the request. For assistance with these entries, please contact support.

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. Advanced Frontend Settings

6. Custom Challenge Parameters

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.

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.

Request Rate Limits

These settings allow you to limit the amount of resources consumed by an IP address. Reblaze can limit consumption by the average number of requests per second, while also allowing temporary bursts at a higher rate.

When a requestor exceeds any of these thresholds, subsequent requests will be answered with error code 503 (Service Unavailable).

Session Key

Reblaze can track a session by using a header, argument, or cookie. This parameter allows you to specify which one to use.

Custom Challenge Parameters

This section is for configuring security for mobile applications.

The parameters on the left are for applications which use Reblaze's Mobile SDK. The parameters on the right (the "Grace" parameters) are meant for applications which do not use the SDK. It is recommended to use the SDK if possible, since this provides much more robust security and the ability to authenticate client requests.

Further Advanced Settings

This section is for advanced configurations only. To use it, please contact support.

Site Deletion

To delete the current site or application being displayed on the page, enter its name into the textbox and click on the Delete site button. Note: this action cannot be undone.

Before deleting a site from Reblaze, you should change your DNS settings to reroute your traffic, and then wait for the changes to propagate. Otherwise, Reblaze will still be receiving traffic, but the traffic will no longer be passed upstream to your server.

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 Certificate Management interface displays certificates according to the load balancer to which they are attached. Those stored in the Reblaze cloud are listed as "None."

Displayed parameters are:

Choosing a different load-balancer option will filter the certificates and display only the ones attached to that LB.

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 "New" button. This dialog will appear:

To upload a PFX file, select "Choose File." Otherwise, enter the Cert Key and Cert Body values into their respective text boxes.

Selecting a load balancer

On the upper right, select the load balancer to which this certificate will be attached. If "None" is selected, the certificate will be uploaded and stored on Reblaze's cloud.

Specifying application(s)

In the example screenshot above, a specific load balancer IP has been selected. This enables the options shown at the bottom of the screenshot:

• Attach to Application: Specifies the application/site to which this certificate will be attached.

• Replace existing certificate: Replaces an existing certificate with this new one. All web applications that were attached to the specified certificate will now be attached to the new one.

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 blue edit icon to the right of its entry in the list. This dialog will appear:

Under "What would you like to do?", the following options are offered.

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

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

• Copy to another load balancer (available only when this certificate is attached to a LB, and more than one LB exists) - Allows you to copy the certificate and upload it directly to another load balancer.

• Auto Let's Encrypt Renewal/Replacement: 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 renewal 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, then the following process occurs:

• If the Auto Let's Encrypt Renewal option for that certificate is enabled, Reblaze will generate a new certificate using Let's Encrypt.

• If the Auto 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.

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.

The Ban action

Most of the Actions listed above 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 Default, Response, or Redirect). However, you can also choose Tag (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.

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

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.

Sometimes ACL Policies can make it difficult to find and block a specific attacker.

For example, let's say an ACL Policy (named "Allow US Traffic") for an ecommerce store allows all traffic originating from the United States. But then an attacker, using an IP within the US, begins to scrape prices and other data from the store.

If an ACL Policy were added to Deny that IP address, it wouldn't work. The hierarchy of ACL Policy enforcement means that the "Allow US Traffic" Policy will take precedence, and the 'Deny' Policy for that IP will never be invoked.

One way to quickly solve this problem is to add an ACL Policy with a name ending in a suffix of "XDeny" (for example, "Block US Scraper XDeny"). As was discussed in the "Special ACLs" section, that suffix moves the ACL Policy to the top of the hierarchy.

Therefore, that ACL Policy will be invoked and enforced for that IP address, and the attacking IP will be blocked, before the "Allow US Traffic" Policy has a chance to grant it access.

The Quarantine section shows a list of traffic sources (i.e., sources of incoming requests) that are currently banned, blacklisted, and whitelisted.

How to ban a requestor

A traffic source is banned automatically when it violates a Dynamic Rule. You cannot manually ban a requestor.

However, you can accomplish the same effect by blacklisting the requestor. Instructions are here.

How to unban a requestor

You can manually remove a requestor from the Banlist or Blacklist. Instructions are here.

How to whitelist a requestor

Whitelisting a traffic source will make it exempt from Dynamic Rules. Instructions are here.

Sometimes a customer wishes to "attack" an application or server as part of a loadtest. Under normal circumstances, Reblaze would prevent this, because it would enforce rate limits and block the excessive requests from reaching the upstream network.

The test can be accomplished by creating an ACL Policy which allows the source IP (or range of IPs), then naming that ACL Policy with a suffix of "OC." (For example, the ACL Policy might be named "Loadtest OC.")

As discussed in the Special ACLs section, the "OC" suffix means that the IP will not be subjected to normal rate limit testing. This allows that IP to generate a large amount of traffic, which will be passed through upstream without being filtered by Reblaze.

Web clients can cache resources from a server. Afterwards, a client can access its local cache, which reduces the number of requests sent to the server.

Servers can instruct clients to implement caching in certain ways. Servers can also set separate caching policies for any intermediary proxies in-between the server and the client.

Reblaze is a proxy between the clients and the backend. When the backend responds to clients, the outgoing responses pass through Reblaze. You can instruct Reblaze to preserve or alter the caching instructions in those responses.

This can be done through Cloud Functions. A future update will provide multiple cache policy templates. Meanwhile, if you need immediate assistance in customizing Reblaze's caching behavior, contact support.

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.

Introduction

A typical security solution provides information about the traffic that it has blocked. Contrary to this, Reblaze shows all of the traffic that it receives.

This provides you with a powerful ability to dig into your traffic data and gain deep understanding about the nature and disposition of incoming requests.

Metrics about blocked requests are very useful, but their usefulness is multiplied when you can compare them to passed requests. By showing all requests, Reblaze allows you to understand what "normal" requests look like. This gives you more insights into abnormal traffic.

Gaining General Insights

Reblaze provides multiple ways to view your traffic. The discussion below will focus on the View Log. Similar tactics can be applied when viewing different parts of the Dashboard.

Sometimes the View Log is used to answer a specific question about a request or a traffic source. At other times, it might be a more general exploration; for example, a beginning-of-the-day review of what happened over the last 24 hours.

Let's discuss the latter scenario (a general exploration). Because the View Log shows all requests, it can be overwhelming. It's helpful to start by excluding requests that aren't as relevant to your current purpose. Examples:

• Exclude passed requests, and show only the challenges or blocked requests: reason:challenge (to show only challenges), or is:blocked (to show only blocked requests).

• Exclude requests being rejected by the origin (i.e., the upstream server): reason:!by origin

• Exclude requests from a banned IP: ip:!1.2.3.4 . Another approach: reason:!autoban/etc.

• Exclude requests that are obviously invalid, e.g. those with unrecognized host headers.

Eventually, you can filter the display down to a list of challenges or blocked requests that might produce some insights.

From this point, you are looking for possible patterns, or unusual outliers, and considering possible actions to take. For example:

• Are there a lot of requests for a Wordpress file, but your site does not use Wordpress? These are coming from malicious traffic sources. It might be useful to set up a Dynamic Rule, e.g. to Ban requestors who submit more than one request for that file in a three-minute period.

• Is the same IP failing multiple challenges? It might be interesting to filter on that IP only, and go through all of its activity, to see what that traffic source was trying to do. (You can see that a challenge is being failed when the challenge itself appears in the logs, but it is not followed by a successful request by the IP for the same URI.)

• Are there many blocked requests for the same URI, but from different traffic sources? This might be a False Positive alarm. See below for more on this.

There is no set procedure for this process. Essentially, you are browsing the list of challenges or blocked requests, thinking about why you are seeing the entries there, and asking further questions.

Translating Encoding in Requests

Sometimes, request data will be encoded. Here's an example of a XSS attempt.

The script in the request is HTTP encoded. To see it in plain text:

• Double-click on the reason (the yellow label beginning with XSS).

• The full contents of the label will appear in the query box, decoded.

For some forms of encoding, more processing is required.

• Reblaze does not perform all possible forms of decoding in the interface.

• Double-encoded requests will only have their first level of encoding undone.

In these cases, you can highlight the string in the query box, copy it, and run it through decoding tools. (For example, http://0xcc.net/jsescape/.)

False Positive Alarms

A “False Positive” (FP) alarm occurs when a security system misinterprets a non-malicious activity as an attack. These errors are a critical issue for cybersecurity.

Although it might seem that FP errors do not necessarily have serious consequences, incorrect security alerts can lead to significant monetary losses. For example, an e-commerce site might incorrectly exclude real online shoppers. Or, it might reject "good" web crawlers, which would reduce its Internet visibility.

FP diagnosis is often done when Reblaze is first deployed, before it has been fine-tuned for the customer's applications. It can also be done later, when you discover that certain requests are being blocked, but you do not understand why.

Determining if a block is a FP

When examining blocked request(s), it can be helpful to ask questions such as the following.

Is Reblaze's configuration appropriate for the application?

Sometimes an application will expect and accept inputs that Reblaze blocks by default. Example: the site might use a CMS which accepts HTML/Javascript POST requests. However, out of the box, Reblaze is often configured to block requests containing POST. Thus, Reblaze would need to be re-configured to match the application it is protecting. (In this example, it's a simple toggle switch in the WAF/IPS Policies interface.)

Has the web application been updated, without Reblaze being updated as well?

If the range of valid inputs has changed, but Reblaze was not re-configured, then FP errors can result.

Is the block happening to multiple users?

If a single IP is being blocked, but other requestors for the same URI are being allowed through, the block is more likely to be the correct response to this IP's request. This is especially true when the single IP has attempted other questionable activities.

Conversely, if multiple requestors are being blocked, and they seem to be innocuous otherwise, this indicates the problem might be a FP.

Is the block being done by Reblaze, or is it coming from elsewhere?

There are some situations where a request is blocked even though Reblaze has no obvious reason to be blocking it. This can occur when Reblaze is not actually the entity making the decision.

• The upstream server can reject requests. These requests can be displayed in the View Log withreason:by origin as the filter.

• Reblaze can use ACLs with external sources of information, e.g. Spamhaus. Example: a request is blocked with a reason of acl-ip. The reason indicates a Reblaze ACL blocked the request because of its IP—but what if you didn't configure any ACLs to reject specific IPs? The answer is that there are several ACLs which rely on external lists of hostile IPs, such as Spamhaus DROP and eDrop.

Is this a FP that resulted from incorrect user actions?

Example: a web user visited a landing page, entered contact details into a form, and then tried to proceed to the next page. However, the request to proceed was blocked.

This could be a FP due to "junk input." Perhaps the user entered a phone number of "1111111111" and it was rejected by the upstream application. Or perhaps the page itself autocompleted a field and inadvertently created junk input on its own.

Is this a FP that resulted from faulty or too-restrictive parameters within Reblaze?

If requestors are being blocked for violating rate limits, and the rate limits are very stringent, then perhaps the limits are too tight, and they need to be relaxed.

Or, perhaps the block is the result of content filtering. This feature is powerful, and it is possible to mistakenly configure it to be too restrictive.

Example: requests are being blocked because of a Custom Signature (reason:acl-custom-sig).

Looking up the custom signature shows that its "Is matching with" condition is the following regex:

(?i)(select|create|drop|\<|>|alert)\W

The admin wrote this regex in order to identify SQL injection attempts (i.e, SELECT, CREATE, and DROP commands. Normally SQL and code injection attempts are blocked automatically by the WAF, but occasionally customers choose to disable this).

Now let's examine one of the blocked requests in the View Log. Its Capture Vector is this:

https://www.pinterest.com/pin/create/button/?url=https%3A%2F%2Fexample.com%2Fpitbull-2012%3Frt%3Dstorefront%26rp%3Dpitbull%26rn%3DPitbull%26s%3Dhanes-S04V%26c%3DBlack%26p%3DFRONT&media=&description=

This can be decoded with a tool such as http://0xcc.net/jsescape/. It now becomes this:

https://www.pinterest.com/pin/create/button/?url=https://example.com/pitbull-2012?rt=storefront&rp=pitbull&rn=Pitbull&s=hanes-S04V&c=Black&p=FRONT&media=&description=

Now let's see why the regex condition matched the request. On https://www.debuggex.com/, it's possible to paste in regex and a string, and see if/where a match occurs.

Notice the highlighted (in yellow) part of the string in the bottom textbox. This shows which part of the bottom string matches with the regex in the box above it.

We see that the expression that was meant to identify an SQL command of CREATE, is also matching with the URL generated by a user who was trying to feature this site's product on Pinterest.

This indicates that the regex should probably be modified, so that it only accomplishes its intended purpose. In this example, it could be modified as follows:

(?i)(\sselect|\screate|\sdrop|\<|>|alert)\W

This would require a space to be found before each potential SQL command, thus eliminating matches when those words are found in a URL.

Summary of FP Detection

As mentioned earlier, there is no set procedure for the process of identifying the underlying reasons why requests are blocked. It requires digging into the requests, gathering data, and asking questions.

Hopefully the examples above are helpful in illustrating the necessary thought process, and some of the tools that are available.

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.

This section describes best practices for some common tasks.

The Account Settings allows you to review and modify your Reblaze user account.

From this page, you can reset your password. Before this can be accomplished, you will need to enter an OTP (One Time Password) code that will be sent to you via SMS text message.

Alternatively, you can scan the QR code shown on this page, using an app like Google Authenticator (available for both Android and iPhone).

This will generate an OTP without requiring you to wait for an SMS message.

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 publish your changes.

Whenever you change the configuration of the Reblaze platform, you must save your changes, and in almost all cases, you must publish them to the cloud as well.

Saving Changes

The Reblaze interface has several ways in which to save changes.

In many places, this button appears on the upper right part of the screen:

In other places, the Save functionality is part of a pull-down menu, which is designated by three vertical dots:

Remember that you must select Save Changes, in whatever format the button is offered, whenever you make any edits within the Reblaze interface.

Also remember that in almost all cases, Save Changes only saves your changes within your local session. To push them to your planet in the cloud, you must Publish Changes as well.

Publishing Your Changes

When editing Dynamic Rules, saving your changes will apply them to your planet.

In all other cases, after Saving your changes, you will also need to Publish them, which will push everything to the cloud.

In some cases, choosing the Save button will be followed by an immediate prompt to Publish. In other cases, it will not, but Publishing is still required. Again, it is recommended that you adopt the habit of always Publishing after Saving.

Publishing is done on the Planet Overview page, via the button on the upper right. The outcome will appear on the screen once it is complete.

Introduction

The Reblaze query command box allows you to query the data in order to present only the records that you want. The structure of a filter is operator:value.

For example, to view only traffic from IP 10.11.12.13:

ip:10.11.12.13

An exclamation mark ("!") can be used with various filters as a "NOT" operator. So, to exclude requests from an IP, add "!" as a prefix:

ip:!10.11.12.13

Note that filters can be combined to fine-tune a search, by chaining them with a comma. For example, in order to show all traffic from France that was blocked:

country:France, is:blocked

Building Queries Efficiently

For example, when looking at this entry for a blocked request (the IPs have been censored for privacy reasons):

Let's say you wanted to quickly see what other requests produced a 403 error that came in from the United States on a cloud IP. Double-clicking on the "403" label, the "United States" label, and the "Cloud" label builds the query string for you automatically:

Then select the "search" button, or place the cursor within the query box and hit "Return" on your keyboard, to process the query.

In some situations, this technique has limited usefulness. In the example screenshot above, double-clicking on the label beginning with "XSS" would add a (very) long filter string to the query, because that label contains the full script from the injection attempt (although the label itself only displays the first few characters in the interface).

If this is what you want (perhaps you need to search only for logged requests which contain that exact script), then this is effective. But if you wanted to build a more general query, then this is not useful.

A better approach is to choose a representative substring.

Examples:

• reason:XSS will show all records with "XSS" in their reason label.

• url:login will include all URLs that include "login".

• ip:191 will display all IP addresses containing "191".

Filter Use Cases and Examples

Regular expressions can be applied to the filter value to make the search more accurate. The regex matching is done by wrapping the search value with re(REGEX here). Examples:

is:re(200|401)

ua:re(iOS!iPhone!iPad)

If you wish to display login requests with method “POST” which were blocked, but not by the origin (upstream server):

url:/login,is:POST,is:blocked,is:!origin.

This displays those requests which produced 502-504 error codes:

is:re(502|504)

This displays the requests that contain a specific value in an argument:

arg_name:text, arg_value:free_text

Available filters

This section answers questions that often arise about using Reblaze.

There are several ways to filter requests based on their content.

Recommended Method: Session Profiling

1. Create one or more lists of content filters in , with appropriate tags.

2. Create for each tag with appropriate actions (Bypass, Deny, or Allow).

3. Include the ACL Policies in one or more .

4. Include the ACL Profiles in one or more .

Other Methods

can be used for specifying content restrictions. They are included within , which are used within , which are assigned to various locations of your site/application on the page.

examines the characters found in arguments. Depending on its mode, it can block requests if unexpected characters are found, or pass them on to the WAF for further inspection. It can also act as an inverse content filter; those requests with arguments which contain only whitelisted characters can bypass WAF filtering.

Reblaze integrates with a wide range of SIEM [Security Information and Events Management] and SOC [Security Operation Center] solutions. Nearly 80% of our enterprise clients stream Reblaze events to their SoC, such as ArcSight, RSA, IBM, and Splunk.

Secure data streaming

Reblaze sends logs over TLS using the Syslog protocol.

The integration process

The variety of available integrations makes it impossible to describe the process for each of them here. Our team will assist you with the integration, to ensure your platforms get the relevant information as soon as it becomes available.

To make the connection, Reblaze requires the following:

• Destination IP/FQDN

• Destination port

• Destination's public SSL certificate in PEM format. (To prevent a MITM vulnerability, Reblaze performs SSL pinning.)

Please have this information available when you to begin the integration.

Data format

Raw logs are sent in the format described .

This video will explain how to manage your SSL Certificates in Reblaze. For more information, see in the section of this manual.

Often, a web application will use external pages. For example, within digital marketing campaigns, it’s common to use landing pages that are provided by a third-party service.

Since these pages are generally hosted by the service provider, they are not directly protected by Reblaze. However, a customer can still use Reblaze to scrub traffic coming from them, and block hostile visitors from affecting the parent site (i.e., the site/application that is using the third-party service).

For example, bots can stuff false information into landing-page forms and submit it to the parent site. Reblaze cannot prevent the bots from accessing the third-party landing page. However, it can interdict the form submissions, and prevent them from passing through to the parent site.

Most third-party services allow code to be embedded into their pages. The following process takes advantage of this.

Add the following code to the page (ideally and if possible, in the page header):

<iframe src="https://www.example.com/pixel-path" width="0" height="0" style="display:none"></iframe> 

Explanation:

• “www.example.com” is your site.

• “pixel-path” is a non-existent path. In other words, the overall address won’t actually resolve to a page or resource within your site.

The purpose of this request is not to return a resource or page; it is merely to trigger a call into the parent site. The call will trigger an active challenge.

• If the visitor is a bot, the challenge will fail. Subsequent access attempts to the parent site (e.g., form submission attempts by a bot) will be blocked.

• If the visitor is a human, the web browser will receive Reblaze’s authenticating cookies. Subsequent actions by the visitor will include the cookies, and will be accepted by Reblaze.

Reblaze REST API operations v2.x

Below are listed the available operations under Reblaze's API. The listings include descriptions, and examples using curl over Bash under Ubuntu 18.

The parameter $HOST refers to the console FQDN, while $KEY refers to the API key.

Operations

List Sites

Lists all sites that are currently set up on the management console.

Duplicate Site

Duplicates/creates new site based on an existing site. You can choose to overwrite the upstream, or use the one that is currently set on the source site. The duplicate site will also create a referring CNAME based on the source site DNS settings.

Remove Site

Removes the site from the sites list. This operation also removes the referring CNAME.

Set Names (domain aliases)

Sets the list of domains that a site supports, and replaces any that existed previously. You can add up to 100 domains per site. A domain can also contain wildcards (e.g, *.domain.name).

Add Names (domain aliases)

Adds to the list of domains that a site supports, without replacing any that existed previously. You can have up to 100 domains per site. A domain can also contain wildcards (e.g, *.domain.name).

Get Names (domain aliases)

Returns the list of domains that a site supports.

List Upstream

Lists the upstream settings of a site.

Set Upstream

Modifies upstream settings. You can add an upstream, change its state, or modify the upstream address. The upstream is a one-line JSON encoded in base64, as shown below. Parameters are described below the code example.

one_line_json='[
  {
    "http_port": "80",
    "https_port": "443",
    "weight": "1",
    "fail_timeout": "10s",
    "monitor_state": "0",
    "down": false,
    "host": "1.2.3.4",
    "max_fails": "1",
    "backup": false
  },
  {
    "http_port": "80",
    "https_port": "443",
    "weight": "1",
    "fail_timeout": "10s",
    "monitor_state": "0",
    "down": false,
    "host": "4.3.2.1",
    "max_fails": "1",
    "backup": false
  }
]'

Encode the json with base64

Set the Upstreams

Add Certificate

Adds a new certificate to the SSL Management.

Attach Certificate

Attaches a domain to a SSL certificate.

Detach Certificate

Removes an attached domain from SSL.

Publish Changes

This video will explain the basics of DNS management in Reblaze. For more information, see DNS in the Settings section of this manual.

There are two APIs within Reblaze: the REST API to control the platform programmatically, and the one used internally by the Mobile SDK.

Most hostile bot activity involves headless browsers and mobile phone emulators. To detect these bots, most web security solutions rely on Javascript injection to detect the browser environment.

Unfortunately, these detection methods have become increasingly ineffective. The latest generations of bots use sophisticated software stacks, and they are able to masquerade as humans using normal browser environments.

To identify hostile bots, the Reblaze platform uses a variety of methods, collectively known as Reblaze Client Side Inspection (RCSI). Although Javascript plays a role within it, RCSI as a whole is unlike any other Javascript challenge in use today. RCSI is effective for protecting web applications, services/APIs, and mobile/native applications. (Some of the implementation details differ, depending on the context.)

RCSI detects bots via a multi-layered approach, described on the following pages:

Log line structure is as follows, note that some fields are quoted and some are not.if we will add more fields in the future, they'll be added on the right side.

Field names:

Example line (sliced into smaller parts):

Headers are base64 encoded JSON string contains headers names and values.

if we decided to block a request, either by ACL, or WAF/IPS it will be marked as "1" in the blocked field,

as well there will be a description at "block_reason" field.

Decoding headers filed shall result with the following:

Note that within the headers, we add an entry for the post_request_body.

Python Parser Example:

Different types of rate limits are defined in different parts of the Reblaze interface.

Static rate limits for each application: Timeouts and request limits per IP are set for each application on the .

By location: Rate limits for specific locations/URLs can be created in and then including them in .

By traffic source: Requestors who are submitting excessive requests across the planet can be banned for configured lengths of time. This can be done via .

Creating Rate Limiting Exemptions

Creating exemptions from rate limits is done differently, depending on the scope of the rate limits being addressed.

Global: Create an .

By location: Create an with the name "Rate Limit Whitelist". This can exempt any combination of IP, Country, and ASN. The Policy should then be included in a , and the Profile should be to the appropriate location(s) or portions of your site/application. Example: