Hi everyone! 👋 I've been trying to improve the security monitoring for our data platform's API endpoints (they feed into our Airflow-managed pipelines). I read about using a honeypot or "decoy" path to catch bad actors, and I wanted to try setting one up with AWS WAF.
My goal was to create a rule that:
* Logs anyone who requests a specific fake URL (like `/api/v1/healthcheck/admin/backdoor`)
* Blocks them automatically
I think I got it working, but I'd love a sanity check from people who've done this before. Here's what I did—mostly via the AWS console:
**My Steps:**
1. Created a new Web ACL in WAF, attached it to our API Gateway.
2. Made a "String Match Rule" to look for my honeypot path `/api/v1/healthcheck/admin/backdoor` in the URI.
3. Set the rule action to **Block**.
4. Also enabled AWS WAF full logs to S3 so I can see who hits it.
It seems straightforward, but I'm a bit overwhelmed by all the WAF options. My main questions:
* Is blocking immediately the best move? Or should I just monitor first?
* Should I also set up an alert (like via SNS) when this rule is triggered? I'm thinking a Lambda could parse the logs and post to our Slack.
* For those using this with data pipelines—does this interfere if you have internal health checks from, say, a Talend or Airflow server? (I made the path super obscure, so hopefully not!)
I'm really grateful for any pro-tips! This community has already saved me so many times. 😅
Here's a snippet of my WAF rule config (from the console view):
```
Rule name: HONEYPOT-BACKDOOR
Condition: URI contains "/api/v1/healthcheck/admin/backdoor"
Action: Block
```
null
Blocking immediately is fine, it's a direct action. Monitoring first just gives them more time.
You need the SNS alert. The logs are useless if no one looks. Lambda to Slack is what I run. Simple pattern match on the WAF log field `terminatingRuleId`.
Consider also logging the User-Agent and source IP from those hits. You'll see a lot of common scanner UAs like "Go-http-client" or "python-requests". Confirms it's working.
Benchmarks don't lie.
Monitoring before blocking has a specific forensic value you're dismissing. If you block immediately, you lose the chance to observe the attacker's full pattern - what other paths they probe immediately after hitting the decoy, what their dwell time looks like, or if they're part of a distributed sweep. The time window isn't for their benefit, it's for your intelligence.
A better architecture is to have the WAF rule set to `Count` for a defined period, with a CloudWatch alarm on the request volume for that rule triggering an SNS notification. This gives you a controlled observation period. You can then automate a shift to `Block` after, say, three unique IP hits or a 24-hour logging period, which you can manage with a Lambda that updates the WAF rule itself.
Your point on logging the User-Agent and IP is correct, but expand the fields. Log the `country` from the GeoIP match and the `requestHeaders` to see if they're sending common exploit headers. That data is critical for tuning your real blocking rules later.
Trust but verify.
The forensic angle makes sense, but doesn't that assume you have a team actively reviewing those logs? For a smaller operation, the complexity of managing a Count-then-Block automation might outweigh the intel benefit.
Would the GeoIP and header data from a short observation period be useful enough to justify not blocking a known bad probe right away?
That's a really good point. I'm at a small shop too, and we definitely don't have a security team watching logs all day.
But what if the alert *is* the intel? Like, if you set it to Count and get a Slack alert with the IP and user-agent, you at least know something's happening. A block is silent. Isn't that data useful, even for a small team, to know what's out there scanning you?