HTTP DDoS Flood Simulation

The BreakingPoint Storm CTM is a highly effective tool for generating massive amounts of load to stress and measure the resiliency of your web services infrastructure. You can leverage this capability to generate both legitimate and nefarious traffic in order to simulate an application layer Denial of Service (DoS) attack. In this blog post, we will step through the generation of a realistic attack scenario which can be used to evaluate your web infrastructure’s resiliency, especially that of DDoS mitigation systems. Also, If you’d like to try this for yourself, simply download the ATI update released today (68714) and open up the tests prefixed "Blog Post 2010-08-20 DDoS".

Step 1

First, we want to accurately model legitimate traffic. In compiling this blog post, we analyzed real web connections to some popular web sites (Facebook and Yahoo!) as representative samples of real-world web pages. We found that connections to these sites followed a consistent pattern: a single TCP session is established, using HTTP1.1, followed by a GET of the /index.html page. The web client parses that page, then issues a series of GET requests to fetch the many objects on the page. These GETs use the existing TCP connection, and are pipelined – GET requests are issued back-to-back, without waiting for responses from the server.

In most larger web sites (such as the ones studied here), images are often served off of a separate server farm. However, most DoS flood mitigation devices are configured to track connections to only a single or small set of servers, so we won’t reproduce those cross-server queries here. Also, note that you could configure a Super Flow to be as complex as you like and fetch a large number of objects, especially if you wanted to model a specific server or site. For this example, we’ll just model GETting four objects – the main page, a JPEG file, a Flash Video object, and a block of text. The three final requests are pipelined, and the Super Flow is configured with persistent HTTP enabled.

Of course, we could make this simulation much more elaborate, with more objects and object types, and we could easily produce multiple legitimate Super Flows with different object sets, User Agents, custom headers, etc.

Step 2

Botnet clients typically do not take the time to parse responses, so their HTTP requests can typically be identified by their more simplistic GETs of only the main page (or another single URL). In this test, we’ll model the malicious traffic as a Super Flow which only fetches a single page (/index.html).

Step 3

Next, we’ll create an App Profile which generates 10x as many flows of malicious traffic as legitimate traffic. One of the improvements in BreakingPoint’s 2.0 firmware release was per-Super Flow reporting, so we can conduct this simulation with a single App Profile.

We’ll define a large set up source IPs to model the web clients (both legitimate and botnet), and a small subnet of Web servers.

Step 4

Now, we run the test, and see if our DoS mitigation device can detect or minimize the attack. While the test is running, we can use the Storm CTM’s Real Time Statistics to examine network utilization – and we see that we’re saturating the 1Gb interface in use.

Looking at the test results, we see that we did indeed generate 10x as many malicious connections as legitimate.

We could also examine our report details to see if any of the connections failed – to determine whether our mitigation device was blocking malicious connections or inadvertently dropping legitimate ones.

Step 5

Stateful, application-layer attacks such as HTTP floods are typically not from spoofed IP addresses, because there has to be a working bidirectional route between the attacker and server. However, attacks may come from specific geographic regions, or mitigation efforts may block certain regions during an attack from which few legitimate connections typically originate. BGP route injection is a typical tool in such blocking efforts.

For the next test, we’ll leave only the legitimate Super Flow in the App Profile of the original AppSim component, and we’ll move the malicious Super Flow to a new AppSim component. However, we’ll create a new network domain using the 69.57.226.0/24 network, which is assigned to Switzerland.

Now let’s look at the Storm CTM’s Reporting capabilities. First, we’ll right-click on our newly created Evil AppSim component to disable it, then we’ll run our simulation with only the legitimate traffic and examine our resulting report. Here, we see that in the absence of attack traffic, we’re successfully conducting about 1,000 legitimate HTTP transactions per second.

Next, we’ll configure the individual AppSim parameters to once again create 10x as many malicious requests and legitimate ones, this time by adjusting the Maximum Sessions Per Second setting for each component. Running this test will let us measure the detection and blocking capabilities of our DOS flood mitigation device against attacks coming from specific IP ranges. At the end of the simulation, we can examine our test results to see what the effects of our efforts were on both malicious and legitimate connections.

Next, we’ll enable the AppSim component with the Evil traffic. When running our test, we can view the Real Time Statistics to see that the TCP Connections per Second rate is right at 11,000 which matches our configuration settings.

We can also look at our detailed test results to see what kind of transaction rate our legitimate traffic was able to sustain while the attack was underway.

Other Variations

There are many variations which can be applied to make these simulations even more realistic or adapt them to specific sites or testing requirements. Very complex and specific web sites may be modeled, along with mixes of different User Agents, cookies, and other HTTP specifics. We can also adjust connection rates, source IPs, and even Load Profiles to mimic an attack which changes over time.