Configuration item | Description |
Account Extraction | Customize the Account Type and Location. You can add a maximum of five conditions. The conditions are evaluated using a logical OR. Account fetch: If a logon request uses the GET method and the request parameter is username=158***&password=***, set Location to Query Parameter and enter username for Parameter Name. This allows WAF to fetch the phone number for subsequent matching. |
Risk Tag | Suspicious Sock Puppet Account: A phone number that seems to be provided by a third-party platform and does not belong to an individual user. The default risk level is High. Fraud Risk: A phone number that seems to have been involved in fraudulent activities. The default risk level is High. Spam User Registration: A phone number that seems to be used with malicious tools to register user accounts for subsequent marketing campaigns. The default risk level is High. Marketing Fraud: A phone number that seems to be used with malicious tools to participate in marketing campaigns, such as registering multiple accounts to claim coupons. The default risk level is High. Auto-purchase Bot: A phone number that seems to be used with malicious tools to participate in ticket grabbing or other flash sale events. The default risk level is High.
The risk levels are High, Medium-high, and Medium. Select a risk level as needed. |
Rule Type | Suspected Bot: Exhibits some characteristics of a crawler but lacks direct evidence, such as attack traces or clear intent. Further verification of its intent is required. Malicious Bot: An automated program that uses automated methods to attack a target system or network, steal data, or perform malicious operations for illicit purposes. |
Actions | Block: Blocks requests that hit the rule and returns a block page to the client that initiated the requests.
Note By default, WAF returns a preconfigured block page. You can use the custom response feature to configure a custom block page. For more information, see Configure a custom block page. Monitor: Does not block requests that hit the rule. It only records the requests in logs. You can query the logs in WAF to find requests that hit the rule and analyze the rule's effectiveness, for example, to check for false positives. The monitor mode lets you test newly configured rules. After you confirm that no false positives are generated, you can set the action to another mode. JavaScript Validation: WAF returns a JavaScript snippet to the client that a normal browser can automatically execute. If the client executes the JavaScript code, WAF allows all subsequent requests from the client for a period (30 minutes by default) without further challenges. Otherwise, the request is blocked.
Note If you enable Fraud Detection for app protection, you cannot select JavaScript Challenge as the action. Slider CAPTCHA: WAF returns a slider verification page to the client. If the client passes the slider verification, WAF allows all subsequent requests from the client for a period (30 minutes by default) without further verification. Otherwise, the request is blocked. Strict Slider CAPTCHA Verification: WAF returns a slider verification page to the client. If the client passes the slider verification, WAF allows the current request. Otherwise, the request is blocked. In Strict Slider mode, every request from the client requires verification. Add Tag: Lets you customize the header name and content (such as rule type, rule ID, and web UMID). WAF does not process the request directly. Instead, it adds a header to forward the hit information to the origin server. You can integrate this with your backend risk control system for business-side processing.
|
Canary Release | Configure the percentage of objects of a specific dimension to which the rule applies. After you enable the grayscale rule, you must set the grayscale Dimension and Canary Release Proportion. The grayscale Dimension can be IP, Custom Header, Custom Parameter, Custom Cookie, Session, or Web UMID.
Note A grayscale rule is applied based on the Dimension you set, not randomly to a percentage of requests. For example, if you select IP as the dimension, all requests from the IPs that trigger the grayscale rule will hit the protection rule. |
Effective Mode | Permanently Effective (Default): The rule is always in effect when the protection template is enabled. Fixed Schedule: To prevent attackers from identifying and bypassing updated protection rules before an event, new rules are typically enabled at the start of the event. You can set the rule to take effect for a specific period in a specific time zone. Recurring Schedule: Suitable for recurring events where stricter protection rules are needed during the event and looser rules are used at other times. You can also deploy new rules during low-traffic periods to verify their effectiveness and check for false positives. You can set the rule to take effect for a specific period each day in a specific time zone.
|