ACL Policies
Access Control List Policies
Access Control List Policies
The ACL Policies section allows you to define Policies and Rules by which Reblaze will process your incoming traffic. Once an ACL Policy has been defined, it is available to be part of a Security Profile. Once a Security Profile has been defined, it is available to be assigned to specific resources (e.g., a section of your website) in the Web Proxy page.
In the discussion below, "ACL" and "ACL Policy" refer to the same thing: the Policies that can be administered in this section.
Existing ACLs are listed on the left. Selecting one will display it in the middle of the screen for editing.
Admins can create new ACL Policies, as discussed below. Admins can also edit many of the ACLs that are included out of the box in a new deployment.
Out of the box, many of the included ACLs are named with a prefix of ACL. This naming convention is recommended when creating/editing new ACLs, but it is not mandatory.
Several of the Reblaze-maintained ACL Policies are templates (designated by the prefix ACLT). If you do not wish to see them on this page, they can be hidden by selecting the Hide Templates checkbox on the upper right. These templates are used by the Create New Site wizard, and can also be assigned to other sites/applications by admins in the Security Profiles section of the Web Proxy page.
To create a new ACL, select the Create New button toward the top of the screen, then choose "ACL Policy." Or, duplicate an existing ACL and then edit the newly-created copy.
Each ACL contains one or more Rules. These are listed in the middle of the screen. To create a new Rule and add it to the current ACL, use the settings on the right part of the screen. (See below for more on this.) When you are finished with the Rule setup, click on the Add button. The Rule will be added to the Policy that you are currently defining or editing.
To remove a Rule from a Policy, click on the "X" to the right of its name.
Each of these fields is explained further below.
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.
There are five available options for Match:
Tag
Company
Country
IP Address
Custom Signature
The first four of these are common matching conditions that are always available. The fifth choice allows you to select custom matching conditions that you constructed by using the Custom Signature feature (however, note that Custom Signatures are being deprecated. Tag Rules should be used instead).
This is the third, unlabeled field in the New Rule dialog. The correct entry will depend on the option that was selected for Match.
If you selected Tag, enter one or more tags as the Match Argument.
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.)
Enter the specific IP or range of IPs (e.g., 178.184.0.0/16).
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.)
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.
Some ACLs are provided and maintained by Reblaze, and are read-only. These are designated by the Reblaze icon. They are updated as necessary with no action required on your part. (Typically these include dynamic elements that need frequent updating—for example, a list of IP addresses with a recent history of malicious activity.)
Fields
Description
Operation
The action that will result when the Rule’s Match condition occurs.
Match
The type of parameter that will be tested to see if a Match occurs.
(unlabeled)
The value for the Match condition.
Suffix
Description
Examples
OC
Over-capacity override: ignore rate limits.
Loadtest OC
XDeny
"God Mode": bypass the Rule Operation hierarchy.
Global DR XDeny