DDoS is a reminder of how broken the internet is.
How many times are we going to see the HN comment that says "lol why do so many people use Cloudflare? I don't need it for my blog!"
Naive decentralization (naive trust) doesn't work.
How many times are we going to see the HN comment that says "lol why do so many people use Cloudflare? I don't need it for my blog!"
Naive decentralization (naive trust) doesn't work.
There are still a zillion low-end bottom feeding web hosts who wouldn't do anything about this, though.
It strikes me that this would prevent a massive number of amplification attacks.
- Volumetric attacks like this one, mostly reflection.
- Application level attacks like SYN floods or protocol-specific attacks.
Defending against both costs a LOT of money.
Volumetric attack are dealt with at the network edge using rate limits and router ACLs. They're really easy to identify and block, but the point is that you need more bandwidth than the attacker in order to successfully do so. With attacks in the terabits-per-second range, this gets expensive.
Application-level attacks are harder to execute since there's no amplification and you need more bandwidth to pull it off, but they're much harder to block, too. They exhaust the server software's capacity by mimicking a real client. Common examples are SYN or HTTP floods.
When you get hit by a DDoS attack, you have two choices:
- Filter the attack and block the offending traffic without affecting legitimate requests. This is hard, and most companies can't do this. They need to have someone like Akamai on the retainer and dynamically reroute traffic like GitHub did.
- Declare bankruptcy and announce a blackhole route to your upstream providers (taking down the host in question, but protecting the rest of your network).
When you host custom applications that can't be scaled out or cached, DDoS mitigation is especially hard since you cannot just throw more servers at it like CloudFlare does.
Most services we host use proprietary binary UDP protocols, which is unfortunate, since UDP is easy to spoof and even experienced DDoS mitigation companies have trouble filtering it. Our customers get hit by DDoS attacks 24/7, so blackholing is not an option.
We had to build our own line-rate filtering appliances in order to handle the ever-increasing number of application-level DDoS attacks, by reverse engineering the binary protocols and building custom filtering and flow tracking.
All of this costs a huge amount of money, and most ISPs simply lack the resources to do this.
Happy to answer questions, but I'm going home right now, so it may take a few hours :-)
(Nitrado is a leading hosting provider specializing on online gaming, both for businesses/studios and regular customers, so we're dealing with DDoS attacks on a regular basis. We got hit with the same memcached attacks than GitHub and CloudFlare, and it was the largest attack in our company history. Ping me if you want to talk.)
Based on how it's done, you can't check first if the page hidden behind clouflare is something you'd want to enable javascript for, because clouflare will not let you see the HTML code of the page, without enabling javascript for it first.
That is broken.
Does anyone have an example of this webpage?
Unless I am engaging in e-commerce, I do not run a browser JavaScript engine. I rarely if ever encounter a webpage that truly "requires" one. GitHub certainly does not require JavaScript for me to use it via www.
It's a requirement when a CloudFlare'd site is in "I'm under attack" mode.
"What's also cool is that data on attack traffic that doesn't pass the automatic checks is fed back into CloudFlare's system to further enhance our traditional protections."
"[P]re-vetted traffic"?
Does this mean they are whitelisting certain IP addresses?
GoogleBot can make hundreds of requests and double digit parallel connections, as frequently as they like, but a single user making one request and one connection is blocked because they are not enabling Javascript?
This does not sound like an intelligent filter.
"[K]nown legitimate visitors"?
What exactly does this mean? How do they "know" a visitor is "legitimate"?
"[A]ttack traffic that doesn't pass the automatic checks..."
Is it possible that non-attack traffic could fail the checks?
What about a single request from a single IP that does not pass the checks because the user does not have JavaScript enabled?
Does the IP address end up on some blacklist?
I have seen Cloudflare reject connections based on certain user agent strings, a header that everyone knows is user-configurable, arbitrary and not a reliable indicator of anything meaningful.
This despite volumes of "legitimate" traffic from same source preceding it. Pick wrong user agent string and suddenly the source becomes "illegitimate".
It would be interesting to know what "checks" the Javascript in question is performing.
We make things more annoying for VPN traffic because it's 99% bad actors. Every time someone is up to no good on our services, they're behind Tor/VPN.
It's simple cost/benefit analysis. If you think a business should bend to every single whim someone might have, then you haven't built much of one.
Making someone run Javascript so they can click on a captcha? Worth the loss of a few pennies because someone's angry about it on HN.
You need to conveniently ignore why people use Cloudflare to say that Cloudflare is breaking the internet. Ideally, nobody would have to use it, but that isn't reality.
Cloudflare provides some page with JS code that computes something and then procedes to the correct page if it is computed correctly.
So I can either enable JS both for the cloudflare interstitial page and for the target website, or I'm not able to access the website.
I'm not angry, I just close the website/go back to search results. I will not allow the browser to run random JS code from the target website for no reason, just because the interstitial page requires it.
Still, if someone requires computing random challenges in javscript in order to gain access to a web page, they're breaking the web. Javascript is still an optional addon.