ACL Profiles
Executing actions based on a request's tags
Last updated
Executing actions based on a request's tags
Last updated
When a request is processed by Reblaze, a number of tags are assigned to it during the early stages of the traffic filtering process.
As one of the final stages of processing, the relevant ACL (Access Control List) Profile for this request is evaluated.
The ACL Profile defines what will happen to a request, based on the tags that it contains. Admins can assign a variety of available actions that will be performed.
An ACL Profile is assigned to paths/URLs within applications and APIs via Security Policies.
When a request is received, the system checks its destination URL, and uses the ACL Profile that best matches it.
Out of the box, the system includes a default ACL Profile. It can (and usually should) be edited, but it cannot be deleted. It is used for all URLs where no other Profile has been assigned.
The main page lists all current ACL Profiles.
The administration (addition/deletion/editing/versioning) of Profiles follows the conventions described here.
Each ACL Profile consists of the following:
Six ACL Lists, shown in the UI as six columns organized into four sections. (These Lists are not labeled in the interface, but ACL Lists will be our designation here in the documentation.) Each List contains zero or more tags; these tags are compared to the request's tags. The first List with a matching tag causes an event to occur. See the full explanation of this process below.
An Action to execute under certain circumstances (see below).
Tags that are attached to requests that are evaluated using this Profile.
General parameters for administration.
As mentioned above, an ACL Profile includes six ACL Lists, each of which is shown in a separate column in the interface. Each one includes a list of zero or more tags.
When a request is processed, its tags are compared to the ones in the Lists. The Lists are evaluated in order from left to right.
If a match is not found, the next List is evaluated.
If a match is found, then one of the following occurs:
The request is subjected to a bot challenge. If it passes, ACL processing continues.
The request is exempted from bot challenges, and ACL processing continues.
The request is passed to the Content Filter Profile for further inspection.
The request is passed, and is exempted from content filtering.
The Action is executed, and processing ends.
Here is a flowchart of this process, with the evaluation of each ACL List column shown as a decision.
| ACL List | Comment |
|---|---|
Enforce Deny | Triggers the Action. (In most situations, admins will choose an action that blocks the request. This is a useful way to quickly filter out, with minimal computing overhead, large numbers of requests that are obviously hostile or otherwise unwanted.) |
Bypass | Allows the request, and bypasses/exempts it from subsequent evaluation by Content Filter Profiles. (Note that any |
Bot Challenge / Skip | Skip the Bot Challenge / Apply stage (the process by which non-human traffic is identified and blocked), and continue processing. An example usage is to allow search engine spiders. |
Bot Challenge / Apply | If the requestor has not previously been verified to be human, a bot challenge will be issued. If the challenge is passed, the request will continue in the evaluation process. Otherwise the Action is triggered. A common use of this column is to add the |
Block / Skip | Passes the request to the Content Filter Profile process for further inspection. |
Block / Apply | Triggers the Action. |
An ACL Profile that blocks requests will only apply to the paths/URLs in the Security Policy where this ACL Profile has been assigned. If you want to block requests globally for specific tags, this can be done by assigning an Action within a Global Filter.
Be cautious when adding the "all" tag to an ACL List. In most situations, that action will be performed for all requests for which a match was not found in any columns to the left.
One common use is the Bot Challenge / Apply column, as noted above. This means that all requestors (except for those which matched one of the columns to the left) will be challenged and verified to be humans.
Another possible use is to place "all" in the Block / Apply column, to create a positive security model. (This will block all requests which did not explicitly meet any of the conditions for Bypass or Block / Skip.) But even this usage can be risky. Unless all the potential conditions for allowing a request are fully and correctly defined, this can result in False Positive errors, and some legitimate requests will be blocked and filtered.
In other columns, "all" can have serious consequences. For example, placing it in the Enforce Deny column will block all incoming traffic to which this ACL Profile is applied. On the other hand, placing it in the Bypass column will allow all incoming traffic (and exempt it from being scrubbed by the Content Filter Profiles!), except for those requests which matched a tag in the Enforce Deny column.
Summary: before using the "all" tag in an ACL Profile, carefully consider its ramifications.
These six columns are explained above: How an ACL Profile works.
A name for this Profile, to be used within the Reblaze interface. An Automatic Tag (shown below the Tags field) will include it as well.
Information about this Profile, for use within the interface.
The action that is performed when a request matches a tag in Enforce Deny or Block / Apply, or the requestor fails a bot challenge. The actions available here are the defined Actions that are relevant for the Enforce Deny and Block / Apply columns (thus, "monitor" and "challenge" types aren't available here).
A list of one or more tags, separated by spaces. Whenever this ACL Profile is used to evaluate a request, these tags will appear in the traffic logs.
In addition to these admin-defined tags, the system also shows some Automatic Tags that will be attached as well.
