Forem: Javier Seng

Building a Cloud-Native S3 Honeypot Detection Pipeline on AWS

Javier Seng — Sat, 17 May 2025 12:59:57 +0000

Building a Cloud-Native S3 Honeypot Detection Pipeline on AWS

Table of Contents

Introduction
Step 1: Deploy a Private Honeypot Bucket
Step 2: Log S3 Data Events with CloudTrail → CloudWatch
Step 3: Create a CloudWatch Metric Filter
Step 4: Alarm & SNS Notification
Step 5: Lambda Automation to Tag VPC
Testing the Pipeline
Next-Level Enhancements
Conclusion

Introduction
In this blog post, I’ll demonstrate how to build an end-to-end honeypot detection pipeline on AWS—catching unauthorized access to a decoy S3 file, alerting the team, and automatically tagging the attacker’s VPC. We’ll leverage AWS-native services like S3, CloudTrail, CloudWatch, Lambda, and SNS to create a turnkey security solution.

Step 1: Deploy a Private Honeypot Bucket
Create your S3 bucket

Name: javierlabs-sensitive-docs
Region: ap-southeast-2
Block all public access
Upload decoy files:

aws-keys.txt (fake credentials)
passwords.csv
internal-financials.xlsx
README.txt (⚠️ Confidential banner)

Lock it down & allow GuardDuty access:

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AllowGuardDutyAccess",
      "Effect":"Allow",
      "Principal":{"Service":"guardduty.amazonaws.com"},
      "Action":["s3:GetObject","s3:ListBucket"],
      "Resource":[
        "arn:aws:s3:::javierlabs-sensitive-docs",
        "arn:aws:s3:::javierlabs-sensitive-docs/*"
      ],
      "Condition":{"StringEquals":{"AWS:SourceAccount":"070978211986"}}
    }
  ]
}

Step 2: Log S3 Data Events with CloudTrail → CloudWatch

Enable CloudTrail S3 data events for read/write on your bucket.
Send logs to CloudWatch Logs, using a log group like /aws/cloudtrail/honeypot-logs.

Step 3: Create a CloudWatch Metric Filter

In the /aws/cloudtrail/honeypot-logs log group:
Pattern:

{ ($.eventName = "GetObject" || $.eventName = "HeadObject")
  && $.requestParameters.key = "aws-keys.txt" }

Metric:

Namespace: HoneypotDetection
Name: AccessedAWSKeysFile
Value: 1

Step 4: Alarm & SNS Notification
From the metric (HoneypotDetection/AccessedAWSKeysFile), create an alarm:

Trigger when >= 1 in 1 datapoint.

Attach SNS action to topic honeypot-alerts.

Name: AlertOnAWSKeysAccess.

Confirm your email subscription in SNS.

Step 5: Lambda Automation to Tag VPC
TagAttackerIP Function

import json, boto3
from datetime import datetime, timedelta

LOOKBACK_MINUTES = 5
VPC_ID = "vpc-078816b7d00f13bd4"

def lambda_handler(event, context):
    print("Alarm Event:", json.dumps(event, indent=2))
    if event['detail'].get('alarmName') != 'AlertOnAWSKeysAccess':
        return {"status":"ignored"}

    region = event.get('region','ap-southeast-2')
    ct = boto3.client('cloudtrail', region_name=region)
    end = datetime.utcnow()
    start = end - timedelta(minutes=LOOKBACK_MINUTES)

    ip = None
    for action in ("GetObject","HeadObject"):
        resp = ct.lookup_events(
            LookupAttributes=[{"AttributeKey":"EventName","AttributeValue":action}],
            StartTime=start, EndTime=end, MaxResults=10
        )
        for evt in resp.get("Events",[]):
            p = json.loads(evt["CloudTrailEvent"])
            if (p.get("eventSource")=="s3.amazonaws.com"
                and p.get("requestParameters",{}).get("key")=="aws-keys.txt"):
                ip = p.get("sourceIPAddress"); break
        if ip: break

    if not ip: return {"status":"no_ip_found"}
    print("Found attacker IP:", ip)

    ec2 = boto3.client('ec2', region_name=region)
    ec2.create_tags(
        Resources=[VPC_ID],
        Tags=[{"Key":"SuspectedAttackerIP","Value":ip}]
    )
    return {"status":"success","ip":ip}

IAM Policy:

{
  "Statement":[
    {"Action":"cloudtrail:LookupEvents","Effect":"Allow","Resource":"*"},
    {"Action":"ec2:CreateTags","Effect":"Allow",
     "Resource":"arn:aws:ec2:ap-southeast-2:070978211986:vpc/vpc-078816b7d00f13bd4"}
  ]
}

Testing the Pipeline
Trigger a HEAD/GET:

curl -I <honeypot url>

CloudWatch Alarm goes ALARM, email arrives.

Lambda logs show “Found attacker IP: …”.

VPC tags now include the attacker's IP address

Next-Level Enhancements
Persist hits to DynamoDB with TTL.

Auto-block via WAF or Security Groups.

Enrich with Threat Intel feeds.

Deploy cross-region honeypots.

Use CloudFront signed URLs for advanced deception.

Conclusion

By combining AWS-native logging, monitoring, and serverless automation, you can build a robust real-time honeypot detection and response platform with minimal overhead—ideal for any cloud security engineer’s portfolio.

Happy hunting!
Feel free to leave feedback or ask questions in the comments.

Building a Secure VPC on AWS: Public & Private Subnets with Bastion Host and NAT Gateway

Javier Seng — Fri, 09 May 2025 05:20:50 +0000

Overview

This project simulates a production-ready AWS environment with strong security boundaries, using a custom Virtual Private Cloud (VPC), public/private subnet separation, a bastion host for controlled admin access, and a NAT gateway for outbound-only internet access from private instances.

In real-world infrastructure, it’s common to isolate frontend and backend components at the networking layer. Direct access to critical systems (like databases or internal APIs) is tightly restricted, and secure channels (like bastion hosts or session managers) are used for administrative access. This architecture helps organizations enforce least privilege, reduce their attack surface, and follow zero-trust design principles.

Business Value

This architecture lays the foundation for secure, enterprise-grade infrastructure in the cloud. By enforcing strict network boundaries between public and private resources, leveraging a bastion host for administrative access, and using a NAT Gateway to support outbound communication without exposing backend systems, organizations can meet both operational and compliance requirements. It minimizes exposure to the internet, isolates workloads by function, and aligns with cloud security best practices — making it suitable for any workload involving sensitive data, regulated environments, or production backend systems.

What I Built:

Creating a custom VPC (10.0.0.0/16)

Segmenting it into:

1. 2 Public Subnets (for public-facing resources like bastion hosts)
1. 2 Private Subnets (for sensitive backend servers)
Launching a bastion host in a public subnet for secure administrative SSH access
Deploying a private EC2 instance that has no direct internet exposure
Setting up a NAT Gateway so the private EC2 can still reach the internet for package updates
Configuring route tables to enforce proper traffic flow and isolation

Part 1: Creating the VPC and Subnet Architecture

To begin, I created a custom VPC called SecureVPC with a CIDR block of 10.0.0.0/16, which gives us 65,536 IP addresses — more than enough for segregated subnets across multiple availability zones.

I then divided the network into four /24 subnets (256 IPs each):

Two public subnets for internet-facing resources (e.g., the bastion host)
Two private subnets for sensitive resources (e.g., backend EC2s, databases)

Subnetting this way helps segment environments by function and prepares us for things like high availability, fault tolerance, and security zoning.

Step 2: Creating and Attaching the Internet Gateway

To allow outbound traffic from the public subnets, I created an Internet Gateway and attached it to the VPC. This is required for any resource (like a bastion host) to have direct internet access.

This gateway will only be referenced in the route table for public subnets — not private ones.

Step 3: Making Subnets Truly Public (Auto-Assign IP)
Even if a subnet routes to an Internet Gateway, instances launched inside it won’t be reachable unless they have public IP addresses. So I enabled auto-assign public IPv4 for the public subnets. This ensures EC2s launched there (e.g., bastion host) get a public IP automatically.

Step 4: Deploying a Bastion Host for Secure Admin Access
Next, I launched an EC2 instance (Amazon Linux 2023) in PublicSubnet1. This bastion host acts as a jump server, allowing me to SSH into private EC2 instances securely.

Security group settings were crucial here:

Inbound Rule: SSH (port 22) allowed only from my public IP

Outbound Rule: Open to all (default)

This setup follows the principle of least privilege and ensures that only authorized admins can reach the private backend network.

Step 5: SSH Access Test to Bastion
I tested SSH access from my terminal using the PEM key and confirmed that access was restricted correctly.

ssh -i ~/Desktop/AWS_projects/aws-webserver-key.pem ec2-user@<bastion-ip>

Step 6: Launching a Private EC2 Instance
I then launched a private EC2 instance in PrivateSubnet1. It had no public IP, which means it is not accessible from the internet under any circumstances.

Security group:

Inbound Rule: SSH (port 22) allowed only from the bastion subnet CIDR

Outbound Rule: Open (to allow NAT access)

This is a textbook example of private-by-default security, and it can be applied to database servers, internal APIs, and sensitive workloads.

Step 7: Configuring the NAT Gateway
To let the private EC2 instance reach the internet (for package updates, outbound requests), I set up a NAT Gateway in PublicSubnet1.

The NAT Gateway uses an Elastic IP and allows outbound internet traffic only — meaning private instances can access the internet, but no one from outside can initiate connections back in.

This is the key to controlled outbound access in private zones.

Step 8: Updating Private Route Table
I created a new PrivateRouteTable and associated it with PrivateSubnet1. I added the following routes:

10.0.0.0/16 → local (VPC internal communication)

0.0.0.0/0 → NAT Gateway

This ensures private instances route external requests through NAT, and internal traffic stays within the VPC.

Step 9: Final Internet Access Test
From my Mac:

SSH’d into the bastion ✅
From the bastion:

SSH’d into the private EC2 ✅
From private EC2:

Ran curl ifconfig.me and sudo yum update -y ✅

This proved that:

The EC2 in the private subnet had outbound internet
It remained unreachable from the outside world

Key Takeaways

Public subnets use an Internet Gateway; private subnets use a NAT Gateway
Bastion hosts should always restrict SSH to a trusted admin IP
Route tables are the glue that define how traffic flows

This architecture prevents direct public exposure of sensitive resources while preserving needed functionality.

Deploying a Static Website on a Custom Domain with HTTPS Using AWS

Javier Seng — Thu, 08 May 2025 07:37:17 +0000

Overview

This project builds on my previous work where I deployed a static website using Amazon S3 and CloudFront. In this phase, I extended the setup to serve the site on a custom domain (javierlab.com) with full HTTPS support, DNS configuration, and a custom 404 error page. The goal was to transform the existing setup into a polished, production-grade deployment.

Why This Project Matters (Business Value)

A custom domain with HTTPS isn't just a nice-to-have—it's a standard for any serious business or professional online presence. This project demonstrates:

Secure delivery with AWS Certificate Manager (ACM)
Professional branding with Route 53 and domain configuration
Improved UX with a custom error page
Scalability and performance using AWS's global edge network via CloudFront
Hands-on knowledge of DNS, SSL/TLS, and error routing

All these are critical for roles in cloud security, DevOps, and infrastructure automation.

What Was Already Set Up

From the previous project:

A static website was hosted in an S3 bucket: javier-static-site-2025
A CloudFront distribution was set up to serve the S3 content globally

This project extends that setup without duplicating it.

Step-by-Step Breakdown

Step 1: Purchase and Register the Domain

Domain javierlab.com was purchased via AWS Route 53

A public hosted zone was automatically created

Step 2: Request SSL Certificate in ACM

Region used: us-east-1 (N. Virginia) (required for CloudFront SSL)

Added both javierlab.com and www.javierlab.com as domain names

Selected DNS validation (recommended for automation)

Step 3: Validate Domain Ownership

Used "Create records in Route 53" to automatically add the necessary CNAME records

Waited for AWS to validate the domain (takes a few minutes)

Step 4: Upload Custom 404 Error Page

Reused the existing S3 bucket (javier-static-site-2025)

Uploaded error.html with styling and a link back to the homepage

Step 5: Configure CloudFront to Use SSL and Serve Custom Errors

Attached the validated ACM certificate to the CloudFront distribution

Added alternate domain names:

javierlab.com
www.javierlab.com

Configured a custom error response:

HTTP error code: 404
Custom error page path: /error.html
Response code: 404
TTL: 10 seconds

Step 6: Set Up Route 53 Alias Records

Created A records to route traffic to CloudFront:

javierlab.com → CloudFront
www.javierlab.com → CloudFront

Step 7: Test the Setup

Opened https://javierlab.com and confirmed successful HTTPS delivery

Tested a non-existent page (/thispagedoesnotexist) and confirmed custom 404 handling

(Optional) Step: Redirect www.javierlab.com to javierlab.com using S3

To ensure consistent traffic routing and avoid duplicate content across subdomains, I configured a redirection bucket:

Created an S3 bucket named www.javierlab.com
Enabled static website hosting, but selected “Redirect requests”
Target: javierlab.com
Protocol: https

Created an A record in Route 53 for www.javierlab.com
Type: A – IPv4 address
Alias: Yes → Targeted the S3 static website endpoint

This ensures all traffic going to www.javierlab.com is redirected cleanly to the root domain javierlab.com.

Final Thoughts

This project refined an existing S3+CloudFront deployment by layering on key production features: HTTPS, domain management, and UX-focused error handling. It’s a clear, job-ready demonstration of practical AWS architecture and hands-on cloud implementation. Perfect foundation for my next move: infrastructure-as-code with Terraform and CI/CD automation.

Stay tuned.

Deploying a Static Website with AWS S3, CloudFront, and WAF Web ACL

Javier Seng — Sat, 03 May 2025 11:16:36 +0000

In this post, I’ll walk through how I deployed a static website using Amazon S3 and distributed it globally with CloudFront. Then, I applied security hardening using AWS Web ACL to defend against common threats.

Step 1: Build the Static Site

I created a simple HTML and CSS layout:

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CloudFront Static Site</title>
    <style>
      body {
        background-color: #0e0e0e;
        color: #f4f4f4;
        font-family: sans-serif;
        display: flex;
        justify-content: center;
        align-items: center;
        height: 100vh;
        margin: 0;
      }
      .container {
        text-align: center;
      }
    </style>
  </head>
  <body>
    <div class="container">
      <h1>Hello, CloudFront!</h1>
      <p>This site is served from an S3 bucket and distributed globally with AWS CloudFront.</p>
    </div>
  </body>
</html>

style.css

body {
  background-color: #0e0e0e;
  color: #f4f4f4;
  font-family: sans-serif;
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
  margin: 0;
}

.container {
  text-align: center;
}

I then uploaded both files to a new S3 bucket named:

javier-static-site-2025

Step 2: Enable Static Website Hosting on S3
In the S3 bucket settings, I enabled static website hosting:

Selected “Host a static website”

Entered index.html as the index document

Left the error document blank

Step 3: Configure Bucket Policy for Public Read Access
To allow CloudFront (and users) to access the files, I added a bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::javier-static-site-2025/*"
    }
  ]
}

Step 4: Preview the Website on S3
After applying the policy, I accessed the site directly via the S3 static hosting endpoint:

http://javier-static-site-2025.s3-website-ap-southeast-2.amazonaws.com

The site loaded correctly, showing the custom “Hello, CloudFront!” message.

Step 5: Set Up a CloudFront Distribution
I created a CloudFront distribution to globally accelerate and cache content:

Origin Domain: S3 website endpoint (not the default bucket domain)

Origin Access: Public (since I allowed public access in the S3 bucket policy)

Viewer Protocol Policy: Redirect HTTP to HTTPS

Allowed Methods: GET, HEAD (default)

Compression: Enabled

Step 6: Link CloudFront to Web ACL (WAF)
I created a Web ACL named CloudFrontWebACL and associated it with the CloudFront distribution.

Adding AWS WAF Rules

With the Web ACL CloudFrontWebACL created and associated with my CloudFront distribution, I added several rules to strengthen the site’s security posture.

Managed Rule Sets Added

AWSManagedRulesCommonRuleSet
Covers a wide range of common threats like LFI, bad bots, size restrictions, and more.
AWSManagedRulesAmazonIpReputationList
Blocks traffic from known malicious IPs.
AWSManagedRulesSQLiRuleSet
Specifically targets SQL injection attempts.
Custom Rate Limiting Rule – LimitRequestsByIP
Blocks any IP that makes more than 10 requests in a 5-minute window.

For all managed rules, I set the action override to “Block” to ensure they actively drop malicious traffic rather than just counting matches.

Testing the Web ACL

This is the part where studying for the eJPT certification came in handy. To validate the effectiveness of each rule, I ran several tests using curl.

1. Rate Limiting

for i in {1..25}; do
  curl -s -o /dev/null "https://<CloudFront URL>" &
done
wait

Result:
Requests beyond the 10-request threshold were blocked as expected. I confirmed this via the WAF metrics panel in CloudWatch, which showed exactly 25 blocked requests.

2. SQL Injection Attempt

curl "https://<CloudFront URL>/?id=1%27%3B%20DROP%20TABLE%20users--"

Result:
The request was blocked with a 403 error, showing that the SQLiRuleSet triggered correctly.

3. SQLMap User-Agent Fingerprint

curl -A "sqlmap/1.0" https://<CloudFront URL>

Result:
Blocked with a 403 error. This confirmed that malicious User-Agent headers were being filtered properly by the common rule set.

4. Path-Based Recon

curl https://<CloudFront URL>/admin

Result:
Returned a 404 error from S3 (object not found), but was not blocked by WAF. This is expected — WAF only triggers on known threat patterns, not missing pages.

CloudWatch Logs Verification
To confirm that the WAF rules were actively blocking traffic, I reviewed the metrics and charts under the “WAF > Web ACLs > CloudFrontWebACL” section.

The rate limiting rule showed 25 blocked requests at the exact timestamp of my curl loop test.

SQLi and User-Agent tests were also reflected in blocked request counts under the relevant rules.

Final Thoughts

This project helped me understand how to:

Deploy a static site via S3 and accelerate it globally with CloudFront
Configure bucket permissions and static hosting
Set up and customize AWS WAF rules
Simulate attacks and observe real-time block metrics in CloudWatch

The final result is a minimal, fast, and well-protected static site — an ideal foundation for future personal projects.