February 28th DDoS Incident Report
51–60 of 114 posts
Re: February 28th DDoS Incident Report
#52DDoS 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.
Re: February 28th DDoS Incident Report
#53DDoS 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.
Now that we are moving away from net neutrality, can we not get ISPs to do DDOS protection so that we don't need specialised services like Cloudflare to be layered on top of simple sites?
- 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.)
Re: February 28th DDoS Incident Report
#54Re: February 28th DDoS Incident Report
#55What’s the point of a DDoS on GitHub anyway? Extortion or pure malice? I don’t see them paying a ransom to stop it so why bother?
Re: February 28th DDoS Incident Report
#56Is there any legitimate reason to spoof a source IP? I don't think there is, why don't ISPs block any traffic with a source IP that isn't in their network. And then the rest of us block any ISPs that don't do that.
Yes, absolutely - there are plenty of scenarios like, ironically, DDoS mitigation where you use source IP spoofing/asymmetric routing. It's still possible to restrict it, but simple RPF checks don't always cut it.
There is almost no reason whatsoever for clients to spoof their public IP address. Obviously, there are reasons to SNAT at the carrier level for load balance or routing purposes.
Re: February 28th DDoS Incident Report
#57Is there any legitimate reason to spoof a source IP? I don't think there is, why don't ISPs block any traffic with a source IP that isn't in their network. And then the rest of us block any ISPs that don't do that.
Yes, absolutely - there are plenty of scenarios like, ironically, DDoS mitigation where you use source IP spoofing/asymmetric routing. It's still possible to restrict it, but simple RPF checks don't always cut it.
Re: February 28th DDoS Incident Report
#58Earlier quoted context omitted.
Yes, absolutely - there are plenty of scenarios like, ironically, DDoS mitigation where you use source IP spoofing/asymmetric routing. It's still possible to restrict it, but simple RPF checks don't always cut it.
Let's rephrase the question - Is there any reason consumer ISP's don't follow BCP38? There is almost no reason whatsoever for clients to spoof their public IP address. Obviously, there are reasons to SNAT at the carrier level for load balance or routing purposes.
Re: February 28th DDoS Incident Report
#59Earlier quoted context omitted.
Yes, absolutely - there are plenty of scenarios like, ironically, DDoS mitigation where you use source IP spoofing/asymmetric routing. It's still possible to restrict it, but simple RPF checks don't always cut it.
How could source IP spoofing help with DDoS mitigation?
Re: February 28th DDoS Incident Report
#60In my day, such back-end services were either simply not connected to the Internet (connected via a private network to the application services), firewalled, or at the very least, configured to listen for and respond exclusively to connections from known front-end or application services.
Is this sort of deployment architecture falling out of favor? My casual observation is that cloud architectures—at least the ones I've seen employed by small organizations—are more comfortable than I am with services running with public IPs. What is going on? Am I misunderstanding this in some way?