• We value your experience with Plesk during 2025
    Plesk strives to perform even better in 2026. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2025.
    Please take this short survey:

    https://survey.webpros.com/
  • On Plesk for Linux mod_status is disabled on upgrades to improve Apache security.
    This is a one-time operation that occurs during an upgrade. You can manually enable mod_status later if needed.

Question Handling Large DDoS Attacks (Many Rotating IPs)

Hangover2

Regular Pleskian
Server operating system version
Debian
Plesk version and microupdate number
Plesk Obsidian 18.0.74 Update #3
Hello,

We currently have a client’s online shop under attack by a large bot network using thousands of different IPs.

For example, the last 50,000 requests in the logs came from more than 25,000 IP addresses worldwide. Blocking specific ISPs or countries doesn’t help in this case.

Our Imunify firewall also isn’t able to detect and stop the attack. The anti-bot / DoS protection doesn’t trigger because most IPs only request 1–2 pages and then rotate.

Besides Cloudflare, are there any effective options to mitigate this kind of attack on Plesk servers that we may have missed?

Thanks in advance for any ideas.
 
What we did in similar cases in the past, is to move the attacked site to a dedicated IP address and then depending on the attack volume and server load, either:

a) block all traffic for this IP address via iptables
b) only allow access from specific countries (we use iptables/ipset for that purpose) to this IP address. In most cases the local country of the site/shop owner was enough to cover 99% of it's customer base and this often proved to be "good enough"

Primary concern for us is always to keep the impact for all other sites on the same server as low as possible.
If that means that (only) the attacked site goes offline completely, then it is what it is and no biggie for us.
The affected customer can then still try to use/buy a Cloudflare subscription to keep the website online...


In the past we sometimes also used a module like mod_qos to "rate limit" a single site (to keep enough processes/workers available to all the other sites), but with Nginx and more so with the support for http2 connections, this method is no longer useful.
 
Hello @ChristophRo , thanks for your reply.

At the moment we’re following a similar approach. We already block some major cloud hosting providers (e.g., DigitalOcean) by denying their ASNs, since a lot of spam originates from their data centers. This helped, but it was not sufficient. For now, blocking whole countries is the only solution that reliably works for us: most attacks come from South America, Africa, India, and parts of Asia.

As a first test, we blocked these countries at the application (PHP) level using php-geoip, because a global block would require a separate dedicated IP, as mentioned. We are now implementing the more robust solution at the edge using NGINX and the ngx_http_geoip2_module.

Based on this Plesk article "(Plesk for Linux) Setting up IP Geolocation for a Website", we also found an interesting alternative to outright blocking:

“Protecting a Website From Brute-force Attacks From the Same Country”

This inspired the following approach:
  • Group “difficult” countries (where most attacks originate) in NGINX.
  • Throttle the entire group to e.g. 60 requests per minute.
NGINX:
limit_req_zone $throttle_group zone=throttle_countries:20m rate=60r/m;

Then we apply the limit (for now) only to direct PHP requests:

NGINX:
limit_req zone=throttle_countries burst=60 nodelay;

This way, users from those countries can still use the shop during normal conditions. If an attack happens again, the server remains stable because the group is capped at 60 requests per minute, which is low enough not to overload the shop system / our server.
 
We have the same problems, but with way more ips. The last attack was 500K Ips. Mostly Brasil, Vietnam and India. After starting to block them they shift to Afrika, Singpur even Germany via VPN Services. The ISPs are mostly Fixed Line IPS, like DSL Services or sth. The best way to fight them is the Cloudflare Under Attack Mode via the Managed Challenge. After you applied this the only thing you can do is wait. It will stop, but it may take days, but not weeks.

I tried the same way before with geofencing in nginx and limitig. The problem with this approach are the hyperscalers. Even by blocking only the "diffictult" countries we get issues that customer uses services from there or have services in the hyperscalers cloud that uses ips from that difficult contries. You have then to whitelist those ip adresses so the customer is able to use the services again.

Challenge Pages worked best at the moment.
 
We encountered the same issue, and in the end Cloudflare was the only effective solution.

Please see -
 
Back
Top