Network Computingwww.networkcomputing.com

We used Caw Networks' WebAvalanche as our load-generation tool for two reasons: WebAvalanche creates and uses fully stateful HTTP sessions, and its detailed configuration options let us better emulate real Internet traffic. Other hardware-based load-generation tools do not use and track full Layer 7 application sessions, instead going with the "packet spew" mentality of creating random noise and not interacting with real network services.

Test Setup Click here to enlarge

In these tests, however, we chose to go with a Linux system (2.4.10 kernel) running the Tux 2.0 Web server. The Tux Web server allows a high number of incoming connections from WebAvalanche but still has a resource ceiling by which we could overwhelm the server if stressed. With a full-duplex, 100-Mbps test-network setup, we configured WebAvalanche to generate a baseline that resulted in 5 Mbps of outgoing HTTP requests (which equaled about 570 HTTP transactions per second and more than 6,000 packets per second) for a static 10-Kb Web page, and the Web server sent about 50 Mbps (at more than 6,000 packets per second) of HTTP response traffic.

We configured WebAvalanche to maximize the connection-per-second rate as well as the bandwidth usage. The downside to this configuration is that connections are less latent and generally faster than with the average user's HTTP connection; however, this won't necessarily affect the capabilities of the tested devices to analyze traffic. To add an element of realism -- and make mitigation harder -- we configured the baseline traffic to use only legal IP addresses, according to which address spaces are allocated by the IANA (Internet Address Numbering Authority).

We ran the baseline for an hour before any attacks, letting the devices form their own statistical baselines of traffic. Over the next hour, the DoS attacks were run (see "DoS Dossier"). We relied on WebAvalanche's real-time transaction status graphs to determine how many HTTP transactions were affected by the attack -- and by the mitigation efforts.

We also developed a small monitoring application, which was run on the Web server and gave us simple network stats, indicating incoming traffic composition. We used this in conjunction with WebAvalanche graphs to determine how the Web server was being affected. To help differentiate attack traffic, we configured WebAvalanche to use even-numbered source addresses, while all attack tools were modified to use odd-numbered source addresses.

Unfortunately, we lacked many components we wanted for testing, so we had to custom-code a few things. We made special Linux iptables/netfilter modules to help in the routing of traffic as well as attacking. Many of the attack tools were modified to produce less obvious attack traffic. Of course, the Linux router and Web server had OS/network-level tweaks to boost performance.