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.
- 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.
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.
- Priority: Indicates the priority of a rule. Rules are given sequence numbers and traffic is matched against the rules based on their priority. A smaller number indicates a higher priority. A rule with a higher priority is preferentially applied over a rule with a lower priority.
The priority of the default rule on network ACL is *. The default rule has the lowest priority.
- 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.
- Priority: Indicates the priority of a rule. Rules are given sequence numbers and traffic is matched against the rules based on their priority. A smaller number indicates a higher priority. A rule with a higher priority is preferentially applied over a rule with a lower priority.
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.
- 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 bound to only one network ACL. When there are multiple rules on the network ACL, rules are applied based on their priority. A smaller number indicates a higher priority. The value of the default rule priority is *, which has the lowest priority.
- 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.
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.
- 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.
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.
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.
- Connect ECS-02 to ECS-03.
- Isolate ECS-01 from ECS-03.
- 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.
For more network ACL examples, see Network ACL Configuration Examples.
Network ACL Configuration Procedure
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. |
|
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. |
|
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. |
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.
Priority
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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot