What Do I Do If Service Traffic is Abnormal?

Symptom

Service traffic is abnormal. For example:

• An EIP cannot access the Internet.
• A server cannot be accessed.

Troubleshooting Methods

Figure 1 Procedure of checking traffic exceptions

Cause 1: Traffic Interruption Not Caused by CFW

You can disable protection on the CFW console and observe the service status. If the service does not recover, it indicates the traffic interruption was not caused by CFW.

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

Cause 2: Traffic Blocked by Protection Policies

Traffic is blocked probably because 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.

You can take the following measures:

In the Access Control Logs tab, search for logs about the blocked IP address or domain name.

• If no records are found, see Table 1 under Cause 3.
• If a record is found, click the Rule column to go to the matched blocking policy.
  • If normal services are blacklisted, you can:
    • Delete the blacklist policy.
    • Add a whitelist policy for the IP address/domain name. (The whitelist takes precedence over the blacklist. After the whitelist policy is added, the blacklist policy becomes invalid and the traffic is directly permitted.)
  • If the traffic is blocked by a blocking rule, you can:
    • Find the blocking rule of the IP address or domain name in the access control rule list and disable the policy.
    • Modify the matching condition of the blocking policy and remove the IP address or domain name information.
    • Add a protection rule whose Action is Allow and Priority is Pin on top. For details, see Adding a Protection Rule.

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.94.

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 2 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.94. A blocking rule named Block-Malicious-Outreach was found, and this rule blocked the traffic from the attack source IP address to the Internet.
   Figure 3 Filtering access control logs
   

3. The administrator searched for "Source: xx.xx.xx.94; 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 4 Searching for a protection rule
   

   

   According to Figure 4, there were three valid rules whose source IP addresses contain xx.xx.xx.94, 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 4).

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.

Cause 3: Traffic Blocked by Intrusion Prevention

The protection mode of intrusion prevention functions, such as IPS, is too strict, blocking normal traffic.

You can take the following measures:

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.90 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.90 were displayed. The IPS rule whose ID was 331978 blocked the traffic.
   Figure 5 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 verify that the service is normal. The administrator searched for the rule whose ID is 331978 from the list on the Basic Protection tab page by referring to Modifying the Action of a Basic Protection Rule.
   Figure 6 Rule 331978
   

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 331978 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.

Submitting a Service Ticket

If the preceding methods cannot solve your problem, submit a service ticket.