If you run a Linux server exposed to the internet, something is already trying to brute force your SSH port. The two most common defences are fail2ban and CrowdSec. They look similar from a distance and work quite differently up close.
Key Takeaways
- Both read logs and ban IPs. The difference is whether your server learns alone or from a shared pool of observations.
- fail2ban is simpler, has no external dependency, and is usually sufficient for a single server with a few exposed services.
- CrowdSec adds shared reputation, which closes the gap on distributed attacks that hit each server only once.
- Running both is common and works, though it inflates your rule count over time and is worth watching.
- Neither tool answers whether anything actually got in. That is a different layer entirely.
Table of Contents
- How fail2ban works
- How CrowdSec works
- Which to choose
- Getting the configuration right
- The part neither solves
How fail2ban works
fail2ban watches log files. You define a filter (a regex that matches a failed login), a jail (which log, how many attempts, over what window), and an action (usually an iptables rule). Five failed SSH logins in ten minutes, ban the IP for an hour.
Its strengths are that it is simple, it has no external dependency, and it works entirely on data you already have. Its weakness is that every server learns alone. If an attacker hits a thousand servers once each, fail2ban catches nothing anywhere.
What that looks like in practice
sudo fail2ban-client status
sudo fail2ban-client status sshd
That second command shows currently banned addresses and total counts for the jail, which is the fastest way to confirm it is doing anything at all. A jail that has been enabled for a week on a public server with zero bans usually means the filter is not matching your log format rather than that nobody is trying.
Verify a filter against your real log before trusting it:
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
This is worth doing after any distribution upgrade. Log formats shift, and a silently non-matching filter is the most common way fail2ban stops working without anyone noticing.
Where the log-parsing model runs out
fail2ban only knows what is written down. An attack that does not produce a distinctive log line does not exist as far as it is concerned. It also acts strictly after the threshold is met, so the first few attempts always land, which is fine for brute force and less fine for something that only needs one request.
How CrowdSec works
CrowdSec parses logs too, but adds a shared reputation layer. When an IP is flagged as malicious by enough participants, that signal is distributed, and your server can block an attacker it has never seen.
The tradeoffs: it is a heavier install, it depends on a network service, and blocking based on someone else's observation means occasionally blocking something you would not have blocked yourself.
The architecture difference that matters
CrowdSec separates detection from enforcement. The agent parses and decides; separate components called bouncers apply the block, and they can sit at different layers, firewall, web server, application, or CDN. That separation is genuinely useful, because it means the same decision can be enforced at whichever point makes sense for the traffic in question.
sudo cscli metrics
sudo cscli decisions list
What shared intelligence buys and costs
The buy: coverage against distributed campaigns. A botnet probing ten thousand servers once each is invisible to any per-server threshold and visible to a pool.
The cost: you are acting on observations you cannot verify. Reputation data can include addresses that are shared, recycled, or wrong for your context. This is manageable, decisions are visible and removable, but it is a real difference from a tool that only ever acts on what it saw itself.
Which to choose
For a single server with a handful of exposed services, fail2ban is usually enough and takes ten minutes to configure well - pair it with an SSH hardening pass and you have covered most of the risk. For a fleet, or for anything internet-facing at scale, the shared intelligence in CrowdSec meaningfully shortens the window between an attacker starting and being blocked.
Running both is common and works fine, they write to different chains and do not fight each other. Just watch for double-banning inflating your rule count over time.
A reasonable decision shortcut:
- One or two servers, mostly SSH exposure : fail2ban.
- Public web application taking real traffic : CrowdSec, mainly for the web-layer scenarios.
- A fleet, or servers managed for clients : CrowdSec, or a managed layer that handles this centrally rather than per host.
- Restricted egress or an air-gapped environment : fail2ban, since the shared component needs outbound connectivity.
Getting the configuration right
Whichever you pick, the same handful of decisions determine whether it helps or hurts. They are covered in more depth in how automated IP blocking works and how it goes wrong, but the essentials:
Allowlist yourself before enabling anything. Your office ranges, your VPN egress, your monitoring. Then confirm from a second connection that you can still reach the server before closing the session you already have. Locking yourself out of a remote box is a bad afternoon and it happens more than people admit.
Match ban scope to the offence. A web-layer detection should not result in an SSH-wide ban. Blanket drops on shared or NAT addresses take out everyone behind them, which on a corporate gateway can mean an entire client office.
Use escalating temporary bans, not permanent ones. Addresses get reassigned. A permanent ruleset becomes an unreadable pile within months and nobody dares prune it.
Mind proxies and CDNs. If traffic reaches you through Cloudflare or a tunnel, every request arrives from the proxy's address. Banning the connecting address eventually bans an edge node. Read the forwarded client address, and only trust that header from known proxy ranges.
The part neither solves
Both tools answer "who is hammering my login." Neither answers "did anything actually get in." A blocked IP list tells you nothing about a file that changed in your web root at 3am, a new listener on an unusual port, or a package with an unpatched CVE.
That gap is why blocking alone is not a security posture. You still need file integrity monitoring, behavioural baselining and continuous threat detection, and something that reviews the whole picture rather than one log file at a time.
It is also worth being clear about where blocking stops helping at all. Against volumetric floods it does nothing, because the bandwidth is consumed before your firewall sees the packet, that distinction is set out in detecting DDoS: Layer 4 and Layer 7 floods on a Linux server. And against a login with valid stolen credentials, there is no failed attempt to count.
SecAI runs both blocking and that broader monitoring layer, and uses an AI pipeline to work out which of the resulting alerts a human should actually look at. If you manage servers for multiple clients, the same engine runs white-label across a client portfolio. How the blocking layer fits with everything else is covered in the guide to Linux server security software, and if you are weighing managed options against self-hosted ones, SecAI vs Wazuh covers that comparison directly.
Frequently Asked Questions
Can I run fail2ban and CrowdSec together? Yes. They write to separate chains and do not conflict. Watch your total rule count over time, and be aware you may end up banning the same address twice.
Does CrowdSec send my logs to a third party? It shares signals about malicious addresses, not your log contents. If your environment restricts outbound connections or has data residency constraints, check the specifics against your policy before deploying.
Is fail2ban still worth running in 2026? Yes. It is simple, dependency-free, and handles the highest-volume threat effectively. Simple tools that keep working beat sophisticated ones that quietly stop.
Why is my fail2ban jail not banning anything?
Almost always a filter that no longer matches your log format, or a jail pointed at a log path that has moved. Run fail2ban-regex against the real file to confirm.
Will either of these stop a DDoS attack? For application-layer floods from a bounded set of sources, they help. For volumetric attacks, no host-based tool can, that has to be handled upstream at your provider.