Blog What we do Support Community
Login Sign up

The Wednesday Witching Hour: CloudFlare DoS Statistics

by John Graham-Cumming.

Data from inside CloudFlare's network shows that over 40% of the time there's a denial of service attack happening and directed at us. And that's just up to network layer 4 (i.e. it doesn't include more sophisticated attacks targeting applications themselves at layer 7).

The Wednesday Witching Hour: CloudFlare DoS
Statistics

Still of the Night

Those attacks literally keep our network engineers awake at night: the busiest time is during the night in the USA. This graph shows the number of 'attack minutes' (number of attacks in each sampled minute; often our engineers are dealing with multiple attacks at the same time) by UTC hour. The peak corresponds to morning in Europe and the deep, dark night in the US.

The Wednesday Witching Hour: CloudFlare DoS
Statistics

The attacks also keep them busy all week, but, like many of us, attackers seem to be at their best mid-week when they've shaken off those Monday morning blues and aren't winding down for the weekend. This graph shows the number of attack minutes by day of the week.

The Wednesday Witching Hour: CloudFlare DoS
Statistics

So, the worst time for DoS attacks is in the middle of the night from Tuesday to Wednesday: the Wednesday Witching Hour. But the real message of those graphs is that DoS attacks simply never let up: they're happening 24/7.

And attackers try everything to bring us and sites on us down. The following graph shows the breakdown of DoS attacks by IP protocol: UDP just nudges past TCP as the majority as reflection attacks using both DNS and SNMP have become very popular. One SNMP reflection attack hit CloudFlare with an aggregate data rate of 21Gbps late last year.

The Wednesday Witching Hour: CloudFlare DoS
Statistics

As CloudFlare is a protection and acceleration service for web sites it's not surprising that 92% of the DoS attacks using TCP are on port 80 (HTTP); and on UDP 97% are against port 53 (DNS). But we've also seen DNS attacks on TCP port 53 and UDP attacks on port 870 and 514 (syslog). Looking into TCP, SYN flooding remains the favorite attack method with 84% of the attacks.

Ironically, DNSSEC is currently making some DNS reflection attacks worse because of the large amount of data that DNSSEC can return. Attackers make EDNS0 requests to servers that are able to interpret them; they do that from forged IP addresses resulting in a large amount of data (in the form of valid EDNS0 replies) hitting a target IP range.

Carpet Bombing and Drive-Bys

We've also seen attackers increasing the intensity of attacks by 'carpet bombing'. To knock off a single web site we see attackers attempting a TCP SYN to the web site's IP addresses, SYN flooding against the DNS server handling the web site and DNS reflection and then the same thing across the entire /24 IP range handling the web server and the entire /24 IP range handling the DNS server.

Those massive attacks keep our network engineers up at night keeping CloudFlare web sites online and fast. But the overall trend in attacks has been slightly down over the last 6 months. We believe that attackers are becoming aware of CloudFlare's DoS protection and are switching to other attack methods (such as trying to break into web sites and not just knock them off line) and we've seen attackers try sophisticated technical and social engineering attacks to break into CloudFlare.

The Wednesday Witching Hour: CloudFlare DoS
Statistics

(Image credit: Flickr user philcampbell)

The other trend is the use of 'booter' web sites to knock other web sites off for a short period of time. These attacks last less than five minutes and appear to be a show of strength by hackers wishing to demonstrate that they can remove a web site from the Internet. Unlike long running DoS attacks designed to make a political point, or cause a business to lose money, these drive-bys are hackers flexing their DoS muscles.

In a future post I'll look at the attacks we see at layer 7 and how our engineers and firewalls keep them at bay.

comments powered by Disqus