Layer 7 Anti-DDoS protection not working on Web hosting?
My site on WP was subjected to a small attack and immediately went down.
Technical support traditionally ignores tickets.
Why declare support for protection when selling hosting, if in fact it does not exist, OVH is becoming similar to Hetzner, they also provide protection only in words.
Web Hosting - Layer 7 DDoS protection on Web hosting
Related questions
- Max_execution_time how to increase time
7322 
24.01.2021 17:14
- How do I limit upload_max_filesize? PHP.ini method not working
7264 06.12.2022 11:02
- Update MySQL Version
7094 14.02.2018 03:27
- I can't login to my account. Reset password don't help
7085 25.02.2020 22:06
- Connect to mysql database
6586 28.02.2018 16:52
- Cannot put SSL on my domain
6059 03.04.2019 19:20
- How do I get rid of the default 'site under construction' page?
5757 27.10.2022 14:35
- Trying to connect my OVH domain to shopify store
5732 13.06.2021 22:43
- Increase PHP Post Max Size and PHP Time Limit
5255 20.09.2023 07:11
- Why can not connect my domain name with my host in ovh?
4926 09.01.2020 09:13
Hi,
Generally, when hosting providers advertise “DDoS protection” in their web hosting offers, they’re referring to network-level mitigation at layers 3 and 4. Almost no low-cost hosting providers in the world, charging just a few euros per year, offer DDoS protection at layer 7.
What some hosts like os2switch and Planethoster do when there’s a layer 7 attack is to put up a captcha during the attack in order to authenticate each request, but this also affects legitimate visitors — which is a problem.
For websites that are targeted by layer 7 DDoS attacks, you really need at least a VPS or a dedicated server in order to properly set things up yourself at the firewall and CDN level.
The reason hosting providers don’t protect all shared hosting servers at layer 7 is precisely so they can offer low-cost pricing, and especially because small websites are very rarely the target of hackers. Attackers usually go after larger organizations.
The investment is therefore not worthwhile for hosting providers to protect small websites.
It's very sad to see this picture in 2025.
A company as big as OVH couldn't implement basic layer 7 filtering with the same captcha or JS call. It would be worthwhile to make a corresponding option in the control panel.
And as for layer 4, they still haven't been able to implement filtering from layer 4 attacks inside their network.
OVH is going downhill!
Hello@VeRtiG0 @KoDe ,
It's not exact, we have L7 protection on shared hosting infrastructure, and not only one level.
The most common can be enable on your service for each domain and is called "firewall"
The others L7 stages are not customisable by customers but protect all our customers.
--
Bruno B.
Team Lead OVH Shared Hosting infrastructures
Hello,
Consider using Cloudflare in front of your website.
OVH has set a simple protection against clients that do not present the User-Agent header,
ant there is a "Firewall" setting in the Multisite panel that is not at all a DDOS protection, but rather Apache::mod_security
Hi.
The idea is great, of course, but you don't take into account that in some countries "ECH Protocol" is blocked and the site simply does not open for users, it is impossible to disable this option on the free CloudFlare plan, and paying $20 per month for this checkbox is too expensive.
That's why I need direct access to the site for some users bypassing CloudFlare proxying.
Do you have any other ideas, I would like to hear them?
Hello,
> in some countries "ECH Protocol" is blocked
I was not aware of this. Thank you for the info.
Hello@KoDe
Can you explain your usecase with ECH Protocol please ?
This protocol is based on the DNS over https and is on client side and for DNS not on http server who serve your website.
--
Bruno B.
Team Lead OVH Shared Hosting infrastructures
Hi.@Bruno B.
In October 2024, Cloudflare activated TLS Encrypted Client Hello (ECH) technology by default for all clients of its CDN service. This extension encrypts HTTPS request metadata, including the SNI (Server Name Indication) field, making it difficult to identify domains. Roskomnadzor (RKN) regarded this as a tool for bypassing the blocking of prohibited resources and a violation of the law, including requirements for technical means of countering threats (TSPU).
Technical consequences of blocking
- Blocking mechanism: RKN detects connections with TLS ECH by two signs: the presence of the SNI extension cloudflare-ech.com and ECH itself. Traffic is discarded by discarding packets, which leads to timeouts in browsers (Chrome, Firefox), but does not affect tools without ECH support, such as wget.
--------
Subsequently, the site's traffic dropped, not everyone can use VPN, it's easier to go to another site than to turn on VPN and bypass these blocks.
I hope I answered the question.
Hello
Sorry to hear that, it's not supposed to happen.
Please tell the targeted domain and the time of ddos OR the OVHcloud support ticket number with these information. I will check your hosting and ask support about what happened.
The WebHosting solution has several (multi-layers, including L7) ddos protection systems.
Ovhcloud also provides a CDN offer which includes additional ddos protection mechanisms (but first let's confirm what happened).
Victor
Hi.
Number CS11447099
All necessary information is indicated on the ticket. Approximate time is Saturday, August 16, 17:17:49 UTC 2025.
Got it. Which tool did you use to perform your ddos test ?
Free l7 booter websites, ~ approximately 600 unique IP addresses.
support in the ticket responded as follows:
"But please note that some of that feature are available only for servers and not shared hosting like your cluster021.hosting.ovh.net
For example you can't create personalised rule in the firewall in a shared hosting.
To answer your request, please note that our system cover mainly layer 3 or 4 attacks, for layer 7 the situation is complex and we don't cover all the possible attack. "
it turns out that even from a basic free attack at l7 there is no protection?
At the same time, protection based on kyprizel/testcookie-nginx-module remains impenetrable for this type of attack, even without displaying the button, just on automatic JS processing.
Some shared hosting providers provide a similar JS call.
You have similar protection, I saw a temporary redirect to "/?_xxxxxx", but it did not work properly....