Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 1 reactie

Test setup

In practice, it turns out to be rather difficult to carry out a good DDoS in a limited testing environment. During one of our first simulations we actually managed to completely flood the MAC address tables of our office switches and consequently we crippled the entire office network. Generating varied legitimate traffic is not a small feat either. Unfortunately, our budget did not allow us to use expensive testing hardware from companies such as Spirent or Ixia, so we had to make do with packet generator software running on a regular PC.

Our testing environment was set up to resemble the situation in our server rack. To this end, we used two HP Procurve 2520G-8 switches for incoming traffic. Both were coupled to an internal network switch, with one of the two made more important by configuring the priorities in the spanning tree. This switch was protected by the RioRey RX1810.

Behind the internal switch an old SuperMicro server with two Opteron 275 dual cores and 2GB RAM was set up. Thanks to its rather limited capacity, this server is ideal for observing the effects of a DDoS. We also used two discarded Dell 1950s, each containing two Intel Xeon 5150s, 4GB RAM and Broadcom NetExtreme II 5708 network chips to generate the incoming traffic - one for legitimate traffic and one for carrying out the DDoS attack.

Both systems were furnished with a recent Debian installation and a 2.6.32 kernel. The server runs lighttpd, version 1.4.26, with which a few statistic files can be served out.

Test network RioRey RX1810

Legitimate traffic

The 'good' traffic was produced by curl-loader, with which one thousand unique IP addresses were generated. These addresses sent around 1250 requests per second, resulting in 8000 packets per second, or 6Mbps of incoming traffic. Subsequently, we let this program download various files, ranging in size from 100 bytes to 100KB; the smaller files were requested more often to simulate requests for images, javascript and CSS files, etc. The server responded to these requests with approx. 16,000pps, using up a bandwidth of about 190Mbit.

The requests from curl-loader were responded to with a delay of about 1ms on average; unfortunately, the application is not able to make a more precise measurement. However, since the delay increases markedly during a DDoS attack, the differences are noticeable enough.

There are, of course, some differences with the real setup of In reality, there are many more types of requests and also the response times differ more widely than during this test. For instance, we found during a TCP attack that our setup could inadvertently dupe the RioRey: after all, there were 'only' one thousand addresses simultaneously making a request each second. This did not seem to be a problem in other attacks, so we cheated by whitelisting the 'good' IP addresses.

Boom box

The DDoS PC was equipped with two software packages to generate random network traffic. To begin with, we used the random packet generator hping3 to generate sizeable amounts of basic, random attack traffic. Hping is a 'fire and forget' tool that is not able to set up real TCP connections. However, the tool is able to generate about 300,000 packets per second and, although not really suggested by the name, in addition to ICMP traffic it is able to generate UDP and TCP traffic. Using two hping3 processes on our DDoS PC we sent around 350,000 packets per second to our web server.

We used BoNeSi to establish full TCP connections, so that it would also be possible to do something with the incoming return traffic. BoNeSi is short for 'BotNet Simulator'. This tool opens real connections from random addresses and, after a connection has been established, is able to carry out HTTP requests.

Door Arjen van der Meijden

- Lead Developer

In oktober 2001 begonnen met als voornaamste taak het technisch beheer van het forum. Daarna doorgegroeid tot senior developer en softwarearchitect. Nu lead developer, met een leidinggevende taak binnen het team van programmeurs en systeembeheerders van Tweakers.

Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en de Persgroep Online Services B.V. Hosting door True