Byte #002: Securing AWS S3 Buckets with YES3 Scanner

Hi there 😊

I just finished a hands-on lab where I learned how to find and fix common security mistakes in Amazon S3 (Simple Storage Service) buckets using an open-source tool called YES3 Scanner. If you’re new to AWS security or curious how automated checks work, this step-by-step guide is for you. (Full lab steps are also available on the Cybr website.)

Why S3 Security Is Important

S3 is where many teams store files, backups, or logs in the cloud. If you don’t lock down your buckets properly, anyone on the internet could download or delete your data or worse, drop in ransomware.

This lab showed me:

• How quickly misconfigurations add up.

• How a few simple fixes cut your risk in half.

• Why automating scans saves time and headaches.

Lab Setup in a Nutshell

IAM user: Pre-configured AWS identity with permission to inspect and update one S3 bucket.

Target bucket: Intentionally misconfigured to simulate a real-world mistake.

Tool: YES3 Scanner (GitHub: FogSecurity/YES3-Scanner).

Shell: AWS CloudShell (no software install on your laptop needed).

Reference: Full step-by-step instructions on the Cybr website.

Running the First Scan

In CloudShell I ran:

git clone https://github.com/FogSecurity/YES3-Scanner.git 
cd YES3-Scanner 
pip install -r requirements.txt --user 
python3 yes3.py --region us-east-1

About 10 seconds later, the scanner printed a list of warnings:

• Account-level “Block Public Access” was OFF.

• Bucket policy allowed public access.

• Versioning disabled.

• Object Lock disabled.

• Server access logging disabled.

These misconfigurations can leave your data exposed or unrecoverable after a mistake or attack.

What Those Warnings Mean

Block Public Access: A set of guardrails that prevent any public-facing settings.

Bucket Policy: A JSON document that can grant wide-open permissions.

Versioning: Keeps older copies of files so you can roll back accidental or malicious deletes.

Object Lock: Prevents deletion or overwrite of objects for a set retention period.

Access Logging: Records who accessed your bucket and when. This is very important for audits and forensics.

Fixing these quickly can drastically reduce your potential impact.

Fixes in the AWS Console

I fixed the three highest-impact issues first:

1. Enable Versioning

   • S3 Console > Properties > Bucket Versioning > Enable

2. Block All Public Access

   • Permissions > Block public access (bucket settings) > check Block all public access > Save

3. Remove Public Bucket Policy

   • Permissions > Bucket Policy > Delete

These three clicks took under two minutes and immediately cut potential exposure.

Re-Running the Scan to Confirm

Back in CloudShell:

python3 yes3.py --region us-east-1

Now the results showed:

• No public buckets

• Versioning enabled

• Bucket-level Block Public Access: all PASS

Running a quick scan, fixing the issues, and scanning again showed me the bucket was secure. The only warnings left were account-level settings I can’t change, but now I know exactly what to ask the cloud-ops team to handle.

Takeaways for Your Team

• Running a quick automated scan can spot problems you’d miss by clicking around.

• Turning on versioning and blocking public access are the fastest ways to make your bucket safer.

• Always scan, fix, and then scan again to be sure your changes worked.

• Adding these scans into your build pipeline keeps new buckets secure from the start.

• Check your setup regularly so old mistakes don’t sneak back in.

Final Thoughts

Working through this S3 lab with YES3 was a great reality check. Seeing those initial warnings and then quietly fixing them one by one reminded me that these small changes really add up.

If you’ve ever wondered whether your buckets are as secure as you think, I’d love to hear your experiences.

Thanks for following along, and I hope this helps you feel a bit more confident the next time you glance at your S3 console.

Until the next byte,

Bye! 💜