Volumetric Attack DDoS Testing

Layer 3 and Layer 4 volumetric attacks are based, as the name suggests, on volume and causing masses of congestion to soak up your bandwidth. Using high volumes of spurious traffic, either within your network directly or between your network and the rest of the Internet, applications and services are rendered useless with no available bandwidth to utilise.  Volumetric attacks might also involve number of sessions, or extreme packet rates (packets per second) as well as traffic volume (bandwidth).

Internet Service Providers can do little to prevent this kind of attack without completing the objective of the DDoS attack and either throttling, or switching off service to the affected server to protect their other customers. This attitude can take companies by surprise if they are relying on their ISP for protection and have not had a formal conversation about response to DDoS events as part of their bandwidth provisioning process.

So what can you learn from a simple overwhelming DDoS load test against a target server?

The only legitimate use for a DDoS test of overpowering scale is to see if you are obtaining the degree of cloud-based DDoS mitigation that you have contracted for and what proportion of attack traffic ‘leaks’ through.

Care needs to be taken that the target does not suffer from unexpected ‘overage’ charges from the cloud-based mitigator or ISP for test traffic. Otherwise the only lesson learned is that you need cloud-based mitigation to defeat volumetric attacks – and that we presume you already know.

The associated risk is that by creating large flows of traffic and aiming it at a target, you run the risk of, not only saturating your own connection, but also causing collateral damage upstream of your server, impacting your immediate service provider and other connected customers.

So simple large-scale DDoS load tests reveal little and can have serious negative consequences.

How big should the volumetric DDoS test be?

Most network systems have a saturation point at around 85% of load. Above this point the system becomes unstable and prone to shockwaves which lead to sudden exponential increase in latency (lag spikes).

activereach normally recommends that most normal corporate customers test their services to, but not past, 70% of the contracted capacity delivered to the service. Anything above 70% and the test results can be obscured by saturation effects – lag spikes caused by simple overloading, rather than the nature of the DDoS attack itself. This value is also important if the capacity will be required to also service live traffic during the test window. It is also activereach’s normal approach to increase attack intensity in stages, to see which devices in the chain of communication fail first under certain attack conditions.

Keeping the attack below the contractual bandwidth level means that collateral damage to other customers using shared network elements upstream will be minimised.

DDoS testing is a great way of assessing how an MSP might respond to a volumetric DDoS attack, and it is not uncommon for testing to reveal a host of misconfiguration and miscommunication errors.

Even so, activereach has a rigorous policy of notification of upstream ISPs and Internet exchanges for DDoS attack tests above a certain size. It is best practice to notify the ISP of any network testing of this type in any event.

Layer 3 (Volumetric IP level) DDoS tests that activereach can simulate include:

·         DNS NXDOMAIN Flood

·         DNS Query Flood

·         GRE Attack

·         ICMP (Internet Control Message Protocol Type 8) Flood

·         IP Fragmented Garbage Flood

Layer 4 (Volumetric IP level and Protocol Transport level) DDoS tests that activereach can simulate include:

·         ACK Flood

·         Brobot Flood

·         Empty Connection Flood

·         RST Flood

·         SlowLoris

·         SYN Flood

·         TCP Connection Flood

·         UDP Flood

Please browse the activereach DDoS Dictionary for the full range of DDoS attacks that can be simulated our Managed Testing platform.