680,000 real readers were challenged while the attackers were not.

The Situation

A high-traffic regional news site was dealing with two problems at the same time. Scammers were abusing its public job-submission form to publish WhatsApp links impersonating real local companies, while traffic suddenly jumped from a normal baseline of 723,000 to 1.48 million requests per day, a 104% increase in just 24 hours.

The owners responded by enabling Cloudflare's I'm Under Attack mode. It sounded like the right move, but it created another problem: the protection was challenging legitimate readers instead of stopping the attackers. In 24 hours, more than 680,000 real visitors were challenged, producing a 26.6% 403 rate, while zero attackers were hard-blocked.

What I Found

I started by pulling eight days of Cloudflare analytics (more than 50 JSON files) to establish a baseline and separate legitimate traffic from suspicious activity. The job-submission form received 15,005 requests in 24 hours, all using crafted /wa.me/ paths. The spam campaign used seven different WhatsApp numbers to impersonate real local companies, supermarkets, a dairy brand, and a transport company.

Performance First

Before changing the security rules, I protected the recovery path with a full database backup, settings snapshot, and theme-modification backup. I then traced the server crashes to a combination of Memcached being offline, WordPress Popular Posts writing directly to MySQL, a Jetpack autoloader rebuild, and a cache-exclusion rule.

I re-enabled Memcached object caching and configured WordPress Popular Posts to batch its database writes every two minutes instead of hitting MySQL on every pageview. I removed the unnecessary cache exclusion, disabled the duplicate /noticias/ rule, and restored the intended seven-day cache behaviour.

I replaced the broken Cloudflare API token with a properly scoped one and deployed a small WordPress MU-plugin that automatically purges Cloudflare whenever an article is saved. JNews required a separate investigation. By querying its cache directly through Memcached, I found the missing-expiry pattern and disabled the JNews query cache in favour of flush-on-publish.

Replacing Under Attack Mode

Once the origin was stable, I replaced the blanket Under Attack approach with targeted WAF protection. I created rules for verified bots, scanners and crawlers, sensitive endpoints such as /wa.me/, xmlrpc.php and the legacy Joomla endpoint, administrative and API access, suspicious threat scores, non-browser clients, and cloud-hosting traffic.

I also added two rate-limit rules: one for login and administration, and another site-wide at 500 requests per 60 seconds, with static assets excluded. This was important because a single article can generate 30–60 sub-requests. I fixed the broken ASN rule and removed the overly broad Vivo rule.

For the job form, I recommended Turnstile CAPTCHA and content filtering for WhatsApp links. I also recommended Cloudflare Access for /wp-admin and /wp-login.

The Rollout

The changes were deployed in three phases rather than all at once. Immediate endpoint blocks came first, followed by bot and rate-limit fixes. Only after those controls were working did I revert Under Attack Mode and clean up the conflicting cache rules.

This approach reduced the risk of a bad rule taking down the entire site or blocking legitimate traffic. Every major change had a rollback path, and the configuration was tested against the traffic patterns identified during the investigation.

The Sister Site

The secondary site had a different set of problems. It was receiving active web-shell scanning from a Korea-based IP, while requests from several countries were probing for sensitive files such as .env, .aws/credentials, and .git/config.

Its Cloudflare SSL mode had also been set to Flexible since 2020, leaving the connection between Cloudflare and the origin unencrypted. Barkrowler was consuming around 10.9% of the site's traffic without meaningful SEO value, and a malicious .htaccess file containing shell-related allowlist patterns was found in a staging directory.

I documented the required hardening steps, including moving to Let's Encrypt, switching to Full (Strict) SSL, reducing unnecessary crawler traffic, and removing the malicious staging configuration.

The Results

After 12 days of phased work, the primary site was stable. Server load dropped from crash-level spikes to around 10% utilization, or about 6.3 on a 64-core server.

Cloudflare's cache hit ratio recovered to 71.1%, while Memcached reached a 90.82% hit rate. MySQL connections returned to normal levels at around 77 of 2,000, and the editor's publishing workflow, which had previously taken minutes, was updating the homepage in seconds.

The Under Attack numbers made the security problem clear. More than 680,000 legitimate readers had been challenged while zero attackers were hard-blocked. Replacing the blanket challenge with targeted rules changed the security model from challenging everyone to identifying and controlling the traffic that actually needed attention.

Client Impact

This was more than a cache or firewall adjustment. The site moved from a security setup that was disrupting its own audience to one that could distinguish between legitimate readers, trusted bots, suspicious automation, and abusive traffic.

At the same time, restoring Memcached, correcting the cache hierarchy, fixing the Cloudflare integration, reducing unnecessary MySQL writes, and addressing the JNews cache issue reduced the amount of work the origin server had to perform.

The client received 203 JSON data files, 15 analysis documents, and rollback steps for every major change, leaving behind both a working configuration and a clear record of what was changed and why.