Tencent Cloud

Recent Pages

Anti-Fraud Guide

Terakhir diperbarui:2024-07-17 16:19:30
Foreword
In recent years, more and more users have uploaded images, videos, and other resources to Cloud Object Storage (COS) when building websites or image hosting platforms. This not only enhances the access stability but also reduces the storage pressure on servers. However, the accompanying problems such as traffic stealing and image hotlink also cause trouble to many developers. If the storage is accessed maliciously, it may incur high traffic fees and lead to unnecessary disputes. These problems can be prevented actually through various protective measures. This document mainly introduces some common protective measures to help developers properly configure buckets, establish security mechanisms, and reduce the risk of significant financial losses due to such problems. 
Protection Schemes
Hotlink can be prevented in many ways, which are distinguished here by configuration difficulty and threshold. Developers can make a choice according to actual situations and requirements.
Basic Protection Schemes
﻿Modifying Bucket Access Permission
﻿
The access permission is one of the most critical and sensitive configurations for buckets. According to incomplete statistics, hotlink occurs mostly because users set the bucket permission to Public Read. Since the public read permission allows anonymous access without a signature, it provides opportunities for the dark industry and attackers. Changing the bucket access permission to private read/write can significantly reduce the hotlink risk, because without the key, the signature cannot be computed and the access will be denied.
In case of no special business requirements, it is recommended to configure the Private Read/Write permission as much as possible. The COS console currently provides 2 options to set the bucket permission:
Bucket Creation Popup
﻿
Bucket Details Page - Permission Management
﻿
﻿
﻿
﻿Enabling Bucket Hotlink Protection
﻿
Hotlink protection is also one of the most common protection methods. Its principle is to make judgment and verification via the HTTP Referer header. Users can configure an allowlist or a blocklist to permit or prohibit certain access sources.
From COS Console - Bucket Details Page - Security Management, you can find the hotlink protection settings:
﻿
Here, it is recommended to set the empty referer configuration to Deny. The allowlist and blocklist can be selected based on actual business situations. For fixed accesses under certain domain names, you can set an allowlist. If malicious accesses are detected and the accessing domain name or IP address is known, you can manually set a blocklist for blocking. For more hotlink protection tips, refer to Hotlink Protection Practice.
﻿Configuring Cloud Monitor Alarms
﻿
Configuring log management can help locate and analyze the hotlink sources. Abundant fields are provided for query, but the drawback is that developers must actively monitor the logs. If you want to detect hotlink problems more promptly, you can configure Cloud Monitor Alarms. Currently, the COS console supports configuring alarms at the same time when a bucket is created:
﻿
If the default alarm policies do not meet your requirements, you can manually create a custom alarm policy in TCOP:
﻿
Go to Alarm Configuration - Alarm Policy, click Create Policy, find COS under Cloud Product Monitoring, and then find the bucket to be configured in the Instance IDs of the alarm object. You can specify the trigger conditions yourself. All metrics displayed on the data monitoring page of the COS bucket can be configured here.
﻿Enabling Log Management
﻿
In the above description about the hotlink protection blocklist, we mentioned "if malicious domain names or IP addresses are detected". Here we need to enable bucket log management. The access logs will record various fields of each request to help us quickly identify the access source.
From COS Console - Bucket Details Page - Log Management, you can find log storage. Once log management is enabled, you can find the access logs under the specified path prefix of the bucket.
﻿
For the fields in the log files, you can refer to Logging Overview documentation. Here are some common analyzable fields:
userSecretKeyId: indicates the access key (KeyId) used by the request. If you confirm that the request wasn't initiated by the business itself, the key might have been leaked. You can go to the Tencent Cloud CAM console to disable the insecure key.
referer: indicates the condition used for judgment in hotlink protection settings. If an unfamiliar referer is found, it may be hotlink by other websites. You can configure Hotlink Protection - Blocklist to restrict accesses by the referer. For enabling bucket hotlink protection, refer to 1.2.
remoteIp: indicates the IP address of the access source. If an untrusted IP address is found, you can go to the Bucket Details Page - Permission Management - Policy Permission Settings, click Add Policy, and configure the policy to prohibit bucket access by the IP address. For example:
﻿
Advanced Protection Schemes
﻿Using Custom CDN Acceleration Domain Name
﻿
Tencent Cloud CDN also provides many configuration items for protection. They can also effectively prevent hotlink.
If the business uses a custom CDN domain name, you can go to the Tencent Cloud CDN console- Domain Details - Access Control Page for configuration. Some common configurations are as follows:
Hotlink Protection Configuration:
﻿
CDN Authentication Configuration:
﻿
IP Blocklist/Allowlist Configuration:
﻿
UA Blocklist/Allowlist Configuration:
﻿
There are also more complex configuration items, such as IP access frequency control configuration and downlink rate limit configuration. You can refer to CDN Console Documentation for usage.
﻿Implementing Auto-Blocking with SCF, Cloud Monitor, and COS APIs
﻿
In basic protection, we mentioned that Cloud Monitor alarms can be configured to detect abnormal traffic in a timely manner. However, sometimes information may be missed or it is inconvenient to handle problems immediately when you're out. In such cases, a simple automation logic can be implemented by calling APIs with automated script code.
Get abnormal public network downlink traffic metrics (InternetTraffic) from Cloud Monitor -> Automatically call COS PutBucketAcl to change the bucket permission to private read/write. The following 2 APIs are mainly involved, and we provide online call samples for debugging reference:
Cloud Monitor's GetMonitorData - Sample Call
COS's PutBucketAcl - Sample Call
Related Suggestions
The above are some common protective measures for hotlink provided in this document. In addition, we must pay attention to some small details in daily use of the COS. Here are some additional usage recommendations that can help reduce the hotlink risk to some extent:
Avoid using plaintext API access keys in the open-sourced code, to prevent key leakage from causing security risks. It is recommended to follow the Principle of Least Privilege.
When configuring cross-domain rules, avoid allowing all sources (i.e., Origin: *) for access. Try to set specific sources instead.
When uploading a large number of files, avoid using too simple sequential prefixes (such as sequence numbers and timestamps), for this could cause attackers to traverse files in the bucket more easily.