60 Days of Attack Scale & Duration

Over the last couple months we’ve observed a discernible uptick in DDoS attack activity and effectiveness, namely across two vectors; scale and virulence.  The scale bit is easier to qualify and quantify than the virulence bit, as the hostility of a given attack is usually best qualified by the impact on the target, not some raw number crunching output – i.e., it’s all about perspective.  Furthermore, Application layer attacks, much more sophisticated than blind spoofing, common SYN or other Transport layer state exhaustion floods, have seen more use over the last few months – and some of these are very low rate and/or difficult to distinguish from legitimate transactions.  Application layer attacks are also much more difficult to mitigate, and most always require some dedicated ‘surgical mitigation’ devices (e..g, Arbor’s TMS stuff) to mitigate _without effectively completing the attack.

This data below is based on ‘misuse anomalies’ within deployed Arbor Peakflow systems in production networks across nearly 100 ISPs globally – and shared with Arbor via ATLAS integration of our anonymous statistics sharing program.  Misuse anomalies are derived from several functions, but namely that of rate-based statistical anomaly detection associated with one or more interfaces with similar anomaly characteristics, network and transport layer transaction attributes, and an array of time-based buckets.  Each discrete attack is reported per SP system and no aggregation has been performed on this data across ISPs, so a given attack that traverses 3 ISPs (ingress, transit, target network) would indeed be reported here 3 times.  The information on scale, duration, etc..  is aggregated only per-ISP deployment.  Furthermore, because an attack would be reported discretely by an ingress, transit, or receiving network, multiple attack flows across unique trajectories are also not aggregated, so smaller attacks may on the target end be much larger than what’s illustrated here.

The bullets below include information on some of the larger attacks we’ve seen over the last 60 days, with 1Gbps or larger being the base.  In total, we saw a total of 48,280 attacks reported, with 9.8% (4753) being 1Gbps or larger.  Of those, 404 were larger than 10 Gbps, which is significant, and enough to impact pretty much any intended target, and quick likely result in collateral damage to other network services (e.g., VoIP, SLAs for dedicated Internet for other customers within trajectories, etc..).

  • > 10 Gbps     404
  • > 8 Gbps      230
  • > 4 Gbps      1367
  • > 2 Gbps      1165
  • > 1 Gbps      1587
  • < 1 Gbps      43527

After rehashing the output in the chart above a couple times, it indeed seems to be the case that larger attacks typically have longer durations, which isn’t really all that surprising.  Both the uptick in scale and increase in Application layer attacks was reported in the Worldwide Infrastructure Security Report.  We’re working on reporting some longer term trends and more details on attack vectors, etc.., and hope to make those available in the near future.

4 Responses to “60 Days of Attack Scale & Duration”

May 04, 2009 at 3:17 pm, jah said:

9.8% being 1Gbps or larger!

May 05, 2009 at 3:28 pm, Danny McPherson said:

Oops, yah, fixed. Thanks!


June 19, 2009 at 3:20 pm, DDoS guru said:

This is great data. We have seen a major increase in attacks in recent months so this backs up what we are seeing. It only seems to be getting worse, very scary.

July 28, 2009 at 1:14 pm, Mikey said:

Thank you for posting this data. It’s very hard to find ddos trend data posted anywhere on the internet.

One thing we’ve noticed in our studies is that the attacks that come in are spoof-sourced from Chinese IP addresses. During mitigation, because our AS prepend didn’t work as expected for AS’s that *should* be in China, we are forced to assume that the actual sources of these spoofed packets are within domestic ASs.

It would be interesting to see bandwidth data for domestic providers for these types of attacks.

Comments are closed.