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:
| Attack | No 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 |
- 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.
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.
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.
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.
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.
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.
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.