fail2ban Setup — Brute Force Protection

fail2ban setup — brute force protection

Any server with SSH exposed receives hundreds of login attempts a day — that is the background noise of the internet. The same applies to site admin panels. Fail2ban reads the logs and temporarily blocks addresses producing failed attempts.

What I configure

• SSH protection — the baseline and most important scenario;
• protection of the site admin against password guessing;
• a response to error bursts from a single address: path scanning, exploitation attempts;
• ban parameters: how many attempts, over what window, for how long;
• a whitelist — so you do not lock yourself or required services out;
• verification that the rules genuinely fire rather than merely existing in the configuration.

The most common problem

Fail2ban is installed but does nothing. The causes are predictable: the service reads the wrong log file, the entry format does not match the pattern, or the rules are created but never applied because of a conflict with another firewall. Everything looks healthy from outside, and no bans happen.

So configuration ends with a test: we deliberately make a few failed attempts and confirm the address was actually banned.

What to keep in mind

Fail2ban protects against brute force, but not against an attack from a thousand addresses at once, and not against a vulnerability in the code. It is one layer of defence, not a substitute for updates and decent passwords.