Live data from Hacker News

February 28th DDoS Incident Report

githubengineering.com

51–60 of 114 posts

Re: February 28th DDoS Incident Report

#52

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.

Better than a private company playing gatekeeper for a massive amount of websites.

Re: February 28th DDoS Incident Report

#53

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.

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?

There are, fundamentally, two different kinds of 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.)

Re: February 28th DDoS Incident Report

#56
post #48

Is 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.

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

#57
post #48

Is 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.

How could source IP spoofing help with DDoS mitigation?

Re: February 28th DDoS Incident Report

#58
post #48

Earlier 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.

No good reason except "it costs money".

Re: February 28th DDoS Incident Report

#59
post #48

Earlier 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?

There are many scenarios where you send of traffic to another datacenter using a GRE tunnel or EVPN.

Re: February 28th DDoS Incident Report

#60
Am I old-fashioned to raise an eyebrow when I discover that Memcached servers are running visible to the public Internet? This strikes me as approximately as bizarre as having a database server that accepts connections from the public Internet.

In 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?

Post reply on HN