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.

This section defines the parameters with which Reblaze scrubs traffic.

The user interface is divided into these sections:

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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

Creating a New Rule

Each of these fields is explained further below.

Operation

The Operation field has three possible values:

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

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

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

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

Match

There are five available options for Match:

• Tag

• Company

• Country

• IP Address

• Custom Signature

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

Match Argument

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

Tag

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

Company or Country

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

IP Address

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

Custom Signature

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

Special ACLs

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

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

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

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

Existing Profiles are shown on the left.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Possible entries for Either one of the following fields:

Entries in Is matching with

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

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

Creating custom signatures

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

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

Overview

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

Main Display

There are four lists of requestors in this section:

1. Banlist

2. Simulation Banlist

3. Blacklist

4. Whitelist

Each is described in more detail below.

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

Banlist

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

Simulation Banlist

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

Blacklist

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

Whitelist

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

Managing Requestors on the Lists

Adding an Entry

Banlist and Simulation Banlist

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

Blacklist and Whitelist

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

The fields are:

Transferring an Entry

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

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

2. Open the section menu.

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

Removing an Entry

Automatic Removal

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

Manual Removal

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

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

3. Choose "Delete".

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

Rate Limit Rule Administration

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

Defining a Rate Limit Rule

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

Each is discussed further below.

Meta Parameters

Rate Limit

Event Criteria

Event criteria have two components:

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

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

Composing Keys

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

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

Key Fields

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

Multiple Keys

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

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

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

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

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

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

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

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

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

So, the evaluation becomes something like this:

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

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

Including/Excluding Requests

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

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

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

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

Action

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

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

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

The Ban action

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

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

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

Assigning Rate Limit Rules to URLs

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

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

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

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

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

• Select a location from the pulldown

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

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

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

Overview

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

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

Each Tag Rule consists of:

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

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

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

Two Types of Tag Rules

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

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

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

Administration

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

Adding a Tag Rule

To add a Tag Rule, either:

The new Rule will be displayed for editing:

Enter values into the following fields:

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

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

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

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

Next, specify the match conditions, as discussed below.

Specifying Match Conditions

Match conditions consist of two parts:

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

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

Match Criteria for an Internet-sourced Profile

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

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

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

Match Criteria for a Self-Managed Profile

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

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

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

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

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

The Entries Relation Field

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

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

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

The Arguments Analysis feature has two primary functions:

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

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

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

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

For both functions, an argument list must be built.

Building an Argument List

Initially, this section will look like this:

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

Automatic Argument Learning

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

Manual Argument Addition

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

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

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

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

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

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

Argument List Administration

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

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

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

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

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

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

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

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

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

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

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

Once Argument Lists Are Built

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

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

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

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

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

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

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

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

New Args Adaptive Mode

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

Automatic

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

Supervised

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

Locked

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

Preview

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

Handling Requests with Unmatched Characters

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

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

Inspect Unknown

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

Strict Whitelist

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

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

Conflicted Arguments

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

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

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

• Deleting

• Modifying

• Accepting

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

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

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

Unchanged Arguments

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

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

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

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

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

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

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

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

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

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

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

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