Is Bot Traffic Overloading Your Server? Case Study: Juridice.ro

When one of Juridice.ro’s technicians noticed server load that seemed too high for the traffic the site was actually serving, the question was simple: where is it all coming from? The answer turned out to be hundreds of thousands of uninvited requests per day — none of them from readers.

Juridice.ro is one of the largest and best-known online resources for legal professionals in Romania, with roughly 550,000 monthly visits according to SimilarWeb. For a publication like this, every minute of degraded performance chips away at something harder to rebuild than a server: brand power. Readers who come for authoritative legal content expect the site to simply work.

This case study answers a question every growing website eventually faces: when your server load grows, how do you know whether it’s success — or parasites?

The Symptom: Load That Didn’t Add Up

Juridice was already a Helios Live client. There was no outage, no incident, no alarm — just a technician with good instincts who felt the servers were working harder than the audience justified, and asked us for guidance.

We went to the logs. What we found split into two separate infestations:

• Hundreds of thousands of SSH login attempts per day — brute-force attacks, with individual IPs firing anywhere from tens to thousands of attempts each.
• Tens of thousands of web requests per day specifically scanning for exploits — bots probing for vulnerable plugins, exposed admin panels, and known WordPress weaknesses.

Nothing had been tried against this before, for a simple reason: nobody knew the scale of it. A migration to Cloudflare was already underway — first as a static file CDN, later as a full proxy — but that had been planned to save resources, not to fight anyone.

Act One: The SSH Flood

Here’s the part that matters before we describe any fix: the chance of an actual breach was nearly zero. In earlier work with Juridice, we had already enforced SSH key-only login for all privileged accounts, with password authentication disabled. The only accounts that still allowed passwords belonged to website users — and none of the bots ever guessed a single valid username.

So this wasn’t a security emergency. It was a resource and noise problem: an army of bots consuming CPU, connections, and log space around the clock, for nothing.

Our first move was the classic one: fail2ban, automatically banning IPs after repeated failed attempts.

It worked — briefly. Then the attackers adapted. The same overall volume of attempts kept arriving, but spread across far more IP addresses, each sending fewer requests to stay under fail2ban’s thresholds. The scanners had simply reshaped themselves around our filter.

So we looked at where those new IPs were coming from. Practically every one of them was already listed on AbuseIPDB, the public database of reported malicious addresses. That gave us the second layer: an automated daily import of AbuseIPDB’s worst offenders, blackholed at the network level before they could even open a connection.

The result: from hundreds of thousands of attempts per day down to roughly 1,000 — a 99% drop — with a few hundred fresh IPs still being caught and banned daily by the combined system.

Act Two: The Web Bots

The web logs were actually where we had looked first, because web services are by far the most load-intensive part of Juridice’s infrastructure — and the exploit scanners were right there in plain sight.

The first fix was cheap and satisfying: we moved the WordPress admin login to a new URL and pointed a fail2ban filter at anything still requesting the old one. No legitimate visitor has any reason to request an admin login page — every hit on the old URL was, by definition, a bot identifying itself.

Then the Cloudflare migration introduced a twist. Once the main domain went behind Cloudflare’s full proxy, our servers no longer received requests from the open internet at all — every connection arrived from Cloudflare’s own IPs. Network-level blackholing was suddenly blind to who the real visitor was.

So we adapted again: the same daily AbuseIPDB list was imported into LiteSpeed, the web server, which sees the real visitor IP forwarded behind the proxy and can reject the request at the application layer.

Blocking Bad Bots Without Hurting Good Traffic

For a publisher living on search traffic, this is the question that matters most: how do you carpet-bomb bots without hitting Googlebot or your own readers?

In practice, the AbuseIPDB approach threaded that needle almost by itself. Google plays nice with the sites it crawls, so nobody reports its IPs — Googlebot sailed through untouched. Real traffic patterns didn’t change at all, and there was not a single complaint from a reader.

One category of crawler, however, did get caught — deservedly. We quickly noticed that Anthropic’s AI crawlers were among the blocked IPs, and the logs showed why: they had been hammering the site with strange, repetitive requests. That accidental catch resolved an older open item — Juridice had already decided to block all AI crawlers, but some were still slipping through the existing measures until our filters caught up with them.

As a final safety check on collateral damage: about 95% of all blocked IPs were located outside Romania. For a publication whose audience is overwhelmingly Romanian legal professionals, whatever marginal edge cases got caught in the net were a trade worth making.

Results

• Total server load dropped by about 15% — with zero hardware changes.
• Exploit scanning fell to zero. Tens of thousands of daily vulnerability probes, gone.
• WordPress login attempts dropped 99%.
• SSH brute-force attempts dropped 99%, from hundreds of thousands per day to around a thousand.

And the client’s reaction? “Thank you.” That’s the whole quote — and honestly, that’s what success looks like in infrastructure work. Nobody celebrates the flood that didn’t happen. The servers just got quieter, and everyone went back to work.

Lessons Learned

The fail2ban-then-adapt-then-blackhole sequence taught us something we’ve since turned into standard practice: the AbuseIPDB import plus fail2ban combination is now part of our default hardening process, applied from day one rather than discovered mid-fight. The attackers will adapt to any single filter; layered filters that draw on the collective reporting of thousands of other victims are much harder to route around.

If you’re thinking about upgrading your servers because of too much load, first confirm that the load is actually caused by legitimate traffic — before committing a single euro.

— Alexandru Eftimie, Helios Live

That’s the takeaway for every site owner reading this. Server upgrades are the expensive answer to a question you haven’t asked yet. In Juridice’s case, 15% of the “growth” in load was parasites — and eliminating them cost a fraction of what scaling up to accommodate them would have.

Conclusion

Juridice.ro’s servers were carrying two hidden armies: SSH brute-forcers and exploit-hunting web bots. Neither posed a realistic breach risk — the earlier hardening work had seen to that — but together they inflated load, polluted logs, and quietly taxed a platform that half a million readers depend on every month.

Two layered, largely automated defenses — fail2ban plus a daily AbuseIPDB blackhole, extended into LiteSpeed once Cloudflare’s proxy changed the terrain — eliminated 99% of the noise, cut total server load by 15%, and incidentally finished the job of shutting out unwanted AI crawlers.

No drama, no downtime, no new hardware. Just a technician’s good instinct, two log files, and the discipline to check who’s actually knocking before building a bigger door.