fail2ban vs WAF, IDS and SIEM tools

fail2ban is not a WAF. It is a log-based intrusion prevention tool: it reads log files after requests have happened and bans the source IP in the firewall once it has failed or misbehaved too often. A web application firewall such as ModSecurity with the OWASP Core Rule Set, or Cloudflare's WAF, inspects each HTTP request before it reaches your application and blocks malicious ones individually. They complement each other: the WAF stops the attack request, and fail2ban can ban the IP that keeps sending them.

The same "different layer" answer applies to Suricata and Snort (network intrusion detection on packets), Anubis (a proof-of-work gate against AI scrapers) and Wazuh (a SIEM whose active response can block IPs across many hosts). None of them is a drop-in replacement for fail2ban, and fail2ban isn't a replacement for any of them.

Where each tool sits#

Is fail2ban an IDS or an IPS?#

Both, in a narrow sense. It detects intrusion attempts by matching log lines (an IDS function) and prevents further attempts by banning the source (an IPS function). It is usually described as a host-based intrusion prevention tool. What it doesn't do is inspect traffic itself: if an attack doesn't produce a log line fail2ban has a filter for, fail2ban never sees it. A single successful SQL injection request leaves no "failure" in an access log, which is exactly the gap a WAF fills.

fail2ban vs ModSecurity (and the OWASP CRS)#

ModSecurity is a WAF engine embedded in Apache (v2) or used as libmodsecurity v3 with Nginx and other servers. On its own it does nothing; the OWASP Core Rule Set (CRS) supplies generic detections for SQL injection, cross-site scripting, remote code execution, scanners and protocol abuse, scored with an anomaly threshold. Trustwave ended its support for ModSecurity on 1 July 2024 and handed the project to OWASP, which maintains it alongside the CRS. Coraza, also an OWASP project, is a Go implementation that runs the same rules in Caddy, Traefik and other proxies.

ModSecurity is better at: blocking a malicious request on the first try, protecting applications you can't patch quickly (virtual patching), and attacks that leave no failure in logs.

fail2ban is better at: making an attacker go away entirely after a few attempts, protecting non-HTTP services, and costing almost nothing per request.

Use them together. ModSecurity writes a line to the Apache error log for every request it denies. fail2ban's apache-modsecurity filter matches those ModSecurity: Access denied with code 4xx/5xx lines, and the stock jail bans after just two:

[apache-modsecurity]
enabled  = true
port     = http,https
logpath  = %(apache_error_log)s
maxretry = 2
bantime  = 1h

The WAF blocks the individual attack requests; fail2ban then drops the scanner at the firewall so it stops consuming WAF CPU. With Nginx and libmodsecurity the log format differs — adapt the filter and test it with the regex tester.

fail2ban vs Cloudflare#

Cloudflare sits in front of your server as a reverse proxy. Its WAF, bot management, rate limiting and DDoS protection act before traffic reaches you, so attacks are absorbed on Cloudflare's network. Free plans get Cloudflare's Free Managed Ruleset (a subset of the full managed rules) and some custom and rate-limiting rules; larger rule sets and bot features are on paid plans. Check Cloudflare's current plan comparison for limits.

Two things change for fail2ban once a site is behind Cloudflare:

1. Your logs show Cloudflare's IPs unless you restore the visitor address (Nginx real_ip_header CF-Connecting-IP with Cloudflare's ranges in set_real_ip_from, or Apache mod_remoteip). Without that, fail2ban either bans nothing useful or bans Cloudflare itself. See fixing the client IP behind a reverse proxy.
2. A local firewall ban doesn't stop proxied traffic, because the connections come from Cloudflare. Ban at Cloudflare instead, with fail2ban's cloudflare action (global API key) or the cloudflare-token action (scoped API token), which add the IP to Cloudflare's IP Access Rules through the API (user-wide for cloudflare, for one zone with cloudflare-token).

That combination is common and effective: Cloudflare handles volume and generic attacks; fail2ban spots application-specific failures in your logs — WordPress logins, Nextcloud, a custom API — and pushes those bans to the edge. The full setup is in the fail2ban with Cloudflare guide.

fail2ban vs Anubis#

Anubis, by Techaro, is a small reverse proxy that answers new browser visitors with a JavaScript proof-of-work challenge; once solved, the visitor gets a cookie and passes through. It became popular in 2025 with Git forges, wikis and documentation sites overwhelmed by AI training crawlers. It is MIT-licensed and actively released.

The reason people compare it with fail2ban is that fail2ban struggles with modern scrapers: they rotate through thousands of residential and cloud IPs, and each address makes only a handful of requests, so no single IP crosses a maxretry threshold, and banning thousands of addresses one by one achieves little. Anubis doesn't care about the IP — it makes every new client pay a CPU cost that is trivial for a person and expensive at crawler scale.

Use Anubis for content sites hammered by scrapers; keep fail2ban for login brute force and abusive clients that do repeat from the same address. Anubis can also hurt: visitors without JavaScript and some legitimate bots can't pass, so configure its allow policies for search engines and feeds you want.

fail2ban vs Suricata and Snort#

Suricata (from the Open Information Security Foundation) and Snort 3 (from Cisco Talos) are network intrusion detection systems. They decode traffic, run thousands of signatures (Emerging Threats Open, Talos rules) and raise alerts; in inline IPS mode they drop matching packets. They see exploit attempts, malware callbacks and protocol anomalies that never reach an application log — but they can't see inside TLS without extra work, and they need tuning and real CPU.

fail2ban is far simpler and cheaper for its one job. A practical combination: run Suricata in IDS mode, and let fail2ban ban sources of high-severity alerts by reading Suricata's alert log with a custom filter. On a single VPS, though, Suricata is usually more than you need; fail2ban plus a WAF covers the common attacks.

fail2ban vs Wazuh#

Wazuh is an open-source SIEM/XDR platform: agents on each host ship logs and security events to a central manager, which correlates them, raises alerts and shows dashboards. Its active response feature runs scripts on agents when a rule fires — firewall-drop (iptables), firewalld-drop, host-deny, route-null, and netsh.exe on Windows — with optional timeouts that undo the block later.

So Wazuh can do fail2ban's job, fleet-wide, from one rule set, and adds file integrity monitoring, vulnerability detection and compliance reporting. The cost is running a manager, an indexer and a dashboard. If you already run Wazuh, its active response may replace fail2ban on those hosts; if you only want brute-force protection on a few servers, fail2ban is the lighter tool. Many teams run both: fail2ban for immediate local bans, Wazuh for visibility (it can ingest fail2ban's own log).

Putting the layers together#

For a typical internet-facing web server:

FAQ#

Is fail2ban a WAF?#

No. A WAF inspects each HTTP request before it reaches your application and blocks malicious requests individually. fail2ban reads logs after the fact and bans IP addresses in the firewall once they have failed or misbehaved repeatedly. They complement each other: fail2ban can ban IPs that a WAF such as ModSecurity keeps blocking.

Should I use fail2ban or ModSecurity?#

Both, for web servers. ModSecurity with the OWASP Core Rule Set stops attack requests like SQL injection on the first attempt; fail2ban stops repeat offenders at the firewall and protects non-HTTP services. Enable fail2ban's apache-modsecurity jail to ban clients after ModSecurity denies two of their requests.

Do I need fail2ban if I use Cloudflare?#

Often yes. Cloudflare filters generic attacks and floods at the edge, but it doesn't know which logins failed in your application. fail2ban reads your logs and can push bans to Cloudflare with its cloudflare or cloudflare-token action. You must restore real visitor IPs in your web server logs first.

Is Anubis a replacement for fail2ban?#

No. Anubis makes browsers solve a proof-of-work challenge so that large-scale AI scrapers rotating thousands of IPs become expensive, which fail2ban handles poorly. It doesn't stop SSH or login brute force. Use Anubis for scraper load and fail2ban for repeated failures from the same address.

Can Wazuh replace fail2ban?#

Yes, on hosts that already run the Wazuh agent: its active response can block IPs with firewall-drop or netsh when a rule fires, with a timeout to unblock. It needs a Wazuh manager, indexer and dashboard, so for a few servers that only need brute-force protection fail2ban is much lighter.

What is the difference between fail2ban and Suricata?#

Suricata is a network IDS/IPS that inspects packets against thousands of signatures and can drop them inline. fail2ban reads application and system logs and bans IPs after repeated failures. Suricata sees attacks that leave no log line; fail2ban is simpler and cheaper for brute-force protection. They can be combined.