How many little sites do you run that get hit by DDoS? I personally run about 10 tiny websites myself, some of them have around ~1-2K daily active users, but neither of them have suffered from any DDoS frequently nor do they use CloudFlare at all. One has been hit once by a DDoS that kept trying for ~2 days to bring the site down, but a simple "ban IPs based on hitting rate limits" did the trick to avoid going down, so wasn't a very sophisticated attack.
It seems to be a common misconception that people defaults to, that you have to use CloudFlare or some alternative, otherwise you'll get hacked/ddos'd for sure.
You could do this with anything. X hasn't happened to me, so I bet it doesn't happen to other people, so people who take measures against X are misinformed/cargo-culting (unlike me who is conveniently the smart one in my narrative).
Most services I've built that achieved any sort of traction have dealt with some sort of DoS including large fees when I've used CDNs like Cloudfront that are susceptible to a wget loop. I default to Cloudflare because it's the only one that actually covers my ass.
Cloudflare is so successful because the internet was built naively as if abusers would never exist. Just consider how IP address spoofing is still possible today and you'll begin to realize how broken the internet has always been long before you even get into dirt cheap residential smart toaster botnets.
> Just consider how IP address spoofing is still possible today and you'll begin to realize how broken the internet has always been long before you even get into dirt cheap residential smart toaster botnets.
I know I'm going to regret asking but, ok, I'll bite... why does IP address spoofing prove the Internet is broken? Especially considering that a) the point of internet routing is to route packets whenever possible especially around damage. and b) by volume, the internet is TCP and you can't complete a handshake with a spoofed ip.
With spoofed src addr:
* you can do all sorts of udp amplification attacks (e.g. dns - send a zone transfer request in a single packet with a spoofed IP, and the IP you spoofed to gets a lot of traffic in response.)
* you can do tcp syn or ack floods with a spoofed IP, these eat resources on the target machine. syn floods cause the os to allocate a new connection and timers waiting for the third ack.
* you can send lots of bad packets from a spoofed ip that causes automated systems to lock out those IPs as a response to attack traffic. If those lockouts block IPs that should be allowed (a type of denial of service)
And plenty more.
I'm not terribly impressed... this reads like a response from an LLM. Yeah I know what kind of packets you can send with a spoofed source IP... But the question was, given these are all decades old, how does that prove the Internet is broken?
The point of the internet is to provide a robust communictions platform. If fundamental infrastructure of that communcations platform can be abused to deny communications, and further that the abuse can continue with the root cause unaddressed for decades, then the platform is broken.
The fact that routing is designed to go around damage is orthoganal to this, and has not bearing on the fact that the communications platform can be used against itself to prevent communications (via spoofed IPs).
For literal decades partial solutions to the spoofing problem have been known - rp filtering would eliminate a lot of problems yet still isn't close to universal.
BGP has been vulnerable to all sorts of simple human mistakes for decades and decade old solutions like IRR are only slowly being adopted because many of the people that run the internet are too busy pretending they are important and good at building systems to actually make the systems good. When those same simple mistakes are intentional, all sorts of IP traffic can be spoofed including full TCP connections.
The fact that there isn't a widely supported way for the consequences of spoofing to be mitigated without paying out the nose for a 3rd party service is pretty broken too. Allowing destinations be overwhelmed without any sort of backpressure or load shedding is a fundamental flaw in "get packets to destination no matter what". An AS should be able to say "I no longer want packets from this subnet", and have it honored along the entire path. This should be a core feature, not an add-on from some providers.
The internet does work as designed, however it's folly to think that the first attempt at building something so different to anything that came before it is the best way to do it and reusing to address design decisions is fundamentally broken.
First, I want to say thanks for the interesting reply! it's refreshing to read good arguments on HN again :)
> The fact that routing is designed to go around damage is orthoganal to this, and has not bearing on the fact that the communications platform can be used against itself to prevent communications (via spoofed IPs).
> For literal decades partial solutions to the spoofing problem have been known - rp filtering would eliminate a lot of problems yet still isn't close to universal.
It's orthogonal, and yet of the places where it would actually matter or have the strongest effect, it's not used? I wonder why... 'cept not really. The Internet seems to still be functioning pretty well for something fundamental broken. For the vast majority of internet routers it's entirely reasonable for them to accept any source IP from any peer. because it is impossible to prove that peer can't reach somebody else. The exception is a huge number of endpoint ISPs who shouldn't be sending these packets and it's on them to filter them. I would love a way to identify and punish these actors for their malfeasance, but I'm not willing to add a bunch of complexity to do so.
> because many of the people that run the internet are too busy pretending they are important and good at building systems to actually make the systems good.
wow, that's a super toxic comment... and I'm an asshole saying that.
> Allowing destinations be overwhelmed without any sort of backpressure or load shedding is a fundamental flaw in "get packets to destination no matter what".
one mans fundemntal flaw is another's design trade off... every single system that has ever seen widespread adoption has defaulted to open and permissive. every. single. one. it's only after seeing widespread adoption does anything ever add in restrictions and rules and most often when it does it's seen as the enshittification of something. (most often then because exerting control allows you to vampiriclly extract more value). but dropping packets one system is overloaded is exactly what the internet does do, what you're describing sounds more like TCP working around it. (poorly admittedly)
> An AS should be able to say "I no longer want packets from this subnet", and have it honored along the entire path. This should be a core feature, not an add-on from some providers.
I could not agree more. but this is a missing feature not a fundamental flaw. the internet still works for the vast, vast majority of users and as I've said in a different thread the use or dependency on cloudflare is often a skill issue not a requirement.
You're 100% correct, core internet routing has many fixable defects. and many ISPs are moving slower than could be reasonably considered ethical or competent. But for something this core of infrastructure I would actually prefer slow and careful over the break everything on a whim because of the "move fast" mind virus that has overtaken CS.
> The internet does work as designed, however it's folly to think that the first attempt at building something so different to anything that came before it is the best way to do it and reusing to address design decisions is fundamentally broken.
It's also needless absolutist to say every defect is a fundamental design decision. The Internet was built to support trusted peering relationships. Where if someone was being abusive, you'd call your buddy and say "fix your broken script". The core need the internet is now supporting is wildly different, and this "fundamental design flaw", is actually just user error. If you strap a rocket engine on a budget sedan, it's not a design flaw when the whole thing explodes. If you're going to add untrustworthy peers to your network you also have to add a way to deal with them. that's a missing feature not a design flaw.
Please do take note that I'm not saying anything like what you claim I said. I'm asking if it's something people commonly get hit by, as I myself haven't had severe issues with it.
I'm not saying others are misinformed or cargo-culting anything, just that I'm seeing lots of people who probably never get hit by DDoS in the first place (couple of visitors per day) adding CloudFlare by default as that's what they see everyone else is doing.
Of course if you do frequently get hit by DDoS attacks, there is nothing wrong with trying to protect yourself against it...
FWIW Cloudflare offers lots of useful services beyond DDoS protection—that's just one of them. Once you use Cloudflare for one service, it's nice to have all of your domains going through their DNS at the very least even if you were to bypass their stack.
Aside from ideological preferences or a preference for some other service, I don't see what you gain by avoiding them.
> IP address spoofing is still possible today and you'll begin to realize how broken the internet has always been
not that you need to have the answer to make your point, but now I am curious: what is the alternative architecture that prevents IP address spoofing? Wouldn't proving you are the IP you purport to be require some sort of authentication, which requires some centralized authority to implement? Which would require a fundamentally centralized internet?
> Which would require a fundamentally centralized internet?
Yes, that fundamentally central authority overseeing the IP address space exists today as IANA, which delegates to RIRs such as ARIN and RIPE, who allow ISPs to assert authority over address space cryptographically (RPKI) and/or in a central registry (IRR). This is the basis on which BGP announcements are typically filtered.
> what is the alternative architecture that prevents IP address spoofing?
It is possible to extend the same filtering approaches used with BGP to actual traffic forwarding without making fundamental architectural changes. See BCP38 (access) and BCP84 (peering). Widespread adoption of these would eliminate IP spoofing.
There's two parts to the answer to GP's question. One is egress filtering, which is widely deployed, and the other is BGP security, which as you know is being deployed.
I've never had any of my 3 houses burn down. I don't know why everyone says buy insurance, and having a fire extinguisher is a good idea.
It seems to me like a common misconception that you "have to have a fire extinguisher" (or other supression system), otherwise you'll have your house burn down.
I personally don't usually use it, but if I ran a Mastodon instance or blog or anything with real traffic and limited bandwidth and the slightest potential to piss someone off, I would. I am definitely not surprised by the amount of people using it.
I wrote this before here, but my site (small b2b saas with a few 100 avid users from small-medium sized companies) gets hit by massive DDOSs a few times a year. The only way I can protect against that is CF bot fight. Everything else will just immediately kill the service until it's over. The last one lasted 24 hours; there were millions of requests from 100000s unique ips over that time; many ips from azure, gcp and aws. Why? I don't have a clue but with CF you simply notice nothing at all.
I cannot rate limit on the machines itself as they die immediately, so then I need to get more advanced firewalls etc which are vastly more expensive than CF.
> How many little sites do you run that get hit by DDoS?
Do you live in a country that has enemies? DDoS attacks are one of the primary weapons of cyberwarfare.
You may not have suffered an attack yet, but thinking the world is a peaceful place in which small players have no worries is naïve.
> Do you live in a country that has enemies?
Who doesn't?
> You may not have suffered an attack yet
But I literally shared in my previous comment that I have?
> thinking the world is a peaceful place in which small players have no worries is naïve
I agree, and I guess I'm lucky for not holding such opinion then.
good luck with all those strawman replies...
It only takes one trivial event to make you a cloudflare zealot, most ISPs (web hosts) don't provide attack mitigation nor prevention. If you didn't know that you could ban IPs programtically you'd have been screwed* and would have loved how quickly cloudflare would protect your site.
It's not a difficulty thing, it's an ignorance thing. cloudflare isn't better,or magic, it's easy and popular. Just like social media, and aws.
For some people, i.e. most 'web developers' you will get hacked if you don't use it... because the alternative would be literally nothing. Not everyone wants to do things correctly, they only want it to work, working correctly is required.
What's the correct way to do things if I don't want to use Cloudflare for attack mitigation?
I'm not an expert in network security, so I can only give you an idea. The correct way to do things depends on so many factors, but the TLDR n probably use multiple ways to identify malicious traffic, and then block it as early as possible. Dropping all traffic from abusive IP addresses with netfilter is where you start because it's easy/simple. Then you can move on to grouping by ASN, and dropping closer to a load balancer.
The problem (as far as I know) that cloudflare actually provides, is being able to identify abusive networks, and making them prove they're not bots before they reach your server. If you can't even identify the abusive traffic, you don't have many options other than cloudflare.
Depends what you're counting as "little", but maybe your experience of 10 tiny sites has blinded you to the fact that sites for activist organisations, whistleblowing, investigative journalism, non-profits and so on, are very regularly targeted.