Forem: Ben Subendran

How I Autoban Hackers Who Touch My Secret URLs

Ben Subendran — Wed, 24 Dec 2025 07:17:55 +0000

If you look at your server logs right now, I guarantee you’ll see them.

The bots. The script kiddies. The scanners. They are relentlessly hitting paths that don’t exist: /wp-admin, .env, /backup.zip, /admin-login. They are looking for a weakness, jiggling the handle of every door in your application.

Usually, the advice is defensive: "Rate limit them." "Ignore them." "Set up a static WAF rule."

I got bored of playing defense. So I built a trap.

In this tutorial, I’m going to show you how to implement Active Defense on AWS. We aren't just going to block known attacks; we are going to create a "Honeypot" URL. It’s a fake login page that no legitimate user will ever see. But if a bot touches it?

Their IP address is instantly identified, logged, and added to a hardware-level Blocklist (WAF) that bans them from my entire infrastructure.

The Architecture: Anatomy of a Trap

To make this work, we need three components: The Bait, The Enforcer, and The Jail.

The Bait (API Gateway)

We need a URL that looks tasty to a bot but is invisible to a human. Something like /admin-backup or /v1/secret. We set up an API Gateway (REST) to listen on this specific path. If a normal user visits your homepage, they are fine. If a bot scans your site and hits this path, they trigger the trap.

The Enforcer (Lambda)

When the trap is triggered, it fires a Python Lambda function. This function doesn't return a webpage. Instead, it performs a "arrest":

It extracts the Source IP of the request.
It calls the AWS WAFv2 API.
It adds that IP address to a specific IP Set (our "Jail").

The Jail (AWS WAF)

This is the heavy lifter. We have an AWS WAF Web ACL sitting in front of our API. It has a high-priority rule: Block ANY request coming from an IP inside the 'Honeypot' IP Set.

The second the Lambda updates that list, the door slams shut. The bot can't access the fake page, the real page, or anything else. They are gone.

Why "Active Defense"?
You might ask, "Bro, isn't this overkill?"

Not really. Traditional WAF rules look for patterns (like SQL Injection strings). They are reactive. This approach is proactive. By identifying an actor who is clearly malicious (probing for hidden files), we can block them before they even launch their real attack.

Plus, it’s extremely satisfying to watch the "Banned IPs" list grow automatically while you sleep.

The Code Breakdown

I built this entire stack using Terraform so it can be deployed (and destroyed) in minutes.

Note: During the build, I discovered a quirk. AWS WAF does not fully support the newer "HTTP APIs" (v2) for this specific type of blocking logic easily, so we are using the battle-tested "REST API" (v1) standard.

The Jail: aws_wafv2_ip_set

First, we need a mutable list. In Terraform, we define an empty IP Set.

resource "aws_wafv2_ip_set" "honeypot_set" {
  name               = "honeypot-blocked-ips"
  scope              = "REGIONAL"
  ip_address_version = "IPV4"
  addresses          = [] 

  lifecycle {
    ignore_changes = [addresses]
  }
}

Critical Dev Tip: Notice the lifecycle { ignore_changes = [addresses] } block? This is mandatory. Without it, every time you run terraform apply, Terraform will see the list has changed (because the Lambda added bad IPs) and will try to wipe it clean. This block tells Terraform: "I created the jail, but I don't control who is inside it."

The Permissions

The Lambda function isn't just running code; it needs permission to modify your firewall. This is where most people get stuck.

We grant the Lambda two specific permissions:

wafv2:GetIPSet: To read the current list (we need the LockToken for concurrency control).
wafv2:UpdateIPSet: To actually write the new IP to the list

{
  Action = ["wafv2:GetIPSet", "wafv2:UpdateIPSet"],
  Effect   = "Allow",
  Resource = aws_wafv2_ip_set.honeypot_set.arn
}

Security Note: We scope the Resource specifically to the honeypot_set.arn. Even if this Lambda gets compromised, it can only ban people—it can’t delete your other WAF rules.

The Logic: Python Boto3

Inside the Python script, the logic is simple but ruthless. We are using the boto3 library to interact with the AWS API.

The most important part is handling the LockToken. AWS WAF uses optimistic locking. To update the list, you must first read the list to get the current "version" (token). If you try to update without it, AWS rejects the request to prevent race conditions.

# 1. Read the list (Get Token)
response = waf.get_ip_set(...)
lock_token = response['LockToken']

# 2. Add the IP
current_ips.append(ip_cidr)

# 3. Push the update (With Token)
waf.update_ip_set(..., LockToken=lock_token)

The Wall: aws_wafv2_web_acl

Finally, we set the rules of engagement.

We create a Rule with Priority 1. In WAF, lower numbers run first. This ensures that before the request is checked for SQL injection or Rate Limits, we check the Ban List. If they are in the jail, we drop the connection immediately.

rule {
  name     = "BlockBannedIPs"
  priority = 1
  action {
    block {} # <--- The Hammer
  }
  statement {
    ip_set_reference_statement {
      arn = aws_wafv2_ip_set.honeypot_set.arn
    }
  }
}

🚀 Deployment

Want to try this yourself? Here is the full code.

Prerequisites

Terraform installed
AWS CLI configured (aws configure) with Admin permissions

Step 1: Create the Python Logic (honeypot.py)
Save this file in a folder. This is the logic that detects the intruder and updates the firewall.

Step 2: The Infrastructure (main.tf)
Save this in the same folder. This builds the WAF, API Gateway, and Lambda.

Step 3: Deployment
Open your terminal in the folder.

Run terraform init.
Run terraform apply -auto-approve.

Step 4: How to Test (Be Careful!)
After Terraform finishes, it will output a TRAP_URL (ending in /admin-backup).

Check your status: Open the SAFE_URL (just the domain). You should see a "Not Found" (which is fine, we didn't make a root page), but it loads.

Trigger the Trap:
Open the TRAP_URL in your browser OR use curl [TRAP_URL].
You will see: Restricted Access. Your IP x.x.x.x has been flagged.

Verify the Ban:
Try to refresh the page.
You should eventually see 403 Forbidden coming from AWS WAF (not the Lambda).

Note: It might take 10-30 seconds for WAF to propagate the update.

How Not to Break Production

Before you deploy this to your company's main website, you need to handle a few edge cases. Active Defense is powerful, but it has no sense of humor.

The "Google Problem" (robots.txt)
You do not want to ban the Google Crawler just because it found your trap URL.

The Fix: Add a robots.txt file to your site root.

User-agent: *
Disallow: /admin-backup

Legitimate crawlers (Google, Bing) respect this and won't touch the link. Malicious scanners usually ignore robots.txt and scan anyway. That’s how you filter the good bots from the bad ones.

Whitelisting
In a production environment, you should add a "Safe List" rule to your WAF with a higher priority (Priority 0) than your Block rule. Add your office VPN and CI/CD server IPs there. This ensures that no matter what crazy testing you do, your internal team never gets locked out.

References:

Honeypots & Active Defense
CSRC.NIST.gov - Honeypot Glossary
CrowdStrike - What is a Honeypot?

AWS WAF & Automation Specs
AWS Docs - UpdateIPSet
AWS Solutions - Security Automations

Infrastructure as Code (Terraform)
Terraform Registry - aws_wafv2_ip_set

Bot Management Standards
Google Developers - Robots.txt Spec

Understanding CORS and Web Origins

Ben Subendran — Sun, 03 Sep 2023 09:16:57 +0000

In the realm of web development, the terms "origin" and "CORS" frequently come into play, especially when dealing with modern web applications that make use of APIs. This short article aims to demystify these concepts for both seasoned developers and newcomers.

What is an Origin?
In the context of web security, the origin is a combination of three components: the scheme (protocol), the hostname, and the port. For two resources to share the same origin, all three of these components must match.

For instance, consider the two URLs:

http://localhost:3000
http://localhost:8000

While both have the same scheme (http) and hostname (localhost), their port numbers differ (3000 vs. 8000). Thus, they are treated as different origins by web browsers.

Why does Origin Matter?
The distinction of origin is crucial because of the Same-Origin Policy (SOP). This web security policy ensures that web pages from one origin cannot access data in another origin without explicit permission. The SOP acts as a protective barrier, preventing malicious sites from reading sensitive data from another site.

However, modern web applications often require the ability to communicate across origins, especially with the rise of microservices and third-party APIs. This is where CORS (Cross-Origin Resource Sharing) comes into play.

Understanding CORS
CORS is a security feature implemented by web browsers that controls how web pages in one origin can request resources from another origin. It's the mechanism that allows or denies web pages to make requests to a different domain than the one that served the web page.

By default, web pages cannot make cross-origin requests. But servers can specify who can access their resources by setting specific HTTP headers.

For example, if a server wants to allow its resources to be accessed by a web page served from http://localhost:3000, it can include the following header in its responses:

Access-Control-Allow-Origin: http://localhost:3000
If a web page from any other origin tries to access the resource, the browser will block the request, thus maintaining security.

The image below displays the error encountered when a client request is blocked due to the browser's CORS policy.

A pivotal part of CORS is the "preflight request." Before dispatching certain types of requests (e.g., a POST request with specific headers), browsers initiate a preliminary "preflight" request using the OPTIONS HTTP method. This request essentially seeks permission for the subsequent main request, verifying whether it's allowed.

If the server doesn't respond affirmatively to the preflight, indicating that the actual request is permissible, browsers will block the main request. The error "preflight request doesn't pass access control check" is symptomatic of such a situation.

Install Bun on WSL

Ben Subendran — Sun, 10 Jul 2022 18:54:18 +0000

Bun(https://bun.sh) is a new JavaScript runtime with a native bundler, transpiler, task runner and NPM client built-in. Bun is superfast compared to NodeJS.

Enable WSL from Windows Features

To turn on the Windows Subsystem for Linux feature, click the checkbox like this:

Install Linux Distro

To work with WSL, you should have installed at least one distro on your computer.

To install Ubuntu, Run this:

winget install -e --id Canonical.Ubuntu

If you want to install any other distro, you can get it here by searching; https://winget.run/

After installed, To check all the available distros, run this:

wsl --list

If you get any error, just update the wsl by running wsl --update. And install the distro again.

Install Bun

After setting up the Unix admin for the respective distro, run this(in your WSL terminal, not in CMD):

curl https://bun.sh/install | bash

If there's any error occurs while unzipping, install the unzip package like this:

sudo apt install unzip

Now you can unzip it, and the installation will be done in seconds.

To check the installed Bun version, run this:

bun -version

Try React on Bun

To scrutinize the specialty of Bun, we'll try installing React via Bun.

The following command will create a React project inside the myapp folder.

bun create react ./myapp

Installed path will be like this: wsl.localhost\Ubuntu\home\USER\myapp

To start the React app, run these commands:

cd myapp
bun dev

Now you can see your React app by navigating to http://localhost:3000.

All this can take significantly less time than NodeJS. That's the magic what Bun can do.

How to add a theme to a Hugo site

Ben Subendran — Thu, 07 Jul 2022 06:53:53 +0000

Hugo is one of the most popular open-source static site generators. The developers craft many themes (https://themes.gohugo.io/) for the Hugo community to use. Here's a quick guide on adding those themes to our Hugo sites.

Install Hugo

You can install Hugo on macOS, Windows, Linux, OpenBSD, FreeBSD, and on any machine where the GO(AKA Golang) compiler tool chain can run.

Here's the official installation guide: https://gohugo.io/getting-started/installing/

Install Extended Hugo on Windows via Chocolatey:

choco install hugo-extended -confirm

The extended version is nothing but has Sass/SCSS functionality.

After installing it, check your Hugo version to ensure you have a suitable version for a particular theme. In some cases, you may need to have installed the extended versions for some themes to be worked perfectly. So keep an eye on this thing as well.

To check your version of Hugo, run:

hugo version

Create a new Hugo site

hugo new site newhugo

The above command will create a new Hugo project in the newhugo folder.

To go inside the root of the directory, run:

cd newhugo

Fork a Hugo theme

I'm using this theme for this tutorial. Anyway, you can find thousands of themes off of this page.

It's always better to fork the particular theme before adding it to our sites. Your forked theme will not be deleted even if the upstream repo is deleted. So the theme will be persisted.

Add the forked theme to our newhugo site

Before adding a git submodule, we have to initialize the git repository. So run this:

git init

Now we can add that theme as a git submodule.

git submodule add https://github.com/apvarun/blist-hugo-theme.git themes/mytheme

Now our theme will be added to the folder themes/mytheme.

Copy the content from theme.

To copy all the content from the theme's exampleSite to our site, run this:

cp -a themes/mytheme/exampleSite/. .

Configure config.toml file

Set the theme name like this:

theme = "mytheme"

Install Node Modules[if required]

Commonly Hugo theme doesn't require node modules unless it uses a tool like PostCSS.

Copy the package.json from the themes/mytheme, and paste it to our newhugo root folder. and run this:

npm install

Run Hugo site

To generate the build, run this(From the root folder):

hugo

To serve the website, run this:

hugo serve

This will render your page in localhost:1313

Let's beautify the Windows Terminal

Ben Subendran — Mon, 04 Jul 2022 23:09:39 +0000

This is a straightforward & clear-cut guide based on Scott Hanselman's YouTube tutorial.

Let's get you set up!

Install Powershell(.NET Core-powered cross-platform Powershell)

winget install Microsoft.PowerShell

Install Windows Terminal

winget install Microsoft.WindowsTerminal

Make PowerShell as your default terminal on Windows Terminal

Go to Settings

Click on Default profile and select PowerShell and save the changes.

Then go to Profiles > PowerShell > Additional Settings > Appearance.

Here you can customize your fonts by choosing a suitable font with lots of Glyphs.

Navigate to the following link to explore & download all the trendiest developer nerd fonts: https://www.nerdfonts.com/font-downloads

So, we will go with this, https://github.com/ryanoasis/nerd-fonts/releases/download/v2.1.0/FiraCode.zip

Choose FiraCode NF as Terminal Font.

Install Oh My Posh

winget install JanDeDobbeleer.OhMyPosh -s winget

For the PATH to be reloaded, a restart of your terminal is advised

Enter the following code in Terminal to get the exact location of the PowerShell profile.

 echo $profile

If you don't see any folder titled PowerShell in Documents, Make new folder in that name anyway.

Inside that folder, create a file Microsoft.PowerShell_profile.ps1 where we're gonna add our functionalities.

Following json is being used as theme property to modify Oh My Posh options.

theme.json:

Download theme.json and locate it wherever you want, I'm letting it beside the Microsoft.PowerShell_profile.ps1 file.

Open Microsoft.PowerShell_profile.ps1 and add the following code and save it.

oh-my-posh --init --shell pwsh --config C:\Users\{YOUR PC USER NAME}\Documents\PowerShell\theme.json | Invoke-Expression

Restart your terminal. You will see the difference.

Install Terminal-Icons

Run the following code in the terminal

Install-Module -Name Terminal-Icons -Repository PSGallery

And then add this line to Microsoft.PowerShell_profile.ps1 file

Import-Module -Name Terminal-Icons

After your installation; if you run ls, you will notice that all the listed files, got colored with beautiful icons like this:

Install PSReadLine

PSReadLine will give you the guessings from the previous command history.

Run the following code in the terminal.

Install-Module PSReadLine -AllowPrerelease -Force

And then add these lines to Microsoft.PowerShell_profile.ps1 file

Import-Module PSReadLine
Set-PSReadLineOption -PredictionSource History

PSReadLine will help you this way:

Enable Predictive Intellisense

Predictive intellisense will gather guesses as much as possible.

Add these lines to Microsoft.PowerShell_profile.ps1 file.

Set-PSReadLineOption -PredictionViewStyle ListView
Set-PSReadLineOption -EditMode Windows

This is the way Predictive Intellisense works:

Make sure your Microsoft.PowerShell_profile.ps1 file contains code like this:

Enable the Glassmorphism effect

Go to Windows Terminal > Settings > Open JSON file, then add these fields to defaults. Then save the settings.json file and restart the terminal. You will see wonders.

"defaults": {
   "useAcrylic": true,
   "acrylicOpacity": 0.5
},

Finally!!! you terminal will look like this(if you follow everything precisely):

CommonJS vs ES Modules

Ben Subendran — Mon, 04 Jul 2022 15:51:54 +0000

cross-posted on https://blog.keture.com/blog/cjsvsesm

If you're already familiar with the JavaScript universe, you unquestionably come to believe that ecosystem of JS is more massive than any other language ever had. When it comes to Modular Programming, CJS, AMD, UMD, and ESM will be the commonly used approaches, and the list goes on. In this article, we will look deeper into CJS and ESM only as it's widely used.
Modular Programming is nothing but a mechanism that allows you to break up your code into separate files; this makes it easier not only to maintain the code-base, but there are some other valuable benefits behind this approach. Let's see what those are.

Before the concept of modular programming appeared in JavaScript, Developers would create multiple files and link to them as separate scripts if they wanted to segregate their code. Here is what it looks like:

the above approach will make two major issues:

Polluting the global namespace
Dependency management

Polluting the global namespace: All the variables you created in your scripts, exist on the window object. If you attempted to use another variable with same name in another file, it would become difficult to know which value would be used at any point in the scripts, since they would all be using the same window. The only way a variable could be private was by putting it within a function scope.

Dependency management: Scripts would have to be loaded in order from top to bottom to ensure the correct variables were available.

IIFE(Immediately Invoked Function Expression); a JavaScript function that runs as soon as it is defined. Writing all code in IFFE and placed them on a single object was the immediate solution provided by the community earlier. Here is what it looks like:

After that, a few module solutions emerged:

CJS (CommonJS) is a synchronous approach implemented in Node.js as default.
Asynchronous Module Definition (AMD), which was an asynchronous approach.
Universal Module Definition (UMD) was intended to be a universal approach supporting both previous styles.

However, these approaches didn't seem completely useful for the client-side(JavaScript). ECMAScript finally came up with the solution ES Modules which are now available natively in JavaScript.

ES Modules

ES Modules in JavaScript use the import and export keywords:

import: Used to read code exported from another module
export: Used to provide code to other modules.

ES Modules are what you see in React, Angular, or any other Front-End JavaScript Libraries/Frameworks. It will work asynchronously. It is compatible with browsers and has HTML support. It can be accessible via CDN/URL.

When it comes to Back-End, NodeJS uses CJS as its default way to import/export packages between files; meanwhile, Deno, the hot new alternative to Node, makes ESM the default.

To achieve the same functionality in vanilla JavaScript, you have to set the type value to the module like this:

If you want to enable ES Modules on NodeJS, you have to do something like this:

By adding "type": "module" to package.json, now every files will be treated as mjs(EcmaScript modules) file. Otherwise, you must create files in mjs extension to achieve the same goal.

package.json

Named Exports

index.js

Then you can import all the exported modules from index.js to your respective file like this:

It is also possible to use an as(alias) to rename the function like this:

Import all modules from particular script

Default Imports

A file can have only one default export, but it can have multiple named exports.

A default export will not be imported with curly brackets, but will be directly imported into a named identifier.

CommonJS

CJS imports modules synchronously. It doesn't support either HTML or CDN/URL imports. It's not browser compatible. It will have to be transpiled and bundled. But it's suitable for the Back-End because NodeJS has CJS as its default modular.

Default Exports

when you import modules via CJS; you can specify either its Module ID or path of the module inside the require method like this:

Named Exports

index.cjs

Note here file extension is cjs but now js also can be supported.

Resources:

https://www.digitalocean.com/community/tutorials/understanding-modules-and-import-and-export-statements-in-javascript
https://developer.mozilla.org/en-US/docs/Glossary/IIFE
https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1
https://nodejs.org/api/modules.html