New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I can do filtering on my machine. But when it comes to L4 flood, filtering doesn't work. So, DDoS protection is necessary for me.
There are many ways to use a VPS where DDoS protection is not required. I do not need it on mine. A DDoS attack does not appear in my threat model. Sure, anyone can DDoS any random IP address, but my VPSs are unlikely to become random targets.
The VPSs I use do not come with DDoS protection. If they did, they would probably cost more. When you're at the very low end of Low End, then DDoS may not be included. That may not be sufficient for @sandoz, but it is okay for me.
thanks for the participation
For me, ddos protection is a bonus if available free(but not a must).
L7 attacks have always been a bigger threat for my purposes. Even with cloudflare forcing a "managed challenge" upon every visit, attacks would still be able to get through. I suppose my site was quite controversial to some, but it was still difficult to mitigate.
I'll only settle for not having it when it's something that can go down and I'll just hit the snooze button on. If it's vital and it's downtime means broken service for someone, I can't compromise.
For personal/test projects I don’t care and for public projects I look at it as a bonus.
I know this thread is old but I'll add I had DDoS with Ramnode (Seattle Data Center) for years. The business critical website is not for public use so no publicly advertised or indexed in search engines. But it was on a shared IP that is DDoS protected. Ramnode Seattle Data center uses CNSERVERS for DDoS. They started having a problem with their router causing packet loss but it was only noticeable if you had a website with complex pages. Your average Wordpress site, they claimed their other customers weren't complaining. I was one of very few but it made the business critical application almost unusable. It was painfully obvious when you brought up the developer tools on the browser and looked at the network object load waterfall view. Random different tiny files less than 2Kb in size would sometimes take 6 seconds to load. It was a nightmare.
The crazy thing is CNSERVERS did not have a hot spare nor a cold spare. So it took a week to fix as they had to order new hardware! I was like "are you kidding me?" So I had to have them assign an IP with no DDoS to my host and move the websites there. Fixed the problem. I will never go back to DDos Protection at Ramnode Seattle Data Center as this experience left deep scar marks and embarrassment with my client. And this was all caused by having DDoS. In all fairness this was the only incidence in over 6 years on Ramnode. But they did admit they use a different company for DDoS at their Los Angeles Data Cente that they have a very direct line of communication with whereas CNSERVERS in Seattle they have to "submit a ticket" just like a regular customer like you or me!
So I think in the future I would only put DDoS on websites that are public and have significant users to where it could attract an attack but leave private, business-critical websites not indexed by Google or advertised to public users on a non-DDoS IP as DDoS is essentially not only a potential benefit as a preventative measure, but technically, as demonstrated in my case, an additional possible bottleneck or point of failure in itself.
Note: That for the business critical website I have a hot-spare running on a host at another data center (using MySQL replication and rsynch file sync.) However it is for in case of major catastrophe at the Seattle Data Center. But theoretically if a DDoS attack happened I could update the DNS (which is on a 15-minute TTL) and send the users to the other server if necessary. I didn't do it in this case as the hot spare is slower, and the sync is one way so migrating back to the Seattle host would require some manual data transfer work and system downtime. Just getting off the DDoS IP was a relatively quick and easy solution.
thanks for sharing, very interesting experience @jazee