How to Launch a 65Gbps DDoS, and How to Stop One

Who are these irresponsible network operators that allow spoofed source addresses out of their network? The only way to make a reflection attack like this work is to make the responses go back to the victim. For that to happen, it has to look like they generated the request.<p>Remember smurf? Spoof-ping a broadcast address for a multiplication effect. It's from 1997 or so. 15 years later and we're still living with that kind of problem.<p><a href="http://en.wikipedia.org/wiki/Smurf_attack" rel="nofollow">http://en.wikipedia.org/wiki/Smurf_attack</a>

We tried to use Cloudflare when they teamed with Dreamhost a few months ago. We had more downtime than uptime....<p>Though this is super-relevant because during the struggle with Cloudflare, we released an article about LOIC and how easy it is to reveal the locations and identities of individuals involved in a DDoS attack using LOIC.<p><a href="http://www.thepowerbase.com/2012/03/low-orbit-ion-cannon-exposed/" rel="nofollow">http://www.thepowerbase.com/2012/03/low-orbit-ion-cannon-exp...</a>

Worth re-stating that they still had a severe outage due to other speculative corrective measures they took.<p><a href="http://blog.cloudflare.com/post-mortem-what-todays-network-outage-looked" rel="nofollow">http://blog.cloudflare.com/post-mortem-what-todays-network-o...</a><p><pre><code> Yesterday I posted a post mortem on an outage we had Saturday. The outage was caused when we applied an overly aggressive rate limit to traffic on our network while battling a determined DDoS attacker </code></pre> Kudos for documenting what you did and what worked.

Part of me has to wonder, how wise is it to attack somebody such as Cloudflare? I know they are a juicy target. But, part of their job is to learn and defend against downtime. If their ops are worth a salt (and it appears they are), they've been logging every bit of information they can about these attacks. Logging allows them to do two things:<p>1) Learn how to mitigate the attack in the future<p>2) Catalog data on botnets<p>Cataloging data on these botnets is one sure way to get them shut down.

I am surprised that the article did not mention egress filtering alongside closing open resolvers. If more edge routers did proprer egress filtering these attacks would be harder to pull off.

Do they inform the target?<p>While it's nice that they can stop an attack without the intended victim noticing, it's still probably a good idea to let them know.

I feel bad that I'm not currently paying for Cloudflare; I use it on a few sites but they don't have any traffic worth adding the extra fee for. However it's an excellent service and something I recommend often; hopefully I'll have something to make better use of it in the future :)

I dont really know much about security hacks, but if open dns is such a problem, then why does google have one (<a href="https://developers.google.com/speed/public-dns/docs/using" rel="nofollow">https://developers.google.com/speed/public-dns/docs/using</a>)?

I may definitely be missing something here, but I find it difficult to believe <i>not a single packet from that attack made it to their network or affected their operations</i>. I understand how the amplifications were mitigated, but how do you distinguish between legitimate and illegitimate traffic and then block just the illegitimate?<p>I ran an MMO a while ago, and we would have a few hundred login packets spammed every minute. When we were DDoS'd, I responded by moving my server to a larger line (1 gbps) since the DDoS itself wasn't nearly as massive. Yet, we had no way of figuring out (at a base level) what was a legitimate packet.

I'm curious about the observed PPS rate. 65 Gb/s is annoyingly large, but network interfaces generally hit pps limits first. The bandwidth graph in this post and post mortem entry is quite interesting. A lot of incoming bytes from customer origins. I'd guess the system cache hit ratio is only 60-70% at peak, dropping to maybe 20-30% during trough. From that I would assume the cache width is quite small, maybe 8-12 hours LRU? I could be misreading that if the average object size is closer to 5kb than 50kb, or if a large number of customers are using it a proxy only fashion.

That might explain djb's tweets a couple days back: <a href="https://twitter.com/hashbreaker/status/246745440798781440" rel="nofollow">https://twitter.com/hashbreaker/status/246745440798781440</a> and <a href="https://twitter.com/hashbreaker/status/246746124222865409" rel="nofollow">https://twitter.com/hashbreaker/status/246746124222865409</a> — he's, uh, not a fan of dnssec but this really seems like more of a failure to apply late-90s recommended practice

EDITED: CloudFlare got great technology, got minor issues with billing (mine case), but solved them after this post.

Does Cloudflare have any competitors yet?

One can still have a public accessible resolver, so long it is TCP-only. Amplification requires UDP spoofing.

The TL;DR; version is "blabla 65GBps DDOS blabla"<p>"we solve it by having 100's GBps networks" (and redirect whatever is legitimate to the client ofc)<p>Okay. Maybe my expectations were set too high :)<p>Leaves me to wonder what they can do if the traffic looks 100% legitimate.

If I read this correctly, then googles 8.8.8.8 dns service is an "open resolver". Are they used for dns reflection attacks?

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.<p>Am I the only one getting this error?

It's scary that a 65Gbps DDos might soon only require about 100 KC home broadband lines.

Interesting. DNS reflection is one I hadn't heard about before. Very interesting.

I tried to send a udp packet with fake source Ip(no evil, i am not a attacker;),but i was failed. I seems that the router of the datacenter censor the packets and drop it; who can taught me how to make it?

so, if I'm understanding correctly, this is what's going on? <a href="http://i.imgur.com/iSxTQ.jpg" rel="nofollow">http://i.imgur.com/iSxTQ.jpg</a>