Classic Load Balancer (CLB) access control filters client requests by using IP whitelists and blacklists on listeners. You can create an access control list (ACL), add IP entries to it, and then associate the ACL with a listener to allow or block traffic from specific sources.
Create an access control list
An access control list (ACL) is a collection of IP entries. After you create an ACL and add IP entries, you can associate it with a listener to implement whitelist or blacklist-based access control.
Console
-
Go to the Access control page of the CLB console. In the top navigation bar, select the region of the target instance, and then click Create ACL.
-
In the Create ACL panel, enter an ACL Name, select an IP Version (IPv4 or IPv6), add IP entries, and then click Create.
IPv4 instances support only IPv4 access control lists (ACLs), and IPv6 instances support only IPv6 ACLs. Select the IP version that matches your CLB instance.
API
Call the CreateAccessControlList operation to create an ACL.
Add IP entries
After you create an ACL, you can add IP entries to it.
Console
Go to the Access control page of the CLB console and click the ID of the target ACL to go to the details page. Add IP entries in one of the following ways:
-
Add a single entry: Click Add Entry. Enter an IP Address/CIDR Block and Remarks, and then click Add.
-
Add entries in batches: Click Add ACL Entries and enter the entries in the following format:
-
Enter one entry per line.
-
Use a vertical bar (|) to separate the IP address or CIDR block from its remarks. Example: 192.168.1.0/24|Remarks.
-
You can add up to 50 entries at a time.
-
After you add the entries, you can delete or export them from the entry list.
API
-
Call the AddAccessControlListEntry operation to add IP entries.
-
Call the RemoveAccessControlListEntry operation to delete IP entries.
Enable or disable access control
After you create an ACL and add IP entries, associate the ACL with a listener to enable access control. If you no longer need access control, you can disable it at any time.
-
If an ACL is empty, access control has no effect and the listener forwards all requests, regardless of whether it is configured as a whitelist or a blacklist. To prevent service disruptions when using a whitelist, ensure the ACL contains the IP addresses that you want to allow.
-
IP entries must be unique across all ACLs associated with a single listener.
Console
-
Go to the Instances page of the CLB console. In the top navigation bar, select the region where the target instance is deployed, and then click the instance ID.
-
Click the Listener tab. Find the target listener, and click Enable or Close in the ACL column.
-
Enable: In the dialog box that appears, select an Access Control Mode (Whitelist: Allows Specified IP Addresses to Access the SLB Instance or Blacklist: Forbids Specified IP Addresses to Access the SLB Instance) and select an ACL, and then click Save.
-
Close: In the confirmation dialog box, click OK.
-
You can also enable or disable access control in the Access Control section of the listener details page.
You can also enable access control when you create a listener.
API
When you call an API operation to create or modify a listener, such as CreateLoadBalancerHTTPSListener or SetLoadBalancerHTTPSListenerAttribute, use the following parameters to configure access control:
-
AclStatus: Specifies whether to enable access control. Valid values:
onandoff. -
AclType: The type of the ACL. Valid values:
white(for a whitelist) andblack(for a blacklist). -
AclId: The ID of the associated ACL.
FAQ
Whitelist allows access from any IP
Cause: The ACL is not associated with the listener (access control is not enabled), or the ACL contains no IP entries. An empty ACL allows all traffic.
Solution: Go to the Listener tab for the CLB instance. Make sure that Enabled is displayed in the ACL column for the target listener, and verify that the associated ACL contains IP entries.
Blacklisted IPs can still access
Cause: Requests are forwarded to CLB through a proxy, such as a Content Delivery Network (CDN) or Web Application Firewall (WAF). The source IP address that CLB sees is the source IP of the proxy, not the real client IP. Therefore, blacklist rules based on client IPs will not match.
Solution: Configure an IP blacklist on the upstream proxy layer (CDN or WAF). If clients can bypass the proxy and access CLB directly, you can configure a whitelist on CLB to allow access only from the proxy's source IP range.
NGINX allow/deny rules ineffective for Layer-7 listeners
Cause: After a CLB Layer-7 listener proxies a request, the backend server receives an internal source IP address from CLB (from the 100.64.0.0/10 CIDR block). The NGINX allow/deny rules, which are based on source IP addresses, cannot match the real client IP.
Solution:
-
(Recommended) Use the CLB access control feature to configure an IP whitelist or blacklist directly on the CLB listener.
-
Configure NGINX to retrieve the real client IP from the
X-Forwarded-Forrequest header and then apply allow/deny rules based on that IP. For more information, see Obtain the real client IP on backend servers through a CLB Layer-7 listener.
ECS security groups do not block CLB traffic
Cause: CLB communicates with backend ECS instances over the 100.64.0.0/10 CIDR block. By design, traffic from this CIDR block bypasses the inbound rules of ECS security groups.
Solution: To restrict access based on client IP addresses, configure a whitelist or blacklist on the CLB listener to block requests before they are forwarded.
Client response to blocked requests
Explanation: CLB access control drops blocked requests without sending any response. The client connection times out.
Can a whitelist prevent DDoS attacks?
Explanation: No. CLB access control cannot protect against DDoS attacks. Attack traffic consumes instance bandwidth before it reaches the access control layer, which can trigger blackhole filtering in severe cases.
Recommendation: Use Anti-DDoS.
Access control in multi-layer proxy scenarios
If a Layer-7 proxy is deployed in front of CLB, CLB access control can only see the source IP of the immediate upstream proxy and cannot identify the real client IP. In this case, you must configure access control at the appropriate layer. Take a scenario where WAF is connected via CNAME (Client → CDN → WAF → CLB → ECS) as an example. The following table describes the observed source IP and recommended access control strategy for each layer.
In cloud service integration (transparent integration) mode, the system automatically adjusts the underlying network routing to direct traffic from the CLB listener port to WAF for security inspection. WAF intercepts malicious requests and forwards legitimate traffic back to the source CLB instance. This mode does not use a dedicated WAF source IP range, so no extra configuration is needed for CLB access control.
|
Layer |
Observed source IP |
Access control recommendation |
|
WAF |
|
Configure an IP whitelist or blacklist at this layer. After WAF is correctly configured, it can block requests based on the real client IP and supports region-based blocking. |
|
CLB |
The WAF source IP. |
Configure a whitelist on CLB to allow access only from the WAF source IP range. This prevents attackers from bypassing WAF and accessing the public IP of CLB directly. You can view the WAF source IP range on the Manage page of the WAF console. |
|
Backend ECS |
An internal IP address of CLB (from the 100.64.0.0/10 CIDR block). |
Make sure that the internal firewalls on your ECS instances (such as iptables or firewalld) do not block traffic from the 100.64.0.0/10 CIDR block. Otherwise, health checks and request forwarding will fail. |
Billing
The access control feature is free of charge. For details on CLB instance billing, see CLB billing overview.
Quotas
You can request to increase the following quotas in Quota Center.
|
Limit |
Quota name |
Default limit |
Request an increase |
|
Number of ACLs per Alibaba Cloud account |
slb_quota_acls_num |
200 | |
|
Number of entries per ACL |
slb_quota_acl_entries_num |
300 |
|
|
Number of listeners per ACL |
slb_quota_acl_attached_num |
50 |
The following limits are fixed and cannot be increased.
|
Limit |
Maximum value |
|
Number of ACLs per listener |
3 |
|
Total IP entries across all ACLs associated with a listener |
1000 |