Defensive Tarpits:Trap Brute-Force Bots, Legally

A bot is spraying your login page with stolen username-password pairs. The tempting answer — the one that does the rounds on security forums — is to fire back a "tab bomb": a page that loops window.open() until the attacker's browser or machine falls over. Don't. It is illegal even when aimed at an attacker, it can freeze a real customer who merely fat-fingered their password, and a popup blocker defeats it in milliseconds. The move that actually drains an attacker is quieter and entirely legal: spot the abuse, divert it into a honeypot, and tarpit the connection so every request hangs for an eternity while you log the lot. That is a defensive tarpit.

DefinitionWhat a defensive tarpit actually is

A tarpit answers abusive clients as slowly as it possibly can, holding their connection open and useless instead of closing it. A firewall says "no" in a millisecond and frees the attacker to try the next target; a tarpit says "almost…" indefinitely, pinning the bot's sockets, threads and patience on you. "Authentication-failure diversion" is just a tarpit bolted onto your login flow: the moment an IP trips a threshold, its requests are quietly rerouted from the real endpoint to the trap, and it never gets a clean answer again.

The mythWhy "crash the attacker" backfires

Shipping a payload meant to crash the client is "hacking back," and it fails on three fronts at once:

• It is a crime. Impairing someone else's computer — yes, even an attacker's — is unauthorised access under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and their equivalents worldwide. You hand the other side a victim: you.
• You are aiming blind. The source IP is usually a botnet node, a shared proxy, a VPN exit or a compromised device owned by someone entirely innocent. A destructive payload lands on whoever happens to be behind it.
• It simply doesn't land. Browsers throttle and block runaway window.open(), and any competent attacker drives a headless client from a disposable container that no tab bomb can reach.

MechanismHow authentication-failure diversion works

Underneath, it is one detection rule feeding one routing rule. When an IP crosses a behavioural threshold, your reverse proxy stops forwarding it to the real backend and starts forwarding it to a trap whose entire job is to look authentic while being slow and heavily instrumented. The strategy you pick for the trap decides how much it costs the attacker:

The connection tarpit is the safe, battle-tested choice: accept the request, then trickle the response out a byte at a time, keeping the socket open for as long as the client is willing to wait. Purpose-built tools have done exactly this for years — endlessh for SSH, classic SMTP tarpits for spam. The same idea fits in a few lines as a honeypot route, and note that every ounce of the latency is spent holding your own response open:

// Express honeypot: divert flagged IPs here, then trickle a response
// out slowly. All latency is on OUR server — nothing touches the client
// machine. Pair with a hard cap on concurrent tarpit sockets.
const tarpit = new Set();

app.use((req, res, next) => {
  if (flaggedIps.has(req.ip)) return res.redirect(307, "/trap");
  next();
});

app.all("/trap", (req, res) => {
  // Log the full attack signature for blacklisting + threat intel.
  logger.warn("tarpit", { ip: req.ip, ua: req.get("user-agent"), body: req.body });
  res.setHeader("Content-Type", "text/html");
  tarpit.add(res);
  // Drip one harmless byte every 10s; the bot's socket stays stuck on us.
  const drip = setInterval(() => res.write(" "), 10_000);
  req.on("close", () => { clearInterval(drip); tarpit.delete(res); });
});

ArchitectureThe blue-team stack around the trap

The tarpit is only the payload; the detection and isolation wrapped around it are what make it both safe and useful. A complete deployment has four layers:

1. Detection — a WAF or IDS watching the paths that matter (/admin, /login) with a strict threshold, say 5 failed logins in 10 seconds, triggered only after rate-limiting and CAPTCHA have already stripped out the ordinary noise.
2. Diversion — a reverse-proxy rule that, once an IP is flagged, sends all of its future traffic to the trap host instead of the real backend.
3. The trap — an isolated honeypot (never your production box) running the connection tarpit, a fake login that records every credential tried, or both.
4. Logging & response — persist the IP, User-Agent and attack signature, feed them to something like fail2ban to widen and lengthen bans, and push confirmed indicators out to your blocklists.

GuardrailsDeploying it without hurting real users

• Isolation is non-negotiable. Run the trap on a static, isolated server. Active-defense logic never belongs on your main production application.
• Rate-limit and CAPTCHA first. Filter out ordinary spam and honest mistakes before anything is ever flagged, so the trap only meets confirmed automation.
• Favour precision over recall. A false positive freezes a real customer who just forgot their password — bias thresholds toward certainty and give legitimate users an obvious, fast recovery path.
• Keep every effect on your side of the wire. Slow responses, fake pages and logging are defensible; anything built to run on or damage the client's machine is not. Don't ship it.