Link11 offers a network security software suite, including robust WAAP (Web Application and API Protection). In this documentation, the platform will be referred to as Reblaze.

Welcome!

Link11 offers an all-in-one web security platform, referred to in this documentation as Reblaze. 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.

The Traffic section allows you to monitor your network activity on a monthly, weekly, daily, hourly, or even minute-by-minute basis. It contains two primary sections: the Dashboard and View Log.

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

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

Before diving into the interface, it's helpful to first read

This section defines the parameters with which Reblaze scrubs traffic.

The user interface is divided into five sections:

1. Static Rules: Security settings that apply to your entire planet.

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

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

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

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

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.

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

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

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

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

This section describes best practices for some common tasks.

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

There are five sections in this part of the interface.

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

SSL Management is where SSL Certificates are uploaded and managed.

DNS is where DNS records are configured.

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

Account is where your user account settings are managed.

This section answers questions that often arise about using Reblaze.

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

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

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

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

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

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

Explanation:

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

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

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

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

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

In a typical deployment, Reblaze performs much of its traffic evaluation according to security Profiles.

Within the Reblaze user interface, there are four sections for defining Profiles:

1. Profiles

2. ACL Policies

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

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

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

Existing Profiles are shown on the left.

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

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

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

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

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

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

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

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

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

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

Secure data streaming

Reblaze sends logs over TLS using the Syslog protocol.

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

Global: The settings apply to your entire planet.

By location: Rate limits for specific locations/URLs can be created by defining the locations within , and selecting "More" at the end of each location's entry in the list. See full explanation here: .

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

For mobile/native applications, Reblaze authenticates the client itself and all communication with it.

At Reblaze, we provide an SDK (for both Android and iOS) to our customers, who rebuild and publish their applications with the SDK embedded. In use, it signs the application, authenticates the device, and verifies user identity.

All communications occur over TLS and include an HMAC signature (a cryptographic identity mechanism on the client side) to harden communications between the mobile/native application and the microservice/API endpoint. The signatures are non-reproducible, non-guessable, non-repeating (they are unique per session and per request), and are based on dozens of parameters (time-based, location-based, environment-based, and more). They provide a reliable, secure mechanism to verify that the packets are originating from a legitimate user, and not from an emulator or other bot.

Instructions and code samples for the Reblaze Mobile SDK are available here:

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

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

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.

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)

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, while adding three additional benefits:

• They enable : 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:

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.

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

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'll be redirected automatically to the Web Proxy screen, where configurations are made on the selected application.

There are two settings to configure, and a third that's optional:

1. Set the IP address of your servers under "Host".

2. Set the Domain Names of your aliases.

3. (Optional) Add a command line to redirect all HTTP requests to HTTPS.

Before proceeding, click on "Security Profiles" to check for the default settings. These are recommended by Reblaze for initial operation. Further changes are recommended only after taking a careful look at the section discussing "Security Profiles", which you can find .

Click on "Save Changes" and "Publish Changes" to complete the process.

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.

Adding an existing SSL Certificate to Reblaze

1. Add your certificate as explained under .

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

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

Generating a new SSL Certificate

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

2. Create a certificate using the "Gen Cert" button in the section (see image below).

3. In the Planet Overview section, publish your changes as explained previously.

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

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

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

Analyze Traffic Log

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

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.

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.

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:

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.

To see full log details for an entry, click on the small magnifier on the right side of the log. This will show all the headers, cookies, and session details.

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

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

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.

When Reblaze receives an incoming request, it decides whether to pass the request through to the upstream server, or block it.

This decision-making is done in several stages.

Some of the criteria for the decisions are global. In other words, they apply throughout your entire planet. For example, the settings in the section are globally applicable, and do not change depending on the context of the request. They will be applied to all traffic for all resources within your planet.

Conversely, some criteria are non-global, and they do depend on the context. For example, you can assign different security rulesets for different resources or locations within your planet. In other words, you can assign different rules to specific domains, subdomains, folders, filetypes, etc.

These non-global criteria are primarily defined within the section. They have their own structure, explained in more detail in that section of this Manual (see especially the page).

Once Profiles are defined, they are available to be assigned to specific resources/locations within your planet. Those assignments are done in the section.

Overview

The Application Profiles tab allows you to set appropriate security behaviors for your web applications.

Before configuring, ensure that the correct site is selected via the dropdown list at the upper right.

To add an entry to the list, click on the "+" button. To delete an entry, click on the "Remove" link next to its name.

Here are the fields for each Application Profile.

Purge Cache

If you'd like to clear cache on one of your websites on the platform, you can click the "Purge" button. Usually, the action takes around 5 minutes.

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

Custom Signatures are a powerful method for specifying content restrictions for traffic. They are included within ACL Policies, which are used within Profiles, which are assigned to various locations of your site/application at Settings->Web Proxy->Security Profiles.

A more direct method is to create content filters directly for a location. This too provides powerful filtering capabilities. Here's a comparison between this and Custom Signatures.

• Both can deny requests based on their content.

• Location-based filtering makes it easier to require certain content in incoming requests.

• Location-based filtering is simpler when setting up different filters for different locations.

• Custom Signatures are modular, and once defined, they can be re-used in multiple places throughout the interface. A location-based filter definition cannot do this. Instead, you have to manually define the filtering conditions for each location.

can be used to rate-limit a requestor, based on the content that is requested.

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

Reblaze does not limit its traffic analysis to the user environment and client session. It also performs extensive, continual analysis of the user’s behavior.

Every HTTP request that Reblaze receives is anonymized and then analyzed according to numerous factors, including (partial list):

• Device and software data (the user’s hardware, its screen resolution and orientation, the software used, battery level, stack trace, fronts and extensions, emulator detection, window size, hidden iframes, etc.)

• User interface and events (mouse/pointer movements, clicks, taps, zooms, scrolls, keystrokes, speed of entry, etc.)

• Session data (requests sent, IPs used, timing, frequency, etc.)

• Consumption analytics (pages viewed, time spent, resources requested, etc.)

• Application-specific events (and other results of user actions.)

Reblaze understands the patterns, typical values, and common relationships of these metrics for legitimate users of each protected application and API. The amount of data that Reblaze processes (over four billion requests per day) is far beyond the capability of human analysts. Therefore, cloud-based compute resources are used, applying Machine Learning in order to recognize patterns that analysts could not have identified on their own, or for which they might not have thought to look.

Reblaze performs this analysis to an extremely granular level: not only per app, but even down to individual pages, screens, and so on. This reveals patterns of behavior unique to that particular context.

Reblaze continually analyzes the activities and behaviors of every requestor in every session. By definition, every hostile user (whether human or bot), must, at some point, deviate from the behavior of a legitimate user. As soon as this occurs, Reblaze blocks that requestor.

Using this approach, Reblaze’s bot detection accuracy is not only high, it is also robust and resistant to reverse-engineering by threat actors. Behavioral profiles are constructed based on private analytics data, and threat actors have no realistic way of obtaining this information.

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

Saving Changes

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

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

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

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

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

Publishing Your Changes

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

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

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

Publishing is done on the Planet Overview page, via the button on the upper right. The status of the Publishing process will appear on the bottom right part of the screen.

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

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

The hierarchy has several levels:

• Profile

As described in , out of the box Reblaze includes an Active Challenge process. This is very useful in distinguishing humans from bots.

Active Challenges work well, but an even better option is Passive Challenges.

• Active Challenges temporarily redirect the user's browser. This can affect site metrics gathered by products such as Google Analytics. (Specifically, the initial referrer information is lost.) Passive Challenges are simple pieces of Javascript. They do not redirect the user's browser; they merely ask it to solve a challenge, and then insert the Reblaze cookies.

• Active Challenges will not occur when site content is served from a CDN. Passive Challenges can still detect bots in this situation.

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

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

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

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

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

When a new user session is initiated, RCSI detects and verifies the authenticity of the environment.

1. The user’s browser is subjected to several dozen tests, verifying the features known to be supported by that browser. This includes hidden canvases, video and audio in various formats, WebRTC and other advanced networking protocols, screen resolution, and more.

2. The browser is subjected to an invisible “attack”: subtle errors are injected into the environment, and the browser engine’s reactions are captured and analyzed. Reblaze verifies that the exceptions and error messages are those which should be generated, if the browser is what it claims to be. (It is very difficult for threat actors to spoof this behavior using headless browsers and emulators, since there is an infinite number of possible errors to which any browser can be subjected, and threat actors need to replicate the actual reactions for each possible input.)

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

How to ban a requestor

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

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

Upstream Servers: The list is where you define the servers that Reblaze will protect. In other words, these are the servers to which Reblaze will send the (scrubbed) web traffic it receives.

This list provides robust capabilities for managing your traffic. You can enable and configure load balancing, which will weight and distribute traffic across your primary servers. You can define backup servers, to which Reblaze will failover your traffic when your primary servers aren’t available. You can take servers offline for maintenance by ticking a single box in the interface. You can even tell Reblaze to keep individual users connected to the same server throughout their sessions.

Adding and deleting servers from this list is straightforward. To add a server, enter its IP in the “New Server” box and click Add, then fill out the rest of the information in the new entry. To delete an existing entry, click on the Delete link next to that entry.

Here are explanations for each field in this list.

Host is the IP/FQDN for each server that Reblaze protects. This can be a normal web server, or it can be a load-balancing server. Note that Reblaze also provides load-balancing capabilities in its own right, as seen in the next field.

Weight is the relative weight of each server for load balancing purposes. Reblaze distributes traffic with a round-robin sequence, according to these weights.

For example, let’s say there are two servers in the list, with the weight of each servers set to one. Therefore, these servers will receive equal amounts of traffic. Suppose instead that the first server was set to three, while the second was set to one. This would mean that the first server would receive three visitors for every visitor sent to the second server.

Max Fails is the maximum number of failed communication attempts that are allowed for this server. Once this number of failures occurs, Reblaze will consider the server to be inactive. If other servers are available, Reblaze will failover the traffic to them. If this was the only server available, Reblaze will return an error to the client (either 504 Timeout, or 502 Bad Gateway).

Fail Timeout: When a server fails, this is the length of time that Reblaze will wait before trying to send traffic to it again. In the example, the timeout is ten seconds.

Is Down: When this box is checked, Reblaze will not attempt to communicate with this server. This allows you to easily take a server offline for temporary maintenance or some other purpose.

Is Backup: when this box is checked, Reblaze will treat this server as a backup. In other words, Reblaze will not attempt to communicate with it unless all the primary servers (i.e., those for which this box is not checked) are unavailable.

Overview

The quarantined section will show requestors that have been banned for violation of the Dynamic 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 Dynamic 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. For example, even if they violate a rate limit, they will not be banned.

Managing Requestors on the Lists

On the right part of the screen is the section menu, invoked via the button with three vertical dots:. Depending on context, the section menu will offer the management abilities described below.

Adding an Entry

Banlist and Simulation Banlist

Requestors are added to the Banlist and Simulation Banlist automatically when they violate a Dynamic 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.

2. Open the section menu by clicking on its button ().

3. Choose "Delete".

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

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

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

On the Application Profiles page, the Cache Operation Mode is where you define Reblaze's caching behavior. There are several aspects to this:

• Whether Reblaze includes caching instructions in the response to the client.

• If so, whether they are the instructions from the origin server, or if Reblaze should override them and send different instructions instead.

• Whether Reblaze itself caches the response content.

Here are the Cache Operation Modes and their effects.

HTTP defines forty standard status codes that can be used to convey the results of a client’s request. The status codes are divided into the five categories presented below.

Below are examples of the most common HTTP codes you will encounter in the logs:

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.

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

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

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

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

Along with its , Reblaze includes WAF/IPS Policies. This section allows you to administer them.

Just like ACL Policies, WAF/IPS Policies are included in . Unlike ACL Policies, a Profile cannot contain more than one WAF/IPS Policy.

Existing WAF/IPS Policies are listed on the left side; selecting one will display its contents on the right for editing.

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:

Within the Reblaze interface, there are several features that require matching conditions to be specified.

The text boxes accept strings or PCRE (Perl Compatible Regular Expressions). If you are unsure of PCRE syntax, you can test your expression at sites such as , which will show you how it will be parsed.

Below are some examples of syntax for specifying matching patterns.

The following table includes a list of TTL expressions:

Reblaze is not a stand-alone platform; it is integrated with a dedicated support team which is available to you 24/7/365. Please contact us at any time if you need assistance.

Our support is not limited to daily operational use of our platform. We're happy to help with initial setup and configuration, ongoing administration, introductory or in-depth training, discussion of feature requests, and more.

Contact Information

You can contact support at any time via email: [email protected]

Or by phone: our international number is

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

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

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

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

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

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

For a detailed list of response codes, .

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

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.

Introduction

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

A note on certificates and sites

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

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

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

Section Overview

The SSL Certificate Management interface displays certificates according to the load balancer to which they are attached. Those stored in the Reblaze cloud are listed as "None."

Displayed parameters are:

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

Generating a new certificate

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

Adding an existing certificate to Reblaze

SSL certificates can be added to Reblaze in two ways:

• Uploading a PFX file.

• Manually entering the certificate information.

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

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

Selecting a load balancer

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

Specifying application(s)

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

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

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

Editing and managing existing certificates

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

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

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

• Replace existing certificates - When this is chosen, a "Select Certificate" dropdown list will appear. Selecting one and then clicking "Save" will result in all sites/applications being transferred from the selected certificate over to the certificate you're currently editing.

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

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

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

Automated renewal using Let's Encrypt

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

Once a day, Reblaze will check each application it protects. If that application's certificate is going to expire in the coming week, then the following process occurs:

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

• If the Auto Let's Encrypt Replacement option for that certificate is enabled, Reblaze will generate a new certificate using Let's Encrypt, and will attach all of its sites to the new certificate.

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

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

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

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

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

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

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

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

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

Possible entries for Either one of the following fields:

Entries in Is matching with

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

An explanation and some examples are here: .

Creating custom signatures

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

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

This section defines security ruleset parameters that apply to your entire Reblaze planet. They are "static" because they are simple settings, and do not vary according to context or circumstance.

The main page for this section has three tabs:

Introduction

The Reblaze system blocks traffic if it matches configured WAF signatures, exceeds triggering thresholds, matches ACL rules, or violates RFC specifications. When a blocking event occurs, Reblaze reports it according to reference IDs.

The reference IDs are listed below, categorized into groups according to their description. In some cases, external links are included with more details on the specific type of attack being described.

Introduction

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

For example, to view only traffic from IP 10.11.12.13:

ip:10.11.12.13

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

ip:!10.11.12.13

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

country:France, is:blocked

Building Queries Efficiently

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

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

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

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

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

A better approach is to choose a representative substring.

Examples:

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

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

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

Filter Use Cases and Examples

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

is:re(200|401)

ua:re(iOS!iPhone!iPad)

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

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

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

is:re(502|504)

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

arg_name:text, arg_value:free_text

Available filters

The Planet Overview page enables the following actions:

1. Managing your planet's sites/applications.

2. Configuring a site/application's health monitoring.

3. Making a site/domain active, or inactive (in "Report Only" mode).

5. Configuring Notifications and Alerts.

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

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

Adding a Web Application

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

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

• On the far right part of the screen, click on its "Duplicate" button.

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

Editing a Web Application

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

Making a site active or inactive ("Report Only" mode)

Each web application has two possible Security modes:

Generating a New SSL Certificate

Reblaze integrates with to provide free SSL Certificates.

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

• Generate a new certificate without attaching it to a site

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

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

Just choose the button for the activity you want.

Configuring Health Monitoring

In a typical deployment, incoming traffic is load-balanced, processed by Reblaze, and then (if it is legitimate) passed through to the upstream origin.

Load-balancing includes more than just equal distribution of loads; it also includes failover. To perform this correctly, the health of the upstream origin must be monitored.

In this section of the interface, you can define a URL within your site that can be queried by the load balancer. If the URL is accessed successfully, the site is assumed to be healthy and capable of handling a continuing load. If the URL is not accessed successfully, the site is deemed to be unhealthy; depending on the configuration, a failover process might then begin.

To set up health monitoring for a site, click on its "[Health] Monitor" button: . Doing so will open this dialog:

Here are the available settings. Check marks at the end of certain fields indicate that the entries are valid.

Reset States

This button resets the health statuses that are displayed in the interface. It does not trigger a health check; it merely resets the status displayed to the user.

For example, a user has disabled health monitoring for a particular upstream server. (Perhaps it has been intermittently failing its health check.) However, its most recent status was "failed," and so its IP address is appearing as red in the interface. To remove this distraction, the user clicks on Reset States. The IP address will now be showed normally.

Notification and Alert Settings

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

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

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

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

The settings for a Notification Group are as follows.

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

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

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

Motivation

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

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

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

Scope

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

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

Administration

As shown in the example screenshot, this page is divided into two sections. The upper section is blue, and lists two special resource recordsets: SOA (Start Of Authority) and NS (Name Server). These are at the Zone level, and once created, these cannot be modified. They also will not be filtered (hidden from view) by the "search" feature.

The "search" feature is based upon the text box at the upper left.

This will control the DNS entries being displayed, by filtering them according to the search value and selected record type. Note that filtering does not apply to the entries in the blue section; these will always be displayed.

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

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

Supported Record Types

Reblaze supports the following types of DNS records:

Expected formats for the respective values are given below.

A Record Type

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

Example:

example: 192.150.2.1

AAAA Record Type

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

Example:

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

CNAME Record Type

A CNAME value is a domain name.

Example:

www.sample.com

MX Record Type

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

Example:

10 mail1.sample.com

20 mail2.sample.com

NS Record Type

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

Example:

ns1.amazon.com

ns2.amazon.org

ns3.amazon.net

ns4.amazon.co.uk

TXT Record

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

Example:

"test1"

"test2"

SPF Record

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

Example:

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

SRV Record

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

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

Example:

2 12 5050 sip-server.example.com

3 15 5060 network.example.com

PTR Record

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

Example:

www.example.com

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

The Web Proxy section defines how Reblaze behaves in this role. It consists of three tabs:

This part of the interface allows administration of three categories of settings, for the site that is currently selected at the top of the screen:

1. Upstream Servers

2. Proxy Settings

3. Log File Parameters

At the bottom, it also provides from the planet.

Upstream Servers

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

Within these settings, you can:

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

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

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

• Instruct Reblaze to keep individual users connected to the same server throughout their sessions.

Adding and deleting servers from this list is straightforward. To add a server, enter its IP in the “New Server” box and click Add, then fill out the rest of the information in the new entry. To delete an existing entry, click on the Delete link next to that entry.

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

Proxy Settings

The Proxy Settings parameters define Reblaze’s behavior as a proxy, i.e. how Reblaze passes information back and forth between client and server.

Additional information

The Client’s IP Header Name (Upstream Side) setting defines how Reblaze passes the client's IP address to the upstream server. In addition to the IP, Reblaze also sends the client's geographic information (if it is available). The field names are:

Log File Parameters

The Log Files Parameters enables you to control the contents of the Reblaze-generated traffic logs.

Site Deletion

When you wish to remove a site from Reblaze, select it in the pulldown list in the upper right of the page. Then, at the bottom of the page, you will find a (disabled) Delete Site button.

To enable the button, check all three boxes next to it. (This is a safety measure to prevent accidental site deletions.) Once the button is enabled, clicking it will remove the specified site from Reblaze. Note that this action cannot be undone.

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

Reblaze REST API operations v2.x

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

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

Operations

List Sites

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

Duplicate Site

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

Remove Site

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

Set Names (domain aliases)

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

Add Names (domain aliases)

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

Get Names (domain aliases)

Returns the list of domains that a site supports.

List Upstream

Lists the upstream settings of a site.

Set Upstream

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

Encode the json with base64

Set the Upstreams

Add Certificate

Adds a new certificate to the .

Attach Certificate

Attaches a domain to a SSL certificate.

Detach Certificate

Removes an attached domain from SSL.

Publish Changes

Introduction

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

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

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

That page is available here:

Gaining General Insights

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

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

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

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

• Exclude health monitor checks: url:!/health.htm [the URL defined for the ]

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

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

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

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

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

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

Translating Encoding in Requests

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

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

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

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

For some forms of encoding, more processing is required.

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

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

In these cases, you can highlight the string in the query box, copy it, and run it through decoding tools. (For example, .)

False Positive Alarms

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

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

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

Determining if a block is a FP

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

Is Reblaze's configuration appropriate for the application?

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

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

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

Is the block happening to multiple users?

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

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

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

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

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

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

Is this a FP that resulted from incorrect user actions?

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

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

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

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

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

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

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

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

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

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

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

This can be decoded with a tool such as . It now becomes this:

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

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

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

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

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

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

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

Summary of FP Detection

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

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

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