Cloud Firewall allows all traffic by default. Once you configure access control policies, Cloud Firewall evaluates traffic against those policies in priority order, executes the action of the first matching policy, and stops. Understanding the two-stage process — how a policy expands into matching rules, and how traffic is evaluated against those rules — helps you build policies that behave exactly as intended.
Key concepts
| Term | Description |
|---|---|
| Matching item | The six fields Cloud Firewall uses to evaluate traffic: source address, destination address, destination port, transport protocol, application-layer protocol, and domain name. Other policy fields (such as access type) define the policy but are not used as matching items. |
| Destination type | The format of the destination address in a policy: IP, address book, domain name, or region. Supported types vary by firewall — Internet Border inbound policies support only IP and address book; VPC border policies support IP, address book, and domain name. |
| Four-tuple | Source IP address, destination IP address, destination port, and transport protocol. |
| Application | An application-layer protocol: HTTP, HTTPS, SMTP, SMTPS, SSL, FTP, IMAPS, or POP3. Select ANY to match all application types. Cloud Firewall identifies SSL/TLS traffic by port: 443 → HTTPS, 465 → SMTPS, 993 → IMAPS, 995 → POPS, all other ports → SSL. |
| Layer 7 policy | A policy that specifies both an application and an FQDN (Fully Qualified Domain Name) as conditions. |
| Expanding logic | When a policy contains multiple values for a field (such as two source addresses or two ports), Cloud Firewall generates a separate matching rule for each combination after the policy takes effect. |
| Matching logic | The process by which Cloud Firewall evaluates traffic against expanded matching rules and executes the corresponding action. |
Domain name identification modes
When a policy destination is a domain name or domain name address book, Cloud Firewall uses one of three identification modes:
FQDN-based (extracts Host and SNI fields): Reads the Host or SNI field from traffic to identify the domain name. Supported applications: HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, and IMAPS (protocol type must be TCP). This is the only mode that supports wildcard domain names and wildcard domain name address books.
DNS-based dynamic resolution: Resolves the domain name to IP addresses dynamically and matches against those IPs. Compatible with a wider range of applications, including MySQL and SSH. A single domain name resolves to a maximum of 500 IP addresses. Supported applications by protocol:
TCP: HTTP, HTTPS, IMAPS, FTP, ANY
UDP: DNS, ANY
ICMP or ANY: ANY only
Both FQDN-based and DNS-based dynamic resolution: Applies both methods in sequence. Cloud Firewall first attempts FQDN identification, then falls back to DNS-resolved IPs. Supported applications: HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, and IMAPS (protocol type must be TCP). Strict mode is required — in loose mode, traffic that cannot be identified by FQDN is allowed and the DNS rule never takes effect.
How it works
Access control policies go through two stages before traffic is controlled:
Policy expansion: After you create an access control policy, Cloud Firewall expands it into one or more matching rules based on the configured fields and sends those rules to the engine.
Traffic matching: When traffic passes through Cloud Firewall, it is evaluated against matching rules in priority order. If a rule matches, Cloud Firewall executes the corresponding action and stops. If no rules match, the traffic is allowed by default.
Policy expanding logic
Cloud Firewall expands each policy into matching rules by generating one rule per combination of configured objects. For policies with multiple sources or ports, this produces multiple rules. The expansion logic differs depending on the destination type.
When traffic matches a policy that expanded into multiple rules, the traffic is evaluated against each rule in order. A match on any rule counts as a match for the entire policy.
When the destination type is IP, address book, or region
Cloud Firewall expands the source, destination, protocol type, port, and application based on the number of configured objects.
When the destination type is a domain name or domain name address book
The expansion logic depends on the domain name identification mode.
FQDN-based (extracts Host and SNI fields)
Cloud Firewall sets the destination address to 0.0.0.0/0 and expands the domain name, source, protocol type, port, and application. Applications are limited to HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, and IMAPS; the protocol type must be TCP.
DNS-based dynamic resolution
Cloud Firewall resolves the domain name to IP addresses and sets the destination address in each matching rule to a resolved IP.
Both FQDN-based and DNS-based dynamic resolution
Cloud Firewall expands the policy into two sets of rules: one set using FQDN matching (destination set to 0.0.0.0/0) and one set using DNS-resolved IPs. Applications are limited to HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, and IMAPS; the protocol type must be TCP.
Enable strict mode when using this identification mode. In loose mode, if FQDN identification fails, the traffic is allowed and the DNS-based rules never take effect.
Policy matching logic
When traffic passes through Cloud Firewall, it is evaluated in three sequential stages: four-tuple matching, application matching, and domain name matching. Cloud Firewall proceeds to the next stage only when the previous stage produces a hit.
Traffic in the application or domain name identification stage is allowed by default during the identification period (for example, when the status is "waiting for payload" or "analyzing"), regardless of ACL engine mode or policy action. The difference between modes applies only when identification fails: in loose mode, unidentified traffic continues to be allowed; in strict mode, identification failure ends the process and moves to the next policy.
Cloud Firewall evaluates access control policies alongside threat intelligence rules, basic protection policies, intelligent defense rules, and virtual patching rules. For the full matching order across all rule types, see FAQ about traffic analysis.
Stage 1: Four-tuple matching
Cloud Firewall matches the four-tuple (source IP address, destination IP address, destination port, transport protocol) against the current policy.
Hit: Proceed to stage 2.
No hit: Move to the next-priority policy. If no policies remain, allow the traffic by default.
Stage 2: Application matching
ANY specified: All traffic passes. Proceed to stage 3.
Specific application specified, and traffic application is identified:
Hit: Proceed to stage 3.
No hit: Move to the next-priority policy.
Specific application specified, but traffic application is not identified:
Loose mode: Allow the traffic by default.
Strict mode: Move to the next-priority policy.
Stage 3: Domain name matching
No domain name specified: All domain names pass. Execute the policy action.
Specific domain name specified, and traffic domain name is identified:
Hit: Execute the policy action.
No hit: Move to the next-priority policy.
Specific domain name specified, but traffic domain name is not identified:
Loose mode: Allow the traffic by default.
Strict mode: Move to the next-priority policy.
Configuration examples
The following examples use Internet Border access control policies to show how the matching logic applies in practice.
Scenario 1: Destination type is an IP address
Policies configured:
| Policy | Source | Destination | Protocol type | Port | Application | Action | Priority |
|---|---|---|---|---|---|---|---|
| Policy A | 192.0.2.0/24 | 198.51.100.0/24 | TCP | 80/88 | HTTP | Allow | 1 |
| Policy B | 0.0.0.0/0 | 0.0.0.0/0 | ANY | 0/0 | ANY | Deny | 2 |
Traffic evaluation:
| Traffic | Source | Destination | Protocol | Port | Application | Result |
|---|---|---|---|---|---|---|
| Example 1 | 192.0.2.1 | 198.51.100.1 | TCP | 80 | HTTP | Stage 1: four-tuple matches Policy A → Hit. Stage 2: application matches Policy A → Hit. Action: Allow |
| Example 2 | 203.0.113.1 | 198.51.100.1 | TCP | 80 | HTTP | Stage 1: four-tuple does not match Policy A → No hit. Stage 1: four-tuple matches Policy B → Hit. Action: Deny |
| Example 3 | 192.0.2.4 | 198.51.100.1 | TCP | 80 | Unknown | Stage 1: four-tuple matches Policy A → Hit. Stage 2: application cannot be identified. Loose mode: Allow by default. Strict mode: continue to Policy B → Stage 1 matches Policy B → Action: Deny |
Processing sequence (Example 3, strict mode): Policy A (four-tuple hit) → Policy A (application unidentified) → Policy B (four-tuple hit) → Deny
Scenario 2: Destination type is a domain name
Policies configured (assume www.aliyun.com resolves to 106.XX.XX.5):
| Policy | Source | Destination | Domain name identification mode | Protocol type | Port | Application | Action | Priority |
|---|---|---|---|---|---|---|---|---|
| Policy A | 192.0.2.0/24 | www.aliyun.com | FQDN-based | TCP | 0/0 | HTTP, HTTPS | Allow | 1 |
| Policy B | 198.51.100.0/24 | www.aliyun.com | DNS-based dynamic resolution | TCP | 0/0 | SSH | Allow | 2 |
| Policy C | 203.0.113.0/24 | www.aliyun.com | Both FQDN-based and DNS-based | TCP | 0/0 | SMTP | Allow | 3 |
| Policy D | 0.0.0.0/0 | 0.0.0.0/0 | — | ANY | 0/0 | ANY | Deny | 4 |
Traffic evaluation:
| Traffic | Source | Destination | Protocol | Port | Application | Domain name | Result |
|---|---|---|---|---|---|---|---|
| Example 1 | 192.0.2.1 | 106.XX.XX.5 | TCP | 80 | HTTP | www.aliyun.com | Stage 1: matches Policy A → Hit. Stage 2: application matches → Hit. Stage 3: domain name matches → Hit. Action: Allow |
| Example 2 | 203.0.113.3 | 106.XX.XX.5 | TCP | 443 | HTTPS | www.aliyun.com | Stage 1: does not match Policy A or B → No hit. Stage 1: matches Policy C → Hit. Stage 2: application (HTTPS) does not match Policy C (SMTP) → No hit. Stage 1: matches Policy D → Hit. Action: Deny |
| Example 3 | 198.51.100.1 | 106.XX.XX.5 | ANY | 22 | SSH | None | Stage 1: does not match Policy A → No hit. Stage 1: matches Policy B → Hit. Stage 2: application (SSH) matches → Hit. (Policy B uses DNS-based mode; no domain name stage.) Action: Allow |
| Example 4 | 192.0.2.2 | 106.XX.XX.5 | TCP | 80 | Unknown | None | Stage 1: matches Policy A → Hit. Stage 2: application cannot be identified. Loose mode: Allow by default. Strict mode: continue → Policy B, C no hit → Policy D hit → Action: Deny |
| Example 5 | 192.0.2.3 | 106.XX.XX.5 | TCP | 80 | HTTP | Unknown | Stage 1: matches Policy A → Hit. Stage 2: application matches → Hit. Stage 3: domain name cannot be identified. Loose mode: Allow by default. Strict mode: continue → Policy B, C no hit → Policy D hit → Action: Deny |
Processing sequence (Example 4, strict mode): Policy A (four-tuple hit) → Policy A (application unidentified) → Policy B (no hit) → Policy C (no hit) → Policy D (four-tuple hit) → Deny
Processing sequence (Example 5, strict mode): Policy A (four-tuple hit) → Policy A (application hit) → Policy A (domain name unidentified) → Policy B (no hit) → Policy C (no hit) → Policy D (four-tuple hit) → Deny
Scenario 3: Destination type is a domain name address book
Policies configured (assume www.aliyun.com resolves to 106.XX.XX.5 and www.example.com resolves to 107.XX.XX.7):
| Policy | Source | Destination | Domain name identification mode | Protocol type | Port | Application | Action | Priority |
|---|---|---|---|---|---|---|---|---|
| Policy A | 192.0.2.0/24 | www.aliyun.com, www.example.com | FQDN-based | TCP | 0/0 | HTTP, HTTPS | Allow | 1 |
| Policy B | 0.0.0.0/0 | 0.0.0.0/0 | — | ANY | 0/0 | ANY | Deny | 2 |
Traffic evaluation:
| Traffic | Source | Destination | Protocol | Port | Application | Domain name | Result |
|---|---|---|---|---|---|---|---|
| Example 1 | 192.0.2.1 | 106.XX.XX.5 | TCP | 80 | HTTP | www.aliyun.com | Stage 1: matches Policy A → Hit. Stage 2: application matches → Hit. Stage 3: domain name matches → Hit. Action: Allow |
| Example 2 | 192.0.2.2 | 107.XX.XX.7 | TCP | 22 | SSH | www.example.com | Stage 1: matches Policy A → Hit. Stage 2: application (SSH) does not match Policy A (HTTP/HTTPS) → No hit. Stage 1: matches Policy B → Hit. Action: Deny |
| Example 3 | 192.0.2.3 | 107.XX.XX.7 | TCP | 22 | Unknown | www.example.com | Stage 1: matches Policy A → Hit. Stage 2: application cannot be identified. Loose mode: Allow by default. Strict mode: continue → Policy B hit → Action: Deny |
| Example 4 | 192.0.2.4 | 106.XX.XX.5 | TCP | 80 | HTTP | Unknown | Stage 1: matches Policy A → Hit. Stage 2: application matches → Hit. Stage 3: domain name cannot be identified. Loose mode: Allow by default. Strict mode: continue → Policy B hit → Action: Deny |
Processing sequence (Example 3, strict mode): Policy A (four-tuple hit) → Policy A (application unidentified) → Policy B (four-tuple hit) → Deny
Processing sequence (Example 4, strict mode): Policy A (four-tuple hit) → Policy A (application hit) → Policy A (domain name unidentified) → Policy B (four-tuple hit) → Deny