Notes · AWS · Hardening · Checklist
5 AWS settings attackers hope you skipped (10-minute check)
Five account-level AWS settings that close the most common doors: S3 Block Public Access, IMDSv2 by default, root MFA, an all-Region CloudTrail trail and IAM Access Analyzer.
These five settings won’t make an AWS account secure on their own. But they close the doors I see left open most often, and each one takes about two minutes. Do them once per account.
1. S3 Block Public Access, at the account level
Since April 2023, every new bucket gets Block Public Access turned on and ACLs turned off by default. (AWS)
The catch: buckets created before that keep whatever settings they had. Older accounts are exactly where the forgotten public bucket lives.
Do: S3 → Block Public Access settings for this account → turn on all four options. If something genuinely needs to be public (a static website), serve it through CloudFront with Origin Access Control instead.
2. Make IMDSv2 the default for new EC2 instances
IMDSv1 answers any request from inside the instance, which is why a simple SSRF bug in a web app can be turned into “read this server’s AWS credentials”. IMDSv2 needs a session token first, which blocks most of those tricks.
Since March 2024 you can set IMDSv2 as the default for all new instances in a Region with one account setting. It doesn’t change existing instances. (AWS)
Do: EC2 → Settings → Data protection and security → IMDS defaults → require IMDSv2, in every Region you use. Then watch the MetadataNoTokenRejected metric before you switch older instances over.
3. Root user: MFA on, no access keys
The root user can do everything, and IAM policies can’t limit it. It should be used almost never.
Do: sign in as root once → Security credentials → add MFA (a passkey or hardware key if you can) → delete any root access keys. Then put the root email on a shared, monitored mailbox, not one person’s inbox.
4. One CloudTrail trail, all Regions
CloudTrail’s Event history only keeps 90 days of management events. Breaches are often found later than that. A trail sends events to S3 for as long as you keep them.
Do: CloudTrail → Create trail → apply to all Regions → deliver to an S3 bucket in a separate, locked-down account if you can, with versioning and Object Lock.
5. IAM Access Analyzer for external access
Access Analyzer reads your resource policies and lists everything shared outside your account or organization: S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues and more.
Do: IAM → Access Analyzer → create an external access analyzer (one per Region). Review every finding. Anything you don’t recognise is the first thing to fix.
Next step: check your buckets for the six ways a “private” bucket still leaks. The free checklist below walks through each one with the exact CLI command.
Sources
- AWS What’s New, Apr 2023: S3 applies two security best practices to new buckets by default
- AWS What’s New, Mar 2024: Set IMDSv2 as default for all new instance launches