Net Shaker

Written by: Tim Davis Created: 21 July 2026

Category: Net Shaker

New!Hits: 422Reading time: 05:13

The short version: In a single week this month, the quiet protective layer around our shared hosting turned away roughly 600,000 hostile web requests — and you never noticed, because never noticing is exactly the point.

Read the full technical breakdown ↓

What that wall actually is

Every website that's online gets knocked on all day long by automated programs looking for a way in. Not people — scripts. They run around the internet around the clock, rattling doorknobs on millions of sites at once, hoping to find one that's been left unlocked.

Most site owners never see any of this. You look at your website, it loads, it works, and everything seems calm. What you don't see is the layer sitting in front of your site that quietly turns most of those knocks away before they ever reach the actual website.

That layer is part of what your hosting with us is for. And this month I pulled the numbers on how hard it's been working, because they surprised even me.

Three kinds of knocks it turns away

Here are the three biggest categories from this past week, in plain English.

1. People trying to log into software you don't even run. A huge share of the automated traffic is scripts trying to break into WordPress — guessing usernames and passwords at the login page. The catch: a lot of the sites they're attacking don't run WordPress at all. Our monitoring turned away over 275,000 of these WordPress-login attempts across our servers in a week, most of them aimed at sites that have never had WordPress installed. It's the digital equivalent of a burglar trying keys in a door that isn't there.

2. Scripts fishing for a back door. Another large group goes hunting for the specific filenames that hackers leave behind after they've broken into a site — little hidden control panels called "web shells." The scripts guess at hundreds of these known filenames, hoping one exists. Our monitoring blocked over 215,000 of those probes in the week. None of them found anything, because those files aren't there, but the scripts keep asking anyway.

3. Visitors we already know are trouble. When the same source keeps hammering away, it gets added to a shared block list, and after that it's turned away at the door before it can generate any load on your site at all. That list holds a couple of thousand known-bad addresses at any given time, and it's shared between our servers so a troublemaker caught on one is already blocked on the other.

Why you never notice

Add it all up and it's roughly 600,000 turned-away requests in a week, across the two shared servers. If even a fraction of that reached your actual website, you'd feel it. Pages would drag, the site would feel sluggish, and sometimes it would fall over entirely.

Instead, both servers spent that week sitting at completely normal, relaxed load levels. The wall absorbs the noise so your site doesn't have to. That's the whole design: the busier the wall is, the less you notice, not more.

The week we accidentally blocked a friend

I'll share one that didn't go perfectly, because I think you deserve the honest version and not just the wins.

A few weeks back, while I was copying a block list from one server to another, I accidentally picked up an address I shouldn't have. It belonged to the tool we use to keep an eye on whether your sites are up and running. For about three days, that watchful tool got a polite "no entry" every few minutes on every site it was checking, and eventually it started reporting sites as "down" that were perfectly fine.

I caught it and fixed it the same weekend, and I added a permanent "never block these" safeguard so this particular mistake can't happen again. Three weeks on, that fix has held with no repeat. A wall this busy will occasionally wave off a friend by mistake. The honest measure of a good one is how fast you notice and how you make sure it doesn't happen twice.

The bottom line

There's a protective layer around your website that you never see and rarely think about, and that's a sign it's doing its job. If you host with us, this is part of what that relationship is quietly doing on your behalf every hour of every day.

And if you're not sure what your current host is doing at this layer, that's a fair question to ask them. If you'd like us to take a look at how your own site is protected, just reach out.

The technical breakdown

The rest of this post is for fellow admins and the technically curious who want the receipts. If you came for the summary, you're done — thanks for reading.

The layers

The "wall" isn't one thing. It's a few layers stacked so each catches a different class of traffic:

• Network layer (CSF/lfd): a firewall deny-list that drops known-bad source addresses at the connection level, before Apache or PHP ever wake up. Around 2,200 entries per server, synced between them. Repeat offenders get promoted here automatically, which is why they stop showing up in the application-layer logs — they no longer get far enough to be logged.
• Application layer (ModSecurity), Cloudflare-real-IP aware: for sites fronted by Cloudflare, ModSec is configured to inspect the true client IP (from CF-Connecting-IP) rather than Cloudflare's edge address, so a single abusive visitor can't hide behind the CDN. On top of the standard ruleset we run a handful of custom rules tuned to what actually hammers our servers.
• A global XML-RPC block and per-account process-suppression rules that keep the alert noise honest so real signal doesn't get buried.

The numbers (past working week)

Two custom application-layer rules do most of the work now:

Combined, that's on the order of 600,000 blocked requests in roughly one working week — about 72,000/day on the busier server and 40,000/day on the other — with both boxes sitting at normal load throughout (load averages around 2–3 and under 1, respectively).

One honest footnote on a big number

If you were watching these logs a few weeks ago, rule 9000001 alone showed close to 150,000 hits in a comparable window. Almost all of that was two artifacts: a scraper burning tens of thousands of requests against one endpoint (since promoted to the network-layer deny-list, so it no longer reaches ModSec), and — less flatteringly — residue from a self-inflicted block of our own uptime-monitoring IP, fixed at the end of June. Stripped of both, the honest steady-state is what you see above: the volume didn't drop, it moved to the two custom rules that catch the WordPress-probe and web-shell-probe floods.

Who's knocking

The top sources this week were overwhelmingly cloud-hosted scanners, most of them living in one large cloud provider's IP space, distributed across many addresses at a few thousand requests each rather than one dominant offender. That distribution is deliberate on the attackers' side (spread the load, dodge simple rate-limits), and it's exactly why layered defense beats any single blunt rule: the network deny-list catches the persistent ones, the application rules catch the pattern regardless of which address it comes from.

The takeaway for other admins

None of these rules are exotic. The lesson isn't "run our exact ruleset." It's that a small number of well-targeted custom rules (block WordPress paths on non-WordPress vhosts; block known web-shell filenames outright; make ModSec Cloudflare-real-IP aware) will absorb a genuinely surprising volume of the automated noise that would otherwise reach PHP and your database. Measure what your wall is actually catching. The number may surprise you too.

← Back to the plain-English summary

Interesting blog? Like it on Facebook, Post it or share this article on other bookmarking websites.