A consultant told a client of mine last month that their server was insecure because — and I'm paraphrasing only very slightly — they used fail2ban instead of "modern access controls." The client paid for the report, looked worried, and rang me to ask whether they should rip everything out.
This is the third time this argument has come up in a year. I'd like to settle it.
What fail2ban is
fail2ban is a daemon that watches log files and bans IP addresses that misbehave. You configure jails. Each jail says "if you see this pattern N times in this window, ban the source IP for M seconds." It writes iptables (or nftables) rules. It expires them. That is the whole shape of it.
It is not access control. It is rate-limiting plus reputation, expressed in firewall rules, driven by what the log says.
What it isn't, and what people get wrong
It isn't authentication. It cannot tell a real attacker who behaves slowly from a real user who fat-fingers their password three times in a row. It will eventually ban one of them. Sometimes it will ban the wrong one.
It isn't IP-based access control. The ban list is reactive, not allow-list-shaped. If you wanted only your VPN and your office to reach :22, you would write that in iptables directly, today, before lunch. You would not lean on fail2ban to discover the attackers and ban them politely.
It isn't a moat. Modern brute-force traffic comes from botnets with tens of thousands of unique source addresses. Banning each one for ten minutes is a small inconvenience to the attacker and a useful tool against script kiddies. It is not what is keeping you alive.
What it is
It is a clean, well-understood, low-overhead first cut at the noise. Done properly, it:
- keeps the auth log readable
- drops the cost of the credential-spraying that would otherwise hit your real authentication
- documents, by its existence, that the operator has thought about brute force at all
- composes well with the things that are access control
I run it on every box I own. I run it with conservative bans, sensible whitelists for known-good infrastructure, and a jail for SSH and one for the web layer.
That is not the only thing keeping those boxes safe. SSH is key-only. PermitRootLogin is off. PasswordAuthentication is off. The administrative path is on a non-standard port behind a VPN. The web layer terminates at a reverse proxy that drops everything that doesn't look like one of three URL shapes. MFA is everywhere it can be.
fail2ban is the doorman, not the lock.
What the consultant should have said
"You're using fail2ban, which is good. Tell me about your other access controls — key-only SSH, whitelisted admin paths, MFA on the things that matter. If those are in place, fail2ban is reducing your noise. If they aren't, we need to talk about those first, because fail2ban can't save you."
Instead they wrote a paragraph that scared the client and recommended a £40,000 platform. We removed the paragraph. We did not buy the platform. The server is still running. So is fail2ban.
A short rule
When somebody tells you a single tool isn't access control, ask them what they think is. If the answer is one product, they are selling something. If the answer is six interlocking things, several of them open-source, you may be talking to a defender.
Choose your consultants accordingly.