Network ACL Overview

Network ACL

A network ACL is an optional layer of security for your subnets. After you add inbound and outbound rules to a network ACL and associate subnets with it, you can control traffic in and out of the subnets.

A network ACL is different from a security group. A security group protects the instances in it, such as ECSs, databases, and containers, while a network ACL protects the entire subnet. Security groups are a mandatory layer of protection but network ACLs are optional. Network ACLs and security groups can be used together for fine-grained access control.

You need to specify the protocol, source port and address, and destination port and address for each inbound and outbound rule of the network ACL. Suppose you have two subnets in region A, as shown in Figure 1. Subnet-X01 is associated with network ACL Fw-A, and ECSs deployed in this subnet provide web services accessible from the Internet. Subnet-X02 is associated with network ACL Fw-B. Subnet-X02 and Subnet-Y01 are connected through a VPC peering connection. Now, you need to configure inbound and outbound rules to allow ECS-C01 in Subnet-Y01 to remotely log in to ECSs in Subnet-X02.

Inbound and outbound rules on Fw-A:
Custom inbound rule A01 allows any IP address to access the ECSs in Subnet-X01 through port 80 over TCP or HTTP. If the traffic does not match custom rule A01, the default rule is applied and the traffic is denied to flow into the subnet.

Stateful network ACLs allow responses to inbound requests to leave the subnet without being controlled by rules. The responses from ECSs in Subnet-X01 can go out of the subnet. Other outbound traffic is not allowed to leave Subnet-X01, because the default rule is applied.
Inbound and outbound rules on Fw-B:
Custom inbound rule B01 allows ECS-C01 in Subnet-Y01 to use access the ECSs in Subnet-X02 through port 22 over TCP or SSH.

Custom outbound rule B02 allows all ICMP traffic over any port. The ping traffic from ECSs in Subnet-X02 to ECS-C01 in Subnet-Y01 can be routed successfully to test the network connectivity.

Figure 1 Network ACL rules

The above figure shows how network ACLs control traffic in and out of subnets. In actual services, the security groups control traffic from and to the instances associated with it. For details about network ACLs and security groups, see What Is Access Control?

Network ACL Rules

Network ACL uses inbound and outbound rules to control traffic in and out of subnets.
- Inbound rules: control traffic sent to the instances in a subnet.
- Outbound rules: control traffic from the instances in a subnet to external networks.
You need to define the protocol, source and destination ports, source and destination IP addresses, and other information for network ACL rules.
- Rule number: Network ACL rules are matched in ascending order, from the lowest to highest rule number.
  The default network ACL rule is marked with an asterisk (*) and is the very last rule that will be used for matching.
- Status: Enabled or Disabled. Enabled rules are applied, while disabled rules are not.
- Type: IPv4 or IPv6.
- Action: Allow or Deny. If a request matches a network ACL rule, the action defined in the rule is taken to allow or deny the request.
- Protocol: The protocol to match traffic. The value can be TCP, UDP, or ICMP.
- Source/Destination: The source or destination of the traffic.
  The source or destination can be an IP address, CIDR block, or IP address group.
  - IP address: an IPv4/IPv6 address, an IPv4/IPv6 CIDR block, for example, 192.168.10.10/32 (IPv4 address), 192.168.1.0/24 (IPv4 CIDR block), or 2407:c080:802:469::/64 (IPv6 CIDR block).
  - IP address group: You can add multiple IP addresses with the same security requirements to an IP address group and select this IP address group when you configure a rule.
- Source Port Range/Destination Port Range: The source or destination port or port range, which ranges from 1 to 65535.

How Network ACL Rules Work

After a network ACL is created, you can associate it with one or more subnets to control traffic in and out of the subnets. You can associate a network ACL with multiple subnets. However, a subnet can only be associated with one network ACL.
Network ACLs are stateful. If the network ACL rule allows outbound traffic from your instance, the response to the outbound traffic is allowed to flow in, regardless of the inbound rule settings. Similarly, if inbound traffic is allowed, responses to such inbound traffic are allowed to flow out, regardless of the outbound rule settings.
Network ACLs use connection tracking to track traffic to and from instances. Changes to inbound and outbound rules do not take effect immediately for the existing traffic.
If you add, modify, or delete a network ACL rule, or associate or disassociate a subnet with or from a network ACL, all the inbound and outbound persistent connections will not be disconnected. New rules will only be applied for the new connections.

After a persistent connection is disconnected, new connections will not be established immediately until the timeout period of connection tracking expires. For example, after an ICMP persistent connection is disconnected, a new connection will be established and a new rule will be applied when the timeout period (30s) expires.

The timeout period of connection tracking varies by protocol. The timeout period of a TCP connection in the established state is 600s, and that of an ICMP connection is 30s. For other protocols, if packets are received in both inbound and outbound directions, the connection tracking timeout period is 180s. If packets are received only in one direction, the connection tracking timeout period is 30s.
The timeout period of TCP connections varies by connection status. The timeout period of a TCP connection in the established state is 600s, and that of a TCP connection in the FIN-WAIT state is 30s.

Each network ACL has the default inbound and outbound rules, as shown in Table 1. If no custom rules are configured, the default rules are applied to deny all inbound and outbound traffic. You can use the default rules only when there is no need for traffic to go in and out of the subnet. If the traffic needs to go in and out of the subnet, you need to add custom rules to control traffic as required.

**Table 1** Default network ACL rules
Direction	Rule Number	Action	Protocol	Source	Source Port Range	Destination	Destination Port Range
Inbound	*	Deny	All	0.0.0.0/0	All	0.0.0.0/0	All
Outbound	*	Deny	All	0.0.0.0/0	All	0.0.0.0/0	All

The default and custom rules of a network ACL does not block the traffic described in Table 2.

**Table 2** Traffic not blocked by network ACL rules
Direction	Description
Inbound	Traffic between the source and destination in the same subnet
	Broadcast traffic to 255.255.255.255/32
	Multicast traffic to 224.0.0.0/24
Outbound	Traffic between the source and destination in the same subnet
	Broadcast traffic to 255.255.255.255/32
	Multicast traffic to 224.0.0.0/24
	TCP metadata traffic to 169.254.169.254/32 over port 80
	Traffic to 100.125.0.0/16 that is reserved for public services on the cloud, such as the DNS server address and NTP server address.

How Traffic Matches Network ACL Rules

A subnet can be associated with only one network ACL. When there are multiple rules on the network ACL, rules are matched in ascending order, from the lowest to highest rule number. The default network ACL rule is marked with an asterisk (*) and is the very last rule that will be used for matching.

The following takes inbound traffic as an example to describe how the rules are applied.

If a custom rule is matched:
- When Action is set to Deny, the traffic is denied to access the subnet.
- When Action is set to Allow, the traffic is allowed to access the subnet.
If no custom rule is matched, the default rule is applied and the traffic is not allowed to access the subnet.

Figure 2 Network ACL matching

How Network ACLs Are Used

A network ACL controls traffic in and out of a subnet. If both security group and network ACL rules are configured, traffic is matched against network ACL rules first and then security group rules. You can add security group rules as required and use network ACLs as an additional layer of protection for your subnets. The following provides some examples on how network ACLs can be used.

In Figure 3, ECS-A01 and ECS-A02 in Subnet-A need to communicate with each other, and the instance with the IP address 10.1.0.5/32 needs to be whitelisted to allow it to remotely log in to ECS-A01 and ECS-A02 to perform O&M operations. The whitelisted instance can be a local PC, an instance in a different subnet of VPC-A, or an instance in another VPC. You need to configure network ACL and security group rules to allow the whitelisted instance to access ECSs in VPC-A and deny any other traffic.

Network ACL rules:
- Inbound rule: Custom rule A01 allows the whitelisted instance to remotely log in to the instances in Subnet-A over SSH. The default rule denies any other traffic to the subnet.
- Outbound rule: Network ACLs are stateful. The responses to inbound requests are allowed to leave the subnet. This means you do not need to additionally add outbound rules to allow such response traffic. The default rule denies any other outbound traffic.
Security group rules:
- Inbound rule: Rule A01 allows the whitelisted instance to remotely log in to instances in Subnet-A over SSH. Rule A02 allows instances in the security group to communicate with each other. Other traffic is denied to access the instances in security group Sg-A.
- Outbound rule: Rule A03 allows instances in Sg-A to access external resources.

Figure 3 Controlling external access to instances in a subnet

If you set loose security group rules, network ACL rules can add an additional layer of protection. As described in Table 3, the security group rule allows any IP address to remotely log in to instances in the security group. The inbound rule of Fw-A associated with Subnet-A allows only the specified IP address (10.1.0.5/32) to access instances in Subnet-A. The default rule denies other traffic to the subnet, eliminating possible security risks.

**Table 3** Security group rules
Direction	Priority	Action	Type	Protocol & Port	Source	Description
Inbound	1	Allow	IPv4	TCP:22	IP address: 0.0.0.0/0	Allows any IP address to remotely log in to instances in the security group using SSH

For more network ACL examples, see Network ACL Configuration Examples.

In Figure 4, VPC-X has two subnets: Subnet-X01 and Subnet-X02. ECS-01 and ECS-02 work in Subnet-X01, and ECS-03 works in Subnet-X02. Suppose you want to:

Connect ECS-02 to ECS-03.
Isolate ECS-01 from ECS-03.

To achieve this purpose, you need to configure security group and network ACL rules as follows:

Add inbound and outbound rules to Sg-A to ensure that the ECSs in this security group can communicate with each other.
The subnet has not been associated with a network ACL, so after the security group rules are added, both ECS-01 and ECS-02 can communicate with ECS-03.
Associate Subnet-X01 and Subnet-X02 with Fw-A.
If there is only the default rule in Fw-A, instances in the same subnet can communicate with each other, while instances in different subnets are isolated from each other. In this case, ECS-01 and ECS-02 can communicate with each other, while ECS-01 and ECS-03 as well as ECS-02 and ECS-03 are isolated from each other.
Add custom rules to Fw-A to allow ECS-02 to communicate with ECS-03.
- Add custom rule A01 to allow ECS-03 to access Subnet-X01.
- Add custom rule A02 to allow ECS-02 to access Subnet-X02.
- Add custom rule A03 to allow traffic destined for ECS-03 to leave Subnet-X01.
- Add custom rule A04 to allow traffic destined for ECS-02 to leave Subnet-X02.

Figure 4 Controlling communications between instances in different subnets

For more network ACL examples, see Network ACL Configuration Examples.

Network ACL Configuration Procedure

Figure 5 Procedure for configuring a network ACL

**Table 4** Procedure for configuring a network ACL
No.	Step	Description	Reference
1	Create a network ACL.	A network ACL comes with default inbound and outbound rules to deny traffic in and out of a subnet. The default rules cannot be deleted or modified.	Creating a Network ACL
2	Add inbound and outbound rules.	You can add custom rules to control traffic in and out of a subnet. Traffic will be preferentially matched against the custom rules.	Adding a Network ACL Rule
3	Associate the network ACL with one or more subnets.	You can associate the network ACL with one or more subnets. If it is enabled, it controls traffic in and out of the subnets. A subnet can be associated with only one network ACL.	Associating Subnets with a Network ACL

Notes and Constraints

By default, each account can have up to 200 network ACLs in a region.
A network ACL can have no more than 100 rules in one direction, or performance will deteriorate.
For each network ACL rule, up to 124 rules can have IP address groups associated in either inbound or outbound direction.

For inbound network ACL rules, the sum of the rules with Source set to IP address group, of the rules with Destination set to IP address group, of the rules with Source Port Range set to inconsecutive ports, and of the rules Destination Port Range set to inconsecutive ports, cannot exceed 120. If there are both IPv4 and IPv6 network ACL rules, up to 120 rules can be added for each type.

The limits on outbound network ACL rules are the same as those on inbound network ACL rules.

For example, to add inbound IPv4 rules to a network ACL, you can refer to Table 5 for rules that meet the restrictions. Of these rules, rule A02 uses inconsecutive ports (22-24,25) as the source port range and IP address group ipGroup-A as the source. In this case, only one quota is occupied.

**Table 5** Inbound network ACL rules
Rule No.	Rule Number	Type	Action	Protocol	Source	Source Port Range	Destination	Destination Port Range
Rule A01	1	IPv4	Deny	TCP	0.0.0.0/0	22,25,27	0.0.0.0/0	1-65535
Rule A02	2	IPv4	Allow	TCP	IP address group: ipGroup-A	22-24,25	0.0.0.0/0	1-65535
Rule A03	3	IPv4	Allow	All	0.0.0.0/0	All	IP address group: ipGroup-B	All
Rule A04	4	IPv4	Allow	UDP	0.0.0.0/0	1-65535	0.0.0.0/0	80-83,87

Traffic from load balancers is not restricted by network ACL and security group rules if:
Transfer Client IP Address is enabled for the listener of a load balancer.

The load balancer can still forward traffic to backend servers, even if there is a rule that denies traffic from the load balancer to the backend servers.