Reblaze can be deployed via two main marketplaces: GCP, AWS and soon, Azure. In the future, with growing demand, the Reblaze solution will be added to other cloud computing platforms. Of course, Reblaze managed services is offered to you as well.

These guides will walk you through the process from the first "Launch" click on the marketplace until Reblaze is successfully deployed and protecting your website. We offer our help at any step of the process at support@reblaze.com.

Coming soon: Azure

Welcome to Reblaze!

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

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

Login

The initial login process is as follows:

1. Go to the link provided by Reblaze.

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

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

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

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

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

6. Click on the Login button.

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

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

Planet Overview

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

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

On the Web Proxy Page

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

In the Frontend section:

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

• Add the Trusted source IPs.

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

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

On the Backend Services Page

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

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

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

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

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

Setting up SSL Certificates

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

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

If you have an existing SSL Certificate

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

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

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

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

Generating a new SSL Certificate

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

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

3. Publish your changes as explained previously.

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

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.

This guide will walk you through the process from the first access of the marketplace until Reblaze is successfully deployed and protecting your website. We offer our help at any step of the process at .

Before doing your first deployment, we suggest that you watch these videos to better understand the onboarding and deployment process.

The process for onboarding Reblaze in AWS includes the following steps:

Last steps

Route your traffic to the load balancer

At this point, your deployment and setup are complete. Now you should test if your website works correctly when routing traffic to the Reblaze deployment. Perform offline testing by modifying your hosts file to point your website to the new load balancer. If you see that you are returned to your website, routing via Reblaze is working correctly.

The last remaining step is to route your traffic to the load balancer, which will send it to your Reblaze instance(s). Reblaze will scrub the traffic and forward it on to your servers. To setup this routing, set your DNS record to the IP address that is resolved from the load balancer DNS Name.

Activate Reblaze traffic filtering

Going Forward: Customizing Reblaze

As you might notice from looking through the interface, the Reblaze web security platform is both powerful and highly customizable, with the ability to be fine-tuned for your specific needs. However, it is beyond the scope of this document to describe this customization process. Furthermore, a full and correct customization is often rather daunting for new users.

Select the Deployment

1. Go to the AWS Marketplace at .

2. If you already have an AWS account, sign in to your account. Otherwise, you will have to create an account at .

3. Search for Reblaze.

There are two Reblaze deployments available:

1. Select the result for a SAAS contract (in above screen, the second result)

2. Review the pricing information, if you wish

Go to the top of the page and select Continue to Subscribe

Now, select the Reblaze contract and time period which best fits your needs. Then click on Create contract at the top of the page.

4. AWS will ask you to confirm your contract. To continue, click Pay now.

AWS will inform you that you have subscribed. Now click Setup your account.

Reblaze License Manager

Following your account setup, the Reblaze License Manager window appears. Click Sign Up and then enter the details requested, ensuring your email and phone number are valid. They will be needed later on.

Note that your phone number must be entered using the international format: the "+" sign followed by the country code, area code and number (no spaces or hyphens; for example, a US number: +17891234567). The phone number must be able to receive text messages.

When you have finished, select Sign up.

In the next window of the Reblaze License Manager, specify a password and select Set password.

Now, sign into the Reblaze License Manager with the credentials you just created. This is where you will create your licenses for Reblaze.

• Note that a separate license is needed for each Reblaze console. If you have multiple environments but wish to use only one Reblaze console, you will need just one license. But if you wish to have multiple consoles you will require multiple licenses.

• For each license needed, select the Generate new license button (see below).

• After you generate a license, you will receive a Welcome email containing your License ID and an AWS Marketplace link which leads to the Product Overview page in the Marketplace.

• If you do not wish to wait for the email and link from AWS, you may reach the same page directly from the AWS Marketplace.

  • If you do this by returning to the previous tab used, be sure to close the pop-up, shown below, without clicking the orange Setup button since you have already setup your account.

Now, go to the search field at the top of the page and once again, enter: Reblaze.

• Select the link that has a version number (which does not say SAAS contract). This will take you to the Product Overview page. On the upper right hand of the page, click the Continue to Subscribe button.

• Next, click Continue to Configuration in the upper right part of the page.

Launch CloudFormation

After selecting "Continue to Configuration," the Configure this software screen will appear. Confirm that the AWS region is correct. Then click the Continue to Launch button on the upper right.

1. The Launch this software screen will appear.

2. In the Choose Action section, select Launch CloudFormation from the dropdown box. Click Launch and begin the Launch process.

3. Accept the default template and then enter the Stack details: define a name for the Stack and specify the Vpcid.

4. Choose the Subnets in your AWS environment.

5. In the RBZAllowAccess field, enter the IP from your VPC, as appears in the Vpcid field.

6. In the Notification Email field, enter an email address.

7. In the Reblaze License ID field, enter the ID you generated in the Reblaze License Manager.

8. Click Next.

Configure Stack Options

Clicking "Next" (above) brings you to the Advanced options screen where stack options are configured. Many users will not need to enter any information on this screen, so you can click Next.

At this point, AWS will display a summary of the stack you are about to create. Review it and then click Create stack. AWS now creates the stack. Once created, you will be able to see the stack in the awstraining box in the Stacks section on the left, as shown in the screen in the next section (immediately below).

Complete the Deployment

Now, go to the Outputs tab and click the link circled below.

The link will take you to the Reblaze Management Console. You can now deploy Reblaze.

1. Enter the Login credentials you defined earlier.

2. The Welcome to Reblaze screen will be displayed with the account details automatically completed. At the bottom of the screen, click Complete Deployment. The remaining deployment steps and console creation now take place automatically in Reblaze.

Once you have received notification on your screen that the process is complete, you will be brought to the Reset My Password page.

1. Enter your email address and click Reset My Password.

2. This will bring you to the Log In screen.

3. Do not fill in the fields on the Log In screen.

• Wait for the email Reblaze will have sent you containing a link to the Reset Your Password screen.

  • Create a new password and click Reset My Password.

  • You will be returned to the Log In screen. From here you may begin setting up your sites and web applications within Reblaze.

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.

​Configure a Load Balancer

1. Go to the AWS Management console at https://console.aws.amazon.com/.

2. In AWS Services, go to EC2 > Load Balancers and click Create Load Balancer.

3. Click Create for Application Load Balancer.

4. Set the Load Balancer parameters:

1. Enter a name for the Load Balancer.

2. Under Load Balancer Protocol, select HTTP and HTTPS.

3. Under Availability Zones, select at least 2 zones.

These should be the same zones as you selected when specifying CloudFormation parameters in Specify Stack Details.

5. Click Next: Configure Security Settings.

Configure Security Settings

On the HTTPS listener, attach the correct certificate and select the Security policy.

1. Select a certificate name.

2. Select a security policy.

3. Click Next: Configure Security Groups.

Configure Security Groups

Allow access to the Load Balancer. Typically you will add a new security group for this, or you can select an existing one.

1. Select Create a new security group.

2. Enter a name for the security group.

3. For TYPE, click and select HTTP for the first row and HTTPS for the second row.

4. Click Next: Configure Routing.

Configure Routing and Create the Load Balancer

1. For Target Group, select Existing target group.

2. For Target type, select Reblaze-80. This is already available from the Marketplace deployment.

3. Click Next: Register Targets.

4. Click Next: Review.

5. Click Create.

6. Once the load balancer is created, click Close.

Update Listeners

The Load Balancer has been created and will appear on the Load Balancer page. Since you created an HTTPS listener earlier, the target group will require an update.

1. Select the Listeners tab for the load balancer.

2. You can see that both Listeners are being forwarded to Reblaze-80. Click View/edit rules for HTTPS 443. The Rules page for HTTPS:443 appears.

3. Click the edit icon (the pencil icon) on the Rules toolbar to edit the rules, then click the edit icon for HTTP:443. The Edit Rule box appears.

4. Click the edit icon under THEN.

5. For Target group, select Reblaze-443.

6. Click Update on the Rules toolbar. A message that "Default rule was successfully updated" appears.

7. Click the back arrow on the Rules toolbar to return to the Load Balancer page.

8. To confirm that the load balancer is configured correctly:

   1. Select the Description tab for the load balancer.

   2. Highlight the DNS name and click the copy icon next to it.

   3. Paste the DNS into a browser window. The browser should return a "403 Forbidden" page from "rhino-core-shield".

Now, return to AWS for the final steps needed to get Reblaze running on your website.

Procedure Overview

Procedure Details

Step 1: Console Creation by Reblaze

The Reblaze team will set up a new 2.x console for you. Once this is done, proceed to Step 2.

Redis settings: If you already have a Redis server installed (which is usually true for Reblaze installations of v2.14 and later), you do not need to create a new one. If you do not have a Redis server setup, you will need to create one.

Step 2: Create New Deployment

Go to EC2 > Auto Scaling groups, see Launch template configuration ( zone , capacity, type, etc.)

Now go to EC2 > Launch Template Select your template. To create a new launch template version with a new image, click Actions > Modify template

On the screen that appears (below), provide a description of the image (version 2.18.0 was used as an example below):

Scroll further down the page and see the AMI details listed in the AMI from catalog tab:

Next, Reblaze deployment in the AWS marketplace must be set up.

Search for Reblaze and click on the first option.

Scroll down the page and click View CloudFormation Template.

Now click View Template in CloudFormation Designer.

In this template (below) you can see each region and its AMI.

Copy the AMI compatible with your region. (In our example we used the “us-east-1” AMI.)

Now, return to the Modify template window. Under AMI from catalog, select Browse more AMIs.

Paste the AMI in the search box. Choose the Reblaze image from among the search results.

Find and select the Reblaze image. Click Select.

In the Modify template window, add the new version to your catalog.

Click Create template version on the bottom right of the screen.

Your new version now appears under Launch template details.

Step 3: Set Up Canary Instance

Go to EC2 > Launch template and change the Default to the new version (2) Click Update.

Go to your AutoScaling group. In the Details tab, find Group details and click Edit.

Desired capacity must be increased by 100% . For example, if you have 2 servers, Desired capacity must be set to 4. Ensure that this amount does not exceed the Maximum capacity or it too will need to be increased.

Click Update (below).

Step 4: Verify Traffic Monitoring

On the EC2 > Auto Scaling groups screen, check the Instance management tab for the number of servers. Alternatively, you can check the number of servers on your console.

You should be able to see new servers being added with the new version.

Go to your Reblaze dashboard and confirm that you see the new instances and that traffic is routing through them and your sites are working as expected.

Step 5: Remove Old Servers

Once we verify the new servers are receiving traffic, the old version and its servers must be terminated.

Under the Auto Scaling group, Details tab, there is an Advanced configurations window.

Make sure Termination policies is set to Oldest Launch Template; if not, click Edit and change the policy.

Under the Details tab on the EC2 > Auto Scaling groups screen, locate the Group size options. Reduce the number of desired servers in group to the original amount.

Click Update. The servers attached to the older version will terminate.

Once you have completed the deployment process, this section will guide you through the process to complete the site setup and link your web applications to Reblaze.

Specify the Web Assets

1. Log into Reblaze. Enter your email address and password, and click the envelope icon to receive a one-time password (OTP). The OTP will go to the telephone number you gave when you created your login account.

2. Enter the OTP and click Log In. Your Reblaze dashboard appears.

3. From the navigation panel, go to Settings > Planet Overview. This shows all the sites and web applications defined within Reblaze. Note: Since the initial setup of a site or application is prone to error, Reblaze lets you create a new application only by copying an existing application and then editing the results. A new Reblaze deployment includes a default application for this purpose.

Click Duplicate on the row of the default application.

5. Enter the name of the new site or application.

6. Click Duplicate. The new site/application is created and opened for editing.

We will use the default Reblaze settings when appropriate.

• A note on load balancing: Please note that the load balancing parameters shown here are separate from the load balancer that you will set up in . The load balancing within Reblaze (which is defined here) is done to distribute scrubbed traffic across the servers within your network. The load balancing outside of Reblaze will dynamically create new instances of Reblaze as needed, in response to spikes of incoming traffic which has not yet been scrubbed. For more details about Reblaze settings, see Reblaze Deployment Terminology in the Reblaze user manual at

7. Under Host, enter the IP address for the upstream server. This is the server that Reblaze will sent the traffic after the traffic is scrubbed.

8. To add additional servers, click Add and enter the IP address for each one.

9. In the Domain Names box, enter the domain aliases for this site or application. Wild cards can be used.

10. (optional) To redirect all HTTP traffic to HTTPS, copy the return 301 https... command as described on the page into the HTTP Redirect Line box.

11. Click Save Changes.

12. You will be prompted to publish your changes to the cloud. Close the popup box and click Publish Changes. Important: After publishing, there will be a message at the bottom that the changes are being published to the cloud. Do not refresh or leave this page until the publishing process is finished.

13. By default, a new application is set to report only mode. In this mode, Reblaze does not filter any traffic. It only reports on traffic that would have been filtered if it were in active mode. This is useful if you want to test or fine-tune an application or new deployment. To move an application to active mode, click the REPORT button to toggle it to ACTIVE mode, and then publish the change.

Sign up to Google Cloud Platform marketplace

To sign up to Google Cloud Platform marketplace you will need a GCP account and a project already set up within your account.

• Start by searching for "Redis" and then select Memorystore.

• Enable this option when the screen below appears. The process takes several minutes to complete.

• When Memorystore has been enabled, the following window appears. Select Marketplace.

• This will bring you to the Marketplace where you will search for "Reblaze." There will be multiple results to your search. Select the option shown below.

Selecting the Reblaze option shown above will bring you to a window where you select Launch.

Set up Deployment

1. On the next window that appears, specify a deployment option. Select License ID and click the Get License link which appears.

2. This will open a new tab showing the Reblaze License Manager. Here, choose Sign Up and then enter the requested information.

• Ensure your email and phone number are valid. They will be needed later on.

• Note that your phone number must be entered using the international format: the "+" sign followed by the country code, area code and number (no spaces or hyphens; for example, a US number: +17891234567). The phone number must be able to receive text messages.

• When you have finished, select Sign up.

3. In the next window of the Reblaze License Manager, specify a password and select Set password.

Now, sign into the Reblaze License Manager with the credentials you just created. This is where you will create your licenses for Reblaze.

• Note that a separate license is needed for each Reblaze console. If you have multiple environments but wish to use only one Reblaze console, you will need just one license. But if you wish to have multiple consoles you will require multiple licenses.

• For each license needed, select the Generate new license button (see below).

4. Now, select the License ID you want to use and copy it to the clipboard.

5. Return to the GCP console and enter that License ID.

6. Scroll further down in order to review the default values for the new deployment, then select Deploy. This will transfer you to a page displaying the progress of the deployment.

7. When deployment is complete, select LOG INTO THE ADMIN PANEL. You will be redirected to the Reblaze Login page.

8. Enter the Login credentials you defined earlier. The account details will be filled in automatically.

9. Select Complete Deployment.

Now, the remaining deployment steps and console creation will occur, which take a few minutes. When the steps have been completed, you will see a notification on the screen informing you that Reblaze is setting up more things in the background.

Once you have received notification on your screen that this process is complete, you will be brought to the Reset My Password page.

1. Enter your email address and click Reset My Password.

2. This will bring you to the Log In screen.

3. Do not fill in the fields on the Log In screen.

• Wait for the email Reblaze will have sent you containing a link to the Reset Your Password screen.

  • Create a new password and click Reset My Password.

  • You will be redirected to the Reblaze console Log In screen. From here you may begin setting up your sites and web applications within Reblaze.

Once you have completed the deployment process, this section will guide you through the process to complete the site setup and link your web applications to Reblaze.

Specify the Web Assets

1. Log into Reblaze. Enter your email address and password, and click the envelope icon to receive a one-time password (OTP). The OTP will go to the telephone number you gave when you created your login account.

2. Enter the OTP and click Log In. Your Reblaze dashboard appears.

3. From the navigation panel, go to Settings > Planet Overview. This shows all the sites and web applications defined within Reblaze. Note: Since the initial setup of a site or application is prone to error, Reblaze lets you create a new application only by copying an existing application and then editing the results. A new Reblaze deployment includes a default application for this purpose.

4. Click Duplicate on the row of the default application.

5. Enter the name of the new site or application.

6. Click Duplicate. The new site/application is created and opened for editing.

1. We will use the default Reblaze settings when appropriate.

   • A note on load balancing: Please note that the load balancing parameters shown here are separate from the load balancer that you will set up in . The load balancing within Reblaze (which is defined here) is done to distribute scrubbed traffic across the servers within your network. The load balancing outside of Reblaze will dynamically create new instances of Reblaze as needed, in response to spikes of incoming traffic which has not yet been scrubbed. For more details about Reblaze settings, see Reblaze Deployment Terminology in the Reblaze user manual at .

2. Under Host, enter the IP address for the upstream server. This is the server that Reblaze will sent the traffic after the traffic is scrubbed.

3. To add additional servers, click Add and enter the IP address for each one.

4. In the Domain Names box, enter the domain aliases for this site or application. Wild cards can be used.

5. (optional) To redirect all HTTP traffic to HTTPS, copy the return 301 https... command as described on the page into the HTTP Redirect Line box.

6. Click Save Changes.

7. You will be prompted to publish your changes to the cloud. Close the popup box and click Publish Changes. Important: After publishing, there will be a message at the bottom that the changes are being published to the cloud. Do not refresh or leave this page until the publishing process is finished.

8. By default, a new application is set to report only mode. In this mode, Reblaze does not filter any traffic. It only reports on traffic that would have been filtered if it were in active mode. This is useful if you want to test or fine-tune an application or new deployment. To move an application to active mode, click the REPORT button to toggle it to ACTIVE mode, and then publish the change.

This guide will walk you through the process from the first access of the marketplace until Reblaze is successfully deployed and protecting your website. We offer our help at any step of the process at .

Before carrying out your first deployment, we suggest that you watch these videos to better understand the onboarding and deployment process.

The process for onboarding Reblaze in GCP includes the following steps:

Last Steps

Route your traffic to the load balancer

At this point, your deployment and setup are complete. To see the IP address of the new load balancer: from your , select Navigation menu > Network services > Load Balancing and then click the name of the load balancer to see its details.

Now test to check whether your website works correctly when routing traffic to the Reblaze deployment. Perform offline testing by modifying your hosts file to point your website to the load balancer. If you see that you are returned to your website, routing via Reblaze is working correctly.

The last remaining step is to route your traffic to the load balancer, which will send it to your Reblaze instance(s). Reblaze will scrub the traffic and forward it on to your servers. To setup this routing, set your DNS record to the IP address that is resolved from the load balancer DNS Name.

Activate Reblaze Traffic Filtering

Going Forward: Customizing Reblaze

As you might notice from looking through the interface, the Reblaze web security platform is both powerful and highly customizable, with the ability to be fine-tuned for your specific needs. However, it is beyond the scope of this document to describe this customization process. Furthermore, a full and correct customization is often rather daunting for new users.

Now that you have configured the Reblaze platform, you should set up GCP health checks and then load balancers.

Create Health Checks

1. In your , select Navigation menu > Compute Engine > Health checks.

2. Set up the port 443 HTTPS health check:

   1. Click Create health check in the toolbar on the top of the page.

   2. Enter a name for the health check. For example, use healthcheck-443 for port 443 (HTTPS).

   3. For protocol, select HTTPS.

   4. For Request path, you can use the same one that was used for the HTTP health check.

   5. The remaining default values are usually reasonable and you can leave them as is, or you can change these values according to your requirements.

   6. Click Create.

Continue to .

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.

Once you set up the load balancers (LB), traffic will be routed through them to Reblaze. Using these load balancers allows GCP to create more instances as needed to handle the traffic.

1. First, set up a load balancer and choose the HTTP protocol for the backend service as follows:

   1. Create an HTTP or HTTPS load balancer

   2. Create the backend service

   3. Select host and path rules

   4. Select frontend configuration

   5. Complete the load balancer creation process

2. When an HTTPS ( port 443 ) is required, create an additional load balancer and choose the HTTPS protocol. The steps for this are the same as creating an HTTP LB, with additional steps within the frontend configuration process.

3. After you have created the required load balancers, return to the main GCP section for the final steps needed to get Reblaze running on your website.

Create a Load Balancer

1. In your Google Cloud Platform Console, select Navigation menu > Network services > Load Balancing.

2. Click Create load balancer.

3. Click Start configuration for the appropriate type:

• The HTTP(S) load balancer supports ports 80, 8080, and 443, (including HTTP and HTTPS) and is the appropriate type for most Reblaze customers.

If you need non-standard ports, then use the TCP load balancer instead.

4. You will now be asked whether this load balancer is for Internet facing or internal only. Select From Internet to my VMs and click Continue. The load balancer creation page appears.

5. Enter a name for the load balancer. We recommend that you include the protocol of this load balancer as part of the name (HTTP or HTTPS), for example, LB1-http or LB2-https.

Continue to the section below: Create the Backend Service.

Create the Backend Service

2. Enter a name for the backend service. We recommend that you include the protocol of this load balancer as part of the name (HTTP or HTTPS), for example, BE1-http or BE2-https.

4. In the New backend fields:.

   1. Select the Instance group that was created when you deployed Reblaze in GCP. The same instance group can be used for both HTTP and HTTPS.

   2. In the Instance group has named ports popup, make sure to select the correct port for each protocol (80 or 443). 80 is the default value.

   3. Click Use selected port name

   4. Select the Port numbers. Make sure that the port number selected matched the protocol that this LB is for.

   5. For Balancing mode, select Rate, and enter 1000000 for Maximum RPS. This ensures that all servers stay available during a traffic spike unless a health check indicates otherwise.

   6. Click Done for New backend.

5. (optional) Enable Google Cloud CDN.

6. Select the Health check that you previously created for this protocol. Make sure to use the matching health check that was created for the load balancer you are now creating (HTTP or HTTPS).

7. Review the remaining values on the page to see that they are appropriate for your application environment.

8. Click Create for the backend service.

Select Host and Path Rules

A default host and path rule has already been created. Additional rules are optional.

Select Frontend Configuration

2. Enter a name for the frontend. We recommend that you include the protocol of this load balancer as part of the name (HTTP or HTTPS), for example, FE1-http or FE2-https.

3. For Protocol, select the protocol that was created for the load balancer you are now creating (HTTP or HTTPS). HTTP is the default value.

4. For most use cases, you will want to reserve a static IP address.

   If this is the first load balancer you are creating (usually HTTP), for IP address do the following:

   1. Select Create IP address.

   2. In the Reserve a new static IP address dialog, enter a name. The name for this IP address should not have the protocol embedded within it, since it will be the same for all load balancers that you create.

   3. Click Reserve. GCP will reserve an IP address and it will now appear in the IP address field in the frontend configuration panel. Tip: Make a note of the IP address provided by GCP. You will need it later at the end of the configuration process.

   If this is an additional LB (usually HTTPS):

   • For IP address, select the IP address previously created for the first LB.

5. HTTPS only: If this load balancer is for HTTPS, you need to add or create a SSL certificate.

   1. For Certificate, select Create a new certificate.

   2. Enter a name for the certificate.

   3. You can either use a certificate you already have, or create a new one:

   4. To use an existing certificate:

      • Enter the certificate information.

      • Click Create for the certificate..

   5. To create a Google-managed certificate:

      • Select Create Google-managed certificate.

      • Enter the domains to which this certificate will apply. Multiple domains can be entered.

      • Click Create for the certificate.

6. Click Done in the Frontend configuration panel.

Complete the Load Balancer Creation Process

• Once you have completed all the required components for the load balancer, click Create in the Load balancer panel. The load balancer is then created. The IP address provided is the destination for your website traffic.

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

Common grid-based administration

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

The grid provides several administrative actions.

Add entry

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

Edit entry

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

Find entries

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

Sort entries

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

Grid details page

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

The component header includes the following 3 blocks:

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

2. Entry selector (the dropdown on the right)

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

Main info

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

Entry selection

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

Actions block

The actions block usually consists of at least 3 buttons:

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

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

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

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

Autocomplete dropdowns

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

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

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

Action Response

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

1. 503 Service Unavailable

2. Challenge

3. Tag Only

4. Redirect

5. Request Header

6. Response

7. Ban (not available in Tag Rules)

503 Service Unavailable

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

Challenge

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

Tag Only

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

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

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

This is the default action for Tag Rules.

Redirect

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

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

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

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

Request Header

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

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

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

Response

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

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

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

Ban

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

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

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

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

Links to URLs

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

Procedure Overview

Procedure Details

Step 1: Console Creation by Reblaze

The Reblaze team will set up a new 2.x console for you. Once this is done, proceed to Step 2.

Step 2: Create New Deployment

Go to the Marketplace and create a new Reblaze Deployment in version 2.x.

For the Deployment type, make sure to select “New region”.

For the Template resource zone, select the same region as the one in the previous installation. (Otherwise, the upgrade will not work.)

Scroll further down the page to the following:

For the Networking region, select the same region as the one in the previous installation. (Otherwise, the upgrade will not work.)

Auto-scaling settings - Minimum number of instances: At least as many instances as in the previous installation. In any case, it should never be less than 2 instances.

Redis settings: If you already have a Redis server installed (which is usually true for Reblaze installations of v2.14 and later), you do not need to create a new one, so you can uncheck the Redis deployment checkbox.

After choosing these settings, click the Deploy button at the bottom of the page.

Once your setup is complete, notify Reblaze support. Reblaze personnel will ensure the console is seeing the new instance group, and will connect the Redis server to it.

Step 3: Setup Canary Instance

Within your GCP console, go to Instance groups and select your current (i.e., the older version) instance group.

Here’s an example where the current group is 6887:

Select it by clicking on its name. The following screen will appear:

Now click on Update VMs. to see the You’ll see this:

Click on Add a Second Template. Add the new template you created. (In this example, the new template is 2354.) Now click on Update VMs.

Click on Add a Second Template. Add the new template you created. (In this example, the new template is 2354.) Now click on Update VMs.

Step 4: Verify Traffic Monitoring

Go to your Reblaze dashboard, and make sure that you see traffic in the new instances, and that your sites are working as expected.

Step 5: Remove Old Template

In your GCP console, delete the template for the old version.

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.

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.

This section defines the parameters with which Reblaze scrubs traffic.

The user interface is divided into these sections:

1. : Thresholds for banning sources of hostile traffic.

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

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

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

5. : Settings for assigning to incoming requests.

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

7. : 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 "" discussion on the next page of this Manual.

Some security entities (Profiles, Rate Limits, etc.) are marked with icons. That means it is a Reblaze-managed default entity, and it cannot be edited or deleted. If you do not wish to see these in the interface, you can hide them with the checkbox at the top of a page.

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. Even if they violate a Dynamic Rule, 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".

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.

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.

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

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.

As mentioned earlier in Security Section Concepts, 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 Policies and Rules by which Reblaze will process your incoming traffic. Once an ACL Policy has been defined, it is available to be part of a Security Profile. Once a Security Profile has been defined, it is available to be assigned to specific resources (e.g., a section of your website) in the Web Proxy page.

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.

ACL Management

Admins can create new ACL Policies, as discussed below. Admins can also edit many of the ACLs that are included out of the box in a new deployment.

ACL Administration

To create a new ACL, select the Create New button toward the top of the screen, then choose "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 are being deprecated. Tag Rules 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.

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.

WAF/IPS Management

Admins can create new WAF/IPS Policies, as discussed below. Admins can also edit many of the Policies that are included out of the box in a new deployment.

WAF/IPS Policy Administration

To create a WAF/IPS Policy, select an existing one and choose Duplicate, then edit the newly-created copy.

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.

Overview

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

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

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

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

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

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

Custom Signature Management

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.

Admins can create new Custom Signatures, as discussed below. Admins can also edit the Signatures that are included out of the box in a new deployment.

Custom Signature Administration

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

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.

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.

Custom Signature components

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.

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

Existing Profiles are shown on the left.

Profile Management

Admins can create new Security Profiles, as discussed below. Admins can also edit the Profiles that are included out of the box (e.g., SP Default) in a new deployment.

Profile Administration

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 to the Profile, 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.

The Arguments Analysis feature has two primary functions:

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

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

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

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

For both functions, an argument list must be built.

Building an Argument List

Initially, this section will look like this:

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

Automatic Argument Learning

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

Manual Argument Addition

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

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

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

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

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

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

Argument List Administration

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

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

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

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

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

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

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

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

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

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

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

Once Argument Lists Are Built

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

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

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

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

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

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

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

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

New Args Adaptive Mode

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

Automatic

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

Supervised

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

Locked

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

Preview

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

Handling Requests with Unmatched Characters

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

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

Inspect Unknown

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

Strict Whitelist

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

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

Conflicted Arguments

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

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

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

• Deleting

• Modifying

• Accepting

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

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

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

Unchanged Arguments

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

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

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

Overview

Early in the (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 .

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

Each Tag Rule consists of:

• Match conditions: A description of possible characteristics that a request can match (e.g., a list of IP addresses that it might originate from).

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

• An Active toggle to enable the Rule.

• An Action to take immediately when a match occurs. Other Actions might be taken later as well; more on this below.

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

Two Types of Tag Rules

Tag Rules can be either Reblaze-managed or self-managed.

• Reblaze-managed Rules are maintained by Reblaze. Most of these are based upon online data feeds (e.g., Spamhaus DROP lists), and are updated frequently and automatically. The match conditions for these rules are not editable in the interface, although the remaining parameters (Active, Tags, Action, etc.) still are.

• Self-managed Rules are created and managed by admins. These Rules are fully editable within the interface.

Administration

The main window (shown above) lists all current Tag Rules.

To edit an existing Rule, select the Edit icon at the end of its entry in the list. To delete a Rule, select the Edit icon, and then within the window that appears, select the Trash icon.

To add a new Rule, select the + button in the main window, or edit an existing one and choose the Duplicate button at the top right.

The discussion below will focus on self-managed Rules. For Reblaze-managed Rules, the parameters that are editable will work the same as discussed below.

Editing a Tag Rule

General Parameters

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

• Active. By default, this Rule will be evaluated for all incoming requests. To prevent this, unselect the checkbox.

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

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

Action Parameter

The Action that is selected here will be applied globally to all requests that match the Match Conditions.

To apply an Action to only some of the matching requests instead:

• Choose the Tag Only Action and an appropriate Tag

Match Conditions

Match conditions consist of two parts:

• A list of one or more criteria to match.

• If the criteria are organized into multiple sections, the Entries Relation specifies the logical condition to apply (either OR or AND) among the sections.

Match Criteria for a Rule based on an external data feed

Some Tag Rules are based on external data feeds. (Many of the Reblaze-managed Tag Rules fall into this category.)

Enter the URL of the data feed into the Source field, then select the update now button that appears. Reblaze will then populate the criteria list automatically.

If the criteria are organized into multiple sections--which is unlikely for a feed-based Tag Rule, but not impossible--also choose the appropriate value for Entries Relation, as discussed below.

Match Criteria for a Rule based on custom criteria

Many Tag Rules will be based on specific criteria for a use case--criteria that are not found in an external feed.

To add match criteria, select the Create new section button. (If this button is not available, verify that the Source field is set to self-managed.)

A new section of criteria will be available, and the following dialog will appear.

For most of the criteria 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 fields. 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.

Multiple sections and the Entries Relation parameter

The first criterion added to a Tag Rule will be in one section. If additional criteria are added, they are all evaluated with an OR. (For a request x and list of criteria a, b, c , the evaluation will be (x==a) OR (x==b) OR (x==c) ).

You can add additional sections by selecting the Create new section button. Each section will similarly use OR internally.

However, when there is more than one section, an additional evaluation must occur among the results of the individual sections. The Entries Relation selector specifies the logical operation used here.

Example: there are two sections. The first section has criteria a, b, c and the second has i, j, k . The Entries Relation is set to AND. For a request x, the evaluation will be ((x==a) OR (x==b) OR (x==c)) AND ((x==i) OR (x==j) OR (x==k)).

Rate limiting restricts the rates at which traffic sources can send requests. When a limit is exceeded, the defined action is enforced.

Rate Limit Management

Admins can create new Rate Limit rules, as discussed below. Admins can also edit the rules that are included out of the box in a new deployment.

Rate Limit Rule Administration

Existing rules are listed on the page shown above. To edit or delete a rule, select the "edit" button at the end of its listing.

To add a new rule, select the + button. The following window will appear.

After defining a new Rate Limit, select the Save button at the top of the window. An additional section (Links to URLs) will then appear at the bottom of the window. This will be discussed later.

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 is a unique option for Rate Limiting, and is described in detail below.

The Ban action

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

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

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

Assigning Rate Limit Rules to URLs

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

The number represents the number of URLs to which this Rule is currently assigned. URLs are linked after a new Rule is created, or they can be added later when editing an existing Rule.

URL linking is done at the bottom of the rule editing window:

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

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 .

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.

The Settings section has an extensive number of configuration values for Reblaze. Many of these are parameters that once set up, usually will not change during your use of Reblaze.

There are several 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 for managing the services that Reblaze is protecting.

is for defining the error pages served to traffic sources.

is where SSL Certificates are uploaded and managed.

is where DNS records are configured.

allows you to purge CDN caches.

provides the abilities to add/manage sites to your planet, generate SSL certificates, and publish changes that were made elsewhere in the interface.

is for managing planet-wide settings.

is where your user account settings are managed.

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