How to reduce the risk of financial loss from malicious traffic - Object Storage Service

Malicious attacks or fraudulent traffic targeting your buckets can cause sudden spikes in bandwidth and data transfer, leading to unexpectedly high bills. Follow these security best practices to reduce the risk of costly incidents.

Important

These best practices are general recommendations, not a comprehensive security solution. They may not suit your specific environment or requirements. Incorporate them into a broader security strategy and remain vigilant about data and content protection.

Risks of significant financial loss

Malicious attacks or fraudulent traffic on your bucket can lead to the following financial risks:

High bills: Malicious attacks consume your Object Storage Service (OSS) bandwidth, and you are responsible for the resulting charges.
Bills that exceed your account balance: OSS is a pay-as-you-go service, and bill amounts are affected by factors such as billing cycles and processing delays. Therefore, the service cannot be suspended immediately when your account balance reaches zero. This may result in an overdue payment. If your bucket is targeted by a malicious attack or experiences traffic theft, you may incur high charges. The associated risk is that the billed amount will often exceed your account balance.

Block public access

OSS allows public access through bucket policies and ACLs, which means anyone can access your resources without authentication. This creates risks of data breaches and high traffic costs from malicious activity. To mitigate these risks, OSS provides a one-click Block Public Access feature at the global, bucket, access point, or Function Compute access point level. Once enabled, Block Public Access overrides existing public permissions and prevents new ones from being created, securing your data from public exposure. For more information, see Block Public Access.

Access OSS resources through PrivateLink

PrivateLink establishes a secure, private connection between your VPC and OSS, avoiding the security risks of public internet access. A private connection enhances data security and reduces the risk of excessive costs from malicious traffic. The benefits include:

Isolation: PrivateLink ensures that your OSS resources are accessible only from within your authorized VPC, preventing internet-based attacks.
Permission control: A VPC endpoint lets you apply fine-grained access controls, such as restricting access to specific IP addresses or subnets, or enforcing specific security group rules.
Traffic monitoring: Services deployed within your VPC allow better monitoring and management of network traffic, enabling you to quickly detect anomalies and prevent malicious access.

For more information, see Access OSS through PrivateLink.

Set ACL permissions to private

Do not set the access control list (ACL) of a bucket or object to public-read or public-read-write unless anyone must be able to read or write your OSS resources. The following permissions apply if you grant public access:

public-read-write: Anyone can read and write objects in the bucket.

Warning
This allows any user on the internet to access your objects and upload new objects to your bucket. This can lead to data exfiltration, unexpected cost surges, and potential legal issues if malicious or illegal content is uploaded. Unless absolutely necessary for a specific use case, we strongly recommend against granting public-read-write permissions.
public-read: Only the bucket owner can write objects to the bucket, but anyone can read the objects.

Warning
This allows any user on the internet to access your objects, which can lead to data exfiltration and unexpected cost surges. Use this permission with caution.

To avoid these security risks, we strongly recommend setting the ACL for your buckets and objects to private. Before changing an ACL to private, verify that the change does not affect your applications or services.

For detailed steps, see Set bucket ACL and Set object ACL.

Configure CloudMonitor alert rules

Create alert rules in CloudMonitor to monitor your OSS resource usage and status. When a metric exceeds a predefined threshold, CloudMonitor sends an alert so you can quickly identify and address anomalies.

For example, you can configure an alert rule for a bucket that triggers when a metric such as public inbound or outbound traffic reaches 100 MB or more within one minute. The alert information is then written to a specified Logstore in Simple Log Service.

The following example shows how to configure an alert rule triggered when public inbound traffic reaches 100 MB or more:

In the Create Alert Rule dialog box, set Product to Object Storage Service (OSS), Resource Range to Instance, and Associate Resources to examplebucket. Set Rule Name to alert and the alert condition to (Bucket)Public Inbound Traffic ≥ 100 Mbytes for one consecutive period. Set Mute For to 24 hours and Effective Period from 00:00 to 23:59. Select group1 for Contact Group. In Advanced Settings, enable Simple Log Service. For Region, select China (Hangzhou) and configure the corresponding ProjectName and Logstore. Leave other options such as Auto Scaling, Message Service (MNS)—topic, and Function Compute disabled. For Method to Process No Data, select Do not process.

You can configure alert rules for a specific bucket or for all OSS resources under your Alibaba Cloud account. For more information, see Create an alert rule.

Configure hotlink protection

Configure Referer-based access rules in OSS to prevent unauthorized referrers from accessing your objects. This blocks hotlinking from other websites and protects you from unnecessary traffic costs.

When a browser sends a request to OSS, the request header includes a Referer that indicates the source. If hotlink protection is configured, OSS evaluates the Referer against the configured rules to allow or deny the request:

If the Referer in the request matches an entry in the blacklist or does not match any entry in the whitelist, OSS denies the request.
If the Referer in the request matches an entry in the whitelist, OSS allows the request.

For example, consider a bucket with a Referer whitelist that contains https://10.10.10.10.

User A embeds an image, test.jpg, stored in the bucket on the website https://10.10.10.10. When a browser requests this image, the request header includes https://10.10.10.10 as the Referer. In this case, OSS allows the request.
User B hotlinks the test.jpg image and embeds it on the website https://192.168.0.0. When a browser requests this image, the request header includes https://192.168.0.0 as the Referer. In this case, OSS denies the request.

For more information, see Hotlink protection.

Configure cross-origin resource sharing (CORS)

Cross-origin resource sharing (CORS) is a standard mechanism that lets web servers control access from different origins to ensure secure cross-origin data transfers. Browsers enforce a same-origin policy to isolate potentially malicious files. By default, a browser blocks a request if JavaScript code from one origin attempts to access a resource from a different origin.

OSS lets you configure CORS rules to permit or deny cross-origin requests. For example, to permit only requests from the origin www.aliyun.com with the cross-origin request method GET, configure the CORS rule as follows:

In the Create CORS Rule dialog box, leave Allowed Headers and Exposed Headers empty. Set Cache Time (s) to 0, and leave Vary: Origin unchecked.

For more information, see Configure CORS.

Avoid using sequential prefixes for object names

When you upload a large number of objects, using predictable, sequential prefixes such as timestamps, alphabetical sequences, dates, or numeric IDs lets attackers guess and retrieve all your objects by iterating through the naming pattern. This can lead to data leaks. Add a random hexadecimal hash prefix to your object names or reverse the characters of the name to significantly reduce the risk of object name enumeration. For more information, see Data security.