The fair starting point
Fail2ban, Wazuh, and Suricata are all serious projects that solved real problems. Fail2ban has been a one-liner answer to SSH brute force since 2004. Suricata is one of the best open-source network IDS engines ever built, with an active ruleset community. Wazuh runs whole government SIEM deployments. None of them are bad, none of them are obsolete, and we are not going to argue that. The question is whether running all three still makes sense for a small to medium operator.
Each one solves one slice of the problem well. The pain comes from running, tuning, correlating, and feeding three of them.
What each one actually does well
Fail2ban tails log files (auth.log, nginx, postfix), matches regex patterns, and bans IPs with iptables or nftables. It is small, fast, and reliable. For SSH brute force on a single box, almost nothing beats it for simplicity.
Suricata reads packets from a NIC or AF_PACKET, decodes protocols, and runs Emerging Threats or custom rules against them. It catches network anomalies, exploit attempts, C2 traffic signatures, and protocol abuse. Strong at the network layer, blind above TLS encryption.
Wazuh is a host agent plus a centralised manager and indexer. It does file integrity monitoring, log collection, vulnerability assessment, and compliance reporting (PCI, HIPAA, NIST). The manager runs Elasticsearch and a UI. It is the SIEM of the trio.
Where they overlap
SSH brute force detection: fail2ban does it from auth.log, Wazuh does it from auth.log, Suricata does it from packet rate to port 22. Three tools detecting the same event, and none of them correlate with the process that ended up spawning if the brute force succeeded.
Web exploits: Suricata fires on the request signature, Wazuh fires on the access log pattern, fail2ban bans the IP. Same event, three pipelines, different timestamps.
File integrity: Wazuh covers it. Neither fail2ban nor Suricata do. But Wazuh's check runs on a scheduled scan, not in real time.
What each one alone misses
Fail2ban alone misses anything that does not hit a log line: a reverse shell after a single successful login, a process spawning a container escape, an outbound C2 callback. It is a log pattern matcher, not a behaviour detector.
Suricata alone is blind to host activity. Once traffic is encrypted, which is most of it now, Suricata sees TLS handshake metadata and not much else. It cannot tell you a process inside the box opened that connection.
Wazuh alone covers more, but its detection relies heavily on log parsing. It is great at what already left a trail. eBPF-level observability of the syscall layer is not part of its model.
All three together still miss something: correlation across layers. The network event, the auth event, the file change, and the process spawn are pieces of one incident, but the tools do not stitch them.
What Inner Warden bundles
The single binary handles five layers in one process tree. eBPF sensor at the syscall and network layer, log tailing for auth and web, file integrity monitoring with real-time inotify, AI triage to score the resulting event, and notification plus autonomous response on confident high-severity events.
The 40 correlation rules tie events together. Three failed SSH logins followed by a successful one followed by a process exec outside the user's normal pattern fires one correlated incident, not four separate alerts. The dashboard athttps://localhost:8443shows the timeline.
# 49 detectors, 40 eBPF hooks, 40 correlation rules
sudo innerwarden detector list
sudo innerwarden correlation listOperational footprint
Running fail2ban plus Wazuh agent plus Wazuh manager plus Elasticsearch plus Suricata is a respectable amount of moving parts. On a small fleet you usually skip the Wazuh manager and run agents only, but then you lose half the value.
The Inner Warden binary is around 38 MB, uses roughly 60 to 90 MB of RSS in steady state, and ships logs to a local SQLite store with retention policies. No Elasticsearch, no broker, no manager. If you want central aggregation across hosts, that is the mesh module, which uses signed Ed25519 messages and runs without a broker. See mesh network game theory.
When you should keep one of the others
Honest answer: there are cases.
Keep Suricata if you have a network tap, span port, or NIDS sensor in front of a segment and you specifically need signature-based packet inspection on cleartext traffic. The two complement each other. Inner Warden does host eBPF, Suricata does the wire.
Keep Wazuh if you have a compliance auditor who asks for it by name, or if you are already invested in the Wazuh dashboards across hundreds of hosts and the migration cost dominates.
Drop fail2ban. The SSH brute force detector in Inner Warden is strictly broader (it sees the syscall layer too), and the auto-block uses the same ipset mechanism. We see no real reason to run both.
For comparison background, see fail2ban vs Inner Warden.
Migration path
Install Inner Warden alongside, run it in notify-only mode for a week, compare the alert stream against your current tools. You will see overlap on common incidents, gaps in the old stack on host-layer activity, and new categories of detection the old stack never produced. Decide what to drop based on data.
For most operators we have talked to, the end state was: keep Suricata if you had it already, drop fail2ban, drop Wazuh agent. For some, the end state was just Inner Warden. Both are reasonable.
Read more: Open-source server security 2026