How Do I Troubleshoot CFW Protection When Service Traffic Is Abnormal?

Locating Method

1. Disable CFW protection.
   • EIP traffic fault: Disable the CFW protection in EIPs whose services are interrupted. For details, see Disabling EIP Protection.
   • SNAT or inter-VPC access failure: Disable the VPC border firewall. For details, see Disabling a VPC Border Firewall.

2. Observe the service running status.
   • If the services are restored, go to Troubleshooting Methods.
   • If the fault persists, the traffic interruption is not caused by CFW but common faults:
     • Network fault: The route configuration is incorrect, or the NE is faulty.
     • Policy-based interception: Interception caused by incorrect configurations of other security services, network ACLs, or security groups.

     If you need assistance from Huawei Cloud, you can create a service ticket.

Troubleshooting Methods

1. In the Access Control Logs tab, search for logs about the blocked IP address or domain name.
   • If a record exists, click the Rule column to go to the matched blocking policy. For details about subsequent operations, see Scenario 1: Incorrect Protection Policy.
   • If no records exist, go to 2.

2. In the Attack Event Logs tab, search for logs about the blocked IP address or domain name.
   • If a record exists, copy the information in the Rule ID column. For details about subsequent operations, see Scenario 2: Incorrect Interception by the Intrusion Prevention Function.
   • If no records exist, go to 3.

3. If services are restored after EIP protection or the VPC border firewall is disabled, you are advised to disable firewall protection and submit a service ticket.
4. (Optional) To monitor the firewall status and quickly detect exceptions, you are advised to:
   • Configure alarm notification on the CFW console. For details, see Alarm Notification.
   • Configure CFW alarm rules on the Cloud Eye console. For details, see Setting Monitoring Alarm Rules. For details about supported monitoring metrics, see CFW Metrics.

Scenario 1: Incorrect Protection Policy

Possible causes

A blocking rule is configured in the access control policy, or the normal services are blacklisted. In this case, CFW blocks related sessions, causing service loss.

Case

Handling process: Detect a fault -> Disable protection -> View logs -> Modify a policy -> Restore protection -> Confirm logs

The network O&M personnel of a company found that an ECS cannot access the Internet through the bound EIP xx.xx.xx.126.

The firewall administrator took the following measures:

1. To ensure that the IP address can be used for external communication during fault locating, the firewall administrator logged in to the CFW console, and chose Assets > EIPs, and disables protection for the EIP.
   During the firewall is disabled, the traffic of the EIP is not processed and related logs are not displayed.

   Figure 1 EIPs
   

2. The administrator chose Log Audit > Log Query and clicked the Access Control Logs tab. He searched for the blocking logs of the access source IP address xx.xx.xx.126. A blocking rule named Block-Malicious-Outreach was found, and this rule blocked the traffic from the EIP xx.xx.xx.126 to the Internet.
   Figure 2 Filtering access control logs
   

3. The administrator searched for "Source: xx.xx.xx.126; Action: Block; Direction: Outbound; Status: Enabled" in the access control policy list. Three available policies that contain the IP address were found.
   The policy contained the Block-Malicious-Outreach blocking rule. According to the value of the Hits column, a large number of sessions have been blocked.

   Figure 3 Searching for a protection rule
   

   

   According to Figure 3, there were three valid rules whose source IP addresses contain xx.xx.xx.252, including Block-xxx-com (with the highest priority), Block-Malicious-Outreach, and Allow-Asia (with the lowest priority). Besides the blocking rule Block-Malicious-Outreach, the administrator checked whether the two other two rules may intercept normal services.

   Finally, it is found that the EIP accessed suspicious IP addresses so that an administrator configured a blocking rule it, but the configured destination was incorrect. As a result, all external traffic is blocked by mistake (see the second protection rule in Figure 3).

4. The administrator changed the destination address to a specific IP address that needs to be blocked, and enabled protection for the EIP on the Assets > EIPs page of the CFW console. After protection was restored, the traffic of the EIP was normally forwarded by CFW.
5. The administrator viewed the external connection logs related to the IP address in the traffic logs and confirmed that the service was restored.

Scenario 2: Incorrect Interception by the Intrusion Prevention Function

Case

Handling process: Detect a fault -> Change the protection status -> View logs -> Confirm services -> Modify the policy -> Restore the protection status -> Confirm logs

The O&M personnel of a company found that a service on the server whose IP address was xx.xx.xx.99 cannot be accessed. It was suspected that the service was blocked by the firewall.

The firewall administrator took the following measures:

1. To quickly recover the service, the administrator logged in to the CFW console, choose Attack Defense > Intrusion Prevention, and changed the protection mode from Intercept mode - strict to Observe.

   During this period, the firewall did not intercept attack traffic but only logged the attack traffic.

2. The administrator chose Log Audit > Log Query and clicked the Attack Event Logs tab. The logs about the access to the destination IP address xx.xx.xx.99 were displayed. The IPS rule whose ID was 334841 blocked the traffic.
   Figure 4 Filtering attack event logs
   

3. The administrator clicked Details in the Operation column, clicked Payload Content in the display page, and created a packet capture task to determine that the service is normal. The administrator searched for the rule whose ID is 334841 from the list on the Basic Protection tab page by referring to Modifying the Action of a Basic Protection Rule.
   Figure 5 Rule 334841
   

4. The administrator clicked Observe in the Operation column. This rule did not block the traffic matching the signature but only logged the traffic.
5. The administrator set the protection mode to Intercept mode - strict and went to the Basic Protection tab to confirm that the Current Status of the rule 334841 was still Observe.
6. In the Attack Event Logs tab, after the service session matched the rule, the Action of the log was Allow. The service was restored.