Handling False Alarms¶
If you confirm that an attack event on the Events page is a false alarm, you can handle the event as false alarm by ignoring the URL and rule ID in basic web protection, or by deleting or disabling the corresponding protection rule you configured. After an attack event is handled as a false alarm, the event will not be displayed on the Events page anymore.
WAF detects attacks by using built-in basic web protection rules, built-in features in anti-crawler protection, and custom rules you configured (such as CC attack protection, precise access protection, blacklist, whitelist, and geolocation access control rules). WAF will respond to detected attacks based on the protective actions (such as Block and Log only) defined in the rules and display attack events on the Events page.
Prerequisites¶
There is at least one false alarm event in the event list.
Constraints¶
Only attack events blocked or recorded by built-in basic web protection rules and features in anti-crawler protection can be handled as false alarms.
For events generated based on custom rules (such as a CC attack protection rule, precise protection rule, blacklist rule, whitelist rule, or geolocation access control rule), they cannot be handled as false alarms. To ignore such an event, delete or disable the custom rule hit by the event.
An attack event can only be handled as a false alarm once.
After an attack event is handled as a false alarm, the attack event will not be displayed on the Events page.
Dedicated WAF instances earlier than June 2022 do not support All protection for Ignore WAF Protection. Only Basic web protection can be selected.
Application Scenarios¶
Sometimes normal service requests may be blocked by WAF. For example, suppose you deploy a web application on an ECS and then add the public domain name associated with that application to WAF. If you enable basic web protection for that application, WAF may block the access requests that match the basic web protection rules. As a result, the website cannot be accessed through its domain name. However, the website can still be accessed through the IP address. In this case, you can handle the false alarms to allow normal access requests to the application.
Handling False Alarms¶
Log in to the management console.
Click
in the upper left corner and choose Web Application Firewall (Dedicated) under Security.In the navigation pane on the left, choose Events.
Click the Search tab. In the website or instance drop-down list, select a website to view corresponding event logs. The query time can be Yesterday, Today, Past 3 days, Past 7 days, Past 30 days, or a time range you configure.
In the event list, handle events.
If you confirm that an event is a false alarm, locate the row containing the event. In the Operation column, click More > Handle as False Alarm and handle the hit rule.
Figure 1 Handling a false alarm¶
Table 1 Parameters¶ Parameter
Description
Example Value
Scope
All domain names: By default, this rule will be used to all domain names that are protected by the current policy.
Specified domain names: Specify a domain name range this rule applies to.
Specified domain names
Domain Name
This parameter is mandatory when you select Specified domain names for Scope.
Enter a single domain name that matches the wildcard domain name being protected by the current policy.
www.example.com
Condition List
Click Add to add conditions. At least one condition needs to be added. You can add up to 30 conditions to a protection rule. If more than one condition is added, all of the conditions must be met for the rule to be applied. A condition includes the following parameters:
Parameters for configuring a condition are described as follows:
Field
Subfield: Configure this field only when Params, Cookie, or Header is selected for Field.
Important
NOTICE: The length of a subfield cannot exceed 2,048 bytes. Only digits, letters, underscores (_), and hyphens (-) are allowed.
Logic: Select a logical relationship from the drop-down list.
Content: Enter or select the content that matches the condition.
Path, Include, /product
Ignore WAF Protection
All protection: All WAF rules do not take effect, and WAF allows all request traffic to the domain names in the rule.
Basic web protection: You can ignore basic web protection by rule ID, attack type, or all built-in rules. For example, if XSS check is not required for a URL, you can whitelist XSS rule.
Basic web protection
Ignored Protection Type
If you select Basic web protection for Ignored Protection Type, specify the following parameters:
ID: Configure the rule by event ID.
Attack type: Configure the rule by attack type, such as XSS and SQL injection. One type contains one or more rule IDs.
All built-in rules: all checks enabled in Basic Web Protection.
Attack type
Rule ID
This parameter is mandatory when you select ID for Ignored Protection Type.
Rule ID of a misreported event in Events whose type is not Custom. You are advised to handle false alarms on the Events page.
041046
Rule Type
This parameter is mandatory when you select Attack type for Ignored Protection Type.
Select an attack type from the drop-down list box.
WAF can defend against XSS attacks, web shells, SQL injection attacks, malicious crawlers, remote file inclusions, local file inclusions, command injection attacks, and other attacks.
SQL injection
Rule Description
A brief description of the rule. This parameter is optional.
SQL injection attacks are not intercepted.
Advanced Settings
To ignore attacks of a specific field, specify the field in the Advanced Settings area. After you add the rule, WAF will stop blocking attack events of the specified field.
Select a target field from the first drop-down list box on the left. The following fields are supported: Params, Cookie, Header, Body, and Multipart.
If you select Params, Cookie, or Header, you can select All or Field to configure a subfield.
If you select Body or Multipart, you can select All.
If you select Cookie, the Domain Name box for the rule can be empty.
Note
If All is selected, WAF will not block all attack events of the selected field.
Params
All
Add the source IP address to an address group. Locate the row containing the desired event, in the Operation column, click More > Add to Address Group. The source IP address triggering the event will be blocked or allowed based on the policy used for the address group.
Add to: You can select an existing address group or create an address group.
Figure 2 Add to Address Group¶
Add the source IP address to a blacklist or whitelist rule of the corresponding protected domain name. Locate the row containing the desired event. In the Operation column, click More > Add to Blacklist/Whitelist. Then, the source IP address will be blocked or allowed based on the protective action configured in the blacklist or whitelist rule.
Figure 3 Add to Blacklist/Whitelist¶
Table 2 Parameter descriptions¶ Parameter
Description
Add to
Existing rule
New rule
Rule Name
If you select Existing rule for Add to, select a rule name from the drop-down list.
If you select New rule for Add to, customize a blacklist or whitelist rule.
IP Address/Range/Group
This parameter is mandatory when you select New rule for Add to.
You can select IP address/Range or Address Group to add IP addresses a blacklist or whitelist rule.
Group Name
This parameter is mandatory when you select Address group for IP Address/Range/Group.
Select an address group from the drop-down list.
Protective Action
Block: Select Block if you want to blacklist an IP address or IP address range.
Allow: Select Allow if you want to whitelist an IP address or IP address range.
Log only: Select Log only if you want to observe an IP address or IP address range.
Known Attack Source
If you select Block for Protective Action, you can select a blocking type of a known attack source rule. WAF will block requests matching the configured IP address, Cookie, or Params for a length of time configured as part of the rule.
Rule Description
A brief description of the rule. This parameter is optional.
Verification¶
A false alarm will be deleted within about a minute after the handling configuration is done. It will no longer be displayed in the attack event details list. You can refresh the browser cache and access the page for which the global whitelist rule is configured again to check whether the configuration is successful.