This topic describes solutions to common issues with Cloud Firewall network traffic analysis.
Why is there a high percentage of the Unknown application type in network traffic analysis?
Why do many unknown ISPs appear in the top traffic results for all access activities?
What do the intelligence tags in outbound connections represent?
What is the rule matching order for traffic protection in Cloud Firewall?
Service traffic overage issues:
What should I do if service traffic exceeds the bandwidth supported by Cloud Firewall?
How do I set up notifications for public network protection bandwidth overages in Cloud Firewall?
What should I do if I cannot handle traffic overages promptly?
What is the maximum specification for elastic bandwidth in Cloud Firewall?
Does the large percentage of Unknown application types in network traffic analysis indicate that the product cannot identify specific Internet requests?
An application may be displayed as Unknown for the following reasons:
A large amount of inbound traffic from the Internet may not use standard protocols. As a result, this traffic cannot be identified as a known protocol.
The destination server may block network traffic and send many RST packets in response. These packets are recorded as outbound or inbound traffic. A high volume of these packets increases the percentage of Unknown traffic.
You can go to the Log Audit page and open the Event Logs or Traffic Logs tab to examine the source and purpose of Unknown traffic and determine if your inbound or outbound traffic is abnormal.
Why do many unknown ISPs appear in the top traffic access results of all access activities?
For inbound traffic from Hong Kong (China), Macao (China), Taiwan (China), or regions outside China, Cloud Firewall displays only the country or region name, not the specific ISP. Therefore, if there is a large amount of inbound traffic from these locations, the ISP is marked as unknown.
You can access the Log Audit page and then go to the Traffic Logs tab to view the region and ISP for specific IP addresses.
What do the intelligence tags in outbound connections represent?
Intelligence tags are attributes that Cloud Firewall automatically assigns to outbound domains or destination IP addresses based on public network information. Examples include Malicious Download, Miner Pool, Threat Intelligence, First Time, epoch, Popular website, and DDoS Trojan. For more information about intelligence tags, see the Outbound Connection page.
Cloud Firewall detects outbound activities that pose threats, including those related to Malicious Download, Miner Pool, and Threat Intelligence.
NoteCheck the outbound connections associated with these tags for false positives. If you confirm the activity is malicious, configure an access control policy to manage it. For more information, see Configure an access control policy for the Internet firewall.
First Time: Cloud Firewall detected the outbound activity for the first time.
Periodic access: Your asset makes periodic outbound connections to this domain name or destination IP address.
Popular website: A domain name that your server or service frequently accesses.
DDoS Trojan: An outbound connection that Cloud Firewall detects as a DDoS attack threat.
How to troubleshoot traffic issues?
When network traffic passes through Cloud Firewall, the following issues may occur:
You cannot log on to the server.
You cannot access services on the server.
The server cannot access the Internet.
If these issues occur, troubleshoot by checking the Internet firewall and the internal firewall:
Internet firewall
Confirm that the Internet firewall is enabled for the asset.
Traffic passes through Cloud Firewall only after the Internet firewall is enabled. For information about how to enable the firewall, see Internet firewall.
NoteIf the Internet firewall is not enabled for the asset, traffic does not pass through Cloud Firewall. You must check for other issues, such as network connectivity problems.
Verify that the corresponding traffic records appear on the Traffic Logs tab.
If no traffic logs exist, the traffic was dropped before it reached the firewall.
If an entry in the Traffic Logs shows that the action is Discard, it means the traffic was dropped by the Internet firewall. To identify the rule that blocked the traffic, query the corresponding traffic in the Event Logs list and check the Judgement Source column.
This instruction from Access Control indicates that your configured access control policy has blocked this traffic. We recommend that you check and modify the access control policy configuration.
If the instruction source is Basic Protection, Virtual Patching, or Threat Intelligence, your intrusion prevention policy blocked the traffic. You can go to the page and disable the corresponding policy.
If traffic logs exist and the action is Allow or Monitor, the traffic was not dropped at the Internet firewall. You must continue troubleshooting the internal firewall (security group) policies.
Internal firewall (security group)
Log on to the ECS console.
In the navigation pane on the left, choose .
Locate the ECS instance that has network connectivity issues and, on the Security Group tab, click the Security Group List tab to confirm that the security group allows traffic (the Authorization policy is set to Allow).
What is the rule matching order for traffic protection in Cloud Firewall?
In Cloud Firewall, network traffic rules are matched in the following order:
Access control policy (ACL)
If you enable access control, the system first matches traffic against your ACL rules:If the traffic hits a rule with the Deny action, it is immediately blocked. No further checks are performed.
If the traffic hits a rule with the Allow or Monitor action, or if it does not hit any ACL rule, the system proceeds to the next check.
Threat Intelligence (TI)
Matches traffic against the threat intelligence feed:If the traffic hits a rule and the action is Block, the matching process stops.
Otherwise, the system proceeds to the next check.
Intrusion Prevention System (IPS) module
Traffic is processed sequentially by three types of rules: Basic Protection, Intelligent Defense, and Virtual Patching. These three rule types have no priority order, and the system evaluates all of them against the traffic. If any rule triggers a block action, the traffic is blocked; otherwise, the traffic is allowed after all evaluations are complete.
The ACL, TI, and IPS modules are independent and use a sequential matching mechanism. The matching process stops as soon as a module blocks the traffic. In all other cases, subsequent checks continue.
How does Cloud Firewall detect Internet exposure?
Cloud Firewall analyzes inbound traffic data to detect anomalous traffic, exposed public IP addresses of your assets, open ports, open applications, and the public IP addresses of your cloud products. For information about how to view Internet exposure, see Internet Exposure.
Service traffic overage issues
What to do if service traffic exceeds the bandwidth supported by Cloud Firewall?
If your service traffic exceeds the bandwidth of your Cloud Firewall instance, the Service-Level Agreement (SLA) is not guaranteed. This can lead to service degradation, which may include the failure of security features such as access control, IPS, and log auditing, the firewall being disabled for assets with the highest traffic, rate limiting, or packet loss.
If your service traffic is at risk of exceeding the limit, see Pay-as-you-go for elastic bandwidth of subscription instances.
For information about how to troubleshoot anomalous traffic, see Troubleshoot anomalous traffic on the Internet border.
For information about how to scale out your protection bandwidth, see Renewal policy.
How to set up notifications for public network protection bandwidth overages in Cloud Firewall?
There are two types of traffic overage notifications: traffic overage notifications and traffic overage alerts.
Traffic overage notification: Provides real-time statistics on the current day's traffic overage for each border (Internet Border, VPC border, and NAT border).
Trigger logic: A notification is sent when traffic exceeds the limit. There is a 10-minute delay. Notifications are sent 24/7.
Sending logic: Sent only once per day.
Note that subscription customers who enable elastic bandwidth will no longer receive traffic overage notifications.
If you scale out your bandwidth within 10 minutes of the overage, an alert is not triggered.
Traffic overage alert: Provides real-time statistics for overage alerts with a 10-minute delay. Currently, alerts are supported only for the Internet Border. Alerts are not supported for the NAT border.
Trigger logic: The current traffic exceeds the configured alert threshold.
Alert content logic: The alert includes statistics on the peak traffic and the number of times the threshold was exceeded in the past 24 hours. An overage is counted once per 30-minute interval if the traffic exceeds the threshold during that interval.
Sending logic: Sent only once per day. If a traffic overage notification has already been sent, an alert is not sent.
When the elastic traffic processing capability is enabled, users are prevented from sending traffic.
Sent 24/7.
For information about supported notification types and how to configure them, see Alert notifications.
What to do if you cannot handle traffic overages promptly?
If you anticipate a short-term burst in service traffic that you cannot promptly handle, you can use Cloud Firewall's subscription-based pay-as-you-go elastic traffic feature.
Pay-as-you-go for elastic bandwidth is a billing model for traffic that exceeds the quota of your subscription plan. This model lets you pay for the excess traffic based on actual usage without changing your original subscription billing method. For more information, see Pay-as-you-go for elastic bandwidth of subscription instances.
For pay-as-you-go instances, all traffic is billed on a pay-as-you-go basis, so this issue does not apply.
What is the maximum specification for elastic bandwidth in Cloud Firewall?
The default daily processing limit is 1,000,000 GB. Note that Cloud Firewall has limits on bandwidth, but not on queries per second (QPS) or the number of connections. For more information, see Billing of pay-as-you-go for elastic bandwidth of subscription instances.