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

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question best practices to be web ddos protected from Plesk

gennolo

Basic Pleskian
Hi all,

From a few days I am struggling with website accesses from china that puts my centos/plesk box KO.
It happens that within a second I have a GET request for 100+ different web pages for my e-commerce website that are
spiking my server load average and crashing everything :(

These accesses comes from legitimate user agents like
"Mozilla / 5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident / 5.0)"
so I can't put a block tied to the user agent.

Very often the ip is always the same so I can block it manually via plesk firewall,
in other cases they seem to be attacks generated by botnets (always from China) so they cannot be easily managed manually.

What do you recommend to try mitigating these situations automatically / with Plesk?

Should I consider third party filters / extensions (e.g. cloudflare), is it possible / a good idea to block connections by geographical area ?
Or to "tune" fail2ban with jails to limit simultaneous connections for ip without blocking legitimate traffic? (I already have plesk-apache / plesk-apache-badbot turned on but
they don't seem to be effective as GET requests are made to legimitate website pages)

Any help would be really appreciated !

Thanks
 
Hi @AYamshanov
Yes, I have full page caching on most part of the website,
but those GET requests are coming to particular pages that are often requiring invalidating cache // DB access.
 
Could start by throwing the domain on the free version of Cloudflare...

See how that goes and take it from there.
 
Thanks :)
Too bad there is no way to perform temp-ban GeoIP country blocking through Plesk / fail2ban ,
it would be a lifesaver in these occasions.
I just voted for the feature in uservoice :D
 
Frequently some of these Chinese attacks are actually some bad bots. If they come with regular browser IDs, there might still be a language ID tag like "zh-CN" in the log line. You can then use that language ID string to block the bots, e.g. in .htaccess like this:

Code:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} (LieBaoFast|zh_CN|Mb2345Browser) [NC]
RewriteRule .* - [F]
 
Hi @Peter Debik ,
thanks for your help.
In my case they spoofed their user agent to "Mozilla / 5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident / 5.0)"
so unfortunately your solution was definitely not working in my case :(
 
In the past I wrote a perl and a php script that protects perl and php scripts from the access of unwanted visitors (spammers, attackers).
It blocks spammers, attackers and content thefts by using his integrated IP database and, in addition, the returned data of the most importand RBL systems of the net.
Currently the main data base contains more than 159 million entries of bad IPs (even IP-ranges and tlds can be blocked) and the data base is growing up day by day.
Now I'm going to add fuctions to integrade and handle the server-side iptables.
This will be able to manage and to expand the rules of the iptable system by using the stored IP data of the perl/php scripts too.
 
In the past I wrote a perl and a php script that protects perl and php scripts from the access of unwanted visitors (spammers, attackers).
It blocks spammers, attackers and content thefts by using his integrated IP database and, in addition, the returned data of the most importand RBL systems of the net.
Currently the main data base contains more than 159 million entries of bad IPs (even IP-ranges and tlds can be blocked) and the data base is growing up day by day.
Now I'm going to add fuctions to integrade and handle the server-side iptables.
This will be able to manage and to expand the rules of the iptable system by using the stored IP data of the perl/php scripts too.
I don't understand your practice unless you have some mechanism which i fail to understand. Please explain of what use is 159 million entries? I em genuinely interested. I don't see any use even for 100 entries. That's very unusual practice unless i completely misunderstood you (which can be very possible thing).

There is a reason why (for example) Fail2Ban is banning some IP for a specific amount of time - usually 6,12,24 hours blabla.

Attackers and spammers are rotating their IPs anyway. So no use of adding IP to some database and having it permanently flagged.

Imagine this scenario. You have a client at your server. Let's call that client Sentinel Corp. From USA. They are communicating with outside world via emails or some other way. Doesn't matter.

Follow me now. Some stupid DDos group rent a server in UK. They abuse it and DDos the hell out of someone and they end up in your IP list somehow. I mean server IP end on your list as potentially dangerous whatever.

That same group/customer/client then is banned by UK server provider because any decent server provider is running internal tools to detect such behavior and then ban user because of violation. Ok.

After some time here comes John Doe, he arrive at UK company which is renting servers and then rent a server from UK company. He and his server is provided with previous IP which is already on your list as potentially dangerous IP. That actually is not rare occurrence that's happening to a lot of people. They are getting IP from previous user. But John Doe does not know that. Now John Doe is providing web hosting and he place company (for example) Blue Elephant.inc on his server. That same company won't be able to communicate with Sentinel Corp because you are running previously saved database of IP numbers. And some of these IP numbers are actually not potentially risky anymore. Hence my question of what use is 159 million IPs. When you say it like "159" million i am getting that perception that you keep (old) IP numbers which doesn't make sense to me.

Hence my question - can you explain a bit more without going in to revealing your system.
 
Last edited:
What do you recommend to try mitigating these situations automatically / with Plesk?

I would look at some sort of throttling solution with advanced filter - not blocking or adding IP to some database and keeping it flagged.
 
I don't understand your practice unless you have some mechanism which i fail to understand. Please explain of what use is 159 million entries? I em genuinely interested. I don't see any use even for 100 entries. That's very unusual practice unless i completely misunderstood you (which can be very possible thing).
Hence my question - can you explain a bit more without going in to revealing your system.
As far as you know what RBLs are (and contain), so far do you kow why they store bad IPs.
In case of John Dee owns one of the bad IPs: nothing will happen - that should be clear to you.
On the other hand:
my system is combined with a math captcha - so a human user can simply resolve the captcha and will not get any restrictions.
 
In case of John Dee owns one of the bad IPs: nothing will happen - that should be clear to you.
On the other hand:
my system is combined with a math captcha - so a human user can simply resolve the captcha and will not get any restrictions.

No it's not clear to me which is exactly why i asked. I know the reason why someone could store IP in database but it isn't because of preventing sucessfull DDos. Do you really think advanced script kiddies are using same IP for their abuse?

And OP asked about that not about captcha protection. Captcha won't solve his type of DDos attack at all. As you can see yourself he posted issues about legitimate user agent visiting his websites in very short amount of time. No login, no any kind of usual situation where captcha could help him.

Moreover math Captcha does not rely on IP database(afaik). So i am even more confused why you mentioned it in DDos thread of his type. You know what, let's call it a weekend.

As i said i misunderstood you and that's it.
 
Yes , you misunderstand me.
My proposal to resolve the problems of the OP was: use iptables geoip (and more)
After that I wrote something about the system that I use for my own (!) and I answered your questions about that.
If you want to know how to code AccessControl scripts - just let me know ...
 
Back
Top