92% of Attackers Are Invisible to Your Server’s Default Defense
92% of Attackers Are Invisible to Your Server’s Default Defense
How threshold-based security tools like Fail2ban and Imunify360 miss the vast majority of malicious traffic
January 2026
The Promise
Fail2ban and Imunify360 are staples of server security. Their pitch is simple: watch for repeated failed attempts, and when someone crosses a threshold, block them. Five failed SSH logins? Banned. Ten 404 errors hitting sensitive paths? Blocked.
It sounds reasonable. It feels proactive. And for years, sysadmins have trusted these tools as their first line of defense.
But there’s a fundamental problem: attackers know about thresholds too.
The Numbers Don’t Lie
We analyzed 30 days of attack data across our network of over 2 million protected websites. The findings are stark:
| Metric | Value |
|---|---|
| Total malicious IPs detected | 2,488,343 |
| Total attacks recorded | 177,096,725 |
| IPs that hit 10+ different sites | 96,052 |
| IPs that would evade Fail2ban defaults | 2,293,154 (92%) |
That last number bears repeating: 92% of the malicious IPs we observed never hit any single site more than 4 times. Fail2ban’s default threshold of 5 failures would never trigger. These attackers are invisible to per-site defenses.
The Architecture Problem
The issue isn’t that Fail2ban is poorly written. The issue is architectural. Per-site security tools can only see their slice of the picture.
Consider an attacker who wants to scan 1,000 WordPress sites for vulnerable plugins. They have two options:
Option A: Hit one site 1,000 times. Get banned after attempt #5. Mission failed.
Option B: Hit 1,000 sites once each. Complete the entire scan. Never trigger a single threshold.
Our data shows attackers overwhelmingly choose Option B. We found IPs that hit over 1,400 different sites while never exceeding 4 requests to any single one:
| Source IP | Total Attacks | Sites Hit | Avg/Site | Max |
|---|---|---|---|---|
| 216.81.248.5 | 1,644 | 1,446 | 1.14 | 4 |
| 172.86.113.81 | 1,389 | 1,345 | 1.03 | 3 |
| 5.181.3.18 | 1,472 | 1,210 | 1.22 | 4 |
| 45.157.54.41 | 1,208 | 1,174 | 1.03 | 3 |
To Fail2ban on any individual server, these look like normal first-time visitors. From a network-wide perspective, they’re obviously malicious reconnaissance operations.
Attackers Know Your Thresholds
It gets worse. Sophisticated attackers don’t just avoid thresholds—they actively probe to discover them.
The Threshold Discovery Attack
The technique is straightforward:
- Send 1 failed login, wait, check if blocked.
- Send 2 failed logins, wait, check if blocked.
- Continue until blocked.
- Now you know: “This site blocks after N attempts.”
The Ban Duration Discovery Attack
Once blocked, the attacker probes periodically:
- 1 minute later—still blocked?
- 5 minutes—still blocked?
- 10 minutes—unblocked!
- Now you know: “Bans last 10 minutes.”
Our data caught this behavior in the wild. Look at these IPs returning at suspiciously consistent intervals:
| Source IP | Return Visits | Avg Gap | Pattern |
|---|---|---|---|
| 139.162.121.238 | 351,880 | 15.8 min | [16,16,16,16,16…] |
| 66.228.56.140 | 351,211 | 15.8 min | [16,16,16,16,16…] |
| 69.164.207.190 | 343,730 | 15.8 min | [16,16,16,16,16…] |
| 37.60.141.252 | 3,863 | 11.8 min | [10,10,10,10,10…] |
Those IPs are returning every ~16 minutes like clockwork. They’ve discovered that bans reset at 15 minutes, so they wait 16 and resume. The [10,10,10,10...] pattern in other entries shows attackers who’ve mapped 10-minute ban windows.
This isn’t guesswork. This is automated threshold evasion.
The Default Configuration Problem
Most administrators never change the defaults:
| Tool | Default Threshold | Default Ban Duration |
|---|---|---|
| Fail2ban | 5 failures | 10 minutes |
| Imunify360 | 10 failures | 10 minutes |
These numbers are documented. They’re in the installation guides. They’re in countless blog posts. Attackers know them by heart.
Armed with this knowledge, an attacker can:
- Stay at (threshold – 1) attempts per target, indefinitely
- Rotate through IPs, resetting attempt counters
- Wait out ban windows and resume exactly when they expire
- Distribute attacks across sites to avoid per-site detection entirely
The 3.6 Million Attack Blind Spot
Perhaps the most damning finding: the gap between network-wide detection and per-site detection isn’t a matter of a few extra attacks. It’s measured in millions.
We compared when our network-wide system would have blocked an IP (after 5 total attacks across any sites) versus when per-site thresholds would have triggered (after 5 attacks to a single site):
| Source IP | Network Block | Per-Site Block | Attacks Before Per-Site |
|---|---|---|---|
| 64.227.98.197 | 01:09:54 | 01:51:16 | 3,635,420 |
| 66.228.56.140 | 09:40:32 | 09:46:06 | 2,006,559 |
| 212.56.46.252 | 20:07:41 | 20:07:41 | 2,002,616 |
| 69.164.207.190 | 09:40:32 | 09:45:15 | 1,987,652 |
That first IP—64.227.98.197—launched 3.6 million attacks before any per-site threshold would have triggered. A network-wide system would have blocked it after attack #5.
The difference isn’t marginal. It’s catastrophic.
What This Means for Your Security
If you’re relying solely on Fail2ban or Imunify360’s default configurations, you’re protected against:
- Script kiddies using unsophisticated tools
- Brute-force attacks from single IPs against single targets
- The small minority of attackers who don’t understand rate limiting
You are not protected against:
- Distributed scanning operations (92% of observed attackers)
- Attackers who have mapped your thresholds
- Coordinated attacks across multiple IPs
- Anyone with access to documented default configurations
The Alternative: Network-Wide Threat Intelligence
The solution isn’t to abandon threshold-based security—it’s to stop thinking at the per-server level.
When you have visibility across thousands or millions of sites, patterns that are invisible at the individual server level become obvious:
- An IP that hits your server once has also hit 1,445 other sites today
- An IP staying under threshold is doing so across your entire network
- An IP returning every 16 minutes is evading bans systematically
This is the approach we take at We Watch Your Website. By aggregating attack data across our network of protected sites, we can block malicious IPs before they ever touch your server—not after they’ve already probed your defenses.
Conclusion
Fail2ban and Imunify360 aren’t broken. They’re doing exactly what they’re designed to do: block repeated failures from a single source to a single target.
The problem is that modern attackers don’t operate that way. They distribute. They probe. They adapt. And they read the same documentation you do.
When 92% of attackers never trigger your default defenses, it’s not a question of tuning your thresholds. It’s a question of changing your architecture.
Contact us to stop the 92%, and growing, number of networked attacks and stay on the bleeding edge of website defense.
We Watch Your Website has been protecting WordPress sites from malware and attacks since 2007. Our network-wide threat intelligence system currently protects over 2 million websites globally.