Statistics of amplification DDoS attacks over last six months | Hacker News Reader

Statistics of amplification DDoS attacks over last six months

blog.cloudflare.com

41 pointsmajke8 comments

Author here. AMA! This post was tough, since the industry doesn't really have common language for discussing the packet floods. In this article I tried to build some language and put focus on Gbps, Mpps, Unique IP's, packet lengths, duration of events in aggregate. I know the post is dense in numbers, but we want to encourage folks to be more open with attack data.

Finally, the "flowspec" section is somewhat controversial - for reasons I can't understand - even though Inter-AS flowspec should be a norm, it still isn't.

I wish there was a way to make packets per second and bits per second stand out from each other a bit more. I first glanced at the graphs and thought "20Mbps? I can handle that." It wasn't until I read underneath that it was actually packets per second and 64Gbps.

Love all the detail though. Interesting reading for someone like myself who has always wondered.

A list of major providers that support inter AS flowspec would be nice. My understanding is that the list is empty.

How long does cloudflare keep connection metadata/captured packets?

This blog post explains our attitude to logging:

* https://blog.cloudflare.com/what-cloudflare-logs/

For attack data we do two things:

* We find the attacks and log the attack metadata (dest ip, duration, unique IP count with HLL, etc). This is in database and stored forever. Most of the info in this blog post is from this aggregates.

* We automatically capture pcaps for some packet floods. The pcaps are pretty small, contain sampled packets (not full flows), and in many cases don't contain packet payload (netflow doesn't have payloads). These pcaps are kept for about a month and are automatically rotated. The "tcpdump-like" snippets in this blog post are from these files.

Cool thanks for the link to the blog post.

Have you seen any progress from ISPs on implementing filters to block spoofed IP addresses?

Yes and no. Most of the spoofed attacks fall into two categories.

A) the IPs are fake but from within the originating AS. Fake ip's but belonging to the right AS. Not much to do about it except for pressing the admins to deploy source validation on their cutomers which may be hard.

B) IPs spoofed from whole IP space delivered over a Tier 1 provider. Tier 1 ISP's can't do IP validation for majority of the traffic. Instead we ask them for netflow data - from which of their customers the fake IP's originated. Sadly in most cases they lack netflow infrastructure.

But both of these scenarios are about IP spoofed floods going directly to us. For amplifications there is nothing we can do. We don't know who originated the spoofed traffic aimed at reflector servers.

Reply on news.ycombinator.com