# How our SSH brute-force firewall works
Source: https://vpsdime.com/knowledgebase/technical-questions/ssh-bruteforce-firewall
Last reviewed: 2026-07-02
Summary: Every Linux VPS sits behind a network-level firewall, built in-house at VPSDime, that watches port 22 for failed password logins and blocks offending IPs network-wide, and because it counts an attacker's failures across many VPSes rather than one, it catches sweeps that a single-server fail2ban never could. What trips it, what makes you immune, how it relates to the other two firewalls, and why the detection specifics stay undisclosed.

## 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](https://vpsdime.com/knowledgebase/client-area/support/ssh-firewall), the short version is that [My VPS is Down](https://vpsdime.com/knowledgebase/client-area/support/vps-troubleshooter) 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](https://vpsdime.com/knowledgebase/getting-started/setting-up-ssh-keys) 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](https://vpsdime.com/knowledgebase/client-area/support/ssh-firewall) (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:

| Layer | Watches | Configured by | Where |
|---|---|---|---|
| **SSH brute-force firewall** (this article) | Failed password logins on port 22 | Nobody, it's automatic (whitelist via [My VPS is Down](https://vpsdime.com/knowledgebase/client-area/support/ssh-firewall)) | Network level |
| **[Managed network firewall](https://vpsdime.com/knowledgebase/client-area/services/firewall)** | High-risk app ports (databases, caches, Docker API) | You, per-app whitelists on the Firewall tab | Network edge |
| **Your own OS firewall** (ufw etc.) | Whatever you configure | You, [inside the VPS](https://vpsdime.com/knowledgebase/getting-started/first-30-minutes) | The VPS itself |

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](https://vpsdime.com/knowledgebase/technical-questions/change-ssh-port)**, 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](https://vpsdime.com/knowledgebase/windows-vps/protecting-rdp); 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](https://vpsdime.com/open-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?"