ACL Profiles
An ACL (Access Control List) Policy is a set of sequential criteria by which a request is evaluated. The input controls at the top of this page are described here: Policies & Rules Entry Administration. Specific editing of an ACL Profile is described below.
This page defines ACL Profiles. The Policies are assigned to URLs within the web application via Security Policies.
Out of the box, Curiefense 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 Policy has been assigned.
The top part of the interface shows the ACL Profile that is currently being edited. Each Policy consists of one or more tags. Each tag is listed under the action which will be triggered when a request matches that particular tag.
In the interface, the tags are listed below their associated actions. Evaluation is performed from left to right:
- The incoming request is evaluated to see if it matches any of the tags in the far left column.
- If a match is found, that column's action is performed, and no further evaluation is done.
- If a match is not found, then the next column to the right is evaluated. A match will trigger that column's action; otherwise the next column is evaluated.
- This process continues until an action is taken or all columns have been evaluated.
- If a request does not match any tags in this Policy, it is passed to the WAF for further inspection.
Action | Comment |
Enforce Deny | 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 the WAF. |
Allow Bot | Passes the request to the WAF for further inspection without triggering a bot challenge (the process by which non-human traffic is identified and blocked). An example usage is to allow search engine spiders. |
Deny Bot | 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 request is blocked. A common use of this column is to add the "all" tag, which means to identify and block all bots that weren't previously Allowed or Bypassed. |
Allow | Passes the request to the WAF for further inspection. |
Deny | Blocks the request. |
An ACL Profile that blocks requests via the Enforce Deny Action 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 defining the appropriate Action within the relevant Tag Rules.
Be very cautious when adding the "all" tag to an action column. In most situations, that action will be taken for all requests for which a match was not found in any columns to the left.
The most common use is the "Deny Bot" column, as noted above. This means that all requestors (except for those previously Allowed or Bypassed) will be challenged and verified to be humans.
Another possible use is to place "all" in the Deny column, to create a positive security model. (This will block all requests which did not explicitly meet any of the conditions to be Bypassed or Allowed.) But even this usage can be dangerous. Unless all the conditions for Bypassing or Allowing requests 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 WAF!), 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.
Last modified 10mo ago