Contributed by NETSCOUT Systems, Inc.
Written by Tom Lynch, NETSCOUT


More than half of all financial services firms will be targets of DDOS attacks this year.

Financial institutions are among the most popular targets for DDoS attacks. Mitigating these attacks is likened to a game of “whack-a-mole” between defenders and attackers, where attackers vary their techniques and intensity while defenders try to keep pace. DDoS attack mitigation is defensive by nature. It is impossible to stop the bad actors, so the only available option is to defend against inevitable attacks. While a defensive mitigation strategy is required, IT professionals need to play some offense to make sure their services can withstand attack. This document describes best practices for applying DDoS Resilience Testing to ensure your services can withstand a DDoS attack before the attack happens.

Test Infrastructure
DDoS Resilience Testing must mimic real world scenarios in order to be effective. This means having your own configurable botnets at your disposal to create and launch attacks using common attack vectors.  Important characteristics of the test infrastructure include:

  • Appear Massively Distributed – DDoS attacks consists of traffic from thousands or millions of source IP addresses. While real botnets vary in size from hundreds to over a million systems, your test botnet will be much more practicable if it resides on a single server or a handful of virtual machines (VMs) that can create traffic that looks like it came from millions of different endpoints.
  • Launch Realistic Attacks – DDoS attacks generally consist of well-known attack vectors that fit into the three broad categories: 1. Volumetric Attacks, 2. TCP State Exhaustion Attacks, and 3. Application Layer Attacks. Using combinations of known attack vectors is critical to testing resilience.
  • Provide Flexibility – DDoS Resilience Testing techniques vary depending on the application or service being tested. Your test infrastructure should support automated test environments via a REST API and should also provide a graphical user interface (GUI) for exploratory testing and larger war games.

How to Test Your Resilience to DDoS Attack
Testing resilience to DDoS attack requires launching attacks of your own in a controlled manner. This can be done in a pre-production test lab; as part of your DevOps automated testing environment; or, with careful planning, in your production network. Using your emulated botnet, you can choose which attack vectors to apply, depending on the test scenario.

Verifying Resilience to Volumetric Attacks
Volumetric attacks are the most common DDoS attacks targeted at enterprises. Attack vectors in this category attempt to disrupt legitime network traffic by saturating all available internet bandwidth available to edge devices and protection systems. These attacks are simply about causing congestion. Testing your network infrastructure resilience to volumetric attacks should begin with these attack vectors:

Attack Vector Description
UDP Flood Floods the target with User Datagram Protocol (UDP) packets with correctly formed headers and random content.
DNS Flood Targets Distributed Name Service (DNS) servers with requests that appear legitime but are intended to overwhelm the server.
Ping Flood Floods the target with ICMP echo requests. The receiving server will attempt to respond to the tremendous volume of requests and run out of resources.
SYN Flood Uses the Transmission Control Protocol (TCP) to overwhelm servers with connection requests. Since the attacker only sends the connection initiation request (SYN) and then moves on, the target continually accumulates TCP connections waiting to timeout.

Since these attacks rely on the sheer volume of traffic to overwhelm a system, testing should be done at the maximum bandwidth available to the target.

Verifying Resilience to TCP-based Attacks
TCP state exhaustion attacks are more sophisticated than volumetric attacks because state exhaustion attacks implement a portion of the TCP protocol, whereas volumetric attacks simply send packets and do not maintain protocol state. TCP state exhaustion attacks target web servers, intrusion prevention systems (IPS), intrusion detection systems (IDS), firewalls, and other services that rely on TCP by forcing the target to reach the limit of concurrent TCP sessions. Once this limit is reached, the target must deny further requests, thereby disrupting service. Even high-performance applications capable of millions of simultaneous TCP connections can be brought down by a TCP state exhaustion attack. Other TCP-based attacks attempt to confuse the server using the TCP protocol. Common TCP-based attack vectors include:

Attack Vector Description
TCP SYN Flood Floods the target with TCP connection requests in attempt to exhaust resources, due to the large number of connections in a half-open state.
ACK Flood Floods the target with TCP packets that have the SYN and ACK flags set.
TCP Space Flood Establishes TCP sessions with the target, and sends messages containing only a single space.
TCP Confusion Flood Floods the target with TCP packets that have all flags set.

TCP-based attacks rely on high volume, but do not require full bandwidth to bring down a target. Testing with these attacks should start at low bandwidth and scale upward to determine when the traffic is identified as an attack, or when the target begins to fail.

Verifying Resilience to Application-Level Attacks
Application-level attacks target some aspect of an application or service at Layer-7. These are the deadliest kinds of attacks, as they can be very effective with as few as one attacking machine generating a low traffic rate. Many application-level attacks use Hypertext Transfer Protocol (HTTP) to target web servers and disrupt e-commerce, an online banking application. Other application-level attacks go after communications infrastructure by flooding public-facing applications, such as a session border controller. Testing resilience to application-level attacks should include the following attack vectors:

Attack Vector Description
SLowloris Exhausts connection resources by sending small chunks of HTTP request headers to the target web server too slowly.
Random Get Floods the target with HTTP GET messages containing a random sequence appended to the selected URI.
HTTP Flood Establishes TCP sessions with the target and generates a high volume of legitimate and unique HTTP GET requests.
Slow Post Establishes TCP sessions with the target and sends legitimate HTTP POST messages at a very slow rate. The unusually slow data rate causes the web server to consume resources while waiting for transactions to complete.
SIP F lood Uses the Session Initiation Protocol (SIP) to flood the target with legitimate SIP messages. Applies to Session Border Controllers and SIP Proxy Servers.

Multi-Vector Attacks
As mitigation systems have become more sophisticated, attacks have followed suit. Multi-vector attacks combine two or more attack vectors to confuse or misdirect mitigation efforts while the real attack goes unnoticed. An attacker might launch a volumetric attack large enough to be detected, but not large enough to bring down the target network. Simultaneously, a relatively low bandwidth application level attack can slowly disrupt a critical service while going unnoticed by mitigation systems. If DDoS mitigation systems are in place, multi-vector attacks should be added to your resilience testing arsenal.

Current trends show that more than half of financial services firms will be targets of DDoS attacks this year, and most of these firms deploy some form of mitigation solution. Attackers know this, and they are continually devising new schemes in hopes of disrupting service. Using a test botnet to verify your resilience to DDoS attack is a far better strategy than waiting for the attack and hoping for the best.