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:

• Class

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

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.

Class

If you selected Class, enter one of these strings as the Match Argument:

• anon-proxy

• bot

• cloud

• tor

• vpn

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

Video demo

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.

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

3. WAF/IPS Policies

4. Custom Signature

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

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.

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.

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

Just like ACL Policies, WAF/IPS Policies are included in Profiles. 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:

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

Below the modules is the list of Allowed HTTP Methods. In general, you should enable as few of these as possible, and then disable the rest.

Sometimes there are methods that are used only by a few specific users. A possible approach for this situation is to disable those methods here, and then define ACL Policies or Signatures by which those specific users are Bypassed from being blocked by this module. This strategy works, but it should only be done in deployments where the specific users can be reliably identified.

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.

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.