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.

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

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

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

Welcome 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!

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.

Overview

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

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

Prerequisite

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

Configuring your environment

Setting up Reblaze

Testing your setup

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

This section defines the parameters with which Reblaze scrubs traffic.

The user interface is divided into these sections:

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

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

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

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

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

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

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

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

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

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

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

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

Analyze Traffic Log

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

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

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

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

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

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

• Export to CSV creates a text-based spreadsheet file.

• The Help button opens a display with a quick-reference guide to Query box operator syntax.

• The Clear button removes your current Query box entries.

Log Structure

Log entries are color-coded depending on their type.

• Passed requests: Black text on a white background.

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

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

• Challenge: Brown text on a yellow background.

Clicking on any log entry will display its details:

This will reveal:

• The URL that was requested

• The user agent

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

• A row of colored labels:

  • Green: Passed request

  • Red: Blocked request

  • Yellow: Explanatory

  • Blue: Informational

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

2. HTTP Version

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

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

5. Origin Country and Country Initials

6. Block reason: The reason, if any, that the request was denied. Standard reasons are listed in the Reblaze WAF Signatures list, while others are constructed dynamically (e.g., from a rate limit). A hyphen ("-", as in the example above) means that the request was not denied.

7. IP Classification: Whether the requestor is using an IP from a cloud provider, VPN, TOR, etc. In the example above, the requestor is using a cloud provider. Note that this does not indicate that the request was blocked for this reason. If the current Profile had included an ACL to block cloud users, then the Block reason would say "acl:cloud", and then this "Cloud" notification would appear after it for the IP Classification.

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

9. Autonomous System Number (organization/ISP/etc.)

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

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

Examples for Log Filters

Example 1

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

Example 2

Using this regex syntax:

status:[4]\d\d

Provides all status codes for 4xx.

Example 3

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

Using the Log

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

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

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

The user interface has three main sections:

1. Filtering and Time Interval Selection

2. Traffic Graphs

3. "Top" section

Filtering and Time Interval Selection

Query Box

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

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

country:France, is:blocked

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

Time Interval Selection

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

Traffic Graphs

Passed vs. Blocked

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

Response Status

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

HTTP Status response codes are divided into five categories:

• 1xx - Informational Response

• 2xx - Request Successful

• 3xx - Request For Redirection

• 4xx - Client Error

• 5xx - Server Error

For a detailed list of response codes, go here.

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

Requests Count

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

Bandwidth

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

Latency

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

Zooming in

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

"Top" Section

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

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

Section Characteristics

Applications

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

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

Countries

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

Sources

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

Sessions

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

Targets

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

Signatures

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

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

Referers

Shows the referers that were extracted from the request headers.

Extensions

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

Browsers

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

Companies

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

Latency

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

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

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

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.

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.

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.

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 .

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.

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.

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.

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.

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

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

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

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

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

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

Creating a New Rule

Each of these fields is explained further below.

Operation

The Operation field has three possible values:

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

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

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

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

Match

There are five available options for Match:

• Tag

• Company

• Country

• IP Address

• Custom Signature

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

Match Argument

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

Tag

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

Company or Country

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

IP Address

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

Custom Signature

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

Special ACLs

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

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

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

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.

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.

The Arguments Analysis feature has two primary functions:

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

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

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

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

For both functions, an argument list must be built.

Building an Argument List

Initially, this section will look like this:

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

Automatic Argument Learning

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

Manual Argument Addition

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

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

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

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

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

Argument List Administration

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

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

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

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

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

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

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

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

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

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

Once Argument Lists Are Built

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

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

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

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

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

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

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

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

New Args Adaptive Mode

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

Automatic

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

Supervised

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

Locked

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

Preview

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

Handling Requests with Unmatched Characters

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

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

Inspect Unknown

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

Strict Whitelist

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

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

Conflicted Arguments

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

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

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

• Deleting

• Modifying

• Accepting

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

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

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

Unchanged Arguments

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

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

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

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

Rate Limit Rule Administration

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

Defining a Rate Limit Rule

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

Each is discussed further below.

Meta Parameters

Rate Limit

Event Criteria

Event criteria have two components:

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

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

Composing Keys

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

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

Key Fields

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

Multiple Keys

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

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

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

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

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

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

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

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

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

So, the evaluation becomes something like this:

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

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

Including/Excluding Requests

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

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

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

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

Action

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

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.

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.

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

SSL Management is where SSL Certificates are uploaded and managed.

DNS is where DNS records are configured.

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

Account is where your user account settings are managed.

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.

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.

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.

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

Reblaze provides the capability to generate an SSL Certificate for free using the Let's Encrypt service. This is not done in this section of the interface; it is done using the "Gen Cert" button on the Planet Overview page.

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.

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.

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.

This section describes best practices for some common tasks.

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.

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 AWS Route 53. 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, contact support for assistance.

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 contact support 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