How a Three-Line Script Kept the Bad Guys Out for 15 Years

Every server with a public IP address lives under a constant, low drone of attack. Most of it isn't targeted — it's just the internet's background radiation: bots rattling SSH ports across the whole planet, scanners walking common web paths, credential-stuffing scripts trying admin / admin a few thousand times a day. It never stops, and it never really has.

The usual answer is to buy a box — a next-gen firewall, an intrusion-prevention appliance, a subscription that promises to worry about this so you don't have to. Fifteen years ago, on a network we still help run today, we did something cheaper and dumber. It's still running. It still works. And the story of the day it caught the wrong person is the best evidence we have that it works at all.

The problem, and a router that couldn't help

Two facts set it up. The web and SSH servers were getting hammered — ordinary brute-force noise, but loud enough to matter. And the edge was a plain router: capable, cheap, beloved by people who like to tinker, and at the time without any built-in "watch the logs and ban the offenders" feature.

That left the intelligence and the muscle in two different places. Which addresses were misbehaving? The servers knew — it was right there in the logs. Who had the power to block them at the door? The router did. The two had no way to talk to each other.

So we made them talk.

The whole thing is about three lines

On the servers we ran fail2ban, the venerable open-source tool that tails your logs and counts failures. Too many failed SSH logins, too many ugly requests to the web server, and it decides an address has earned a ban. Standard so far. The trick was what happened on a ban.

fail2ban lets you define your own ban action. Ours was a two-line shell script that did exactly one thing — SSH into the router and run whatever command it was handed:

#!/bin/bash
# /usr/bin/mikrotik — the entire "integration," such as it is
ssh -i /root/.ssh/id_ed25519 -l fail2ban <router-ip> "$1"

And the fail2ban action that called it was a single line, telling the router to drop the offender's address into a blocklist:

actionban = mikrotik ":ip firewall address-list add address=<ip> list=blocked comment=\"fail2ban ban\""

That's the integration, in full. A server notices an attacker, reaches into the router, and adds them to a list. The router already had one standing rule: drop anything on the blocked list. From that instant the attacker is gone — not from one server, but from the entire network behind the router. And because each entry expires on its own after a day, the list stays current without anyone ever tending it.

No appliance. No license. No agent. A tool that was already free, a router that was already there, and about three lines of glue to introduce them to each other.

Why it survived fifteen years

Complicated things rot. They need updates and renewals, a vendor that stays in business, an engineer who still remembers how they were set up. This had almost none of those failure modes, because there was almost nothing to fail. fail2ban is still maintained and still boring. The router rule is one line. The script is three. Nobody had to log in and "administer" it — the blocklist filled and drained by itself, quietly eating the internet's worst as it showed up.

For fifteen years it sat there and did its job with no dashboard, no alerts, and no drama. Which is exactly what makes a block like this hard to prove. It's invisible by design: the attacker simply stops getting answers. There's no satisfying "THREAT BLOCKED" banner. There's just silence.

The proof, when it finally showed up

We got our proof the way you'd least want it. It caught us.

Years in, we aimed our own authorized security scanner at that network as part of a full assessment. The scan came back empty — every host dark, not a single open port anywhere. We spent hours suspecting our own tooling, because "nothing at all responds across an entire network" reads like a broken scanner long before it reads like a wall.

It was the wall. The scanner had pounded the edge exactly the way an attacker would, put itself on the very same blocked list that had been swallowing real attackers for over a decade, and gotten blackholed — silently, completely, with no error to point at. The repair was one line: add the scanner to an allow-list so the rule would leave it alone. The appreciation took a little longer. The simplest control on the network had quietly beaten the expensive, purpose-built tool we'd brought in to test it — and it hadn't made a sound doing it.

How we help

We keep telling this story because it runs against the grain of how security usually gets sold. Nobody needed a bigger box. Someone needed to connect two things that were already there — cleverly, cheaply — and then trust it enough to walk away for fifteen years. That instinct, solving the real problem with the fewest moving parts and building it to outlast the person who built it, is most of what good IT actually is.

We still run networks on that philosophy, with modern tools carrying the load now: managed firewalls, log-driven blocking, and our own Pseudopod platform watching Linux fleets around the clock. If your security has turned into a stack of subscriptions you're afraid to switch off, we'd rather show you the boring, durable version. Ask us what that would look like for your systems.