root

Somewhat tarpitting script kiddies

2026-04-03 · Security

I stumbled on this gem the other day:

Tweet by Marcus Gill Greenwood suggesting 302 redirects to large files for script kiddies

302 redirect scanners to a 10GB file. That's evil. I love it.

Every site gets scanned. So why not make their life a little worse?

Go ahead, try yasiraslam.dev/.git — I dare you.

What is tarpitting?

From Wikipedia:

A tarpit is a service on a computer system that purposely delays incoming connections. The technique was developed as a defense against spam and computer worms. Network abuses such as spamming or broad scanning are less effective, and therefore less attractive, if they take too long.

TLDR: We waste scanners' time and bandwidth until the target feels not worth it.

The plan (and what actually happens)

My original idea was a clean pipeline:

  1. Tarpit first — redirect known scanner paths to a 10GB file
  2. Rate limit — if they keep hammering, throttle them
  3. Block — after that, just cut them off entirely

Sounds elegant, right? Here's what I learned after actually setting it up.

Rule 0 (Scanner Tarpit)

Type: Redirect Rule Action: 302 redirect to https://ash-speed.hetzner.com/10GB.bin

(http.request.uri.path contains ".git")
or (http.request.uri.path contains ".env")
or (http.request.uri.path contains "config.yaml")
or (http.request.uri.path contains "wp-config")

These expressions are just examples. Check your own access logs for patterns — you'll be surprised how many bots probe the same predictable paths.

Scanner requests /.git/config → Cloudflare serves them a 302 to a 10GB binary. Enjoy the download.

Reality check: Most scanners don't follow 302s. Nuclei ignores redirects by default, curl needs -L and even then chokes on the binary output. The redirect still messes with script kiddies and naive tools but your WAF block rules are doing the real work. Also redirects fire in phase 1 and are terminating actions. Rate limiting fires in phase 9. The request never gets there so redirected requests don't count toward rate limit counters.

Rate Limiting

Type: Rate Limiting Rule
Action: Block for 10 seconds

(http.request.uri.path ne "/favicon.ico")
  • Rate: 50 requests per 10 seconds per IP

Still useful for catching IPs hammering >50 req/10s across any path. Just don't expect it to track the redirected ones.

Rules 1–4 — The actual heavy lifters

Type: WAF Custom Rule (Security > WAF > Custom Rules)
Action: Block

Beware: If your redirect rule and WAF rules share the same expressions, WAF never fires for those paths. Redirects are terminating actions in phase 1. The request is done before phase 8.

So keep your redirect expressions narrow (the fun stuff) and let WAF cover everything else.

Split across multiple rules because Cloudflare has expression length limits per rule:

Rule What it catches
1 Sensitive files & configs (.env, .git, docker-compose, terraform.tfstate, etc.)
2 CMS & admin panels (/wp-admin, phpmyadmin, /jenkins, /grafana, etc.)
3 Debug & infrastructure probes (/actuator, /swagger, /graphql, etc/passwd, etc.)
4 Injection attempts (path traversal, SQLi, XSS, RCE patterns in URLs)

How it actually flows

Scanner hits /.git/config
        │
        ▼
  Phase 1: Redirect Rule matches?
  ┌─ Yes → 302 to 10GB.bin
  │        (scanner follows? tarpit works)
  │        (scanner ignores? moves on)
  │        ⚠ request terminates — never reaches later phases
  └─ No  ↓
        ▼
  Phase 8: WAF Custom Rule matches?
  ┌─ Yes → Blocked (this is where most scanners actually die)
  └─ No  ↓
        ▼
  Phase 9: Rate limit exceeded?
  ┌─ Yes → Blocked for 10s
  └─ No  → Request passes through

The redirect is the fun part.

The WAF block rules are the real defense. Rate limiting is the safety net for volume abuse.

What we learned

  • The 302 redirect tarpit is fun but most scanners ignore redirects. Don't rely on it alone.
  • WAF block rules do the real work.
  • Cloudflare free tier gives you 10 redirect rules, 5 WAF custom rules, and 1 rate limiting rule. Enough for all of this.
  • Redirects terminate in phase 1. They never reach WAF (phase 8) or rate limiting (phase 9).
  • Check your access logs. Every site attracts the same predictable probes.

What's next

The 302 has a fundamental problem. You can't force a client to follow it. Most scanners just ignore it.

A Cloudflare Worker could serve a slow-drip response directly. No redirect to ignore. The scanner starts receiving bytes, 1KB per second, forever. That's a real tarpit. Need to investigate if Workers play nice with the WAF pipeline.

If you're bored and want to save meow city from evil larry, head over to yasiraslam.dev and defeat him. The city needs you.

Hetzner, please don't sue me.

← All posts