DEV Community: 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.

From Zero to Cloud Hero: My First AWS EC2 & S3 Web Project

Javier Seng — Wed, 30 Apr 2025 02:49:53 +0000

As someone pivoting into cloud security, I wanted to get hands-on with AWS. This blog documents how I built a basic web server on EC2, hosted an image on S3, and embedded that image in a live Apache-hosted web page — all secured and scalable. If you're starting your cloud journey, this is the post I wish I had.

The goal:

Launch an EC2 instance (Ubuntu)
Host a simple webpage using Apache
Embed an image stored in an S3 bucket
Apply basic security best practices
Power it all from scratch with my own hands

This post is a walkthrough — not just of what I did, but what I learned.

Spinning Up an EC2 Instance

The first step was to launch a virtual server (EC2 instance) on AWS. Here's how I did it:

1. Choose the AMI (Amazon Machine Image)
I picked the Ubuntu Server 24.04 LTS (HVM) image — a lightweight, stable OS that's commonly used in web hosting setups.

2. Select Instance Type
For this simple project, I went with a t2.micro instance — free tier eligible and perfectly sufficient for lightweight workloads.

3. Create a Key Pair
To securely SSH into the instance, I generated a key pair named aws-webserver-key and downloaded the .pem file.

Make sure to store the .pem file securely and restrict permissions with:

chmod 400 aws-webserver-key.pem

4. Configure Network Settings
I created a new security group with the following inbound rules:

SSH access from my IP only

HTTP access from anywhere (to serve the webpage)

With the instance up and running, I connected via SSH:

ssh -i aws-webserver-key.pem ubuntu@<EC2-PUBLIC-IP>

Installing Apache and Hosting the Webpage

Once connected to the EC2 instance via SSH, I set up a simple web server using Apache.

1. Update the System
After logging in, I made sure the system packages were up to date:

sudo apt update

2. Install Apache
Next, I installed the Apache2 package:

sudo apt install apache2 -y

3. Enable the Apache Firewall Rule

Although not strictly necessary for this setup, I ran the following to allow Apache through the firewall:

sudo ufw allow 'Apache'
sudo ufw reload

Then I checked the service status to confirm that Apache was running:

sudo systemctl status apache2

4. Test the Web Server
Opening the EC2 instance’s public IP address in a browser confirmed Apache was serving the default web page.

5. Customize the Web Page
I replaced the default /var/www/html/index.html with a simple HTML file using nano:

cd /var/www/html
sudo rm index.html
sudo nano index.html

I inserted a basic HTML page:

<!DOCTYPE html>
<html>
  <head>
    <title>Hello Cloud Security</title>
  </head>
  <body>
    <h1>Hello, Cloud Security!</h1>
    <p>Powered by AWS EC2 and Apache</p>
  </body>
</html>

This immediately reflected in the browser when visiting the instance’s IP:

Hosting an Image in S3 and Embedding It in the Web Page

To take the project a step further, I created an Amazon S3 bucket to host a public image and then embedded that image into my EC2-hosted web page.

1. Create the S3 Bucket
In the S3 dashboard, I created a new bucket with a globally unique name.

I kept the default settings, including blocking public access, which is AWS’s secure-by-default posture.

2. Adjust Bucket Permissions
To allow public read access to the image, I edited the bucket's permissions and added a Bucket Policy manually.

Here's the policy I applied:

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

This allows only read access to objects inside the bucket — not the bucket itself, and not any write access.

3. Upload the Image
I uploaded a simple image file named green_apples.jpg to the bucket.

4. Confirm Public Access
After uploading, I verified the public URL for the image:

https://javier-cloud-project-2025.s3.amazonaws.com/green_apples.jpg

5. Embed Image in the Web Page
To finish the integration, I edited index.html on the EC2 server and added an img tag to load the image from S3.

<img src="https://javier-cloud-project-2025.s3.amazonaws.com/green_apples.jpg" alt="S3 Image" width="400">

After refreshing the page in the browser, the image appeared successfully, loaded directly from the S3 bucket.

Reflections and Takeaways

This was my first real AWS project. It may look simple, but it taught me a lot:

How to launch and configure EC2 instances from scratch
SSH access, key pair security, and managing Linux servers
Installing and configuring Apache to host a live web page
The principles of least privilege and public access control with S3
Writing and applying secure S3 bucket policies manually
Connecting cloud services (EC2 and S3) in a practical way

One of the most valuable takeaways was understanding AWS’s security-first design. From blocked public access by default, to strict key permissions, to required manual policy writing — this project forced me to think about security as part of every step.

It also reminded me that doing is better than reading. A basic EC2 + S3 integration might seem trivial on paper, but doing it from scratch — and hitting permission issues along the way — made the knowledge stick.

What’s Next?
Now that I’ve completed this foundational project, I plan to:

Set up HTTPS using Let’s Encrypt and custom domains
Explore infrastructure-as-code using Terraform or CloudFormation
Dive deeper into IAM roles and access control models
Build more offensive-security inspired labs on AWS as part of my cloud security journey

Thanks for reading. If you're also learning AWS, feel free to connect with me — happy to share resources or ideas.