Protect your S3 bucket in a right way
Sometimes you dont have enough time to properly configure the devices and services you use. Manufacturers are trying to make the setup process quick and easy, providing an option to make important changes later. And if you just click the “Next” button several times, youll get a working, but not necessarily a security-compliant environment.
AWS Simple Storage Service (S3) is used in a wide variety of business fields. Today, S3-related private leaks are highlighted in different reports almost every week, so its important to understand the consequences of such negligence.
An improperly configured S3 can lead to viewing, uploading, modifying, or deleting S3 objects by third parties. To prevent S3 data loss or exposure and unexpected charges on your AWS bill, you need to grant access only to trusted entities by implementing the appropriate access policies recommended in this conformity rule. Bruteforce tools are already scanning all possible bucket names, analyzing configurations letter by letter and getting closer to your information every minute.
Time is crucial, so you dont even need to read all the documentation to be safe. Here are some AWS tools and step-by-step instructions to detect these critical security flaws.
First, answer these questions about data you want to store in your S3 bucket to make security policies applicable to your environment:
You can also use 2 options from AWS for deeper analysis:
These tools are great, but there are some pitfalls you should know about.
Each region for AWS Config has separate rules. So you may miss the security check for your public bucket if you run it within only one region.
Attention! If you run all 38 security/compliance checks and leave it for a day or two, then Amazon will charge you ~ $76 per region monthly. Since there are 14 regions, to monitor all their rules will cost you $12,768 a year! Choose wisely.
The basic AWS Trusted Advisor plan gives you access to the 6-core Trusted Advisor analysis; however other checks are available only for billable AWS support.
Now Kromtech is developing a free tool to check security for public S3 buckets in a better way. We have also provided the free guide below on how to quickly check your security gaps using Amazon commercial instruments.
This is our commitment to securing the internet and protecting customers around the globe.
The AWS Trusted Advisor service comes free with your AWS account. It provides not only security checks, but also cost optimization, performance, and fault tolerance checks. Simply visit console.aws.amazon.com/trustedadvisor/.
This is the list of free features:
Security Groups - Specific Ports Unrestricted
Amazon EBS Public Snapshots
Amazon RDS Public Snapshots
MFA on Root Account
Other important security checks are available as part of a paid support plan.
There are some other great security checks provided by AWS Trusted Advisor:
Checks S3 buckets for unplanned public access
Checks if Cloudtrail is on
Checks if IAM keys have been rotated in the past 90 days
Checks if a password policy is set
Various Security Group checks, such as specific ones to ensure RDS databases are not exposed
Checks Route53 for each MX record, and ensures a TXT record contains a corresponding SPF value to deny email spoofing
Checks if ELB listeners use good SSL policies
Checks if SSL certificates will expire soon
Checks for exposed access keys
If you dont have AWS Trusted Advisor, then use AWS Config. It costs $0.003 per Configuration Item recorded and $2 per active Config Rule monthly per each used region.Use AWS Config logs to understand how an account operates.
To open AWS Config you can:
Go to SERVICES - Management Tools and select AWS Config
Or follow this link https://console.aws.amazon.com/config/
We recommend activating only needed rules. As our primary task is to secure our buckets please select S3 specifics here.
Rule details are shown after being added:
This is how the Config Dashboard should appear:
Drill-down on rule details for s3-bucket-public-read-prohibited will show you a similar picture:
Now you can change permission to avoid leakage for Noncompliant resources.
So how did your bucket suddenly become public?
DevOps engineers usually like to grant public access to buckets because they need to get something up and running quickly and don't want to spend time configuring access controls and security-related issues. Also, developers want to test their code, so its easier for them to make the bucket public and dive into the work.
However, there are many other people who simply want their stuff to work, without worrying about access controls and security. This approach often results in leakages, data loss, and reputational damage in case a bucket such as this suddenly gets deployed in production.
When we discover an image like this, it might be quite promising:
For detection and removal of any S3 buckets that allow unknown cross-account access, do the following:
Sign in to the AWS Management Console.
Navigate to the S3 dashboard at https://console.aws.amazon.com/s3/.
Select the S3 bucket you want to examine:
In the Bucket panel, click the Permissions tab and uncheck the Access Control List (ACL) for any grantee named "Everyone". Click on it and youll see this:
The grantee called "Everyone" is the predefined group that allows access to anonymous users. Make the needed changes and save.
Repeat steps 2-4 for each S3 bucket that you want to examine. These are listed in your AWS account.