Keysight Technologies Inc.

04/24/2024 | News release | Distributed by Public on 04/24/2024 06:04

Harnessing Unparalleled Scalability: Recreating the Rapid Reset DDoS Attack’s 398 Million RPS with Keysight BreakingPoint

Harnessing Unparalleled Scalability: Recreating Rapid Reset's 398 Million RPS with Keysight BreakingPoint

In this second installment of our two-part blog exploring the record setting Rapid Reset distributed denial of service (DDoS) attack, we demonstrate how to pair BreakingPoint with Keysight's hyperscale APS-100/400GE series appliances or our powerful CloudStorm load modules to recreate the Rapid Reset attack at scale, allowing users to generate the 398 million requests per second (RPS) as seen wild with this potent DDoS attack.

And in case you missed it, you might want to check out part-one of this blog series called, "Is Your DDoS Mitigation Ready for 398 million Requests Per Second?" in which we explore the underpinnings of the Rapid Reset DDoS attack and show how it starves a server of resources to deny legitimate traffic.

To recap, DDoS attacks are cyber-attacks that flood a target system with traffic to starve that system of resources and deny access to legitimate users. The Rapid Rest DDoS attack leverages the HTTP/2 protocol to flood a target system with multiple, simultaneous HTTP/2 request streams. The client then immediately cancels these requests and sends a fresh batch of requests, repeating this process over and over, overwhelming the target system as it tries to handle this flood of requests and resets.

To recreate Rapid Reset's record setting 398 million RPS, we will use three CloudStorm 100GE 2-port load modules installed in an XGS12-HSL chassis running Keysight's BreakingPoint application and network security testing platform.

Figure 1: CloudStorm load modules as depicted in the BreakingPoint web UI

In this example, we will run the test in "two-arm" mode, where BreakingPoint emulates both the test clients and servers. However, you can also run other variations of this test in "one-arm" mode and send test traffic directly to your own server or service.

Figure 2. Two-arm and one-arm testing configurations

One requirement of a "successful" DDoS attack is the use of many thousands of unique client IP addresses to send the malicious traffic which ensures the connections appear to be legitimate, helping to avoid any DDoS protections that may be in place on the target system. To this end, we have configured more the 300,000 unique IP addresses in BreakingPoint Network Neighborhood for use in this test.

Figure 3. More than 300,000 unique IP addresses configured in Network Neighborhood

Next, we need to add Test Components to configure the test traffic and associate it with the Network Neighborhood settings. For this test we will configure three Application Simulator Test Components ("DDoS Attack Traffic 1", "...2" and "…3"), one Test Component for each CloudStorm load module. Additionally, we enable the "Super Component" feature for each Test Component which ensures that all test traffic is divided evenly amongst the compute resources on each CloudStorm load module.

Figure 4. Adding Application Test Components While it is straightforward to perform dual-stage

Now we need to edit each of the three "DDoS Attack Traffic" Test Components to:

  1. Add component "Client Tags" and "Server Tags" to associate the Network Neighborhood settings we defined earlier.

  2. Define the Test Parameters "Maximum Simultaneous Super Flows" (10M) and "Maximum Super Flows Per Second" (1.5M).

  3. Create a new "Application Profile" to define the detailed characteristics of the DDoS attack traffic.

Figure 5. Adding Client and Server Tags, and editing Test Parameters

If you have followed along to this point, you might be asking, "if we have 3 Test Components ("DDoS Attack Traffic 1", "...2" and "…3"), and each of these have been configured with a Maximum Super Flows Per Second set to 1.5M, won't that only generate 4.5M RPS, well short of the 398M RPS we want to generate?"

Great observation! This does indeed appear to be the case, but remember that the Rapid Reset DDoS attack leverages a feature of the HTTP/2 protocol that allows multiple HTTP streams to be sent simultaneously over a single TCP connection.

The test traffic we will define for this test will generate 100 HTTP GETs for each HTTP transaction (as we can see in the test traffic PCAP below):

Figure 6. PCAP of the test traffic showing 100 GETS and RSTs for each transaction

So, now let's reconsider the traffic being sent:

  • 3 Test Components x 1.5M Max Super Flows/Sec x 100 Requests Per Super Flow or:
  • 3 x 1.5M x 100 = 450M RPS (!)

Ok, back to the test configuration!

Once we create a new Application Profile, (we call it "DDoS Rapid Reset Profile" here), we can add the pre-defined Super Flow called "DDoS HTTP/2 Rapid Reset (no TLS)" to the configuration:

Figure 7. Rapid Reset Application Profiles in BreakingPoint.

We can then view/edit the Super Flow Actions associated with this Load Profile:

Sever SETTINGS Frame

  • SETTINGS MAX CONCURRENT STEAMS "100". This allows 100 streams per session which is required in order to generate the desired 400M RPS

Rapid Reset Request:

  • Rapid Reset Count: "100" This allows us to send 100 RSTs to ensure each HTTP "GET" is followed by a "RST", a key feature of the Rapid Reset attack that further drains resources of the targeted server.

Rapid Reset Response:

  • Custom Data File: "http2_rapid_reset_response.html" This sends a 404 response to simulate the server being unavailable because of the DDoS attack. You can also define a pattern of alternating 200OKs and 404NOTFOUND as server responses for even m

Figure 8. Rapid Reset Super Flow in Actions in BreakingPoint

We are now ready to start the test and can see in the Real Time Statistic window that test quickly ramps up to generate 4.3M transactions/sec which - remember we are sending 100 GETS/RST per transaction - equals 430M RPS, 30M more than the actual Rapid Reset attack!

Figure 9. Realtime Statistics showing 4.3M transactions / 430M RPS

We can also see that while busy, the CloudStorm load module processors are effectively handling this hyperscale traffic load:

Figure 10. Realtime Statistics showing system resources

And finally, these results can be confirmed in the test result report which shows BreakingPoint quickly ramping up to 4.3M transactions/sec or 430M RPS and sustaining that load for the duration of the test:

Figure 11. Test report showing 4.3M transactions / 430M RPS

By harnessing the power of just three CloudStorm load modules (or just three APS-ONE-100 appliances), organizations can emulate this staggering attack volume with exceptional precision. The APS-ONE-100 and CloudStorm load modules both offer a level of scalability and versatility that sets a new industry standard. These hardware solutions not only empower users to test their systems' ability to withstand such attacks but also demonstrate Keysight's commitment to staying at the forefront of DDoS mitigation technology, helping organizations ensure they are fortified against even the most formidable DDoS threats.


Learn more about the APS-100/400GE series appliances, CloudStorm load modules and BreakingPoint application and security test tool.

For more information on mitigating DDoS attacks, including the Rapid Reset attack, please visit:

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack#:~:text=A%20multifaceted%20approach%20to%20mitigations

https://www.cisa.gov/sites/default/files/publications/understanding-and-responding-to-ddos-attacks_508c.pdf