What is HTTP ACL Policy
HTTP ACL Policy supports customizing HTTP access control to filter out HTTP request based on a combination of criteria of commonly used HTTP fields, such as IP, URL, Referer, UA, and parameters. This feature applies to different business scenarios, such as anti-leech protection and website admin console protection.
HTTP ACL Policy supports the following fields: Params, URL, IP, Referer, and User-Agent. Wherein, Params stands for the parameter, which is usually the part after “?” in an URL. For example, in
www.abc.com/index.html?action=logon, the parameter isaction=logon.HTTP ACL Policy supports multiple logical operators, such as Does not have, Has, Does not include, Includes, Does not equal, Equals, Length less than, Length equals, and Length more than.
Note
Before configuring HTTP ACL Policy, consider the following points:
- Each rule allows a combination of three conditions at most.
- Multiple conditions in a rule are connected by “AND”, that is, a request must satisfy all the conditions to match the rule.
- Three types of actions can be taken after a rule is matched: Block, Allow, and Warn (the request is recorded but not blocked). After specifying Allow or Warn, you can further decide whether to proceed to perform Web Application Protection, HTTP Flood Protection, Intelligent Protection, Regional blocking, and Data Risk Control.
- Matching rules follow a specific order. You can set the order for the rules to achieve the optimal protection performance.
Procedure
Follow these steps to configure HTTP ACL Policy:
Log on to the Web Application Firewall console and access the Website Configuration page.
Click Policies under the Operation column of the target domain name.
Enable HTTP ACL Policy, and then click settings to configure the relevant rules.
Examples
HTTP ACL Policy supports various configuration methods. You can work out the best rules based on your business characteristics. Some examples are as follows.
IP blacklist/whitelist configuration
Use the following configuration to block all access from 1.1.1.1.
Use the following configuration to allow access from the 2.2.2.0/24 CIDR block.
Note: Do not check Proceed to execute web application attack protection or Proceed to execute HTTP flood attack protection.
Blocking malicious requests
The following figure shows an example of WordPress bounce attack, featuring that the UA contains WordPress.
Use the following configuration to defend against this type of attack.
For more information about protection configurations against WordPress attacks, see Prevent WordPress bounce attacks.
Blocking specific URLs
If a large number of IP addresses are requiring a specific but inexistent URL, you can use the following configuration.
Anti-Leech
You can configure a Referer-based access condition. For example, if you find abc.blog.sina.com is using a large quantity of pictures on your site, you can use the following configuration.
