Expose SSH or a website to the internet and the automated login attempts will find it. You do not need to read thousands of failed-password lines by hand, but you do need a sensible way to stop repetitive abuse. Fail2ban and CrowdSec both turn suspicious activity into firewall decisions.

They overlap, but they are not quite the same product.

Fail2ban: small, local, and predictable

Fail2ban watches logs, matches patterns called filters, and bans an address through a firewall action when a jail reaches its threshold. It has been doing that job for years, and for a single Linux server that is often exactly what you need.

On Debian or Ubuntu:

sudo apt update sudo apt install fail2ban

Create /etc/fail2ban/jail.local instead of editing the packaged defaults:

[DEFAULT] findtime = 10m maxretry = 5 bantime = 1h  [sshd] enabled = true

Restart it and inspect the jail:

sudo systemctl restart fail2ban sudo fail2ban-client status sshd

Adjust the backend only if your distribution does not read SSH logs correctly. Test from a system you control, and keep an active root or console session while changing firewall behavior so a bad rule cannot lock you out completely.

Fail2ban is easy to reason about: this log, this pattern, this threshold, this ban. It does not require a central account or a crowd to be useful.

CrowdSec: behavior detection plus shared intelligence

CrowdSec also parses logs and detects behavior locally. Its architecture separates the detection engine from bouncers, which enforce decisions in a firewall, reverse proxy, or another layer.

That split is useful when you want one place to detect abuse and another to block it. CrowdSec can also consume community intelligence about addresses exhibiting malicious behavior elsewhere, while sharing signals according to its configuration. Treat that as an additional data source, not as proof that every listed address attacked you personally.

Typical inspection commands are:

sudo cscli alerts list sudo cscli decisions list sudo cscli metrics

The metrics view is particularly important: it shows which log sources are being read and which parsers are working. Installing a security agent without confirming that it parses your actual logs creates comforting dashboards and very little protection.

Use the official installation documentation for your distribution, install the relevant collections for SSH or your web server, and add a firewall bouncer. Then generate a harmless test event or use CrowdSec's testing facilities rather than attacking your own public endpoint.

Which one should you choose?

Choose Fail2ban when:

  • You have one or a few servers.
  • SSH brute force and a small set of log patterns are the main concern.
  • You want minimal moving parts and fully local decisions.

Choose CrowdSec when:

  • You want a broader scenario ecosystem for web and service abuse.
  • Detection and enforcement need to happen in different places.
  • Community threat intelligence is valuable to your setup.

Running both against the same logs is possible, but it also creates overlapping bans and two systems to debug. For a small VPS, pick one and operate it well.

Neither tool fixes weak security

An IP ban is a reaction, not an authentication strategy. Disable SSH password login where practical, use keys, keep software updated, and restrict exposed ports. Our Fail2ban installation guide and SSH hardening guide cover those fundamentals.

Also watch false positives. A shared NAT address can represent many innocent users, and overly aggressive thresholds can ban your own office. Start with conservative rules, review alerts, and know how to unban an address.

For most home servers, Fail2ban remains a perfectly good answer. For richer web detection and distributed enforcement, CrowdSec earns its extra complexity. The best choice is the one whose logs, decisions, and recovery commands you actually understand.