Simulating DDoS Attacks – how many attackers is enough?

January 23, 2017

Botnet sizes vary considerably. In 2006 the Washington Post wrote that the average size was 20,000 hosts. In 2016 the Mirai botnet is believed (by Dyn, one of its victims) to have around 100,000 members. If you want to simulate a realistic DDoS attack and ensure your protected how many attackers should you have

 

It’s not enough to send ‘lots of traffic’ – you need to make the attack traffic distribution look realistic:

In the ‘old days’ testing DDoS involved a pen-tester remotely logged in to a few Internet hosts and manually co-ordinating some commands from a ‘bash prompt’. While this can generate a DDoS the traffic patterns generated vary considerably from what would be seen in the wild. A real DDoS attack features attackers traffic patterns vary considerably based on the compromised hosts CPU and network capabilities as well as the round-trip latency.

Two identical ‘bots’, one topologically close (say in the same country) and the other on the other side of the world will have traffic patterns that look wildly different for layer 7 attacks.

Almost all DDoS mitigation systems have the capability to mitigate aggressive traffic based on identifying source IP’s which exceed simple policy thresholds like:

• High rate of TCP SYN/sec
• High inbound/outbound rate packets/sec
• High inbound/outbound bandwidth in bits/sec
• Exceed threshold of established simultaneous TCP connections

The best type of DDoS testing involves a mix of traffic types to test all of the above controls.

 

What attackers do to try and defeat simple anti-DDoS countermeasures:

It should be obvious that an attacker wanting to defeat the above countermeasures would use a large botnet so that each attacker’s overall traffic rate below each of these thresholds while at the same time the sum of all the attack traffic overwhelms the target.

It is possible to defend against these cases, but it requires non-trivial DDoS countermeasures that many organizations have not deployed or configured.  The common (albiet incorrect) belief that because DDoS attacks are large also means each individual attacker sends an abnormally large amount of traffic. This is often not the case.

Organizations wishing to know effective strategies to block these attacks which often slip through traditional packet-oriented DDoS defense systems can contact RedWolf.

Keeping 3rd party DDoS providers honest:
When testing 3rd party DDoS mitigation providers a common question is ‘do they re-use their blacklists’. RedWolf has found some do and some do not. To keep your 3rd party DDoS provider honest RedWolf suggests mixing in some ‘good traffic generators’ that make low-rate normal HTTP(s) requests to sites.

Here’s how RedWolf does it: RedWolf can simulate real browsers (Chrome, Webkit) as well as API style (curl-like) requests. Every new test RedWolf swaps the IP addresses of the ‘good’ vs. ‘attacker’ IP’s.  The ‘good traffic’ agents should never be blocked and if they are RedWolf can detect blacklist re-use. Conversely if the 3rd party DDoS company being tested whitelists any ‘good traffic’ generator (which they should not do) and RedWolf swaps  it for an attacker then that attack traffic will leak through.

 

So, how many IP’s do you need?

Goal	Number of Attackers	Tactic
Functional testing of the existence (not the finesse) of DDoS mitigation functions	10 cloud agents Geographic dispersion: limited	Rapid start/stop at specific levels that should unambiguously activate DDoS mitigation. Each agent gets 1/10th the overall traffic.
Good run-down of pre-and-post activation levels	200 cloud agents	Start attack at very low levels (say 1 megabit/sec – each attacker gets 1/200th of that), and ramp-up slowly to verify that DDoS mitigation activates before site is overwhelmed. There should be no gap in the protection. Randomly swap good traffic generators and attackers between tests if testing 3rd party DDoS mitigation.
Realistic DDoS Test	400-2000 cloud agents 25% in continent, 75% global, minimum 10 data centers, and 2 cloud  providers.	Start attack at low levels, but randomly vary amount of attack each attacker gets linearly. Some should be 25% of max, some should be 100% of max. Randomly swap good traffic generators and attackers between tests if testing 3rd party DDoS mitigation. Keep groups of attackers in reserve and add them in as attack progresses to simulate new botnet attackers being drafted into the attack. Mitigation systems may take a moment to mitigate the new attackers during which traffic may leak. Generate multiple types  of simultaneous DDoS attack vectors, and swap the attacker/vector combinations and/or change targets periodically.