CDN:Troubleshoot access control issues

• Cause: URL authentication is enabled on CDN, but the URL that is actually accessed does not carry the signing parameter.

• Solution: If you need the authentication feature, follow Configure URL signing to generate and carry the correct signing parameter for requests. If you do not need the authentication feature, log on to the CDN console and disable URL authentication for the domain name.

• Cause: The URL carries the signing parameter, but the timestamp in the signing parameter has expired. The validity period of a signed URL is determined by the validity duration that you configured. The signing becomes invalid after the validity duration elapses.

• Solution: See Configure URL signing to regenerate the signed URL. If your business pages take a long time to load, you can appropriately extend the signing validity duration.

• Cause: The MD5 value of the signing parameter is calculated incorrectly. This is usually caused by a mismatch between the signature algorithm of your signing code and the requirements of the CDN authentication method.

• Solution: We recommend that you first use the URL generator in the CDN console to generate a signed URL, compare it field by field with the URL generated by your own signing code, and locate the signature difference. For the signature algorithm of each authentication method, see Type A signing. For signing code examples, see URL signing examples.

• Cause: The Referer carried by the request is not in the whitelist, or matches the blacklist. This commonly happens when the whitelist omits the domain name of the site that actually references the resources.

• Diagnosis: In the CDN console, check the Referer blacklist/whitelist configuration of the accelerated domain name and determine whether the Referer of the blocked request matches the rules. You can also download the CDN logs to find the Referer header of the corresponding access record.

• Solution: Add the blocked Referer to the whitelist (or remove it from the blacklist). For the configuration method, see Configure a Referer blacklist or whitelist.

• Cause: Requests in the following scenarios do not carry a Referer (an empty Referer): accessing a resource URL directly from the browser address bar; constructing requests in apps or client programs without setting the Referer header; an HTTPS page referencing HTTP resources, in which case the browser does not send the Referer based on the default Referrer-Policy; the page explicitly setting Referrer-Policy: no-referrer; and using command-line tools such as curl or wget, which do not carry a Referer by default. If Allow direct access to resource URLs from the browser address bar is not selected in the Referer blacklist/whitelist configuration, requests with an empty Referer are blocked.

• Solution: If your business needs to allow access with an empty Referer, select Allow direct access to resource URLs from the browser address bar in the Referer blacklist/whitelist configuration. If you intentionally block empty Referer requests to prevent traffic theft, do not allow them, and see Traffic anomalies and malicious traffic theft to configure more fine-grained mitigation policies. For the configuration method, see Configure a Referer blacklist or whitelist.

After you configure an IP blacklist/whitelist, the CDN node rejects a request and returns a 403 error if the client IP address matches the blacklist or is not in the whitelist. The response header X-Tengine-Error: denied by IP ACL = blacklist indicates that the IP address matches the IP blacklist, and X-Tengine-Error: denied by IP ACL = not in whitelist indicates that the IP address is not in the IP whitelist.

• Diagnosis: First confirm the real public IP address of the client (you can query it by running curl ifconfig.me or curl myip.ipip.net). If requests pass through a proxy or load balancer, the client IP address obtained by CDN may be the proxy IP address rather than the end user IP address, and you need to confirm the client IP address actually identified by the CDN node. In the CDN console, check the IP blacklist/whitelist configuration of the domain name and confirm whether the IP address matches the rules.

• Solution: First confirm whether the block is intended. If you need to allow the IP address, on the Domain Names page in the CDN console, click Manage for the target domain name. In the left-side navigation pane, click Access Control, and adjust the rules in the IP Blacklist/Whitelist section. For the configuration method, see Configure IP blacklist or whitelist. If an IP address in the IP blacklist can still access the resources, see FAQ about access control.

After you configure a UA blacklist/whitelist, the CDN node rejects a request and returns a 403 error if the User-Agent in the request header matches the UA blacklist or is not in the UA whitelist. The response header X-Tengine-Error: black ua indicates that the User-Agent matches the UA blacklist, and X-Tengine-Error: not in white ua indicates that the User-Agent is not in the UA whitelist.

• Diagnosis: Run curl -v <accelerated resource URL> to check the User-Agent value that the request actually sends, or check the request headers in the browser developer tools. In the CDN console, check the UA blacklist/whitelist rules of the domain name and confirm whether the User-Agent matches. Note that the UA blacklist/whitelist supports wildcard matching, so check whether the User-Agent is unexpectedly matched by a wildcard rule.

• Solution: First confirm whether the block is intended. If you need to allow the request, on the Domain Names page in the CDN console, click Manage for the target domain name. In the left-side navigation pane, click Access Control, and adjust the rules on the UA Blacklist/Whitelist tab. For the configuration method, see Configure a User-Agent blacklist or whitelist.

After remote authentication is enabled, the CDN node forwards requests to the authentication server that you specified for verification. Requests are blocked and a 403 error is returned in the following two cases:

• The authentication server returns the Authentication Failure Status Code defined in the configuration (for example, 403). CDN determines that authentication failed and rejects the request.

• Authentication times out (the interaction between the CDN node and the authentication server does not complete within the configured timeout period), and Action After Authentication Timeout is set to Reject.

• Diagnosis: If the 403 error does not belong to any of URL authentication, Referer, IP ACL, or UA ACL described above (the X-Tengine-Error value in the response headers does not match any of them), and remote authentication is enabled for the domain name, you should troubleshoot remote authentication first. In the CDN console, check Authentication Failure Status Code, Authentication Timeout Settings, and Action After Authentication Timeout in the remote authentication configuration of the domain name, and then check the access logs of the authentication server to confirm the status code that the authentication server actually returned and whether timeouts occurred.

• Solution: If the block is not intended, adjust the verification logic of the authentication server or the authentication failure status code configuration. If authentication frequently times out, troubleshoot the performance of the authentication server (the timeout period can be set to a maximum of 3,000 milliseconds), or set Action After Authentication Timeout to Allow based on your business risk assessment. For the configuration method, see Configure remote authentication.

The 403 error is returned by the OSS origin server. There are three common error messages:

• The error You have no right to access this object because of bucket acl: The bucket has private read permissions, and the origin fetch request of CDN does not pass OSS authentication. We recommend that you enable origin fetch authorization for private OSS buckets in the CDN console. For the configuration method, see Configure origin fetch from a private OSS bucket.

• The error You are denied by bucket referer policy: A Referer blacklist/whitelist is configured for the bucket, and the Referer of the origin fetch request of CDN does not match the rules of the bucket. Check the Referer blacklist/whitelist settings of the bucket in the OSS console and allow access from the origin fetch requests of CDN (for example, allow an empty Referer, or add the Referer carried by the origin fetch requests of CDN to the whitelist).

• The error You are forbidden to list buckets: Private bucket origin fetch of CDN and static website hosting of OSS are enabled at the same time, and the two features conflict with each other. Disable one of them: disable origin fetch authorization for private CDN buckets, or disable the static website hosting feature of OSS. For the conflict description, see What can I do if errors arise after I enable access to private OSS buckets and static website hosting?.

• Cause: When CDN performs an origin fetch, the origin host determines which site on the origin server IP address the origin fetch request accesses. If the origin host is configured incorrectly, the request may be matched to a site that does not provide services or that has access restrictions on the origin server, and the origin server returns a 403 error. In addition, the firewall rules, WAF policies, or application-layer access control of the origin server itself may also block the origin fetch requests of CDN.

• Diagnosis: Map the accelerated domain name to the IP address of the origin server by binding the hosts file, access the origin server directly, and verify whether it also returns a 403 error. Check the origin host configuration in the CDN console and confirm that it points to the site that actually provides services on the origin server.

• Solution: Correct the origin host configuration to ensure that the origin host points to the site that actually provides services on the origin server. If the firewall or WAF of the origin server blocks the origin fetch requests of CDN, add the origin fetch IP address ranges of CDN to the whitelist of the origin server. For general troubleshooting methods on the origin server side, see Troubleshooting guide about origin fetch.

Preliminarily confirm it in the following ways:

• Log on to the CDN console and check the bandwidth and traffic trends of the domain name in Monitoring Reports. Check whether abnormal peaks occur outside business hours.

• Download the CDN access logs of the domain name, analyze the IP address distribution, Referer distribution, and User-Agent distribution of access sources, and identify abnormally high-frequency IP address ranges, abnormal Referer sources, or crawler-like User-Agents.

• Check in CloudMonitor whether bandwidth or traffic alerts have been triggered.

We recommend that you take protective measures in advance: configure alarm rules for peak bandwidth and downstream traffic through the alarm settings feature so that you are notified promptly when the thresholds are reached; and configure access control policies such as an IP blacklist, a Referer blacklist, a UA blacklist, or URL authentication based on attack characteristics to block the attacks. For blocking solutions against traffic theft scenarios, see Prevent traffic abuse.

If the domain name has been moved to a sandbox, wait until the attack traffic subsides and then submit a ticket to request removal from the sandbox. To avoid triggering it again, we recommend that you configure the access control policies before the removal.