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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 1, views: 41.810 •

Attack!

In our tests we aim to keep the number of requests per second from the 'good' client as stable as possible when an attack is carried out. This way, we can compare the statistics of curl-loader in 'peace time' to those generated during DDoS simulations.

To put the performance of the RX1810 in context we have also carried out attacks on the same server using only an iptables firewall. In addition, we tried to tweak the network settings, for instance with FloodMon. This tool did not live up to the expectations, therefore we omitted the corresponding results.

We have carried out the following attacks leading to the corresponding availability of the server:

AttackNo protection Linux firewall RioRey RX1810
TCP/SYN flood, port 80 0,6% 4,6% 90,6%
UDP flood, port 80 9,5% 10,9% 100%
ICMP flood 8,8% 10,1% 100%
ICMP flood, 1500 bytes 4,7% 33,4% 100%
TCP data flood, port 80, 1500 bytes 15,2% 17,0% 76,9%
TCP connections, port 80 4,9% 5,3% 100%
DNS reply flood 0% 90% 0%1

  1. With this form of protection all UDP traffic on port 53 was blocked, though whitelisting DNS servers does offer a solution.

In the table above you can find the availability percentages that were measured after the RioRey was able to react. Our test server may therefore have been unavailable during the first 90 seconds.

TCP/SYN flood on port 80

The aim of a SYN flood is to request as many connections as possible. Whenever a lack of resources occurs, regular connection requests are no longer accepted.

In the case of the unprotected server (SYN cookies were used, though) the SYN flood caused the website to be practically unavailable - only the odd request seemed to filter through. Using the iptables gave a somewhat better result, although the server remained largely or even completely unavailable. The RioRey was a great asset in this type of attack - availability only dropped to a little above 90 percent.

RioRey: tcp syn flood port 80

What we see in this type of attack, as in some others, is that the legitimate client is not able to fully recover itself following the DDoS attack. Insofar as we have been able to verify, this is mainly caused by not properly closing the connections that have been set up. As soon as the added IP aliases of the client were removed and the curl-loader application was restarted, the number of requests did again reach about 1250 requests per second.

UDP flood on port 80

In a UDP flood, very many random packets are produced. This test is therefore mainly concerned with the server's processing capacity.

Although the unprotected server seemed to be better able to withstand this type of attack than a SYN flood, its availability still fell far short of satisfactory. Remarkably enough, using an iptables rule to drop all UDP traffic on port 80 did very little to alter this situation. There is probably not much of a difference between 'ignore UDP traffic on port 80' and 'immediately throw away all UDP traffic on port 80'.

However, the RioRey was very well capable of dealing with this type of attack - it was so effective in blocking bad traffic that, even during the first few minutes, the client did not even notice the UDP flood.

RioRey: upd flood port 80

ICMP flood

The aim of an ICMP flood is the same as that of a UDP flood. Therefore, what matters is the processing capacity of the various network devices. As a result, the effect on the server was nearly the same as with UDP. Also in this case the RX1810 - after having discovered the attack - blocked all attack traffic. By the way, it is possible to block all ICMP traffic and we do not doubt we would have got the same result as in the UDP flood.

RioRey: icmp flood

ICMP flood with 1500B packets

This type of ICMP flood works with substantially larger packets, which allows it to reach the maximum capacity of the network connection. According to the RX1810, interface load during this test increased to 95 percent, the highest value we have measured in any of the tests.

In this type of attack, the availability of the unprotected server was even worse than when it experienced a stream of small ICMP packets. The server that was protected with iptables, and which threw away all ICMP traffic, did show some better results this time. After about ten minutes, availability stabilised in one third of all requests. It seems that for the RioRey the size of the ICMP packets is a sign that something is wrong: this attack was blocked right from the very first packet.

RioRey: icmp flood 1500 bytes

TCP flood with 1500B packets on port 80

In this type of attack, traffic is generated that bears a resemblance to web traffic, but without setting up a connection first. In theory, since this traffic is not related to known connections, protection could easily consist of an iptables firewall with connection tracking. In this case, it should be difficult for the RioRey to distinguish between attack packets and legitimate packets.

Compared to the other attacks, the unprotected server did a relatively good job - an even better one than during the ICMP flood with large packets. Despite the connection tracking feature, the iptables firewall was not much of a help. As expected, the RioRey did have quite a hard time handling the attack. Since there was a continuous stream of requests from a relatively small number of legitimate clients, requests that did not have anything to do with the attack were blocked as well.

However, we believe that, in practice, this attack will have less severe consequences: the requests of our real visitors do not exhibit the regularity of the requests of our legitimate client. However, in this test, even after whitelisting the good clients, the number of legitimate requests per second was lowered by approximately 20 percent.

RioRey: tcp flood port 80 1500 bytes

TCP connection flood on port 80

The aim of this attack, again, is to open as many connections as possible, so that legitimate requests can no longer pass through. As opposed to other types of attack, the connections are fully opened and are even harder to distinguish from those of legitimate clients.

The unprotected server seemed to be quite at a loss here. The number of requests per second that could pass through fluctuated heavily, but remained below 20 percent most of the time, while at certain moments nothing could pass. The iptables protection did not offer much of a solution - traffic patterns became more constant, but availability hardly improved.

This type of attack relies on IP addresses that really exist. The number of different IP addresses is therefore more limited than in a fully random generated attack. This became very evident when we viewed the results: the attackers were detected without much of a delay and were blocked for a longer period of time.

RioRey: tcp connections port 80

DNS reply flood

In this type of attack, source port 53 was used to send random UDP traffic. These packets are hard to distinguish from traffic generated by DNS servers, which, in theory, makes it impossible to use DNS servers.

Sure enough, in the case of the unprotected server it turned out to be impossible to carry out any more DNS lookups. With regard to the server protected with iptables and connection tracking, traffic was as yet hindered, but nearly all DNS replies reached their goal.

The RioRey does not make use of connection tracking and is therefore not able to make a clear distinction between attack and legitimate replies. However, one can create a good work-around by configuring the IP addresses of several known DNS servers to legitimate sources of traffic.


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 software architect. Nu lead developer, met een leidinggevende taak aan het team van programmeurs en systeembeheerders van Tweakers.net.



Populair: Desktops Samsung Gamecontrollers Smartphones Sony Microsoft Games Apple Politiek en recht Consoles

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013