Improperly configured access control policies can cause data breaches, Internet exposure, and service interruptions. Understanding how these policies work helps you build a more secure system.
Background
If you do not configure any access control policies, Cloud Firewall allows all traffic by default. After you configure access control policies, Cloud Firewall filters traffic and allows only the traffic that complies with your policies.
Terms
Term | Description |
Matching item | A Cloud Firewall access control policy contains multiple elements, including access type, source, and destination type. Cloud Firewall uses only the source address, destination address, destination port, transport protocol, application-layer protocol, and domain name as matching items. It matches these items one by one against the traffic messages that pass through Cloud Firewall. |
Destination type | The type of destination address in a Cloud Firewall access control policy. It supports different types such as IP, address book, domain name, and region. Note The supported destination types vary by firewall.
|
Four-tuple | In this topic, a four-tuple refers to the source IP address, destination IP address, destination port, and transport protocol. |
Application | An application-layer protocol. The types include HTTP, HTTPS, SMTP, SMTPS, SSL, FTP, IMAPS, and POP3. If you do not know the application type, select ANY. The value ANY specifies all application types. Note Cloud Firewall identifies the application of SSL or TLS traffic based on the port.
|
Layer 7 policy | A policy configured with application and FQDN domain name conditions. |
Expanding logic | When you configure an access control policy, if a configuration item (such as source or port) is set with multiple matching objects, Cloud Firewall expands these objects one by one and generates multiple specific matching rules after the policy takes effect. For example, you can set the port to multiple values, such as 80/80 and 22/22. Cloud Firewall generates a separate matching rule for each port to achieve more granular traffic management. |
Matching logic | The process where Cloud Firewall uses the expand matching rules to determine if network traffic meets the allow conditions and then executes the corresponding policy action based on the matching result. |
If the destination type of an access control policy is a domain name or a domain name address book, you must also understand the following three domain name identification modes:
FQDN-based (extracts Host and SNI fields): Supported only for application types such as HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, and IMAPS. Cloud Firewall uses fields such as Host or SNI in traffic messages to control access to domain names.
DNS-based dynamic resolution: This mode is compatible with specific application types, including but not limited to HTTP, HTTPS, MySQL, and SSH. Cloud Firewall performs dynamic DNS resolution for the domain name and controls access based on the resolved IP addresses. A maximum of 500 IP addresses can be resolved for a single domain name.
Both FQDN-based and DNS-based dynamic resolution: Supported only for application types such as HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, and IMAPS. Cloud Firewall first attempts to identify the domain name from the Host or SNI field in the traffic and combines this information with the results of dynamic DNS resolution. If a match is found using either method, the domain name condition is met, and access control is applied. This mode is suitable for scenarios where one of the seven application types is selected, but some or all of the traffic does not contain a HOST/SNI field.
ImportantThe destination type supports wildcard domain name and wildcard domain name address book objects only when the domain name identification mode is set to FQDN-based (extracts Host and SNI fields).
You must enable strict mode for access control when you select the Both FQDN-based and DNS-based dynamic resolution mode.
In loose mode, if you select one of the seven applications such as HTTP and the traffic does not contain domain name information, the traffic is allowed because the FQDN domain name cannot be identified.
In strict mode, even if the traffic does not contain domain name information, Cloud Firewall still performs dynamic DNS resolution to match the resolved IP addresses, ensuring more precise security control.
Workflow
The access control policy workflow is as follows:
After you create an access control policy, Cloud Firewall expands the policy into one or more matching rules according to the access control policy expanding logic and sends them to the engine.
When traffic passes through Cloud Firewall, it is matched against the policies in order of priority. Based on the result, Cloud Firewall allows or blocks the traffic packets.
If a traffic message hits a policy, Cloud Firewall executes the action for that policy and stops matching. Otherwise, it continues to match against the next-priority policy until a policy is hit or all configured policies have been checked. If the traffic does not hit any access control policy after all policies are checked, the traffic is allowed by default.
Access control policy expanding logic
After you create an access control policy, Cloud Firewall expands it into one or more matching rules based on specific logic and sends them to the engine. Internet firewalls, NAT firewalls, and VPC firewalls support domain name control based on the domain name information in the traffic. The expanding logic for access control policies varies depending on the information identified in the traffic.
After you create, modify, or delete an access control policy, it takes about 3 minutes for Cloud Firewall to send the matching rules to the engine.
When traffic matches an access control policy that has been expanded into multiple matching rules, the traffic is checked against those rules in order. If the traffic hits any of the matching rules, it is considered a hit for the access control policy.
For more information about domain name resolution, see Overview of access control policies.
When the policy destination type is IP, IP address book, or region
When the Destination type of a policy is set to IP, IP address book, or Region, Cloud Firewall expands the source, destination address, protocol type, port, and application based on the number of configured objects.
When the policy destination type is a domain name or domain name address book
When the Destination type of a policy is set to Domain name or Domain name address book, Cloud Firewall determines the domain name identification mode for the policy, expands the policy accordingly, and sends it to the engine.
When the domain name identification mode is set to FQDN-based (extracts Host and SNI fields), the application can only be one or more of HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, or IMAPS, and the protocol type must be TCP. Cloud Firewall sets the destination address of the matching rule to 0.0.0.0/0 and expands the domain name, source, protocol type, port, and application based on the number of configured objects.
When the domain name identification mode is set to DNS-based dynamic resolution, Cloud Firewall resolves the domain name's IP address, sets the destination address in the matching rule to the resolved IP address, and expands the source, destination address, protocol type, port, and application based on the number of configured objects.
If Protocol Type is TCP: Supports various applications such as HTTP, HTTPS, IMAPS, FTP, and ANY.
If Protocol Type is UDP: Only supports applications such as DNS and ANY.
If Protocol Type is ICMP or ANY: Only supports the ANY application.
When the domain name identification mode is set to Both FQDN-based and DNS-based dynamic resolution, the application can only be one or more of HTTP, HTTPS, SMTP, SMTPS, SSL, POPS, or IMAPS, and the protocol type must be TCP. It first attempts to identify the domain name by extracting the Host/SNI from the FQDN and then uses DNS-based dynamic resolution to obtain the destination IP address. Therefore, Cloud Firewall expands the policy into two sets of matching rules that are used to match traffic in order.
ImportantIn loose mode, if the domain name is not identified by extracting the Host/SNI from the FQDN, the traffic is allowed, and the DNS rule is not effective for the unidentified domain name traffic. Therefore, you must enable strict mode when you select Both FQDN-based and DNS-based dynamic resolution.
Sets the destination address of the matching rule to 0.0.0.0/0 and expands the domain name, source, protocol type, port, and application based on the number of configured objects.
Sets the destination address in the matching rule to the resolved IP address and expands the source, destination address, protocol type, port, and application based on the number of configured objects.
Access control policy matching logic
When traffic passes through Cloud Firewall, it is matched against access control policies, threat intelligence rules, basic protection policies, intelligent defense rules, and virtual patching rules. The action for the corresponding rule is then executed based on the matching result. This section describes the logic Cloud Firewall uses during the access control policy matching stage. For more information about the matching order of different stages, see FAQ about traffic analysis.
During the access control policy matching stage, Cloud Firewall matches access control policies sequentially based on the four-tuple (source IP address, destination IP address, destination port, transport-layer protocol), application, and FQDN domain name contained in the traffic.
Traffic that enters the application identification and FQDN domain name identification stages is allowed by default during the identification period (for example, when the application identification status is 'waiting for payload' or 'analyzing'), regardless of the ACL engine mode or policy action. The difference between ACL engine modes is that in loose mode, traffic is continuously allowed for identification if identification fails. In strict mode, if traffic identification fails, the identification process ends, and the traffic flow moves to the next policy matching stage.
If the traffic does not match the current policy, it is either allowed or matched against the next policy.
If the traffic does not match any policy, it is allowed by default.
Four-tuple matching: Cloud Firewall first matches the four-tuple of the traffic. If the policy is hit, it proceeds to match the application and FQDN domain name. Otherwise, it continues to the next-priority policy.
If a next-priority policy exists, the matching process starts over.
If not, the traffic is allowed by default.
Application matching:
Application not specified (ANY application): All traffic is considered a successful application match. The process continues to FQDN domain name matching.
Specific application specified
Traffic application is not identified
In loose mode, the traffic is allowed by default.
In strict mode, matching continues with the next-priority policy until a policy is hit or all policies are checked.
Traffic application is identified
Policy hit: The process continues to FQDN domain name matching.
Not hit: Matching continues with the next-priority policy.
Domain name matching:
Domain name not specified: All domain names are considered a successful match. The policy action is executed.
Specific domain name specified
Traffic domain name is not identified
In loose mode, the traffic is allowed by default.
In strict mode, matching continues with the next-priority policy until a policy is hit or all policies are checked.
Traffic domain name is identified
Policy hit: The policy action is executed.
Not hit: Matching continues with the next-priority policy until a policy is hit or all policies are checked.
Configuration examples
The following examples use access control policies for the Internet Border to demonstrate how policies are matched in different scenarios. This helps you better understand how access control policies work.
Scenario 1: The destination type of the access control policy is an IP address
Assume that the following two policies have been created.
Access control 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
Cloud Firewall expands the access control policies into multiple matching rules based on the expanding logic and sends them to the engine.
When traffic passes through Cloud Firewall, it is matched against the policies in order of priority.
Session traffic
Source
Objective
Protocol Type
Port
Application
Matching result
Example 1
(Match)
192.0.2.1
198.51.100.1
TCP
80
HTTP
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Hit
Executes the action of Policy A: Allow the traffic packet
Example 2
(Source IP does not match)
203.0.113.1
198.51.100.1
TCP
80
HTTP
Matches the four-tuple of Policy A. → Not hit
Matches the four-tuple of Policy B. → Hit
Executes the action of Policy B: Deny the traffic packet
Example 3
(Application not identified)
192.0.2.4
198.51.100.1
TCP
80
Unknown
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Cannot identify traffic application
Checks the current mode.
In loose mode: Allows the traffic by default
In strict mode: Continues to match Policy B
Matches the four-tuple of Policy B. → Hit
Executes the action of Policy B: Deny the traffic packet
Scenario 2: The destination type of the access control policy is a domain name
Assume that the following policies have been created.
Access control policy
Source
Destination
Supported domain name matching mode
Protocol Type
Port
Application
Action
Priority
Description
Policy A
192.0.2.0/24
www.aliyun.com
(FQDN-based)
FQDN-based (extracts Host and SNI fields).
DNS-based dynamic resolution.
Both FQDN-based and DNS-based dynamic resolution.
TCP
0/0
HTTP
HTTPS
Allow
1
The destination domain name of this policy is matched using the Host or SNI field.
Policy B
198.51.100.0/24
www.aliyun.com
(DNS-based dynamic resolution)
DNS-based dynamic resolution
TCP
0/0
SSH
Allow
2
The destination domain name of this policy is matched using the IP address from DNS resolution.
Policy C
203.0.113.0/24
www.aliyun.com
(Both FQDN-based and DNS-based dynamic resolution)
FQDN-based (extracts Host and SNI fields).
DNS-based dynamic resolution.
Both FQDN-based and DNS-based dynamic resolution.
TCP
0/0
SMTP
Allow
3
The destination domain name of this policy is matched using the IP address from DNS resolution.
Policy D
0.0.0.0/0
0.0.0.0/0
None.
ANY
0/0
ANY
Deny
4
None
Cloud Firewall expands the access control policies into multiple matching rules based on the expanding logic and sends them to the engine.
When traffic from your assets passes through Cloud Firewall, it is matched against the policies in order of priority.
NoteAssume that the resolved IP address for www.aliyun.com is 106.XX.XX.5.
Session traffic
Source
Purpose
Protocol Type
Port
Application
Domain Name
Matching result
Example 1
192.0.2.1
106.XX.XX.5
TCP
80
HTTP
www.aliyun.com
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Hit
Matches the domain name of Policy A. → Hit
Executes the action of Policy A: Allow the traffic packet
Example 2
203.0.113.3
106.XX.XX.5
TCP
443
HTTPS
www.aliyun.com
Matches the four-tuple of Policy A. → Not hit
Matches the four-tuple of Policy B. → Not hit
Matches the four-tuple of Policy C. → Hit
Matches the application of Policy C. → Not hit
Matches the four-tuple of Policy D. → Hit
Executes the action of Policy D: Deny the traffic packet
Example 3
198.51.100.1
106.XX.XX.5
(The accessed domain name is www.aliyun.com)
ANY
22
SSH
None
Matches the four-tuple of Policy A. → Not hit
Matches the four-tuple of Policy B. → Hit
Matches the application of Policy B. → Hit
Executes the action of Policy B: Allow the traffic packet
Example 4
192.0.2.2
106.XX.XX.5
(The accessed domain name is www.aliyun.com)
TCP
80
Unknown
None
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Cannot identify traffic application
Checks the current mode.
In loose mode: Allows the traffic by default
In strict mode: Continues to match Policy B
Matches the four-tuple of Policy B. → Not hit
Matches the four-tuple of Policy C. → Not hit
Matches the four-tuple of Policy D. → Hit
Executes the action of Policy D: Deny the traffic packet
Example 5
192.0.2.3
106.XX.XX.5
(The accessed domain name is www.aliyun.com)
TCP
80
HTTP
Unknown
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Hit
Matches the domain name of Policy A. → Cannot identify traffic domain name
Checks the current mode.
In loose mode: Allows the traffic by default
In strict mode: Continues to match Policy B
Matches the four-tuple of Policy B. → Not hit
Matches the four-tuple of Policy C. → Not hit
Matches the four-tuple of Policy D. → Hit
Executes the action of Policy D: Deny the traffic packet
Scenario 3: The destination type of the access control policy is a domain name address book
Assume that the following two policies have been created.
Access control policy
Source
Objective
Supported domain name matching mode
Protocol Type
Port
Application
Action
Priority
Policy A
192.0.2.0/24
www.aliyun.com
www.example.com
(FQDN-based)
FQDN-based (extracts Host and SNI fields).
DNS-based dynamic resolution.
Both FQDN-based and DNS-based dynamic resolution.
TCP
0/0
HTTP
HTTPS
Allow
1
Policy B
0.0.0.0/0
0.0.0.0/0
None.
ANY
0/0
ANY
Deny
2
Cloud Firewall analyzes the access control policies you created and expands Policy A into multiple matching rules.
When traffic passes through Cloud Firewall, it is matched against the policies in order of priority.
NoteAssume that the resolved IP address for www.aliyun.com is 106.XX.XX.5, and the resolved IP address for www.example.com is 107.XX.XX.7.
Session traffic
Source
Objective
Protocol Type
Port
Application
Domain Name
Matching result
Example 1
192.0.2.1
106.XX.XX.5
TCP
80
HTTP
www.aliyun.com
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Hit
Matches the domain name of Policy A. → Hit
Executes the action of Policy A: Allow the traffic packet
Example 2
192.0.2.2
107.XX.XX.7
TCP
22
SSH
www.example.com
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Not hit
Matches the four-tuple of Policy B. → Hit
Executes the action of Policy B: Deny the traffic packet
Example 3
192.0.2.3
107.XX.XX.7
TCP
22
Unknown
www.example.com
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Cannot identify traffic application
Checks the current mode.
In loose mode: Allows the traffic by default
In strict mode: Continues to match Policy B
Matches the four-tuple of Policy B. → Hit
Executes the action of Policy B: Deny the traffic packet
Example 4
192.0.2.4
106.XX.XX.5
(The accessed domain name is www.example.com)
TCP
80
HTTP
Unknown
Matches the four-tuple of Policy A. → Hit
Matches the application of Policy A. → Hit
Matches the domain name of Policy A. → Cannot identify traffic domain name
Checks the current mode.
In loose mode: Allows the traffic by default
In strict mode: Continues to match Policy B
Matches the four-tuple of Policy B. → Hit
Executes the action of Policy B: Deny the traffic packet