How our SSH brute-force firewall works

What this is#

Every Linux VPS on our network is protected, automatically, with nothing to install or configure, by a firewall at the network level that watches port 22 for failed password logins and temporarily blocks the IPs behind them. It's built in-house at VPSDime, not fail2ban, not an off-the-shelf appliance, but our own system, designed specifically for the way our network runs and operated by the same team that runs it. If you've ever managed a bare Linux server elsewhere and watched the auth log fill with thousands of guesses a day, this is the system that makes that noise mostly not reach you here.

(This is the "how it works" article. If you're here because your own IP got blocked, the unblock and whitelist mechanics are on the SSH firewall page, the short version is that My VPS is Down detects and whitelists your IP automatically.)

Why it beats a fail2ban on a single server#

fail2ban and its cousins are good tools, but they share one structural limit: they can only see one server's logs. An attacker sweeping a network makes three attempts against your VPS, three against your neighbor's, three against a thousand others, and stays under every individual server's threshold while making thousands of guesses in total.

Our firewall inverts that: it counts a source IP's failed attempts across many VPSes at once, so the sweep pattern that's invisible to any single machine is obvious at the network level, and the block that follows applies network-wide, one detection protects every customer simultaneously. Two practical consequences:

• A VPS with nothing installed is already defended. A fresh deploy with a password and no hardening yet benefits from every detection the whole network has ever made.
• Attackers get less out of the network than out of any single server. Miles better math, for them, in the wrong direction.

What trips it, and what makes you immune#

The counter watches failed password authentication on port 22. So:

• Correct logins never count, using your VPS normally is invisible to it.
• Key-based authentication can't trip it, there's no password to fail, which is one more reason key-only login is the recommended state: it makes you immune by construction, both to attackers and to accidentally banning yourself.
• Your own typos count like anyone's. Retrying a misremembered password, or a script (rsync, CI, anything using sshpass) looping on a stale one, is the most common way customers meet the system, the page-demo covers getting unbanned and whitelisting your IPs (up to 10, applied network-wide).

On the detection side, there are multiple mechanisms in place beyond simple counting, and we keep the specifics, thresholds, windows, escalation, deliberately undisclosed: publishing the exact rules would hand attackers the recipe for staying under them. What we'll say is that blocks are temporary, scale with behavior, and whitelisted IPs are never touched.

The three firewalls, untangled#

Your Linux VPS is behind three distinct protective layers with easily confused names:

They stack: a defense-in-depth setup uses all three.

Do you still need fail2ban?#

Not for password attacks on SSH's default port, that's covered better than a local tool could. It remains sensible for other exposed login surfaces (mail, panels, WordPress) and for SSH if you move it off port 22, since the network firewall watches 22 specifically, moving ports trades this protection for obscurity, another reason keys matter more than port games.

Scope, and the edges of it#

• It protects Linux VPS, port 22. Premium and Windows VPS aren't behind it (Windows has RDP to defend instead; on Premium, bring keys and your own tooling).
• There is no opt-out, and in practice nobody needs one: correct logins are unaffected, keys make you immune, and whitelisting covers fixed IPs and automation. The system's whole value is that it covers everyone.
• Our own infrastructure isn't relying on it either, that's protected separately, with IP restrictions and keys in multiple layers.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP and the IP you connect from,
• whether it's about a current block or how the system works.

Related questions#

• "Do I need fail2ban on my VPS?"
• "How does your SSH brute-force protection work?"
• "Why is a network-level ban better than fail2ban?"
• "Does key-based login protect me from the SSH firewall?"
• "Can I opt out of the SSH firewall?"
• "What's the difference between your firewalls?"