DEV Community: rotem levi # Cloud Security

How to Plant Canary Tokens in Your AWS Environment

rotem levi # Cloud Security — Fri, 04 Jul 2025 17:40:05 +0000

Why Cloud Breaches Often Go Undetected

You’ve locked down your IAM roles, hardened your S3 buckets, and turned on GuardDuty — great.
But here’s the problem:
Attackers don’t always trigger alarms.

They quietly browse public buckets.
They find leftover .env files.
They scan for credentials in GitHub repos.
And they move silently, often going undetected for weeks or months.

Canary Tokens

Canary Tokens are small, fake files or credentials designed to look real — but trigger alerts when someone touches them.

They don’t block the attacker.
They don’t interfere with your environment.

They simply whisper:

“Someone's here. You should take a look.”

Tools like Canarytokens.org make it super easy to create these traps — no infrastructure, no cost.

Use Cases in AWS

Want to catch unauthorized access? Try this:

S3 Bucket Trap

Drop a fake creds.txt or .env file in a low-profile S3 bucket.
If someone opens it — boom, you get an alert.

GitHub Canary

Generate a fake AWS Access Key and commit it on purpose to a private (or honeypot) repo.
If someone tries to use it — instant notification.

Lambda or EC2

Place a fake secrets file in EC2 user data or as an environment variable in a test Lambda function.

How to Set One Up (Takes ~60 Seconds)

Go to Canarytokens.org
Choose a token type (.env file, AWS key, QR code, etc.)
Set your email or Slack webhook
Download or copy the token
Place it where attackers might find it
Wait. If it’s accessed — you’ll know.

Extra TIPs

Use realistic names like config_backup.env, not DO_NOT_TOUCH_THIS_TOKEN.txt
Place tokens where attackers actually look — dev folders, buckets, user data, etc.
Rotate tokens occasionally
Integrate alerts with your SOC or Slack #security channel
Never rely on them as your only defense — they’re early warning, not a silver bullet

Final Thought

You don’t need to monitor everything.
You just need one trap in the right place to know someone’s inside.

Start with one token. Place it smart. Sleep a little better.

Securing Your AWS EC2 and S3 Communication: Best Practices for Enhanced Security

rotem levi # Cloud Security — Sun, 10 Nov 2024 08:45:00 +0000

Securing Your AWS EC2 and S3 Communication: Best Practices for Enhanced Security

Cloud security is more crucial than ever, especially in complex environments where numerous resources interact. Ensuring the protection of your AWS architecture requires a multi-layered approach. This blog post will walk you through a practical example using the diagram below to illustrate essential security measures for securing an EC2 instance accessing an S3 bucket.

Overview of the Architecture

The diagram showcases an AWS environment where an EC2 instance communicates with an S3 bucket, with numbered components representing critical security checkpoints. Each number indicates a recommended security measure that fortifies the connection and protects data integrity.

Detailed Breakdown of Security Measures

1. Use IAM Role

Assigning an IAM role to the EC2 instance ensures that it has temporary, secure access to AWS resources without the need for hard-coded credentials. This practice reduces the risk of credential leakage and supports the principle of least privilege.

2. IAM Policy with Least-Privilege Access

Design IAM policies that grant the minimum permissions needed. By implementing least-privilege access, you limit potential damage in case of compromised credentials and keep your AWS environment more secure.

3. Configure Security Group

Security groups act as virtual firewalls for your EC2 instance, allowing you to control inbound and outbound traffic. Ensure that only necessary ports and IP addresses are permitted to minimize exposure to potential threats.

4. Use S3 Gateway Endpoint

Set up an S3 Gateway Endpoint to ensure that data transferred between the EC2 instance and the S3 bucket stays within the AWS network, avoiding exposure to the public internet. This improves the overall security and performance of your environment.

5. Least Privilege S3 Gateway Endpoint Policy

Configure the S3 Gateway Endpoint policy to allow only specific actions and restrict access to authorized resources. This enforces strict access control, making sure that only necessary operations are permitted.

6. Use SSE-KMS with Customer Managed Key

For data at rest, use Server-Side Encryption (SSE) with AWS Key Management Service (KMS). By utilizing a customer-managed key, you maintain control over key rotation, access policies, and auditing. This ensures that sensitive data is encrypted and access is well-regulated.

7. Allow Only Secure Connection

Ensuring that data transfer is secure is paramount. Enforce the use of HTTPS-only connections by:

VPC Endpoint Policy: Configure the policy to require HTTPS traffic using the aws:SecureTransport condition set to true.
Bucket Policy: Apply a policy that mandates secure connections by also using aws:SecureTransport set to true. This guarantees encrypted data transfers and prevents unauthorized access.

8. Configure Bucket Policy – Allow Access Only from S3 Endpoint

Restrict S3 bucket access so that only traffic coming from your specific VPC endpoint is allowed. This ensures that public access is blocked and only internal traffic is permitted, adding an additional layer of security.

9. CloudTrail Logs

Enable AWS CloudTrail to monitor and log all API activity within your environment. CloudTrail provides the necessary audit logs to detect unauthorized actions and support compliance requirements. Reviewing these logs regularly can help you spot anomalies and respond to incidents promptly.

Best Practices and Recommendations

Continuous Monitoring: Integrate AWS services like GuardDuty and AWS Config to monitor for misconfigurations and potential threats.
Regular Policy Reviews: Audit and review IAM and bucket policies periodically to ensure they remain relevant and aligned with best practices.
Enforce MFA: Use multi-factor authentication (MFA) for accessing the AWS Management Console and when making sensitive changes.
Automated Remediation: Implement Lambda functions to automate responses to specific alerts or incidents.

Conclusion

Securing your AWS environment involves more than just initial setup—it requires ongoing vigilance and adaptation to new threats. By applying these security measures, you create a robust defense against unauthorized access and data breaches. Regularly assessing your cloud architecture and refining your security policies will help maintain a secure and compliant environment.

Call to Action

Are there additional security practices you follow? Share your thoughts and insights in the comments. Let’s continue the conversation and keep our cloud environments secure together!

Listing All AWS Lambda functions with Runtime end of support(across all regions)

rotem levi # Cloud Security — Wed, 17 Aug 2022 14:01:00 +0000

In the post, there is an AWS CLI / AWS CloudShell command that lists all Lambda functions that have Runtime end of support.

Script:

runtimes=("dotnetcore3.1" "nodejs12.x" "dotnetcore2.1" "python3.6" "python2.7" "ruby2.5" "nodejs10.x" "nodejs8.10" "nodejs6.10" "nodejs4.3-edge" "nodejs4.3" "nodejs")
for region in `aws ec2 describe-regions --query "Regions[].RegionName" --region us-west-1 --output text`
do
    echo "[${region}]"
    for runtime in ${runtimes[@]}
    do
        aws lambda list-functions --region ${region} --output text --query "Functions[?Runtime=='${runtime}'].{ARN:FunctionArn, Runtime:Runtime}"
    done
done

Usage AWS CLI

export AWS_PROFILE=xxxx # Not necessary if you always set the default profile.
sh ListingLambdaEOS.sh

Usage AWS CloudShell
Just copy the Script and run in your CloudShell.

Output

[eu-north-1]
[ap-south-1]
[eu-west-3]
[eu-west-2]
[eu-west-1]
[ap-northeast-3]
[ap-northeast-2]
[ap-northeast-1]
arn:aws:lambda:ap-northeast-1:111111111111:function:bla   python2.7
arn:aws:lambda:ap-northeast-1:111111111111:function:blalba   python3.6
[ca-central-1]
[ap-east-1]
[ap-southeast-1]
[ap-southeast-2]
[eu-central-1]
[us-east-1]
arn:aws:lambda:us-east-1:111111111111:function:testx node12
[us-east-2]
[us-west-1]
[us-west-2]
arn:aws:lambda:us-west-2:111111111111:function:testz rubi

Reference
Lambda runtimes
AWS Command Line Interface